Template OCR fails visibly when a supplier changes layout. Layout-aware extraction fails invisibly. The honest case for each, and why the real question is neither.
Firms evaluating document extraction are usually presented with the choice as a generational one: the old approach, template-based OCR, versus the new approach, layout-aware extraction. Pick the new one.
That framing obscures the thing that actually determines whether either works in a firm. The two approaches do not differ mainly in accuracy. They differ in how they fail, and for accounting work the failure mode matters more than the average.
How template OCR works, and how it breaks
Template OCR reads characters off the page and pulls values from positions it has been told about. The invoice number is in this region, the total is in that one. Where the layout is fixed and the scan quality is good, this is fast, cheap and very accurate.
It breaks when the layout moves. A supplier redesigns their invoice, adds a line, shifts the totals block down two centimetres, and the extraction starts pulling the wrong region.
The important property is that this failure is usually loud. The value that comes back is blank, or is obviously not a number, or is a fragment of an address where an amount should be. Somebody notices in the first batch. The system is brittle, and brittleness at least announces itself.
The subtler version is worse: the layout shifts just enough that a plausible wrong value lands in the field. A subtotal read where a total should be, for instance — still a number, still the right order of magnitude, and silently wrong from then on.
How layout-aware extraction works, and how it breaks
Layout-aware extraction reads the page as a whole. It is not looking at a fixed coordinate; it is identifying which value on the page is the total from the labels, columns and lines around it. Change the layout and it generally still works, which is the entire reason firms are moving to it.
Its failure mode is the mirror image, and this is the part evaluations under-weight: when it is wrong, it is wrong quietly and plausibly. It returns a well-formed number in the right field with no indication anything went awry. A digit misread from a poor scan produces a value that is structurally perfect and factually incorrect.
For a firm this is the more dangerous failure. A blank field gets fixed. A confidently wrong figure gets posted, and is discovered — if at all — at a reconciliation weeks later, by which point the cost of finding it far exceeds the cost of the original keying.
The failure both share
Neither approach solves the problem that causes most real extraction errors in accounting documents, because it is not a reading problem at all. It is that document labels do not reliably mean what they say.
A field labelled as a total may be a pre-discount figure, with the actual payable further down. A number presented beside a tax registration label may be a registration identifier rather than a tax amount. A credit note may carry positive values throughout and be a negative document by type alone. A quote and a payment confirmation both look like invoices and neither is a cost.
Every one of these is read correctly by both approaches, character for character, and used wrongly by both. Accuracy of reading is not the binding constraint. Interpretation is. That specific problem is worked through in why supplier invoice totals do not match.
The question that actually matters
Not “which reads more accurately”, but: when this is wrong, will I find out?
That reframes the evaluation, and it is answerable with checks that are independent of whichever engine produced the reading.
- Recompute the arithmetic the document asserts. Subtotal plus tax should equal total. If it does not, at least one of the three is wrong, and you know this without knowing which — which is enough to route it to a person. This single check catches a large share of extraction error and costs nothing.
- Read it twice, independently. Two different engines fail on different things. Where they agree, confidence is high for a real reason rather than a self-reported one. Where they disagree, you have located the uncertainty exactly, and a disagreement is a far better signal than either engine’s own confidence score.
- Validate against the outside world. The line items should sum to the subtotal. The tax should be a plausible rate of the net. The date should be inside the period. The supplier should be one that exists in the ledger. Each of these is a cheap constraint that a misread value tends to violate.
- Classify the document before extracting from it. Establishing that something is an invoice rather than a quote, and a credit note rather than a bill, prevents a whole category of error that no amount of reading accuracy addresses.
- Read structurally where layout carries meaning. Multi-column documents read as a text stream interleave, producing correct values attached to the wrong rows. Reading by position on the page rather than by order in the file avoids it.
A system that runs these checks and reports what failed them is useful whichever engine sits underneath. A system that does not is asking you to trust it, and trust is exactly what a firm cannot extend to a process whose errors are invisible.
Where each approach is genuinely the right choice
Neither approach is a default, and treating the newer one as an automatic upgrade produces its own waste.
Template OCR is the better answer where a small number of high-volume sources are stable and the scan quality is controlled — a handful of suppliers sending hundreds of identically laid-out invoices a month, or statements from one bank in a fixed format. It is cheaper to run, faster, entirely deterministic, and its output can be reasoned about exactly. Deterministic matters more than it sounds: the same document produces the same reading every time, so a defect found once is a defect fixed permanently.
Layout-aware extraction is the better answer where variety is the defining feature — a long tail of suppliers each sending a handful of documents, photographed receipts, formats that change without notice. Building and maintaining templates across that tail costs more than it saves, and the maintenance burden grows with every new supplier rather than levelling off.
Most firms have both problems at once, which is why the framing as a choice is misleading. A sensible arrangement routes the stable high-volume sources through templates and everything else through layout-aware extraction, then applies the same validation to both. The validation is what makes the mixture safe: because the checks are independent of which path produced a figure, the routing decision becomes an efficiency question rather than a risk one.
That is the practical shape of an answer, and it is rarely what a single-product vendor will recommend, because it is not a product.
What to ask a vendor
The productive questions are not about accuracy percentages, which are quoted against document sets you will never see.
Ask what happens when the system is unsure — whether there is an unsure state at all, or whether everything comes back as an answer. Ask what proportion of a hard sample it declines to resolve; a system that resolves everything on genuinely awkward documents is not confident, it is silent. Ask whether the extracted figure can be traced back to the region of the document it came from, because a value you cannot audit is a value you have to re-key to check. Ask what happens when a long-standing supplier changes template, and whether you would be told or would simply start receiving different numbers.
The honest answer to “template or layout-aware” is that the choice is real but second-order. Layout-aware extraction handles variety better and should generally be preferred for a varied supplier base. But the difference between an extraction system that saves a firm time and one that quietly costs it money is not which engine reads the page. It is whether anything independent checks the reading, and whether the things it cannot settle are put in front of a person instead of guessed.
That principle is what invoice data entry automation is built around: verify against evidence the document itself provides, and raise everything that fails as an exception rather than passing it through.
Questions this raises
Which is more accurate overall, template OCR or layout-aware extraction?
On a stable, high-quality document set that a template was built for, template OCR is extremely accurate and cheap. On a varied set with changing layouts, layout-aware extraction is substantially better. Neither answer is useful without knowing the document set, which is why an accuracy figure quoted without one should be treated as marketing.
Why does a confidence score not solve this?
Because a confidence score is produced by the same system that produced the reading, so it inherits the same blind spots. A system that misreads a digit because the scan is poor will often be confident about the misreading. Confidence is useful for ranking a review queue and unreliable as a gate.
Can we just use both?
That is essentially the recommendation. Two independent readings that agree are strong evidence; where they disagree you have located the uncertainty precisely, which is more valuable than either reading alone. The cost of the second read is small relative to the cost of a wrong figure reaching a ledger.
How do we test a vendor claim before buying?
Give them a sample containing your genuinely awkward documents — the photographed receipt, the supplier who changed template mid-year, the credit note — and ask not for the accuracy figure but for the list of items the system flagged as uncertain. A system that flags nothing on a hard sample is not accurate; it is silent.