Showback

Showback is the practice of reporting technology costs to the teams responsible for them without formally charging those costs to their budgets. A team sees what its workloads cost; the money still sits wherever it was budgeted.

The FinOps Foundation describes showback as reporting that can be used at any granularity to show any group, large or small, the costs of the scope it is responsible for, and distinguishes it from chargeback by one thing: formality. Chargeback sends expenses to official accounting budgets; showback does not.

How visibility can support action

Some expensive workloads are not deliberate. A dashboard refreshing every few minutes for an audience that opens it once a day, a development cluster left running over a weekend, a query that scans a full table because nobody added a date filter — none of these needs to be anyone’s decision. They can persist because the people who could change them never see what they cost. Seeing the cost does not guarantee a change: the team also needs control over the workload, a reason to act on the number, and a way to weigh the cost against the value or performance it buys.

Showback can close that visibility gap without the organizational weight of moving money. It also lets the numbers be imperfect: if a shared-cost split is contestable, a report can say so and invite discussion, whereas a charge to a budget invites a dispute. The FinOps framework is explicit that neither showback nor chargeback should be considered more mature than the other, and that chargeback is not required in every organization.

What it depends on

Showback is only as good as the cost attribution beneath it. If costs cannot be traced to teams or workloads — because resources are untagged or compute is shared without identifying who used it — the report can show actual consumption only for what was recorded. The rest can be shown as an unexplained remainder, allocated by an agreed rule such as a fixed split, a proportion, or a business proxy, or kept in a central budget. An agreed allocation is a legitimate choice as long as the report states its basis, what it cannot show, and which costs a team can actually control; an allocation presented as measured usage undermines the point.

What makes a showback report useful

• The owner’s own scope. Costs grouped by the things a team recognizes — its pipelines, dashboards, and models — not by cloud service names.
• Change, not just totals. Show what changed since last period and investigate why. A stable total also needs review against its level, workload, and value.
• Unit costs where possible. Cost per report consumer, per model run, or per thousand requests ties spending to a defined unit of activity in a way a total cannot. A unit cost does not show value on its own, so read it alongside usefulness, quality, and total spend.
• Shared costs shown separately. Direct costs a team controls should be distinguishable from its share of common costs it does not.
• A path to act. Someone the team can ask, and levers they can pull: schedules, sizes, retention.

The common failure is a cost dashboard that exists and is not read. Delivering the report into a regular review a team already holds tends to matter more than the sophistication of the report itself.

Where showback sits between basic visibility and chargeback on a shared data platform is worked through in Enterprise Scale: One Platform, Workloads That Disagree.

References

• FinOps Foundation, FinOps Framework: Invoicing & Chargeback
• FinOps Foundation, FinOps Framework: Allocation