The most expensive line on an IT budget is usually the one no business unit has ever seen. A shared data warehouse. An observability stack every team writes to. A container platform, an identity service, an internal agent platform: the plumbing everyone consumes and nobody is billed for. The invoice lands in one cost center, usually IT's or one beside it, and the teams generating the load experience the whole thing as free. Free things get used the way free things always get used.
I have argued before that showback is the cheap, high-leverage move: put consumption next to the name of the person driving it, and behavior shifts without an invoice ever changing hands. That is true, and it is where most organizations should stop. This post is about the heavier instrument, the one you reach for when visibility is not enough. Showback changes behavior. Chargeback changes budgets. When the cost actually moves onto the consuming unit's P&L, the conversation stops being a polite request to be tidy and becomes a number an owner has to defend to their own boss. That is the point of chargeback, and it is also why it is so easy to get wrong.
I should be plain about my vantage. I do not sign the whole IT P&L. I run security and DevOps, a real slice of it, and I report the return on that slice to a board. But I have built the one thing a chargeback program cannot live without and almost never has: a platform that meters consumption at the point where it happens, rather than reconstructing it from an invoice a month later. That is AgentOS, our governed internal agent platform, and most of what I know about why chargeback fails I learned from the metering, not the accounting.
The allocation key is the whole ballgame, not the total
Chargeback is two decisions, and people argue about the wrong one. The visible decision is how much: the total to recover. The decision that actually determines whether the program survives is the allocation key, the driver you divide that total by to decide who owes what. The total is arithmetic. The key is fairness, politics, and behavior, all at once.
A key is one of three things, and the distance between them is the whole subject. It can be direct metered consumption: this team used this many units of the thing, they pay for that many units. It can be a proxy, such as headcount, seat count, revenue share, or a fixed percentage negotiated once, used because the real driver is hard to measure. Or it can be an even split, the peace treaty you sign when nobody can agree. The FinOps Foundation treats allocation as its own discipline for exactly this reason: the taxonomy of who-pays-for-what is harder, and more consequential, than the total everyone fixates on.
One test separates a price from a tax. A metered key changes behavior, because a team can act on it: use less, owe less. A proxy key cannot, because a team's bill has nothing to do with what it did, so it moves money without moving anyone's incentives. If your allocation key is headcount, you have not built chargeback. You have built an internal tax with an IT label on it, and the first budget season it will be treated as exactly that.
Meter what the consumer controls, not what is easy to count
The metering problem is why most chargeback programs quietly die, and it is almost never phrased right. The question is not can we measure it. Modern platforms measure everything. The question is whether you are metering the thing the consumer can actually control. Get that wrong and you have built a bill people resent and cannot act on: the political cost of chargeback with none of the behavioral payoff.
- The wrong driver. Allocating a shared database by stored gigabytes when the cost is driven by query volume. The team with a big, quiet dataset gets billed for load it never creates, while the team hammering it with unindexed queries pays for the disk it barely touches. Meter the driver, not the artifact that was easiest to pull.
- The vanity meter. Precise, auditable, and disconnected from spend: request counts that do not map to cost, dashboard views, lines of log. A meter that measures activity instead of cost feels rigorous and allocates the bill wrong.
- The untagged residual. In any real cloud estate a meaningful fraction of spend arrives without an owner: shared services, cross-cutting network egress, resources no
cost-centertag ever got applied to. That residual does not disappear because you ignored it. It gets smeared across everyone, and the teams with good tag hygiene end up subsidizing the teams with none. - The commitment blender. Reserved capacity and savings commitments buy the platform a discount. Do you charge consumers the blended rate or the on-demand rate? Pass through the blend and a team's unit price now depends on a commitment someone else made and can change. Charge on-demand and the platform quietly books a margin on its own consumers. Either is defensible; choosing neither on purpose is how you end up litigating it every quarter.
- The peak nobody pays for. Capacity is sized for peak and billed on average. The team whose spiky Tuesday-morning job forces you to hold headroom all week pays the same per-unit rate as the team with a flat, predictable load. Average-based metering hides the cost of volatility, and volatility is the expensive part.
The through-line is that a meter is a claim about causation. It asserts: this consumer caused this cost. When the meter measures something the consumer cannot move, the claim is false, and everyone downstream knows the bill is unfair even if they cannot articulate why. Agents make this sharper. An agent's cost is invisible unless the platform meters the run at the moment it executes. When three of our tools disagreed on token counts, I built the metering layer. A number reconstructed from a vendor invoice afterward is guesswork, and guesswork is not something you can charge a team for and expect them to accept.
The unallocatable pool needs a rule, not a debate
Some cost genuinely cannot be metered to a consumer, and pretending otherwise is its own failure mode. The security baseline that protects everything. The platform team's own salaries. The floor of shared infrastructure that exists whether or not anyone leans on it heavily this month. The mistake is treating each quarter's split of that residual pool as a fresh negotiation.
The fix is not a better metric. It is a rule decided once, written down, and left alone: this pool is allocated by headcount, or by each unit's metered share of the directly-attributed cost, or by an even split across consuming teams, so pick one, publish it, and stop relitigating it. Predictability is worth more than precision here. A business owner can plan against a crude rule they can compute in advance. They cannot plan against a number that arrives every month as the output of an argument they were not in. The unallocatable pool should be boring, stable, and explainable on one page. The moment it becomes interesting, the program is losing trust.
Fair enough to self-regulate, not fair
The goal of chargeback is not accounting accuracy. It is self-regulation: consumers who moderate their own demand because they can feel the cost of it. That reframes what good means. Beyond the point where the bill is fair enough that people accept it and act on it, more precision is pure cost: more instrumentation, more disputes, more reconciliation labor, and no additional behavior change. A chargeback program that chases the last five percent of accuracy has usually already failed, because it spent its credibility on decimal places instead of on being predictable and legible.
Fair enough has three properties. It is legible: a consumer can look at the bill and understand, roughly, what they did to earn it. It is stable: the method does not shift under them, so this month's number is comparable to last month's. And it is actionable: there is a lever, visible to the person holding the bill, that makes the number go down. A program with those three properties survives contact with a budget season even when its numbers are approximate. A program with perfect numbers and none of the three does not, because the first time a business unit disputes a line and wins, the whole thing is back to being a suggestion.
Chargeback where there is a real decision, showback everywhere else
None of this argues for charging back everything. The instrument has a cost; spend it only where the consumer has a genuine decision to make. Chargeback earns its political price when demand is elastic, when a team shown the bill can plausibly use less: turn off the idle warehouse, right-size the over-provisioned environment, kill the agent that runs hourly and helps no one. Where demand is inelastic, as with the mandatory security control, the compliance-driven logging retention, or the platform everyone is required to be on, a bill changes nothing except who is annoyed, and showback carries the visibility at a fraction of the friction.
There is a trap on the far side of chargeback, and it is where well-run programs go to die. The moment you bill a business unit a real number, you have implicitly granted them the right to ask why they cannot buy the same thing cheaper somewhere else. Now you are running an internal market you did not staff to run and cannot win on price, and the exit door is shadow IT. Chargeback works when the consumer can act on the signal. It backfires when the only action it invites is leaving. Know which one you are building before you send the first invoice.
If you build one, build it this way
Meter the driver the consumer can actually move, not the number that is easiest to export. Decide the unallocatable-pool rule once, publish it, and refuse to reopen it every month. Optimize for fair-enough-to-act-on over accounting precision: legible, stable, and actionable beats exact. And charge back only where the consumer has a real decision; show back everywhere else, which is most places.
The allocation key is the part you will still be defending two budget seasons from now, so choose it as though it were the program, because it is.