Invoice processing automation: what AI can read, and what still needs a person

Invoice processing automation reads incoming invoices, pulls out the supplier, dates, amounts, VAT and line items, checks them against rules and passes the clean ones on to your books. Current AI reads clean digital PDFs well and poor scans less well. A person is still needed for the exceptions: totals that don't add up, missing purchase orders, new suppliers and, above all, changed bank details.

What invoice processing automation actually does

The phrase covers a pipeline with five parts, and only one of them is AI.

1. Intake. Invoices arrive in a shared inbox, a folder or an upload page and are picked up automatically, so suppliers don't have to change how they send them.
2. Extraction. OCR and an AI model turn each document into fields: supplier, invoice number, dates, net amount, VAT, total and, where you need them, line items.
3. Validation. Rules check those fields against each other and against what you already know about the supplier.
4. Review. Anything that fails a rule, or that the model was unsure about, goes to a person with the original PDF next to the extracted values.
5. Output. Clean rows land in Excel, a database or your accounting software, through its API or its import file.

When a team tells me an extraction tool didn't work for them, they had usually bought step two on its own. Extraction without validation and review gives you a table that is mostly right, and you can't tell which rows are wrong, so someone ends up checking all of them against the PDF. That is slower than typing them in the first place, and it's the reason a lot of finance teams are sceptical of the whole idea.

What OCR invoice processing reads reliably today

OCR invoice processing has moved on a long way from the template days, when every supplier layout needed its own zones drawn by hand. Microsoft's prebuilt invoice model in Azure AI Document Intelligence is a fair reference point. According to Microsoft's documentation, it handles phone photos, scans and digital PDFs, supports invoices in 27 languages and returns structured JSON with fields such as the invoice ID, customer, total and line items. General vision models from OpenAI or Anthropic can do similar work and cope better with odd documents, at the cost of being less predictable from one run to the next.

In my experience the input decides more than the choice of model. From easy to hard, roughly:

• Digital PDFs generated by accounting software, with a text layer. These extract very reliably.
• Clean scans of printed invoices. Header fields are usually fine; line items depend on how the table is laid out.
• Phone photos, skewed scans and documents with handwriting or stamps on them, which produce more review cases.
• Multi-page invoices whose line items run across pages, credit notes that look like invoices, and single PDFs that bundle several invoices together.

I don't quote general accuracy percentages, because they say little about your documents. The number worth trusting is one measured on a sample of your own invoices, and the test for that is described further down.

What still needs a person

AI can read an invoice. It can't decide whether you should pay it. These are the cases I'd always route to a person, whatever the model's confidence:

• Changed bank details. If a known supplier's account number differs from the one on file, stop and verify by phone, using a number you already had, not the one printed on the invoice. Fake bank-detail changes are a common route for invoice fraud, and no extraction model can tell a real change from a forged one.
• A new supplier, until someone has checked who they are and set up their master data.
• An invoice with no matching purchase order, or one that doesn't match the PO on quantity or price.
• Credit notes and partial credits, which have to be linked to the right original invoice.
• Invoices addressed to the wrong legal entity, which happens a lot in groups with several companies.
• Cost-centre coding where the answer depends on who ordered something and why.

The aim is to turn each of these into a short decision with the reason already attached, so the reviewer isn't re-checking the whole document.

Validation rules that don't depend on AI

The rules are what make AI data extraction safe to use, and none of them needs a model. A typical set looks like this:

• Line items add up to the net amount, and net plus VAT equals the total.
• The VAT rate is plausible for that supplier and country.
• The supplier exists in your master data and the bank details match the ones on file.
• The invoice number hasn't already been booked for that supplier.
• The invoice date isn't in the future, and isn't so old that it suggests a resend.
• Where you work with purchase orders, the invoice matches an open PO within a tolerance you choose.
• The model's confidence on the total and the invoice number is above a threshold you set.

Documents that pass everything go straight through. The rest land in the review queue with the failing rule named, so the reviewer knows where to look. After a few months the queue tells you something useful as well, namely which suppliers cause most of the exceptions; a polite email asking one of them to send a proper PDF instead of a phone photo can remove a whole category of review work.

Extract data from PDF to Excel: when a spreadsheet is enough

Not every team needs a pipeline into the ERP. Sometimes the job is to extract data from PDF to Excel once a month so someone can reconcile or analyse it. Then the output can be a clean sheet in the column order your team already uses, and the review step can be as simple as a column that flags the rows to check.

Whether you need OCR at all depends on the PDF. A PDF exported from software has a text layer, and plain parsing gets you most of the way without any AI. My free bank statement to Excel converter works like that: it reads the text layer of a statement inside your browser and never uploads the file. It can't read scans, because a scan is a picture of text and needs OCR first. So the first thing I check on any batch of documents is which of the two it is, since that decides how much of the job is simple parsing and how much needs a model.

If the spreadsheet is the end product and someone rebuilds a report from it every month, Excel automation with Power Query can take the copy-paste out of that next step as well.

Data entry automation beyond invoices

The same setup covers most data entry automation around documents: receipts, bank statements, delivery notes and order confirmations. The fields change and the rules change with them, but the pipeline stays the same, from intake through review to output.

E-invoicing will shift part of the mix. Under the EU's VAT in the Digital Age package, member states can now require e-invoicing, and digital reporting requirements apply to cross-border B2B transactions from 1 July 2030, according to the European Commission. A structured e-invoice skips extraction entirely, which is good news. But rollout differs per country, suppliers outside the EU aren't covered, and receipts and statements will keep arriving as PDFs for years. A pipeline that accepts both structured files and PDFs, and sends both through the same rules and review queue, keeps working while the mix changes.

Once the data is clean, put it to use. Extracted invoice data can feed finance views like the overdue-invoice and ageing tables in this concept CFO dashboard, built on sample data, or a monthly pack that assembles itself through automated reporting.

When automating invoices is worth it

Volume matters, but less than people think. A team that receives a few dozen invoices a month from the same five suppliers is often better served by a tidy Excel template and a fixed routine than by any pipeline. The case for automation gets stronger when one or more of these is true:

• Someone spends a real part of their week typing invoices, and the backlog grows at month end.
• You have many suppliers with different layouts, so no single template works.
• Errors are expensive: duplicate payments, missed early-payment discounts or VAT that has to be corrected later.
• The data is needed somewhere else as well, such as a spend dashboard or a cash forecast, and copying it twice is how mistakes creep in.

A simple way to decide is to time it. Have the person who does the work note how long a normal week of invoices takes, including the corrections and the searching for missing POs. If that number is small, spend the money elsewhere. If it's a large share of someone's job, and most of that time goes into the easy invoices from regular suppliers, automation will help; if the time goes into the awkward exceptions, it will help less, because those still end up with a person.

How to test invoice processing automation before you buy

Whatever tool or builder you choose, test it on your own documents first. A useful test takes an afternoon to prepare:

1. Collect a sample of real invoices from your regular suppliers, plus the awkward ones: scans, credit notes, multi-page line items. Anonymised copies are fine.
2. Type the correct values for the fields you care about into a spreadsheet. That is your answer key.
3. Run the extraction and compare field by field, not document by document. A document with nine correct fields and a wrong total has failed where it matters.
4. Count how many documents would have passed every rule and gone straight through, and how many would have gone to review.
5. Check the documents that went straight through for errors. That count should be zero or very close to it; if wrong values slip past the rules, tighten the rules before anything goes live.

After the test, run the pipeline next to your manual process for a while without letting it touch your books, and compare. What you're measuring isn't how clever the extraction is but how many minutes per invoice a person still spends, and whether any error got through. Those two numbers decide whether it was worth building.

Where your documents go

Invoices carry names, bank details and prices, so ask any provider where documents are processed and stored, how long originals are kept and whether your documents are used to train models. Can they answer in writing? If not, keep looking.

For my own builds I'm based in the Netherlands, use EU regions where the provider offers them (or your own Azure tenant if you prefer), choose API terms that exclude training where the provider offers that, and sign an NDA and DPA on request. You decide how long the originals are kept.

If you'd like to see how this would do on your own invoices, my invoice processing automation service starts with an accuracy test on a sample batch, so you can judge the results field by field before paying for a build.

Frequently asked questions