Intelligent document processing (IDP) is software that turns business documents into checked data. IDP software works out what kind of document it has, pulls named fields such as the invoice number and total, scores its confidence in each field, checks the values against your own records, and sends the doubtful fields to a person.
Many pitches skip that last step. Below: each stage in the vendors' words, OCR vs IDP, a worked example, the main services, and what to measure.
- IDP classifies a document, reads named fields with a confidence score each, checks them against your records and sends doubtful fields to a person.
- OCR is one step inside IDP. It turns an image into text but can't tell which number is the invoice total.
- IDP doesn't remove people. Microsoft's and AWS's docs both plan for human review, and the review queue is now usually yours to build.
- Measure the straight-through rate per document type, and define it before the first document goes through.
What does intelligent document processing do?
Five things, in order. The IDP service does the first three. The last two are rules and queues you build around it.
| Stage | What happens | What the vendor docs say |
|---|---|---|
| Classify | Decide what the document is: invoice, bank statement, loan application | Azure's custom classifiers "identify designated document types (classes) before invoking an extraction model" |
| Read fields | Pull named, typed values, not just text | Microsoft's prebuilt invoice model returns InvoiceDate as a date and SubTotal as currency |
| Score | Attach a confidence to each value | Azure scores from 0 to 1; Textract from 0 to 100 |
| Validate | Check values against your own records | Yours to write: vendor master, open purchase orders, duplicates |
| Route | Send low-confidence or failed fields to a person | Yours to build |
Vendors print different labels for the same thing. AWS says Textract "maps relationships between field names in different documents such as bill number, invoice number, receipt number," returning one standard field.
Validation is yours. No IDP service knows which purchase orders are open, and a value read correctly from the wrong invoice is still wrong. If those records sit in systems that don't share data, start with connecting disconnected business systems.
Why IDP doesn't remove people
The common belief is that IDP takes people out of document work. The vendors don't claim that.
- Microsoft's page on confidence scores says: "For scenarios where accuracy is critical, confidence can be used to determine whether to automatically accept the prediction or flag it for human review."
- AWS's Amazon A2I guide says: "Many ML applications require humans to review low-confidence predictions to ensure the results are correct."
What has changed is who runs the review queue. Google's Document AI deprecations page lists Human in the Loop (HITL) as deprecated on January 16, 2024, and the A2I guide now opens with: "Amazon SageMaker A2I is no longer open to new customers." Plan to build the review step yourself. Our post on AI workflow automation covers where people sit in a workflow.
OCR vs IDP: what's the difference?
OCR turns pixels into words, with their positions on the page. IDP adds what the words mean.
| OCR | IDP | |
|---|---|---|
| Output | Words and lines, with positions | Named, typed fields, such as an invoice date |
| Document type | Not identified | Classified first |
| Confidence | Per word or line | Per field, on top of the reading confidence |
| Your records | Not checked | Checked by rules you configure |
| Doubtful values | Not flagged | Routed to a person by threshold |
OCR still runs underneath, and in Azure the two layers carry separate scores. Microsoft warns that "The confidence of the read results doesn't affect the confidence of the key/value extraction results, so you should check both."
A worked example: one invoice through IDP
Illustrative only. Scores are on Azure's 0 to 1 scale. Textract uses 0 to 100, so a threshold written for one service doesn't carry over. Thresholds are set per field: a misread phone number costs less than a misread bank account.
| Field | Value read | Confidence | Check against your records | Result |
|---|---|---|---|---|
| Document type | Invoice | 0.99 | None needed | Accept |
| Vendor name | Example Supply Co. | 0.97 | Matches an active vendor | Accept |
| Invoice number | 20417 | 0.98 | Not already in the payables ledger | Accept |
| PO number | 5531 | 0.94 | Open, same vendor | Accept |
| Total | 4,812.50 | 0.96 | Doesn't match PO lines plus tax | Review: validation failed |
| Remit-to account | Ending 0912 | 0.82 | Differs from the account on file | Review: always |
Two fields go to a person, for different reasons. The total scored well and still failed the purchase order match. The bank account goes to review at any score, because changing payment details is a decision, not a reading task. Everything else posts untouched.
A loan application follows the same shape. Azure's prebuilt US mortgage 1003 model is described as "Extract loan application details," and the checks run against your loan origination system instead.
Intelligent document processing solutions: the main cloud services
The three large cloud providers' document data extraction tools, in their own words:
| Service | What it reads | Worth knowing |
|---|---|---|
| Azure Document Intelligence | Prebuilt models for invoices, receipts, bank statements, checks and pay stubs; custom models and classifiers | "Currently, not all document fields return a confidence score." API v2.1 retires September 15, 2027 |
| Amazon Textract | AnalyzeDocument for forms, tables and queries; AnalyzeExpense for invoices and receipts; Analyze Lending for mortgage packages | Each result block carries a confidence from 0 to 100 |
| Google Cloud Document AI | Processors including an Invoice Parser, Bank Statement Parser, Custom Classifier and Custom Splitter | Human in the Loop deprecated January 16, 2024 |
Checked 30 October 2026 against each vendor's documentation. Whichever you test, run your own worst scans through it.
What to measure: the straight-through rate, defined
The straight-through rate is the share of documents that go from arrival to posting with no person touching any field. Define it per document type and count documents, not fields. We don't quote a typical rate: it depends on your documents, thresholds and rules.
Track three more beside it:
- Correction rate. How often reviewers change a value. A field they almost never change may have too cautious a threshold.
- Errors after posting, from a sample of accepted documents. This tells you whether straight-through is safe.
- Time in the review queue.
Our guide to automating data entry covers the review screen and measurement in practice, and where business process automation starts helps pick the first document process.
Before you buy an IDP service: the 30-day assessment
An IDP service is one component. The choices around it decide whether it works. The 30-day assessment is fixed in scope, at a price agreed before work starts. Before anyone proposes a build, we spend 30 days inside your systems and document process, with read-only access, under an NDA.
Week 1: we agree the scope, with a go or no-go decision before any access is given. Week 2: NDA, read-only access, and we trace how documents arrive, where the data goes and what depends on it. Week 3: senior engineers verify the findings with your team and capture the unwritten checks. Week 4: written findings and a readout to the decision makers.
The findings cover where the process stands, the practical options (including doing less than planned, or nothing), which IDP and automation tools fit your stack and which would be hype for your case, where handoffs and approvals slow the work whatever the technology, and a phased roadmap with durations. You keep them. Your team can build from them, or we build it as a separate project with its own scope and price, as on our data entry automation page. The findings stand on their own either way.
Book a scoping call and bring two or three sample documents with personal data removed. If a narrower check would answer your question, such as one document type tested against one service, we'll say so.