Every week a pile of documents arrives and someone has to type what is on them into a system. Supplier invoices into the accounting software. Intake forms into the practice system. Signed contracts into a folder, with the key dates copied into a spreadsheet. It is slow, it is boring, and the person doing it could be doing something else.
You have probably tried something. A scanner app that gets the total wrong one time in ten. A vendor demo where a clean sample invoice came through perfectly and your real ones did not.
AI document processing is the practice of getting a machine to read those documents, pull out the specific facts you need, check them, and file the result where it belongs, with a person only looking at the ones that need a person. This article explains how it works, the parts that fail, and what a good build looks like.
What AI document processing actually is
Think of a good bookkeeper opening the mail. She does not read an invoice the way you read a novel. She looks for the supplier, the invoice number, the date, the line items and the total. She checks the total against the purchase order. If the numbers do not match, she puts it in a tray for someone to look at. If they do, she enters it and files the paper.
AI document processing is that same sequence, done by software, in four steps. Reading: turning the image or PDF into text the machine can work with. Extraction: pulling out the specific fields you care about, in a fixed shape. Validation: checking those fields against what you already expected (the purchase order, the customer record, the rules of your business). Routing: the clean ones flow into your system; the doubtful ones go to a person with a note saying exactly what was doubtful.
The difference between a system that works and one that does not is almost never the reading step. It is whether the last two steps exist. A tool that pushes every result straight into your books is not automation. It is a very fast way to make mistakes nobody catches.
1. Decide what a document is for before you extract anything
Start with the destination, not the document. For each document type, write down which system the data ends up in and which fields that system needs. A supplier invoice going into QuickBooks needs perhaps eight fields. A patient intake form might need twenty. A signed lease needs the parties, the term, the rent, the escalation clause and the notice dates, and almost nothing else.
This list is the whole specification. Vendors love to show you a tool that pulls “everything” from a document. Everything is not useful. Eight fields you can check are useful. Writing the list also exposes the documents not worth automating: four of a certain form a month, three minutes each, leave it alone.
2. Understand the two ways a machine reads a page
Traditional OCR (optical character recognition, software that finds letters in an image and turns them into text) is cheap, fast and good on clean typed documents. It struggles with skew, stamps, handwriting, tables and anything where the layout matters, because it hands you a wall of text with no sense of what was a heading and what was a value.
Vision models are the newer option. The current Claude models, GPT-class models and Gemini can all take an image or a PDF page directly and answer questions about it, including “what is the invoice total”. They understand layout the way a person does, so a total in a box in the bottom right reads as a total. They cost more per page than OCR and are slower, but on messy real-world documents they are much more accurate.
In the systems we build, the usual pattern is a vision model for anything with layout or variability and plain OCR for high-volume uniform documents where the format never changes. Ask your vendor which one they use. “We use AI” is not an answer.
3. Extract into a schema, never into free text
A schema is a fixed list of named fields with types: invoice_number is text, invoice_date is a date, total is a money amount, line_items is a list of (description, quantity, unit_price). When you ask the model to fill a schema instead of “summarize this invoice”, the output is always the same shape, so your software can rely on it, and missing fields are visibly missing instead of silently absent from a paragraph.
Every major model provider now supports asking for output in a fixed structure; the plain-English version is in LLM Structured Output and Tool Calling, Explained Plainly. The practical rule is that extraction should produce a record, not a description, and a vendor whose product gives you a summary paragraph and calls it extraction has skipped the hard part.
Include a confidence flag per value, or ask the model to mark values it was unsure about. This feeds the exception queue later. A schema where every field is always confidently filled is being guessed at.
4. Validate against what you already know
This is the step that makes the whole thing trustworthy, and it needs no AI at all. Once you have a record, check it against the world. Does the supplier exist in your vendor list? Does the invoice number already exist (duplicates are the most common expensive error in accounts payable)? Do the line items sum to the total? Is there a purchase order, and does the total match it within your tolerance? Is the amount inside the range this supplier normally bills?
Each check is a plain rule a developer writes once, and each failed check is a specific, named reason a document needs a person. “Total does not match PO 4471 by $312.50” is something a clerk can resolve in thirty seconds. “The AI was not sure” is not.
Validation is also your defence against the model making something up, which it will do occasionally. A hallucinated invoice number will not exist in your system, and a rule catches it. The wider discipline is in AI Hallucination Guardrails for Business Applications.
5. Build the exception queue as a real screen, not an email
The documents that fail validation, or come back with low confidence, need to land somewhere a person actually works. A shared inbox is not that place; things get lost, and nobody knows who is on it. Build or buy a simple queue: each document with the original image on one side, the extracted fields on the other, the failed checks highlighted, and buttons to correct, approve or reject.
The person handling exceptions should be able to fix a field and approve in a few seconds. Log their corrections; after a month you will know which fields the system gets wrong most. Aim for the queue to hold a minority of documents; if more than a quarter of what arrives needs a person, the extraction or the rules need work. If nothing ever lands in the queue, be suspicious rather than pleased.
6. Keep the original and a full trail
Never discard the source file. Store the original, the extracted record, the validation results, who approved it and when, and where it was filed, and link the record in your accounting system back to the original. When a supplier disputes something two years later, you want to open the record and see the actual page. The same trail turns “the totals were wrong on one supplier’s March invoices” into a five-minute investigation instead of a week.
7. Know which documents will not behave, and say so
Some inputs are not going to work well and you should know which before you promise anything. Handwritten forms are readable by vision models but with more errors, so tighten the validation and expect more exceptions. Long documents with the useful fields scattered across forty pages need extraction per page and then reconciliation. Big tables with merged cells are where both OCR and vision models still slip. And some documents should stay with a human entirely: anything where a misread changes a legal position, and anything too rare to be worth it. Put the exclusions in the scope.
8. Start with one document type and measure it
Pick the one document that costs you the most hours or the most errors, usually supplier invoices or intake forms. Run the new system alongside the old process for a few weeks: the person still types the documents, and you compare. Count the fields the system got right, the exceptions it raised, and the errors it let through. Switch only when the let-through rate is below what your people were producing. Then add the second document type; the queue, the storage and the trail are shared, which is why the first one takes longest.
Picture a business like this one
The business below is a composite of the kind of company that writes to us, not a client. The numbers describe the shape of the problem, not a case study.
Picture a business like this one: a regional building-supplies distributor with about forty staff. Around six hundred supplier invoices a month arrive by email as PDFs, from two hundred suppliers, each with its own layout. Two people spend most of their week keying them in and matching them to purchase orders. Duplicates get paid maybe twice a quarter, and each one is a phone call and a credit note.
What gets built for a distributor like this:
- A mailbox watcher that picks up every attachment sent to the invoices address and stores the original.
- A vision-model extraction step with a schema of eleven fields including line items, with a confidence flag per field.
- Validation rules: supplier exists, invoice number not seen before, line items sum correctly, purchase order matched within two percent, amount within the supplier’s usual range.
- An exception screen showing the original beside the fields, with one-click correct-and-approve.
- A push into the accounting system for approved records, with a link back to the original file.
- A weekly summary of exception reasons by supplier.
What changes is not that the two people are gone. They now spend an hour or two a day approving exceptions and chasing genuinely wrong invoices, instead of typing. Duplicate payments stop, because the invoice-number check is not tired on a Friday afternoon. And the distributor has a searchable record of every line item from every supplier, which turns out to be useful for negotiating prices. The other side of the ledger, getting your own invoices paid, is in Automate Invoicing and Collections Without Annoying Customers.
What it costs to run
The model cost is the part people worry about and it is usually the smallest line. Processing one invoice page through a current vision model costs a fraction of a cent to a few cents depending on the model tier; check the current pricing page of whichever provider you use. At six hundred invoices a month, expect the model bill to be in the tens of dollars, not hundreds, especially if a cheap model handles the clean documents and a stronger one only the failures.
The rest is ordinary infrastructure. A small server or a managed platform to run the pipeline and the exception screen: between $10 and $50 a month. File storage for the originals: cents per gigabyte. If the pipeline runs inside n8n or Make, add that subscription. A commercial document-processing product is usually priced per page, often a few cents to twenty cents each, with a monthly minimum; those add up faster at volume. The real ongoing cost is human review time on exceptions, which is exactly the point.
The mistakes we see most
- Straight-through processing from day one. Extracted data pushed into the books with no validation. It works for a month and then a misread total sits in the accounts until the auditor finds it.
- Judging the tool on the demo document. Every vendor’s sample invoice is clean. Test with fifty of your own, including the ugly ones.
- Extracting everything. Sixty fields, most never used, each a place for an error to hide.
- No confidence signal. If the system cannot say which values it was unsure of, every value has to be checked, and you have automated nothing.
- Exceptions to an inbox. The queue needs to be a screen with the original beside the data, or nobody works it.
- Discarding originals. Storage is nearly free; a dispute with no source document is not.
When to bring in help
An owner can get a long way alone. If your documents are uniform and your accounting software has a built-in invoice capture feature, turn it on and see how far it gets you; the accounting-specific rules are in AI QuickBooks Automation: What AI Can Safely Do With Your Books. Make and n8n both have AI steps that extract fields from an attachment, and for one document type with a simple check or two, a careful non-developer can build that in a weekend.
You need a developer when there are several document types, when validation has to check against your real systems, when you need a proper exception screen, or when volume means errors cost real money. The schema, the rules and the queue are software and should be built and tested like software.
Levelbrook builds document pipelines like the one above for businesses, at a fixed price from a written scope, running in accounts you own. If you want to talk through your document pile, the form below is where that starts.