Read Invoices and Receipts Automatically, Stop Retyping

Short answer. You read receipts and invoices in automatically with scan and recognise (OCR): you email or upload the document and the software pulls out the supplier, amount and VAT. You check it and post it. Only when formats deviate or multiple systems are involved do I build a custom recognition and integration layer.

Retyping invoices by hand is one of the dumbest tasks I come across in administrations. Someone grabs a PDF, looks at the amount, types it over, looks at the VAT rate, types that over, and repeats it hundreds of times a month. Every retyped line is a chance for an error, and you only spot that error once the numbers no longer add up. It can be done differently, and in most cases it can even happen largely by itself.

What scan and recognise does and why it works

By now almost every Dutch accounting package has a scan and recognise feature. You email an invoice to a fixed address or upload a photo of a receipt, and OCR technology reads out the relevant fields: supplier, invoice date, amount and VAT. You check it and post it with a single click. Exact claims this saves you up to 73% of your processing time, and you find comparable features in SnelStart, e-Boekhouden.nl, Moneybird and Rompslomp.

The goal here is not just time saved. It is about control and numbers that add up. When data is read out automatically, the number of typing errors drops and you get a current picture of your obligations faster. That is the real win: an administration you can build on.

Look at your process first, not straight at the tool

Before I set anything up or build anything, I walk through the process. Many administrative steps came into being at some point and have never been touched since. I regularly see invoices first being printed, then stamped, then scanned again. Or a fixed supplier sending the same invoice every month that gets posted by hand, when a recurring entry could handle it.

Sometimes a step turns out to be redundant. Sometimes it turns out the standard scan and recognise feature of the existing package is perfectly sufficient and you do not need to build anything further. That is a deliberate outcome, not a reason to look away. The calculation and the processing have to happen, the only question is at which level. Only once I know how the flow from receipt to posting actually runs do I know what can be done more cleverly.

When standard scan and recognise falls short

The built-in feature works well for run-of-the-mill invoices. It starts to chafe as soon as your situation deviates from the standard case. A few patterns I often come across:

• Deviating or foreign formats. Receipts from a specific supplier or till receipts that the package consistently reads out incorrectly.
• Line-level detail you genuinely need. Many features recognise the header and total, but not the individual invoice lines you want to link to cost centres or projects.
• Multiple systems. The invoice has to go not only into the accounting, but also into a project administration or CRM, without double entry.
• Your own approval logic. Invoices above a certain amount go to a second pair of eyes, or are matched automatically against a purchase order.

For the heavier cases there are specialised tools such as Basecone, which draws on more than 25 million anonymised invoices to recognise, and Zenvoices with self-learning recognition. These connect to Exact Online, AFAS and SnelStart. Good starting points, and I often simply recommend them.

What I build where the package stops

Sometimes no off-the-shelf package fits the situation. Then I build the missing layer. Concretely that means an AI workflow that pulls incoming invoices out of the mail, uses a recognition model to read out the fields your package leaves behind, and writes the result into the right system through an integration. On top of that a dashboard that shows you what has been recognised, what still needs manual checking and where things go wrong.

That is exactly the point where build-vs-buy tips over. As long as a standard feature meets your goal, you use it. The moment your process has its own logic that no package knows, a custom solution is the difference between staying stuck in the mud and a system that adds up. Building that is my work.