Start by measuring the baseline properly
Almost every automation business case we are shown begins with an estimate that nobody verified. "It takes about ten minutes per invoice" is a guess, and guesses are usually wrong in the optimistic direction because people recall the smooth cases rather than the ones that required three emails to resolve.
Spend a week measuring properly before committing to anything. Track volume, handling time including interruptions and rework, error rate, and — critically — the tail. In most document workflows, 15% of cases consume half the total time. Whether automation handles that tail or escalates it changes the return dramatically.
- Volume per week, measured rather than estimated
- Handling time including interruptions, chasing and rework
- Error rate and the downstream cost of each error
- The tail — how much time the hardest 15% of cases consume
Calculate true cost, not just the build fee
The build fee is the visible number. Three others belong in the model and are routinely omitted, which is why projections so often look excellent on paper and disappointing in practice.
Inference cost scales with volume and is controllable but not zero. Maintenance is genuinely unavoidable — models get deprecated, providers change behaviour, and your documents drift. Budget 15 to 25% of build cost annually. And there is internal time: someone on your side reviews escalations, validates output during the evaluation period, and owns the process. That is real cost even though it never appears on an invoice.
Be honest about the automation rate
The single most common error in automation business cases is assuming 100% automation. Real workflows have exceptions, and a well-designed system escalates rather than guessing. A realistic target for a document workflow is 70 to 85% fully automated, with the remainder routed to a human with the extraction pre-filled.
Model the partial cases explicitly. An escalated case with pre-filled fields still takes meaningfully less time than one processed from scratch, and leaving that saving out understates the return as badly as assuming full automation overstates it.
A worked example
A finance team processes 2,000 invoices a month at a measured 8 minutes each — roughly 267 hours, or about $8,000 monthly at a fully-loaded $30 per hour.
Automation handles 78% end to end. The remaining 22% escalate with fields pre-filled and take 3 minutes rather than 8. New monthly handling time is about 22 hours, or $660. Inference and infrastructure run $400. Amortised maintenance adds roughly $250. Monthly cost after automation is around $1,310 against $8,000 before — a saving of $6,690.
Against a $26,000 build, payback lands just under four months. That is a strong case, and notably it is strong without assuming anyone is made redundant — the freed capacity absorbs backlog that was previously never getting done.
The benefits that do not fit the spreadsheet
Some real returns resist quantification and should be stated as narrative rather than forced into a number. Consistency is the main one: an evaluated system applies the same criteria to case one and case ten thousand, while a rotating team does not.
Speed matters too. Invoice processing that takes hours rather than days changes what the finance team can commit to. Support responses within minutes rather than the next morning change customer perception. Neither shows up cleanly as saved hours, and both are frequently why the project was actually approved.
Frequently asked questions
What payback period should we expect?
Well-scoped automation on genuinely high-volume workflows typically pays back in three to eight months. Anything projecting under two months usually rests on an unrealistic automation rate or an unmeasured baseline. Beyond twelve months, the workflow is probably too low-volume to justify custom automation.
How do we pick which workflow to automate first?
High volume, low variation, clear rules and a tolerable failure mode. Start where being wrong is recoverable rather than with the highest-value process, because the first project is also where your organisation learns how to evaluate and operate these systems.
What if the accuracy is not good enough?
That is what the evaluation period is for — running in parallel with the manual process and comparing outputs before switching anything over. If accuracy does not clear the bar, the threshold is raised so more cases escalate, which reduces the saving but keeps the system safe.
Working on something like this?
We build custom AI development, AI solutions and AI automation for teams shipping to production. A 30-minute call with an engineer, no obligation.
Book a free strategy call
