Why your AI bill moved and nobody can tell you what changed

Infrastructure cost used to be nearly fixed. You sized a server, you paid for the server, and the number moved when you decided it should. Model spend does not behave that way. It is variable per use, per user and per model choice, and it can move by an order of magnitude in a month with no deployment and no decision.

That is the actual change. The cost of running something stopped being a line in a budget and became a live number that responds to behaviour. Most finance processes have no place to put a number like that.

A bill is organised the way the provider sells. A decision is organised the way the company runs. Nobody’s invoices are shaped like their business, and that mismatch is where the confusion lives.

One thing you run sits on a hosting account, a database project, one or two model providers and a drift of subscriptions. Each bill is organised around its own vendor’s internal structure, and none of them knows the four together are one thing. The join exists in exactly one place: a spreadsheet somebody rebuilds by hand each month, or more often does not.

So when the total moves, the question "which part of the business did that" has no available answer. Not because the data is missing — because it is never assembled.

In our experience there are four common causes, in roughly this order of frequency:

• A default that nobody chose. A library or SDK upgrade changes the default model, and the new default is four times the price of the old one. No code review flags this, because nothing in the diff looks like a cost decision.
• A feature that succeeded. Usage grew where you wanted it to grow. This is good news presented as a scare, and you can only tell it apart from bad news if spend is attributed to something.
• Retries and long context. A failure path that retries three times, or a prompt that quietly carries a growing history, multiplies the same work without any visible change in behaviour.
• Individual subscriptions. Per-seat AI tools bought department by department, none large enough to question, collectively larger than the platform bill.

Knowing the bill is bookkeeping. Knowing what one thing costs against what it brings in is a business fact — and it is the one almost nobody has.

Add one number a month from outside the provider accounts: revenue, customers, or active users for each thing you run. The set stops being ranked by what it spends and starts being ranked by whether the spending was worth it. The thing with the largest bill and the thing with the worst economics are usually not the same one — and only the second is worth acting on.

A cost that moved for reasons you cannot reconstruct is worse than no cost at all, because you will make a decision on it anyway.

Be clear about the limit. Reading closed months tells you what happened and what it was worth. It cannot cap a budget, block a spend, or warn you about a spike this afternoon — that is a control problem, and control belongs upstream of the bill, in how the work is routed in the first place.

Be equally clear about provenance. Every number should say how it was made: invoice-exact where the provider states the amount, apportioned where a total is split by a visible rule, estimated where no invoice exists and cost is reconstructed from plan and usage. Shared costs are either apportioned visibly or held above the group — never divided silently.

Take last month, not this one. Closed months are the only ones you can reason about. Pull every provider bill you received, group each line under the thing that consumed it, and put one business figure beside each group.

It takes an afternoon the first time and it usually changes at least one decision that was already on the table. That is the whole test.