The short version
Template matching breaks whenever a layout changes and breaks silently. Reading for meaning survives layout churn but needs measuring on your own worst documents, not your tidiest. The two things that make a deployment usable are a confidence signal on every field and a validation rule that catches the errors confidence misses.
Why did the last attempt fail?
Because it was configured per document type, and configuration is a promise about layout. The moment a supplier redesigns their invoice, moves the total, or adds a line, the coordinates stop matching.
Worse, it failed quietly. A template that no longer matches does not raise an error — it returns a blank field, or the wrong number from an adjacent box. Teams discovered the problem weeks later in a reconciliation, which is why confidence in these systems collapses so completely after the first bad month.
And the economics were inverted. Templating cost effort per supplier, so it was applied to the highest-volume ones — but those were already manageable. The long tail, where the manual cost actually sat, was never worth configuring.
What is different about reading the document?
A system that understands what an invoice is can find the total on a layout it has never seen, in the same way a new member of staff can. It handles the redesign, the unfamiliar supplier, the two-page invoice with a continuation, and the one where the total is labelled “amount due” instead.
That removes the per-supplier configuration cost entirely, which is what makes the long tail viable for the first time. It also changes the failure mode: instead of silently returning nothing when a layout changes, it returns its best reading — which is more useful and requires a different safeguard, covered below.
How accurate is it?
Entirely dependent on your documents, and anyone quoting a universal figure has not seen them. Clean digital PDFs from a modern accounting system extract very reliably. Photographs of receipts taken at an angle in poor light do not. Faxed and re-scanned documents sit somewhere unpleasant in between.
The only number worth anything is one measured on your own worst material. Take two hundred documents including the ones people complain about, extract them, and compare against the correct values. That is a few days of work and it replaces every vendor claim with a fact you can budget against.
What is a confidence signal and why does it matter?
It is the system telling you how sure it is about each field, rather than only what it read. That distinction is what makes the difference between a usable deployment and an unusable one.
With confidence, you can route: high-confidence fields flow straight through, low-confidence fields go to a person with the document open at the right place. Someone checks the twenty percent the system was unsure about instead of all of it, and that is where the saving comes from.
Without it, every field is equally trustworthy in appearance and equally untrustworthy in fact, so everything gets checked and you have automated nothing. Ask about this early — a proposal that does not mention confidence or routing has not thought about how the output gets used.
What about validation rules?
Confidence catches uncertainty; validation catches confident mistakes, which are the dangerous ones. These are ordinary business rules and they are cheap to add:
- Do the line items sum to the stated total?
- Does the tax figure match the rate for that jurisdiction?
- Is the supplier one you have a record of?
- Is the date within a plausible range, and is this invoice number a duplicate?
- Is the amount within the normal range for this supplier?
Each is a few lines of logic and together they catch a large share of the errors that would otherwise reach your ledger. They are also the part most likely to be omitted from a quote, because they are unglamorous and specific to you.
Do we still need OCR?
For genuinely scanned material, yes — something has to turn pixels into text before anything can read it, and the quality of that step still sets a ceiling. A badly scanned document produces garbled text and no amount of comprehension recovers a digit that was never captured.
Which makes document capture worth attention. Scanning at a sensible resolution, encouraging suppliers to send digital PDFs rather than printed-and-rescanned ones, and rejecting unusable images at the point of receipt will do more for accuracy than any tuning downstream. It is also nearly free.
What does a realistic deployment look like?
A sorting machine rather than a black box. Documents arrive, fields are extracted with confidence scores, validation rules run, and three things happen: clean and validated records post automatically, uncertain fields queue for a person with the document open at the relevant page, and anything failing validation is flagged with the reason.
The measure of success is not extraction accuracy in isolation. It is how much time a person spends per document, and whether the errors that reach downstream systems are fewer than before. A slightly less accurate system that flags its own uncertainty well can outperform a more accurate one that does not.
How should we start?
On documents you have already processed, where the correct answers are known. Extract a real month, compare field by field, and produce three numbers: overall accuracy, accuracy on your worst document type, and what proportion would have been flagged for review.
That last figure is the one that determines whether the project is worth doing, and it is the one nobody asks for. Ninety-five percent accuracy sounds excellent until you learn that forty percent of documents were flagged for checking anyway.
What about documents in other languages?
Generally handled well, and considerably better than templating ever managed — a system reading for meaning does not need a separate configuration per language the way coordinate matching did. Mixed-language documents, common in international shipping and trade paperwork, are also usually fine.
Two things still need checking on your own material: date formats, where an ambiguous numeric date can be read two ways and the consequences are quiet rather than obvious, and decimal separators, where a comma and a full stop mean different things in different places. Both belong in your validation rules rather than in your hopes.
Where should the extracted data go?
Into a structured store you own, not only into the downstream system. Keeping the extraction record — source document, fields, confidence scores, what was corrected by a human — gives you three things: an audit trail when a figure is queried, a labelled dataset showing exactly where the system struggles, and the ability to re-run everything if you change approach.
Teams that pipe results straight into the ledger and discard the intermediate record lose the ability to answer "why did it read it that way?", which is the first question anyone asks when something is wrong.