A supplier invoice lands in the inbox. The amount matches the quote. The layout is the one your team has cleared a hundred times. Someone on the accounts-payable desk waves it through, and the money goes to a bank account that is off by a single character.
Carelessness doesn’t explain it. Nobody put the invoice’s account number next to the one you have on file. That kind of checking is the whole job of building an analysis agent that works.
Everyone wants the demo version of this: point an AI at the invoices, let it read, let it decide. The useful version is quieter and more honest. It is an agent that reviews each incoming invoice against the contract and the last few months of history, then flags what a human should look at. It does not approve payments. That single boundary is the design, not a limitation to apologise for.
The desk you already run
Pick the job before you pick the technology.
Every mid-sized company already runs an invoice-review desk, by hand, today. A person opens each supplier invoice and asks a short list of questions. Is this a duplicate of one you have already paid? Has the price drifted above the rate you agreed in the contract? Is there a purchase order to match it against? Is the VAT treatment right, and is the bank account the one you have on file?
This is genuine analysis, not a macro. A rules engine can catch an exact-duplicate invoice number. It cannot read a scanned contract, hold last quarter’s pattern in mind, and judge that a nine-percent price rise on one line is worth a second look while a rounding difference is not. That judgement is the reason an agent fits here, and it is also the reason an agent can fail here. The task is legible to a leader (the cost of a mistake is money, not abstraction) and forgiving of one (a flag is cheap; a wrong payment is not).
Think of the agent as a capable new hire on that desk. Fast, tireless, and occasionally confidently wrong. You wouldn’t give a new hire signing authority on day one. You would have them read each invoice, mark the ones that look off, and bring those to someone who can approve them. Hold that picture: it is the whole architecture, and I will build it out from there.
What the agent is actually made of
Strip away the branding and an analysis agent is a small number of parts.
At the centre sits what Anthropic’s engineering write-up calls an augmented model: a language model with tools, retrieval, and memory bolted on (Building Effective Agents, vendor-primary, so take the anatomy and leave the endorsement). For this desk, the tools are the lookups into the ERP and the purchase-order system. The retrieval is the contract and the last few months of invoices. The memory is what the agent carries from one step of its own reasoning to the next.
Around that core runs a loop. The agent reads the invoice and extracts the fields. It plans what to compare. It acts by calling the lookups and running the three-way match (invoice against purchase order against goods received). Then it checks whether the numbers reconcile and how confident it is. The same write-up puts it plainly: an agent is a model “using tools based on environmental feedback in a loop,” and each tool result is a piece of ground truth it can measure its own progress against.
The practitioners who build research agents add four things to that loop when the work gets harder: a detailed brief, a planning step, sub-agents, and a scratchpad the agent can write to (LangChain, “Deep Agents”). For invoice triage you rarely need all four. Start with the loop, and add complexity only where it earns its place.
The part most people skip is the way out. Before anything leaves the agent, it passes a verification gate. High confidence and every check passed: clear it, no human needed. Low confidence or a failed check: route it to a person, with the evidence attached. That gate is what turns a clever reader into a colleague you can trust with the desk.
The four parts a leader needs to see: what the agent can look at, the loop it reasons in, the gate that decides, and the two ways an invoice can leave. Everything hard about this build lives at the gate.
That anatomy is the easy half. The half that earns your trust is what happens when a part of it quietly gives way.
Start with what can actually go wrong
An analysis agent does not fail the way software usually fails. It rarely crashes. It hands you a confident, well-formatted answer that happens to be wrong, and it does so in a few specific ways worth naming.
Start with silent-wrong extraction. On the exact task of reading invoices, a benchmark from the German research institute Fraunhofer IAIS (arXiv 2509.04469, a preprint rather than a peer-reviewed paper, and its roster of GPT-5, Gemini 2.5 and Gemma 3 is already a model generation old as of July 2026) put its best model at roughly 96.5% field accuracy on clean digital invoices, around 92% on scans, and about 87% on noisy scanned receipts. Newer models have probably pushed that ceiling up a point or two, though nobody has re-run the full clean-to-noisy spread with the same rigour. Read the shape, not the decimal. A genuinely good model still misses a real share of the fields it reads, and it misses more as the paperwork gets messier.
The average is the wrong number to watch anyway. The same study found the bank account (the IBAN) extracted noticeably worse than every other field: the model confuses characters that look alike and hands back a plausible, wrong account with full confidence. That is a property of the field rather than a quirk of one model generation. Any value that runs long, mixes letters and digits, and carries no internal redundancy to check itself against is exposed the same way, whatever is reading it. That is the mis-paid invoice from the opening, and the error stays invisible unless something checks the number.
Then there is compounding error. A model can reason flawlessly through one step and still come apart over a chain of them. A large 2026 study across thousands of agent runs found that systems strong on short and mid-length tasks “often break down on long-horizon tasks,” and that the failures are dominated by the agent no longer verifying whether the world is still what it assumed (HORIZON, arXiv 2604.11978). Applied here: an agent asked to close a whole month in one pass will drift. An agent asked to review one invoice has nowhere to drift to.
The third failure makes leaders nervous, and it should. When one of these agents gets an answer wrong, you can usually see that it failed. You often can’t see where. Locating the exact step that broke is hard enough that researchers built a dedicated method for it, which improves the accuracy of finding the first faulty step by up to 30 points on their own benchmark (a figure the method’s authors report on a test they designed, so treat it as evidence the gap is real, not as a product spec) (span-level error localisation, HF 2606.02060). If a specialist paper needs new tooling to find the broken step, your agent won’t volunteer it either.
Last, over-trust. An agent that treats a corrupted lookup or a stale contract as ground truth will reason perfectly from a false premise. A cluster of 2026 reliability benchmarks points the same way: agents hold up on clean single-turn tests and degrade under chained, real-world conditions. Take that as the shape of a literature I have read rather than re-verified number by number. None of this is a reason to avoid building. It is the reason to build the gate first.
Every named failure has a cheap, dull fix on the right. Not one of them is “trust the model more.”
Making it boring on purpose
Notice what the mitigations have in common. They are boring, they are cheap, and not one of them asks the model to be better than it is. That is praise.
The discipline behind them is not new, and I won’t re-teach it here: earlier pieces in this series (why good agents look nothing like good demos, and what to hand an agent and what to keep in your own hands) make the case that you own the loop, not the model. What the invoice desk adds is a worked example of owning it.
Give the agent a confidence score and a line it may not cross. Above the line, it clears the routine invoices. Below it, a person reviews, and the person’s decision teaches you where the line should sit. Pair that with a check the model cannot talk its way past: a three-way match, and a check-digit test on the IBAN, are deterministic. They either pass or they do not, and the agent’s confidence has no vote.
Others land in the same place. Practitioner write-ups on these OCR-and-LLM invoice pipelines keep re-deriving the rule from scratch: a model’s self-reported confidence is poorly calibrated, so the safeguard is a deterministic invariant (net plus VAT equals gross; an IBAN checksum), not a more capable model. That is a pattern across trade write-ups rather than a controlled finding. But a conclusion that keeps being re-derived on each new model generation carries more weight than any single benchmark number.
Then make the agent show its work. For every flag, it records the claim, the evidence it used, and the check it ran. This is the fix for “you can’t see where it broke.” You are not asking the model to be more reliable; you are making the agent’s reasoning legible enough that a human catches the break cheaply. An analysis agent that works is not one that never errs. It is one that shows its work.
One more discipline, learned the boring way. In the invoice benchmark, converting each document to clean text first (the obvious, sensible pipeline choice) halved accuracy on noisy documents, roughly 47% against 87%, because the tidy-up step, not the model, became the bottleneck (Fraunhofer IAIS again). The lesson generalises past invoices. Test the plumbing you assumed was safe.
Then run the agent in parallel with your existing manual process before you trust it: same invoices, both paths, compared, until the exceptions are rare enough that a human reviews only those. In my line of work with regulated firms, that parallel run is where trust is actually earned, not in the pitch deck.
Which leaves the question a leader actually has to answer.
Build, buy, or commission
You don’t have to build any of this yourself. For a standard document-processing task at modest volume, the fastest route to value is usually to buy: an established invoice-processing tool will do the reading and matching, and you spend your effort on the confidence line and the exceptions. The market has largely voted this way. Roughly 76% of enterprise AI use cases are now bought rather than built, a reversal from a near-even split the year before (a Menlo Ventures figure, reached here through the industry press rather than the original report; enterprise and US-weighted, so read it as direction rather than as a mid-sized European sample).
Building in-house earns its place in narrower cases. When the analysis is a genuine competitive edge, when no vendor fits your constraints, or when the data cannot leave your walls under the EU AI Act and GDPR, an off-the-shelf tool stops being the obvious answer. Be honest about the cost, though. The expensive part of a built agent is not the launch; it is the maintenance and integration that land afterwards, the plumbing you didn’t price in. One illustrative estimate puts the crossover where building starts to beat buying at around a million agent interactions a year (unaudited arithmetic, useful as the shape of a curve rather than a threshold to bank on). Below that, the case for buying is strong.
Between the two sits the option this practice exists to name. You can commission a scoped build you own: the judgement of a fractional CAIO to design the agent, set the gate, and hand you an asset your team runs, without a permanent AI hire on the payroll. It is the middle path for the common situation where the task needs real judgement, no vendor fits exactly, and there is no in-house AI team yet. I will disclose the obvious: that is the argument evonomics is positioned to make, so weigh it as a considered view rather than a neutral finding. The point holds regardless of who does the work.
The honest cost read under each leaf: buy is fast and rented; build is slow and yours, with most of the cost arriving after launch; commission is scoped and yours. The volume crossover is a footnote, not the decision.
What “done” actually looks like
Go back to the invoice that went to the wrong account. The failure was never the mistake itself; tired people make mistakes on a Friday afternoon, and models make them too. The failure was that the mistake was silent, and nobody had built anything to catch it.
So a finished analysis agent promises you legible errors: a flag, with the evidence, at a human’s desk, before the money moves. That is the unglamorous version, the one that stops at the gate and shows its work. Build it on one desk you already understand, and run it beside the humans until it has earned the confidence line you gave it.
You already know how to make this call. Every capable new hire gets the reading on day one and the signing authority later. What they flag in between is the evidence that decides when.
