Calculating the ROI of AI Projects: Method, Assumptions, Pitfalls

Sooner or later, anyone proposing an AI agent is asked two questions: what will it deliver, and what will it cost? This article sets out a method that holds up under scrutiny from finance, management and a supervisory board. It covers benefits and costs, the common metrics, how to handle uncertainty and the mistakes that most often distort the result. Status: October 2026. All figures in the worked example are assumptions for illustration, not measurements.

What does ROI mean for an AI project, and why is one number not enough?

ROI, or return on investment, relates the gain from an undertaking to the capital put in. For AI projects one number is not enough, because benefits and costs are spread over several years and both are uncertain. A useful assessment needs yearly cash flows, stated assumptions and a range of outcomes instead of a single value.

The simple formula is (benefit − cost) divided by cost. As an arithmetic step it is fine, but it hides three things. First, it says nothing about timing: money received in three years is worth less than money received today. Second, it conceals how much depends on staff actually using the agent. Third, it easily mixes real cash effects with notional ones such as "hours freed up".

A practical approach keeps four things apart:

• Baseline: What does the process cost today in time, errors and waiting? Without a measured baseline nothing can be shown afterwards.
• Benefit side: Which cash flows change, and from when?
• Cost side: What do build and operation cost over the whole life of the system?
• Uncertainty: How does the result move if the main assumptions do not hold?

AI projects differ from classic software in one respect: the outcome depends not only on the technology but on the quality of the output and on how the organisation works with it. An agent whose drafts are rewritten every time creates cost, not value. That is why human review time belongs explicitly in the calculation.

Which metrics exist, and when does each help?

Three metrics cover most decisions: simple ROI, payback time and net present value. Each answers a different question. ROI compares ratios, payback shows how long capital is at risk, and net present value accounts for the time value of money. Together they give a picture that no single figure can.

Payback period. It states how long it takes for cumulative returns to cover the initial outlay. It is easy to explain, which is why it is popular. Its weaknesses are well documented: it ignores the time value of money and any cash flows after the break-even point. A project that pays back slowly but runs profitably for many years therefore looks worse than it is.

Net present value (NPV). This is the sum of all cash flows discounted to today, with the initial investment entering at time zero. A positive value means the project creates more value than it costs. The description of the method also notes what matters here: the result is only as accurate as the forecast cash flows, their timing, the project length and the discount rate. NPV is purely financial and leaves out strategic reasons and hidden costs.

Simple ROI. It suits a quick comparison of similar projects, provided all are calculated over the same period. When projects have different time horizons, use NPV instead.

For the internal decision, show all three and add the point at which NPV crosses zero. A sentence such as "the project pays off if most of the possible time saving is really used" tells decision-makers more than any single result.

How do you determine the benefit side properly?

Benefit arises only where a cash flow changes: lower costs, higher revenue or avoided losses. Time saved is an intermediate value that becomes a benefit only after a second question: what happens to the freed time? Carry every benefit through to a cash figure, or list it separately as a non-monetary effect.

It helps to sort benefits into four kinds, because each is evidenced differently:

1. Direct cost effects. External services, licences or overtime that disappear. This is the most robust kind because it shows up in the accounts.
2. Capacity effects. The same team handles more cases. This becomes a benefit only if there is demand that went unserved: unanswered enquiries, long quote turnaround, waiting customers.
3. Revenue effects. Faster quotes, better follow-up, fewer drop-outs. These effects are real but hard to attribute. Use very cautious assumptions and support them with your own comparison data.
4. Risk effects. Fewer errors, avoided complaints, better traceability. Value them as expected loss (probability times damage), and only if both inputs come from your own data.

The most common source of error is converting hours into money. Valuing each saved hour at the full hourly cost assumes that the hour is put to fully productive use elsewhere, or that payroll cost actually falls. Both are rarely true. Introduce a realisation rate instead: the share of the notional time saving that turns into an actual cash effect. It is the most important lever in the calculation and belongs openly in the assumptions list.

How do you find the realisation rate? Best from a small pilot on real cases: how many drafts were accepted unchanged, how many revised, how many discarded? That shows how much review work remains. Without a pilot you have only a cautious estimate, which you lower further in the pessimistic scenario.

Which costs belong in the calculation?

The cost side has one-off build costs and recurring running costs over the whole period considered. The second group is underestimated most often in business cases because it arrives quietly after launch: model costs, maintenance, quality review, monitoring, training and the time business staff spend on approvals and corrections.

One-off costs. These include analysis and process clarification, building the agent, connecting systems (for example ERP, CRM, document storage), testing on real cases, and rollout and training. Count the time of your own specialists as well. Whoever validates the agent professionally is missing from daily work during that time.

Running costs. A split helps:

• Model and infrastructure. For hosted models, providers bill by token. On Anthropic's pricing page, input and output tokens are priced separately, per million tokens. Prompt caching and the batch API are documented there as levers: for the batch API the page states a 50% discount on input and output tokens, with asynchronous processing as the price. With local operation, hardware, power and administration replace the token bill.
• Maintenance and development. Models get retired, interfaces change, processes evolve. Plan a fixed annual budget instead of being surprised by it.
• Quality assurance. Spot checks, error analysis, adjusting instructions. This effort declines as the agent matures but does not disappear.
• Human review. For agents that deliver drafts instead of acting alone, review time per case is the largest cost block. It belongs in both the cost and the benefit calculation: the benefit is only the difference between handling a case with and without the agent, review included.
• Licences and security. Accounts, roles, logging and any measures from your AI governance.

A detailed breakdown by cost category will follow in a separate article in this knowledge area once it is published. This article concentrates on the method.

Finally, check third-party prices for currency. Model prices change, and the provider's page states the date of its figures. Note the retrieval date in your assumptions list.

What does a worked example look like?

The following example is purely illustrative and rests on freely chosen assumptions. It shows how strongly the result depends on the realisation rate: the same investment gives a clearly positive, a negative or a barely positive net present value depending on one assumption.

Assumptions (quotation example). A company writes 400 quotes a year. A quote currently takes 3 hours, and 1.5 hours with the agent (draft plus human review). The difference of 600 hours a year is valued at 60 euros an hour, giving 36,000 euros of notional benefit. Build and rollout cost 30,000 euros once. Running costs are 13,400 euros a year: 2,400 for model usage, 8,000 for maintenance and quality assurance, 3,000 for platform and monitoring. The horizon is three years, cash flows fall at year end, and the discount rate is 10 percent.

The lesson sits in the middle row. At a realisation rate of 60 percent the project does not pay for itself within three years. Over five years the picture would change, because the agent keeps running after the investment has come back. That is exactly why NPV and the chosen horizon matter: the decision depends on how long the solution is realistically used, not on payback alone.

The calculation also yields a threshold. With these assumptions, three-year NPV turns positive only from a realisation rate of roughly 71 percent. That is the figure management and the business unit should discuss: do we believe a good 70 percent is achievable, and how would we know early on?

How do you deal with uncertainty?

Uncertainty does not disappear through more precise figures; it is made visible. Calculate every decision in at least three scenarios, name the two or three assumptions with the greatest influence, and test them with real data as early as possible. A sensitivity analysis shows which assumption actually tips the result.

A proven approach in four steps:

1. List the assumptions. Every number with its source (own measurement, estimate, vendor statement) and date.
2. Test the influence. Move each assumption up and down by a fixed amount, one at a time, and watch NPV. The assumptions with the biggest swing are your risks.
3. Measure early. For the two biggest risks, fix a measure that the pilot will collect: acceptance rate of drafts, review time per case, error rate.
4. Agree a stop criterion. Decide in advance at which measured value the project is adjusted or ended. That protects against continuing out of habit.

A staged approach fits this. Instead of a large budget up front, run a small pilot whose results supply the assumptions for the next stage. The first investment is small, and the knowledge it produces has a value that a rigid calculation never shows. A rule of thumb for mid-sized companies: split the investment so that after every stage you decide with better figures.

The discount rate is the most overlooked assumption. It reflects the return you could earn on an investment of similar risk. Agree it with finance and also run the project with a higher rate. For long horizons it weighs more heavily than for short ones.

Which mistakes distort the calculation most often?

Most flawed AI business cases fail not on arithmetic but on assumptions nobody checked. Typical are a realisation rate that is too high, forgotten running costs, double counting of benefits, and comparing against an ideal process rather than the actual current state. Anyone who knows these errors finds them quickly, in other people's calculations and their own.

• An idealised current state. The process "today" is described as it should work, not as it runs. The baseline must be measured, or before-and-after comparisons are worthless.
• Full utilisation assumed. The agent is calculated at the maximum number of cases, while day-to-day use stays below that.
• Review work forgotten. Drafts must be checked. If review time is not counted, the benefit is overstated.
• Double counting. The same time saving appears as a cost advantage and again as a capacity gain.
• One-off costs without upkeep. Build is budgeted, operation is not. After a year there is no money for adjustments, and quality drops.
• Labour-cost rate instead of cash flow. Time is valued at the full labour-cost rate although no cost disappears and no revenue arises.
• Technology instead of process. The calculation covers what the agent can do, not what the organisation makes of it. An agent without a clear owner in the business unit stays unused.
• Non-monetary effects forced into money. Putting invented amounts on quality or satisfaction makes the calculation easy to attack. Show such effects in a column of their own.

One uncomfortable truth belongs here: some use cases do not pay off. That is a good result of an honest calculation, not a failure of it. A project that is positive only under the most optimistic assumptions should wait until one of those assumptions can be evidenced. For ideas on which processes are candidates, see the overview of AI agent use cases.

What does the calculation look like in practice?

In practice a sequence works well that starts with measurement and ends with a decision paper. Most of the effort goes into the first steps: understanding the process, measuring the baseline, clarifying assumptions. The calculation itself is then a table with three columns.

1. Choose and scope a process. One with a clear start and end, a measurable volume and named owners. Examples are quotation preparation or answering technical enquiries.
2. Measure the baseline. Volumes, lead times, handling time per case, error and rework rates. Two to four weeks of measurement is often enough; where no data exists, a manual sample helps.
3. Describe the target state. Who does what in future? Where does a person review? Which cases does the agent not handle? This step also clarifies which systems must be connected.
4. Calculate benefits and costs. Year by year, with realisation rate and maintenance effort. Assumptions and sources go into a table of their own.
5. Three scenarios and a threshold. Optimistic, realistic, pessimistic, plus the realisation rate at which NPV turns positive.
6. Pilot with measures. The two biggest assumptions are measured in the pilot. Results flow back into the calculation.
7. Document the decision. What was assumed, what was measured, what was decided? The record makes the business case checkable later and is the basis for comparing plan with actual.

The calculation is not finished at launch. After six months compare plan and actual: was the realisation rate reached, have costs shifted, do the business units use the agent? That review produces better assumptions for the next project. Anyone who never recalculates never learns which of their estimates can be trusted.

Where are the limits of the method?

Every financial calculation is only as good as its inputs, and in AI projects many inputs are new and have no track record. The method therefore delivers no forecast but a structured justification for a decision. It replaces neither judgement nor the strategic question of whether a process should be automated at all.

Some limits deserve to be stated openly:

• Strategic reasons. A project can make sense although NPV is negative, for instance to build skills or reduce a dependency. Then say so in the justification rather than polishing the numbers. NPV leaves out strategic factors, so add them.
• Technological change. Models and prices move quickly. A five-year calculation rests on assumptions that may be outdated after two. Shorter horizons and regular recalculation limit the risk.
• Learning effects. The value of a pilot often lies in the knowledge it yields. That does not appear in the arithmetic and still justifies small investments.
• Legal requirements. Obligations, for example under the EU AI Act or data protection law, can cause costs that belong in the calculation. This article is not legal advice; clarify the requirements for your case with specialists.
• Data quality. If the process data is patchy, the baseline is uncertain. Then data clarification comes first, not the calculation.

How do you get started?

Start small and measurable: choose one process, measure the baseline over two to four weeks and build a first calculation in three scenarios. Stated assumptions matter more than precision. Afterwards decide which assumption a pilot should test.

A concrete way in:

• Create a table with the columns "assumption", "value", "source", "date".
• Measure and record the baseline of one process.
• Build a three-year calculation in three scenarios and find the threshold for the realisation rate.
• Pick the two most influential assumptions and plan a pilot with clear measures and a stop criterion.

For an overview of which processes suit AI agents, see the page on AI agents for mid-sized companies.