Chargeback vs showback: which cloud cost model to use, and when

What showback is

Showback is a report. It takes the cloud invoice, allocates every line to a business consumer such as a department, a cost center, a product or a customer, and shows each consumer what it used and what that cost. The money stays where it was: central IT, a platform team or a shared technology budget still pays the provider.

The point of showback is visibility with accountability attached. A team that sees its own number, every month, with the drill-down to check any line, behaves differently from a team that sees nothing. It also surfaces the allocation rules for inspection. If the platform team’s Kubernetes cluster is split by CPU requests and the data team disagrees, showback is where that argument happens, cheaply, before any budget is affected.

Showback is also the proving ground for the data. Tags are missing, accounts are shared, a subscription belongs to two products, and a discount was applied at the payer level. Every one of those defects appears as an unallocated or disputed line in a showback report. Fixing them there costs a conversation. Fixing them after chargeback costs a journal entry and an apology.

What chargeback is

Chargeback is showback with consequences. The allocated cost is transferred to the consumer’s budget, usually as an internal recharge or an intercompany invoice, so the department that used the cloud pays for it out of its own plan. Central IT becomes a pass-through, or a service provider with an agreed margin, rather than the owner of a bill nobody else feels.

Because money moves, chargeback needs more than a report. It needs a policy that says what is charged and how, allocation rules that are agreed in advance, a treatment for shared costs and discounts that the recipients accept as fair, a statement in a layout finance can post, and a process for disputes and corrections. That is why chargeback programs that skip showback tend to stall: the first disputed statement becomes a finance-versus-engineering argument instead of a data fix.

Done well, chargeback is the strongest lever there is on cloud spend, because it gives the people who make provisioning decisions a budget line they own. Done badly, it teaches teams to avoid shared services, tag things creatively and argue about rules every month.

Showback vs chargeback at a glance

Why most organizations start with showback

Cloud spend is now the top management problem for most organizations. In Flexera’s 2026 State of the Cloud survey, 85% of respondents named managing cloud spend their number one challenge, ahead of security. The FinOps Foundation’s State of FinOps reports show where practitioners want to spend their effort: allocation, forecasting, budgeting and reporting are the capabilities they prioritize most, ahead of another round of rightsizing.

Both findings point the same way. The problem is not a shortage of savings recommendations. It is that nobody can say, with confidence, whose money the bill was. Showback answers that question first and lets the organization check the answer before it has to be defended in a budget review.

There is a second reason. The cloud bill is only partly under any one team’s control. Enterprise discount programs, reserved capacity and savings plans, support plans, networking, security tooling and the platform itself are shared by design. Until the organization has agreed how those are split, chargeback pushes costs onto teams that cannot change them, and the model loses its legitimacy on the first statement.

When chargeback is the right answer

Chargeback earns its place when the following are true, and it is usually introduced for part of the bill before all of it.

• The allocation has been reported as showback for at least a few cycles and the disputes have dropped to a handful of lines.
• Budget owners have asked for it, because they want to decide what they run and what they stop, and they cannot do that against a number they do not pay.
• Finance needs the cost to sit in the right P&L for pricing, margin or unit-economics reasons: a product line, a customer contract, a subsidiary.
• Shared costs and discounts have a written treatment that the recipients have signed, even if they do not love it.
• The organization is large enough that a central technology budget has become a place where cost hides rather than a place where it is managed.

Chargeback is rarely right for everything. A common end state is chargeback for direct, tagged, clearly owned consumption and showback for the shared platform, with the platform’s cost reviewed as its own budget rather than smeared across every team.

The three allocation methods both models rely on

Whether a report is showback or chargeback, every line of the invoice has to land somewhere, and the total has to reconcile to what the provider charged. Three methods do that work, in this order of preference.

1. Direct allocation. A cost has one owner, identified by account, subscription, project, resource group, or a tag such as cost-center or product. A virtual machine tagged to the payments team is the payments team’s cost. This should cover the majority of the bill, and the share it covers is the single best measure of how healthy the tagging and account structure is.
2. Proportional allocation. A shared cost is split by a usage driver: CPU and memory requests for a Kubernetes cluster, query bytes for a shared data warehouse, request count for an API gateway, headcount for a collaboration platform. The driver has to be measured, not estimated, and it has to be one the recipients recognize as fair.
3. Fixed allocation. A shared cost is split by agreed percentages or an even share. This is the fallback for costs with no sensible driver, such as a security tool licensed for the whole estate, or for costs too small to be worth a driver. The percentages are written down and reviewed on a schedule, not adjusted mid-month.

The three methods are applied as rules in a fixed order: direct first, then proportional, then fixed, with anything left over reported as unallocated rather than hidden. A model that reports its unallocated remainder honestly is more trusted than one that claims 100% and cannot show its working.

Shared costs: the part that decides whether chargeback survives

Shared costs are where chargeback programs are won or lost. They are typically a fifth to a third of the bill, they are the costs recipients least control, and they are where a percentage chosen in a meeting becomes a line on someone’s statement. A workable treatment names each shared category and its default method before the first statement goes out.

• Platform and Kubernetes clusters: proportional, by requested CPU and memory, with idle capacity carried by the platform budget rather than the tenants.
• Networking, transit and egress: proportional by bytes where the provider reports them per owner; otherwise fixed by an agreed split.
• Security, logging and observability tooling: fixed, or proportional by ingested volume where the tool reports it.
• Support plans and enterprise agreements: proportional to each consumer’s direct spend, because that is how the provider prices them.
• Commitment discounts (reserved capacity, savings plans, committed use): allocated to the consumers whose usage the commitment covered, at the discounted rate, with any unused commitment carried centrally as the cost of the decision to commit.
• Central FinOps, architecture and tooling: showback only, reviewed as a budget of its own.

Moving from showback to chargeback: a four-phase path

1. Allocate and reconcile. Load the billing exports from every provider, apply direct allocation, and measure the unallocated share. Fix tags, account ownership and mappings until direct allocation covers most of the bill and the model reconciles to the invoice to the cent. Exit when the unallocated share is small and stable.
2. Report showback. Publish a statement per consumer every month, with drill-down to the line. Run a dispute process even though no money moves, and use it to write the shared-cost rules. Exit when a full cycle passes with disputes in single figures and no rule changes.
3. Charge back the direct costs. Post the directly allocated costs to consumer budgets. Keep shared costs on showback for one more cycle so recipients see the number they will pay before they pay it. Exit when the first postings close without corrections.
4. Charge back the agreed shared costs. Add each shared category to chargeback as its treatment is signed off, and keep the remainder on showback with an owner and a review date. This is a steady state, not a finish line; the rules are reviewed on a schedule as the estate changes.

Common mistakes

• Charging back before the allocation is trusted. The first disputed statement becomes a political argument instead of a data fix.
• Allocating 100% by force. Spreading the unallocated remainder evenly across teams hides the problem and teaches everyone the numbers are made up.
• Passing commitment discounts to whoever happened to be running when the reservation matched, rather than to the consumers the commitment was bought for.
• Changing rules mid-period. A rule change applies from the next period, with the old and new treatment shown side by side once.
• Building it in a spreadsheet. A spreadsheet cannot reconcile three providers’ exports, hold the rules as data, or let a recipient drill into a disputed line. It works until the first dispute and then it is the dispute.
• Treating showback as the goal. Showback is the means; the goal is budget owners making decisions against numbers they trust.

How Runcost handles both

Runcost produces showback and chargeback statements from the same ledger. Billing exports from AWS, Azure and Google Cloud are normalized into one model, allocation rules for direct, proportional and fixed methods are applied in order, and the unallocated remainder is reported rather than hidden. A statement is produced per department, cost center, product or customer, and any line can be drilled to the resource and the rule that put it there. Moving a category from showback to chargeback is a setting on the rule, not a new report.