Document processing
Invoice OCR vs AI data extraction: what actually changes
By The MURAVIAN engineering team · · 7 min read
The difference between invoice OCR and AI data extraction is how the software finds a field. Template OCR, also called zonal OCR, turns the page into text and then picks each value from a fixed position or next to a fixed label, so it needs a template for every supplier layout. AI extraction gives the whole document to a language model, which finds the supplier, the dates and the amounts wherever they sit. What changes in practice is that new layouts stop being a setup job, and the effort moves to validation and review.
One clarification before the detail. OCR, optical character recognition, only converts an image into text. It is still part of many AI pipelines, especially for scans. The real comparison is between templates and a model that understands the document.
How template OCR works
A template-based system works in two steps. First, OCR recognises the characters on the page. Second, a template tells the software where each field is. There are two common ways to do that:
- Zones. The invoice number is in this rectangle, the total in that one.
- Anchors. Find the word “Total” and take the number to its right, or look for a pattern shaped like a VAT ID.
Someone builds one template per layout and maintains it. When you receive hundreds of invoices a month from a handful of suppliers whose layouts never change, this works well. It is fast and predictable.
Where template OCR breaks
The trouble starts when documents stop looking the way the template expects.
- New layouts. Every new supplier needs a template, and every redesign of an existing invoice breaks one. If you have many suppliers who each send only a few invoices a year, building a template for each is rarely worth the effort.
- Scans. A page fed into the scanner at a slight angle shifts every zone. The software reads the right rectangle and finds the wrong text, or nothing.
- Photos. Receipts photographed on a phone come with perspective, shadows and creases that fixed positions cannot follow.
- Tables. Line items that run over two pages, or a table with one more column than usual, are hard to describe with zones.
- Labels. The same field is called “Total”, “Amount due” or “Balance payable”, or something else in another language.
The worst failures are the quiet ones: the template reads the subtotal as the total and nothing flags it.
How AI extraction works
In an AI pipeline, the document goes to a large language model together with a description of the fields you want: supplier name, VAT ID, invoice number, issue and due dates, net, VAT, total, and line items if you need them. Depending on the setup, the model receives the recognised text, the page image or both. It returns the values in a structured format that software can check and pass on.
Because the model reads the document as a whole, it does not depend on where things are. It recognises that “Amount due” and “Total payable” label the same thing, that the company in the header is the supplier and the one in the “Bill to” box is you, and that the date next to “Due” is not the issue date.
What a well-built pipeline adds
The model alone is not the system. Three things around it make the output safe to use:
- Validation. Do net and VAT add up to the total? Does the VAT ID have a valid format? Is the supplier already known? Has this invoice number been seen before?
- Confidence thresholds. Each field gets a threshold. Above it, the value goes through. Below it, the document waits.
- A human review queue. A person sees the document next to the extracted fields, corrects what is wrong and approves it.
This is how we build AI document processing at MURAVIAN. ALYSAR, the accounting firm in our group, uses these document automations every day.
What AI extraction does not solve
The limits are worth knowing before you buy.
- Bad scans. If a digit is illegible to a person, the model cannot know it either. It may still return a plausible number, which is exactly why validation matters.
- Missing data. If the invoice has no purchase order number, there is nothing to extract. The model must be allowed to return an empty field, not pushed to fill every one.
- The need for rules. A model can swap two dates or misread a digit with complete confidence. Arithmetic and format checks catch errors the model does not notice.
- Judgement. Extraction tells you what is on the invoice. Deciding how it should be booked is still a person’s job, or a separate set of rules you define.
- Data questions. Your invoices are sent to an AI service. Check that the provider’s terms do not allow training on your data, and where the processing takes place.
Template OCR and AI extraction compared
| Aspect | Template or zonal OCR | AI data extraction |
|---|---|---|
| How it finds a field | Fixed position or label on the page | Reads the whole document and identifies the field by meaning |
| New supplier layout | Needs a new template | Usually works without setup, but should be tested |
| Scans and photos | Sensitive to skew, shifts and poor quality | More tolerant, still limited by legibility |
| Line items | Difficult when tables move or span pages | Handled better, should be checked against the totals |
| Typical failure | Empty or wrong field after a layout change | A plausible but wrong value |
| What keeps it reliable | Template maintenance | Validation rules, confidence thresholds, human review |
| Main ongoing cost | Building and maintaining templates | Usage of the AI service per page, plus review time |
| Best fit | Few suppliers, stable layouts | Many suppliers, varied layouts, mixed quality |
How to test on a sample of your own invoices
Product demos use clean documents. The test that tells you something is one on your own.
- Build a representative sample. Take 50 to 100 invoices from the last few months. Include the awkward ones on purpose: scans, phone photos, multi-page invoices, credit notes, foreign suppliers.
- Write down the correct answers. For each invoice, record the right value of every field you need. Your accounting software already holds most of them.
- Run the sample through each option, with the validation rules switched on.
- Compare field by field, not document by document.
- Read the failures. A wrong value that was flagged for review is an inconvenience. A wrong value that passed is a risk.
We test on a sample of a client’s own documents before we quote. For accounting practices, our page on automation for accounting firms shows where invoice extraction fits alongside document collection.
What to measure
Three numbers tell you whether the system is worth having.
- Field-level accuracy. For each field, the share of invoices where the extracted value matches the correct one. Keep the fields separate: a strong result on the invoice date does not make up for a weak one on the total or the VAT ID.
- Straight-through rate. The share of invoices that pass every check and need no human touch. This decides how much time you save.
- Review time. The minutes a person spends on each invoice that lands in the queue. Compare it with the time it takes to type the same invoice in by hand today.
Add a fourth if you can: the number of wrong values that passed without a flag. It should be as close to zero as your rules can make it.
To turn the result into money, put the hours your team spends on invoices today into the ROI calculator and set them against the indicative prices.
Next step
If you want to know how your own invoices would behave, book a free 30-minute automation audit. We map your invoice process with you and tell you what can be automated, roughly what it costs and how a test on your own documents would work.
About the author
The MURAVIAN engineering team
Engineers who build and run the systems we write about
Articles are written by the engineers who build and run MURAVIAN’s automations and its eight products. We have been building software since 2005 and write only about what we have put into production ourselves.