How to automate invoice processing

Supplier invoices arrive as PDFs in a shared mailbox, as attachments to a personal one, as downloads from six different portals, and occasionally on paper. Someone opens each one, retypes the supplier, the date, the amount and the VAT, matches it against an order if there is one, chases an approval, and books it.

The work is genuinely mechanical, which is why it is a good candidate. The reason automation projects here go wrong is that the extraction is the easy part and everyone spends their budget on it.

Start by removing invoices from the problem

Before any extraction, ask your twenty largest suppliers to send structured e-invoices. In the Netherlands and across the EU this means UBL, usually over the Peppol network, and most accounting packages can receive it. A structured invoice arrives as data: supplier identifier, line items, VAT per rate, payment reference, all of it typed and none of it guessed.

Every supplier who switches is an invoice your system never has to read. For businesses selling to Dutch public bodies this is already routine, and the wider EU move towards mandatory e-invoicing means the direction of travel is settled.

This is the least exciting recommendation in the article and the highest return. A pipeline that reads 400 PDFs a month is a smaller, safer pipeline when 250 of them became data at the source.

The pipeline, step by step

For everything that remains, seven stages. The value is concentrated in stages four and five.

1. One intake point. A single mailbox, say invoices@yourcompany, plus scheduled fetches from supplier portals and a scan folder. Forwarding from personal mailboxes is a rule, not a hope. Every document gets an identifier and is archived unchanged before anything touches it.
2. Classify before you extract. Not everything in that mailbox is an invoice. Reminders, statements, credit notes, price announcements and the supplier's Christmas card all arrive through the same door. Route non-invoices out early rather than letting them reach the ledger.
3. Extract, structured first. If the document carries embedded data (a UBL attachment, or a ZUGFeRD-style hybrid PDF), read that and skip the model entirely. Otherwise use OCR plus a language model to produce a fixed schema: supplier, VAT number, invoice number, date, due date, currency, net, VAT per rate, gross, payment reference, IBAN, and line items where you need them. Ask for the same fields every time, including the ones that are often absent, so that "missing" is a value rather than a silence.
4. Validate arithmetically. This is what separates a system from a demo. Recompute the totals: line items should sum to net, VAT should follow from the rates, and net plus VAT should equal gross. Check the VAT number format and, for cross-border invoices, verify it against VIES. Check the date is plausible. Any mismatch goes to a person, because a document whose own numbers do not add up is either a bad read or a bad invoice, and you want to know which.
5. Match against what you expected. Look up the supplier in your own master data by VAT or Chamber of Commerce number, never by name. Deduplicate on supplier plus invoice number plus amount, so the copy that arrives by email and the one downloaded from the portal collapse into one record. Where you use purchase orders, do the three-way match against the order and the goods receipt.
6. Route for approval by rule. Thresholds by amount and cost centre, with everything that failed validation going to a review queue that shows the extracted values next to the original document, side by side. Reviewing is fast when the source is one click away and slow when it is not.
7. Post and archive. Write to the ledger through the API of whatever you run: Exact Online, Twinfield, AFAS, e-Boekhouden or Moneybird all support this. Keep the original document, the extracted data and the decision trail together, and keep them for the seven years Dutch tax law expects.

The failure that costs real money

Never take the bank account number from the invoice.

Payment redirection fraud works like this: an attacker who has read a supplier's mailbox sends a genuine-looking invoice with one field changed, the IBAN, sometimes with a polite note about a new bank. A pipeline that extracts the IBAN and pays it is a very efficient way to send money to a stranger, and it is efficient at scale.

The rule is that payment details come from your supplier master record, not from the document. When a document's IBAN differs from the master record, that is not a validation warning, it is a stop: the invoice goes to a human, who verifies the change by calling a number they already had, not a number on the invoice. Changing a supplier's bank details should be a deliberate act with a second pair of eyes, and it should never be a side effect of processing a payment.

Two smaller failures worth naming. Confidence scores from an extraction model tell you how sure the model is, not how right it is, so calibrate thresholds against a sample you checked by hand, and re-check after any model change. And credit notes handled as negative invoices cause quiet reporting errors when nobody tests them, because they are rare enough to be forgotten and common enough to matter.

When not to automate invoices at all

If one person books the month's invoices in an afternoon, the maintenance will cost more than the work. A system touching a mailbox, an OCR service, a model, your supplier master and your accounting package will break several times a year by itself, because five vendors change things on five schedules. That upkeep does not scale down for low volume. The general version of this argument is worth reading before you commit.

If your coding of cost centres and ledger accounts is genuinely a judgement call, automate the extraction and leave the coding to a person with a good interface. Suggested codes with a one-click correction beat a system that codes confidently and wrongly, and the corrections are the training data for doing better later.

And if your real problem is approvals sitting in someone's inbox for three weeks, extraction will not help. Fix the approval flow first, on its own.

What good looks like after six months

Most invoices arrive as data, not paper. Extraction handles the rest with a review queue that stays short because validation catches the genuine problems rather than flagging everything. Nobody types an IBAN. Duplicates collapse on their own. A person still looks at the exceptions, and that person knows they own it.

The word "confidence" does not appear in your metrics. What appears instead is how many invoices went through untouched, how many needed review, and how many were wrong after posting, which is the only number that actually tells you whether it works. For anything that puts a model in front of money, the wider discipline is containing hallucination in production.

This is the shape of most of our workflow automation projects, and the rest of the workflow automation guides take the same approach to neighbouring processes.

Frequently asked questions

Do we still need OCR if our supplier sends UBL?

No. A UBL or Peppol invoice is already structured data, so you read the fields directly and skip extraction entirely. That path is both cheaper and more accurate, which is why moving suppliers onto it is the first step rather than an afterthought.

How accurate is model-based extraction on scanned invoices?

Accurate enough that arithmetic validation, not the model, becomes your quality control. Expect a good result on clean PDFs and a worse one on photographed or faxed documents, and design the review queue on the assumption that some percentage will always need a human.

Can it post straight to our accounting package?

Yes, if your package has an API, which Exact Online, Twinfield, AFAS, e-Boekhouden and Moneybird all do. The integration is rarely the hard part. Deciding what happens when a posting is rejected is.

What about the seven-year retention requirement?

Keep the original document as received, the extracted data and the approval trail, linked together. Dutch tax law requires the administration to be retained for seven years, and an automated pipeline makes that easier than a shared drive as long as archiving is part of the flow rather than a separate habit.