Attribution produces a number per team. This chapter is about what happens to that number, and it is the point where a cost programme either changes behaviour or becomes a monthly email nobody opens.
The vocabulary is worth fixing first, because it is used loosely.
- Showback — the team is told what it spent. No money moves.
- Chargeback — the team's own budget is debited. Money moves.
The industry argument treats these as a maturity ladder with chargeback at the top. That framing is wrong often enough to be worth resisting. The question that decides the outcome is not how hard the mechanism is, but whether the number lands on someone with both the authority and the technical ability to change it. A chargeback to a team that cannot alter the architecture generating the cost is a tax, and teams respond to taxes by disputing the assessment rather than reducing the spend.
The constraint that sets your start date
Before designing any of this, there is a hard limit worth internalising, and Azure documents it plainly: resource tags are only included in usage data while the tag is applied, and tags "aren't applied to historical data or to future data, after the tag is removed." Azure also notes that resource tags only appear in Cost Management after the data has been refreshed, and that a tag applied less than 24 hours ago may not have surfaced yet.
Three consequences follow, and they are the ones teams discover late.
- Allocation cannot be backdated. The first month of a chargeback programme is the month you finished tagging, not the month you started the project. Anyone promising retroactive allocation is promising to model it, which is a different claim.
- Removing a tag erases future attribution, not past attribution. Untagging a resource does not rewrite history — it stops the flow. Half-finished retagging exercises therefore produce a discontinuity in the middle of a reporting period, which looks exactly like a real cost movement.
- There is a lag between tagging and seeing it. A tag applied today is not necessarily in today's report. Reconciling a report against the console on the same day will show differences that are timing, not error.
The practical rule: freeze the taxonomy, complete the tagging, wait a full billing period, and only then publish the first allocation. A number published mid-migration will be wrong in a way that costs more credibility than the delay would have.
Showback done properly beats chargeback done badly
Showback's reputation as the weaker option comes from how it is usually implemented: a monthly spreadsheet, sent to a distribution list, with no owner and no comparison. That is not showback failing, that is reporting failing.
Showback earns behaviour change when it has three properties, none of which require moving money:
- A named owner per line. Not a team, a person. A cost with no name attached is nobody's.
- A comparison, not an absolute. Against last month, against the unit metric from unit economics, or against a peer service. A bare figure is unactionable; a direction is a conversation.
- A stated expectation. "This is up sharply on last month and we would like to know why by Thursday" is a control. "Here is your spend" is a newsletter. (No illustrative percentage there on purpose — the same rule as in attribution at scale. A number invented for an example is still a number a reader will remember.)
Chargeback adds one thing showback cannot: it makes the cost compete with the team's other priorities on the team's own budget line. That is genuinely powerful and it is the reason to do it eventually. It also adds a finance workflow, a dispute process, and an internal-transfer mechanism — real overhead that is only worth paying once the attribution underneath it is trusted.
Do not put chargeback on top of attribution you have not yet reconciled. The first disputed invoice will surface every unattributed dollar at once, in front of the people whose support you needed.
The unallocated pool is a design decision
Some spend genuinely belongs to nobody: shared clusters, platform services, the untaggable resource types named in the attribution chapter, and the reserved-prefix system tags you cannot edit. Every organisation must decide what happens to it, and there are only three honest choices.
| Treatment | What it does | When it is right |
|---|---|---|
| Leave it central | Platform absorbs it; teams see only their direct spend | Early programmes; when the pool is small and shrinking |
| Allocate by a driver | Split by a stated metric — headcount, request share, direct spend | When the pool is large enough to distort comparisons |
| Show it, unallocated | Publish it as its own line with an owner | Nearly always, alongside either of the above |
The failure mode is a fourth option nobody chooses deliberately: allocating it silently. A report that spreads shared cost without saying so produces per-team numbers that cannot be reconciled against anything, and the first engineer who tries to verify their line will find it unverifiable — and stop trusting the whole report.
Whichever treatment is chosen, the driver must be stated on the report itself, not documented elsewhere. If teams are being charged by request share, the report says "allocated by request share" on the same page as the number.
The sequence that works
- Attribute — get the tags right, measure coverage, publish the unattributed share.
- Show, with owners and direction — one named person per line, one comparison, one expectation.
- Wait for the disputes to become boring. When a quarter passes without anyone contesting the arithmetic, the data is trusted.
- Then charge back, if the organisation's budget structure makes it meaningful. Some do not; a single engineering budget with no per-team envelopes gets nothing from chargeback except paperwork.
Skipping step 3 is the most common failure, and it is expensive in a way that does not show up as spend: it burns the credibility that every later cost initiative depends on.
The honest limit of this chapter
This is the least sourceable chapter in Part 5, and it should be read as such. The tagging constraints above are documented and checkable; the sequencing advice is not. No vendor publishes data on whether showback or chargeback produces larger reductions, and this book will not manufacture a comparison — see making it stick for what a control with real documented mechanics looks like by contrast.
What can be said with confidence is narrow and still useful: allocation cannot start before tagging, tags are not retroactive, and there is a reporting lag between the two. Those three facts constrain any showback or chargeback design regardless of which one you pick, and they are the reason the first credible report is always further away than the plan assumes.