What this covers
- Field extraction from PDFs and scans is largely a solved problem. It is no longer where document projects fail.
- The failure point is validation: reconciling what the document says against what your master data holds.
- Straight-through rate, not extraction accuracy, is the number that determines whether headcount is freed.
- Confidence has to be per field and act on the workflow, not a single score printed next to the document.
A purchase order arrives as a scan. It has a header, a table of eight lines, a delivery address and a set of terms at the bottom. A document processing tool reads it and returns a structured record: customer, PO number, eight line items with codes, quantities and prices, a requested date. It reports ninety-something percent field accuracy and the demonstration ends there, which is exactly where the interesting part starts.
Because the record is not the goal. The goal is a sales order in the system, correct, without anyone keying it. Between those two states sit questions the extraction never touched. Is that customer code ours or theirs? Is the price on line four the price this customer is entitled to? Does 'ea' on line six mean the same thing our catalog means by it? Is the delivery address one we have on file?
Three generations, and what changed
It helps to be clear about what actually improved, because the market talks about intelligent document processing as if the whole problem were new.
| Approach | How it reads | Where it fails |
|---|---|---|
| Template OCR | Fixed coordinates on a known layout | Every new sender, and every layout change from an existing one |
| Trained extraction | A model trained on labeled examples of each document type | Document types with too few examples; drift as formats change |
| Agentic reading | A general model reads the document the way a person does, in context | Not at reading. At deciding what the extracted values mean in your data |
The third row is the real change. A model that reads a document it has never seen, in a layout nobody labeled, and understands that the column headed 'Menge' is a quantity and the handwritten note in the margin is a delivery instruction, removes the setup cost that made document automation a project rather than a feature. That is genuine progress and it is worth the attention.
Reading the document stopped being the bottleneck. Knowing what it means in your systems never was one, and now it is the only one left.
The gap between a field and a fact
Extraction gives you what the document says. Operations need to know what is true. The distance between those is where the work is.
- The document says part 'AX440-SS'. Your catalog has AX-440S. Same item, different string, and no amount of extraction accuracy closes that.
- The document says $98.40. The contract for this customer says $100.80. One of those is wrong and the agent has to decide which before anything is committed.
- The document says 'qty 24'. Your catalog sells that item in boxes of six. Twenty-four pieces or twenty-four boxes changes the order by a factor of six.
- The document has no customer code at all, only a letterhead, and the sender's email domain matches two accounts in the system.
- The invoice has a freight line the purchase order never carried, within a tolerance nobody has written down.
None of these are reading errors. The extraction was perfect in every case. They are reconciliation problems, and they are solved with access to master data, customer history and business rules rather than with a better model.
What a working pipeline actually does
- 01Capture
Take the document from wherever it arrives: a shared mailbox, an attachment, a document library, a scan. Including the email body, which frequently carries terms the attachment does not.
- 02Read
Extract the content in context, including tables that break across pages, handwritten annotations and the difference between a header value and a line value.
- 03Resolve
Match every extracted entity against master data: the sender to an account, each line to a catalog item, each unit to your unit of measure, the address to one on file.
- 04Validate
Check the resolved record against the rules: pricing against contract, quantities against what this account orders, totals against the sum of lines, invoice lines against receipts and tolerances.
- 05Score
Attach a confidence to each resolution, not to the document as a whole, so a single uncertain line can stop one line rather than the entire transaction.
- 06Route
Complete what cleared. Hold what did not, presented to a person as a specific question with the candidates the agent was choosing between.
- 07Commit and log
Write the result into the system of record and keep the full trail: the source document, what was read, what it was matched to, which rule fired.
The number to ask for
Extraction accuracy is a component metric. It is useful to an engineer and misleading to a buyer, because a document can be read perfectly and still require a person for every one of the reasons above.
The number that maps to the business case is the straight-through rate: the share of documents that complete, correctly, with no human touch. It is the only figure that converts into hours. And it is a property of your data as much as of the software, which is why any vendor quoting it without seeing your documents is quoting somebody else's operation.
Two supporting numbers make it interpretable. What share of held cases were held for a good reason, and what share of completed cases were later corrected. A high straight-through rate with a meaningful correction rate is worse than a lower one with none.
What improves the rate over time
A deployment should get better after it goes live, and the mechanism should be legible rather than mysterious. Three things move the number.
- 01Aliases. Every time a person resolves a customer part number to a catalog item, that mapping should be captured, so the same code from the same account resolves automatically next time.
- 02Rules. Cases held repeatedly for the same reason are usually a rule nobody had written down. Writing it down converts a recurring exception into a routine case.
- 03Master data. Held cases point at the specific records that are wrong or missing, which is a far more targeted cleanup than a general data quality project.
Notice what is not on that list: retraining a model on your documents. With agentic reading, the model does not need to learn your layouts. What the system learns is your data, and it learns it from the decisions your own team makes while working the held queue.
Where this shows up
Document processing is not a workflow. It is a capability inside several, and it is worth evaluating in the context of the transaction it feeds rather than on its own: inbound RFQs in quoting, purchase orders in order entry, supplier invoices in finance, and supplier confirmations in procurement.
Each of those ends in a different system with different rules, which is the argument against buying document processing as a standalone tool. Extraction that stops at a structured record hands you a new file to process. The value is in what happens after.