Three hundred supplier invoices land in a distributor's inbox every week. Some are clean PDFs. Some are scans of scans, half in Arabic, half in English, with a VAT line that shifts position depending on which supplier generated the document. Someone has to pull the line items, the quantities, the unit prices, and the VAT, then check all of it against the purchase order before anyone gets paid. That is the kind of task I get handed and asked to automate, and the kind of job that ends up as a standing AI e-mployee on BrianServes, my platform for deploying autonomous AI e-mployees. And it is where I want to walk through a decision I run often, because the interesting part isn't the AI model you pick. It's whether you let one prompt do the whole job or you break the job into steps.
The 300 Invoices and the Decision Nobody Wanted to Make Twice
The obvious move is a single, well-crafted prompt to a vision-capable model: read the invoice image, return the structured line items, quantities, prices, and VAT as clean JSON. It works. Most of the time it works well. The question I actually care about is what happens on the invoices where it doesn't — and whether you'd ever know.
The less obvious move is to split the job into three steps. First, classify the document type, because a scanned handwritten delivery note needs different handling than a clean digital PDF. Second, extract the data using a prompt tuned to that document type rather than one generic prompt trying to cover every case. Third, add an arithmetic validation pass: do the line items plus VAT actually add up to the stated invoice total? That third step doesn't touch the model at all. It's a calculator, not a prompt.
Decomposing a task always costs something — more calls, more latency, more code to maintain. So before I add steps to something that already works, I want a number, not a hunch. This is the shape of the comparison I run to get one.
One Call or Three: The Comparison I Run
To be clear about what follows: these are round, illustrative figures from the kind of test I run on this class of problem at Webspot, my AI strategy firm in Beirut, not an audited result from a named client engagement. I'm using them because the shape of the comparison is the real lesson, and shapes are easier to see with clean numbers.
Take a sample of 40 invoices, a mix of the clean and the messy. Run the single-prompt approach first. It flags 6 of the 40 as low-confidence, which is honest of it — those are the ones it wasn't sure about. But when you actually audit all 40 by hand, 11 of them contain a real extraction error: a wrong unit price, a misread VAT figure, a line item quietly merged with the one above it. That means 5 invoices came back wrong and confident. The model didn't flag them, because from inside a single answer, there's no way to notice that your own arithmetic doesn't hold together.
Now run the three-step version on the same 40. The classification and per-type extraction steps produce roughly the same raw numbers as before, errors included. But the validation pass — the plain arithmetic check — catches 9 of those 11 errors, because a wrong unit price or a misread VAT figure usually breaks the total. The extraction can look plausible line by line and still fail to sum correctly, and that's precisely the kind of mistake a single model call has no mechanism to catch on its own.
On cost: the single call runs around $0.02 per invoice. The three-step version, with its extra classification and extraction calls, runs closer to $0.06. At 300 invoices a week, that's roughly $6 versus $18 — a difference of about $12 a week.
What the Numbers Said, and What They Didn't
Twelve dollars a week is not a serious sum of money for a business processing purchase orders. What it buys is catching 9 of 11 silent errors on documents that feed directly into what gets paid to whom. Framed that way, the decision is not close. But I want to be honest about what the test didn't prove.
It didn't prove that three steps beat one in general. It proved that for this specific task — financial documents, real money on the line, errors that don't announce themselves — the extra step earns its cost. If the task were instead tagging product photos for an internal catalog, where a wrong tag gets noticed and fixed the first time someone looks at the page, I'd keep the single call and skip the ceremony. The value of decomposition isn't fixed. It's a function of what a silent error actually costs you, multiplied by how often it happens, compared against what the extra step costs, multiplied by your volume. Change any of those four numbers and the answer can flip.
That's also why "add a validation step" isn't a universal upgrade. A validation step you never look at, on data where errors are cheap and visible anyway, is pure overhead. The right question isn't whether decomposition helps. It's whether this particular task has the two properties that make it pay for itself: an error that hides well, and a consequence expensive enough that hiding matters.
The Decomposition Rule I Use Now
I've turned that test into five questions I ask before I decide whether a task gets one prompt or several.
- The self-check test. Does the task have some internal consistency you can verify as a separate step — numbers that should sum, dates that should sequence in order, references that should actually exist? If yes, adding that check is close to free value, because you're not asking the model to grade itself.
- The silence test. Does this task fail loudly, in a way someone will obviously notice and fix, or silently, in a way that looks fine and isn't? Loud-failure tasks usually don't need a validation step. Silent-failure tasks need one badly.
- The volume-adjusted cost test. Don't judge a few cents per call in isolation. Multiply the cost difference by your real weekly or monthly volume before you decide the extra step is too expensive to bother with.
- The latency budget test. Does a human need the answer right now, or can this run as a batch overnight? Extra steps only cost you time you don't have when the process is synchronous. In a batch job, three steps and one step finish at roughly the same moment as far as anyone waiting is concerned.
- The escalation-cost test. Build the validation step so it routes to a human only when the check actually fails, not on every single run. Decomposition is supposed to shrink the amount of human review needed, not hand your team a second full-time job checking the AI's work.
None of this is really about which model is smartest, or which prompt is cleverest. Those choices matter, but they're the easy part. The decision that actually determines whether an AI workflow holds up in production is whether you built in a way for it to catch its own mistakes — and whether you did the arithmetic to know if that was worth doing at all. The research points the same way I do: Where LLM Agents Fail and How They can Learn From Failures studies agents "which integrate planning, memory, reflection, and tool-use modules" and finds that those richer architectures make cascading failures more likely, not less — which is exactly why I only add steps when one of them is a step that checks the others.
Written by Brian, Dr. Jonah Tebaa's AI partner, on his behalf.
