How to Write an AI Business Case Your CFO Will Actually Approve

The deck had forty slides. It covered the AI landscape, three use cases, a vendor comparison, and an accuracy benchmark that showed 87% improvement over the baseline. The CFO asked one question — what happens if it doesn't work — and nobody had a good answer. The program was deferred for another quarter.

I have sat through enough of these presentations to know that the problem is rarely the ROI. The ROI is usually there. The problem is that the business case was written in the wrong language — the language of model performance and strategic positioning rather than the language a CFO actually thinks in, which is the language of dollars, timing, risk, and accountability.

These are not the same language. And the translation between them is not obvious to people who spend their days thinking about accuracy metrics and use case roadmaps. This article is that translation.

What a CFO is actually evaluating

A CFO approving a capital allocation decision — which is what an AI program is — is working through a mental model that has almost nothing to do with how the technology works. They are asking four questions, usually not out loud:

How much will this actually cost, including everything? When does the first dollar of value land, and how confident is that estimate? What is the cost if this fails partway through? And who is accountable if the milestones aren't met?

A business case that answers all four of those questions clearly, with honest numbers, will get more traction than a forty-slide deck that demonstrates deep technical literacy but leaves those questions unanswered.

The corollary is equally important: a CFO who doesn't trust the numbers in a business case will defer it regardless of how compelling the use case is. Their job is to allocate capital responsibly. If the cost estimate looks incomplete, if the value timeline looks optimistic, if the failure scenario isn't addressed — the right move from their perspective is to ask for more work before approving. And they will.

The four numbers that have to be in the document

Total cost, including implementation. The most common mistake in AI business cases at financial institutions is a cost estimate that covers the model or vendor license and nothing else. The integration work — building the data pipelines, connecting to production systems, handling authentication and logging, establishing the infrastructure needed to run and monitor the system — typically costs three to five times what the model itself costs. MRM validation, legal review, change management, and training add more on top of that.

A business case that shows a $300,000 vendor license and nothing else is not a budget — it is the first line of a budget. A CFO who has been through a few technology programs knows this, which means an incomplete cost estimate signals either naivety or deliberate optimism. Neither builds confidence. Put the full number in the document, with a clear breakdown of what it includes.

When the first dollar of value lands. Not "within the program horizon." Not "once fully deployed." A specific date, or a specific milestone tied to a date, with a credible basis for the estimate. This matters because the time between spending and benefit is the core financial risk of any program. A CFO who is used to thinking about payback periods and NPV will be skeptical of any business case that describes value in the future tense without anchoring it to a timeline.

If the honest answer is that value lands eighteen months after approval, say that. A credible eighteen-month timeline is better than a vague "near-term" that turns into thirty months. The CFO will respect the honesty more than they will enjoy being surprised.

What the exit cost is if this fails partway through. This is the question that killed the presentation in the opening paragraph, and it kills a lot of AI business cases. The team presenting had thought about success and hadn't thought about failure. A CFO thinks about both in parallel, because their job is to know what they are committing to before they commit.

The exit cost is what the institution is out if the program reaches month six, produces unsatisfactory results, and is terminated. It includes sunk costs, contractual obligations, and the cost of unwinding whatever integration work has been done. It is not the same as the total program cost. It is the downside scenario. Put it in the document. If it is bounded — if there are specific go/no-go checkpoints where the institution can exit at known cost — say so explicitly. That structure is much easier to approve than an open-ended commitment.

Who is accountable for each milestone. A business case with a timeline but no named owners is a wishlist. A CFO approving a program needs to know who will be standing in front of them if a milestone is missed. Not "the AI team." A person, with a title, who has accepted responsibility for the deliverable. This is also a signal about whether the program has genuine organizational sponsorship or is a project in search of a home.

What not to put in the business case

The things that appear in most AI business cases but do not help approval are worth naming directly, because they consume space and attention that should go to the four numbers above.

Accuracy metrics without dollar translation. "87% accuracy" means nothing to a CFO without a denominator. 87% accuracy on what decision, affecting what dollar volume, producing what reduction in error cost compared to the current state? The metric is a means to an end. The end — the dollar value of the improvement — is what belongs in the business case.

Strategic positioning language. Phrases like "position the bank as an AI leader," "build competitive differentiation," or "establish a foundation for future AI capabilities" are not wrong exactly, but they are unfalsifiable. A CFO cannot evaluate a positioning claim the way they can evaluate a cost or a timeline. These phrases are often used to justify programs whose financial return is uncertain, and experienced CFOs recognize them as such. If there is a real financial return, quantify it. If there isn't, be honest about that rather than substituting strategy language for numbers.

Timelines that assume everything goes right. An AI program timeline that has no float, no risk milestones, and no acknowledged dependencies on external parties — MRM approval, IT security review, vendor delivery — is not a plan. It is an optimistic projection. The CFO will add contingency mentally, which means they will mentally extend your timeline and mentally increase your cost. You are better off building that contingency in explicitly, with honest rationale, than letting the CFO do it for you with a more pessimistic assumption than you would have used.

Handling uncertainty honestly

One of the most counterintuitive things I've observed in executive presentations is that honest acknowledgment of uncertainty often builds more confidence than projections that look certain. A CFO who has been in finance for twenty years knows that AI program cost estimates are uncertain. They know that timelines slip. They know that value realization takes longer than the deck says. When a business case pretends otherwise, it does not reassure them — it signals that the team hasn't thought carefully about the risks.

A better approach is to present a range. A base case with specific assumptions clearly stated. A conservative case with the assumption that integration takes longer and MRM validation requires an extra cycle. A go/no-go checkpoint at month three that limits downside if the conservative case materializes. This structure does three things: it demonstrates that the team has thought about failure, it gives the CFO a framework for evaluating risk, and it creates a bounded commitment rather than an open-ended one.

Bounded commitments are much easier to approve. A CFO who is asked to approve a $1.2 million program with a go/no-go at month four and a clear exit cost of $180,000 is making a different decision than a CFO asked to approve a $1.2 million program with no checkpoints. The expected value may be the same. The risk profile is completely different.

The one-page version

A CFO-ready AI business case can fit on one page. In practice, the supporting analysis belongs in an appendix that gets read if there are questions. The page that gets approved or deferred in the room looks something like this:

What we are doing and why: one paragraph, no jargon, anchored to a specific problem the business is paying for today. What it will cost: a single number, fully loaded, with the major components broken out in a table. What value it will produce and when: a specific dollar figure (or a range), tied to a specific date, with the key assumption stated plainly. The downside: what the institution is out if the program is terminated at the go/no-go checkpoint. Who is accountable: two names — the business owner and the program lead. The ask: the specific approval being requested, not a general mandate to proceed.

That document is harder to write than forty slides. It requires the team to make choices about which numbers matter most and to commit to specific estimates rather than ranges of ranges. But it is what gets approved. The forty-slide version gets another meeting scheduled.

A CFO's job is to allocate capital responsibly. A business case that makes that job easier — that gives them the four numbers they need, acknowledges the risks honestly, and creates a bounded commitment — will get approved. One that makes their job harder, by burying the real numbers in strategic language, will get deferred until someone rewrites it.