The extraction problem is largely solved. Modern document AI reads a skewed, coffee-stained bill of lading, a fifty-line freight invoice, or a supplier's idiosyncratic PO format with accuracy that would have seemed implausible a few years ago. Yet intelligent document processing initiatives stall at a stubborn rate, and the post-mortems rarely blame the models. They blame everything around the models: exception handling nobody designed, validation data nobody could match against, and processes that kept their manual shape with an AI step bolted on. The lesson from our own operating experience in logistics — where paper still moves with every load — is that IDP is a workflow redesign that happens to use AI, not an AI project that happens to touch workflow.
The economics only work in specific places
IDP pays off where three conditions overlap: high document volume, structural variability that defeats simple templates, and a downstream action that data entry currently delays. Freight paperwork is a canonical fit. A brokerage or shipper handles carrier invoices, rate confirmations, BOLs, and proof-of-delivery documents from hundreds of counterparties, each with their own layouts, and cash flow waits on every one — a POD that sits unprocessed is an invoice that cannot be sent. Accounts payable in any enterprise fits for the same reason: variable supplier formats, meaningful volume, and working-capital consequences tied to processing speed.
Where the economics quietly fail: low-volume document types where exception-handling infrastructure costs more than the labor it displaces, documents whose real bottleneck is a downstream approval rather than data entry, and — the most common trap — documents that arrive as unstructured PDFs only because a trading partner hasn't been asked for EDI or an API feed. The best IDP outcome for a high-volume partner is often eliminating the document, not reading it faster.
The three stall points
Stall one: the confidence threshold nobody owns. Every extraction carries a confidence score, and someone must decide the threshold at which a field flows straight through versus routing to a human. Set it too high and the "automated" process sends most documents to review, delivering automation theater. Set it too low and bad data flows into payment runs and load tenders, which is worse than the manual process it replaced. This is a business decision about error tolerance — the cost of a wrong invoice amount is not the cost of a wrong reference field — and projects stall when it is left to the vendor's defaults.
Stall two: extraction without validation. Reading "$14,750" off an invoice is the easy half. Knowing whether $14,750 matches the rate confirmation for that load is the valuable half, and it requires clean reference data to match against. Organizations discover mid-project that their IDP program has a master-data prerequisite no one scoped: you cannot three-way match against records that are inconsistent or missing.
Stall three: the exception queue becomes the process. If exceptions route to a generic queue with no ownership, no service-level expectation, and no feedback loop back into the extraction layer, the queue silently becomes the new manual process — now with extra software in front of it. Exception handling deserves the same design rigor as the happy path, because in month one it is the majority path.
What a working program looks like
The implementations that compound in value share a pattern. They start with one high-volume document type and take it to genuine straight-through processing before adding a second. They instrument the true end-to-end metric — touchless processing rate and cycle time from document arrival to completed business action — rather than headline extraction accuracy, which flatters every project. They treat human corrections as training signal, so the system's performance in month six is measurably better than month one. And they revisit the intake mix quarterly, converting high-volume paper senders to structured feeds so the document stream itself shrinks.
The practical takeaway
Before funding an IDP initiative, answer four questions in writing. Which document types clear the volume-variability-urgency bar? What confidence thresholds will govern straight-through processing, and who owns that risk decision? Is the reference data required for validation actually fit to match against? And who owns the exception queue as a permanent operational function, not a project artifact? Teams that can answer these tend to reach touchless processing that genuinely changes cycle times and working capital. Teams that can't will get an impressive extraction demo, a growing review queue, and a familiar conclusion: the AI worked, and the project didn't.