73% of AI business cases approved by CFOs fail to deliver their projected ROI within 18 months.

That is not a technology failure. The AI works. The use cases are real. The failure is in how the business cases are built. They model pilot economics, not production reality. They describe what the AI does rather than what it changes for the business. They underestimate total cost and overestimate the pace at which value arrives.

CFOs have learned this. In 2026, CFOs are in the room asking hard questions, and the answers are not always satisfying. Forrester research found enterprises are postponing 25% of planned AI spend to 2027 as financial scrutiny increases. One in two CFOs will terminate funding if an initiative fails to demonstrate ROI within the first year.

The business case that gets funded and delivers is built differently from the one that describes a technology. Here is how to build it.

What a CFO Is Actually Evaluating

A CFO reviewing an AI business case is not evaluating whether AI is strategically important. They have accepted that already.

They are evaluating three specific questions.

• Is this investment credibly sized?

Not just the initial cost, but the full three-year cost including infrastructure, integration, governance, maintenance, and the engineering capability required to operate the system. 73% of AI business cases underestimate total deployment cost versus the initial proposal. The CFO has seen this pattern. An investment proposal that matches the pattern gets scrutinised more closely.

• Is the value claim specific and verifiable?

A business case that promises efficiency improvements without connecting them to a specific financial line is not a financial argument. It is an aspiration. The CFO needs to know which metric moves, by how much, on what timeline, measured against what baseline.

• What is the risk that this does not deliver?

AI projects have a documented failure rate. The CFO knows this. A business case that does not address failure modes honestly is one that the CFO will identify gaps in before they fund it. A business case that names the risks and explains why they are managed is one that builds credibility.

The Most Common Reason AI Business Cases Fail CFO Review

The highest-risk assumption in any AI business case is organisational capability.

Most AI business cases are built by technology teams who understand the AI better than they understand capital allocation. They model the value correctly but underestimate the operational reality of deploying AI at production scale.

An enterprise that approved an $8.5 million AI investment based on pilot economics applied to 400 product lines found, eighteen months later, that the system was running on 47 product lines. The accuracy gains held. The operational overhead of data engineering, integration maintenance, and model governance had not been modelled. The economics that worked at pilot scale collapsed at production scale.

This is the pilot-to-production gap in financial terms. The economics that justify the investment are calculated at pilot scale. The costs that materialise arrive at production scale. The gap between them is where most AI business cases fail after being funded.

The business case that closes this gap does not model the pilot and project it forward. It models what production actually costs: integration engineering, data infrastructure, governance overhead, model maintenance, and the organisational capability required to operate AI systems continuously rather than just deploying them once.

The Structure of a CFO-Grade AI Business Case

1. Name the decision the AI changes

The starting point is not what the AI does. It is which business decision it changes and what that decision is currently costing.

A procurement AI does not improve procurement. It changes how supplier qualification decisions are made. The current cost of making those decisions manually is a specific figure. The accuracy and speed of decisions made with AI assistance is measurable against a defined baseline. The financial value of better, faster supplier qualification decisions flows through to procurement cycle time, supplier performance outcomes, and cost avoidance.

This is the structure that works: identify the decision, calculate the current cost of making it the current way, model the improvement from AI assistance, and connect that improvement to a financial outcome.

A business case that describes "improved procurement efficiency" is not a financial argument. A business case that describes "reduction in average supplier qualification time from 14 days to 3 days across 2,400 annual qualifications, reducing procurement cycle time by an average of 11 days and enabling 340 additional procurement completions per year at an average contract value of $180,000" is.

2. Model production costs, not pilot costs

The three-year cost model needs to include every cost that production operation will generate.

Initial deployment costs include data preparation and integration engineering, which typically accounts for 40 to 60% of total build cost. Model training and validation. Infrastructure procurement. User training and change management.

Ongoing costs include inference compute, which scales with usage. Integration maintenance, which is triggered by every change to connected enterprise systems. Model retraining as the business environment changes. Governance and compliance overhead, which is a real operational cost in businesses with regulatory obligations. And the engineering capacity required to maintain and improve the system over time.

Infrastructure costs in manufacturing, logistics, and analytics AI surpass development costs within 12 to 18 months due to ongoing processing demands. This cost trajectory needs to be in the model before the CFO asks about it.

3. Build the value model on verified baselines

The value claim needs a documented baseline. Not an industry benchmark. The actual current performance of the specific process the AI will improve, measured in the same units as the projected improvement.

If the business case projects a 30% reduction in manual invoice processing time, the baseline is the actual time currently spent on manual invoice processing, measured from the organisation's own operational data. If that baseline is not available, establishing it should be the first deliverable of the project, before the investment case is finalised.

Value that cannot be connected to a verified baseline is a projection that the CFO will treat as an aspiration. Value connected to a verified baseline is a commitment that can be tracked and that frames the go/no-go decision at each stage of deployment.

4. Address the two objections before they are raised

Every CFO reviewing an AI business case has two objections that they may or may not raise explicitly.

• Objection 1: Most AI shows no return. Why is this different?

The answer to this objection is specificity. The business cases that fail are the ones that are built on general capabilities applied to general use cases. The ones that succeed are built on specific capabilities applied to a specific operational problem with a specific measurable outcome.

Name the specific process. Name the specific metric. Name the specific baseline. Name the specific improvement. Name the specific financial value. Name the specific timeline. Each level of specificity reduces the CFO's grounds for the objection.

• Objection 2: We do not have the capability to operate this.

The highest-risk assumption in any AI business case is organisational capability, as described above. Addressing this proactively means describing explicitly how the system will be operated after deployment. Who maintains the model. Who manages the integration. Who owns the quality monitoring. Who governs the outputs.

If the answer relies on an external partner, describe the partner model clearly, including cost and terms. If the answer relies on internal capability, describe what that capability currently looks like and what investment is required to build what is missing.

A business case that acknowledges the capability requirement and addresses it explicitly is more credible than one that assumes internal capability exists without examining whether it does.

5. Define success before the investment is approved

The business case should define what success looks like at three specific points: the end of the pilot phase, the end of the initial production deployment, and the end of year one at full scale.

Each success definition should include a specific metric, a specific target, and a specific date. These become the gates that determine whether the programme continues, adjusts, or stops.

One in two CFOs will terminate funding if an initiative fails to demonstrate ROI within the first year. Defining success milestones before the investment is approved establishes a shared understanding of what the programme is accountable for. It also protects the initiative from being terminated against unclear expectations. A programme that hits its defined milestones is demonstrating ROI by the definition the CFO approved. A programme without defined milestones is evaluated against whatever expectation the CFO has formed, which may not match what was promised.

What to Do When the Numbers Do Not Stack Up

Sometimes the honest financial model does not produce a compelling return at the scale being proposed. This is useful information.

It is better to discover this during the business case process than after the investment is approved. If the numbers do not stack up at a specific scale, reduce the scope to the use case where they do. A smaller, financially sound investment that delivers its projected return is a better outcome than a large investment that does not.

It also builds credibility with the CFO. A team that brings a proposal and says "we modelled three scenarios and recommend the middle one because the full-scale case does not yet have a compelling ROI" is a team the CFO will trust with future investment proposals. A team that brings a proposal with inflated projections and delivers less than half of them is not.

The business case is not the end of the conversation with the CFO. It is the beginning of a relationship around AI investment that will either build trust over time or erode it. Building it on honest numbers and conservative projections is the foundation that makes subsequent proposals easier to fund.

Vishleshan AI's forward deployed engineering (FDE) approach starts every engagement by establishing the business metric and the baseline that the investment will be measured against. The business case is built on the production reality of the client's actual environment, not on pilot economics projected forward. This is what makes the returns we project the returns that materialise. Book a Consultation