Teardown: the supplier invoice workflow, step by step

Invoice processing is the automation most businesses want and the one most often built badly. It looks simple — read the PDF, put the numbers in the accounting system — and it is not, because an invoice workflow that is 95% correct is worse than no automation at all. A ledger with wrong entries in it costs more to fix than it ever saved.

This is the complete anatomy of how we build one: all nineteen steps, the validation rules, the failure branches, and the four decisions that determine whether it works or quietly corrupts your accounts. It is written so you can evaluate anyone's proposal against it, including ours.

The four decisions that matter

Before any building, four questions have to be answered by the business, not by the engineer. Everything downstream follows from them.

1. What is the matching tolerance? If the invoice says $1,204.50 and the purchase order says $1,200.00, is that a match? Most businesses settle on something like "within 2% or $25, whichever is lower." There is no universally correct answer, and getting it wrong in either direction is costly — too tight and everything lands in the queue, too loose and overcharges sail through.
2. What is the auto-post threshold? Which invoices are allowed to post without a human looking? Common answer: matched to a PO, within tolerance, from a known supplier, under a value ceiling. Everything else gets reviewed.
3. What happens to an unknown supplier? Create the record automatically, or hold for a human? Auto-creating is convenient and is also how duplicate supplier records breed.
4. Who owns the review queue? If the answer is vague, the automation will fail — not technically, but organisationally. A queue nobody owns becomes a backlog, and a backlog becomes people bypassing the system.

Stage 1: Intake and deduplication

Step 1 — Watch the inbox. A dedicated address such as invoices@ is monitored. Not a personal mailbox, and not a shared inbox people also use for conversation, because the automation needs to be able to act on everything it sees.

Step 2 — Separate attachments from body. Most invoices arrive as PDF attachments; some arrive as inline HTML; some arrive as a link to a supplier portal. The third case usually needs its own handling and is worth identifying early, because it is the one people forget to mention during scoping.

Step 3 — Compute a content hash. Every attachment gets hashed. This is the duplicate defence, and it matters more than it sounds: suppliers resend invoices constantly, people forward the same email to two colleagues, and a chased invoice arrives again with "REMINDER" in the subject. Without hashing you will pay some invoices twice.

Step 4 — Check the hash against processed history. Seen before? Log it, link it to the original, and stop. Do not silently discard — a suppressed duplicate should still be visible, because "why has this not been processed" is a question somebody will ask.

Step 5 — Store the original immutably. The source PDF goes to document storage before anything is extracted, with a reference that travels with the record. Every downstream step needs to be able to point back at the original document, and auditors will ask for it.

Stage 2: Extraction

Step 6 — Classify the document. Is this actually an invoice? Inboxes receive credit notes, statements, remittance advice, delivery notes and marketing email. Routing a statement through invoice processing creates a phantom liability. This step is a genuine classification problem and one of the few places a model earns its place.

Step 7 — Extract header fields. Supplier name, supplier tax ID, invoice number, invoice date, due date, currency, subtotal, tax, total, and PO reference if present. Each field comes back with a confidence score, not just a value.

Step 8 — Extract line items. Description, quantity, unit price, line total, tax code. Harder than the header because table layouts vary wildly and multi-page invoices split tables across pages.

Step 9 — Arithmetic self-check. Do the line items sum to the subtotal? Does subtotal plus tax equal the total? This single check catches most extraction errors, because a misread digit almost always breaks the arithmetic. It costs nothing and it is the highest-value validation in the entire workflow.

Step 10 — Normalise. Dates to ISO format, currency to a consistent representation, supplier name matched against your existing records rather than taken at face value. "ACME Ltd", "Acme Limited" and "ACME LTD." are one supplier, and treating them as three is how the supplier list becomes unusable.

Stage 3: Validation and matching

Step 11 — Resolve the supplier. Match against the existing supplier ledger using tax ID first (reliable), then bank details, then fuzzy name matching (least reliable). No confident match means the invoice holds for review — per decision three above.

Step 12 — Check for a duplicate invoice number. Distinct from the hash check in step 4. The same invoice number from the same supplier, with different content, is either a supplier error or something worse. Either way a person should see it.

Step 13 — Find the purchase order. By explicit PO reference where present; otherwise by supplier plus amount plus date proximity. Invoices arriving with no PO are common and are a policy question, not a technical one.

Step 14 — Two-way or three-way match. Two-way compares invoice to PO. Three-way also compares against the goods receipt, which is what you want if you receive physical goods. Apply the tolerance from decision one, and record which tolerance rule was applied — you will want that in an audit.

Step 15 — Apply account coding. From PO coding where a PO exists; otherwise from supplier defaults; otherwise flag for review. Never guess a nominal code. A misposted expense is invisible until month-end and annoying to unwind.

Step 16 — Evaluate against the auto-post rules. All the accumulated evidence — match status, confidence scores, value, supplier standing — is weighed against decision two. The outcome is binary: auto-post, or route to the queue with a stated reason.

Stage 4: Posting and notification

Step 17 — Post idempotently. Create the bill in the accounting system with an idempotency key derived from the content hash. If the workflow is retried after a timeout, it must not create a second bill. This is the failure that costs real money, and it is entirely preventable.

Step 18 — Attach and cross-reference. The original PDF attaches to the accounting record; the accounting reference writes back to the document store. Someone in eighteen months should be able to go from either direction to the other without asking anyone.

Step 19 — Notify and log. Auto-posted invoices post a digest rather than an alert each — nobody wants forty Slack messages a day. Queued invoices notify the queue owner. Everything is logged with extraction confidences, the match decision, and the rule that produced it.

The review queue is the product

Here is the part most proposals underplay. The automation's job is not to process every invoice. It is to process the routine ones and present the rest well.

A well-built queue shows, for each held invoice: the original document alongside the extracted fields, exactly which rule caused the hold, the candidate matches it considered and rejected, and one-click actions to approve, correct or reject. A reviewer should resolve a typical item in under thirty seconds.

A badly built queue is a spreadsheet of invoice numbers with the word "REVIEW" beside them. People stop using it within a fortnight, and then the invoices are processed manually anyway — which is how a working automation gets abandoned despite functioning exactly as specified.

Budget for the queue interface as a first-class part of the build, not as an afterthought. If 15% of invoices are held, that queue is where a fifth of the work now lives.

What this costs and returns

We build this for $14,000 to $22,000. The spread depends on three things: how many suppliers send genuinely unstructured documents, whether you need three-way matching against goods receipts, and whether your accounting system has a decent API.

Running cost is typically $50 to $150 a month — extraction charges plus platform operations. It scales with volume, so high-throughput businesses should model it rather than assume.

Hours returned in the businesses we work with usually land between 15 and 40 a month, which makes this the largest single recovery on our list of common automations. The secondary benefits — no duplicate payments, no missed early-payment discounts, a complete audit trail — are harder to price and frequently worth more.

What it will not do is reach 100% straight-through processing. Anyone promising that is either not counting the exceptions or has not met your suppliers. A realistic target is 75% to 90% auto-posted after the first few months of tuning, with the remainder handled quickly through a well-designed queue.

---

If you are evaluating a proposal for this, the four decisions in the first section are the questions to ask. If the proposal does not address the review queue, the tolerance rules, or idempotency on posting, it is describing a demo rather than a system.