The Problem with Invoice Automation

Every invoice automation demo goes the same way. A clean PDF, a confident extraction, fields populated correctly, a number like 99% accuracy on the slide.

Then the project starts, and within two months someone is manually checking every document anyway.

The demo wasn’t dishonest. Extraction really has got very good. It’s just that extraction was never the part that decided whether these projects work.

What 98% accuracy actually means

Accuracy sounds like a finished answer until you apply it to your own volume.

Say you process 800 supplier invoices a month, averaging 12 line items each. That’s 9,600 line items, each with several fields — description, quantity, unit price, tax, total. Call it five fields per line: 48,000 extracted values a month.

Field-level accuracy	Wrong values per month
95%	2,400
98%	960
99.5%	240
99.9%	48

At 99.5% — better than most systems achieve on mixed real-world documents — you are still producing around 240 incorrect values every month.

The question that decides your project isn’t how small that number gets. It’s what happens to those values. If they flow through silently, you’ve automated the production of errors. If they’re caught, the system works even at 98%.

That reframing is the whole point. Accuracy is a vendor metric. Catch rate is an operational one.

Four things that actually break projects

1. Header-level capture

Most tools extract reliably at the header: supplier, invoice number, date, total. Far fewer extract the body properly — every line, with quantity, unit price, and the freight or duty apportioned to it.

Header data is enough to post an invoice. It is not enough to do anything else. Without line items you cannot do a three-way match, cannot build landed cost, and cannot see that a supplier raised one SKU by 8% while holding the invoice total roughly flat.

Ask any vendor to run one of your own multi-line invoices and show you the line-item output, not the summary. This single test separates the field faster than anything else.

2. Extraction without validation

A value read cleanly from a PDF is not a correct value. It’s a legible one.

Validation means checking extracted data against something you already know:

• Does the line total equal quantity × unit price?
• Does the sum of lines equal the invoice total?
• Does this invoice number already exist for this supplier?
• Is the unit price within its usual range for this SKU?
• Does the quantity match what the goods receipt says arrived?

Each of these catches a different failure. Arithmetic checks catch misread digits. Duplicate checks catch the most expensive error in accounts payable — paying the same invoice twice. Range checks catch the transposition that turns £12.40 into £124.00, which parses perfectly and is wrong by an order of magnitude.

A pipeline without validation isn’t automation. It’s data entry performed by a machine that never gets tired and never notices anything.

3. Exceptions with nowhere to go

Every system produces exceptions. The difference between projects that work and projects that quietly get abandoned is almost always what happens to them.

The failure pattern is consistent: exceptions accumulate in a queue nobody owns. Two weeks later there are 300 of them, working through the backlog is a bigger job than the original manual process was, and someone starts processing invoices by hand again “just for now.”

What works instead is unglamorous. Every exception routed to a named person, not a shared inbox. The document and the reason attached, so resolution doesn’t start with a search. An age on every item, visible. And a review of what’s actually being flagged — because if the same supplier generates exceptions every month, that’s a rule to add, not a task to keep doing.

4. The long tail of formats

The first ten suppliers go well. Suppliers 40 through 60 are where projects stall — the freight forwarder whose invoice is a scanned fax, the supplier whose “invoice” is a spreadsheet attachment, the utility that only issues through a portal.

The mistake is treating this as an extraction problem to be solved with better models. It’s usually a process problem. Some of the tail is genuinely worth automating. Some of it is three invoices a year and should stay manual forever, and saying so explicitly is what keeps a project from stalling in pursuit of complete coverage.

Decide the cut-off deliberately at the start rather than discovering it at month four.

A worked example: the three-way match

The clearest illustration of why line items matter.

You ordered 200 units at £4.20. The goods receipt records 194 received. The invoice arrives for £840.

Header-only capture: invoice total £840, supplier matches, PO number matches. It posts. You’ve paid for six units you never received — £25.20, on this one invoice, invisible.

Line-item capture with validation: the line reads 200 × £4.20. The receipt says 194. The system flags a quantity variance, routes it with both documents attached, and someone raises a credit note.

£25.20 isn’t much. Across 800 invoices a month, with a small percentage carrying some variance, it’s a recurring leak that never appears as a problem because nothing ever looks wrong. That’s the characteristic of this whole category of error — it doesn’t announce itself, it just makes margin slightly worse than it should be, forever.

What to ask before you buy

Five questions. Ask them of any vendor, including us.

1. “Run this invoice and show me the line-item output.” Bring your worst one — the freight invoice with apportioned charges, or the one with 40 lines.
2. “What validation runs after extraction, and can I add my own rules?” If the answer is only about extraction accuracy, that’s the answer.
3. “Show me the exception queue.” Who does an item go to? What’s attached? Can I see how old it is?
4. “What happens to a duplicate invoice?” Duplicate payment is the single most expensive AP error, and it should be caught structurally, not by someone recognising the supplier name.
5. “How do I reprocess last month?” If a mapping was wrong and you need to re-run a period, can it be done without duplicating what’s already posted?

The answers tell you whether you’re buying an extraction tool or a document pipeline. Both are legitimate purchases — just know which one you’re making.

Scoping a pilot that proves something

Don’t start with your whole supplier base. Start with a set that will actually tell you something:

• Your top 10 suppliers by invoice volume. These are where the time goes.
• Two deliberately awkward ones. The scanned freight invoice, the one with apportioned charges. Include the hard cases from the start, because they’re what determines whether this works.
• One month, run in parallel. Keep the manual process running alongside. Compare outputs. The disagreements are the finding.

At the end you’ll know your real catch rate on your real documents, which is the only number worth making a decision on. It will be lower than the demo. That’s expected, and it’s fine — a system catching 96% of your documents with the other 4% properly routed is a working system. A system claiming 99.5% with no exception handling is not.

---

Document Processing extracts at line-item level, validates against your own records, and routes exceptions to named owners. AI Reconciliation is what happens to the data next.

Contact us today to talk through a pilot on your own invoices.