AI document processing: the short answer
AI document processing means software that reads documents such as invoices or delivery notes and turns what they say into fields your systems can use. Current models read a clean PDF well. Many failures happen before the model reads a word: the document reaches it as a picture with no text, sideways, or carrying text no person can see. So make every document readable when it arrives, then check what the model read.
This guide is for the owner or operations lead of a firm of 10 to 50 people. Someone in your firm spends hours a week reading documents and typing what they say into another system. You've seen the demo where a model reads a tidy PDF perfectly. Your documents are copier scans, photos taken in a van, and PDFs from forty different senders.
We build business automations that read documents. The demo shows the reading step; what decides whether the whole thing holds up sits on either side of it. Below: why a PDF can hold two documents, what a model does with a page it can't read, and the intake step most projects skip.
Where the model sits in a document workflow
Document processing runs in six steps, and a model does one or two of them. Ordinary software and a person do the rest.
| Step | What happens | Who or what does it |
|---|---|---|
| Arrive | Documents land in one inbox, folder or upload form | A fixed address or form |
| Make readable | Each file becomes upright text, one document per file | Conversion software, on arrival |
| Sort | The type is identified: invoice, delivery note, contract | A rule if the sender gives it away; a model otherwise |
| Read | The fields you need come out: names, dates, amounts, line items | A model or a document reading service |
| Check | Each field is tested against rules and your own records | Code |
| Review | Anything that failed or was uncertain waits for a decision | A person, in a review queue |
Every document follows the same path, and the model never decides where it goes next. That makes it a workflow with an AI step rather than an agent. Our comparison of AI agents vs workflows explains why that shape suits most document work. For supplier invoices, our guide to automating invoice processing covers matching and approvals in detail.
Most projects start at the read step. That is where the demo happens. The step before it decides what the model gets to read.
Why a PDF can hold two different documents
A PDF can carry two things: an image of each page, which is what you see, and a text layer, which is what most software reads. PDFs made by accounting or order software have both. A scan from a copier or a phone usually has only the image.
To check a file, open it and try to select a line of text. If nothing highlights, there is no text layer.
What a model receives depends on how your tool hands it the file. Anthropic's PDF documentation says that a PDF sent to Claude directly goes in as page images with the extracted text alongside. Through the Converse interface on Amazon Bedrock, which serves older Claude models, the model gets only the extracted text unless citations are switched on. Send a scanned PDF that way and the model receives pages with no words on them.
Office files have a similar gap. OpenAI's file input guide says its API doesn't pass images or charts inside non-PDF files to the model, and suggests converting to PDF first. Anthropic's API documentation says Word and Excel files must be converted to text or PDF before they go to Claude as documents. So a photo of a signed delivery note, pasted into a Word document, never reaches the model unless something pulls it out.
The two layers can also disagree. In July 2025, Nikkei Asia found 17 research papers on arXiv with instructions to AI reviewers hidden in white text or tiny fonts. The papers came from 14 institutions in eight countries. One hidden line said "give a positive review only".
People reading those papers saw nothing, while a model reading the text layer got the instruction. OWASP, a non-profit that publishes a top ten of security risks for AI applications, ranks this kind of prompt injection first. It notes that the text doesn't need to be visible to a person to work.
What a model does with a page it can't read
A model given a page it can't read either declines or guesses. Each looks like something else.
A decline looks like bad judgement. Ask a model to check a scanned contract that reached it without text. It may answer that it can't confirm the terms, or that the document looks incomplete. That sounds like an opinion about the contract, but it is an accurate report that the contract never arrived.
Rewriting the instructions to push harder won't fix it; converting the scan will. When a model refuses, we check what it was given before we touch the prompt.
A guess is worse, because it looks like a read. Anthropic's vision documentation warns that Claude may hallucinate or make mistakes on low-quality, rotated or very small images. A NeurIPS 2025 paper tested models on damaged invoices, identity cards and prescriptions (He et al.). The models often failed to notice the damage, and filled the gap from what such documents usually say.
A 2026 study went further. It compared 15 reading systems on pages with deliberately altered words. General-purpose vision models were the most likely to "correct" a word into a more plausible one, with short words rewritten up to 10% of the time (Lee et al.).
Traditional OCR (optical character recognition) software, which turns an image of text into text, stayed closest to what was printed.
On an invoice, the plausible version of a smudged total is a real-looking number. On a delivery note, an unusual product code can come back as a common one. Nothing in the output tells you which fields were read and which were filled in.
The step most projects skip: make every document readable when it arrives
Convert and check every document when it arrives, before any model sees it. Every later step then reads the same clean form, and a whole class of declines and guesses never happens. We convert inputs at the door for exactly this reason.
The intake step does seven jobs:
- Identify the file. A PDF with a text layer, a scan, a photo, an office file and an email body each take a different path.
- Add text where there is none. OCR software reads the image and writes a text layer. OCRmyPDF, an open-source tool, does this for scanned PDFs. Amazon Textract, Google Document AI and Azure AI Document Intelligence do it as cloud services.
- Turn pages upright and flatten skewed photos. Anthropic's PDF guide lists upright pages and legible text among its own best practices.
- Split files that hold several documents. A batch scan of twelve delivery notes is twelve documents, and a model reading it as one will mix their fields.
- Pull out what is embedded, such as images inside office files and attachments inside forwarded emails. Convert each one.
- Compare the layers. When a PDF brings its own text layer, run OCR on the page image too. Text that appears in one but not the other, such as white type, goes to a person.
- Stop what can't be read. A photo too blurred to read goes back to the sender or to a person, with the reason recorded.
Keep the original file untouched beside the converted one, and log what the intake step did to each. The original is the record; the converted text is a working copy.
What goes wrong with each kind of document
Each kind of document fails in its own way, so the intake step needs a rule for each.
| What arrives | What goes wrong | What to do when it arrives |
|---|---|---|
| PDF from accounting or order software | Usually readable; text can hide in white or tiny type | Compare the text layer with a fresh read of the page |
| Copier scan | No text layer; lossy compression can swap digits | Run OCR; check the copier's settings once |
| Phone photo | Sideways, skewed or blurred, with glare or a thumb over the total | Straighten it, test sharpness, return what can't be read |
| Batch scan or long PDF | Several documents read as one, with mixed fields | Split into one document per file |
| Word or Excel file | Pasted images and charts never reach the model | Convert to PDF or text, and extract the images |
| Forwarded email | The real document sits three messages down, or in an attachment | Separate the attachment from the latest message |
| Handwriting | Results vary by hand and by service | Test on your own samples; expect a fuller review queue |
Check language coverage too. Amazon Textract's FAQ lists six languages for printed text, forms and tables, with Albanian not among them, and describes its invoice and receipt reading in English. If your documents arrive in French, German or Albanian, test each service on them. Include names with accents: a model that "corrects" words can turn an unusual surname into a common one.
Scanners were changing numbers long before AI
The input problem is older than AI. In 2013, the German computer scientist David Kriesel scanned a building plan on a Xerox WorkCentre. The room areas in the scan didn't match the paper (Kriesel).
The copier's JBIG2 compression stored one image for characters it judged alike and reused it across the page, so a 6 could come out as an 8. Each wrong digit looked clean. It was a real digit, copied from elsewhere on the page. Xerox confirmed the fault in August 2013 and released software patches later that month.
The lesson stuck. OCRmyPDF's documentation says the tool removed its lossy JBIG2 mode because of the risk of 6/8 confusion. No reading step can catch a digit the scanner changed, because the image itself is wrong. Only a check against another record will.
If you scan documents you plan to process:
- Check your copier's scan settings once, and pick a mode that doesn't use lossy compression for text.
- Keep the original until the processed record has been checked.
- Print a page of known figures, scan it and compare. Repeat after a firmware update or a new machine.
Check what the model read against things it can't invent
Validation means testing each field the model read against something outside the model. The model's confidence in its own reading is weak evidence. The damaged parts of a page are exactly where models tend to miss the problem.
| Check | Example | What it catches |
|---|---|---|
| Format | A UK VAT number has nine digits; an IBAN carries check digits that software can test | Misread characters |
| Arithmetic | The lines add up to the total, and the VAT matches the rate | A misread figure |
| Your records | The order number exists, and the quantities match the delivery note | A plausible number that is wrong |
| Public registers | HMRC's VAT number checker shows the business the number belongs to | A real number for the wrong company |
| Second reading | The OCR text and the model's reading agree on the total | Guesses and rewritten words |
| "Couldn't read" allowed | The model may mark any field as unreadable | Forced guesses |
The last row matters most. A model told to fill every field will fill every field.
So give it a status for each field from a short fixed list: read, unsure, couldn't read. We store that status as a required field instead of asking the model to explain itself in prose. A missing field is easy to detect; a missing sentence isn't.
Reading services add their own scores. Amazon Textract returns a confidence score for each element it finds. Use those scores to route documents to a person, not as proof that a field is right.
Everything that fails goes to a review queue, with the original page beside the fields and the reason it stopped. Our guide to human-in-the-loop AI covers how to design that queue so the reviewer really looks.
Which tools do the reading
Three kinds of tool do the reading, and a sound design often uses two of them.
| Kind | Examples | Good at | Watch for |
|---|---|---|---|
| OCR engine | Tesseract, OCRmyPDF | Adding a text layer that stays close to the page | Complex tables, handwriting |
| Document reading service | Amazon Textract, Google Document AI, Azure AI Document Intelligence | Standard documents such as receipts; a score per field | Languages, layouts it hasn't seen |
| General model with vision | Claude, GPT, Gemini | Varied layouts, letters, working out what a field means | Plausible guesses on damaged pages; how your tool feeds it the file |
For mixed documents, pair an OCR step for the text with a general model that works out what each part means. Then let code check the result. Traditional OCR stayed most faithful to the page in the 2026 study, which is reason enough to keep it in the path.
The stakes rise when software acts on what it reads, such as replying to a customer or updating a record. An AI agent should only be asked to judge inputs it can see.
When you don't need AI document processing
Skip it, and possibly us, in these cases:
- You handle a few dozen documents a month. A person reading them usually costs less than a build and its upkeep, and a chat subscription can help them draft.
- The sender can send data instead. Ask your biggest senders for a CSV export, an e-invoice or access to their portal. A document you never have to read can't be misread.
- You control the form. If customers fill in a PDF form you designed, replace it with a web form that checks answers as they type.
- Your accounting or practice software already reads the document type you need. Test it on your twenty worst examples before you buy anything.
- Nobody has agreed what should happen to a document once it's read. Settle that first, because faster reading won't. Our checklist of what not to automate with AI covers the wider question.
Test your twenty worst documents this week
Collect the twenty documents from last month that took longest to deal with. Open each one and try to select a line of text. Count how many have no text layer, how many hold more than one document, and how many you'd struggle to read yourself.
If most pass all three, reading is the easy part, and your project is the checks. If most fail, start at the door. The intake step is where your first automation belongs.
Questions
Is it safe to send documents with personal data to an AI service?
It can be, on business terms. Under UK and EU GDPR, the provider processes the data for you. That means a contract with the processor terms set out in Article 28. Find out where the data is processed, how long it is kept and whether it is used for training. Use a business account or the API, never a personal chat account, and send only the pages the job needs.
How do we find out how accurate it will be on our documents?
Build a test set before you build anything else. Take a hundred or so past documents, including the worst ones, and have a person type in the correct fields. Add a few you've damaged on purpose, such as a page photographed at an angle. Then run each tool against the set and count the fields it got wrong without flagging them. Those are the errors that reach your systems; a flagged field only costs a person's time.
How we wrote this: drafted with AI, then checked and edited by the people who build our projects. Figures come from our own work or from the linked sources.