In almost every first conversation about document automation, the same pile sits on the table: incoming invoices. And almost as often there's already been a failed attempt with "OCR software" — bought, set up, quietly buried after six months. Why that happened, and what actually works today.
The process itself is unspectacular and expensive for exactly that reason: an invoice arrives by email or post, someone sifts it, types amount, date, vendor and line items into the accounting system, matches it, files it. Three to eight minutes per invoice, depending on the process — with a few hundred invoices a month, that's whole working days, every month again. That you'd want to automate this is obvious. The only question is why so many attempts fail. The answer in one sentence, up front: because most projects invest in the wrong place — in recognition, which has long worked, instead of in checking and handover, which make the difference. The rest of this text is the long version of that sentence.
Why classic template OCR fails on reality
The OCR generation most failed projects were built with works with templates: for each vendor layout you define once where the amount sits, where the date is, where the invoice number goes. That works surprisingly well — for the twenty vendors whose invoices always look the same. It breaks on the reality of a normal business: hundreds of vendors, each with their own layout, plus new ones all the time. Every new vendor means a new template; every layout change is a silent error that only surfaces in accounting.
That's how template maintenance becomes its own part-time job — and at some point someone does the maths and finds that retyping was cheaper. That's the point where the software gets quietly buried. Not because OCR doesn't work, but because rigid templates and layout variety don't go together.
How modern AI extraction works
Modern models read a document more the way a human does: they understand what an invoice number is — regardless of where it sits. Unfamiliar layouts, scanned letters, crooked phone photos, English invoices between German ones: all the same path, without anyone maintaining a template. We've been running this pattern in production for years — among others in TaxCastle, where tax firms photograph receipts and get DATEV-compliant entries back.
The uncomfortable truth for everyone currently comparing vendors: recognition is thereby largely solved and is becoming standard. Which is exactly why it's no longer the place where projects fail. Failure now happens one floor up.
The part that really counts: validation and handover
A recognised amount is not yet a booked document. Between recognition and accounting belongs a validation layer, and it makes the difference between a toy and a tool:
- Arithmetic checks: net plus tax equals gross? Line items add up to the invoice total? Sounds banal, but catches recognition errors and faulty invoices alike.
- Master data matching: is the vendor known? Does the VAT ID fit? And the most important case: if the IBAN differs from the one on file, that's an alarm signal — not just a recognition issue, but a classic fraud pattern.
- Duplicate detection: the same invoice arrives by email and two weeks later by post. Without a check it gets booked twice — in the worst case, paid twice.
- Confidence instead of gut feeling: uncertain fields are flagged and land in a human review loop — original on the left, extracted fields on the right. Confident cases pass through.
And then the handover: the validated record has to go, structured, into the system the business actually works with — ERP, DATEV, Lexware and co. Without that connection you get the classic island: recognition works, but someone copies the results onward by hand, and the savings dissolve into clicks. The integration is unglamorous, often costs more project time than the AI — and still decides everything.
What "handover" means concretely depends on the target system. Towards DATEV it means: a posting proposal with the document image attached, so the firm can review instead of enter. Towards an ERP or Lexware and co: the invoice as a pre-captured record with an account assignment proposal, pinned to the original. In all cases the same rule holds: the leading system stays leading. The automation feeds into it — it doesn't build a second set of books next door where, a year later, nobody knows which state is correct.
From what volume it pays off
The calculation is the same as for any automation: document volume times minutes per document, set against building and operating. Roughly sorted: below about a hundred invoices a month, what your accounting software ships with these days is usually enough — we wouldn't build a dedicated pipeline for that. From a few hundred invoices a month, a dedicated pipeline with proper validation and integration starts to pay off, with payback in months rather than years. And whoever processes four figures a month loses not just time without automation, but quality too — at that volume, nobody types with focus anymore.
A worked example with round numbers, for plugging in your own: 500 invoices a month, a conservative five minutes each, makes a good forty hours — half a position, just for sifting, retyping and matching. If the pipeline realistically takes over three quarters of that, around ten hours of review work remain. What the thirty saved hours mean in euros, anyone can calculate with their own staff costs — and hold against a project budget that's incurred once, while the pile comes back every month.
An honest warning belongs in every one of these calculations: never calculate with one hundred percent automation. A realistic share passes through; the rest — bad scans, exotic cases, handwriting — lands in the human review loop. You plan for that residual share and measure it, instead of wishing it away. Automation that sits at 100 percent on paper sits at zero in practice — because nobody trusts it anymore.
And e-invoicing? The context that's usually missing
Since the beginning of 2025, companies in Germany have to be able to receive e-invoices in B2B business — structured formats under EN 16931, in practice XRechnung and ZUGFeRD. The obligation to issue invoices that way follows in stages over the coming years. On paper, that makes recognition obsolete: an XRechnung is a data record, not an image — there's nothing to recognise, only to read in.
In practice the topic doesn't disappear because of it: foreign invoices, small-amount invoices, receipts and the years-deep backlog of PDF and paper invoices remain. What's realistic is a hybrid pipeline — structured formats are read in directly, the rest runs through AI extraction, and both feed into the same validation and handover. That's also the good news for everyone building now: you build the validation and integration layer once; the intake end in front of it is interchangeable and gets cheaper with every e-invoice.
Getting started, without a big bang
The start we recommend is unspectacular: take one month of real incoming invoices — not the ten prettiest, but the honest cross-section including the problem cases — and measure what the extraction manages. After that, numbers are on the table: recognition rate, residual share, minutes per case. You can decide with those, not with brochure promises. And the accounting team that's supposed to use the tool daily later sits at the table from hour one — they spot the problem cases faster than any spec sheet, and in the end they decide adoption.
Exactly this pipeline — extraction, review interface, handover to the leading system — is what we build as a fixed package, prototype on your real documents first; the details are on our document automation page. And what the same pattern looks like beyond invoices is in our workshop note on automating payslips in tax firms.
