OCR digitises text. Invoice processing requires more.

An invoice from a supplier doesn't just contain text — it contains structured business information. The problem is that the same information is expressed differently across every supplier: "Invoice No", "Inv#", "Our Reference", "Document Number". OCR extracts the characters it finds. It has no way to know which field is which.

A finance team processing 200 invoices a month from 40 suppliers is dealing with 40 different layouts, 40 different field labels, and 40 different ways of expressing the same underlying data. OCR gives you the characters. It doesn't give you the meaning.

Every business has rules — even if they've never been written down. Supplier A should always have a PO number. Supplier B's invoices are always zero-rated. GL code 4000 covers direct materials; GL code 5000 covers subcontractor labour. If the VAT rate is 20% and the net is £1,000, the VAT should be £200.

OCR extracts values. It doesn't check them. Every exception, every VAT discrepancy, every missing reference number gets through and lands in your ERP as a data quality problem that someone has to fix manually. The tool that was supposed to save time creates a new category of work.

There is no standard invoice format. Suppliers use whatever their accounting software produces — and that changes when they update their software, merge with another business, or change their template. OCR tools are brittle: they're configured against a known layout, and when the layout shifts, extraction breaks.

Scanned invoices introduce a further layer of complexity. A document scanned at 2 degrees off vertical, or at lower resolution, or with a coffee ring on the bottom corner, produces different character outputs from the same OCR engine run twice. The resulting data requires human review that erodes most of the time saving.

Organisations that deploy OCR for invoice processing typically find that they've shifted the work rather than removed it. Instead of keying invoices, staff are reviewing OCR output — correcting misread characters, filling in fields the OCR missed, checking totals that don't add up.

The measure that matters isn't extraction rate — it's straight-through processing rate: the percentage of invoices that go from receipt to ERP without any human intervention. For most OCR deployments, this sits well below 50%. For Harold, the target is above 90% for trained suppliers.

Harold uses vision AI, not character recognition. The model sees the document the way a human does — it understands that a number in the top-right corner of most invoices is probably the invoice number, that a table of rows with quantities and prices is a line item table, that a reference labelled "Your PO" is the purchase order number even if it's never appeared in that position before.

Per-supplier training means Harold builds a Supplier Profile from examples — 3 to 10 invoices is enough. From that point, every invoice from that supplier is processed using the learned mapping. When the supplier changes their template, Harold adapts rather than breaks.

The validation layer runs after extraction. Harold checks every document against your rules before the data goes anywhere. VAT arithmetic, mandatory fields, GL code assignment, KeyMatch against your supplier master — all of it checked, flagged, or corrected before it reaches your ERP.