Build cost governance dashboard and chargeback

Introduction

When LLM spend sits in a platform-team line item, the people whose code generates it never see the number — and invisible spend never gets optimized. This lesson walks you through standing up a cost-governance dashboard that exposes per-team and per-feature spend, budget burn-rate, and a chargeback breakdown, then operating the showback-to-chargeback transition without burning trust with peer teams. By the end you will be able to draft the dashboard panel spec, write the chargeback SQL, choose a refresh cadence and review cadence you can defend to finance, and secure sign-off on a chargeback model that hits department P&L. Skip this and the next quarter's bill grows 30-40% while no feature owner feels accountable.

Key Terminology

• Showback — visibility-only spend reporting that surfaces per-team usage without billing them; this is your starting point because it changes behavior with zero finance integration.
• Chargeback — formal cross-team billing that posts LLM cost to each consuming team's P&L; this is the step that locks accountability in but requires finance sign-off and a defensible attribution model.
• Cost-per-business-unit — spend normalized by something the team owns (cost per ticket resolved, per active user, per query); this is the number that drives optimization decisions, because raw dollars hide efficiency differences.
• Burn-rate — projected month-end spend extrapolated from the current run-rate; this is what triggers budget alerts before overspend, not after.
• Optimizer attribution — the breakdown of savings from caching, routing, and compression credited back to each team; this is what makes engineers own optimization instead of treating it as someone else's problem.

Concepts

The flow below shows how raw usage events become per-team accountability — usage logs feed a normalized record, which fans out to the showback dashboard and (once finance signs off) into chargeback journal entries (see Code Walkthrough).

Showback before chargeback

Skipping straight to chargeback creates resentment without behavior change — teams feel billed for a system they don't understand. Run showback for at least one full quarter first: publish per-team spend, let teams see their own numbers, resolve attribution disputes, and only then propose the chargeback model. The dashboard is the same; only the accounting plumbing changes.

Cost-per-business-unit, not raw dollars

"Team X spent $50K" is a number; "Team X spent $5 per resolved ticket while Team Y spent $0.40" is an argument. Every dashboard panel should normalize spend by a team-owned unit — tickets, queries, active users, documents processed. Raw totals hide the teams that are inefficient-but-small and unfairly indict the teams that are efficient-but-large.

Refresh cadence that drives behavior

Daily refresh is the sweet spot. Weekly is too coarse — a team can blow through half its monthly budget before it sees a number. Hourly is dashboard noise that erodes trust in the alerts that matter. Daily refresh with a Monday morning auto-posted summary in team Slack is the cadence that produces clicks and conversations.

Optimizer savings attribution

If your caching, routing, or prompt-compression work isn't visible on the dashboard, the team that built it gets no credit and the teams that benefit don't know to push for more. Publish a stacked-bar panel of savings attributed back to each consuming team, sourced from the same usage records — see the dashboard panel definitions later in this lesson.

Code Walkthrough

Now that you have the conceptual flow — showback first, cost-per-business-unit, daily cadence, optimizer attribution — the snippets below turn those concepts into the two concrete artifacts you ship: the dashboard panel definitions (one declarative file that drives the showback view) and the chargeback aggregation query (the monthly SQL that finance will actually approve).

Code snippetyaml
1panels:
2  - title: Total spend (current month vs prior)
3    type: time_series
4    metrics: [llm_spend_usd]
5    grouping: [team]
6  - title: Cost-per-ticket by team
7    type: bar
8    metrics: [cost_per_ticket_usd]
9    grouping: [team]
10    sort: desc
11  - title: Burn-rate vs budget
12    type: gauge
13    metrics: [month_to_date_spend_usd, projected_month_end_spend_usd]
14    threshold: [team_budget_usd]
15  - title: Optimizer savings attribution
16    type: stacked_bar
17    metrics: [cache_hit_savings_usd, routing_savings_usd, compression_savings_usd]
18    grouping: [team]
19  - title: Top features by spend (last 7 days)
20    type: table
21    metrics: [feature_spend_usd, request_count, avg_cost_per_request]
22    grouping: [feature_id]
23    limit: 25
24  - title: Anomaly alerts
25    type: alert_list
26    filter: severity in [critical, high]

Code snippetsql
1-- Monthly chargeback aggregation. Finance signs off on this query;
2-- each row becomes one journal entry against the consuming team.
3SELECT
4  team,
5  SUM(cost_usd)                                            AS gross_spend_usd,
6  SUM(cost_usd * (1 - optimizer_savings_pct / 100.0))      AS net_charged_usd,
7  SUM(cost_usd) - SUM(cost_usd * (1 - optimizer_savings_pct / 100.0))
8                                                           AS optimizer_credit_usd,
9  COUNT(*)                                                 AS request_count,
10  SUM(cost_usd) / NULLIF(COUNT(DISTINCT business_unit_id), 0)
11                                                           AS cost_per_business_unit_usd
12FROM   llm_usage_records
13WHERE  ts >= date_trunc('month', NOW())
14  AND  ts <  date_trunc('month', NOW()) + INTERVAL '1 month'
15GROUP  BY team
16ORDER  BY gross_spend_usd DESC;

You'll know it works when finance can run the chargeback query unaided, every team can find their own row on the dashboard within 10 seconds, and the monthly review meeting spends its time on optimization decisions rather than disputing the numbers.

Do's and Don'ts

Having just walked through the panel spec and the chargeback SQL, the items below distill the operating rules that decide whether the dashboard actually changes behavior or just adds another tab nobody opens.

Do's

1. ✓Do run showback for a full quarter before any dollar hits a P&L — teams need to recognize their own numbers and resolve attribution disputes in a no-stakes window so the chargeback cutover lands on calibrated metrics.
2. ✓Do anchor team targets on cost-per-business-unit — cost per ticket, query, or active user scales with usage instead of penalizing growth, and is what drives the optimization conversation in the monthly review.
3. ✓Do treat finance sign-off on the chargeback SQL and the monthly review cadence as the exit artifact — the dashboard alone changes nothing; the recurring meeting with finance and team leads is what locks accountability in.

Don'ts

1. ✗Don't skip showback and go straight to chargeback — formal cross-team billing without prior visibility creates resentment, attribution disputes, and zero behavior change.
2. ✗Don't refresh hourly because the pipeline supports it — high-frequency noise erodes trust in the burn-rate alerts that matter, and produces no faster behavior change than the daily cadence.
3. ✗Don't bill teams for spend they can't attribute — every usage record must carry a team and feature tag at write time, or your chargeback query collapses the first time finance asks for a breakdown.