How to Calculate AI ROI Before You Commit Budget

AI business cases fail in two familiar ways. One multiplies an optimistic hourly rate by optimistic hours and produces a figure nobody in finance believes. The other declines to estimate, and the project goes unfunded or is funded on faith. The method below measures every input on your own operation, counts every running cost and judges the case on its downside, the column a CFO reads first.

• 37%of respondents attribute any EBIT impact to AI, essentially unchanged from 2025¹
• 2 to 4 yrsfor a typical AI use case to reach satisfactory ROI, against 7 to 12 months expected of other technology²
• 1 in 5respondents say AI operating costs, including token costs, have constrained their AI use¹

The AI ROI formula

AI ROI is the net benefit a system produces over a set horizon, minus the cost of building it, divided by everything it cost to build and run. Seven measured inputs feed it, plus the discount rate and horizon that finance already sets.

Inputs, per month unless stated
  V    cases handled                       from the system of record
  C0   fully loaded cost per case today    labor, rework, external spend
  a    automation rate                     share resolved correctly, no human touch
  e    effort per exception                vs today's average case (1.0 = same)
  R    run cost                            inference, hosting, evaluation, sampled review, migration
  G    other hard benefits                 errors avoided, external spend replaced, revenue
  B    one-off build and change cost
  r    monthly discount rate               your annual hurdle rate, converted to monthly
  T    horizon in months

Cost after launch    = R + V × (1 - a) × e × C0
Net benefit  N       = V × C0 - cost after launch + G
Payback (months)     = B ÷ N               with a ramp: first month cumulative N exceeds B
NPV                  = -B + Σ (t = 1..T) N_t ÷ (1 + r)^t
ROI over horizon     = (Σ N_t - B) ÷ (B + Σ R_t)

Step 1: Measure the baseline from systems of record

The baseline is today's fully loaded cost per case multiplied by volume, taken from the systems that already record the work. Pull volume from the ticketing, case management or ERP system over a full business cycle, so month-end and seasonal peaks are included. Take handling time from system timestamps, using time studies only where none exist, and the error and rework rate from QA samples, reopened tickets, credit notes or journal corrections. Add external spend on the same work: outsourced processing, agency fees and contractor hours.

Load the labor rate properly. In US private industry, benefits made up 30.0% of employer compensation costs in June 2026, so an hour of a person's time costs roughly the wage divided by 0.70, before any overhead for space, systems and supervision.³ Use your own payroll figures where finance has them. A bare wage rate leaves out at least 30% of what the hour costs.

Loaded hourly cost  = hourly wage ÷ wage share of compensation + overhead per hour
C0                  = handling hours × loaded hourly cost
                    + rework rate × rework hours × loaded hourly cost
                    + external spend per case
Baseline per month  = V × C0

Name the system and date range behind every line, so finance can audit the baseline and every report after launch can be compared with it.

Step 2: Set the automation rate from your own graded cases

The automation rate is the share of cases the system resolves correctly, end to end, with no human touch, measured on your own historical cases. Pull a few hundred real cases, stratified by case type and including the awkward ones, and have your best people record the correct outcome for each. Run a prototype against that graded set before the full build is approved, then in shadow mode on live traffic, and sort every case into three buckets: resolved correctly, resolved after a human edit, and handed to a person. Weight each case type's rate by its share of volume to get a.

Resolution and containment are different measures. Resolution is the customer's problem solved, judged by the QA standard your people are held to. Containment is a conversation that ended without a handoff, which many product dashboards report; a contained case that returns tomorrow as a complaint counts as a success there and a failure on your ledger. Vendor figures describe someone else's case mix and belong nowhere in your model.

Published evidence argues for caution. In Stanford's 2026 AI Index, agents' success on OSWorld, a benchmark of real computer tasks, rose from 12% to about 66%, and agents still failed roughly one attempt in three on structured benchmarks.⁴ Executives told Deloitte that proofs of concept on dummy data breed optimism, and problems surface once real data arrives.²

Step 3: Count the full cost to build and run

The full cost is the one-off build plus every recurring line needed to keep the system accurate, and the recurring lines are where business cases go wrong.

Inference needs its own estimate, because its unit price and its bill move in opposite directions. Stanford's 2025 AI Index found the inference cost of a system performing at a fixed benchmark level fell more than 280-fold between November 2022 and October 2024.⁵ Yet about one in five respondents to McKinsey's 2026 survey said AI operating costs, including token costs, had constrained their AI use.¹ Agents make several model calls per case, retry and carry long context, so tokens per case can outgrow the fall in price. Estimate inference per case from shadow-mode traces, never from a price sheet; our guide to governing AI inference spend covers the controls.

Model migration is a certain cost that most cases leave out. One major cloud's published lifecycle policy gives most hosted models six months' notice before retirement and some only 45 days; after the end-of-life date, requests to the model fail, and migration does not happen automatically.⁶ Each forced migration means re-running the graded set, reworking prompts and re-approving the release, so budget at least one inside any horizon longer than a year. The build figure has its own drivers, covered in what drives AI agent development cost.

Step 4: Value the benefits beyond labor

Benefits beyond labor often decide the case, and each needs its own measured formula. Only hard benefits, the ones that change a budget line, belong in the base case; soft and strategic benefits go in the upside column.

• Labor. Hours returned count as savings only where a budget line moves: overtime, contractors, outsourced processing, or hires avoided as volume grows. Hours freed inside a salaried team are capacity until someone decides what it is for.
• Errors. Errors avoided per month × cost per error, where cost per error is the rework, credit notes, write-offs and penalties your ledger already records.
• Speed. Cycle time converted to cash: early-payment discounts, lower days sales outstanding, quotes answered while the buyer is still deciding.
• Revenue. Conversion or retention lift measured against a holdout group the system does not touch. Assumed lift belongs in the upside column.
• Risk. Expected loss avoided, as probability × impact, for fraud, compliance findings or missed deadlines, net of the new risks the system introduces.
• External spend. Outsourced processing and agency fees the system replaces, where MIT NANDA documented some of the largest back-office savings, without material cuts to internal staff.⁷

The organizations that report material returns treat this step as a redesign of the work. McKinsey's AI high performers, about 6% of respondents, attribute at least 5% of EBIT to AI; they pursue growth alongside efficiency, and nearly three-quarters of them have fundamentally redesigned workflows because of AI, against one-quarter of everyone else.¹ A system inserted into an unchanged process returns hours; a redesigned process returns money.

Step 5: Compute payback and NPV

Payback is the build and change cost divided by the monthly net benefit, counted from the month benefits start; NPV discounts each month's net benefit at your hurdle rate and subtracts the build. Payback tells a CFO how long capital is at risk, and NPV whether the project beats the next use of the money.

Model a ramp, because benefits start after the build and grow as autonomy widens. Use the discount rate finance applies to other capital projects. Cap the horizon at three years, since the model, the prompts and the process will have changed by then, and treat anything later as upside.

Deloitte's 2025 survey of 1,854 executives found most respondents reach satisfactory ROI on a typical AI use case in two to four years, against the seven to 12 months expected of other technology investments, and only 6% reported payback inside a year.² Narrow processes pay back faster: in a Gartner survey of 160 senior finance leaders in early 2026, data extraction, payables and receivables automation, and report creation generally delivered returns within nine to 10 months.⁸ A focused process with a measured baseline should sit with the second group. A case that needs three years to pay back is a transformation program and should be argued as one.

Step 6: Run base, downside and upside cases

Run the same model three times with the same variables, changing only their values, and fund the project on the downside column. The table uses hypothetical round numbers on an index where today's process costs 100 a month; B stands for your own build and change cost.

Read the downside column first. With automation 20 points below the graded result, exceptions 10% harder, running cost up by half, no benefit beyond labor and the build 50% over, this case takes three times as long to pay back. A base case that repays its build in eight months has a 24-month downside, which a CFO can fund. A base case that needs 18 months has a downside of four and a half years; narrow the scope to the case types with the highest graded rates before funding it.

One more figure tells the sponsor how much room there is: the break-even automation rate, the value of a at which the project just pays back inside your target period P.

Break-even automation rate
  a* = 1 - (V × C0 - R + G - B ÷ P) ÷ (V × e × C0)

Compare a* with the rate your graded cases showed; the gap is the margin of safety. A case whose graded rate sits 30 points above break-even can absorb a disappointing launch, and one sitting five points above cannot. Where no graded evidence exists yet, apply a harsher test: halve the automation rate, double the build cost and add 50% to the run cost. If the project still pays back inside two years, optimistic assumptions are not carrying the argument.

How to calculate cost per outcome

Cost per outcome is the all-in monthly cost of the process after launch divided by the cases it resolved, and it is the one figure to set beside today's cost per case in every report.

Cost per resolved case, all-in   = (R + V × (1 - a) × e × C0 + B ÷ T) ÷ V
AI run cost per case it resolved = R ÷ (a × V)

The second line catches what cost per token hides. Inference spent on cases that end with a person still has to be paid for, so it lands on the cases the system did resolve. When the automation rate slips, AI cost per resolved case rises even if the token price falls. Put both lines on the monthly dashboard: the first tells finance whether the process got cheaper, the second tells engineering where the run cost goes.

What the research says about AI ROI, and why the studies disagree

The major studies agree that most organizations cannot yet show a financial return from AI, and they disagree on how many because each one measures a different thing.

Three differences explain the spread. The unit: MIT counted organizations, IBM initiatives, Deloitte a typical use case. The bar: MIT required measurable P&L impact six months after a pilot, while McKinsey counts any EBIT impact a respondent attributes to AI. The scope: MIT studied enterprise generative AI tools, and the other surveys cover AI broadly. MIT's authors flag their own limits: a self-selected sample, success definitions that varied, and a six-month window that may understate success for complex systems.⁷ McKinsey's figures are respondents' own attributions.¹

Read together, the studies support two conclusions. The base rate is poor, and 64% of the CEOs IBM surveyed said the risk of falling behind drives some technology investment before its value is clear, so the burden of proof sits on your own measured inputs.⁹ And returns concentrate where a specific process was measured before and after: back-office work in MIT's data, finance automation in Gartner's, and redesigned workflows among McKinsey's high performers.⁷⁸¹

Build, buy or wait: run the same model on each path

Decide between building, buying and waiting by running the identical model three times, changing only the inputs each path actually moves, and choosing the path with the best downside NPV.

The evidence on building against buying points both ways. In MIT NANDA's interview sample, tools bought from or co-developed with external partners reached deployment about 67% of the time, against about 33% for internal builds, and the authors caution that the gap may reflect the organizations more than the approach.⁷ McKinsey's 2026 survey found 32% of respondents had decided against buying at least one software product or feature because they could build it internally with agentic coding tools.¹ Neither figure settles your decision; the model, run on your numbers for each path, does.

How to report AI ROI after launch

Report the same variables the business case used, measured the same way, every month, against a holdout of cases the system does not touch. Executives interviewed by Deloitte said AI usually arrives alongside data clean-ups, reorganizations and process changes, and one could produce only a ballpark estimate because AI's gains were hard to separate from those programs.² A random slice of cases handled the old way moves with everything else, so the difference belongs to the system.

Agree the review trigger before launch: if the live automation rate sits below the downside assumption for two consecutive months, the sponsor and finance narrow the scope, fix the exception path or stop. A project that can be stopped on evidence is far easier to fund.

In the systems we build, the graded case set and the baseline come before the architecture, because together they decide whether the build should happen at all, and once it does they become the evaluation suite and the ROI dashboard. That is where our AI development work starts.