CFOs do not buy “AI transformation.” They buy specific bets with defensible numbers, named owners, and a clear answer to the question “what does this cost me, what does it return, and how do I know if it is working?” The AI business cases that survive finance review look almost identical structurally. The ones that get pushed back also look structurally similar — they fail in the same four places, repeatedly.
Below is the structure we have seen survive finance review at companies from 200-person scale-ups to large enterprises, with the four common mistakes that kill submissions.
The structure that gets approved
Six sections, in this order. Most AI business cases get pushed back because they invert sections 1 and 2, or because they skip section 5 entirely.
1. Problem statement — in business terms
Not “we should use AI for X.” State the business problem as the CFO would: “Customer service handles 40,000 tickets per month; average handle time is 18 minutes; agent capacity is the bottleneck on growth targets; current cost per ticket is £8.” The problem must be quantified in money or capacity, today.
2. Proposed solution — in plain language
One paragraph. What you are building, who uses it, what it does. Resist the urge to explain the architecture here — the CFO is not evaluating the model; they are evaluating whether the business problem in section 1 will be measurably improved.
3. Financial impact — quantified, conservative
The heart of the case. Show three scenarios: conservative, expected, and stretch. For each, name:
- The KPI that will move
- The current baseline value
- The target value
- The financial impact in revenue, cost, or capacity
- How that financial impact is calculated (the formula, with each input named)
Bias the “expected” case toward the conservative side. If the model works as well as the team thinks it will, you outperform the case and gain credibility for the next ask. If you put the optimistic case forward and miss, you do not get the next ask.
4. Investment required — broken out
Total investment over 18 months, broken into:
- Build cost (people, time, vendors)
- Run cost (cloud, GPU, API calls, ongoing managed services)
- Change cost (training, process redesign, communications)
- Contingency (10–20%)
Most AI cases under-budget the run cost. A model that costs £40k to build and £15k a month to operate at scale has a £180k annual run cost that is invisible if you only show the build line. Show both.
5. Risks, dependencies, and what would kill the case
The section finance teams notice most. List the top 5 risks, each with:
- What would happen
- Probability and impact
- The mitigation
- The named owner of the mitigation
Include the killer: “If the model accuracy on production traffic falls below 75% within the first 90 days, we will pause and re-scope.” Naming the kill criterion is the single biggest credibility move in the document. It tells finance that you are not asking for an open cheque — you have a stopping rule.
6. Tracking and decision points
How you will know it is working, and when the next funding decision happens. Specifically:
- The dashboard that will be monitored
- The metric thresholds for go/no-go at each milestone
- The cadence of review (typically monthly to the steering committee, quarterly to finance)
- The point at which the program is declared complete or extended
The four mistakes that kill submissions
Mistake 1 — “Soft” benefits without dollar figures
“Improves customer experience” is not a benefit; it is a hope. The same proposal with “reduces ticket-driven churn by 0.4 percentage points, worth £180k in annualised retained revenue” is.
Every “soft” benefit can be translated into a dollar figure if you chain it through one or two assumptions. The chain has to be defensible, not certain. CFOs do not require certainty — they require traceability.
Mistake 2 — Confusing capacity savings with cash savings
“We will save 12 FTE-equivalents of effort” is not the same as “we will save 12 salaries.” If you will not actually fire 12 people, the savings is capacity, not cash. Capacity is real, but it has to be converted into something the business will do with it — backlog burned down, new work taken on, growth supported without hiring.
Be explicit about which it is. Mixing them up is the most common credibility failure.
Mistake 3 — Build cost without run cost
AI systems have ongoing run costs that often exceed build cost in year 2. Cloud, tokens, GPU, vendor licences, managed services, model drift monitoring, retraining. Without these visible, the business case looks like a one-off investment. It is not.
Mistake 4 — No kill criterion
A business case without a written stopping rule reads to finance as “we have not yet thought about what failure looks like.” Even if you never need to invoke it, having it written down is what separates a serious proposal from an enthusiastic one.
A one-page summary that works
For the final submission, distil to a one-pager finance can scan in 90 seconds. Sections:
- One-sentence problem in business terms
- One-sentence proposed solution
- Investment over 18 months (one number, with conservative range)
- Return over 36 months (one number, with conservative range)
- Payback period (months)
- Single primary KPI with baseline and target
- Top risk with mitigation owner
- Kill criterion in one sentence
- Named accountable executive
The one-pager is what gets your case onto the agenda. The full document is what gets it approved.
AI business cases are not different from any other capital request — they just feel new. The teams that get repeated approvals are the teams that write each case to look exactly like the previous infrastructure or software proposal that finance signed off. Familiar structure, defensible numbers, conservative assumptions, named owners, written stopping rules. The novelty is the technology, not the discipline.