Supplier invoice checks and routing over your own REST APIs

Supplier invoice checks and routing over your own REST APIs

An n8n workflow that checks a supplier invoice and sends it where it belongs. A webhook receives the name of an invoice file. Your
extraction service reads the document, and the workflow compares the result with your supplier list and open purchase orders. Next it
posts the bill, opens a ticket for a person to check, or alerts accounts payable, and answers the webhook with the outcome.

The workflow holds the rules and the routing, and nothing else. It has no AI model and no accounting system inside. Every outside
system is a plain HTTP request to your own API, so you supply that API or swap each request for a node of your own system.

What is inside

• workflow.json: the workflow as n8n exports it, 18 nodes. 16 of them run and two are sticky notes. It holds no credential.
• README.md: these notes.

What we changed from the original copy

• The address https://api.your-company.example in both Config nodes is now https://<YOUR_API_HOST>.
• The two sticky notes no longer name the template's author or link to its site. They also no longer say the extraction step can call a
  model at base/llm/complete, because the step calls base/documents/extract. The notes now say what the nodes do, and ask you to save and press
  Publish instead of "Activate".
• Nothing else. The rules, the thresholds and the routing are as they were.

Before you start

• An n8n instance, on n8n Cloud or your own server. The original's note asks for n8n 1.100 or later.
• An API that answers the six routes below, or other n8n nodes that reach your systems.
• A mailbox rule, a Drive watcher or an upload form that can send a POST to the webhook.
• A few invoices to try.

The routes the workflow calls

Each route is called against the base address in Config. The nodes have no authentication, so add it to each one as your API needs.

• POST /documents/extract with { "file_name": "...", "mime": "application/pdf" }. It must answer `{ "fields": { supplier, invoice_no,
  date, trn, subtotal, vat, total, currency, confidence, line_items: [{ amount }] } }`.
• GET /accounting/suppliers. It must answer { "rows": [{ supplier_name, trn, approved_limit_aed }] }.
• GET /accounting/purchase_orders. It must answer { "rows": [{ po_number, supplier, amount }] }.
• POST /accounting/bills with the checked invoice. It must answer { "bill_id": "..." }.
• POST /review/queue with the file, the status and the reasons. It must answer { "ticket": "..." }.
• POST /alerts with a channel and a text. Any answer will do.

Set it up

1. In n8n, create a workflow, open its menu and choose Import from File. Pick workflow.json.
2. Open Config and replace <YOUR_API_HOST> in base with your API's host. Check auto_approve_limit, ap_channel and
   total_tolerance. Do the same for base in Config (errors).
3. Add the authentication your API needs to each of the six HTTP Request nodes, or replace them with the nodes of your own systems.
4. Open the Code node Validate: TRN, duplicate, totals, PO match, limit and check the rules. The VAT rate is 5%, a TRN must have 15
   digits, the confidence floor is 0.9, and the limits are in AED.
5. Save, press Publish at the top of the canvas (or Shift+P), and copy the Webhook URL. Point your mailbox or upload form at it. Anyone who has the URL can post to it,
   so keep it private.
6. In the workflow's settings, choose this workflow as the error workflow so that Error trigger sends an alert when a run fails.
7. Try a correct invoice first and then one whose total is off, and read the answer for each.

How a run goes

1. Webhook: invoice received (email, drive or upload) takes a POST with a file_name in its body.
2. Config adds the base address, the limit for automatic approval, the alert channel and the tolerance for totals.
3. AI: extract fields from document posts the file name to your extraction route and gets the fields back.
4. Accounting: supplier master and Accounting: open purchase orders fetch the two lists, and Merge lookups joins them.
5. Validate: TRN, duplicate, totals, PO match, limit runs the rules, listed below, and sets a status and a list of reasons.
6. Route by status sends AUTO_APPROVE to Accounting: post bill, REVIEW to Review queue: human check and REJECT to
   Slack: rejected, AP notified.
7. Outcome builds a short answer with the status, the reasons and a bill id, a ticket or an alert flag.
8. Respond 200 (invoice handled) returns it to the caller.

On any failure, Error trigger starts Config (errors) and Alert ops (Slack), which posts a message to /alerts.

The rules, each with its code:

• V-00: the supplier or the invoice number is missing. Review.
• V-01: the same supplier and invoice number were seen before. Reject.
• V-02: the supplier is not in the master. Review.
• V-03 and V-04: the TRN is not 15 digits, or differs from the master. Reject.
• V-05: the lines do not add up to the subtotal, within the tolerance. Review.
• V-06: the total is not the subtotal plus 5%, within the tolerance. Review.
• V-07: the extraction confidence is below 0.9. Review.
• V-08: the total is over the automatic approval limit and no purchase order matches. Review.
• V-09: the total is over the supplier's own limit and no purchase order matches. Review.

Change the look

• The limits and the alert channel: Config.
• Any rule, the VAT rate, the TRN length or the confidence floor: the Code node Validate: TRN, duplicate, totals, PO match, limit.
• The routes and the systems behind them: the HTTP Request nodes, or your own nodes in their place.
• What the caller gets back: Outcome and Respond 200 (invoice handled).
• Where failures go: Alert ops (Slack).

Good to know

• Not run: Mindket made no call to any API. It ran the validation code on sample invoices on its own machine and checked each rule above.
• Nothing extracts anything by itself. The extraction route receives only a file name and a fixed application/pdf type, so your service
  must be able to find the file by name, and every file is treated as a PDF.
• The TRN length, the VAT rate and the AED limits are built into the code. Change them for your country before you rely on the checks.
• The duplicate check keeps its list in the workflow's static data. According to n8n's documentation, static data is not saved when you
  run a workflow by hand, only for a published workflow that a trigger or webhook runs. The list also never shrinks.
• An invoice sent to review counts as seen. Sending it again after a fix is rejected as a duplicate, so correct it in your review queue.
• The webhook has no authentication. Anyone who learns the URL can send file names and cause bills to be posted, so protect it.
• Posting a bill is automatic when every rule passes. Run it against a test system first.
• The error workflow setting: n8n's documentation describes an error workflow as one that starts with the Error Trigger. It does not say
  whether a workflow may name itself, so make one run fail to test it.
• Your data: the file name and the invoice fields go only to the API you put in base.
• Credentials: the JSON holds none.