From inbox to approved payment: every step, every branch and the compliance loop — as a graph your AI can execute instead of a policy document it has to interpret.
Invoice Approval — 9 nodes · 11 connections. Labels on the arrows are the conditions that take each branch.
Invoice approval is the classic case of a process everyone describes in prose and nobody can automate from that prose. The policy says "invoices are matched against the purchase order and approved by the appropriate manager" — but not what happens when the PO number is missing, who approves when the amount crosses a threshold, or how often a correction may loop before a human takes over. An AI reading that policy fills those gaps with guesses.
This graph makes the gaps impossible. Each node carries a contract — what comes in, what happens, what goes out — and every branch is labelled with the condition that takes it. The compliance check at the end is an evaluator with written criteria and a stop condition, so the correction loop cannot run forever. Open it in nodalo, replace the example thresholds with yours, and hand it to Claude, ChatGPT or Copilot to build the automation or run the process.
Each node carries a contract — what comes in, what happens, what goes out. This is the text your AI receives, node for node, when you hand the graph over.
Entry point of the process. An invoice arrives as a PDF or image — by email to invoices@, by upload, or forwarded by a colleague. Capture the file together with its source and arrival date. No interpretation happens here; the document is passed on exactly as received.
Read the document and produce a structured record: vendor name, invoice number, invoice date, due date, currency, net amount, tax, gross amount, purchase order number if present, and line items with quantities and unit prices. Keep the original wording of line items — do not normalise or translate them. If a field cannot be read with confidence, record it as missing rather than guessing a value.
Check the extracted record against the required fields: vendor, invoice number, date, gross amount, tax rate, and a deliverable purchase order number or an explicit note that no PO exists. The outgoing branches are exclusive: an invoice is either complete and moves on, or specific fields are missing and it goes to clarification.
Write to the vendor (or the colleague who forwarded the invoice) and name the exact missing fields — never send a generic "please provide more information". Include the invoice number and a reply-by date seven days out. When the answer arrives, merge the new details into the record and send it back through the completeness check. If the reply-by date passes without an answer, park the invoice and notify accounting.
Compare the invoice against the referenced purchase order: vendor must match, gross amount must be within 2% or 50 of the PO total, and every line item must map to an ordered position. Quantity overruns are a mismatch; price rounding inside the tolerance is not. Invoices that declare "no PO" match only if the amount is under the no-PO limit defined by accounting.
The mismatch cannot be resolved automatically. Create a review task that contains the invoice, the purchase order, and a one-paragraph statement of exactly what differs — amounts, quantities or vendor. A human decides: accept the difference, dispute with the vendor, or reject. Their decision and reasoning are attached to the record before it continues to the audit trail.
Route by gross amount. Up to 1,000: auto-approve, no human involved. From 1,000 to 10,000: the budget owner of the cost centre on the PO. Above 10,000: budget owner plus finance lead, both must approve. If the budget owner is the person who submitted the invoice, approval moves one level up — nobody approves their own spending.
Before payment is released, verify: the tax rate is valid for the vendor's country, the cost centre exists and is open, the approval chain matches the routing rule, and the vendor's bank details equal the ones on file — a changed IBAN always fails this check. If any criterion fails, send the record back to extraction with the specific failure named, at most twice. After the second failure, stop and hand the case to accounting with the full history.
The result of the process: an invoice record marked approved, carrying the extracted data, the match result, every approval with name and timestamp, and the compliance confirmation. It is handed to the payment run and written to the audit trail. Nothing after this node changes the record.
Yes — that is the point of the template. Every node contract is editable in nodalo: replace the example threshold in the approval-routing decision with your own limits, and rewrite the compliance criteria to match your policy. The structure stays, the rules become yours.
Whatever assignment you give it at handoff: generate the automation (for example an n8n or Zapier flow along these steps), run a single invoice through the process step by step, draft the process documentation for your team, or review the graph and report where your rules are still ambiguous.
Because most failed checks are fixable: a wrong cost centre or a missing note does not need a rejection, it needs one correction pass. The evaluator sends the invoice back with the specific failure, at most twice — after that it stops and hands over to a human. The stop condition is what makes the loop safe.
Open the template, adjust the contracts, and hand the graph to your AI — as a specification it can execute, not prose it has to decode.