The cloud invoice arrives as one number, addressed to finance. Engineering made most of it, marketing made some of it, and nobody is sure who made the rest. Showback and chargeback are the two usual ways to hand each part back to whoever owns it. The choice is smaller than it sounds, and the work underneath it is bigger.
What is the difference between showback and chargeback?
Both begin with allocation. The FinOps Foundation defines it as how “costs should be apportioned to those responsible for each component of that cost.” What you do with the apportioned numbers is the split:
- Showback reports each team’s cost back to it. Nothing moves in the accounts. Teams see what they spent.
- Chargeback moves the cost into the team’s, product’s or cost centre’s books, so it counts against their budget.
The Foundation’s own wording is that “the primary difference between showback and chargeback is the formality.” Showback “can be used at any granularity to show any group, large or small”, so it works for a squad of four as well as a business unit.
Neither changes your supplier invoice. Microsoft says its cost allocation “doesn’t affect your billing invoice” and that “all chargeback processes happen in your organization outside of Azure.” Chargeback is an internal accounting decision, not a cloud feature.
Which one do you need?
The Foundation is blunt: “Showback is always required in any FinOps practice, but chargeback is dependent on organizational accounting policies.” It also says “neither type of reporting should be considered more mature than the other”, which quietly retires the idea that chargeback is the grown-up version you graduate to.
It goes further: where chargeback is not needed, “the additional cost and burden of creating official chargeback reporting may be unwarranted.”
| Question | Points to showback | Points to chargeback |
|---|---|---|
| Do teams or products have their own budgets or P&L? | No | Yes |
| Does finance book IT costs to cost centres? | No | Yes |
| Is allocation data complete and trusted? | Not yet | Mostly |
| Is the goal awareness first? | Yes | Later |
| Is there a policy requiring internal billing? | No | Yes |
The first two rows are the decisive ones, because they are accounting facts, not cloud facts. If your accounting policy does not ask for chargeback, you can stop at showback and lose nothing the Foundation counts as maturity.
Why showback comes first anyway
Allocation is where this goes wrong. A chargeback built on weak data bills a team for something it did not run, and the next meeting is about the method, not the money.
Showback is the safe place to find that out. Teams see their numbers, argue with them, and point at the resources that are not theirs. By the time the numbers carry a budget consequence, they have survived an argument.
It also supports the Foundation principle that “everyone takes ownership for their technology usage”, which the Foundation describes as engineers being accountable for the cost of their work. Ownership starts with seeing the cost. It does not need an invoice to begin.
The part that decides both: allocation data
Neither model works without knowing who a cost belongs to. The Foundation notes that “allocation granularity is enhanced using resource-level naming conventions and tags or labels applied to the data”, and warns that tagging strategies “must take into account the challenges of tagging compliance and consistency.”
Two practical points from the providers’ documentation:
- AWS tags must be activated. AWS says you “must activate both types of tags separately before they can appear in Cost Explorer or on a cost allocation report”, and that tags can take up to 24 hours to appear. Untagged resources are not lost: the allocation report includes both tagged and untagged charges, and the total reconciles with the Bills page. They just land in a bucket nobody owns.
- Enforce tags, don’t request them. Microsoft’s governance guidance is to enforce tagging requirements to “group and allocate costs” across environments, departments or projects, and to start with a monitor-first approach rather than blocking deployments at once.
Treat the untagged share as a number to report every month. It is the honest measure of how far your showback can be trusted.
What to do with shared costs
Most organisations have shared costs: networking, logging, a central platform account. The Foundation’s advice is to “choose for each shared cost what kind of allocation policy generates the best value for the organization.” Note the phrase: for each shared cost, not once for all of them.
Azure’s cost allocation rules show the range of options. A shared cost can be split evenly, by percentages you set, or in proportion to targets’ compute, storage, network or total cost. Microsoft also notes that cost allocation does not support purchases, including reservations and savings plans, so commitments need their own rule.
Fixed percentages are easy to explain and age badly. Proportional splits track reality and are harder to predict. Pick the one the teams will accept as fair, write it down, and revisit it when the architecture changes.
A sensible order of work
- 1Define ownersTeam, product or cost centre
- 2Tag and allocateEnforce tags; track untagged
- 3Run showbackMonthly reports to each owner
- 4Decide on chargebackOnly if accounting needs it
Most of the effort sits in steps one and two. Steps three and four are reporting.
Where Auris fits
Auris works with certified FinOps practitioners who set up this kind of cost visibility for a company’s cloud estate: tagging, allocation rules and the reports that tell each team what it owns. If you want help getting showback running, the FinOps page explains how an engagement works.
The bottom line
Start with showback. Add chargeback only when your accounting policy asks for it, and not because it sounds more advanced; the Foundation says it is not. In both cases the real work is allocation: clear owners, enforced tags and an agreed rule for shared costs.