- Intelligent document processing, or IDP, reads documents, pulls out the details, checks them and sends them where they belong.
- Modern AI reads layouts it has never seen. Older tools needed a template for each one.
- Accuracy depends on your documents. Test on your own samples, measured field by field.
- People still review low-confidence fields and anything with consequences.
- Off-the-shelf tools fit common documents. Custom work fits unusual documents, strict rules or several systems downstream.
What it means, in plain words
Somewhere in your company, a person opens a PDF, reads it and types what it says into another system. Orders. Invoices. Packing slips. Applications. Certificates. Lab results. Contracts.
Intelligent document processing is software that does that reading and typing. It takes a document in, figures out what kind it is, pulls out the details you care about, checks them and passes them on.
That's it. The "intelligent" part just means it handles variety. A good system reads an order from a customer it has never seen before, in a layout nobody set up.
Our guide to automating document intake walks through the full intake process step by step. This guide focuses on the reading itself: how it works now, how to judge it and when to buy rather than build.
What changed with modern AI
Ten years ago, document automation meant templates. Someone defined where each field sat on each layout. "The PO number is in the top right, 40 pixels from the edge." It worked well for a few high-volume layouts and badly for everything else.
Then came trained models. You labelled a few hundred examples of a document type and the model learned to find the fields. Better, but every new document type meant a new training project.
Current AI models read documents more like a person does. They understand that "Ship to" and "Deliver to" mean the same thing. They read tables that span pages. They handle a photo taken at an angle. Many can be told what to extract in plain language, with no training set at all.
That shift changes the economics. The long tail of documents, the ones that only arrive a few times a month, used to be left for people. Now it can often be automated too.
It doesn't change the need for checking. AI models can read a number wrong with complete confidence. They can also fill in a field that isn't on the page. Every serious IDP setup still has validation and review.
The document types that matter
Documents fall roughly into three groups, and each behaves differently.
- Structured forms. Same layout every time: your own intake form, a government form, a standard certificate. These read reliably with almost any tool.
- Semi-structured documents. Same information, different layouts: invoices, purchase orders, bills of lading, packing slips. This is where modern AI shines most.
- Unstructured documents. Free text: contracts, letters, emails, reports. The task here is usually finding specific facts or summarizing, not filling fixed fields.
Most operations teams deal with all three. A useful system handles the mix and knows which kind it's looking at.
Then there are the awkward cases. Handwriting. Faxes. Multi-page scans with documents stapled together. Stamps over the important number. Ask any vendor how they handle these, and test them yourself.
How to measure accuracy
Every vendor quotes an accuracy figure. Treat it as marketing until you've tested on your own documents.
Here's a simple, honest test:
- Gather a few hundred real documents from recent months. Include the bad ones on purpose.
- Have your team record the correct values for each field you care about.
- Run the documents through the tool and compare, field by field.
- Look at the errors, not just the rate. A wrong date is annoying. A wrong quantity on a shipment is expensive.
Three numbers tell you most of what you need. Field accuracy, for the fields that matter. Straight-through rate, meaning documents that needed no human touch. And how well the confidence scores line up with real errors.
That last one is easy to skip and important. If the system says it's 95 percent sure, it should be right about that often. If high-confidence fields are frequently wrong, you can't use confidence to decide what skips review.
Where people review
Review isn't a sign the system failed. It's how you get reliable results from a system that is usually right.
The common pattern looks like this. Fields above a confidence threshold, that also pass your checks, go straight through. Everything else goes to a person, who sees the document and the extracted value side by side and fixes what's wrong.
Checks do as much work as the AI. Does the order total equal the sum of the lines? Does this customer exist? Is the delivery date in the future? Is this a duplicate of something already received? Each rule catches errors no confidence score will.
Amazon, Google and Microsoft all build human review into their document services for this reason. Our guide to designing human review for AI work goes deeper on review screens and how to stop reviewers rubber-stamping.
What a day looks like after launch
Picture a customer service team at a distributor. Orders arrive by email all day, as PDFs, spreadsheets and the odd photo of a handwritten list.
Before, two people spent their mornings keying orders. After, the system reads each one as it lands. It matches the customer, checks each item against the catalog and confirms prices against the customer's agreement. Clean orders go straight into the order system.
The rest arrive in a review queue. One order has an item code the system can't find. Another has a price that doesn't match the agreement. A third came from an address nobody recognizes. Each sits next to the original document, with the problem highlighted.
The two people still work on orders. They just spend their time on the ones that need judgment, and they call customers about real problems instead of typing.
Off-the-shelf IDP or custom
There's a healthy market of IDP products. Some are general. Some specialize in invoices, freight documents, healthcare forms or legal files. The big cloud providers also offer document reading services that developers build on.
An off-the-shelf tool fits when:
- Your documents are common types the tool already knows.
- The tool connects to the system the data needs to land in.
- Its review screen works for your team.
- Your rules are simple enough to set up in its settings.
Custom work fits when:
- Your documents are unusual, or mixed together in one email.
- The checks depend on your own data, like open orders, approved customers or contract terms.
- The results need to land in more than one system.
- The review step needs to fit into a screen your team already uses.
A custom build usually still uses a cloud provider's reading service or a general AI model underneath. What you're building is everything around it: the checks, the routing, the review and the connection to your systems. Our document processing page shows what that can include.
Data, privacy and where documents go
Documents carry sensitive details. Customer addresses, pricing, signatures, sometimes health or employee information. Before any tool reads them, know where they travel.
Ask where documents are processed and stored, and for how long. Ask if the provider uses your documents to improve its models, and how to switch that off if so. The major cloud providers publish this in their terms. Smaller vendors should be able to answer just as clearly.
Keep access narrow on your side too. Reviewers need to see the documents they review, not the whole archive. Keep a record of who viewed and changed what.
For regulated work, involve your compliance lead early. They'll know which rules apply and what records they'll want to see.
Questions to ask any IDP vendor
- Can we test on our own documents before we sign, and see the results field by field?
- How do confidence scores work, and can we set our own thresholds per field?
- What does the review screen look like, and can our team use it without training?
- How does it handle documents bundled together in one file or one email?
- Where does our data go, how long is it kept and is it used to train anything?
- How do results reach our systems, and what happens when that connection fails?
Good vendors answer these easily. Vague answers on testing or data use are worth noticing.
What most guides miss
Classification comes first. Before you can extract fields, you need to know what you're looking at. A single email might hold an order, a revised order and a certificate. Splitting and sorting them correctly is often harder than reading them.
The source matters more than the model. If customers can send orders in a structured way, some will. A simple order form or a portal removes documents from the pile entirely. The best document is the one you never have to read.
Accuracy drifts. A big customer changes its order layout. A vendor switches systems. Reading quality on that one source drops overnight. Track accuracy by source so you notice in days, not months.
Keep the original. Store every document next to what was extracted from it and who changed what. When a customer disputes an order three months later, you'll want both.
How we do it
We start with a free intro call and a sample of your real documents. Then we work alongside your team to test reading quality on those samples before anything is built, and design the checks and review around how your people already work. We stay on after launch to watch accuracy by source. Start with an intro call.
