What is document AI (intelligent document processing)?

Document AI, also called intelligent document processing or IDP, is software that reads documents such as invoices, contracts, forms, and reports and turns them into structured data your systems can use. Modern tools are very good at the reading itself. The harder, less-solved part is placing what they read into the right structure, and that is where most of the real errors come from.

Why does document AI make placement errors if it reads the text correctly?

Because reading and placing are different skills. A model can transcribe a value perfectly and still not be able to say which line, section, or record it belongs to. When it reasons about location in words instead of positions, tying the value back to the exact spot on the page fails often. This is the reference gap, and it produces confident, wrong output that is easy to miss because the characters look right.

How do I evaluate a document AI vendor?

Test on your hardest documents, not the clean sample. Watch whether each extracted value lands in the right row, section, or record, not just whether the characters are correct. Ask what the system does when it is unsure, because one that flags a doubtful case for review is safer than one that guesses silently. And price the reconciliation layer, not just the reading model, since that is where the real cost and the real risk sit.

What is the reference gap in document AI?

The reference gap is the difference between reading a detail and being able to point back to exactly where it belongs. DeepSeek named it in 2026. In document AI it shows up as placement error: the model reads a total, a clause, or a footnote correctly but attaches it to the wrong line, section, or sentence. We measured it on a real 700-page document and found roughly half of about 4,700 footnotes had no reliable spot to attach to after the first pass.

What document AI still gets wrong: the reference gap

TL;DR

Document AI has mostly solved reading. The unsolved part is placement: binding what the model read back to the right spot, the total to its row, the clause to its section, the footnote to its line. That gap is what decides whether the output is trustworthy.
In our own document AI pipeline, on a real 700-page document, about half of roughly 4,700 footnotes had no reliable spot to attach to after the first pass. Reading was never the hard part. Placing was.
When you evaluate document AI, do not watch it transcribe. Watch it place, on your hardest documents, and check what it does when it is unsure.
A cheap trick helps: ask the model for a coordinate, not a description. But it only cleans up the last mile. The real ceiling is whether the model detects the thing at all.

Watch a document AI demo and the problem looks solved. You upload a contract, an invoice, a dense report, and the tool reads it back cleanly: every line, every number, every clause. Reading really is close to solved now. Modern vision models transcribe even hard documents well.

Then you put it into a real workflow, and a quieter problem shows up. The tool read the total correctly but attached it to the wrong line item. It read the footnote but tied it to the wrong sentence. It read the clause but filed it under the wrong section. The characters were right. The placement was wrong. That gap, between reading something and knowing where it belongs, is the part of document AI that is not solved, and it is the part that decides whether you can trust the output.

Reading is easy. Placing is hard.

DeepSeek gave this problem a name in early 2026: the reference gap. A model can see a detail perfectly and still not be able to point back to exactly where it came from when it reasons in words. Reading is one skill; pointing is another, and the second is the one that is not solved.

For a buyer, that distinction is the whole game. In document-heavy work the value is not in reading a number. It is in binding that number to the right place: this total to that line, this citation to that source, this obligation to that party. Get the reading right and the binding wrong, and you have a confident, wrong answer. That is worse than an obvious error, because nobody catches it.

What it looks like in production

We hit the reference gap in its purest form building our own document AI pipeline, one that turns a scanned book into a faithful translated document. The reading was never the hard part. Placing the footnotes was. On a real 700-page document, about half of roughly 4,700 footnotes had no reliable spot to attach to after the first pass, and closing that gap took a thirteen-module repair system plus a person confirming the hard cases by hand. We wrote up the full study, with the numbers and the method, in the reference gap: a field study.

The lesson generalizes well past footnotes. Swap “footnote to its line” for “line item to its total,” “clause to its section,” or “lab value to its patient,” and it is the same problem, now in invoices, contracts, and records. Reading is close to free. Placement is where the engineering lives, and where the risk lives with it.

Why the demo hides it

A demo is built to show reading, and reading is the part that works. It shows clean transcription on a clean page. It rarely shows a document with three totals that could each belong to the line you care about, or a clause that could attach to two different sections. Those are the cases where placement breaks, and they are exactly the cases a short demo leaves out. The demo is not dishonest. It is just answering the easy question.

So the useful question to ask a document AI vendor is not “can it read my documents.” It is “can it put what it read in the right place, on my hardest documents, and tell me when it is not sure.”

How to test for the reference gap

If you are evaluating document AI, four checks separate a real product from a good reader.

Bring your messy documents, not the clean sample. Test on the pages with crowded tables, ambiguous references, and poor scans, because that is where placement fails. A tool that only works on the tidy example is not the one you are buying.

Watch placement, not transcription. Check whether each extracted value lands in the right row, section, or record, not just whether the characters are correct. Correct characters in the wrong slot is the failure that costs you.

Ask what happens on uncertainty. A system that flags a doubtful placement for review is safer than one that guesses silently. Silent wrong placements are the expensive kind, because they ship looking right.

Price the whole system. The reading model is the cheap part. The reconciliation layer that makes the output trustworthy is where the real cost sits, and where a thin vendor is exposed. If a plan prices only the OCR, it is pricing the easy 20%.

The cheap trick, and its ceiling

There is a cheap fix worth knowing about, because it tells you where the difficulty really is. Instead of asking a model to describe where something is, you can ask it for a coordinate, a point on the page. A point is exact where a description is vague. In our own tests it helped: it placed items the word-matching approach had missed, never once placed one wrong, and cost about a tenth extra.

But it only cleans up the last mile. The harder ceiling is detection: whether the model notices the thing at all. When it does not, no amount of clever placement helps, because there is nothing to place. That is the honest boundary. Cheap grounding tidies the placement you can already reach; getting the model to see reliably in the first place is the part that still takes real work.

Where this leaves you

If you are buying document AI, the reference gap is the thing to probe before you commit, because it is the thing the demo is built to hide. If you are building it, the placement layer is where your effort and your budget belong, not the reading. Either way, the reading is the easy 20%, and the trustworthy 80% is the part worth measuring.

This is the kind of production reality we pressure-test for clients before they buy or build. If you are evaluating a document AI vendor, our AI technical due diligence work runs your hardest documents through it and reports where the placement breaks, not just how well it reads. If you are building, our LLM and RAG evaluation work is about exactly this: measuring whether the output can be trusted, one hard case at a time. If either is on your desk right now, start a conversation.