FinOps for AI: Who Gets the Invoice After Go-Live

FinOps for AI is cost discipline applied to the running bill of an AI system: make its spend visible, attribute it to an owner, and express it in a unit the business recognises. In the organisations I work with, the arithmetic is the easy part. The hard part is deciding who gets the invoice before go-live, because once an AI system runs, its bill arrives somewhere, and usually somewhere nobody chose.

My reader here is the person who will be asked about that invoice: the IT manager, informatiemanager or CIO of an organisation of 250 to 5,000 people, with an ICT partner or an internal IT team already in place and a specialist AI supplier on the way in. My company is such a supplier. We build AI systems; we do not run your infrastructure or your cloud contract. That position gives me a clear view of a moment most projects handle badly: the first month after go-live, when the build invoice has been paid and the metered bill starts to arrive.

Why does AI running cost not fit an IT budget?

Most IT budgets in organisations of this size are built from things that behave politely. Licences priced per seat. Support contracts priced per year. Hardware written off over a fixed number of years. Even public cloud, which broke that pattern a decade ago, has by now been tamed in most IT departments with reserved capacity, tags and a monthly review.

The running cost of an AI system breaks the pattern again, in three ways at once.

• It is billed per unit of consumption that your finance system has never seen. Model providers price per token, and a token means nothing to a controller.
• It varies with behaviour rather than with headcount. The same system costs more in a month with longer documents, more exceptions or an agent that pulls far more context into each step than the task needs.
• It often lands in a cloud subscription that the ICT partner administers, under a cost centre that was created for infrastructure, so the person who sees the spike is not the person who caused it or the person who can change it.

None of this is a mystery about price. Rate cards are published. What nobody knows in advance is the volume: how many cases, how long each one is, how many retries, how much context each call carries. That is the variable that decides the bill, and it is the one most business cases leave blank.

The discipline that handles this already exists. The FinOps Foundation's sixth State of FinOps survey, published in February 2026, reports that 98% of its 1,192 respondents now manage AI spend, up from 31% two years earlier. Read that figure carefully. It is a survey of FinOps practitioners, so it tells you the practice has arrived in organisations that already have a FinOps team. It says nothing about whether yours does. In the mid-sized organisations I meet, the honest answer is usually that one controller and one cloud engineer share the job between other work.

What did the 2023 energy price cap teach about capping a bill?

Every Dutch reader will remember the prijsplafond. For all of 2023, households and other small consumers paid at most €0.40 per kWh of electricity up to 2,900 kWh and at most €1.45 per cubic metre of gas up to 1,200 m³. Above those volumes, as the government announced in December 2022, you paid the rate in your own energy contract. In the same announcement the cabinet expected 50 to 60 percent of households to fall under the cap with their entire consumption. Which means it expected the rest not to.

That is the first lesson, and it transfers directly. A cap on the price is not a cap on the bill. The contract you sign with a model provider, or the rate your supplier quotes, fixes the price per unit. It fixes nothing about the number of units. I have sat in meetings where an AI system's cost was declared under control because the token price had been negotiated down, while nobody in the room could say how many documents the system would read in a busy month.

The second lesson is less obvious and more useful. The consumption ceiling was not spread evenly over the year. Because most households burn far more gas in winter, the scheme worked with day volumes: you were allowed a larger share of the ceiling in the first and last months of the year and less in between. Radar worked out what that meant per month, and pointed out that you could stay within the yearly total and still go over it in one period.

An AI budget split into twelve equal months makes the mistake the scheme was designed to avoid. An invoice-processing system peaks at month-end and harder at year-end. A customer-service agent peaks after a holiday and after every product change. A tender-reading assistant follows the tender calendar. If the monthly budget line is the annual figure divided by twelve, the alert will fire in exactly the months the system is doing its most valuable work, and someone will be tempted to switch the system off.

The analogy has limits, and I should name them. Energy was a necessity, and a household could only cut its use so far. An AI system's consumption is a design choice: which model, how much context, when to stop, when to hand a case to a person. That is the good news. The volume that decides the bill is far more controllable than a cold February. A note for Flemish readers: the prijsplafond was a Dutch scheme, and Belgium handled the same energy crisis with its own measures, so this is a Dutch memory rather than a shared one.

Who should get the invoice for an AI system?

Cost allocation for AI starts with a plain question: who pays the running bill? In practice it lands in one of three places.

• On the supplier's account. The supplier holds the contract with the model provider and passes the cost on, sometimes with a margin, usually as one line on a monthly invoice. Simple to start, and you lose sight of what drives the number.
• In the ICT partner's subscription. The cost is technically visible, but to the party that did not build the system and has no say in how it behaves. The alert goes to a mailbox, and the mailbox belongs to someone whose job is uptime.

• In your own tenant, under your own agreement with the model provider or your existing cloud contract, tagged to the system and assigned to a budget holder inside your organisation.

My view is that it belongs in the third place, and I say so in the first meeting even though it makes my company's invoices smaller and simpler. The reasons are practical. You see the raw usage rather than a summary of it. Nobody earns a margin on volume, so nobody has a quiet reason to prefer more of it. And the account is part of your exit: in the AI capability you should not outsource I argued that whoever holds the evaluation set can change supplier. Whoever holds the model account can change supplier without a migration project first.

The budget holder should be the business owner of the process the system serves: the head of finance for invoice processing, the head of customer service for the service agent. IT should see the spend and own the technical controls, because IT can act on them at two in the morning. Splitting it that way mirrors what most organisations already do with a business application. The one thing that does not work is a cost with no budget holder at all, parked under an infrastructure cost centre until the annual review finds it.

There is a fair case for starting on the supplier's account. In a pilot, getting a new cloud resource approved can take longer than the pilot itself. I have no objection to that, provided a date is written down on which the account moves to you, and the supplier sends the raw monthly usage export rather than an invoice line in the meantime.

Should finance see tokens or cases?

Tokens are for engineers. A controller cannot judge whether 40 million tokens in March was good or bad, and should not have to. What a controller can judge is the cost per handled invoice, per answered ticket or per processed dossier, set next to what the same case costs when a person handles it. That is the number that tells you whether the system is worth running, and it is the same unit you should have used to judge the pilot. If you have not, measuring AI ROI starts from the same place.

Getting there is a build requirement, not a reporting exercise. The cloud side of the bill is standardising: the FinOps Foundation reports in the same release that all major clouds now generate data in FOCUS, its open cost and usage format, natively. That gives you cost per resource. It does not give you cost per case, because one model deployment often serves several use cases, and a resource tag cannot tell them apart. The system itself has to label every model call with the use case and the case it belongs to, and write that to a log your controller can read. If you are commissioning an AI system, put that in the specification. Adding it later means touching every call the system makes.

Report the cost per case as a median and a tail, not as an average. Most cases cost little. A few cost a great deal: the 300-page contract, the email thread with forty attachments, the case where the agent retried six times. The average hides both, and the tail is where design decisions pay off. A rule that sends any case above a certain size to a person, or to a smaller model for a first pass, often does more for the bill than any discount on the rate card.

Showback or chargeback: where should an IT organisation start?

The usual sequence in cloud cost management runs from showback, where each team sees what it consumes without paying for it, to chargeback, where the cost is booked against the consuming department's budget. For AI I would hold the first step for longer than most organisations want to.

Charging a department for a cost it cannot influence produces arguments rather than savings. In the first months after go-live the cost per case moves for reasons the business owner does not control: the supplier tunes a prompt, the ICT partner changes a logging setting, a new model version arrives. Show the numbers every month, with the cost per case and the volume side by side, until both have been stable through at least one full business cycle, including the peak. Then move to chargeback, and only for the part of the cost that follows the department's own volume.

Alongside showback, set a monthly ceiling with an alert below it, not at it. In who gets paged when the AI breaks I listed a cost spike as one of four AI incident types and gave it to IT with a ceiling agreed before go-live. This is the other half of that decision: what the system does when it reaches the ceiling.

A hard stop is an outage of a business process, decided by a billing threshold. Sometimes that is right. More often the better answer is to degrade: switch to a smaller model, stop the optional steps, or queue new cases for a person until the next period. Each of those has to be built in advance, so decide which one you want before the system is designed, not when the alert fires.

What should the supplier contract say about running cost?

Most AI contracts I see describe the build in detail and the running cost in one sentence. These are the points I would want written down, whichever supplier you choose.

• Whose account the model usage runs on, and who owns that account at the end of the contract.
• A run-cost estimate expressed per case, with its assumptions stated: monthly volume, typical document length, the share of cases expected to need more than one pass.
• A monthly usage export in a format your controller or FinOps lead can load, labelled per use case.
• Who may change the model, the prompt or the context size, given that each of those changes the cost per case, and the rule that such a change goes through your change process like any other.
• What the system does at the budget ceiling: stop, degrade, or queue for a person.
• Whether the supplier adds a margin to pass-through usage, and if so, how much.

None of these is exotic, and none costs much to agree before signing. Every one of them is expensive to agree afterwards. For the build side of the same budget, the build and run cost of custom AI sets out what drives the number.

What I tell an IT manager in the first meeting

The question in the first meeting is rarely what the system will cost to run. It is where the invoice will land and who can change the number on it. If the answer is a cost centre nobody owns and a supplier nobody can see into, the project has a problem that no rate card will fix.

So I ask for three things before we design anything. A budget holder from the business, named. An account in your tenant, or a date when it moves there. And the unit you will judge the system by, written down as a case rather than a token. With those three in place, the rest of FinOps for AI is the same discipline your organisation already applies to cloud, extended to a bill that moves with behaviour. Without them, the first month after go-live becomes a search for the person who owns the spike. That is the seam we work on, alongside your IT team and your ICT partner, in AI implementation for mid-sized organisations.

Frequently asked questions