OCR invoice processing, and what replaced it

If you evaluated invoice capture before and came away unimpressed, that impression was earned. For two decades the technology worked by learning the coordinates of each field on each supplier's invoice. It worked on your top ten suppliers and fell apart on everyone else — which is backwards, because the top ten were never the problem.

What changed isn't character recognition, effectively solved on clean digital PDFs for years. It's the layer above: the part deciding which number on the page is the total, and which of four dates is the due date.

Why classic OCR broke on real invoices

An invoice is semi-structured. Every one contains roughly the same facts and no two put them in the same place. There's no standard for where the invoice number goes, what a supplier calls the total, or whether tax is a line or a column. Template systems handled this by defining zones per layout: "invoice number is the text in this rectangle." The failure modes followed directly.

The economics were the real problem. Templating paid off where volume per layout was high, and the manual effort concentrated exactly where volume per layout was low.

How modern extraction works

Three things combine.

Text and position, together. Research on layout-aware pre-training — LayoutLM and its successors are the widely cited line of work — showed that jointly modelling what text says and where it sits substantially improves document understanding versus treating a page as a flat string of words. The model learns that a number in the lower right of a table, next to the word "Total," is probably the total, as a general pattern rather than a per-supplier rule.

Vision, not just characters. Systems now read the page image directly, so they handle stamps, handwriting, logos, checkboxes, borderless tables, and the photo a technician took of a delivery note in a van.

Instruction rather than configuration. You define fields in plain terms — "supplier tax ID," "purchase order reference," "payment due date" — and the model extracts against that schema. Adding a field is a schema change, not a retraining project. That's what removes per-supplier setup cost.

So an unfamiliar supplier's invoice extracts at roughly the quality of a familiar one. None of this eliminates OCR — for scans it still turns pixels into candidate text, and its quality caps everything downstream. Pull more fields than you need today; re-processing a year of archives later is the expensive option.

Validation is where accuracy comes from

An extraction model returns values. It doesn't tell you whether they're right. Validation rules do, and most are arithmetic or lookups.

Arithmetic catches a disproportionate share of extraction errors, because a misread digit almost always breaks a sum. It's the cheapest accuracy gain available and doesn't involve the model at all.

PO matching, plainly

Two-way match compares the invoice to the purchase order: do items, quantities and prices agree with what was ordered? Three-way match adds the goods receipt: did the items actually arrive? Three-way is stronger, but only where receiving is recorded promptly — otherwise it generates exceptions caused by your own process.

Set tolerances in both percentage and absolute terms and apply the tighter of the two — an invoice three cents off a PO should never reach a human. Not everything has a PO, either: utilities, subscriptions and professional fees route by coding rules and approval hierarchy instead.

Exception routing

Design the exception path first. A system that handles the clean majority but dumps the rest into one undifferentiated queue has just moved the problem. Route by cause, not by a confidence score:

• Low confidence on a field → review that field, source region shown beside it
• Failed arithmetic → almost always an extraction error; seconds to fix
• Unknown vendor → vendor onboarding, not AP
• PO mismatch outside tolerance → the buyer, who knows what was ordered
• Missing goods receipt → receiving, not finance
• Bank details changed → stop. Verify out of band. Never a routine approval click.

The review interface matters more than the model. A reviewer who sees the extracted value beside the highlighted region of the original fixes an error in seconds. One who has to open the PDF and hunt is slower than typing the invoice from scratch.

What accuracy should you expect

Be sceptical of vendor accuracy claims: the number means little without knowing what was measured. Twelve fields at 98% each is a fully correct document less than 80% of the time. Perfect reading is fiction anyway — the DocVQA benchmark recorded human accuracy at 94.36%.

Measure three things on your own invoices instead. Straight-through rate — the share posting untouched — determines cost. Exception rate by cause tells you whether to fix the model, your PO discipline, or your vendor data. Error escape rate — invoices posted wrong that nobody caught — is the least measured and most important.

Why a human stays in the loop

Three reasons, one of them about accuracy. Accuracy: confidence is a real signal, but confidently wrong outputs exist. Fraud: invoice fraud targets automated AP precisely because automation is predictable, and an invoice from a plausible vendor with altered bank details extracts perfectly while being entirely fraudulent. Authorisation: approving spend is a control, not a data task.

The target isn't zero human involvement. It's routing the matched, in-tolerance majority straight through.

Does e-invoicing make this obsolete?

Eventually, partly, not soon. Structured e-invoicing sends invoice data as machine-readable records rather than documents, removing extraction entirely. The European Union adopted its VAT in the Digital Age (ViDA) package on 11 March 2025, with digital reporting requirements applying to cross-border B2B transactions from 1 July 2030. The United States has no federal mandate. You'll receive structured invoices from some suppliers and PDFs from the rest for years, so build for both.

Frequently asked questions

Is OCR still used for invoice processing?

Yes, as one component rather than the whole system. Optical character recognition converts scanned or photographed pages into machine-readable text, and remains necessary for anything that isn't a native digital PDF. What's been replaced is the layer above it: per-supplier templates mapping page coordinates to fields. Modern systems use layout-aware and vision-language models that interpret structure and meaning, so they read an unfamiliar supplier's invoice with no setup at all.

How accurate is automated invoice data extraction?

High on clean documents, imperfect on all of them, and the honest answer depends on what's counted. Per-field accuracy sounds better than per-document accuracy: a document with a dozen fields is fully correct much less often than any per-field figure implies. Scan quality, layout complexity and handwriting all matter. Treat vendor benchmarks as marketing until you've run the system on several hundred of your own invoices.

What is three-way matching?

Three-way matching compares an invoice against the purchase order and the goods receipt before payment is approved. The order says what was requested and at what price, the receipt confirms what arrived, and the invoice states what's charged. If all three agree within tolerance the invoice posts without review. Two-way matching skips the receipt. Three-way is stronger, but only where receiving is recorded promptly.

Can invoice processing be fully automated with no human review?

You can run it that way, and it's a poor idea above trivial amounts. Two risks make review worth its cost. Confidently wrong extractions exist, and validation catches most but not all. And invoice fraud targets automated accounts payable specifically — an invoice with altered bank details extracts perfectly and is entirely fraudulent. A workable design auto-posts only invoices matched to a PO, within tolerance, from a known vendor whose bank details haven't changed.

How does capture handle suppliers we've never invoiced with before?

Modern extraction handles them with no configuration, the main practical difference from template-based systems. Because the model generalises from layout and language patterns rather than memorised coordinates, a first-time supplier's invoice extracts at roughly the quality of a familiar one. What still needs human attention is the vendor record: an unrecognised supplier should route to onboarding for verification of identity, tax ID and bank details before any payment is released, rather than being created automatically from the invoice.

How does this differ from document processing automation?

Invoice processing is one application of a general pattern. Invoices are a good starting point because they're high volume, structurally similar, and carry arithmetic that validates itself. The same ingest, classify, extract, validate, route and store pipeline applies to contracts, intake forms and statements. If invoices work and you're choosing what's next, document processing automation covers how to decide. The outbound side is accounts receivable automation.