How to Build an AI Business Case Finance Will Approve
To build an AI business case finance will approve, align stakeholders on the specific problem before any numbers get built, assemble the case's pieces — problem statement, cost model, benefit model, scenarios, financial metrics, risk, and recommendation — in that order, pressure-test it internally against a finance-literate reviewer before it's formally submitted, and treat finance's first response as a specific, answerable set of questions rather than a verdict to appeal. Programme leaders who skip the alignment and pressure-testing steps and go straight to the numbers are the ones who find their case back in their inbox with a list of gaps.
Start With the Problem, Not the Technology
Before any cost or benefit figure gets built, get explicit agreement from the business unit lead, Finance, and any relevant technical owner on exactly what business problem or opportunity the case addresses — in terms a non-technical reviewer can evaluate, not a description of the AI approach. A case that reaches finance without this alignment done in advance gets this conversation anyway, just later and more expensively, after a full financial model has already been built around an unvalidated premise.
Assemble the Pieces in Order
With the problem agreed, the case comes together as a fixed set of pieces, each with its own depth elsewhere: a problem and options statement, a complete cost model (capital and operational cost, kept separate, including an AI-specific non-linearity allowance — the full breakdown of cost categories most AI cases miss is in Why Most AI Business Cases Collapse Under Finance Scrutiny), a benefit model, a three-scenario comparison, and the financial metrics that follow from them — the full step-by-step calculation is in How to Calculate the ROI of an AI Project, Step by Step. For the complete document structure these pieces fit into, section by section, see AI Business Case Template: Sections Finance Expects. Building them in this order matters: a cost or benefit figure built before the problem is agreed tends to get re-built once stakeholders actually weigh in, which is wasted effort the sequencing avoids.
Pressure-Test It Internally Before Finance Sees It
Before formal submission, walk the case past someone who will ask the questions a finance reviewer will ask — ideally someone in Finance who isn't the formal approver, or a colleague who has had a business case rejected before and knows what that felt like. The specific value of this step is catching the gap that's invisible to the person who built the case: a missing cost category, a benefit figure with no stated methodology, a single scenario presented as if it were the only plausible outcome. A case that has already survived one informal challenge arrives at formal review in materially better shape than one that hasn't.
Anticipate the Three Challenges Finance Always Raises
Three objections account for most of the reasons a first-pass AI business case gets sent back. First: a single scenario presented with more confidence than the uncertainty in AI programme economics actually supports — met by presenting Conservative, Base, and Aggressive cases side by side, not a request to remove the uncertainty. Second: a cost model missing a category finance expects to see — most often change management, ongoing model maintenance, or opportunity cost — met by using the full five-category cost model as a checklist before submission, not after a reviewer points out the gap. Third: a recommendation that isn't actually a decision — a case that presents numbers without stating plainly what's being asked for (approve, conditionally approve, or reject) and what happens next if approved. Finance reviews a lot of material; a case that makes the ask explicit gets a faster, clearer answer than one that leaves the reviewer to infer it.
Present It as a Decision, Not a Pitch
The executive summary — one page, headline metrics, explicit recommendation — is what a time-constrained reviewer reads first and sometimes only. Everything after it exists to support that page, not to build suspense toward it. A case structured as a narrative that arrives at its numbers on the final page asks the reviewer to do more work to find the answer than a case that states the recommendation up front and uses the rest of the document to defend it.
What Happens After Submission
A finance response that isn't an outright approval is rarely a dead end — it's usually a specific, answerable question: a benefit assumption they want justified, a scenario they want added, a cost category they want broken out further. Treating that response as a checklist to work through, rather than a rejection to contest, is both the faster path back to approval and the one less likely to damage the working relationship the next case will depend on. A business case that goes through one or two rounds of specific, addressed feedback before approval is a normal outcome, not a sign the original case was weak.
A Hypothetical Illustration
Picture a programme team that aligned with the business unit and Finance on the problem before building anything, assembled the cost model using all five categories as a checklist, ran three scenarios, and had a finance-literate colleague review a draft before submission. Finance's actual response was one specific question — justify the Year 1 benefit ramp assumption against a comparable prior programme — rather than a broad rejection. The team answered it with the documented ramp-curve methodology already built into the benefit model, and the case was approved on the next pass. None of the steps eliminated finance's scrutiny; they made the scrutiny fast and specific instead of broad and repeated.
The AI Investment ROI Model builds the cost model, benefit model, three-scenario comparison, and financial metrics this process assembles, with an Assumptions Log tab that documents every input's source — exactly the kind of detail a finance reviewer's specific follow-up question asks for.
→ Available at www.viksya.com