Intelligent document processing (IDP) turns documents such as invoices, delivery notes, contracts and forms into validated, structured data that your systems can use without someone typing it in. It combines text recognition, classification, field extraction, business validation and human review in one pipeline. The value is not reading the document: it is getting correct data into the ERP with an audit trail.
Our guide to RPA vs AI process automation introduces IDP as one case of intelligent automation. This article goes further: how OCR, classic IDP and LLM-based extraction differ, what each pipeline step must do, how to measure accuracy, and how to decide between buying software and building it.
What intelligent document processing is
There is no single legal definition, but the main references agree on the core:
- AWS describes IDP as automating manual data entry from paper-based documents or document images into digital form, so the data can feed other business processes.
- IBM describes it as extracting business-critical data from documents: sorting them by type, pulling out key fields and formatting the result (often as JSON) for downstream workflows.
Both definitions end in the same place: the data must feed another process. IDP is an integration problem, not just a reading problem. A document that is read perfectly but never reaches the ERP has saved no work.
OCR vs IDP vs LLM-based extraction
These three terms are often mixed up. They are different layers.
| OCR | Template-based IDP | LLM-based extraction | |
|---|---|---|---|
| What it produces | Plain text from an image | Named fields from known layouts | Named fields from any layout, plus classification |
| How it finds a field | It does not: it only reads characters | Position, anchors and rules per template | Meaning of the content |
| New supplier layout | Not applicable | Needs a new template | Usually works without changes |
| Typical failure | Misread characters on poor scans | Breaks when the layout moves | Returns a plausible but wrong value |
| Best for | Making scans searchable | High volume of a few fixed forms | Many layouts, free text, contracts |
OCR (optical character recognition) converts images of text into machine-readable text. IBM notes that it needs preprocessing such as straightening skewed scans, and that it struggles with irregular fonts, low resolution and poor phone photos. OCR knows that a page contains “1.234,50”, not that it is the invoice total.
Template-based IDP adds rules on top of OCR: the total sits below the word “Total” in the bottom right. It is precise and cheap per page while the layout stays fixed.
LLM-based extraction, often sold as AI document processing, uses a language model, sometimes one that reads the image directly, to find each field by its meaning. It handles new layouts and long documents such as contracts. Its weak point is the opposite of templates: it rarely breaks loudly, but it can return a confident wrong answer. That is why validation and human review are part of the design, not an extra.
In practice, automated document processing today mixes the three: OCR for scans, templates or rules where a format is stable, and a model for everything else.
The IDP pipeline step by step
1. Capture
Documents arrive by email, upload portal, scanner, supplier portal or API. Capture must keep the original file, record its source and time, and detect duplicates (the same invoice sent twice is a common error). Image quality is decided here: a phone photo of a crumpled delivery note limits every step after it.
2. Classification
The system decides what each document is: invoice, credit note, delivery note, contract, ID document. It also splits multi-document PDFs, for example ten invoices scanned as one file. A wrong class sends the document to the wrong extraction schema, so classification needs its own confidence threshold.
3. Extraction
Each document type has a schema: the fields to extract, their format and which are mandatory. For an invoice that means supplier, tax ID, number, date, base, tax rates, total and line items. Line items and tables are where most errors appear.
4. Validation
Extracted data is checked against rules and against data you already hold:
- Arithmetic. Lines add up to the base, base plus tax equals the total.
- Master data. The supplier tax ID exists in the ERP; the bank account matches the one on file.
- Cross-document matching. The invoice matches the purchase order and the delivery note (three-way match).
- Format and range. Dates are plausible, the tax rate is one that applies.
Validation catches many model errors without a person looking at anything.
5. Human in the loop
Cases with low confidence or failed validation go to a review queue. The reviewer sees the document next to the extracted fields, corrects them and approves. Corrections are logged and become test data for the next version. Review must be meaningful: the reviewer needs time, context and the authority to reject.
6. Export to the ERP
Approved data is written to the target system through its API, with idempotency so a retry does not create a duplicate record. If there is no API, a file import or, as a last resort, an RPA bot. How to design these connections, retries and monitoring is covered in systems integration for ERP and CRM.
Typical documents and what makes them hard
| Document | Key data | Main difficulty |
|---|---|---|
| Supplier invoices | Supplier, tax ID, totals, taxes, lines | Many layouts, line items, credit notes |
| Delivery notes | Items, quantities, order reference | Handwritten notes, signatures, poor scans |
| Contracts | Parties, dates, amounts, renewal and termination clauses | Long text, clauses that refer to other clauses |
| Forms and applications | Applicant data, checkboxes, attachments | Handwriting, incomplete forms, personal data |
Invoices are often the first project because the volume is high and the result is easy to check. Note that structured e-invoices (XML) do not need IDP at all: you parse them. In Spain, upcoming e-invoicing obligations will move part of B2B invoicing to structured formats, as explained in our integration guide. Paper, PDF and non-structured invoices will still arrive from some suppliers.
IDP extracts fields so a system can store them. If the goal is to answer questions over a set of documents, that is RAG over company documents, a different architecture.
How to measure accuracy
A vendor’s “99% accuracy” says nothing until you know what was counted. Measure with your own documents:
- Build a ground-truth set. Take a few hundred real documents, spread across types and suppliers, and record the correct value of every field by hand.
- Measure per field, not per document. Field-level accuracy tells you where the errors are: the total may be right while line items are not.
- Measure document-level accuracy. The share of documents with every mandatory field correct. This is what decides whether a document can skip review.
- Track the straight-through rate. The share of documents that pass validation and confidence thresholds and reach the ERP with no human touch.
- Measure residual errors. Errors that still reach the ERP after validation and review. This is the number that costs money.
- Check confidence calibration. If the system reports high confidence, those cases should in fact be right. Sample them regularly.
Segment the results by document type and supplier. An average hides the one supplier whose invoices fail every time. Re-run the evaluation each time you change the model, prompts or rules.
Build or buy intelligent document processing software
| Option | Fits when | Watch out for |
|---|---|---|
| Off-the-shelf IDP software | Standard documents, standard ERP, a ready connector exists | Per-page pricing at your volume, limits on custom validation, where data is processed |
| Cloud document APIs (Amazon Textract, Google Document AI, Azure AI Document Intelligence) | You have a development team and want building blocks | You still build validation, review, export and monitoring |
| Custom pipeline | Your own document types, complex business rules, an in-house or vertical system as target | You own maintenance and evaluation |
What usually drives the cost of document processing automation: number of document types, number of layouts, line-item extraction, the validation rules, the review interface, how the target system is accessed, and per-page model or licence consumption. Ask for a quote based on your own document sample, not on a generic page count.
GDPR and the AI Act
Documents are full of personal data: names, tax IDs, signatures, bank accounts. Under GDPR Article 5, extract only the fields you need and set retention for the original files. If a cloud provider processes the documents, it acts as a processor and you need an Article 28 contract and to know where the data is processed.
Under the AI Act, document data extraction is usually minimal risk, unless its output decides about people, for example in credit or hiring. Our EU AI Act obligations guide covers the checklist by use case and the AI literacy duty.
Common mistakes
- Starting with the hardest document. Start with one type, high volume and an easy check.
- No ground truth. Without it, nobody can say whether a change improved anything.
- Trusting confidence scores blindly. Validate them against real results.
- Skipping the review interface. If reviewing is slow, the queue grows and people approve without looking.
- Leaving export for the end. The ERP connection often takes longer than the extraction.
What we have built at LCApps
At LCApps we build document data extraction: we process documents with AI, extract the information relevant to each case file and load it directly into that file, with human review where the data is critical. We design these projects in line with the GDPR and the EU AI Act.
Frequently asked questions
Is IDP the same as OCR?
No. OCR turns an image into text. IDP uses that text, or the image itself, to classify the document, extract named fields, validate them and send them to a system.
Can an LLM replace an IDP platform?
A model can do the extraction step. Capture, validation, review, export and monitoring are still needed, and they are most of the work.
How many documents do I need to start?
Enough to build a ground-truth set that covers your main document types and your largest suppliers. Start with one type and widen the set as you add more.
Conclusion
Intelligent document processing is a pipeline, not a model: capture, classification, extraction, validation, human review and export. Measure it on your own documents, field by field, and judge it by the errors that reach the ERP.
If you have a document flow that still depends on manual data entry, tell us which process you want to improve and we will help you scope a pilot.