AI document processing: what it can and can't do

Last updated: 29 October 2026

AI document processing, also called intelligent document processing (IDP) or document AI, reads documents such as invoices, contracts and forms, extracts the data, checks it and sends it to the system that uses it. It still makes mistakes, so it scores its own confidence. Microsoft's 2026 guidance uses that score to decide what a person checks.

It works best on documents that arrive in large numbers and follow a pattern. This post covers how IDP differs from OCR, which documents suit it, how accurate AI invoice processing is, where people stay involved and how to start without a large project.

What is intelligent document processing (IDP)?

Intelligent document processing is the industry name for AI document processing. Document AI is a third name for the same idea. All three mean software that reads a document, understands its layout, pulls out the fields you need, checks them and routes the result.

It grew out of two older approaches:

• OCR (optical character recognition) turns an image of text into text. It reads the words but doesn't know which number is the total.
• Template capture adds fixed boxes: draw a box where the invoice number sits, and read whatever is in it. It breaks as soon as a supplier changes their layout.

IDP reads the document more like a person does. It finds the invoice number wherever it is, reads tables that run over two pages and copes with scans and photos. Then it does the dull part of the job: checks the data against rules and other systems, and enters it where it belongs.

OCR vs templates vs AI: how they compare

A typical IDP flow has five steps:

1. Receive. Documents arrive by email, upload or a shared folder.
2. Read. The text is extracted, including from scans and photos.
3. Extract. The fields you need are pulled out: supplier, date, amounts, line items, terms.
4. Check. The data is tested against rules: do the line items add up, does the purchase order exist, is this a duplicate?
5. Route. Clean results go into your system. Unclear ones go to a person.

The value is mostly in steps 4 and 5. Reading a document is the easy part now. Knowing what to do with it is your business.

Which documents suit AI document processing?

The best candidates arrive in volume, follow a rough pattern, and someone currently retypes or checks them by hand.

Good fits

• Invoices and receipts. Many suppliers, similar fields, clear rules for matching. This is why automated invoice processing is the most common starting point.
• Purchase orders and delivery notes, especially when they must be matched against invoices.
• Application and onboarding forms. Fixed questions, many submissions.
• Contracts, for finding specific clauses. Renewal dates, notice periods, liability caps.
• Identity and compliance documents, with a person approving the result.

Harder fits

• Documents that need judgement to read. A complaint letter, a legal opinion, a medical history. AI can summarise and sort them; a person should decide.
• Rare document types. If you see five a month, automation costs more than it saves.
• Poor scans and handwriting. Possible, but accuracy drops and more cases go to review.

How accurate is AI invoice processing?

Accurate enough to save most of the typing, and never accurate enough to skip checking. The useful question is not "how accurate is it" but "does it know when it might be wrong?"

Good tools return a confidence score for each field. Microsoft's documentation for its document AI service (2026) describes it as an estimated probability between 0 and 1: a score of 0.95 means the value is likely correct 19 times out of 20. It recommends using that score to decide whether to accept a result automatically or flag it for human review. For custom models, it suggests an accuracy score of 80% or higher, and close to 100% for sensitive cases such as financial or medical records.

Accuracy also depends on your documents. Ten suppliers with clean PDFs behave differently from three hundred sending phone photos. Test on your own documents before you trust any number, including the vendor's.

In AI invoice processing, the rule checks matter as much as extraction. A total that doesn't match its line items, a supplier missing from your records or an invoice number you've already paid are all caught by rules, not by the model.

Where do people stay involved?

In three places, and they should stay there.

• Low-confidence fields. Anything the system isn't sure of goes to a person, with the document and the unclear field side by side.
• Exceptions. Rule failures, unknown suppliers, amounts above a set limit.
• Decisions. Approving a payment, accepting a contract, rejecting an application. AI prepares; a person decides.

Plan for the review queue from the start. If nobody owns it, the old manual process returns.

Agents, and why documents are untrusted input

Newer setups add AI agents that act on what they read, such as emailing a supplier about a missing purchase order number. That adds a risk.

A document can contain text written to give the model instructions, such as a line in an invoice telling it to mark the invoice as approved. OWASP lists this as indirect prompt injection in its 2025 list of risks for AI applications: it happens when a model "accepts input from external sources, such as websites or files". Treat document content as data, never as instructions. Limit what an agent can do on its own, and keep approval with people.

How does AI document processing connect to your systems?

This is where most projects take longer than planned. Reading the document is quick. Getting the data into your accounting system, ERP or CRM is the real work.

Questions to answer early:

• Where do documents arrive today? A shared inbox, a supplier portal, a scanner?
• Where must the data end up? Which system, through which interface, and who can grant access?
• What do you match against? Purchase orders, supplier records, contracts. Are they in one place, and do the names agree?
• Where does the data live? Documents often hold personal and financial data. Decide where it is processed and stored before you choose a tool.

Mismatched names are a common blocker. The same supplier has a slightly different name in each system, with "LLC" in one and not the other, and matching fails until someone agrees a mapping.

Should you buy an IDP tool or have it built?

Off-the-shelf IDP tools fit standard documents going into a standard system, such as invoices from common suppliers into a popular accounting package.

A built integration fits when the hard part is your process, not the reading: matching rules that live in people's heads, an ERP with no ready connector, or several systems that disagree about the same supplier.

How should a business start with AI document processing?

Small, on one document type, with a measure agreed before you start.

1. Pick one document type with volume and clear rules. Invoices from your top suppliers are a common first choice.
2. Measure today's process. How many documents a month, how long each takes, how often mistakes happen.
3. Collect real samples, including the bad ones: scans, photos, odd layouts.
4. Run it alongside the manual process for a few weeks. Compare the results field by field.
5. Agree the bar for going live, for example which fields a person must check and what share of documents may go to review. The decision to go live is yours.
6. Then widen it, to more suppliers, more document types or more of the checks.

How iHux helps companies with document processing

Documents make a good first use case for our forward deployed engineer, which we also call an embedded engineer. A senior iHux engineer works inside your team, on your systems and data, with our team building behind them, until the use case runs in production. They learn the process the way your staff do it before automating any of it.

It starts with a two-week discovery that returns a short list of use cases ranked by value and difficulty. A second senior engineer reviews every change before it reaches your systems. The work happens in your accounts, and you own the code and documentation. We prepare the system for going live; when it goes live is your call, and the legal side stays with you. You can pause or end with 30 days' notice, and every engagement is quoted for your team.

To talk about your documents, contact us. To understand the model, read what is a forward deployed engineer?. For why AI pilots stall, read why AI projects fail and how to reach production.