Snowflake Chargeback Model: Allocating Snowflake Costs to Teams When the Warehouse Is Shared

A Snowflake chargeback model splits the credit bill across the teams that caused it, and it works cleanly only when each team owns its own warehouse. The moment a warehouse is shared, warehouse metering stops answering the question and you need per-query attribution. That is where most models quietly break, because Snowflake documents that the cost per query excludes data transfer, storage, cloud services, serverless features, and AI service tokens, and excludes warehouse idle time. Per-query costs therefore never add up to the invoice. The residual is usually somewhere between a tenth and a quarter of compute, and how you allocate it is the part finance will actually argue about.

Most write-ups on this topic stop at "use QUERY_ATTRIBUTION_HISTORY." That view is genuinely good and it is the right foundation. It is also bounded in ways that decide whether your chargeback survives its first review meeting, so this guide starts with the boundary and works outward.

How do you allocate Snowflake costs to teams?

Start by finding out which problem you have, because the two answers are very far apart in effort.

If every team runs its own warehouse, allocation is a lookup. WAREHOUSE_METERING_HISTORY reports credits consumed per warehouse per hour, you map warehouse names to cost centers once, and you are finished. The meter and the cost center are the same object, so there is nothing to apportion. Teams that can afford dedicated warehouses should take this route and stop reading vendor material about attribution engines.

If warehouses are shared, and most platform teams consolidate them deliberately to cut queue times and idle, you need query-level data. Snowflake provides it through QUERY_ATTRIBUTION_HISTORY, which reports the warehouse credit usage for executing each query. You join that to a department signal, which is either an object tag on the user, a query tag set by the application, or both, and TAG_REFERENCES tells you what is tagged. Query tags matter most where one service runs queries on behalf of several departments, because the user is then the service account and tells you nothing.

Both routes need one more decision that neither view makes for you, which is what happens to everything that is not query execution.

What Snowflake's per-query cost does not include

This is the sentence to take into your first planning meeting. Snowflake states that the cost per query does not include data transfer costs, storage costs, cloud services costs, costs for serverless features, or costs for tokens processed by AI services. Warehouse idle time is excluded from per-query cost as well, though Snowflake notes it can be distributed proportionally across departments afterwards using the same views.

Two more constraints are worth knowing before you design around the view. QUERY_ATTRIBUTION_HISTORY operates within an individual account rather than across an organization, and cross-account attribution is limited to dedicated resources. If your estate spans several accounts by region or by business unit, the model has to be assembled per account and consolidated outside Snowflake.

A worked month, so the residual is a number and not a caveat

Take an account that burned 1,000 credits of compute in a month across three shared warehouses. Query attribution accounts for 780 of them. Warehouse metering minus attributed query cost leaves 140 credits of idle. Serverless features, chiefly a nightly auto-clustering job and a set of tasks, take 60. Cloud services take the remaining 20.

So 78 percent of the compute bill has a team name attached to it directly and 22 percent does not. That 22 percent is not an edge case you can round away. If you present a chargeback that recovers 780 credits against an invoice for 1,000, the first person to reconcile it against the general ledger will ask where the rest went, and the honest answer has to already exist.

Allocating the idle proportionally is the defensible default and it is the method Snowflake's own documentation points at. If the data engineering team caused 390 of the 780 attributed credits, it carries half the idle, which is 70 credits. Do the same for cloud services. Handle serverless separately, because auto-clustering and tasks belong to identifiable objects with identifiable owners, and spreading them proportionally would charge a team for a clustering job on a table it never touches.

Run the arithmetic once and publish the method alongside the numbers. The general principles behind that split are the same ones covered in our guide to cost allocation methods, and the same residual problem shows up in shared cloud cost allocation in a different costume.

Dedicated warehouse or shared warehouse: the trade you are actually making

The tension in that table is the real content of most Snowflake chargeback projects. Dedicated warehouses make allocation trivial and the total bill larger. Consolidation makes the bill smaller and the allocation harder. Neither team is wrong, and the argument gets much shorter once both sides can see that they are trading accounting clarity against idle credits rather than disagreeing about facts.

A reasonable middle path is dedicated warehouses for the two or three teams with the largest and most predictable workloads, and one shared pool for everybody else with proportional idle allocation. You get unarguable numbers where the money is concentrated and you keep the pooling benefit where the workloads are small and bursty.

What is a Snowflake chargeback model?

A chargeback model is the full set of rules that turns a Snowflake invoice into a set of departmental charges: which meter each team is measured on, how unattributed cost is distributed, what happens to storage, how often it runs, and who can dispute a number. It is a finance artifact, not a dashboard. The dashboard is how you deliver it.

The distinction that matters is between showback and chargeback. Showback publishes the split and moves no money. Chargeback debits a real departmental budget. Almost every successful implementation runs showback for at least a quarter first, because the first three reports always contain attribution errors and it is far better to have those found by a department head defending their number than by an auditor. Our note on showback vs chargeback covers when the switch is worth making.

How Databricks handles the same problem

Worth knowing if your estate has both, because the shape of the answer is different. Databricks exposes system.billing.usage, which records consumption with workspace_id and account_id, sku_name, billing_origin_product telling you whether the charge came from jobs, DLT, SQL and so on, usage quantity in DBUs, custom_tags as a map, and identity_metadata with a run_as field naming the user or service principal that ran the workload.

That run_as field is the structural difference. Databricks attributes at the workload level natively, including serverless charges, so you get an owner without needing a separate attribution view or a rule for idle. Two documented caveats: in FedRamp-enabled workspaces the identity metadata values are replaced with __REDACTED__, and private_endpoint_name is always null on AWS. It is still a table rather than a product, so somebody has to own the queries and the refresh, but the raw material for chargeback is closer to complete than Snowflake's.

Five steps to a model finance will sign off

1. Inventory warehouses and name an owner for each. Do this before writing any SQL. Warehouses with no owner are where the unallocated cost accumulates, and there are always more of them than the platform team expects. Anything genuinely shared gets marked as shared now, not later.

2. Get tags in place and verify they are actually populated. Object tags on users and warehouses, query tags for applications that run work on behalf of multiple departments. Check TAG_REFERENCES rather than trusting the rollout, because a tagging standard that covers 70 percent of queries produces a chargeback that is 30 percent guesswork.

3. Reconcile to the invoice before you show anyone. Sum attributed query credits, add warehouse idle, add serverless, add cloud services, and confirm the total matches billing. If it does not reconcile, the model is not ready, and finding out in a review meeting is expensive in credibility.

4. Write the residual rules down. Idle proportional to attributed credits. Serverless by object owner. Cloud services as overhead. Storage by database ownership. One page, agreed in advance, referenced in every report. This is the single most effective thing you can do to keep the conversation about spending rather than about method.

5. Publish as showback for a quarter, then decide. Departments will find errors, and that is the point. Fix them while nothing is being charged. Move to chargeback only when the teams carrying the number genuinely control the consumption behind it, which for a team that cannot change its own pipelines is not yet true.

Where the unallocated cost usually turns out to be

Three patterns account for most of the residual on a first pass, and all three are findable for free.

Long auto-suspend settings are the most common. A warehouse set to suspend after ten minutes of inactivity bills at full rate for those ten minutes after every burst, and on a bursty analytics workload that adds up to a substantial share of the idle line. Shortening it is usually the cheapest single change available.

Oversized warehouses are the second. Short queries running on a large warehouse finish faster and cost more per second, and the sizing decision often dates from a one-off backfill nobody revisited.

Orphaned scheduled work is the third and the most annoying to find, because a nightly task that still populates a table for a dashboard that was retired eighteen months ago looks exactly like legitimate consumption in every cost view. Cost data cannot tell you that nothing downstream reads the output. Tracing which tables actually feed a live report is a data lineage question rather than a cost question, and it is the fastest way to separate work that matters from work that merely still runs.

Do you need a tool for this?

Not to start. Snowflake Budgets, resource monitors, and the ACCOUNT_USAGE views are free, already in your account, and cover more than most teams assume. Know their limits: budgets are for alerting only and do not stop spending, you get a maximum of 100 custom budgets per account, and the default refresh interval is 6.5 hours with a one-hour option priced at 12 times the default. Resource monitors are the control that can actually suspend a warehouse.

Buying makes sense at two specific points. If the credits themselves are too high and the workloads are fine, an optimizer that changes warehouse configuration is the right purchase, and several of them charge on measured savings. If the problem is that nobody can say which team caused an increase, or that Snowflake is one of six technology costs rising at once and the meeting is with a CFO, an attribution platform is the right purchase. Our comparison of Snowflake cost management tools sorts ten options by exactly that split, including which ones cover Databricks and BigQuery and which publish a price.

Costanalyst sits on the attribution side of that line. It connects read-only, never changes a resource, and reports data platform spend alongside cloud accounts and SaaS subscriptions attributed to teams and cost centers, from $99 a month. It will not resize a warehouse, and if that is what you need, the guide above says which tools will. For the wider allocation picture across every provider, cloud cost allocation software covers the category and our own allocation feature covers how we do it.