Chargeback allocates AI agent costs to internal budgets and actually moves the charge; showback reports the same allocation for visibility without moving any money. Both require attributing spend to the team, product, or agent that generated it — the difference is entirely in what happens with that attribution once you have it.
The Core Distinction
Showback tells a team what their AI agent usage costs, on a report or dashboard, without changing anyone's budget. No money moves. The purpose is visibility and behavior change through awareness — a team that sees its agent costs trending up has a reason to investigate, even though nobody is debiting their P&L.
Chargeback takes the same cost data and applies it as an actual charge against the consuming team's budget. The team's finance owner sees a real line item, and the cost becomes part of how that team is evaluated financially. This is a bigger step, both organizationally and technically, because a number that only informs a conversation can tolerate more slack than a number that debits someone's budget.
Neither model is inherently better. The choice depends on your cost attribution maturity, your organizational appetite for internal billing disputes, and whether you need cost accountability to actually change behavior or just to be visible.
Why Attribution Accuracy Is the Real Gate
The technical prerequisite for both models is the same: every unit of AI agent spend needs to be attributable to a consuming team, product line, or cost center. What differs is the accuracy bar.
For showback, attribution needs to be directionally right. If a report attributes a share of the shared agent budget to Team A and the true figure is a few points off, nobody's compensation or budget changes as a result — the report still does its job of surfacing a trend. Rough attribution beats no attribution.
For chargeback, attribution needs to survive a dispute. If Team A is charged for spend it can show it didn't generate — because the attribution logic double-counted a shared workflow, or mis-tagged a run to the wrong cost center — that dispute becomes a recurring finance-versus-engineering fight that erodes trust in the entire program. Chargeback attribution needs an audit trail precise enough to answer "show me exactly which task runs produced this charge" for any contested figure. See Spend Attribution Per Agent and Showback for the attribution mechanics that both models depend on, and Tracking Per-Connection AI Usage and Cost for attributing spend at the integration level rather than just the agent level.
A Decision Framework
Use the following as a sequence of gates, not a one-time choice:
| Question | If no | If yes |
|---|---|---|
| Can you attribute spend to a specific team or cost center for every task run, not just in aggregate? | Fix attribution before choosing either model | Continue |
| Has that attribution run for at least a few billing cycles without a disputed figure? | Start with showback | Chargeback is viable |
| Do you have an explicit rule for splitting shared-resource costs (a shared agent, a shared model deployment)? | Resolve the split rule first — undefined splits break both models | Continue |
| Does your organization already run chargeback for other shared infrastructure (compute, storage)? | Showback may be a smaller organizational lift to start | Chargeback fits existing finance process |
| Is the goal primarily awareness, or does a team's budget actually need to shrink in response to cost data? | Showback if awareness is sufficient | Chargeback if budget consequences are required |
The typical adoption path runs showback first. Reporting spend without moving money lets you validate the attribution pipeline against real disputes in a low-stakes setting — if a team disagrees with a showback number, you fix the attribution logic without anyone's budget having been touched. Once attribution has held up cleanly across multiple cycles, chargeback becomes a lower-risk move.
Handling Shared Costs
Agent programs rarely map cleanly to one team's budget. A shared agent might serve multiple product lines; a shared model deployment or guardrail layer sits underneath every workflow that uses it. Neither chargeback nor showback works without an explicit rule for splitting these shared costs.
Common allocation rules, in increasing order of precision:
- Even split across consuming teams — simplest, but inaccurate if usage is lopsided.
- Proportional to task volume — each team's share tracks the number of task runs it generated.
- Proportional to measured resource consumption — token count, tool calls, or compute time attributed per team, which tracks actual cost drivers rather than a proxy like task count.
- Proportional to outcome value — rarely used for cost allocation, but relevant when a shared agent produces very different value per task across teams and a flat cost split would penalize the highest-value user.
Whichever rule you pick, document it and apply it consistently. An allocation rule that changes without notice, or that a finance owner cannot reconstruct from the underlying usage data, undermines trust in the whole exercise regardless of which model — chargeback or showback — you're running.
Failure Modes to Watch For
Chargeback too early. Applying real budget debits before attribution has stabilized generates disputes that could have been resolved for free during a showback phase. Each unresolved dispute costs credibility for the next billing cycle's numbers, even after the underlying attribution bug is fixed.
Showback with no consequence, indefinitely. Showback is a starting point, not a destination, for spend that's material enough to warrant accountability. A team that sees escalating agent costs on a dashboard every month with no budget consequence has limited incentive to optimize. If the numbers are large enough to matter and stable enough to trust, staying in showback indefinitely leaves cost ownership diffuse.
Attribution gaps hidden inside an aggregate. A report that shows total organizational agent spend without a reliable per-team breakdown is neither chargeback nor showback — it's just a bill. Both models require the breakdown to be the primary artifact, not an afterthought.
No connection to budget enforcement. Reporting a cost after the fact, whether as chargeback or showback, doesn't stop a runaway agent from generating that cost in the first place. Both models are retrospective; pair them with the budget enforcement covered in How to Set Budgets for AI Agents and Budgets vs Rate Limits: Controlling Agent Consumption so cost visibility and cost prevention work together rather than one substituting for the other.
Common Questions
Can we run chargeback for some teams and showback for others?
Yes, and this is common during a transition. Teams whose attribution has proven reliable and whose costs are material enough to warrant budget consequences move to chargeback first; teams with newer or smaller agent programs stay in showback until their numbers stabilize. Document which teams are on which model and why, so the distinction doesn't look arbitrary.
What granularity of cost data does either model actually require?
At minimum, cost per team or cost center per billing period. Better programs break this down further — per agent, per model, per workflow — so a team disputing a charge or reviewing a showback report can see which specific agent or workflow drove the number, not just the total. Coarser granularity works for showback longer than it works for chargeback, since disputes over an aggregate figure are harder to resolve without a breakdown.
How does this differ from the FinOps loop we already run for budget alerts and caps?
Budget alerts and hard caps, as described in FinOps for AI Agents: Controlling Token and Tool Costs, are forward-looking controls that stop spend before or as it happens. Chargeback and showback are backward-looking allocation models applied to spend that already occurred. You need both: the FinOps loop prevents runaway costs, and chargeback or showback decides who's accountable for the costs that were incurred within budget.
Does the choice between chargeback and showback affect how granular our cost attribution needs to be from day one?
Not from day one, but it should shape the roadmap. If chargeback is the eventual goal, design the attribution pipeline with an audit trail in mind from the start — capturing which task run, which agent, and which cost center generated each unit of spend — even while you're still operating in showback mode. Retrofitting audit-grade attribution onto a reporting pipeline that was only ever built for directional accuracy is more expensive than building it in from the outset, even if chargeback itself is a year away.
Who typically owns the decision to move from showback to chargeback?
In most organizations this is a joint call between the platform or engineering team that owns the attribution pipeline and the finance function that owns internal cost allocation policy more broadly. Neither side should make the call unilaterally — engineering can confirm the data is reliable enough, but finance needs to confirm that chargeback fits how the organization already allocates other shared costs before introducing a new billing relationship between teams.
What Good Looks Like
- Cost attribution is accurate enough for showback before chargeback is ever proposed.
- Shared-resource cost splits are documented and applied consistently, not renegotiated informally each month.
- Disputed figures during a showback phase get resolved by fixing attribution logic, not by ignoring the complaint.
- Teams on chargeback can trace any contested charge back to specific task runs.
- The allocation model is reviewed periodically as agent usage patterns shift across teams.