Software & AI · Document intelligence · Written and maintained by Haink’s AI adoption team · Updated August 2026 · 13 min read

Document data capture methods — and how to choose between them

The standard article on this subject is a list. OCR, then OMR, then ICR, then intelligent document recognition, then — in the older ones — QR codes and voice assistants, which have nothing to do with getting data out of a business document. You finish the list knowing what the acronyms stand for and no closer to knowing what to use.

This page is a selection framework instead. It rests on one observation that almost never survives into the listicles: the method is chosen by how much the form varies, not by how modern the method is. Get that axis right and the rest follows. Get it wrong and you will pay a language model to read a form you designed yourself.

The methods, and where each actually breaks

Two of those four are not competitors: OCR is an input to the others as often as it is a method in itself, and the current generation of vision models increasingly does its own reading. The real choice is between the last three.

The selection matrix

Three axes decide it. The first does most of the work.

The second axis is cost of error, and it does not change the method so much as what has to be built around it: confidence thresholds, cross-field validation, an exception queue and a human. A wrong middle initial and a wrong payment amount are not the same event, and a system that treats them the same is mispriced in one direction or the other.

The third axis is reproducibility, covered in its own section below, because it decides the answer wherever you will have to explain it to somebody — which is far more processes than the word “regulated” suggests — and because no comparison table includes it.

The arithmetic nobody shows you

Accuracy in this field is quoted at character level and experienced at field level, and the gap between those two numbers is much larger than intuition suggests. A field is wrong if any character in it is wrong, so the error compounds with length:

A 2% character error rate sounds like a rounding difference. On a thirty-character line — a supplier name, an address line, a description — it means getting it wrong nearly half the time. This is why pipelines that look excellent in a benchmark produce an exception queue nobody budgeted for, and why the first question to ask any vendor quoting accuracy is which of the two numbers they are quoting.

It also explains a design rule that looks counter-intuitive: shorter fields are cheaper to automate than long ones, so splitting a captured line into its components early is worth doing even when it feels like extra work.

When rules are cheaper and more reliable

This is the section the rest of this market will not write, because everyone selling in it sells models.

Prefer a deterministic rule or template when:

• You control the form. If the document is your own, the correct engineering answer is usually to fix the form rather than to learn it — add a barcode, fix the field order, make the boxes real boxes. Ten minutes of form design beats a training set.
• The criterion is written down. Validation such as “total equals the sum of the lines”, date ranges, checksum digits, VAT formats — arithmetic and lookups, not inference. A model that learns these will approximate them and then disagree with them occasionally, which is worse than not having them.
• The same input must give the same output permanently. See below.
• Volume is low. Under a few thousand documents a year the labelling effort alone will not pay back, and no amount of model quality changes that.
• Failure must be loud. A template that cannot find its anchor throws an error. A model returns a plausible wrong answer with high confidence. In a process where a silent error propagates, the noisy method is the safer one.

Models earn their place where the input is genuinely unstructured and the pattern is learned rather than legislated: reading a scanned estimate, resolving a contradiction between two documents in the same pack, ranking which cases need attention. The architecture that survives an audit is usually a machine-learned reading layer feeding a deterministic validation and decision layer — the same conclusion reached from the regulatory side in AI underwriting under the EU AI Act and in how AI claims processing works.

Reproducibility, and why it belongs in the choice

Accuracy is the criterion everyone applies. Reproducibility is the one that decides the hard cases — and unlike accuracy it is a property of the method itself, not of how well you tuned it.

It is easy to file this under compliance and assume it applies to banks and pharmaceutical plants. The useful question is narrower and applies almost everywhere: who will you have to explain this answer to, and when?

A regulation is one row of that table, and not the most frequent one. Most explaining happens to counterparties and to your own management, neither of whom has a rulebook and both of whom can make an inconsistent answer expensive. If any row applies to your process, reproducibility is a selection criterion — and the choice of method has already partly made it for you.

Why this matters in practice: a complaint, a dispute or an audit arrives months after the fact and you have to state what the system read and why. A template answers that question by construction. A hosted model may not be able to answer it at all, because the version that produced the output no longer exists. This is the quiet argument for pinning versions and for self-hosting open weights where the process is regulated — the deployment trade-off is covered in on-premises versus cloud LLM deployment and cloud versus private AI.

How to measure it without fooling yourself

Three habits separate an evaluation that predicts production from one that does not.

Weight fields by the cost of being wrong. An unweighted F1 across all fields tells you almost nothing, because it averages the invoice total with the middle initial. Assign each field a correction cost and report the money, not the score.

Draw the test set from the ugly end of production. Not the clean sample someone assembled for the pilot — the night-time photographs, the scans of faxes, the pages someone stapled crooked. If the evaluation set was prepared by a human who wanted the pilot to succeed, it is a demonstration, not a measurement.

Count the exception queue as a cost line, not a failure. Straight-through rate and accuracy trade against each other, and the optimum is almost never 100% automation. A system that routes 15% to a human and is right about the other 85% may be worth far more than one that automates 98% and is quietly wrong about 4%.

What kills the pilot

The clean subset. The single most common cause. A few hundred well-formed documents are assembled, the method performs, and production then delivers the real distribution. The gap is not model quality; the pilot never met the input.

No ground-truth set. Without a labelled hold-out that everyone agrees on, “is it good enough” becomes an argument between opinions, and the project stalls at exactly the point where it should be approved.

A metric with no money attached. If nobody can say what one percentage point of accuracy is worth, nobody can say when to stop tuning — and the project either ships too early or never ships.

Nobody owns the documents. If files arrive across email, a portal and the post with no single accountable owner, there is nothing stable to automate against. Fix that first; it is the general pattern in why AI pilots fail.

The same mechanics under four different rulebooks

What makes the matrix reliable is that the underlying mechanic — classify the page, find the fields, check completeness, flag what a human must look at — recurs unchanged under very different regulation. We have shipped it under civil-aviation maintenance rules in MRO document control, in immigration casework in visa memorandum drafting, under AML and identity rules in identity verification, and the same pattern applies under GMP in batch record review. Four rulebooks, one set of capture decisions — which is the practical reason a selection framework travels better than a list of tools.

Frequently asked questions

Which document data capture method should we use?

It is decided by how much the form varies, not by how advanced the method is. Fixed forms — your own template, a statutory form — are best served by template extraction against anchors: cheap, exact and identical every time. Forms that vary within known limits, such as invoices from two hundred suppliers, suit trainable extraction over layout features. Genuinely arbitrary documents — deal packs, medical records, mixed correspondence — need a model that reads the page whole. Most real document estates contain all three, which is why the useful answer is a routing decision per document type rather than a single method.

Are vision-language models now better than OCR?

Better on hard documents, worse on easy ones. Vision-language models handle noisy scans, unusual layouts and relationships between fields that a text-only pipeline cannot see. On clean printed documents a conventional engine is faster, cheaper and no less accurate, and on a fixed form a coordinate template beats both. Treating the newest method as the default is the most expensive mistake in this area.

Why do small character error rates cause large field error rates?

Because a field is wrong if any character in it is wrong. At a 2% character error rate an eight-character field is wrong about 15% of the time, a thirty-character field about 45% of the time, and a sixty-character line about 70% of the time. Character-level accuracy is the number vendors quote; field-level accuracy is the number your process experiences. Always ask which one is being reported.

When is a deterministic template better than a model?

Whenever the layout is fixed and the answer has to be identical every time. Templates need no training data, cost almost nothing to run, fail loudly rather than silently, and produce the same output from the same input permanently. That last property matters wherever a decision may have to be explained months later — to an auditor, a counterparty or your own management — after the model has been retrained twice.

How should extraction quality be measured?

Against the cost of a correction, not as an F1 score in the abstract. Weight each field by what a mistake in it costs: a wrong invoice total is not the same as a wrong middle initial. Then measure at field level on a held-out set drawn from real production documents, including the worst ones, and track the proportion routed to a human as a cost line rather than a failure.

Does handwriting still break document capture?

It degrades it rather than breaking it, and how much depends on what you need from the handwriting. Detecting that a signature box is filled, or that a checklist cell is empty, is reliable. Reading arbitrary handwritten prose into structured fields is not, and any design that depends on it should carry a human review path by default rather than as an exception.

Related Resources

• Document Data Capture services — applying this matrix to your document estate, and what it costs
• How AI Document Processing Works — the pipeline end to end, once the method is chosen
• Invoice Processing Automation and E-Invoicing Mandates
• How AI Claims Processing Works
• AI Underwriting and the EU AI Act High-Risk Line
• Intelligent Document Processing services