An AI ROI formula that survives the finance review

Why most AI ROI numbers fail review

Finance teams have learnt to distrust AI ROI figures, and they are right to. The usual number is built from a vendor's productivity claim multiplied by headcount, with no baseline, no measurement after launch and no cost beyond the licence. It is a projection, and projections are not returns.

A number survives review when every term in it has a source, the baseline was measured before the system existed, the costs include people and operation, and the gains are the kind that show up in a ledger. That is a higher bar than most AI reporting clears, and it is entirely achievable if you set it up before launch rather than reconstruct it after.

The formula

The formula is the standard one. What makes it survive review is the discipline around each term: gains are measured against a baseline, costs include everything, and the period is stated. Report ROI over a defined window, typically twelve months from launch, and show payback period alongside it.

Baseline before launch

The single most valuable hour in an AI project is the one spent measuring the current state before anything is built. How long does the task take? How many are done per week? What is the error rate and what does an error cost? What is the backlog? What does the team cost per hour, fully loaded?

Measure the same things the same way after launch and the gain is a subtraction rather than an argument. Discovery in our AI project roadmap exists partly to force this. If the baseline genuinely cannot be measured, that is a signal about the project rather than a reason to skip the step.

Three kinds of gain that count

Time redeployed. Hours saved per task, multiplied by tasks, multiplied by loaded hourly cost, but only where the hours become something: overtime not paid, contractors not hired, backlog cleared, capacity moved to revenue work. State which. "Saves each agent an hour a day" is a claim about capacity; what the organisation did with the capacity is the gain.

Revenue or conversion lift. More deals, higher conversion, better retention, faster cycle. These need a controlled comparison, because many things move revenue at once. A team or segment that uses the system against one that does not, over the same period, is the minimum. Your analytics setup must be able to tell them apart.

Errors and risk reduced. Fewer mistakes with a known cost, fewer incidents, lower fraud losses, as in fraud and anomaly detection. Record the baseline rate, the new rate and the cost per event. Avoid valuing hypothetical disasters.

Count every cost

Build includes your people's time, partners, data preparation and the evaluation set. Run includes tokens or hosting, retrieval infrastructure, monitoring and ongoing maintenance, as broken down in the cost of LLM applications. Change includes training, process redesign and the productivity dip during rollout. The last is the one most often omitted, and the one finance will ask about first.

Leading and lagging metrics by use case

ROI is a lagging metric; it arrives months after launch. Leading metrics tell you early whether it is coming. Track both, and name the source for each.

The leading metrics are also your evaluation signals in production. If they move the wrong way, the lagging metrics will follow, and you have time to act.

Attribution pitfalls

An illustrative example

Illustrative scenario with hypothetical numbers. A finance team processes supplier invoices. Baseline, measured over four weeks before launch: 12 minutes per invoice, 2,000 invoices a month, a 4% error rate, each error costing about an hour to resolve. Loaded cost of the team: 40 currency units per hour.

After an invoice processing system goes live, measured over the following quarter: 4 minutes per invoice of human handling, the same 2,000 invoices, a 1.5% error rate. Time per month falls from 400 hours to roughly 133, and error resolution from 80 hours to 30. That is about 317 hours a month, worth about 12,700 units at the loaded rate, and the team confirms the capacity was used to bring month-end close forward and defer a planned hire. Over twelve months the measured gain is about 152,000 units.

Costs over the same twelve months: build 60,000 units including the evaluation set, run 18,000 units for tokens, hosting and monitoring, change 10,000 units for training and the rollout dip. Total 88,000. ROI over year one: (152,000 − 88,000) ÷ 88,000, about 73%, with payback in roughly seven months. Every figure has a source, the baseline predates the system, and the capacity claim is backed by a decision the team made. That is a number finance can check.

A reporting cadence

Report leading metrics monthly from launch, lagging metrics quarterly, and a full ROI calculation at six and twelve months with the assumptions written out. Use the same format every time so trends are visible. For the board, one page: the baseline, the measurement, the gain, the cost, the ROI, and what you are unsure about. Our guide to the AI CTO's first 90 days shows where this sits in the wider reporting rhythm, and the LLM cost calculator helps keep the run-cost term current.

What matters most

• ROI = (gains − costs) ÷ costs, over a stated period, with every term sourced.
• Measure the baseline before launch; it turns the gain into a subtraction.
• Count only time that was redeployed or removed from cost, and say which.
• Use a control group for revenue claims; too much else moves revenue.
• Include build, run and change costs; change is the one finance asks about.
• Track leading metrics monthly so you know the lagging ones are coming.
• Report in the same one-page format every time, including what you are unsure about.

Related services