Automation business cases fail in finance review for a predictable reason: they are built on benefits that cannot be observed on a financial statement. "Improved employee experience." "Faster access to information." "Better decision-making." These may all be real, but a CFO cannot book them, and a program funded on unbookable benefits is a program one budget cycle away from cancellation.
The alternative is not more optimistic math. It is a narrower, harder set of measures — established before the automation is built, and reported against after it ships.
The four measures that survive scrutiny
1. Fully loaded cost per transaction
Take the process's total labor cost — salaries, benefits, allocated overhead — and divide by transaction volume. An invoice processed, an application reviewed, a ticket resolved. This is the anchor metric because it converts directly to dollars and because it is auditable: every input comes from systems finance already trusts.
2. Cycle time
Elapsed time from intake to completion, measured at the median and the 90th percentile — not the average, which hides the long tail where most customer pain and working-capital cost lives. Cycle-time gains convert to financial benefits differently by process: faster invoicing is working capital; faster onboarding is revenue pulled forward; faster service resolution is retention.
3. Error and rework rate
The percentage of transactions requiring correction, escalation, or repetition. Rework is the most underpriced cost in most operations because it is invisible in headcount planning — the same people do the work twice, and the second pass is booked as ordinary labor.
4. Volume capacity per FTE
Transactions handled per full-time equivalent. This is the honest framing of the headcount question. Most mid-market automation does not eliminate roles; it absorbs growth without new hires. "We grew volume 40% with flat headcount" is a stronger and more defensible claim than a speculative reduction that never materializes.
A benefit that cannot be measured against a baseline is not a benefit. It is a hope with a budget attached.
Building the case: the 90-day baseline
The discipline that separates fundable programs from stalled ones is the baseline period. Before building anything, instrument the current process for ninety days — or reconstruct ninety days from system logs, which is usually possible. Record volumes, cycle times, error rates, and the labor allocation. The baseline does three things:
- It forces process clarity — you cannot measure a process you cannot describe.
- It sets the denominator for every ROI claim you will ever make about the program.
- It frequently reveals that the right first target is a different process than the one leadership assumed.
Reporting after deployment
Report the same four measures, from the same sources, on the same cadence — monthly, to the same finance audience that approved the case. Include the costs honestly: software, implementation, and the internal time spent on exceptions and oversight. A program that shows a 2.5× return with honest accounting builds the credibility to fund the next three programs. A program that claims 10× with soft benefits gets one budget cycle of applause and then a quiet cancellation.
A note on payback expectations
Across our engagements, well-selected automation targets in finance and operations typically reach payback within six to twelve months, with document-intensive workflows at the faster end. Anything promising payback in weeks should be treated with suspicion; anything requiring more than two years should be resequenced behind nearer-term wins that can fund it.