Building a cost-benefit analysis for an AI project

By Ivo Donker — compiled with AI assistance (Claude & Gemini) · Last updated: August 7, 2026

The introduction of large language models (LLMs) and generative AI applications into the operations of small and medium-sized enterprises (SMEs) is often driven by technological enthusiasm or the fear of falling behind. Once an AI initiative moves beyond the stage of exploratory conversations, however, the board or management needs a business justification. That justification is the cost-benefit analysis (CBA).

A cost-benefit analysis for an AI project is not a marketing document, nor an exercise in filling in the blanks to justify a pre-selected solution. It is a formal decision document that provides structural insight into the investments, the expected returns and the risks across the entire life cycle of the software. Because AI systems differ from traditional software — among other things through stochastic behaviour, variable processing costs and continuous model development — a CBA for AI requires a specific approach. This guide describes step by step how to build a solid cost-benefit analysis as a decision document.

1. The foundation: always compare three alternatives

One of the most common mistakes in justifying an AI investment is making a binary comparison: setting the proposed AI solution against the current situation as if that will remain unchanged forever. A professional CBA therefore always sets three fully-fledged alternatives side by side:

1. Alternative 0: Do nothing (status quo & autonomous developments)
   This is the real reference point. "Doing nothing" does not mean the costs are zero. It covers continuation of the current process, including expected increases in wage costs, friction in scalability and the risk of losing market position if competitors become more efficient. It forms the baseline against which all investments are measured.
2. Alternative 1: Process optimisation without AI (low-tech / rule-based)
   Before investing in complex language models, you should analyse how much can be gained with traditional means. Think of redesigning the workflow, better forms, standardisable templates or rule-based automation (RPA or classic API integrations). It often turns out that 40% to 60% of the problem can be solved without AI, at a fraction of the maintenance costs. Alternative 1 prevents you from using AI budget to fix a poorly designed process.
3. Alternative 2: The AI integration proposal
   The proposed solution in which LLMs, agentic workflows or automated processing take centre stage. This alternative is measured against both Alternative 0 and Alternative 1. Only when Alternative 2 demonstrably delivers more net value than Alternative 1 is the AI component justified.

For a proper trade-off between building it yourself, buying an existing package or choosing a hybrid form, see the in-depth analysis of building or buying AI functionality.

2. Defining scope and time horizon

A cost-benefit analysis stands or falls on clear boundaries. If the scope is drawn too broadly, indirect benefits become contaminated with unprovable assumptions. If the scope is drawn too narrowly, essential preconditions such as data cleaning or licensing are overlooked. For the exact delimitation of your initiative, consult the guidelines for AI project scoping.

Using one universal time horizon

Choose exactly the same time horizon for all three alternatives. For SME software projects, a period of 36 months (3 years) is standard. A shorter horizon (12 months, for example) does not do justice to the one-off start-up costs. A longer horizon (such as 5 years) is unreliable with AI technology because of the high pace of innovation, falling API rates and changing legislation.

Make sure the chosen horizon takes account of your organisation's depreciation model and that all cash flows are classified per quarter or per year.

3. The cost side: from one-off investment to hidden operations

The total cost of ownership (TCO) of AI systems is more complex than that of classic SaaS packages. Where traditional software consists primarily of fixed licence costs, AI has a mix of fixed infrastructure, variable consumption costs and ongoing human supervision.

One-off costs (CAPEX / start-up)

• Research and proof of concept (PoC): The hours and resources used to validate technical feasibility.
• Data infrastructure and clean-up: Collecting, anonymising, labelling and structuring internal documents or databases. In practice this often accounts for 30% to 50% of the initial budget.
• System integration and software engineering: Building API integrations, middleware, vector databases, back-end logic and the user interface.
• Procurement and licence set-up: Legal review, privacy impact assessments (PIA/DPIA) and concluding enterprise agreements.
• Change management and training: Training staff, writing working procedures and guiding the organisational transition.

Recurring operational costs (OPEX)

• Processing and infrastructure costs: Variable costs for token consumption on external APIs or the rental of dedicated GPU capacity. For a detailed comparison between open-source hosting and closed-source APIs, see the overview of TCO of open versus closed source models.
• Database and search infrastructure: Hosting costs for vector databases (for example Pinecone, Qdrant or pgvector), storage of embeddings and traditional cloud infrastructure.
• Oversight and human control (human-in-the-loop): AI systems in business environments require sample-based or full review by qualified staff to catch hallucinations and errors. This working time must be entered directly as an operational cost item.
• Maintenance, prompt recalibration and evaluations: When model providers update or deprecate an LLM, prompts, embeddings and evaluation sets (evals) have to be readjusted and retested. This requires structural development time.

To keep these recurring IT expenses manageable during the management phase, it is advisable to include the principles of monitoring API costs in the decision document.

4. The benefit side: hard, soft and non-quantifiable effects

Benefits should never be entered in a CBA as vague promises. Every advantage must be categorised and substantiated according to a clear mechanism.

Hard benefits (directly quantifiable in euros)

Hard benefits are direct, demonstrable financial gains. The most important rule here is: time saved is only money when that time is genuinely spent differently or leads to a reduction in wage costs.

If an AI application saves an employee 30 minutes a day, but that time is filled with informal consultation, the financial benefit is zero. Only when the time saved demonstrably leads to less overtime, to not having to fill a vacancy (FTE reduction) or to a direct increase in billable volume may it be counted as a hard benefit.

Soft benefits (indirectly quantifiable)

Soft benefits concern performance indicators that indirectly represent a financial value:

• Shorter lead times: Faster quotation processing raises conversion. Substantiate this with historical conversion figures.
• Quality improvement and error reduction: Fewer human errors in data processing leads to less rework and lower claim or compensation costs.
• Capacity increase: Processing more transactions or customer requests without the workforce having to grow proportionally.

Non-quantifiable benefits (qualitative)

Some effects are strategically valuable but cannot reliably be expressed in figures. Think of higher employee satisfaction because repetitive work disappears, or building internal knowledge about AI integration. Mention these points explicitly in a separate qualitative paragraph in the decision document, but do not include them in the net present value (NPV) or the final financial calculation.

For a detailed treatment of the calculation methods around these advantages, see the guide on calculating the ROI of AI projects.

5. Dealing with uncertainty: ranges and sensitivity analysis

Determining costs and benefits for AI projects involves a higher degree of uncertainty than traditional IT investments. It is therefore irresponsible to calculate in the CBA with single point estimates (for example "this project will yield exactly € 45,000").

Working with three scenarios

Draw up three scenarios for each alternative:

1. Pessimistic scenario (conservative): High integration costs, low adoption among staff (e.g. 40%), high API costs and the need for intensive human review.
2. Realistic scenario (base case): Expected lead times, average adoption (e.g. 70%), normal API rates and planned reviews.
3. Optimistic scenario (best case): Rapid adoption (90%+), high quality gains and further falls in model costs.

Sensitivity analysis

Identify the two or three variables that most strongly influence the financial outcome. In AI projects these are almost always:

• The actual time saved per transaction.
• The percentage of output that requires human correction (error rate).
• The adoption rate among end users.

Demonstrate in the decision document what happens to the return if the time saving turns out 50% lower than hoped, or if oversight costs double. This gives the board insight into the project's margin of safety.

6. Fictitious worked example: CBA structure for an SME organisation

To make the structure of a cost-benefit analysis clear, the table below shows a fictitious worked example for a medium-sized service provider (50 employees) that wants to automate the handling of incoming customer requests. The horizon is set at 36 months.

Note: all amounts and hours below are explicitly fictitious and serve solely to illustrate the table structure in the CBA.

In this fictitious example, Alternative 1 (process optimisation without AI) already yields a saving of € 28,000 against a low initial investment. Alternative 2 (the AI project) demands a considerably higher start-up investment (€ 45,000), but delivers a net advantage over 36 months of € 57,000 compared with doing nothing, and € 29,000 compared with Alternative 1. The decision document must now show whether the additional risk of Alternative 2 outweighs this € 29,000 of extra return.

7. Why payback time can be misleading with AI

In classic IT business cases the payback period is a popular metric: "within how many months is the investment recouped?". With AI projects, steering on this metric alone can lead to the wrong decisions.

There are two reasons for this:

1. Price and quality shifts: The costs of model calls (API tokens) have historically fallen quickly, while performance per model increases. A calculation based on today's rates may look more favourable in 18 months' time.
2. Structural maintenance pressure: Unlike traditional software, where a package can run for years after delivery without major adjustments, AI systems require continuous attention. Models are swapped out by suppliers, prompts lose their effect on updates and input data changes. As a result the operational cost curve does not drop to zero; a structural floor of management expenditure remains.

Use the payback period, therefore, as no more than a secondary indicator and rely primarily on net present value (NPV) with an adequate discount rate.

8. When do you stop calculating? The step to a pilot project

Making a cost-benefit analysis has its limits. When the assumptions about time savings, error rates and the amount of human review needed are too far apart, there is no point in spending weeks calculating theoretical models. The uncertainty in the CBA is then too great to base an investment decision on.

In that situation the right conclusion of the CBA is not "yes" or "no", but proposing a phased decision:

• Do not yet approve the main budget.
• Make a limited budget available for a clearly delimited trial.

A focused trial period has the sole purpose of validating the 2 to 3 most critical assumptions from the CBA in practice. How to set up such a manageable test phase is described in the playbook for an AI pilot in 30 days. After the pilot is completed, the measured data are entered into the CBA, after which a definitive decision about full rollout can be taken.

9. Common mistakes in CBA practice

When reviewing cost-benefit analyses for AI projects, accountants and board members regularly encounter the same structural shortcomings. Make sure your decision document avoids the following four pitfalls:

Mistake 1: Double-counting benefits

Entering time savings and additional revenue as separate items, while both stem from the same capacity. If a consultant spends less time on administration thanks to AI, you can count either the salary hours saved or the additional billable hours they work in that time, but never both at once.

Mistake 2: Confusing pilot costs with structural costs

Assuming that the costs from the pilot phase are representative of the production phase. A pilot often uses expensive, generic API models and manual overviews. In production the cost per transaction may be lower through optimisation, but is offset by higher costs for security, monitoring and SLAs. For the step to scaling up, see the guide on the transition from pilot to production.

Mistake 3: Valuing person-hours at the wrong rate

Valuing internal hours saved at externally hired consultancy rates, or calculating with an average hourly rate including overhead for tasks carried out by staff in a lower salary scale. Calculate solely with the direct employer costs of the specific role that actually performs the task.

Mistake 4: Forgetting the cost of human oversight (human-in-the-loop)

Assuming that the AI system operates 100% autonomously and flawlessly. In virtually all B2B processes (such as contract analysis, complaint handling or financial coding) human sampling or final review remains necessary. If reviewing an AI-generated document takes 5 minutes, and drafting it manually takes 15 minutes, the real gain is 10 minutes per document — not 15 minutes.

Summarising decision framework

A professional cost-benefit analysis for an AI project gives the board clarity by providing structure in an uncertain market. By comparing three alternatives as a matter of course, fully including operational and oversight costs, and calculating with scenarios, you prevent your organisation from investing in technological experiments without business returns.

If the outcome of the CBA shows that Alternative 2 (the AI solution) also performs better than process optimisation without AI (Alternative 1) in the pessimistic scenario, you have a solid foundation for the investment request. If the assumptions are still too soft, use the CBA to establish the preconditions for a controlled pilot.