The Automation ROI Math Vendors Show You, Recalculated

The spreadsheet is arithmetically correct and still wrong

Somewhere in the deck there is a slide with a big number on it. Four hundred percent. Six-month payback. Three-point-two million in annual savings. Under it, in a smaller font, is the arithmetic: hours per week, times people, times an hourly rate, times fifty-two, minus the license fee.

Every one of those multiplications is correct. That is what makes the slide hard to argue with in a room. You cannot point at a cell and say the vendor got it wrong, because the vendor did not get it wrong. The model answers the question it was built to answer, which is how much time this process consumes today. It does not answer the question you are being asked to approve, which is how much cash leaves your P&L next year and how much comes back.

Those are different questions, and the distance between them is where most automation business cases go to die. We rebuild these models for buyers before they sign. The recalculated number is almost never zero. It is also almost never the number on the slide.

Here is what moves it.

Saved hours are not recovered hours

The standard model takes the hours a task consumes and treats every one of them as recoverable cash. That holds only when the automation removes a whole role, or a whole shift, and you actually act on it.

Most automation does not work that way. It removes forty minutes a day from eleven people. Those forty minutes do not aggregate into a headcount you can remove or redeploy. They spread back into the day, into the work that was already being crowded out, into a slightly less compressed afternoon. That is a real benefit. It is a morale and quality benefit, and it belongs in the case as one. It is not a line in the labor budget, and presenting it as one is how a CFO learns to stop believing the rest of your numbers.

The test we apply is simple and unpopular: point at the budget line that goes down. If nobody in the room can point at one, the hours are soft, and soft hours get counted separately and conservatively or they do not get counted.

The rate is usually wrong in both directions

Vendor models tend to use a salary-derived hourly rate. That understates the cost of an hour. Bureau of Labor Statistics data for private industry in December 2025 puts benefits at 29.9 percent of total compensation, with wages making up the other 70.1 percent. Average total compensation ran $46.15 per hour, of which $13.79 was benefits. Add equipment, software seats, space and supervision, which the BLS series does not count, and the common planning multiplier lands between 1.25 and 1.4 times base salary.

So the rate should go up. But it should only be applied to the hours that survive the previous section. We routinely see models where the rate is too low and the hour count is too generous, and the two errors are quietly offsetting. That is not conservatism. That is two mistakes shaking hands.

The automation will not run at demo effectiveness

The demo processed a hundred clean records and handled a hundred. Your queue does not look like the demo. It has the vendor whose invoice format changed last quarter, the customer with two account numbers, the scan that came in sideways, the exception that only your longest-tenured person knows how to route.

Practitioners building honest pre-build estimates commonly assume 65 to 75 percent effectiveness on a first automation of a real process, regardless of what the demonstration achieved, and replace that assumption with a measured number as soon as a pilot produces one. The residual is not free either. Every exception still costs a human touch, plus the context switch to pick it up, and exception handling is slower per item than the original work was.

Two effects to price, then. The savings shrink by roughly a quarter to a third. And a new job appears, which is watching the automation, which is the job you did not have before. That job is small. It is not nothing, and it never appears on the slide.

Maintenance is annual and it does not decline

This is the single biggest omission, and it is the one buyers are least prepared for, because software feels like a thing you buy once.

Automations break when the systems around them change. A UI update, a schema change, a new tax rule, a renamed field in your ERP. Industry guidance across RPA implementations converges on 15 to 25 percent of initial development cost per year for maintenance, and vendor support contracts typically run 18 to 25 percent of license fees annually on top of that. Both are recurring. Neither declines as the estate ages. They compound, because year three has you maintaining year one's automation and year two's alongside the new one.

A three-year model with maintenance in it looks materially different from a one-year model without it. Run the case over the life of the thing, not over the honeymoon. If a vendor's model stops at twelve months, that choice is the finding.

The denominator is missing your side of the work

The cost line in a vendor model is the vendor's invoice. Your cost is the invoice plus your people: process mapping, data cleanup, integration, testing, security review, training, and the meetings. We have written separately about what an AI pilot actually costs once those land, and the pattern is consistent enough to plan against. The internal share is frequently comparable to the external quote and it is paid in the time of the people who are already the constraint.

That last part matters more than the dollars. The integration work falls on the two people who understand your systems, and they were fully committed before the project started.

Then multiply by the odds

Every vendor ROI model assumes the project succeeds. None of them are priced as an expected value.

Gartner projects that more than 40 percent of agentic AI projects will be canceled before the end of 2027, citing escalating costs, unclear business value and inadequate risk controls. Take whatever return survives the recalculations above and weight it by a realistic probability that this particular project reaches production and stays there. A 300 percent return at a 55 percent chance of completion is a different investment than a 300 percent return, and it is still frequently a good one. It is just an honest one.

The odds are also not fixed. They move with scope. Bounded, high-volume, repeatable work with a clear input and a clear output pays back fastest and survives most often. Open-ended, judgment-heavy work is where the negative returns concentrate. Which means the most effective thing you can do to your ROI number is usually not to negotiate the price. It is to narrow the scope until the process is one the automation can actually finish.

What the recalculated number is for

Do this honestly and the return usually drops a long way from the slide, and lands somewhere defensible. That is the useful outcome. A business case that survives contact with year two is worth more than a big number that gets quietly retired at the first review, along with some of your credibility.

We are not arguing that automation does not pay. Plenty of it does, and we have argued the other direction too, that some processes should not be automated at all. We are arguing that the model deciding it should be yours. The vendor's model is a marketing asset. It is built to be true, and it is built to be persuasive, and when those two goals compete the second one wins. That is not dishonesty. That is what a sales model is for. Ask any accountant: the numbers always add up, it is just a matter of whose column they land in.

Where this gets genuinely hard is the part a checklist cannot cover. Which saved hours in your organization are actually recoverable. What effectiveness rate is right for your queue and your exception mix. What your maintenance burden looks like given how often your core systems change. Those answers are specific to your systems and your people, and they are the difference between a model that holds and one that flatters. The same is true of the vendor sitting across the table, which is a separate exercise we have covered in how to evaluate an AI vendor when you are not an engineer.

If you have a proposal on your desk with a payback number on it and no independent read on whether it holds, that is what a consult is for. Bring the vendor's model. We will rebuild it with your numbers in it, and tell you what the deal looks like from your side of the table.