How to Justify the ROI of an AI Project to the Board: A Guide with Real Numbers

How to justify the ROI of an AI project to the board

The short answer: your board does not care about AI. It cares about money. Your job is to translate a technology decision into a financial decision, and to do it with numbers that can be verified, not with projections that look like they came out of a startup pitch deck.

That is possible. But it requires doing the work before you walk into the room.

The real problem with ROI presentations that fail

Most AI proposals that reach a board fall apart for one of two reasons.

The first: the numbers are too vague. "We expect to reduce operational costs" is not an argument, it is a hope. An experienced CFO dismisses it in thirty seconds.

The second: the numbers are too optimistic. Projections of 10x returns in the first year, built on assumptions that have never been tested, destroy credibility. And once credibility is gone, it is hard to rebuild.

The right approach is different: be conservative, be specific, and start from data you already have inside your organisation.

The three-layer method for calculating ROI

Layer 1: Quantify the current problem

Before talking about returns, you need to quantify the cost of the current situation. This is the step many managers skip, and it is exactly what the board needs to see first.

Concrete questions to ask internally:

• How many hours per week are spent on this manual process?
• What is the hourly cost of the people involved?
• What is the current error rate and what does each error cost (returns, complaints, rework)?
• What is the impact of a slow decision in this process, in lost revenue or opportunity cost?

One example: in an insurance claims error detection project, the starting point was mapping how many claims were processed incorrectly and what it cost, on average, to fix each error by hand. That number alone showed the decision-maker the scale of the problem before any improvement projections were introduced. You can read more about this case in the article on detecting errors in insurance claims.

If you do not have these numbers yet, start by measuring the baseline. We explain how in the guide on baseline measurement.

Layer 2: Build the conservative scenario

Do not present the best-case scenario. Present the conservative scenario and explain why it is conservative.

The structure is straightforward:

Total investment = development cost + integration cost + first-year maintenance cost

Direct return = (hours freed up × cost per hour) + (error reduction × average cost per error) + (revenue or margin impact, if measurable)

Payback period = total investment ÷ estimated annual return

An illustrative example: if the project costs €40,000 and frees up €18,000 per year in manual work and avoided errors, the investment pays back in roughly 26 months. That is an argument. Present it that way, with the assumptions in plain sight.

What the CFO will scrutinise are the assumptions, not the final number. Make sure you have internal data to back them up.

Layer 3: Add the harder-to-measure benefits, carefully

Some benefits are real but difficult to quantify precisely: faster decisions, less dependence on key individuals in critical processes, the ability to scale without hiring at the same rate.

Mention them, but keep them out of the main calculation. Present them as "additional unaccounted gains." This signals honesty and reinforces the credibility of the conservative number from Layer 2.

The three most common traps (and how to avoid them)

Trap 1: Starting from the return and working backwards. This happens when you decide you want to justify a €100,000 investment and build the numbers to reach that conclusion. CFOs recognise this pattern immediately. Start from real data and work towards the estimated return, never the other way around.

Trap 2: Ignoring post-delivery costs. An AI model in production needs maintenance, monitoring, and periodic updates. Projects that show only the development cost and overlook running costs create unpleasant surprises months later. Include an estimate of the annual maintenance cost, even if it is approximate.

Trap 3: Promising a timeline you do not control. The return on an AI project depends partly on internal factors: team adoption, the quality of available data, and integration with existing systems. Present the ROI tied to explicit assumptions, not as an unconditional guarantee.

What the board actually needs to see

When a CEO or CFO approves an AI project, they are making a capital allocation decision. What gives them confidence is not the technology. It is clarity on three things:

1. What problem are we solving and what does it cost today
2. What is the total investment and when do we get it back
3. What are the risks and how are we managing them

If your presentation answers these three questions with real data and transparent assumptions, you have an argument. If it answers them with slides about the potential of generative AI and success stories from large multinationals, approval will be hard to come by.

The difference between an approved project and a rejected one rarely comes down to the technical quality of the solution. It comes down to the quality of the business case behind it. An AI project that cannot be justified internally should not move forward: without clarity on the expected value, there is no way to manage expectations or measure success afterwards.

And once the project is in production, the work shifts: proving that the promised return is actually materialising. We cover that in the article on how to measure the real impact of an AI project in production.