Why nobody can say what the cloud and AI bill actually buys

The spend is rarely out of control because the engineering is wasteful. It is out of control because the invoice has no owner, so every conversation becomes an argument about blame. Only 49% of organisations track unit economics at all, and 98% of FinOps teams now manage AI spend that arrived before anyone decided how to attribute it.

The bill is up again. Somebody asks what drove it. The answer takes two weeks to assemble and nobody fully believes it.

The instinct is that engineering is wasteful. Usually it is not. The bill arrives as one number, and one number cannot be governed by anybody.

Four reasons, none of them waste

Four reasons the bill cannot be governed

None of them is engineering waste. All four are attribution problems, and they have to be fixed in a different order from the one most programmes use.

The fourth is the newest and the fastest moving. 98% of FinOps teams now manage some form of AI spend, up from 31% two years ago, and most of that arrived before anyone decided how to attribute it.

Source: FinOps Foundation, State of FinOps 2026, the sixth annual survey of the FinOps community: 1,192 practitioners representing more than $83B in annual cloud spend.

The invoice has no owner. It arrives to one person who forwards it. Every discussion about it becomes an argument about blame rather than a decision about value, because nobody in the room caused a number they can point to.

Shared cost has no stated method. Networking, storage, platform overhead and the data team sit in a pool nobody accepts as theirs. An unstated allocation method is what makes every recipient dispute the figure rather than act on it.

The reported unit is consumption, not outcome. Cost per compute hour, cost per gigabyte, cost per seat. Those tell you how much you bought. None of them tells you whether it was worth it.

AI spend arrives under one key. A single organisation-wide API key, so no use case can be separated from another, and no history exists to separate them retroactively.

Where the discipline actually is

Where the discipline actually is

Reported by FinOps practitioners about their own organisations. The gap between the first bar and the last is the whole problem.

• FinOps teams managing some form of AI spend
• FinOps practices reporting into the CTO or CIO organisation
• Organisations with a dedicated FinOps team
• Organisations tracking unit economics

Source: FinOps Foundation, State of FinOps 2026: 1,192 practitioners representing more than $83B in annual cloud spend. AI spend management rose from 31% two years ago and 63% last year; unit economics tracking rose 9 points year over year; CTO or CIO reporting is up 18 points against 2023.

The FinOps Foundation's State of FinOps 2026 is the sixth annual survey of its community, covering 1,192 practitioners representing more than $83 billion in annual cloud spend. Four figures from it are worth holding together.

98% of FinOps teams now manage some form of AI spend, up from 63% last year and 31% two years ago. 78% of FinOps practices report into the CTO or CIO organisation, up 18 points against 2023. 63% have a dedicated FinOps team. And 49% track unit economics, up 9 points year over year.

Read the first and last together. Nearly every practice is now responsible for AI spend, and about half of organisations still cannot say what any of their spend buys per unit of work. The responsibility arrived faster than the measurement.

The 49% is the figure to sit with. It means half of organisations can answer how much they spent and not whether it was worth spending, which is a different question and the only one a budget review is actually asking.

Why the unit matters more than the total

A platform cost that rises while the work it supports rises faster is working.

That sentence is the whole argument for unit economics, and it is why the absolute bill going up is not on its own evidence of a problem. Without a denominator, a rising bill and a growing business look identical on the invoice, so the conversation defaults to cutting rather than to deciding.

The denominator should be a unit of business outcome: an order, a claim, a report, an active customer, a processed document, a resolved ticket. One per product area. Then cost per unit, with the method written next to it so somebody else can recompute it next quarter.

The AI version is worse, and newer

AI spend is the hardest of the four reasons because it arrived fastest.

Going from 31% of FinOps teams managing it to 98% in two years means most of that spend was provisioned before anyone decided how to attribute it. In practice that means one API key, one project, and a line on the invoice that cannot be decomposed.

The cost of leaving it rises with volume, because you cannot retroactively separate what was never separated. A key or a project per use case is cheap now and impossible to backfill later.

There is a second trap specific to AI, which is that pilot figures mislead badly. A pilot runs at low volume with short context windows and an expert handling the failures. The same workflow at production volume, with real document lengths and real retry behaviour, is a different per-unit number. That is covered in cut the bill or fix attribution first, and the recurring costs that get left out of a first-year quote are in what an AI system costs in year two.

What an unowned estate costs

What an unowned estate costs, in seven engagements

Published annual figures. In each case the estate had accumulated because each addition was individually reasonable and nobody held the total.

Three of these landed the residual near a quarter of the prior cost: $4.7M to $1.1M, $1.9M to $420K, $1.3M to $310K. Three data points rather than a benchmark, and enough to make the question concrete when a proposal claims a figure.

Source: Thinklytics case library, published delivery outcomes per engagement.

Seven engagements in our case library published the annual figures, and the pattern across them is that each addition was individually reasonable and nobody held the total.

A cloud provider had let 14 business units each build their own data warehouse over eight years: $4.7M a year to maintain, no shared metrics, no cross-unit reporting. A casino group ran five property management systems at $1.9M. A credit union carried four core banking systems after three acquisitions at $1.3M. A retailer was running 220 store reports that rested on only 40 distinct metrics, at $890K a year of reporting labour.

Three of those landed the residual near a quarter of the prior cost: $4.7M to $1.1M, $1.9M to $420K, $1.3M to $310K. Three data points rather than a benchmark, and enough to make the question concrete when a proposal quotes a figure.

It is an ownership problem, and the evidence is in the failures

The cloud provider case is the instructive one, because the first attempts failed.

The CTO had ordered a consolidation and previous efforts had stalled, not on technology but on business unit resistance. The engagement that worked did not overcome that resistance, it removed the reason for it: each unit kept control of its own data and published it through a shared catalogue with standard interfaces, migrated in groups of three over 30 weeks.

By week 30 all 14 units were integrated, the cost had fallen from $4.7M to $1.1M a year, cross-unit revenue and customer overlap reporting existed for the first time, and there were zero business unit escalations. See the federated data mesh engagement.

Changing who owned the data was the intervention. The architecture followed from it.

What we would do first

Two numbers, before any target is set.

Total spend in scope by provider and by month, for twelve months so seasonality is visible. Then the share of that total a named person would recognise as theirs. Attributed means recognised, not tagged.

The second figure is usually far lower than expected, and the gap between the two is the whole project. Resist setting a reduction target before it exists, because a target with no baseline cannot be checked afterwards and the second year's request will not be believed.

Which to fund first, and in what order, is in cut the bill or fix attribution first.

Delivery sits in cloud and AI cost optimization for the attribution and the engineering levers, system consolidation where the estate itself is the cost, and data foundation for the platform layer the spend is buying. The full set of work in this area sits under the platform bill keeps climbing.

Frequently asked questions

Why does the cloud bill keep climbing with no explanation?

Four reasons, and none of them is engineering waste. The invoice has no owner, so it arrives to one person who forwards it and every discussion becomes an argument about blame. Shared cost has no stated allocation method, so networking, storage and platform overhead sit in a pool nobody accepts. The reported unit is consumption rather than outcome, so the number says how much you bought and not whether it was worth it. And AI spend arrives under one organisation-wide key, so no use case can be separated from another.

What does the FinOps data say about where organisations actually are?

The FinOps Foundation's State of FinOps 2026, its sixth annual survey of the FinOps community, covers 1,192 practitioners representing more than $83 billion in annual cloud spend. 98% of FinOps teams now manage some form of AI spend, up from 63% last year and 31% two years ago. 78% of FinOps practices report into the CTO or CIO organisation, up 18 points against 2023. 63% have a dedicated FinOps team. And 49% track unit economics, up 9 points year over year.

Why is 49% tracking unit economics the number that matters?

Because it means half of organisations cannot answer whether the spend was worth it, only how much of it there was. Cost per compute hour or per gigabyte tells you what you bought. Cost per order, claim, report or active customer tells you whether the platform is earning its bill. A platform cost that rises while units rise faster is working, and only the per-unit figure shows that, so the absolute bill going up is not on its own evidence of a problem.

Why is AI spend harder to attribute than cloud spend?

Because it arrived faster than anyone's attribution model. 98% of FinOps teams now manage AI spend against 31% two years ago, and most of that growth happened under a single organisation-wide API key, so there is no per-use-case history to recover. The fix is a key or project per use case, and the cost of not doing it rises with volume, because you cannot retroactively separate what was never separated.

What does an unowned estate cost in practice?

In seven engagements in our case library, the annual figures were published. A cloud provider ran 14 business unit data warehouses built independently over eight years at $4.7M a year, reduced to $1.1M. A casino group ran five property management systems at $1.9M, reduced to $420K. A credit union ran four core banking systems after three acquisitions at $1.3M, reduced to $310K. A retailer was running 220 store reports that rested on only 40 distinct metrics, at $890K a year of reporting labour.

Is this a technology problem or an ownership problem?

Ownership, and the clearest evidence is what happens when a programme ignores that. A cloud provider's earlier consolidation attempts had stalled on business unit resistance rather than on technology. The engagement that worked gave each unit ownership of its own data and published through a shared catalogue instead of centralising it, and recorded zero business unit escalations across 30 weeks while taking the cost from $4.7M to $1.1M.

Should we start by cutting cost or by fixing attribution?

Attribution, with the fast engineering levers running in parallel. A reduction target handed to someone who cannot see their own consumption is a request they cannot act on, and a saving nobody owns is the one that comes back. Attribution also tends to produce a real reduction before any engineering, because a team that can see what it is running switches off what it was not using.

Where should we start?

Write down the total spend in scope by provider and by month for twelve months, then the share of it a named person would recognise as theirs. Two numbers. The second one is usually far lower than expected, and the gap between them is the whole project. Do not set a reduction target before that figure exists, because a target without a baseline cannot be checked afterwards.

The work behind this

Nine engagements in the case library carry cost optimization, and seven published an annual before and after figure. Three of them landed the residual near a quarter of the prior cost, including a 14-warehouse estate that went from $4.7M a year to $1.1M with zero business unit escalations.

Cost optimization, 9 engagements.