For two decades, document processing has competed on a single number. Accuracy. A tool reads 98%, 99%, 99.8% of the fields on a page, and that figure goes on the slide, into the RFP, and onto the contract.

For finance teams, the number meant something specific. If an invoice carried fifteen fields, supplier name, invoice number, date, net, VAT, gross, line items, then reading all fifteen as printed was 100%. Capture the page faithfully, and you were done.

That definition made sense when the job was turning paper into text. It does not make sense now. A number that measures how well a tool reads the page tells you almost nothing about whether the data can do its job inside your ERP.

Accuracy is no longer one number. For finance teams, it is three questions.

Question one: is the extraction right?

Start with the obvious layer. Did the tool read the value correctly? Capture the total as 4,210.00 when the page says 4,210.00.

Here the first crack appears. "Accurate" assumes the document is a reliable source of truth. Often it is not. An order total does not match the sum of its line items. A date reads 03/04/2026, which is March in one country and April in another. A supplier states a VAT amount that the rate does not support. A quantity is transposed.

Faithfully reproducing a wrong value is still a wrong value. A capture tool that reads the page perfectly will hand you the error with full confidence, because reading the page is all it was built to do. Deciding which value is correct when the document contradicts itself is a different task. It needs interpretation, a cross-check against business logic, and reasoning about context. The total should reconcile with the line items. The date should resolve against the supplier's country. The VAT should follow from the rate and the net.

So the first question is not only "did we read it right." It is "is it right," which the document alone sometimes cannot answer.

Question two: is it right for your system?

Now assume the extraction is genuinely correct. Every value matches the page. Every figure reconciles. The data can still be unusable.

The page was written for a human reader. Your ERP is not a human reader. It expects the supplier to match a vendor master record, not the trading name printed at the top of the invoice. It expects a date in one format, a currency in ISO code, a cost center the document never mentions, a tax code from your own table rather than the supplier's wording.

This is where "captured" and "system-ready" part company. The document was read perfectly, and the ERP still rejects it. A line item references a SKU that exists in the supplier's catalogue but not in yours. The supplier reads "ACME Trading Ltd" on the page and "Acme Ltd" in your master data. None of this is a capture failure. It is the gap between what the document says and what the system needs, and it is exactly the gap that lands on an accounts payable desk as a manual correction.

A capture rate of 100% does not close this gap. It cannot, because it is measuring the wrong thing. Data that is accurate to the page but wrong for the system still has to be fixed by hand. The work did not disappear. It moved downstream.

Question three: is it complete?

Here is the question legacy thinking cannot even ask.

If 100% means "everything that is on the page," then the ceiling is set by whatever the supplier chose to include. And suppliers leave things out. A purchase order number is missing. The currency is implied but never stated. A cost center, a GL code, a payment term: absent from the document, required by your process.

A capture tool stops at the edge of the page. There is nothing more to read, so there is nothing more to give. The field comes through empty, and a person fills it in.

An intelligent platform does not stop there. It infers the missing value from context and reference data. It matches the supplier and applies the cost center that always belongs to them. It derives the currency from the country and the bank details. It recognises the purchase order from the line items and your open orders. The output then carries correct, usable data that was never written on the document.

Measured against a number that tops out at "100% of the page," this is data that goes past the ceiling. Not more characters read, but more of what finance actually needs, delivered ready to use. The old metric has no way to describe it. That is the clearest sign the old metric is the wrong measure.

A better definition of accuracy

Put the three questions together, and accuracy stops being a recognition rate and becomes a measure of usefulness.

  • ∙Is the extraction right, including when the document itself is ambiguous or wrong?
  • ∙Is it right for the system that receives it, not only for the page it came from?
  • ∙Is it complete, including the values the document left out?

This is a more honest test, because it measures what finance teams care about. Not how well a tool reads, but how much manual work is left when it is done. A platform can score beautifully on capture and still leave your team validating totals, remapping suppliers, fixing date formats, and keying in the fields a supplier forgot. A platform that answers all three questions leaves them with data they can post.

For anyone evaluating document processing now, the better questions are simple. Does it understand context or only fields? Does it validate against your business logic and master data? Does it correct and enrich on its own, or push exceptions to a queue? Does the output arrive shaped for your ERP, or does it need post-processing first? A capture percentage answers none of these.

The thing itself, not the proxy

This is the shift Docupath is built around. Not a faster reader, but an AI-native document intelligence layer that reads, interprets, validates, and structures document data before it reaches your ERP. Accuracy, in that model, is not the share of a page we capture. It is whether the data lands in your system ready to work: complete, reconciled, and correct, without a person checking it first.

The number on the page was always a proxy. For teams, it is time to measure the thing itself.