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.

In short

This is a decision problem wearing an extraction problem's clothes. Four questions answered by the business, not the engineer (matching tolerance, auto-post threshold, what happens to an unknown supplier, and who owns the review queue) decide whether the nineteen steps below produce a clean ledger or a quiet mess.

It will not reach 100% straight-through processing, and nobody's does. The job is to process the routine invoices and present the rest well, which is why the review queue is the part of the build worth arguing about.

The supplier invoice workflow, end to end5 stages, 19 steps

Stage 1IntakeSteps 1 to 5. Hashed, deduplicated, stored
Stage 2ExtractionSteps 6 to 10. Fields, then the arithmetic check
Stage 3Matched within tolerance?Yes, coded from the PONo, held for review
Stage 4Auto-post rules met?Yes, posted idempotentlyNo, queued with a reason
The restReview queueA fifth of the work lives here

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.

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.
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.
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.
Who owns the review queue? If the answer is vague, the automation will fail, not technically, but organizationally. A queue nobody owns becomes a backlog, and a backlog becomes people bypassing the system.

The tell

If a proposal for invoice automation does not ask you these four questions, whoever wrote it has not built one before. They are not implementation details; they are the specification.

Stage 1: Intake and deduplication

01Watch 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.

02Separate 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.

03Compute a content hash

Every attachment gets hashed. This is the duplicate defense, 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.

04Check 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.

05Store 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

06Classify 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.

07Extract 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.

08Extract 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.

09Arithmetic 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.

10Normalize

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.

Why the arithmetic check matters so much

Extraction models are good but not perfect, and their failures are plausible. An 8 read as a 3 produces a number that looks entirely reasonable. Confidence scores help, but arithmetic is the check that catches what confidence misses. Any invoice automation without it is trusting OCR further than OCR deserves.

Stage 3: Validation and matching

11Resolve 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.

12Check 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. In both cases a person should see it.

13Find 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.

14Two-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.

15Apply 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.

16Evaluate 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

17Post 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.

18Attach 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.

19Notify 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 badly built queue

A well-built queue

A spreadsheet of invoice numbers with the word "REVIEW" beside them.

The document and the extraction togetherThe original alongside the extracted fields, on one screen.

No statement of what the automation objected to, so the reviewer reconstructs it.

The rule that caused the holdStated exactly, along with the candidate matches it considered and rejected.

People stop using it within a fortnight, and the invoices are processed manually anyway.

One-click approve, correct or rejectA reviewer resolves a typical item in under thirty seconds.

That 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

As a single system this is $3,500 to set up, fixed before work starts: capture, extraction, two-way matching against purchase orders, a review queue and posting into your accounting system. Three things add quoted scope: a long tail of suppliers sending genuinely unstructured documents, three-way matching against goods receipts, and an accounting system without a usable API.

After launch, changes are $175 each on pay as you go, or included in a plan from $700 a month. Separately, vendor charges typically run $50 to $150 a month for extraction and platform operations. It scales with volume, so high-throughput businesses should model it rather than assume.

Hours returned typically 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 often 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.

Teardown: the supplier invoice workflow, step by step