The short version
The easy 70% is now largely solved by templates you can install. The expensive 30% — the exceptions — is where the cost sits, and automating it requires encoding your own rules, reaching data that has no API, and deciding what a machine is allowed to approve without a human. Budget accordingly: the work is in the exceptions, not the invoices.
What ships out of the box
Claude for Small Business includes ready-to-run workflows spanning finance and operations — invoice tracking, monthly financial close and margin analysis among them — with connectors to QuickBooks, PayPal, HubSpot, Google Workspace, Microsoft 365 and others. Setup is a matter of connecting the tools you already use and choosing the workflows you want; every task is initiated by you, and you approve the plan before it runs.
For larger finance functions there is a separate set of agent templates covering general ledger reconciliation, month-end close and statement audit, each packaging domain instructions, governed data connectors and subagents for parts of the task.
If your invoice problem is simple — consistent suppliers, clean POs, few exceptions — there is a real chance a template plus a connector gets you most of the way, and you should try that before commissioning anything.
Where the templates stop
Four gaps, and they are the same four in almost every finance function.
Your matching rules are yours
Roughly seventy percent of invoices match cleanly and were never the problem. The cost is in the remainder: the partial delivery, the price variance within tolerance, the credit note that arrives separately, the supplier who invoices per pallet when the PO is per unit. Every business resolves these slightly differently, and those decisions live in the heads of the people doing the work rather than in any document. Extracting them is the actual project.
The awkward system has no API
There is nearly always one. The warehouse system that exports a nightly CSV. The delivery notes scanned to a folder share. The ERP that only a consultant can change. Connectors cover the popular tools; they do not cover the one that matters most in your particular case, and that integration is usually the largest line in the budget.
Approval thresholds are a policy decision
What may a system post without a human? Under £500 with an exact three-way match? Under £5,000? Anything from a supplier on an approved list? This is not a technical question, it is a controls question, and your auditor has views. Getting it wrong in the permissive direction is how automation turns into a finding.
Templating breaks on the long tail
Per-supplier OCR templating is the approach most firms have already tried and abandoned. It works for the top twenty suppliers and fails for the hundred below them — which is precisely where the manual effort is concentrated, because those are the ones with inconsistent layouts. A language-model approach reads the document rather than matching a template, which is the actual change, and it is why the second attempt often works where the first did not.
What does a realistic deployment look like?
Not full automation. A sorting machine:
- Clean matches post automatically within your agreed thresholds.
- Explainable exceptions — partial delivery, known price variance — are resolved with the reasoning shown, and a human approves in seconds rather than investigating for minutes.
- Genuine anomalies route to a person with the three relevant documents already assembled side by side.
The saving is not that nobody looks at invoices. It is that people stop looking at the seventy percent that were always fine, and start each exception with the evidence already gathered.
How long does it take, and what does it cost?
Genuinely variable, and anyone quoting a firm figure before seeing your exception rate and your systems is guessing. The honest sequence is to buy a short, scoped discovery first: someone samples a real month of invoices, measures how many are clean, categorises the exceptions, and tests whether your awkward system can be reached at all. That produces a scope and a price, and occasionally it produces “install the template and stop”, which is the cheapest possible outcome.
What you can size yourself, today, is the prize: count the people-hours currently spent on reconciliation in a month and multiply by twelve. That number sets what the project is worth, and anything quoted well above it should be declined regardless of how good it sounds.
The order that works
- Measure your clean-match rate on one real month. This single number determines everything else.
- Try the ready-made workflow against your actual data before commissioning anything custom.
- Write down how your team resolves the five most common exceptions. This is the specification.
- Prove access to the awkward system early, not late.
- Agree approval thresholds with whoever owns financial controls, before build.
- Run alongside the manual process for a full cycle before anyone's workload changes.
The templates have moved the starting line. They have not moved the finish, because the finish was never about reading invoices — it was about your rules, your systems and your controls.
Do we still need people checking invoices?
Fewer, doing different work. The realistic end state is that nobody reviews the clean matches and everybody’s attention goes to exceptions that arrive pre-assembled — the purchase order, the delivery note and the invoice side by side, with the discrepancy already identified.
That is a genuine reduction in hours and it is not the same as removing the function. Someone still owns supplier relationships, still handles the disputes, and still answers to the auditor. Practices that cut the headcount before proving the exception path is reliable are the ones who end up rebuilding the team six months later.
What about approval limits and segregation of duties?
Decide them before the build with whoever owns financial controls, because retrofitting them is painful and your auditor will ask. The questions are concrete: what value may post without human approval, does that threshold change for a new supplier, who can override a rejection, and is that override logged.
Segregation of duties is the one most often overlooked. If the same system both matches and posts, the control that used to come from two people has quietly disappeared. It can be reinstated — approvals routed to someone who did not raise the purchase order — but only if it was designed in rather than noticed afterwards.
What happens when a supplier changes their invoice layout?
Nothing, and that is the substantive difference from the templating approach most finance teams have already tried and abandoned. A system that reads the document rather than matching fixed coordinates handles a redesigned invoice the way a person does — by understanding what the fields mean.
This matters because layout churn is exactly where the old approach failed, and it failed silently: a template that stopped matching produced blanks or wrong values rather than an error. Whatever you deploy, test it against a genuinely inconsistent sample rather than the twenty tidiest suppliers, or you are measuring the easy case and budgeting for it.