How to build an AI business case your CFO will approve

Getting budget approved for an AI initiative is harder than it should be. Not because the ROI isn't there — in most cases it clearly is — but because the business case is framed the wrong way. Engineers talk about capabilities. Finance wants to talk about money. The gap between those two conversations kills a lot of good projects.

Here's the framework we use with clients to build AI business cases that actually get approved.

The challenge isn't proving that AI delivers ROI — Harvard Business Review research shows that companies with mature AI programs report significant efficiency gains and cost reductions. The challenge is structuring a business case that connects those possibilities to your specific situation clearly enough that finance will approve it.

Start with the problem, not the solution

The fastest way to lose a CFO is to lead with the technology. "We want to build an AI model that..." is not a business case. It's a shopping list.

Start with the problem statement: what is currently broken, slow, or expensive? Put a number on it. "Our team spends 12 hours per week manually reconciling invoices" is the kind of concrete problem that finance understands — and can evaluate against a proposed solution.

Before writing a single word of your business case, work through our five-question framework to validate the opportunity.

Quantify the status quo

Every problem has a cost. Your job is to find it and document it.

• Labor cost: hours per week × hourly rate × 52. Don't forget benefits multiplier (typically 1.3–1.5×).
• Error cost: how often does the manual process produce errors, and what does each error cost to fix?
• Opportunity cost: what could your team be doing if they weren't doing this?
• Delay cost: what decisions are being made slowly because the underlying process is slow?

Add these up. In our experience, most manual business processes cost 2–4× more than companies realize when all four categories are included.

Use conservative projections

The temptation is to use best-case numbers to make the ROI look compelling. Resist it. Finance will cut your projections anyway — so start conservative and let the math speak for itself.

Use 50–70% of the theoretical maximum benefit. If the AI could theoretically eliminate 100% of the manual work, model 60%. That accounts for edge cases, training time, and the reality that people aren't 100% efficient even when using good tools.

Include the full cost picture

Common mistake: business cases that only include the cost of building the AI system, not running it. Make sure your cost model includes:

• Development and implementation (one-time)
• Infrastructure and API costs (ongoing, monthly)
• Maintenance and monitoring (ongoing)
• Training and change management (one-time)
• Integration with existing systems (one-time)

Our AI consulting engagements always include a full cost model as part of the strategy phase — so there are no surprises when you take it to finance.

Lead with payback period, not IRR

CFOs respond to payback period more than any other metric. "This investment pays for itself in 8 months" is a sentence that gets budget approved. Work backwards from your cost model to find the payback period and put it front and center.

For context: the invoice processing system we built had a payback period of under 4 months. That's a strong business case even without anything else in the document.

Include a risk section

Most business cases skip risk because it feels like arguing against yourself. The opposite is true. A business case with a clear-eyed risk section — and mitigations for each risk — reads as credible and well-considered. One without risk reads as naive.

Common AI project risks to address: data quality issues, user adoption, integration complexity, regulatory compliance, and model accuracy in edge cases.

For each risk, document the likelihood, the potential impact, and your mitigation plan. Three columns. Keep it tight. A CFO who sees "Data quality risk — mitigation: data audit in week one before any build begins" understands you've thought this through. That's what moves a business case from "interesting" to "approved."

Structure the document like a CFO reads

CFOs are busy. They read executive summaries first, skip to the numbers, and only read the detail if the numbers hold up. Structure your business case accordingly:

1. Executive summary — problem, solution, payback period, ask. One page maximum.
2. Problem statement — current cost of the status quo, quantified.
3. Proposed solution — what you're building, at a high level. No technical jargon.
4. Financial model — costs, benefits, payback period, 3-year projection.
5. Implementation plan — phases, timeline, team requirements.
6. Risk register — top 5 risks with likelihood, impact, mitigation.
7. Appendix — technical detail, vendor comparisons, data sources. For anyone who wants to go deeper.

The executive summary is the most important section. If it doesn't land, nothing else matters. Write it last, after you know exactly what the numbers say.

Get stakeholders aligned before the meeting

The worst place to encounter objections is in the room where the decision gets made. By then it's too late — you're defending instead of presenting, and the dynamic has already shifted against you.

Before the formal budget meeting, walk the business case past the key stakeholders individually. The department head whose team will use the system. The IT lead who has to integrate it. The finance analyst who will sanity-check your numbers before they reach the CFO.

This does two things. First, it surfaces objections early when you can actually address them — updating the model, clarifying an assumption, strengthening a section. Second, it means you walk into the budget meeting with allies, not skeptics. People who've already seen it and nodded along are far more likely to support it publicly.

In our experience, business cases that go through informal stakeholder review before the formal presentation get approved at roughly twice the rate of those that don't. [Guessing on the exact ratio, but the directional effect is real and consistent.]

What happens after approval

Getting budget is the beginning, not the end. The business case you presented becomes the benchmark you're measured against. If you projected 60% time savings and delivered 40%, someone will notice. If you projected an 8-month payback and it takes 14, finance will remember.

Build a measurement plan into the business case itself. Define exactly how you'll track the benefits: which metrics, how often, who owns the reporting. This signals to finance that you're serious about accountability — and it protects you if results take time to materialize, because you've already agreed on how they'll be measured.

The best AI business cases we've seen treat approval as the start of a relationship with finance, not a one-time event. Regular progress reports, honest updates when timelines slip, clear communication about what's working and what needs adjustment. That's what builds the organizational trust to fund the next AI initiative — and the one after that.

If you're working through this process and want a second set of eyes on the model before it goes to finance, book a free strategy call. We've built business cases for AI initiatives across industries and know what CFOs push back on — and how to get ahead of it.