Perspective · · 5 min read
Why purchase invoice automation is not a generative AI product
The hardest thing about selling invoice automation in 2026 isn't convincing buyers that AI can do it. It's convincing them that generative AI alone can't. Gartner's own guide is blunt: focusing exclusively on GenAI guarantees failure. Invoice automation is where that warning lands hardest.
In their Enterprise Guide to Generative AI, Gartner puts it bluntly: focusing exclusively on GenAI is a guarantee to fail. They flag prediction, forecasting, and critical decision intelligence as areas where generative models fall short.
Purchase invoice automation is all three of those things at once. Which is why the LLM-wrapper approach keeps failing, even with increasingly impressive demos.
The demo is the easy part
Here's what usually happens. A team puts together an invoice automation demo in a couple of days. They pick a sample set of clean invoices. They pipe them through a modern LLM with a reasonable prompt. Account prediction lands at 93% accuracy. Everyone in the room is impressed. The build-or-buy calculation suddenly looks obvious. Why pay someone when we can do this ourselves in a week?
Then production starts.
The invoices that arrive in a live customer environment are not the sample set. They come from vendors the model has never seen. Some are ten pages long with nested summaries that don't add up. Some have typos in vendor names. Some use internal numeric codes instead of descriptions. Some are partial credits against invoices from six months ago. And unlike the sandbox, you cannot peek at the answer to check whether the model got it right. In a demo you know the expected outcome. In production you just have the model's guess and hope.
Accuracy drops. Not by a few points. Sometimes by thirty. The team grinds on it, finds patterns, adds rules, tunes prompts. A few months in, the rate recovers. The team is relieved.
Then someone realises account prediction is one of a dozen things that has to work reliably before you can call anything automated. Cost centers. VAT status. Approval routing. Periodisation. Credit notes. Duplicate detection. Arithmetic that doesn't add up. Each one has the same demo-versus-production gap. Each one needs the same months of grinding.
This is the marginal-value trap. Getting one field to work at 90% is interesting but it is not a product. A customer does not pay for we got GL accounts right most of the time and you still have to check everything else. They pay for invoices that go from arriving to booked without anyone opening them. Every one of the dozen layers has to be reliable, because the weakest one sets the ceiling for how much the customer can trust the output.
This is a bag of tricks, not a model
What runs in production isn't a model. It's an orchestration.
One layer reads the document. Another layer, trained on each customer's own posting history, predicts accounts and cost centers. A third handles VAT with deterministic rules, because VAT is not a place where pretty confident is acceptable. Graph structures route invoices based on supplier relationships. Calibration logic turns noisy confidence numbers into three decisions: post it, suggest it to a human, or escalate.
Each of those layers is a different technique. None of them is optional. Remove one and the system still runs, but invisibly worse. A few more bad postings. A few more escalations that didn't need to escalate. A drift nobody notices until it's three months old.
And the combination that works today isn't the combination that works next year. New model releases change which technique is cheapest for which job. A customer's COA migration breaks assumptions that held for two years. A new VAT directive lands in one country. Every one of these requires the stack to be re-tuned, not replaced.
This is the full-time job. Not building the stack. Keeping it honest against a frontier that won't sit still.
Why this is hard to catch up to
The usual argument against building internally is cost and time. Fine. That's not the interesting part.
The interesting part is surface area. Two or three good engineers can build a credible prototype in six months. LLMs make early progress feel fast. The plateau shows up around month nine, and it's not the kind you fix by hiring a smarter person. You fix it by having seen the same failure mode in forty customers, not one.
A product team inside a software vendor has other priorities. Invoice automation is always their third priority, never their first. That's not a criticism. It's a correct allocation of their time. But it means their stack ages faster than they can keep up with, and the people who notice are the customers who were expecting it to improve.
We process over 1.5 million invoices every month. Our Never Look rate, the share posted with zero human touch, climbs every month in live data visible to every customer on their own dashboard. It climbs because someone is watching it climb and working on the layers that are holding it back. That's the whole trick. There is no trick.
The real question
The question isn't whether you can build invoice automation. You probably can build the demo.
The question is whether it's worth your team's time to push through the eighteen months between the demo and something a customer will actually pay for. For most vertical SaaS companies the answer is no. Not because they couldn't do it, but because their customers aren't buying them for their invoice automation. They're buying them for the accounting platform, the workflow, the vertical depth. Invoice automation is something they tolerate shipping with it.
Nobody churns to a competitor over a better document extractor. But when the automation is quietly the best in the market, customers notice in the places that matter. Retention. Price defensibility.
Frequently asked
What is purchase invoice automation?
Purchase invoice automation is the process of taking an incoming invoice from arrival through to a booked accounting entry without human intervention. At a basic level, OCR and suggestions make a human's job faster. At the Never Look level, the invoice is posted end-to-end without anyone opening it — with escalation only for genuine exceptions.
Why doesn't a generative AI model alone handle invoice processing?
A single LLM can read an invoice and make reasonable guesses about accounts. On a clean sample set it can look very accurate. In production it meets invoices from vendors it has never seen, partial credits, internal codes, and multi-page summaries that don't add up — and accuracy drops sharply. Account prediction is only one of a dozen layers (VAT, cost centers, approval routing, periodisation, duplicates) that all have to work reliably before anyone can call the result automated.
Why can't a software vendor just build this in-house?
They can build a credible prototype in six months. The plateau shows up around month nine. From there it's an eighteen-month grind through failure modes you only see in live customer data — and invoice automation is their third priority, never their first. Meanwhile the frontier keeps moving: new models, COA migrations, VAT directives. The real work is keeping the stack honest, not shipping it once.
How is this different from an LLM wrapper with a good prompt?
An LLM wrapper does one thing — extract and classify — on invoices that fit its training. Never Look is an orchestration of at least a dozen techniques: customer-specific account models, deterministic VAT rules, graph-based supplier routing, calibrated confidence scoring, exception workflows. None of the layers is optional. Remove one and the system still runs, invisibly worse.
Commercial Director, FabricAI — part of Visma Solutions Oy.
See it in practice
Want to see outcome-based automation live?
Book a Partner Fit Workshop and we'll walk you through how we price the outcome — and what it takes to deliver it.