Intelligent document processing is the automated reading of business documents such as invoices, orders and delivery notes into structured data, using trained models rather than fixed templates. We think extraction is now the straightforward part, and that what a buyer should judge is everything that happens after it.
Every IDP demo goes the same way. A supplier invoice appears on screen, coloured boxes settle over the header fields, a confidence score of 98.4% flashes up, and the room is impressed. Six months later the finance team is still opening a queue every morning, because a document read correctly is not a document that has been dealt with. This guide covers what the category actually contains, where the numbers mislead, and what has to sit behind extraction before anyone's day gets shorter.
At Lleverage we build AI agents that read the document and then finish the job. They apply the customer-specific rules, post the record into the ERP and route the exceptions with the context attached. That is the pay-and-collect work where most of this starts. Every number below names its source, and where we could not verify one, we have said so rather than rounded it up. If you would rather test it than read about it, book a demo with your own awkward documents.
What is intelligent document processing?
Intelligent document processing, usually shortened to IDP, is a category of automation that takes an unstructured or semi-structured business document and returns structured data a system can act on. It classifies the document type, locates the relevant fields wherever they sit on the page, reads them, validates the result against reference data, and hands the output onward.
The category name is a vendor construction rather than a standards-body term, and the boundaries move depending on who is selling. ABBYY, IBM, Databricks and a long tail of specialists all publish a definition of IDP, and they broadly agree on the mechanism while disagreeing about where the product should stop. That disagreement is the most useful thing about the category for a buyer, because it is exactly the decision you are making.
Our definition, and we will be explicit that it is ours: IDP is the reading layer. It is necessary, it is no longer difficult, and on its own it does not reduce anyone's workload, because reading was never the slow part of the process.
What counts as a document here?
In practice, the documents that matter in a manufacturing, wholesale or logistics back office fall into a short list, and they behave very differently from one another.
- Purchase orders and sales orders arriving as PDF attachments, Excel sheets with the customer's own column names, or the body text of an email
- Supplier invoices, in as many layouts as you have suppliers, increasingly alongside structured e-invoices
- Delivery notes and packing lists, often photographed rather than scanned, sometimes handwritten in the margin
- Certificates and compliance documents, where a single wrong field has consequences well beyond an admin correction
- Technical documentation, which is read for answers rather than extracted into fields
That last category is a useful reminder that IDP is not only about pulling fields into a form. Oude Reimer unified 170 manuals from more than 15 manufacturers into one searchable knowledge base, where troubleshooting questions that used to mean scrolling through hundreds of pages now return referenced answers in about 70 seconds.
How does intelligent document processing work?
Five stages, in the same order in every product, whatever the marketing calls them. Understanding the stages matters because vendors differ enormously in which ones they actually do, and a demo tends to show stage three at the expense of everything else.
Stage 1: ingestion and capture
The document arrives, from a shared mailbox, a scanner, a supplier portal or an EDI feed, and is converted into something a model can read. Scanned paper is de-skewed and cleaned up. A native PDF keeps its text layer. This stage is unglamorous and rarely fails, though photographs taken on a phone in a warehouse remain the honest exception.
Stage 2: classification
The system decides what the document is. Invoice, order, delivery note, credit note, or something nobody anticipated. Misclassification here is quietly expensive, because every later stage applies the wrong expectations to a document that was never what it claimed to be.
Stage 3: extraction
The part everyone demos. Fields are located and read: supplier, invoice number, dates, line items, quantities, prices, totals. Template-based products need to be told where each field sits for each layout. Model-based products infer position from context, which is why they survive a supplier redesigning their invoice and template-based products do not.
Stage 4: validation
The extracted values are checked against something real: does this supplier exist in the ERP, does the article number resolve, do the line items sum to the stated total, is this invoice number already booked. Validation is where a confident wrong answer gets caught, and it is the stage most often thinner than the buyer assumed.
Stage 5: output and human review
Structured data is handed to the next system, and anything below the confidence threshold goes to a person. This is where an IDP product traditionally stops, and precisely where the buyer's problem starts. "Handed to the next system" is doing an enormous amount of work in that sentence.
How is IDP different from OCR and from AI document processing?
OCR turns pixels into characters and has done so for decades. It has no idea what any of those characters mean. IDP adds classification, field-level understanding and validation on top, so the output is not text but a structured record with named fields.
The relationship to "AI document processing" is less tidy, and the honest answer is that the two terms overlap almost entirely. IDP is the older, more enterprise-flavoured label associated with established vendors, while AI document processing is the newer phrasing for the same job done with modern models. We use them interchangeably, and we have written separately about how AI document processing works and where it stops if you want the mechanics rather than the category.
| OCR | Template-based IDP | Model-based IDP | Document agents | |
|---|---|---|---|---|
| Output | Raw text | Fields, per known layout | Fields, layout-independent | A posted record in your system |
| New supplier layout | No concept of it | Needs a new template | Handled without setup | Handled without setup |
| Understands meaning | No | Only where mapped | Yes, at field level | Yes, plus your business rules |
| Validates against ERP data | No | Sometimes | Usually | Yes, before posting |
| Decides what to do next | No | No | No | Yes, including exception routing |
| What a person still does | Everything after reading | Maintains templates, clears queue | Clears queue | Handles genuine judgement calls |
The final column is where we sit, and stating that plainly is more useful than pretending the comparison is neutral. The distinction we would defend to anyone is the bottom row: every column except the last leaves a queue behind.
Why does field-level accuracy overstate what IDP delivers?
Because the number vendors quote is measured per field, and your process cares about whole documents. This is the single most common way a business case gets built on sand, and the arithmetic is worth doing in front of the vendor.
Take a supplier invoice with 20 extracted fields, which is modest for an invoice with several line items. If every field is read at 98% accuracy and the errors are independent, the chance that the whole document is perfect is 0.98 raised to the power of 20.
| Per-field accuracy | Chance a 20-field document is fully correct |
|---|---|
| 98% | About 67% |
| 99% | About 82% |
| 99.5% | About 90% |
| 99.9% | About 98% |
This is arithmetic, not a benchmark, and real errors are not perfectly independent, so treat it as an illustration rather than a measurement of any product. The direction it points in is still correct. It explains something buyers find genuinely puzzling: a vendor demonstrating 98% accuracy in good faith can leave a third of your invoices needing a human glance.
There is a second problem underneath the first. Not all fields carry the same consequence, and averaging them hides that. Getting a supplier's address slightly wrong costs nothing. Getting a quantity or a price wrong costs money and may not be caught for a month.
Our position is that you should stop asking for accuracy entirely. Ask for straight-through rate instead: of 100 documents like ours, how many posted correctly with no human involvement at all. It is a harder number for a vendor to produce, it cannot be inflated by counting easy fields, and it is the only one that maps to hours saved.
What has to happen after extraction?
Four things, none of which are reading, and all of which decide whether the project pays for itself.
Matching against what you already know
An invoice means nothing until it is connected to the purchase order and, for physical goods, the goods receipt. That comparison is where the real exceptions live: partial deliveries, price changes, one invoice spanning three orders. We have covered the mechanics in a piece on three-way matching automation; the point here is that extraction hands you a clean record and no opinion about whether you should pay it.
Applying rules that only exist in your company
Every business carries conversions, tolerances and customer-specific quirks that no vendor ships as standard. At Xpol, 25 customer-specific rulesets covering unit conversions, weekday-specific label text and multi-depot splits were encoded into the agent, replacing knowledge that had lived in the head of a retiring specialist. That is not extraction. That is the part that used to be the job.
Writing into the system of record
Structured data sitting in a middleware layer has not saved anyone a minute. It has to become a posted document in Business Central, SAP or whatever you run, with the correct dimensions, cost centres and approval routing. Topa Bathroom Products now has over 90% of incoming orders posted straight into Business Central by an agent, with order confirmations back to the customer within 30 seconds and four FTEs moved onto after-sales and service planning.
Routing what is genuinely uncertain
The remaining cases need a person, and how they reach that person decides whether the exception takes two minutes or two days. A queue entry saying "confidence 0.62 on field total_amount" is not help. The assembled context, the document beside the order beside the receipt with the difference highlighted, is.
"The answers come back with references to the exact manual and section. That is what builds trust — the technician can verify the information themselves before passing it to a customer."- Remco Hooft, Technical Owner, Oude Reimer
Remco is describing technical documentation rather than invoices, but the principle transfers exactly. A system that shows its working gets trusted and therefore gets used. One that produces confident answers with no traceable source gets checked by hand, which returns you to where you started.
Where does intelligent document processing pay off first?
Start where three conditions overlap: high volume, high variety, and a rule set someone can actually articulate. High volume alone is a poor guide, because a thousand identical EDI messages a week were never the problem.
The processes that consistently qualify in a manufacturing or wholesale back office are supplier invoice handling, sales order intake from email, delivery note reconciliation and quote preparation from customer requests. Each arrives in many formats, each is governed by rules the team can explain if asked, and each currently consumes named people.
J. Kisch & Zonen cut repetitive customer questions by 80% with an agent handling the recurring ones. That is the same pattern in a support setting: high volume, high variety of phrasing, and an answerable rule about what a good response looks like.
The processes that disappoint are the mirror image. Low volume with high judgement, such as contract review, where the reading is easy and the decision is the whole job. And anything where the rules genuinely are not written down anywhere, because an agent can encode a rule your team can state, and cannot invent one nobody has agreed.
Should you buy IDP, build it, or buy agents that include it?
Three routes, and the right answer depends less on your size than on how many processes you intend to automate.
- Buy a dedicated IDP product. Sensible when you have one very high-volume document type, an existing workflow system to receive the output, and IT capacity to connect the two. You are buying the reading layer and supplying the rest yourself.
- Build on general models. Viable now in a way it was not three years ago, and genuinely cheap to prototype. The cost lands later, in validation, exception handling, connector maintenance and the ongoing work of keeping accuracy honest. Teams consistently underestimate the last 20%.
- Buy agents that include extraction. The reading layer comes as part of something that also matches, applies your rules, posts and escalates. This is what we build, and the reason we build it this way is set out above: the reading was never the bottleneck.
There is a cost dimension worth stating plainly, because most of this market does not publish rate cards. Established IDP vendors typically price per page or per document, which means your bill grows exactly as the automation succeeds. Lleverage publishes its pricing: one monthly price per agent, from €2.000 per month, with integration and AI usage included rather than metered by volume. We think per-page pricing is the wrong shape for this work, and that is a commercial position as much as a technical one.
How do you evaluate intelligent document processing vendors?
Bring your worst documents, not your cleanest ones, and insist the test runs on them. Assemble fifty real ones. Include the supplier who scans crookedly, the customer who sends orders as an Excel sheet with merged cells, the invoice spanning three purchase orders, and the delivery note somebody photographed on a phone. Then work through seven questions.
- What is the straight-through rate on these documents, meaning posted correctly with nobody touching them? Refuse a field-accuracy figure as the answer.
- What happens when a supplier changes their layout next month? A template-based answer means recurring work forever.
- Does the system validate against our ERP master data before posting, or only after?
- When something is uncertain, what does the person clearing it see on screen?
- Does a human correction teach the system anything, or will the same exception recur next week?
- What does it cost at three times our current volume? Per-page pricing changes the answer dramatically.
- Who owns the connector to our ERP when Microsoft next changes something?
Question five separates the field more sharply than any other. A system that improves as your team corrects it has a fundamentally different cost curve. The alternative needs a project every time reality shifts. The company brain that stores your rules and exceptions is what separates the two. Our reading is that this, rather than extraction accuracy, is where the durable advantage sits.
A worked example: one supplier invoice, end to end
It helps to follow a single document. A supplier emails an invoice for a partially delivered order to a shared finance mailbox on a Tuesday afternoon.
Capture takes the PDF from the mailbox with the sender and subject preserved. Classification identifies it as a supplier invoice rather than a statement or a credit note. Extraction returns the supplier, the invoice number, the date, the payment terms and six line items with quantities and prices. Validation resolves the supplier against the ERP, confirms the article numbers, checks the line items sum to the stated total, and confirms this invoice number has not already been booked.
An IDP product stops here and hands over a structured record. Everything that follows is your problem.
What happens next in an agent-run process is the actual work. The invoice is matched to its purchase order and the posted goods receipt. Five of the six lines match. The sixth was delivered short, because the supplier split the shipment, which means the invoiced quantity exceeds what was received. The company's rule, written down during implementation, is that short deliveries under a stated tolerance are accrued and flagged to the buyer rather than blocked. The agent applies it, posts the five clean lines, holds the sixth, and sends the buyer a message with the invoice, the order line and the receipt side by side.
The buyer confirms in one click that a second shipment is due. The correction is retained, so the next split shipment from that supplier resolves without anyone being asked. Total human involvement: one click, on one line, on one invoice. That is the difference between reading a document and dealing with it.
Frequently asked questions
What is intelligent document processing in simple terms?
Intelligent document processing is software that reads business documents such as invoices, orders and delivery notes and turns them into structured data your systems can use. It classifies the document, finds and reads the relevant fields regardless of layout, validates the values, and passes anything uncertain to a person.
Is intelligent document processing the same as OCR?
No. OCR converts an image into characters with no understanding of what they mean. IDP adds document classification, field-level understanding, validation against your reference data and confidence scoring, so the output is a structured record rather than a block of text. OCR is one component inside most IDP systems.
How accurate is intelligent document processing?
Vendors typically quote field-level accuracy above 98%, which sounds better than it behaves. On a 20-field document, 98% per field means only around two thirds of documents are fully correct if errors are independent. Ask instead for the straight-through rate on your own documents, meaning how many post correctly with no human involvement.
Do we still need people if we automate document processing?
Yes, for judgement rather than typing. Routine documents post without anyone touching them, while genuine exceptions such as a disputed price change or an unexplained short delivery go to a person with the full context attached. The work that disappears is retyping, not deciding.
How long does an intelligent document processing project take?
For a single well-defined process with rules the team can state, expect weeks rather than quarters. Most of that time goes on connecting the system of record and agreeing exception rules, not on the reading itself. Projects that run long usually do so because the business rules were never written down.
Bring the documents that break things
If your team can already name the supplier whose invoices always need fixing and the customer whose orders arrive as a merged-cell spreadsheet, you have everything needed for a real test. Those are the documents worth putting in front of any vendor, including us.
Book a demo with Lleverage with your own awkward documents, and watch what posts, what stops and why. If a straightforward extraction product would serve you better, we would rather say so than sell you an agent you do not need.