What intelligent document processing is, in plain English

IDP in one paragraph

Think about what your order desk does with a customer PO. Someone opens the email, opens the PDF, finds the PO number, ship-to address, part numbers, quantities, prices and dates, and types them into the ERP. Intelligent document processing does the reading and pulling-out part. It takes the document in, finds each field, and turns it into clean data your system can accept. Microsoft describes its own service, Azure Document Intelligence, as a cloud service you can use to build intelligent document processing solutions. Google describes Document AI as a platform that takes unstructured data from documents and turns it into structured fields that fit in a database. Same idea, different vendors.

That's all IDP is. It isn't a robot that runs your order desk. It's the part that reads.

How it's different from OCR and templates

People mix up three different things, so it helps to separate them.

• OCR (optical character recognition) turns a picture of text into text. As TechTarget puts it, OCR uses character matching to make a document machine-readable. It gives you the words, but it doesn't know which number is the quantity and which is the price.
• Template capture adds a map: "the PO number is in this box, the total is in that box." It works well when every document looks the same. TechTarget notes these older template tools couldn't handle new document types. When a customer changes their PO layout, the map breaks. That's the same problem we wrote about in why your Zap broke when a customer changed their PDF.
• IDP uses machine learning (and now often large language models) to understand what each field is, even when it moves around the page. It can adapt to new layouts instead of needing a new map for each one.

What the big vendors actually offer

You don't need to buy any of these directly. But knowing what's inside them helps you judge any product built on top.

Microsoft Azure Document Intelligence

Microsoft offers ready-made ("prebuilt") models for common documents. Its overview page, last updated Sept. 8, 2026, lists models for invoices, receipts, bank statements, checks, contracts, pay stubs, U.S. tax forms and more. There's no model with "purchase order" in its name. But the invoice model says it pulls key fields and line items from sales invoices, utility bills and purchase orders, and it lists sales orders and purchase orders as supported document types. Microsoft's newer service, Content Understanding, has a prebuilt analyzer for purchase order forms.

When the prebuilt models aren't enough, you train a custom one. Microsoft says you only need five examples of a document type to get started. It offers two main kinds:

• Custom template models are for highly structured documents with a fixed look. Microsoft says changes to the template lower accuracy, and it requires a model for each variation.
• Custom neural models handle documents with the same information in different page structures, using one model for all variations. Microsoft's neural model page lists invoices and purchase orders as examples of semi-structured documents, and Microsoft recommends neural over template models for higher accuracy where your language is supported.

Microsoft also has composed models (several models behind one address) and a classifier that sorts documents by type before extraction. For an order desk, the practical takeaway is simple: POs from 40 different customers look like 40 different documents, so you want the kind of model built for variety.

Amazon Textract and Google Document AI

Amazon's Textract says its invoice and receipt feature pulls data from almost any invoice or receipt without templates or setup. It also has a Queries feature where you ask a question like "What is the PO number?" and get back the answer, its location on the page and a confidence score. If it finds no answer, it leaves the answer blank instead of making one up. Amazon also says Queries can't pull out whole tables, so line items need a different feature.

Google's Document AI processor list includes an invoice parser and an expense parser, plus a Custom Extractor that uses generative AI or custom models. We didn't find a purchase order parser on that list.

All three give you the reading part. None of them knows your item master, your customers' part numbers or your pricing rules. That's the work between "fields pulled from a PDF" and "a correct sales order in your ERP."

Is it more accurate than people typing?

Not automatically. The best broad evidence we found comes from clinical research, where data accuracy is studied closely. A 2025 meta-analysis by Garza and colleagues in the International Journal of Medical Informatics pooled 93 papers published from 1978 to 2008. It compared error rates for four ways of getting data off paper and into a system.

Pooled error rates by data processing method

Clinical research data, 93 papers published 1978-2008. Percent of fields with an error.

1. Reading from records by handMedical record abstraction6.57%
2. Optical scanningOCR and mark recognition0.74%
3. One person typingSingle-data entry from a form0.29%
4. Two people typing, third checksDouble-data entry0.14%

Source: Garza et al., Int J Med Inform, 2025 (preprint on PMC).

A few things stand out. First, the worst method by far was a person reading through messy records to find the data, at 6.57%. That's the closest match to an order desk hunting through an email thread. Second, old-style optical scanning was not a sure win over one person typing from a structured form. Its pooled rate was 0.74% against 0.29%, but the authors say there were too few optical data points for a deeper analysis, and the ranges overlap, so don't read that as proof scanning is worse. Third, the most accurate method was a check step: two people typing separately and a third resolving differences.

This is old data from a different field, and it predates modern IDP. We use it for one lesson: the method of checking matters as much as the method of reading. Any reading method, human or machine, makes mistakes. The ones that win catch their own.

IDP is the reading part. The checking part should stay with a person until the numbers prove it out.

Confidence scores: the feature that matters most

Good IDP doesn't just return a value. It returns how sure it is. Microsoft explains that a field confidence of 0.95 means the prediction is likely right 19 out of 20 times. Where accuracy is critical, Microsoft says to use confidence to decide whether to accept a value automatically or flag it for human review. It also notes that not every field returns a confidence score yet.

That's how a sensible setup works:

1. The software reads the PO and fills every field it can.
2. Fields above your threshold go into the draft order. Fields below it are highlighted.
3. A person looks at the highlighted fields, fixes them, and approves the order.
4. You track how often the person had to fix something. Over time, that tells you which customers and fields you can trust more.

Microsoft's own transparency note for Content Understanding gives an example of sending results at 0.80 confidence or higher straight through and the rest to human review. That's an example, not a rule. For orders and invoices, start stricter. It's the same approach we describe in human-in-the-loop automation.

Where IDP still struggles

To be fair to the skeptics, there are real limits:

• Bad scans and handwriting. TechTarget notes extraction may not be accurate when an image is low quality, blurry or faded. Microsoft's own example shows a handwritten word being missed. Microsoft also suggests more than five training documents when images are low quality.
• Values split across pages. Microsoft says its custom neural model doesn't recognize values split across page boundaries, though tables can run across pages.
• AI that sounds sure but is wrong. When IDP uses large language models, Microsoft warns they might not always produce factually accurate information, and says to avoid using them where no human check or second verification is available.
• Look-alike documents. Microsoft points out that documents can look similar to people but appear different to an AI model. Two customers' POs that seem alike to your team may need separate samples.
• It stops at the fields. IDP can tell you the customer wrote "SS 1/4-20 HHCS." It can't tell you that's your part 10442 unless someone connects it to your item list.

None of these are reasons to avoid IDP. They're reasons not to let it post orders on its own on day one.

What this means for your order desk

If you're a distributor or manufacturer getting POs by email, here's how to think about IDP:

• It's a component, not a project. The reading part is now cheap and good. The work is in what comes after: matching customer part numbers, checking prices against your contracts, and putting a clean draft in front of a person.
• Ask any vendor about confidence and review. What happens when a field is uncertain? Who sees it? Can you see how often reviewers correct it?
• Test with your real documents. Pull 20 POs from your messiest customers, not the cleanest. Count how many fields come out right.
• Keep a person on the approve step until your own correction rate says otherwise.

If you want to see how the pieces fit together, our guides on AI vs. RPA for order entry and automating email and PDF orders walk through the rest of the flow.