Showback Reporting for AI Spend Teams Will Actually Read

Showback is chargeback without the invoice. Each team sees what its AI usage cost, the money stays in a central budget, and the only lever is visibility. Done properly it changes behaviour almost as much as chargeback does, at a fraction of the organisational friction. Done badly it is a monthly email that everyone filters into a folder.

The difference between the two outcomes is not report design or tooling. It is whether the numbers connect to something the recipient can change this week.

The report has one job

A showback report is not a bill and should not look like one. Its job is to answer three questions for a team lead in under two minutes: what did we spend, what changed since last time, and is anything here obviously wrong.

That third question is the one that produces action. Most of the value in early showback comes from teams recognising their own mistakes — a job left running after a migration, an agent re-reading a repository it does not need, a debug prompt that shipped to production with a huge preamble. Nobody finds these by staring at a total. They find them by seeing a workload they did not expect near the top of a list.

So the report should be ordered by absolute spend, cut by workload rather than by person, and it should surface the largest movers explicitly rather than making the reader diff two tables.

What belongs in it

Five things, and being disciplined about excluding the sixth is what keeps it read.

Total for the period, with the previous period beside it. One number, one comparison. No cumulative year-to-date curve.

A breakdown by workload, sorted descending, truncated at the point where the remainder is a rounding error. Ten lines is plenty. A twenty-line table gets skimmed and a fifty-line one gets ignored.

The biggest change, named. Not just that the review bot rose 60 percent, but that it rose because average input tokens per review went from thirty thousand to seventy thousand after a change on the eleventh. That sentence is written by a person, and it is the most valuable line in the document.

One or two unit metrics. Cost per merged pull request, cost per resolved ticket, cost per processed document — whatever unit the team already uses to describe its own output.

A link to the underlying data. Not an attachment. A query or dashboard link where a curious engineer can get to individual runs. The people who follow that link are the ones who fix things.

What does not belong: token counts as a headline. Tokens are the metering unit, not the quantity anyone reasons about, and putting them at the top makes the report feel like infrastructure trivia. Token accounting for finance covers the translation.

Unit metrics that survive scrutiny

The point of a unit metric is that it separates doing more work from work getting more expensive. Total spend rising is ambiguous; cost per merged pull request rising is not.

A good unit has three properties. The denominator is already counted by the team for other reasons, so nobody has to trust a new measurement. It is roughly proportional to value, so improving it is not obviously gameable. And it is stable enough month to month that a change means something — a denominator that swings by half for seasonal reasons produces a ratio nobody believes.

Cost per merged pull request works well for a code-assistant workload because merges are already tracked and roughly correspond to delivered work. Cost per resolved support ticket works for a triage assistant. Cost per developer per month is the crudest of these and still useful as a sanity check against per-seat tooling. AI cost per pull request and AI cost per developer per month cover how to compute both.

Expect the first challenge to be about the denominator, not the cost. Someone will point out that pull requests vary enormously in size, and they are right. The answer is that the metric is for detecting change over time within one team, not for comparing teams, and comparisons across teams should be avoided in the report for exactly this reason.

Cadence

Monthly is the default and it is usually slightly too slow. A cost problem introduced on the third of the month has run for four weeks by the time it appears in a report, and by then the change that caused it is buried under other work.

The pattern that works is monthly showback plus a weekly digest for the teams whose spend is large enough to matter. The weekly digest is short — total, biggest mover, anything that crossed a threshold — and it lands close enough to the causing change that someone still remembers making it. The monthly report is the one that goes to a lead and includes unit metrics and commentary.

Neither replaces alerting. A report on any cadence is the wrong instrument for a runaway loop, which needs to be caught within the hour. AI cost anomaly detection covers that path.

How showback fails

The dominant failure is that the numbers are not actionable. A team sees that it spent a certain amount, has no idea which of its systems produced it, no baseline for whether that is high, and no lever it controls. The rational response is to ignore the report, and they do.

The second failure is unattributable spend large enough to discredit the rest. If a fifth of the total sits in an "other" bucket, the first question in every review is about that bucket, and the useful conversation never happens. Fix tagging before you increase reporting frequency.

The third is comparison between teams. It feels natural to rank them and it reliably produces defensive behaviour rather than optimisation, because the teams differ in what they do and everyone knows it. Report each team against its own history.

The fourth is the report that only ever goes up and never carries commentary. Growth with no explanation reads as loss of control even when it is entirely legitimate. One sentence of narrative per major mover prevents this.

Knowing when to stop

Showback has a natural end state, and it is worth recognising rather than escalating out of habit.

If teams are acting on the reports — you can point at specific fixes that happened because of a line item — showback is working and chargeback would add administration without adding signal. If the reports have produced no behaviour change over a couple of quarters and spend is material, that is the case for moving money, because visibility alone has been tested and failed. Chargeback models for AI covers what changes when you do.

There is also a scale below which neither is worth it. A team spending a few hundred a month should get a dashboard link and no report at all; the effort of producing and reading a monthly document exceeds anything it could save.

A starting template

One page per team. Total and prior period at the top. Workload table, ten rows, sorted by spend, with a percent-change column. One paragraph naming the largest mover and its cause. Two unit metrics with a six-month sparkline of history. A link to the raw data. Sent monthly, with a three-line weekly digest for the top few teams.

Send it for three months before deciding whether it works. The first report is always mostly discovery of instrumentation bugs, and the second is where the real conversations start.