Flowgrammer

Intelligent Document Processing

Learn how IDP classifies, extracts, validates and reviews documents, plus the requirements and test cases to compare platforms safely.

— Craig Major

Intelligent document processing classifies a file, extracts typed fields, runs deterministic checks, and routes low-confidence or high-consequence results to a person before a controlled handoff. OCR only turns pixels into characters. IDP is not RPA, not a document store, and not a chat that summarizes a PDF. A person still approves before a high-consequence or irreversible downstream action. On an invoice, that includes a financial write.

This guide covers the category: stages, boundaries, requirements, and how to read vendor capabilities. The paired IDP Requirements and Evaluation Worksheet is the editable scoring workbook. What to automate first stays on Document Processing Automation. For invoices, the intake-to-draft path stays on Invoice Processing Automation. The register that records intake, status, and approval stays on Invoice Tracker.

Who this is for

Use this when files already arrive and the question is whether a document-understanding layer is warranted: mixed types in one inbox, fields that must be typed and checked, and a person who must see exceptions before another system is updated.

Prerequisites:

  • One business process, one document family, one intake path, and one controlled destination or action for the first evaluation. The worked example is fictional Cedar & Quay Fabrication Ltd.
  • A named owner who can write required fields and review rules
  • A representative sample of real layouts you can replace with fictional or approved files
  • A destination that can accept a controlled, non-final handoff and, where it supports it, an idempotency key or equivalent lookup
  • Agreement that extraction is not a final record change and not a consequential decision. On an invoice, extraction is not posting and not payment.

Stay out of the first IDP project when the first action would be high-consequence or hard to undo: autonomous payment, supplier bank-detail changes, tax filings, final record changes, or other consequential decisions. Multi-entity matching is also a poor first slice.

If you still need to choose the first document family, start with the pillar. If invoices are already the first family, use the invoice-processing guide and the live Invoice Processing Test Pack. That pack uses five fictional labelled-text fixtures and does not measure OCR.

What intelligent document processing is

IDP is a document-understanding system. After a file is accepted, it typically:

  1. Classifies the document type and, when needed, the page ranges inside a packet
  2. Extracts fields, tables, and line items into a schema you own
  3. Validates required fields, arithmetic, lookups, and duplicates with rules you wrote
  4. Uses confidence scores and those rules to decide automatic accept, review, or reject
  5. Hands a reviewed payload to another system as a controlled, non-final handoff, with a retry key where the destination supports it

Microsoft's Document Intelligence docs describe prebuilt and custom models that classify and extract, then tell you to use field confidence and human review when accuracy is critical. Google Document AI documents the same split: a custom classifier identifies the type, a custom extractor returns entities with confidence 0-1, and evaluation metrics (precision, recall, F1) are computed against a labelled test set. Those are product mechanics. They are not a finished business process.

IDP does not become payment, legal advice, or a certified records program because a model returned JSON.

Common IDP jobs

The pipeline stays classify → extract → validate → human review → controlled handoff. The fields, risks, and final action change with the document family.

Job Typical fields Main risks Controlled handoff after review
Invoices and receipts Vendor, number, dates, line items, tax, total Duplicate bills, bad totals, payment or posting too early Intake/review record, then an accounting draft if configured. Payment stays separate.
Purchase orders and packing slips PO number, SKU, quantities, ship dates Quantity mismatch, wrong order, goods marked received too early Status or receiving record. Do not treat a packing slip as an invoice.
Forms and applications Applicant, identifiers, required answers, signatures Missing required fields, wrong type, premature acceptance Case or CRM record in a non-final state.
Contracts and correspondence Parties, dates, renewal, key clauses Missed obligation, unreviewed legal language treated as fact Matter or contract record with provenance. A person still reads high-consequence clauses.
Claims and case files Claimant, dates, amounts, attachments, status Mixed packets, unknown types, a decision issued from an unreviewed extract Case file update or exception queue. The extract is not the decision.

Cedar & Quay below is an invoice-and-packing-slip example of that same pipeline. Use it for the acceptance cases. Reuse the stages when the family is a form, contract, or claim.

OCR versus IDP

Optical character recognition converts image text into characters. Intelligent character recognition is the handwriting-oriented cousin. Both are read steps.

IDP uses a read step, then adds structure and control: type, fields, validation, confidence routing, human review, and a write policy. A high OCR word-confidence score does not prove the string is the invoice number, that the total is arithmetically consistent, or that the file is not a duplicate.

Job OCR / ICR IDP
Turn pixels into text Yes Usually includes a read model
Name the document type No Classification, with unknown-type handling
Return typed fields and tables No, unless you parse the text Extraction into a schema
Enforce required fields and math No Deterministic validation
Route by confidence Rarely, and only for glyphs Field or document confidence plus your thresholds
Keep a person on high-consequence values Not defined Review queue and always-review fields
Hand a reviewed payload to another system No Integrator-owned handoff after approval

OCR and IDP answer different jobs. Use this comparison when a read step is not enough and you also need type, fields, validation, and a review policy.

Document capture is the intake and imaging layer: scanners, email, and file validation. Capture without classification, extraction, and review is not IDP.

IDP versus RPA, document management, and chat

Approach What it does What it does not do
IDP Understands documents and prepares a reviewed payload Does not, by itself, click through another product or store the official record
RPA Automates UI or system steps Does not understand a new layout unless an IDP or parser sits in front
Document management system Stores, versions, and permissions files Does not extract, validate, or approve a destination write
Chat with documents Summarizes or answers from text Does not give you a schema, field confidence, an audit of who approved a value, or a safe write

Teams often combine them. RPA can move a file into IDP and later push an approved payload. A DMS can keep the source PDF. A chat tool can help a reviewer find a clause. None of those substitutions removes the human gate before a high-consequence or irreversible action. On an invoice, that includes a financial write.

Worked example

Cedar & Quay Fabrication Ltd is a fictional Toronto buyer. On 8 September 2026 its shared inbox holds four files:

  1. Ridgemont Industrial Supply Co invoice INV-TP-2401. Subtotal CAD 400.00, HST CAD 52.00, total CAD 452.00. Digital PDF.
  2. Ridgemont packing slip PS-RM-188 for the same shipment. Quantities only. No totals.
  3. Ashbridge Print Works credit note CN-AB-09. Document type the current invoice extractor was not trained on.
  4. A second copy of INV-TP-2401 plus a faded scan of Prairie Bolt & Fastener Ltd invoice INV-TP-2404, where subtotal plus tax is 220.50 and the printed total is 185.00.

Classification should label file 1 as invoice, file 2 as packing_slip, and file 3 as credit_note or unknown if that class was not trained. Extraction on file 1 should return vendor, invoice number, date, currency, line items, subtotal, tax, and total. Validation should accept 400.00 + 52.00 = 452.00 and send the row to pending_review. A person approves. The invoice tracker receives one intake and review record. If accounting is connected, that system receives one draft only after approval. posted_ref and paid_ref stay empty until a person confirms those later actions.

The second INV-TP-2401 is a duplicate on vendor plus invoice number. It does not go to a reviewer. The faded Prairie Bolt scan is held: either low read confidence, a conflicting total, or both. The credit note is not forced through the invoice schema.

The companies, people, and amounts are fictional. They are not customer results. The same invoice numbers appear in the Invoice Processing Test Pack. That pack is labelled text and does not measure OCR. Use it to prove validation, duplicates, and the human gate. Add scans before you claim read or extraction performance.

The IDP workflow

  1. Intake. Accept files from one agreed channel. Store the original, a hash of the bytes, and the source path or message id. Reject empty, locked, or unsupported files into a visible queue.
  2. Classify. Assign a document type and page ranges. If splitMode or an equivalent splitter is off, a packet is one document. Azure Document Intelligence v4.0 defaults splitMode to none and requires auto or perPage when one file holds several documents. Unknown types stop here.
  3. Extract. Fill your schema, not the vendor's field names. Keep the printed span next to any normalised value.
  4. Validate. Required fields, arithmetic, lookups, and duplicates. These rules live in your workflow even when the vendor has a rule engine.
  5. Score and route. Use model confidence to flag review. Do not treat a score as a business rule. Microsoft documents field confidence as an estimated probability between 0 and 1 and tells you to add human review for critical scenarios. Google documents a confidence threshold that changes precision and recall. Rossum states that its default 0.8 score_threshold does not equal the accuracy of fields that pass it. Nanonets suggests about 0.8 as a starting point and says you must calibrate per model.
  6. Review. A named person confirms type, fields, and exceptions. Always-review fields (bank details, totals, tax IDs, or other high-consequence values) ignore a high score.
  7. Handoff. After an explicit approve, write a controlled, non-final record only. Store the destination id against the intake record. If the response is lost, retry with the same idempotency key where the destination supports it.
  8. Monitor. Count classification misses, validation failures, review rate, correction rate, and failed writes. Do not convert those counts into a savings claim.

Microsoft's Power Platform invoice examples show the same shape in a different stack: extract, check confidence, optionally call a second model when a score is low, and still leave the write decision to the flow author. AI Builder's invoice model documents per-field confidence and a 20 MB file limit. That is not an approval product for a final action.

Requirements process

Write the job before you open a vendor trial.

  1. Name the start and end events. Example: file lands in the agreed inbox; a reviewed intake record exists; a non-final destination write happens only after approval. Final actions stay out of scope.
  2. List document types, languages, and channels. Mark structured, semi-structured, and unstructured.
  3. List fields. Required versus optional. Extracted versus derived. Line items yes or no.
  4. Write deterministic rules: required fields, arithmetic where amounts exist, lookups, and a duplicate key.
  5. Write the confidence policy: per-field thresholds left blank until you measure; always-review list; sampling rate for auto-accepted documents.
  6. Write human-review rules: who, SLA, escalation, and what the reviewer may change.
  7. Write destination rules: non-final versus final action; idempotency or deduplication; attachment retention.
  8. Build a representative corpus. If invoices are in scope, start with the labelled-text invoice fixtures. Add scans and the other types before any OCR claim.
  9. List security and residency requirements as questions the vendor must answer with a current page, not as assumptions.
  10. Score vendors only with cited evidence or a dated test you ran. A hard disqualifier of Yes beats a high score. Unknown or blank disqualifier answers leave the vendor Incomplete.

The paired IDP Requirements and Evaluation Worksheet holds those tabs, fictional sample rows, blank working rows, and reproducible scoring.

What can run automatically, and what cannot

Situation Automatic action Person required
Supported file arrives Store original and hash Confirm the channel if intake is messy
Known type, high classification confidence Attach the type and continue Yes, if type is unknown or below your threshold
Required fields present and checks pass Move to pending_review Yes, before any destination write
Low confidence on a high-consequence field Hold in review Yes. Do not auto-accept
Duplicate identity key already exists Status duplicate Only if a written override policy exists
Unknown type on a single-family schema Quarantine Yes. Do not invent a mapping
Reviewer approves Status approved The approve decision itself
Controlled destination write created Record destination id after the write is confirmed Yes. IDP does not execute the final action
Lost destination response Retry the same idempotency key Confirm that only one destination write exists

Human gates

A person keeps these decisions:

  • Whether an unknown or low-confidence type may continue
  • Whether a missing field, conflicting value, or low-confidence high-consequence field may be overridden
  • Approve, reject, or hold
  • Whether a duplicate may proceed under a written policy
  • Whether a destination write may be retried or abandoned
  • Whether a later final action, such as posted or paid on an invoice, may be recorded after an external confirmation

The system must not treat a confidence score as approval. It must not execute a high-consequence final action: creating a posted vendor bill, releasing a payment, changing supplier bank details, or issuing a binding case decision.

ABBYY Vantage documents a Manual Review Client after classification and extraction, with optional multi-stage review. Rossum documents three queue automation levels (none, confidence, full) and will not export a document that still has validation errors. Nanonets documents approval stages that can flag on confidence or field rules before export. Those are review products. They do not remove your always-review list.

Failure paths

Failure Expected status Next action
Empty, locked, or unsupported file unreadable Recover the source. Do not invent pages
Type not in the trained classes unknown_type Add an other class or a threshold. Azure classifier docs recommend both when unseen types will arrive
Required field missing exception Collect the field. Do not approve
Arithmetic or consistency check fails exception Check the source. Override only with a named decision
Same identity key already exists duplicate Stop. Do not create a second approval
Low confidence on an always-review field pending_review Person inspects the source span
Destination write times out write_failed Retry the same key. Do not mint a new key
Retry uses a new key Invalid Treat as a duplicate-write defect
Export attempted with validation errors Blocked Rossum documents this as a hard stop even in full automation. Copy the rule even if you use another vendor
Extraction treated as a final action Prohibited Stop. Payment, posting, or another consequential decision is a separate system

Acceptance criteria and test cases

A first IDP slice is acceptable when these cases pass on a version-pinned model or API. Record the version. Do not publish an accuracy rate from a demo.

Case Input Expected result
Clean digital invoice INV-TP-2401, CAD 452.00, all required fields Type invoice. Validation passes. Status pending_review. No destination write until approve. After approve, one tracker intake record. One accounting draft only if that destination is configured.
Packing slip in the same mailbox PS-RM-188 Type packing_slip. Invoice schema is not applied. Quantities may extract. Totals stay empty.
Unknown or untrained type Credit note CN-AB-09 unknown_type or credit_note. Not forced through the invoice extractor.
Duplicate Second file with Ridgemont and INV-TP-2401 duplicate. First row unchanged.
Conflicting total INV-TP-2404, printed 185.00 versus 220.50 exception / conflicting_total
Low-confidence faded scan Same Prairie Bolt layout as a scan Held for review. No auto-accept. Not an OCR accuracy claim until you measure scans.
Destination timeout Approved INV-TP-2401, lost response Retry with the same idempotency key. At most one destination write.
Write without approval Any destination call while approval_decision is empty Rejected.

The Invoice Processing Test Pack already covers the clean invoice, duplicate, missing invoice number, conflicting total, and destination-timeout cases as labelled text. It does not measure OCR. Seed an invoice corpus with those five fixtures, then add classified non-invoice files and scans before you compare read engines.

The Invoice Tracker Starter Pack records intake, status, and approval and can store a reference to a downstream draft. The accounting draft, if you create one, lives in the accounting system. IDP does not replace the tracker.

Implementation order and limits

  1. Write the job, fields, and acceptance table.
  2. Stand up validation and duplicate rules against labelled fixtures. These rules should pass with no vendor account.
  3. Add classification and extraction for one document family.
  4. Calibrate confidence on your files. Leave thresholds blank until you have a distribution.
  5. Connect one controlled, non-final destination handoff. Use an idempotency key or equivalent deduplication where the destination supports it.
  6. Measure review rate and corrections for two weeks before adding a second document type.

Start with simple rules or a manual workflow when volume is low, the layout is one stable template you can parse with rules, or the bottleneck is approval ownership rather than extraction. An invoice tracker is one example of that simpler register.

Limits that stay true regardless of vendor:

  • Flowgrammer has not published a live accuracy number for Azure Document Intelligence, AI Builder, Google Document AI, AWS Textract, ABBYY Vantage, Rossum, Nanonets, or Docsumo. Local Azure sample work covered schema and confidence-merge helpers only.
  • Destination writes are the integrator's job. Vendor APIs return analysis results.
  • Payment and other final actions are separate system capabilities. IDP prepares a reviewed payload; it does not execute payment or make a consequential decision by itself.
  • Canadian data residency is not assumed. Some Google Document AI classifier release-candidate versions document that they do not support data residency. Confirm the current page for the exact processor version before you promise a region.

Platform capabilities, not a ranking

The table records official capabilities as of 8 September 2026. It is a capability inventory, not a scorecard and not a recommendation.

Platform Classification Extraction Validation Confidence Human review Handoff Documented limits to respect
Azure AI Document Intelligence Custom classifier; page ranges; splitMode Prebuilt plus custom neural, template, and composed models; layout/read Confidence concepts in-product; business rules in your app Field confidence 0-1 Recommended for critical cases; native HITL is workflow-side REST/SDKs to the caller Custom classifier needs at least two classes and five samples per class. v4.0 splitMode default is none. Paid analyze size up to 500 MB.
Microsoft AI Builder Document-type selection and custom document-processing models Document processing models; prebuilt invoice fields Conditions in Power Automate using confidence Per-field and table-cell scores in flow outputs Example flows route low scores to a second model or a person Power Automate actions Invoice files JPEG/PNG/PDF, 20 MB. 360 document-processing calls per environment per 60 seconds. Do not collapse AI Builder with Document Intelligence or Syntex.
Google Cloud Document AI Custom classification processor (CUSTOM_CLASSIFICATION_PROCESSOR) Custom extractor and pretrained processors; entities with confidence Evaluation thresholds; business rules usually external Entity confidence 0-1; evaluation uses a confidence threshold Docs describe triggering manual review on low confidence API to the caller Evaluation reports precision, recall, and F1 against a labelled test set. Some classifier release-candidate versions do not support data residency.
AWS Textract Not a dedicated document-type classifier; forms, tables, queries, and layout AnalyzeDocument and AnalyzeExpense (invoices/receipts) Application layer Confidence on blocks and expense fields HumanLoopConfig uses Amazon A2I API, sync or async A2I entered maintenance mode in July 2026 and does not accept new customers. Sync documents max 10 MB; async PDFs max 500 MB. JPEG, PNG, PDF, or TIFF.
ABBYY Vantage Classify activity; review can change type Extract activity / Document skills Rule errors can force review Uncertain fields drive review modes Manual Review Client; multi-stage API, connectors, folders, email Manual Review is a runtime client plus a process activity. Vantage is not FineReader.
Rossum Queue and schema oriented AI extraction to schema fields Schema constraints and connectors; validation_sources rir_confidence 0-1; default threshold 0.8 Validation UI; automation never / confident / always Export on queue; webhooks Documents with validation errors are not exported, including in full automation. Hidden fields are not validated.
Nanonets Model and workflow oriented Field predictions with bounding boxes Workflow rules including confidence flags score 0-1 per prediction Review stages; approve before export Export after approval; API Docs recommend about 0.8 as a starting threshold and say you must calibrate. Confidence availability has differed by model type.
Docsumo Document type on upload Key-values and tables via platform/API Review and approve gates Product HITL pages describe low-confidence flagging; confirm score fields in the API before you depend on them HITL review screen; review status APIs REST API and webhooks Treat marketing pages as product description, not an accuracy benchmark.

Flowgrammer has not run a paid live accuracy test against any row in this table.

What to measure, and what cost includes

Count files received, classification misses, validation failures, documents sent to review, corrections, duplicate stops, failed writes, and median hours from intake to approve.

Do not convert those counts into a savings percentage. The Automation ROI Calculator is a planning worksheet. Replace its illustration with your observed numbers.

No live production metric is reported here, and no unit prices are listed. When you cost a trial, collect current quotes in these categories only: per-page or per-document processing, AI credits or SKUs, seats, human-review labour, implementation, maintenance, storage, and egress. Re-read the vendor's official pricing page on the day you fill the cell.

How to use the worksheet

Download the IDP Requirements and Evaluation Worksheet. The paired workbook is a requirements and evaluation kit: workflow job, corpus plan, document types, fields, validation rules, confidence policy, human-review rules, duplicates, exceptions, destination and idempotency rules, security questions, vendor evidence, weighted scoring, hard disqualifiers, proof gates, a test-result log, and a decision record.

  1. Copy the fictional Cedar & Quay rows or clear them and use your own approved samples.
  2. Fill required fields and always-review fields before you score a vendor.
  3. Leave unit prices and residency answers blank until you paste a current official source and the access date.
  4. Enter a score only when the evidence cell has a URL or a dated Flowgrammer test. The workbook treats a score without evidence as invalid.
  5. If any hard disqualifier is Yes, the vendor is Disqualified. If any required disqualifier is Unknown or blank, or scoring or evidence is incomplete, the vendor is Incomplete. There is no winner badge.

The worksheet is not a live Google Sheet and it is not an extraction engine.

Next step

If one document family, one intake path, and one destination are already clear, stay on the matching spoke until those cases pass. For invoices, that is the invoice-processing guide and the tracker.

If several document types, unclear scope, or a vendor shortlist is the blocker, use the AI Success Audit. That is the existing audit with a document-workflow focus. Bring the field list, the exception codes, and a redacted sample of files.

Already know the workflow and need it built? Scope an AI Automation System after the audit, not instead of writing the acceptance table.

Sources

Frequently asked questions

What is intelligent document processing (IDP)?

A system that classifies documents, extracts typed fields, validates them, routes by confidence and rules, keeps a person on exceptions, and hands a reviewed payload to another system. It is more than OCR.

How is IDP different from OCR?

OCR converts image text to characters. IDP uses that read step, then adds type, schema, validation, review, and a write policy.

How is IDP different from RPA?

RPA automates steps in other systems. IDP understands documents. They often sit in one workflow. Neither makes a high-consequence final decision by default.

How is IDP different from a document management system?

A DMS stores and permissions files. IDP extracts and validates data so work can move. You usually keep both.

How is IDP different from chatting with a PDF?

Chat can summarize. IDP returns fields, confidence, an auditable review, and a controlled handoff. A fluent answer is not an approved record.

What is intelligent character recognition (ICR)?

Handwriting-oriented recognition in the OCR family. It is not a synonym for IDP.

What stages are in an IDP workflow?

Intake, classify, extract, validate, review as needed, destination write, and monitor.

What is a confidence score in document AI?

A model-estimated probability that a prediction is correct. Platform scales vary. Use it to route review. Do not use it as the only business rule.

When should a human review a document?

Low confidence, high-consequence fields, validation failures, unknown types, or a sampling policy on auto-accepted files.

Can IDP post invoices to accounting automatically?

Extraction and a non-final draft are not posting and not payment. Destination writes need an explicit human policy.

How should we evaluate an IDP platform?

Shared corpus, field-level metrics, review behaviour, security answers, integrations, and cost categories. Score only with cited evidence. Do not treat this guide as a ranked shortlist.

When is IDP excessive?

Low volume, one stable template, or when the bottleneck is process ownership rather than extraction. Simple rules or a manual register can be enough. An invoice tracker is one example.