Chargeback vs Showback

Last reviewed: September 2026

In one sentence: Showback tells teams what their technology usage costs; chargeback makes those costs financially accountable to them.

What are chargeback and showback?

Showback is a cost reporting model that assigns technology costs to the teams, departments, customers, products, or services responsible for them without transferring the cost to their budgets. Chargeback uses similar allocation methods but goes one step further: the allocated amount becomes an actual internal or external charge.

Both approaches answer the same fundamental question:

Who consumed the resource, and what did that consumption cost?

The difference is what happens after the cost has been calculated.

With showback, a team might receive a monthly report showing that it consumed €18,400 of infrastructure. The information creates visibility and accountability, but no money changes hands.

With chargeback, that €18,400 is charged to the team's cost center, business unit, customer account, or another financial entity.

This makes showback primarily an information and accountability mechanism, while chargeback is also a financial mechanism.

Chargeback vs showback at a glance

Showback is often easier to introduce because teams can see and challenge the data before it affects their budgets.

Chargeback requires greater confidence in the underlying data, allocation methodology, and rates. Once a cost becomes a financial transaction, questions such as "Why am I paying this?" and "How was this rate calculated?" become much more important.

How showback works

Suppose three teams consume a shared Kubernetes environment costing €30,000 per month.

Their measured consumption is:

Under a showback model, each team receives visibility into its allocated share.

Team A learns that its workloads account for €15,000 of the monthly platform cost. That information might encourage the team to remove idle workloads or investigate unusually expensive applications.

But the €15,000 remains part of the central IT or platform budget.

How chargeback changes the same example

With chargeback, the allocation can be identical:

Team A: €15,000
Team B: €9,000
Team C: €6,000

The difference is financial treatment.

Instead of merely reporting these amounts, the organization transfers or bills the costs to the respective teams or cost centers.

That distinction sounds small, but it changes the requirements of the model.

A showback report can tolerate some estimation if everyone understands the methodology. A chargeback model needs stronger governance because the calculated rate directly affects budgets, margins, or invoices.

The difficult part of chargeback therefore isn't producing an invoice. It is building a cost model that people trust.

Building an on-prem chargeback rate

Public cloud pricing provides an obvious starting point: the provider already publishes prices for compute, storage, network, and other services.

Private infrastructure is different.

There may be no pre-existing price for one vCPU-hour.

You have to build it.

Consider a private cloud environment with the following annual costs:

The infrastructure provides 800 vCPUs.

There are:

8,760 hours in a year

So the theoretical annual capacity is:

800 × 8,760 = 7,008,000 vCPU-hours

At first glance, you might calculate:

€960,000 ÷ 7,008,000 = €0.137 per vCPU-hour

Rounded, the internal rate would be approximately:

€0.14 per vCPU-hour.

But this calculation assumes something unrealistic:

100% of the infrastructure is consumed 100% of the time.

It rarely is.

Allocated capacity vs consumed capacity

Suppose the environment operates at an average 65% usable consumption level.

The expected consumed capacity becomes:

7,008,000 × 65% = 4,555,200 vCPU-hours

To recover the same €960,000 annual infrastructure cost from the capacity that is actually expected to be consumed:

€960,000 ÷ 4,555,200 = €0.211 per vCPU-hour

The rate is now approximately:

€0.21 per vCPU-hour.

Nothing about the infrastructure became more expensive.

The denominator changed.

This is one of the most important concepts in private-cloud chargeback: the unit rate depends not only on cost, but also on which capacity you choose to divide that cost across.

What about reserved-but-idle capacity?

Now imagine Team A reserves 100 vCPUs for the entire month but uses them at only 40% average utilization.

A 30-day month contains 720 hours.

The team therefore reserves:

100 × 720 = 72,000 vCPU-hours of capacity

But its actual average consumption is equivalent to:

72,000 × 40% = 28,800 vCPU-hours

Which number should you charge for?

There is no universally correct answer.

Consumption-based model

Charge only for measured consumption:

28,800 × €0.21 = €6,048

This gives teams a strong connection between usage and cost.

However, the remaining reserved capacity is still unavailable to other consumers even though Team A is not actively using it.

Reservation-based model

Charge for all capacity reserved:

72,000 × €0.21 = €15,120

This makes the consumer financially responsible for capacity held on its behalf.

But it may weaken the connection between the bill and actual resource consumption.

Hybrid model

A third option is to charge a base amount for reserved capacity plus a variable amount for actual consumption.

For example, assume reserved-but-unused capacity is charged at €0.08 per vCPU-hour, while consumed capacity is charged at €0.21.

Consumed:

28,800 × €0.21 = €6,048

Reserved but unused:

43,200 × €0.08 = €3,456

Total:

€6,048 + €3,456 = €9,504

This approach recognizes two economic realities simultaneously: consumed infrastructure has a cost, and capacity held exclusively for a consumer also has value.

The appropriate method depends on why the capacity exists, whether it can be reassigned, and what behavior the organization wants its pricing model to encourage.

The rate is a policy decision, not just a calculation

This is why an internal chargeback rate should not be treated as a purely technical metric.

Consider the €960,000 infrastructure cost from the earlier example.

Should every euro be recovered through vCPU-hours?

Perhaps not.

Storage could have its own GB-month rate. Network services might use another unit. Some platform costs might be distributed equally between tenants. A central IT function might deliberately absorb part of the cost.

Even the definition of "cost" requires decisions.

Should the rate include:

• hardware depreciation?

• software licenses?

• electricity and cooling?

• data center space?

• support staff?

• backup?

• monitoring?

• unused capacity?

• redundancy and failover capacity?

Adding or removing any of these changes the rate.

A useful chargeback model therefore documents three things clearly: what costs are included, what unit they are divided by, and who is responsible for that unit.

Without those definitions, a precise-looking number can create a false sense of accuracy.

Should unused capacity be allocated?

This is one of the hardest questions in private infrastructure cost allocation.

Imagine the platform costs €960,000 per year, but only €750,000 can reasonably be attributed to actual consumers under the organization's chosen allocation model.

There is still €210,000 somewhere.

One option is to spread it across consumers by increasing their rates.

Another is to allocate it according to reserved capacity.

Another is to keep some or all of it explicitly unallocated.

An unallocated line is not necessarily evidence that the model has failed. It can reveal economically important information: excess capacity, strategic headroom, incomplete ownership data, shared infrastructure, or costs that management has deliberately chosen not to assign.

Forcing every euro onto a consumer can make a report appear complete while hiding those realities.

For a deeper explanation of allocation methods and the treatment of shared and unallocated costs, see Cost allocation.

When should you use showback instead of chargeback?

Showback is often the better starting point when an organization is still improving its cost data, ownership information, tagging, allocation rules, or internal rates.

It allows teams to see:

"If we were charging you today, this would be your cost."

That creates an opportunity to validate the model.

Teams can identify incorrect ownership, missing metadata, unexpected consumption, or disputed allocation rules before those numbers affect departmental budgets.

Showback can also be the permanent model.

An organization does not need to implement chargeback simply because it can calculate allocated costs. If visibility is enough to influence decisions and financial recovery is not required, showback may provide the desired accountability with less administrative complexity.

When does chargeback make sense?

Chargeback becomes more useful when costs genuinely need to follow consumption.

This is common where IT operates as an internal service provider, business units control their own technology budgets, shared infrastructure needs to recover its costs, or a managed service provider bills external customers.

Chargeback can also create stronger economic signals.

If a team reserves significantly more capacity than it needs, the cost becomes visible in its own budget rather than remaining an abstract efficiency problem for central IT.

But that only works when teams trust the numbers.

A poorly designed chargeback model can create the opposite incentive: teams spend their time disputing bills rather than optimizing consumption.

Showback, chargeback and FinOps

Showback and chargeback are mechanisms for making technology consumption financially visible and accountable. Neither should be confused with FinOps itself.

FinOps encompasses broader practices around understanding technology costs, establishing ownership, optimizing usage, forecasting spend, measuring value, and enabling engineering, finance, and business teams to make informed decisions.

Showback and chargeback can support those practices by connecting consumption with accountability.

The progression does not have to be:

no allocation → showback → chargeback

Some organizations remain with showback. Others require chargeback from the beginning. Some use both: showback for certain shared services and chargeback for resources with clear ownership.

The right model depends on what decision the cost information needs to support.

How Exivity supports showback and chargeback

Both Exivity products support this. Exivity Core meters and rates usage — including private infrastructure — and prepares showback, chargeback and invoice-ready charges from it, deployable in your own environment. Hypermeter adds cross-source allocation and unit economics where costs span many systems.

Once an organization has decided what should be allocated, to whom, and according to which rules, tooling can make the model repeatable.

Exivity collects consumption and cost data from public cloud, private cloud, virtualization, containers, storage, SaaS, and other technology sources and combines it with relevant business context.

Organizations can define their own services, rates, allocation logic, and charging rules to translate technical consumption into financial information.

That makes it possible to support both sides of the model:

Showback: provide teams, departments, or customers with detailed visibility into the costs associated with their consumption.

Chargeback: use the resulting rated consumption as the basis for internal cost recovery or customer billing.

Because Exivity is data-source agnostic, the same cost model can incorporate hyperscaler billing data alongside private cloud, on-premises, SaaS, and custom infrastructure consumption.

This is particularly useful when a chargeback model needs to represent the economics of the complete service rather than the bill from a single cloud provider.