What AI Really Costs: An Honest Accounting Beyond the License Price

The question “What will this cost us?” gets asked too early and answered too narrowly in AI projects, and regularly so. Too early, because it can’t be answered without a concrete use case. Too narrow, because usually only the license price is named – and that’s rarely the biggest item.

This article walks through the actual cost blocks and shows how to quantify the benefit so the calculation holds up.

The six cost blocks

1. License or usage fee

The most visible item, and usually the smallest. Prices are typically per user per month, sometimes tiered by feature scope. With twenty users and a mid-tier plan, this comes out to a few hundred euros a month – well under what many expect.

Watch for two details: what’s included in the price, and what’s billed by consumption? And: do only active users count, or every account created?

2. Consumption

Language models bill internally by text volume. With flat-rate plans, this is invisible to you. With consumption-based pricing, it can become relevant – especially when large documents are processed or an assistant works automatically in the background.

The practical recommendation: clarify before you start whether there’s a cap and what happens when it’s reached. An unexpected bill is the fastest way to end a successful project.

3. Setup and integration

This is where the biggest one-time item sits. What costs money isn’t the installation, it’s connecting to your systems: integrating with Microsoft 365 or the file server, building the permissions logic, preparing the documents, setting up sign-in through your directory.

The effort depends almost entirely on the state of your environment. A clean, group-based permissions structure keeps this block small. An organically grown file structure with direct permissions makes it large – regardless of which provider you choose.

4. In-house groundwork

The most commonly underestimated block, because it never appears on an invoice. Cleaning up permissions, sorting out outdated documents, establishing one valid version per document, compiling text building blocks, collecting test cases.

This is internal working time, often from people who are already fully booked. Factor this effort in and plan for it — otherwise it becomes the reason the project stalls.

5. Training and support

Two to four hours per team, plus a contact person who is reachable in the first few weeks. This item is small but still decides whether the project succeeds: a tool that nobody can really operate costs the full license fee and delivers nothing. Since February 2025, training is not just advisable but also required under the AI literacy obligation of the EU AI Act.

6. Ongoing operation

Someone has to make sure the connected content stays current, that new employees get access and departing ones lose it, and that feedback is captured. In smaller companies that is only a few hours a month — but it has to belong to someone.

The cost trap nobody plans for

There is one item that appears in no calculation and still occurs regularly: the restart. It happens when a tool is procured first and a use case is sought afterward. After six months it turns out the solution doesn’t fit the actual need, and you start over.

The most reliable way to avoid this item is the order of operations: the use case first, the solution second.

How to put a solid figure on the benefit

Blanket productivity promises don’t help. The calculation becomes solid once you build it around one concrete process. The pattern is always the same:

• How often does the process occur per month?
• How long does it take today on average — honestly measured, not estimated?
• What share of that is searching, assembling, and formatting?
• How much of that realistically goes away? Calculate conservatively.
• What is an hour worth in this area?

The honest answer to the fourth question matters most. If a quote takes three hours today and two of those hours go to searching and assembling, a saving of one hour is realistic — not two and a half.

Benefits that are hard to calculate and still count

Some effects are hard to express in euros and are often the more important ones in practice.

Processes that previously didn’t happen at all. Tenders that were skipped for lack of time. Quotes that arrived too late. When processing becomes markedly faster, the volume changes, not just the duration.

Knowledge that is preserved. With retirements coming up, making existing documentation accessible can be worth more than any time saving.

Fewer errors. A flag on a changed bank account, a contradiction spotted in a quote, a duplicate payment avoided.

Relief at bottlenecks. When one person is the bottleneck for an entire department, any relief has an outsized effect.

A rough orientation

For a mid-sized company with twenty to fifty users and a clearly defined first use case, the rule of thumb is: the one-time effort for integration, groundwork, and training clearly exceeds the first year’s license costs. From the second year on, the ratio reverses, and every further use case is considerably cheaper because the groundwork is already in place.

This has an uncomfortable but useful consequence: whoever stops after six months has only paid for the expensive part.

The question that comes before the cost question

Before comparing quotes, answer this: which specific process should get faster or better, how often does it occur, and who in-house is responsible for the changeover? With these three answers, any quote becomes comparable. Without them, you’re comparing prices for different things.

These are exactly the questions we ask in the initial conversation — and we’ll tell you honestly even when deploying it at a particular point isn’t worthwhile.

A worked example to replicate

To make the method tangible, here is a calculation you can fill in with your own numbers. Let’s take quote preparation in a company that writes forty quotes a month.

A quote takes an average of three hours today. Experience shows that around two hours of that go to searching, assembling, and formatting, and one hour to argumentation and coordination. If, conservatively, half of the two mechanical hours goes away, that is forty hours a month. Multiplied by your internal hourly rate, that gives you the monthly benefit.

Set against that are: the license costs for the people involved, a one-time effort for integration and cleanup, and the internal working time for groundwork and training. Spread the one-time effort over twelve months, and you’ll see in which month the calculation tips in your favor.

Honesty about the time saved matters. Anyone who calculates with a saving of two and a half of the three hours is building a number that won’t hold up in practice — and loses credibility for the next project as a result.

The cost of doing nothing

For completeness, the other side of the calculation should include what continues unchanged without action: quotes that arrive too late. Tenders that go unanswered. Knowledge that disappears with retirements. And the time employees are already investing today in unapproved tools, without the company gaining anything from it.

These items can’t be pinned down exactly. But leaving them out entirely produces a calculation that is systematically biased against change.

Frequently asked questions

What is the most commonly underestimated item?

The internal working time for groundwork — permissions, filing, test cases. It never appears on any invoice and is still the reason projects stall. Plan for it explicitly.

Is this worthwhile for ten employees?

It’s not the number of employees that decides, but the frequency of the process. Ten people who write quotes daily have a clearer case than a hundred who do it once a month.

How do we avoid a cost surprise?

Clarify before you start whether billing is usage-based, whether there is a cap and what happens when it’s reached. And whether only active accounts count, or every account created.

What does switching providers later cost?

That depends on whether you can export configuration, templates, and integrations. Ask this before signing the contract — afterward it’s no longer up for negotiation.

Three worked examples

So the method doesn’t stay abstract, here are three cases of different sizes. The numbers are placeholders to replace, not benchmarks — the calculation method is what transfers.

Case A — trade business, 25 employees, quote preparation. Fifteen quotes a month, two hours each, of which a good one hour is searching and assembling. At a conservatively assumed half saving, that’s around eight hours a month. Set against that are license costs for five users plus a one-time effort for integration and cleanup. The calculation only holds up here if the hourly rate is high or the cleanup effort is low — a borderline case that should honestly be labeled as such.

Case B — IT systems house, 80 employees, quotes and tenders. Forty quotes a month, three hours each, two of them mechanical. Half a saving comes to forty hours a month. On top of that comes an effect that makes up the real impact: tenders that used to be declined for lack of time now get handled. At this size, the project typically pays off within the first year.

Case C — manufacturing company, 200 employees, document processing. Eight hundred incoming invoices a month. The time saving per document is small; the volume makes the difference. But the bigger item lies elsewhere: in the early-payment discounts that currently lapse because of long approval chains. That figure is already in your accounting and is the most convincing part of the calculation, because nobody has to estimate it.

What all three cases show: headcount is not the driver. What matters is how often the process occurs and how large the mechanical share is.

When recalculating is worthwhile — and when it isn’t

There are situations where a detailed cost-benefit calculation takes more effort than the insight it delivers.

With a standard plan for a small group, the monthly costs are so low that the calculation is pointless. Here the relevant question isn’t whether it pays off, but whether the data is protected and whether someone is overseeing its use.

With a project with significant implementation effort, the calculation is always worthwhile — not because the result comes as a surprise, but because gathering the baseline figures forces you to examine the process closely. This side effect is regularly more valuable than the final number.

With a project that solves a knowledge problem — upcoming retirements, dependence on individual people — pure time-based calculations are misleading here. The question isn’t how many hours you save, but what it costs if that knowledge disappears.

A negotiating tip

Two items are often calculated too tightly in quotes and turn out expensive in the project: integration with existing systems and support after launch. Have both itemized separately and ask explicitly what happens if the integration turns out to be more involved than assumed.

The reverse also holds: a quote that openly names the groundwork needed on your side, rather than glossing over it, is usually the more realistic one — even if it looks more expensive at first.