A cost that lands in a team’s profit and loss statement before that team can see, at any hour of any day, exactly what it is being charged for, gets disputed within a week and ignored within a month. I have watched that sequence play out at three organisations now, and in every case the failure was scheduled the day someone decided chargeback was the obvious next step after tagging.
It is not the next step. It is a different commitment with a different counterparty. Showback is a conversation you have with engineering. Chargeback is a contract you sign with accounting, and accounting has a close calendar that does not care that your billing export arrives late. Part 5 got every currency unit on the invoice attributed to somebody. This part decides what you do with that attribution.
What separates showback from chargeback
Showback means you produce a report that tells a team, product or department what its share of the technology bill was, while the money itself stays in a central budget. Nobody’s budget moves. The report informs, and the only consequence is whatever the reader chooses to do about it.
Chargeback means that same number is posted as a journal entry, which is the formal accounting record that moves an expense from one ledger account to another, into the receiving team’s cost centre. A cost centre is simply the identifier finance uses for a bucket of budget with a named owner. Once the entry is posted, the expense sits in that owner’s profit and loss statement, it affects their variance to budget, and it can only be changed by another journal entry.
The FinOps Foundation frames the distinction in exactly those terms. Its Invoicing and Chargeback capability states that the primary difference between showback and chargeback is the formality of sending expenses to official accounting budgets, and that showback reporting can be used at any granularity to show any group its costs. The same page is unusually direct about hierarchy: neither type of reporting should be considered more mature than the other.
That single sentence contradicts almost every vendor maturity slide I have been shown. It is also correct. Showback is required in any FinOps practice, because a practice where nobody can see their own consumption is not a practice. Chargeback depends entirely on your organisation’s accounting policy, and there are large, well run companies that will never need it.
Is chargeback really the more mature model?
No, and treating it that way is how practices acquire a project they cannot finish. The FinOps Foundation notes that when technology costs allocate to a single cost centre, or to a set of cost centres that is easy to allocate to, the additional cost and burden of creating official chargeback reporting may be unwarranted. That is a polite way of saying that some organisations will spend six months of practitioner time building a mechanism that changes nobody’s behaviour.
The question that actually decides it is not maturity. It is authority. Chargeback works when the person receiving the charge can do something about it: cancel an environment, resize a fleet, kill a feature, change an architecture. If your budget owners are directors who cannot influence a single deployment decision, the charge produces no optimisation and a great deal of correspondence. I would rather run excellent showback into the hands of engineering managers with real authority than run formal chargeback into a cost centre hierarchy that stops three levels above anyone who touches a console.
There is a second decider, which is whether your organisation needs the number for something outside itself. If you bill external customers, operate a shared services company that recovers its costs internally, or report segment profitability to a regulator or a board, chargeback is not optional and the maturity question never comes up. You need the ledger entry because somebody outside your practice depends on it.
| Property | Showback | Chargeback |
|---|---|---|
| Where the expense lands | Central technology budget | Receiving cost centre profit and loss |
| Who has to sign off | Nobody outside the practice | Accounting, and often internal audit |
| Tolerable error | A few percent, corrected next month | Small enough to avoid a true up entry |
| How a mistake is fixed | Republish the report | Reversing journal entry in a later period |
| Deadline pressure | Yours to set | Financial close, typically 3 to 5 working days |
| Handles late billing data by | Waiting for it | Posting an estimate, then a true up |
| Main failure mode | Report nobody opens | Disputes that consume the practice |
| Required by the Framework | Always | Only where accounting policy demands it |
Close timelines vary by organisation. The rows on formality and requirement follow the FinOps Foundation Invoicing and Chargeback capability, reviewed in July 2026.
In practice
The most useful thing I have done on this topic cost nothing. Before proposing chargeback, I ran the proposed numbers as a showback report for one quarter and sent each team a single line: here is what you would have been charged last month if this were live.
Two things came out of it. Every allocation rule that was going to be argued about got argued about while it was still free to change, and one team discovered a forgotten test cluster in the first week. By the time the real charge started, the disputes were already spent.
Prerequisites before you charge anyone
Six things need to be true before the first journal entry. Miss any of them and you will spend the first quarter defending numbers instead of reducing them.
Allocation coverage has to be high and stable. My threshold is 95 percent of invoiced spend attributable to a named owner, holding for three consecutive months. Stability matters more than the number itself, because a coverage figure that swings between 88 and 96 percent means the rules are still moving, and rules that move produce charges that move.
The shared cost rule has to be written and agreed by the people who will pay it, not just by you. Commitment purchases are the sharpest case. A three year commitment bought centrally, whose discount benefits a workload owned by one team, will be a source of conflict forever unless the distribution method is agreed in advance. The Foundation lists this precisely as the difference between a crawl practice, where commitments are charged to whoever happens to own the account that bought them, and a run practice, where all commitment based purchases are charged to teams based on their consumption of the discount.
Finance has to give you the cost centre hierarchy and the general ledger codes, and that hierarchy has to reach down to a level where somebody can act. You also need a close timeline with a named date, an agreed estimation method for the days when billing data has not landed, and a documented true up process, which is the correcting entry posted once final data arrives.
Last, and most often skipped, there has to be a dispute path with a service level. A team that believes it has been charged incorrectly needs to know who to contact and how long a decision takes. Without that, every dispute escalates to whoever is loudest, which is a policy, just not one you chose.
Building the monthly chargeback file
The chargeback file is the artefact finance ingests. It is a table of cost centre codes and amounts, in one agreed currency, with enough breakdown that a recipient can answer their own questions without telephoning you. Building it is five steps in a fixed order, and the order matters because each step changes the base the next one works from.
Start with directly attributed cost, which comes straight from your tags and account boundaries. Then distribute commitment discounts to the teams whose usage consumed them, rather than to the account that made the purchase. Then apply the shared cost rule to platform components, data transfer and anything else structurally untaggable. Then decide what stays central: tax, support fees and, in my view, any legacy untagged spend that is being actively remediated, because charging a team for a resource nobody can identify is how you teach people that the file is unreliable. Finally, convert currency if you need to, and map each line to its general ledger code.
Provider tooling helps at step one and two, and less than you would hope after that. AWS offers Billing Conductor, a service aimed at channel partners and organisations with chargeback requirements, which produces a pro forma version of your billing data each month by applying pricing plans, pricing rules and custom line items to billing groups. It is the closest thing any provider offers to a native chargeback engine, including markups and one off charges. Azure exposes cost allocation rules in Cost Management, where you select subscriptions, resource groups or tags as sources, pick targets, and split by custom percentages or in proportion to network cost. Microsoft documents that rules process in creation order and can take up to 24 hours to take effect. On Google Cloud the practical route is the billing export into BigQuery, where you build the split yourself.
My recommendation across all three is to keep the final split logic in your own data layer rather than in provider configuration, even where a native feature exists. The rules will change, finance will ask for a restatement of a prior month, and a percentage buried in a console setting cannot be version controlled, reviewed or explained to an auditor eight months later.
| Cost centre | Direct, USD | Shared split, USD | Total charged | Share of invoice |
|---|---|---|---|---|
| CC4417 Checkout | 20,800 | 1,283 | 22,083 | 38.1 percent |
| CC4418 Data platform | 14,250 | 879 | 15,129 | 26.1 percent |
| CC5203 Mobile | 8,900 | 549 | 9,449 | 16.3 percent |
| CC5211 Internal tools | 5,000 | 309 | 5,309 | 9.2 percent |
| CC1000 Central, held | 3,410 legacy untagged | 2,620 tax and support | 6,030 | 10.4 percent |
| Invoice total | 48,950 attributed | 3,020 by rule | 58,000 | 100 percent |
Illustrative, continuing the same 58,000 invoice used in Parts 4 and 5. The shared split is proportional to directly attributed spend. Note that the file balances to the invoice exactly, which is the one property finance will check first.
Worked example, the true up
Close is on working day three. Final billing data for the month lands on day six. So on day three you post an estimate of 22,000 to Checkout, based on the first 27 days of usage scaled to the full month.
On day six the actual is 22,083. The difference of 83 is posted as a true up entry in the following period, and because it is under half a percent, most accounting policies will let you skip the correction entirely and absorb it centrally.
That threshold is the number to negotiate with finance up front. Agree that variances under an agreed percentage are absorbed rather than corrected, and you remove most of the monthly administrative load from the process before it starts.
Where chargeback breaks in its first quarter
Three failures account for nearly everything I have seen go wrong, and all three are visible in month one if you know to look.
The first is charging for costs the recipient cannot control. A team charged for its share of a Kubernetes control plane it did not size, on a cluster it does not administer, will correctly point out that it has no lever to pull. The charge is arithmetically fair and operationally useless. Where a team cannot act, either hold the cost centrally or make sure the report shows the charge as fixed overhead so nobody wastes a sprint trying to reduce it.
The second is estimates that never get trued up. Posting an estimate at close is normal and the Foundation treats it as expected practice. Never returning to correct it is the crawl behaviour that quietly destroys trust, because within two quarters the ledger and the billing data disagree by an amount nobody can reconcile, and every conversation about optimisation stalls on which number is real.
The third is a variance that stays high. Track the gap between what you post at close and what the final data says, per cost centre, every month. If it is not trending down, the problem is upstream in allocation and no amount of process design in the chargeback step will fix it. That single metric is the best early warning available, and it costs one chart to maintain.
Key takeaways
- Showback and chargeback are not two settings on one dial. One informs, the other moves money into somebody’s profit and loss statement.
- Showback is required in every FinOps practice. Chargeback depends on your accounting policy, and plenty of good practices never need it.
- Authority decides it: charge only where the receiving owner can actually change the spend.
- Get to 95 percent allocation coverage, stable for three months, before the first journal entry.
- Agree the estimate variance threshold with finance up front, and track that variance monthly as your health metric.
Run showback for two quarters, then charge only what teams control
Here is the recommendation without hedging. Run showback for two full quarters using the exact numbers you intend to charge, and send them to teams monthly with the line stating what they would have been charged. Use that period to settle every allocation argument while settling one is still free. If, at the end of it, your accounting policy requires formal chargeback, or an external party depends on the number, build it, starting with one pilot cost centre rather than the whole hierarchy.
If neither of those is true, keep running showback and put the effort into the reporting instead. A showback report that reaches an engineering manager weekly beats a chargeback file that reaches a director monthly, every time, on the only measure that matters, which is whether the bill went down.
Part 7 takes on the reporting itself, which is where most of the value of showback is either delivered or wasted, and asks what a cost report has to contain before anyone acts on it. The earlier groundwork, including Part 3 on the Framework and Part 5 on allocation, sits on the Cloud FinOps guide.
One thing to do this week: pick your largest cost centre and write down, in one sentence, what its owner could actually cancel or resize tomorrow. If you cannot finish the sentence, you have your answer on chargeback.
References
- Invoicing and Chargeback capability, FinOps Framework, FinOps Foundation
- Allocation capability, FinOps Framework, FinOps Foundation
- What is AWS Billing Conductor, AWS Billing Conductor User Guide
- What is pro forma billing data, AWS Billing Conductor User Guide
- Allocate Azure costs, Microsoft Cost Management
- Introduction to cost allocation, Microsoft Cost Management
All monetary figures, percentages and cost centre codes are illustrative and chosen to show the shape of a real chargeback file. Provider capabilities and framework wording were verified in July 2026 and change over time.
About The Author
DrJha