Resources · Invoice OCR
Generic OCR gets invoices wrong in a predictable way — and the predictability is exactly what makes it fixable. Why layouts trip parsers up, what a correction loop is, and why a blank field is worth more than a plausible guess.
The problem
Modern OCR reads characters very well. Point it at a scanned invoice and it will transcribe nearly every digit and letter on the page. The mistakes happen one step later — deciding which characters mean what. Is that number the invoice total, the amount due after a partial credit, or the balance carried over from last month's statement? Is that date the invoice date or the delivery date? On an invoice, meaning lives in the layout. And there is no standard layout.
One vendor puts the total in the top-right corner. Another buries it under a remittance stub. A third prints a balance forward that's larger than the invoice itself, one line above the number that actually matters.
"Total," "Amount due," "Balance," "Please pay this amount" — different words for the same field, and sometimes the same word for different fields. Tax shows up per line on one invoice and as a single line at the bottom of another. Freight is a line item here and a surcharge there.
Descriptions wrap across rows, part numbers merge into the description text, and a cramped column grid puts the quantity where the unit price should be. A parser that has never seen the layout has to guess where one line ends and the next begins.
The pattern
A vendor's invoice is a template. Next month's invoice is the same layout with different numbers in it. So when a generic parser misreads a vendor, it doesn't misread them randomly — it makes the same mistake, on the same field, on every invoice that vendor sends. The team fixes the freight charge in March, fixes it again in April, and again in May. Data entry didn't go away; it turned into data correction. But a repeated mistake is a learnable mistake. Random noise can't be fixed. A pattern can.
The fix
A correction loop treats every fix a person makes as something worth keeping. Instead of repairing one invoice and throwing the repair away, the parser stores what the person did — scoped to the vendor whose layout caused it — and reads the next invoice from that vendor differently. The work your team was already doing becomes the training.
A reviewer moves a misplaced total into the right box, retypes a date the parser put in the wrong slot, or splits a merged line description. Ordinary review work — nothing new to learn, no annotation tool, no separate training step.
The correction is stored against that vendor's layout rather than discarded when the invoice is saved. The parser now knows something specific: on this vendor's paper, that number in that position is freight, not tax.
When the same vendor bills again, the parser reads the invoice with the correction applied. The mistake it made last month simply doesn't happen. The fix was made once, not monthly.
The first invoice from a new vendor may take a few touches. Each touch makes the next one cleaner — so the reading improves fastest on the vendors who bill you every month, which is exactly where the hours were going.
Money fields
The dangerous failure in invoice OCR isn't the field the parser can't read — it's the field it reads wrong with confidence. A wrong amount looks exactly like a right one. A plausible number sitting in the total field sails through review, clears approval routing by amount, and gets paid. Nobody catches it, because there is nothing visible to catch.
A guessed unit price doesn't announce itself. It flows into line coding, throws off matching against the purchase order and goods receipt, and can push an invoice over or under an approval band — all while looking perfectly normal on screen.
A blank field is a visible question. It stops the invoice and puts it in front of a person, who fills it in seconds by glancing at the document. Descriptions can tolerate a fuzzy read; totals, tax, quantities, and unit prices cannot.
In a correction loop, the value the person types isn't just a fix for one invoice. It's a correction stored for that vendor — so the field that was blank this month is read correctly next month.
One example
Onivo AP reads emailed and uploaded invoice PDFs with Google Document AI, and a learning layer keeps your team's corrections per vendor — the loop described above, built into invoice capture and OCR. When a field can't be read with confidence, it stays blank for a person rather than being guessed. Downstream, each line is coded to a GL account, cost center, and project, matched within tolerances you set, routed for approval, and — once approved — synced into your ERP through the ERP integration, with every decision kept in a tamper-evident audit trail.
FAQ
Modern OCR reads characters very well; the mistakes happen one step later, in deciding which characters mean what. On an invoice, meaning lives in the layout, and there is no standard layout — every vendor designs their own invoice, and the labels don't agree from one to the next.
A correction loop treats every fix a person makes as something worth keeping. Instead of repairing one invoice and throwing the repair away, the parser stores the correction against the vendor whose layout caused it and reads that vendor's next invoice with the fix applied — so the fix is made once, not monthly.
A wrong amount looks exactly like a right one, so a plausible guess in the total field sails through review and gets paid — there is nothing visible to catch. A blank field is a visible question: it stops the invoice and puts it in front of a person, who fills it in seconds by glancing at the document.
Bring last month's stack — the vendor whose total always lands in the wrong field — and watch the first fix hold on the second invoice.
