Attribution and Chargeback Taxonomy
Estimated read: 3 min
Having system.billing.usage and list_prices gives you a priced ledger, but a ledger only becomes
a chargeback report once every row can be attributed to a payer. The taxonomy question – what keys
do we tag by, and what do we do with cost that can’t be tagged – is where most FinOps efforts stall,
and it’s the same problem your legacy warehouse’s cost-center codes solved with a rigid, centrally
managed chart of accounts. Databricks gives you more flexibility than a fixed chart of accounts, and
that flexibility is exactly what needs governance.
Direct attribution covers workloads with a clean 1:1 owner: a job that always runs for one team,
a SQL warehouse dedicated to one BI tool, a cluster provisioned for a single project. These get
tagged at the resource level – team, project, cost_center, environment are the four keys
most organizations standardize on, mirroring the general-ledger dimensions a Teradata chargeback
report would have used. Databricks supports this natively: custom tags attached to clusters,
jobs, SQL warehouses, and pools propagate automatically into usage_metadata and custom_tags on
every system.billing.usage row those resources generate, and the same tags flow into your cloud
provider’s billing export for infrastructure costs that sit outside Databricks’ own SKUs.
Indirect and shared attribution covers everything that doesn’t have one owner: a shared all-purpose cluster three teams use for ad hoc analysis, Unity Catalog metastore overhead, storage costs for a bronze table five downstream jobs read from. Three allocation methods handle this, in increasing order of complexity:
| Method | How it works | Legacy analogue |
|---|---|---|
| Proportional by usage | Split shared-resource cost by each tenant’s measured DBU or query share | Mainframe CPU-hour chargeback by session accounting |
| Headcount- or seat-based | Split evenly (or by team size) across known consumers of a shared service | Flat departmental IT allocation |
| Showback only | Report the cost per team without moving budget – visibility, not billing | A cost dashboard nobody’s P&L actually reflects |
Showback vs. chargeback is the distinction that determines how much rigor the taxonomy needs. Showback – surfacing “your team spent $4,200 last week” without an actual budget transfer – is useful for driving behavior change with a much looser tagging bar, since a slightly wrong number still nudges the right direction. True chargeback, where a team’s cloud bill line item is debited against their budget, demands enforced tagging (cluster policies that reject untagged compute, Databricks Asset Bundles that inject tags at deploy time) because an unattributed or misattributed dollar becomes a finance dispute, not just a rounding error on a dashboard.
Decide showback vs. chargeback before designing your tag schema. Chargeback-grade attribution needs enforced, non-optional tagging at resource creation; showback tolerates gaps. Building chargeback-grade enforcement for a showback-only use case is wasted platform engineering effort.
A migration adds a fifth taxonomy dimension most greenfield deployments skip: migration phase.
Tagging workloads as parallel_run, cutover, or steady_state lets Finance see the temporary
double-running cost of the parallel-run period as a distinct, time-boxed line item rather than a
permanent increase baked into a team’s ongoing budget – the same way a legacy program would have
tracked a “dual-run” cost center separately from BAU operations during a system cutover, so the
spike doesn’t distort the post-migration baseline everyone compares future spend against.
Standardizing that fifth tag alongside team/project/cost_center/environment from the start
saves you from retroactively reclassifying months of billing history once the migration program
office asks “how much did running both systems in parallel actually cost us.”
Reference: Custom tags for billable usage attribution.
| ← Previous: The system.billing.usage Deep Dive | Next: Building the Chargeback Dashboard → | |:—|—:|