The sentence that has killed the most AI projects is not a technical one. It is: where does this show up in the financials? The technical team usually has an answer — higher accuracy, faster responses, happier customers — but none of it is in the finance director's language, and the next phase never gets funded.

The remedy is not to inflate the claim. It is an honest framework that quantifies cost and value before the work starts and measures the same numbers when it ends: one that lets a good project be defended and a bad one be stopped in time.

Real cost: the four layers that get forgotten

• One-off setup: discovery and design, data preparation and cleaning, integration, and testing.
• Running cost per answer: the price of one request times real monthly volume, retries included.
• Human cost: hours reviewing output, user training, and the productivity dip of the first weeks.
• Maintenance: quality monitoring, retraining or switching models, and updates whenever process or data changes.

What a defensible saving looks like

Any value you cannot attach to a financial line carries no weight in a budget meeting. Four kinds are genuinely defensible:

• Freed hours redirected into revenue-generating work or additional delivery capacity.
• Error reduction with a measured rate: less rework, fewer penalties, fewer returns.
• A shorter operating or cash cycle that releases working capital.
• Revenue not lost: a lead answered in time, or a customer who did not churn.

One caveat: freed hours do not appear in profit until they convert into sales or delivery capacity. Unallocated capacity is a saving on paper, not in the accounts.

A calculation sheet with five numbers

• Monthly case volume in the process.
• Current cost per case, based on time spent and a real hourly rate.
• The share of cases the system finishes without human involvement.
• Cost per system answer, including the review that remains.
• One-off setup cost.

The first four give the monthly saving; setup cost divided by that gives the break-even month. If it sits beyond your planning horizon, the project is not ready to run.

The sensitivity test matters more than the headline

Coverage rate cannot be known precisely before implementation, so write the calculation in three scenarios, halving coverage and multiplying setup cost by one and a half in the pessimistic case. If the project still holds there, the decision is easy; if it only works in the optimistic case, it is a high-risk experiment, not an investment.

Without a baseline, ROI is a story

The most common mistake is starting measurement on go-live day; at that point you have nothing to compare against and any improvement is deniable. Before the first line of code, spend two to four weeks recording the status quo: time per case, error rate, cycle time.

How to defend the case to finance

• State value in monthly currency, not in model accuracy percentages.
• Put the full four-layer cost on the table yourself; hiding cost destroys the report's credibility.
• Agree and document the baseline and measurement method before starting.
• Declare the stop condition up front: if the target metric misses the agreed number by the agreed date, the project ends.

Common mistakes in the calculation

• Counting freed hours as cash profit without reassigning that capacity to new work.
• Ignoring running cost per answer, which at high volume exceeds setup cost.
• Attributing the whole improvement to the system when part came from process redesign or seasonality.
• Having no stop criterion, which keeps a fruitless project alive for months.

Frequently asked questions

• What is a reasonable horizon to break even?
  For one defined, high-frequency process, a few months is realistic; if your estimate stretches into years, the scope is too large.
• What about intangibles such as customer satisfaction?
  Report them separately as complementary benefits, but base the decision on measurable numbers.
• If the pilot fails, has the money been wasted?
  Not if it was cheap and short. A pilot that proves a path does not work prevents the large spend that would have followed.

Takeaway

AI projects die more often from lacking a shared language with finance than from technical weakness. A framework that counts cost in full, ties value to a financial line and fixes a stop condition in advance both rescues the good project and ends the bad one sooner. Either outcome is a win.

Glossary

• ROI: the ratio of the gain from an investment to its cost.
• Total cost of ownership: setup, operating, human and maintenance cost across the system's life.
• Break-even: the point at which accumulated savings equal the money spent.
• Baseline: the recorded status quo before the project, used for comparison.
• Stop condition: a pre-agreed numeric criterion whose failure ends the project.