Intelligent document processing, or IDP, uses software and AI to identify documents, extract information and check it against the requirements of a business process. Its output might be a structured record, an exception for a person to resolve or a proposed update to another system.
Reading a page is one part of that job. A delivery note can be perfectly legible while disagreeing with a purchase order. An invoice can contain the right total for the wrong supplier. The operational question is whether the information is sufficient, consistent and authorized for the action that follows.
To understand how IDP works, follow a shipment through a distributor's receiving process. The purchase order, delivery note and inspection record each describe a different part of the same event. The system needs to preserve those differences while helping someone reach a clear disposition.
What changes when document reading becomes document processing?
Optical character recognition, or OCR, recognizes text in an image or scanned page. Extraction assigns information to fields, such as an order number, quantity or delivery date. Classification identifies the kind of document being handled. Validation checks the extracted information against required formats, other records and business rules.
These functions can work together. A scanned delivery note may need OCR before its quantities can be extracted. A document with a usable text layer may not need that same recognition step. A model that understands page layout can help associate a value with its label or table row, but a plausible association still needs checking.
AWS's intelligent document processing guidance shows an architecture with document extraction, classification, validation and human review for unresolved cases. The important distinction is between obtaining information from a document and deciding how that information should affect the business.
A search assistant might retrieve a passage from the delivery note. An IDP workflow must also determine which delivery it describes, whether a newer revision exists and whether its quantities can be reconciled. Different jobs require different completion criteria.
This makes IDP useful for invoice handling, procurement, supplier onboarding, claims intake, technical document review and many other processes. The right design depends on the documents involved and the consequence of using a wrong field.
A shipment with three different quantities
Suppose a distributor orders 24 crates of a component, with ten units in each crate. The delivery note records 22 crates arriving. The inspection record places two of those delivered crates on hold because of visible damage. Assume the warehouse confirms those physical counts.
The packet now contains three meaningful quantities: 240 units ordered, 220 delivered and 200 available after the inspection hold. Extracting 240 from the purchase order is accurate. Using it as the available inventory would be wrong.
| Record | Information it establishes in this example | Quantity in units |
|---|---|---|
| Purchase order | What the distributor requested | 240 ordered |
| Delivery note | What the carrier reports as delivered | 220 delivered |
| Inspection record | Which delivered goods are held | 20 on hold |
| Reviewed receiving decision | What can enter available stock | 200 available |
The missing 20 units and the held 20 units are different exceptions. One concerns a short delivery. The other concerns goods that arrived but are not yet available. Combining them into “40 missing” would lose information that purchasing and warehouse staff need for different actions.
Even this simple packet raises practical questions. Does the inspection refer to the same shipment? Does “two” mean crates or individual units? Was there a partial delivery notice? Does a corrected document supersede the first delivery note? A model should be able to identify those questions without inventing the answers.
Follow the packet from arrival to disposition
Establish which documents belong together
Give each received file an identity and preserve its original content. Record when it arrived, where it came from and which business record it appears to concern. If the same file arrives twice, recognizing it as a duplicate should not discard evidence of the second receipt.
Matching needs more than similar filenames. Check order references, supplier identity, shipment references and relevant dates. A packet may contain several orders or several deliveries against one order. Uncertain matches should remain uncertain until the necessary evidence is available.
Version handling belongs here too. A later arrival is not automatically a correction. A revised delivery note should have a clear relationship to the earlier version, with the reason for accepting the replacement retained. Keep the superseded evidence accessible to the people who need to understand the change.
Extract a value with its location and meaning
For a quantity, retain the original text, the normalized number, its unit and the document location. “22 crates” should not become an unexplained integer. Store the ten units per crate as a separate conversion assumption grounded in the order or an approved product record.
Preserve table structure when it matters. A quantity attached to the wrong product row can look sensible in isolation. Repeated headers, footnotes and totals can also be mistaken for line items. Review several extracted rows against the page before trusting a batch.
Missing information should remain missing. If the delivery note has no inspection status, the processor should not infer that all goods passed inspection. If the scan is unreadable, request a better copy or route it for review. Completing a field with a guess makes downstream processing look more certain than it is.
Reconcile what the records say
Apply explicit checks to the structured data. In the example, delivered crates cannot be counted as available stock while they are on hold. The order, delivery and inspection must refer to compatible products and units before their quantities can be compared.
Separate a failure to read from a business disagreement. An unreadable crate count needs better evidence. A clear count of 22 against an order for 24 needs a short delivery decision. Asking the model to extract the page again will not resolve the second problem.
An exception should name what is blocking progress, identify the responsible person and show the evidence needed to resolve it. “Quantity mismatch” is a start. “Two ordered crates are not recorded as delivered; purchasing must confirm whether a second shipment is expected” gives someone a useful next action.
Design the review screen around the disagreement
A person reviewing the shipment should see the relevant source locations beside the extracted values and conversion rules. They need to understand what the processor found, what failed validation and what accepting the proposal would do.
Recognition confidence can help prioritize that review, but it does not establish that a business record is correct. A clearly printed wrong order number may have high recognition confidence. A correctly read delivery note may still conflict with a warehouse count.
Amazon Textract's best practices recommend considering confidence alongside the sensitivity of the use case. Choose review thresholds using representative documents and the consequences of errors. Do not assume that one threshold is suitable for every field or action.
For this shipment, the reviewer might confirm 220 delivered units and retain 20 on hold. Purchasing separately investigates the short delivery. The decision should record the accepted quantities, the evidence used, the unresolved exception and who authorized the next step.
Reviewer corrections are valuable evidence for improving extraction or validation. They do not automatically establish that a model has learned a new rule. Evaluate any proposed change against additional documents before applying it broadly.
This is also where the action boundary becomes important. Approving the interpretation of a document and authorizing an inventory update are distinct decisions. The guide to human participation in AI workflows explains how to give reviewers a clear proposal and a meaningful approval boundary.
Test the packet, then test the business outcome
Begin with representative packets whose expected outcomes have been reviewed by people who understand the process. Include familiar layouts alongside poor scans, corrected documents, mixed units, missing pages, duplicate arrivals and genuine business disagreements.
Evaluate field extraction separately from reconciliation. A processor might read every quantity correctly but select the wrong inventory outcome. It might also reach the right total accidentally by making two offsetting mistakes. A single overall accuracy score would conceal both problems.
Useful measures include correctness of critical fields, the proportion of packets requiring review, errors that incorrectly pass without review, reviewer effort and the correctness of confirmed downstream updates. Report performance by document type and supplier layout so a common easy case does not hide a difficult one.
For the receiving example, test these outcomes explicitly: short delivery remains distinguishable from inspection hold; units are converted once; a missing inspection result blocks release; and a duplicate packet does not create another stock receipt.
External updates need their own reliability checks. If an inventory service times out, the processor should establish whether the receipt was accepted before retrying. Keep a stable reference for the intended receipt and use the destination's duplicate prevention facilities where available. Record the confirmed external result separately from the proposed update.
Choose the smallest useful deployment
A single stable form may be well served by conventional extraction rules. Variable documents with similar business meanings may benefit from layout models or language models. Complex packets may need a combination of extraction software, deterministic checks and human review.
Compare approaches on your own document set. Consider whether source locations are available, how revisions are handled, what happens when a field is absent and whether the system can leave a case unresolved. Include processing cost, reviewer time, latency and access requirements in the comparison.
Keep document access narrow. A person authorized to resolve a delivery exception may not need every supplier contract. An agent that extracts fields may not need permission to update inventory. Define retention for originals, intermediate outputs and review records according to the organization's requirements.
Swarm can provide a shared place for the investigation around a packet. In a Space, a team can keep permitted document references, extraction results, unresolved questions, Tasks and human decisions together. A connected agent can use approved document processing tools, then contribute an Artifact with the values and supporting evidence for review.
For a recurring supplier discrepancy, warehouse and purchasing staff can continue the same discussion while agents contribute new findings from their permitted sources. The receiving decision remains attached to the work that produced it. The connection guide describes how agents gain access to selected Spaces.
Choose an initial scope that ends with a verifiable outcome, such as preparing a reviewed receiving proposal for one supplier's shipments. Observe where reviewers actually spend time before expanding automation. The strongest improvement may come from making exceptions clear and easy to resolve, even before more packets can proceed without review.
IDP becomes valuable when information moves from a page into a business process without losing its meaning. In the shipment example, success is knowing which goods are available, which remain held and which never arrived, with enough evidence for the next person to act confidently.