Knowledge baseBuyer's guide
Choosing scan & recognise software in 2026: what should you look at?
You assess good scan & recognise software on six points: recognition at line level instead of header data only, the real exception rate, how the system learns from corrections, the quality of the connection with your accounting package, the pricing model and the agreements on data processing. This guide works out each criterion and gives a plan for a fair trial.
Published on 13 August 2026 · reading time approximately 9 minutes
What is scan & recognise software?
Scan & recognise software turns incoming invoices and receipts into posting data for your accounting package. The document arrives by email, upload or app, the software reads out fields such as supplier, invoice date, amounts and VAT, and then prepares a proposed posting. In practice this has become the standard layer at almost every bookkeeping and accountancy firm: nearly everyone already has something like it running, often as part of the accounting package or as a separate service alongside it.
Precisely because the basics are everywhere, a choice in 2026 is rarely about whether software can read an invoice. The question is what happens to the documents that do not go well on their own, and how much work is left with people afterwards. That is where vendors differ, and that is therefore what your comparison should be about.
Where does scan & recognise get stuck?
As a basis for comparisons we assume 60% automation for a common scan & recognise setup. That means about forty per cent of documents still needs attention: poor scans, receipts, unknown suppliers, invoices with several VAT rates such as 21% and 9% on one document, and composite invoices that have to be split. Each of those documents costs several actions, while the tidy monthly invoice from a known supplier was already going through quickly without new software.
This is general explanation, not a product claim: the exact percentage differs per firm and per document flow. But the distribution is the same everywhere. The saving from better software lies almost entirely in the difficult remaining pile, not in the standard flow. You will find the longer version of this story in the guide to posting invoices automatically and that guide covers the whole chain.
The six criteria for comparing scan & recognise software
1. Header versus line recognition
Header recognition reads the invoice number, date, supplier and totals. Line recognition also reads each invoice line separately, so that materials, labour, packaging or deposits can each go to the right GL account and VAT code. Ask concretely which documents are processed at line level and which only at total level. A vendor that says “yes” to everything is best asked to demonstrate it with an invoice showing 21% and 9% VAT side by side.
2. Exception rate, and what happens after an exception
A recognition percentage in a brochure says little. Three questions matter more: what share of documents is posted correctly without any correction, how does the system show doubt, and how long does it take to handle a single exception? A system that parks a document with a concrete reason when in doubt and only asks you to check the uncertain fields saves more time than a system with a higher percentage that quietly posts on and only makes errors visible at the period review.
3. Learning rules: does it learn, and where does that apply?
If you correct a posting, the software should learn from it. But learning without limits is dangerous: a correction for client A must not become an incorrect automatic rule for client B. Assess whether learning rules can apply separately per firm, per administration and per supplier, whether you can see which rule was created, and whether you can change or delete a rule. Invisible learning rules become an audit problem in the long run.
4. Connections with your accounting package
The best recognition is worthless if the posting does not land reliably in the package. Check whether the connection creates draft postings or can also post definitively, whether attachments come along, and what happens when the package returns an error: does the document then appear in a work queue, or does it quietly disappear? Also check whether the package your firm uses is actually supported; our current overview is on our page about integrations.
5. Pricing model: calculate with your own mix
Pricing models differ widely: per document, per administration, with tiers, monthly minimums or bundles. A low amount per document can work out differently for a small firm because of a firm minimum, and a fixed amount per administration works out differently with many small administrations than with a few large ones. So always calculate with the real spread of your documents across administrations and months, including peak months. Also ask what will apply after a trial period, so the first invoice holds no surprises.
6. GDPR and the data processing agreement
Invoices contain personal data, bank details and commercial information. A data processing agreement should separately state where the application runs, where documents are stored, which sub-processors are involved, which retention periods apply and whether your documents are used to train general models. Note: “not training” is something different from “keeping nothing”. For Agentancy itself: hosting in the Netherlands and storage within the EU, laid down in the data processing agreement.
Comparison table: the criteria at a glance
Use this table as a scorecard during vendor meetings. It deliberately covers criteria and test questions, not brands: vendor percentages and demos are only comparable once you test them on the same set of documents.
| Criterion | Question to put to the vendor | What to look for in the trial |
|---|---|---|
| Header versus line recognition | Which documents are processed at line level? | An invoice with 21% and 9% VAT is split correctly per line. |
| Exceptions and behaviour when in doubt | What happens when the system is in doubt? | Parked with a reason; only the uncertain fields need checking. |
| Learning rules | Where does a learned rule apply, and is it visible? | A correction for one client does not leak to other clients. |
| Accounting package connection | Draft or definitive posting, and what on a package error? | Errors land in a work queue; documents never disappear. |
| Pricing model | Which minimums, tiers and limits apply after the trial? | Calculated on your own spread of documents and administrations. |
| GDPR and the data processing agreement | Where do hosting and storage run, and is our data used for training? | The answers are on paper, not only in the conversation. |
How do you set up a fair trial?
The biggest mistake when comparing scan & recognise software is testing with the nicest invoices. Those go well everywhere. A fair trial uses the documents your current setup gets stuck on, and records in advance what “correct” means and who judges that. A set of fifty representative documents says more than five hundred standard ones.
- Collect ten tidy standard invoices as a baseline check: these simply have to go well.
- Add twenty documents that now need manual splitting or looking things up, such as invoices with several VAT rates or cost centres.
- Include ten poor scans, till receipts and invoices from unknown suppliers.
- Test ten documents with administration-specific or contact-specific agreements, so you can see whether context is taken into account.
- Deliberately correct one posting and submit a comparable document again: does the system learn, and only in the right place?
- For each document, measure the handling time, the number of corrected fields and whether the doubt was explained understandably.
Run the same set through your current way of working and compare the outcomes. That way you are comparing results instead of brochures, and you see straight away whether the gain is in your remaining pile or only in the standard flow that was already going well.
Should you switch straight away or run alongside first?
Choosing new software does not have to mean migrating your entire document flow. You can put a new solution next to your existing setup first, only for the documents that are left lying around now. That reduces the risk and produces evidence from your own administration before you replace anything. We describe what such a setup looks like in practice alongside Exact Scan & Recognise on our page about an alternative to Exact Scan & Recognise. Replacing it entirely only makes sense once the new solution also convincingly covers the standard flow, the connection and the management.
Conclusion: the best scan & recognise software is measurably better on your exceptions
There is no best scan & recognise software for everyone; there is a best choice for your document flow. Assess vendors on the six criteria in this guide, let them work on your own difficult documents and calculate the pricing model on your own spread. Distrust every comparison that leans on a recognition percentage alone.
Want to see how Agentancy meets these criteria itself? Have a look at posting invoices automatically with Agentancy and the current rates on our pricing page. You can test with 30 days or 100 documents free, precisely with the documents your current software gets stuck on.