Invoice Processing Automation: From Inbox to Posted Entry

The problem

Accounts payable receives documents, not data. A supplier invoice arrives as a PDF attached to an email, or as a scan of a printed page, or occasionally as a photograph of a scan. Someone reads it, works out which supplier it is, checks the arithmetic, finds the purchase order it belongs to, decides which account and cost centre it should be coded to, and types it into the ledger.

None of those steps is difficult. All of them are exacting, and the cost of getting one wrong is measured in duplicate payments and a month-end that will not close.

The volume is also the wrong shape for headcount. Invoices arrive in a spike around period end, which is exactly when the finance team has the least capacity to key them, so the backlog forms in the week it matters most.

What the manual process looks like today

1. Invoices arrive in a shared AP inbox, plus a supplier portal, plus whatever a site manager forwards from their own mail.
2. Someone opens each attachment and works out what it is — invoice, credit note, statement, delivery note, or a chase email with no document attached at all.
3. They key the header fields: supplier, invoice number, date, currency, net, tax, gross.
4. They look for the purchase order and, if policy demands it, the goods receipt.
5. They code the lines to accounts and cost centres, usually from memory of what this supplier normally gets.
6. They route it for approval according to a threshold nobody can recite from memory.
7. They post it, and file the document somewhere it can be found again during an audit.

Steps 3 and 5 are typing. Steps 4 and 6 are lookups. Only the judgement inside step 5 — is this the coding a person would defend to an auditor — genuinely needs a person, and only for the invoices that are not routine.

What this playbook does not attempt

It does not decide to pay. Payment release stays a separate, human-authorised step with its own controls, because invoice fraud works by making a fabricated invoice look entirely ordinary, and an ordinary-looking invoice is precisely what an extraction pipeline processes most smoothly.

It also does not touch supplier bank detail changes. That is the most attacked path in accounts payable, and it belongs in a controlled process with out-of-band verification — not in an automated workflow, however well supervised.

What it takes to implement

A supplier master worth matching against. Extraction gives you a name printed on a page; posting needs a ledger record. The bridge between them is the supplier master, with tax registration numbers and known trading names. If that master is dirty — three records for the same supplier, spelling variants, a "misc supplier" catch-all — the matching layer inherits the mess, and the project stalls there rather than on anything to do with the model.

A purchase order discipline, or an honest admission that there is not one. Three-way matching only works where POs exist and receipts are booked. Where they do not, what you are building is intake plus coding, and the exception rate will be higher for good reason. Deciding which of the two you are building is the first scoping question, and answering it optimistically is the most common way these projects miss.

Per-field confidence, not per-document confidence. A document is not right or wrong; a field is. The invoice number can be certain while the tax figure is not. Thresholds are set per field, and the fields that move money — gross, tax, currency, supplier — are set tighter than the descriptive ones.

Deterministic checks that outrank the model. Line total arithmetic, the tax calculation, the net-to-gross reconciliation and the duplicate check are code, not inference. If the arithmetic disagrees with the extraction, the arithmetic wins and the document becomes an exception. A model should never be the authority on a sum.

A correction loop that feeds back. Every human correction is recorded against the field it corrected. That record is what tells you whether the pipeline is improving, which supplier layouts are the problem, and where next week's work should go.

An audit trail joined to the posted entry. The original document, the extracted values, the confidence scores, the checks that ran, who approved it and when — all retrievable from the ledger entry itself. This is not a refinement. It is the thing that makes the automation defensible in an audit, and retrofitting it is far more expensive than building it in.

Where it fails, and what oversight it needs

Scan quality sets the ceiling. A photograph of a faxed copy will not extract reliably whatever runs behind it. The fix is upstream — a supplier portal, a structured e-invoicing format, or simply asking the ten worst offenders to email a PDF. All cheaper than any change to the pipeline.

Line-level matching is much harder than header matching. Headers extract well. Matching invoice lines to PO lines defeats pipelines routinely, because quantities are partial, units of measure differ and descriptions do not agree. Plan for header matching to work early and line matching to be a project of its own.

Tax is jurisdictional and it changes. Reverse charge, mixed rates, exemptions and place-of-supply rules are not something to infer from the face of a document. Encode them as rules, keep them owned by someone in finance, and treat any invoice the rules cannot classify as an exception.

Duplicates arrive legitimately. The same invoice is emailed by the supplier, forwarded by the site, and uploaded to a portal. Deduplication on supplier plus invoice number plus gross runs before anything else — and near-duplicates, same amount with adjacent invoice numbers, need a person rather than a rule.

Straight-through processing is not the goal. It is a metric that can be gamed by lowering thresholds, and the cost of a wrongly posted invoice is much higher than the cost of a review. Watch it alongside the correction rate, never on its own.

How to tell it is working

Three numbers, weekly. The touchless rate — documents posted with no human field edit. The correction rate per field, which tells you where the pipeline is actually weak rather than where it feels weak. And the age of the exception queue, because an automation that quietly accumulates a backlog of hard cases has moved the work rather than removed it.

If the touchless rate rises while corrections on the money fields also rise, the thresholds are too loose, and you are buying speed with errors you will find at month-end.

What it might save

This scales with invoice volume and with how standardised your suppliers' documents are, so read any figure as an estimate rather than a result. A team processing a few hundred invoices a month with reasonable PO coverage can plan for something in the range of 30% to 60% of documents posting without a human field edit once the common supplier layouts are covered, with the remainder arriving pre-filled rather than blank. Below roughly a hundred invoices a month it is hard to justify on time saved alone — though the duplicate check and the audit trail can still be the reason to build it.