Your Snowflake dollar figures are ~23% low if you hardcoded $3 a credit

The arithmetic was never in doubt. credits × price is correct. The defect was treating price as a property of Snowflake rather than a property of your contract.

List price is a starting point that most accounts do not sit on. Edition changes it — Standard, Enterprise and Business Critical are different rates for the same credit. Region changes it. Capacity commitments change it, which is the entire point of signing one. An account on a negotiated multi-year deal and an account on pay-as-you-go can differ by well over the 23% we were out by, in either direction.

So a flag with a sensible default is not a small approximation. It is a number the user has to already know in order to correct — and if they knew their effective rate offhand, they probably would not need a cost tool.

Snowflake publishes it. ORGANIZATION_USAGE.RATE_SHEET_DAILYcarries the effective rate per usage type per day, in your organisation's billing currency. It is not in ACCOUNT_USAGE, which is where everyone looks first, and that is most of why it gets missed.

SELECT date AS rate_date, effective_rate
FROM snowflake.organization_usage.rate_sheet_daily
WHERE account_locator = %(account)s
  AND usage_type = 'compute'
  AND currency = 'USD'
  AND date >= DATEADD(day, -7, CAST(%(start)s AS DATE))
  AND date <= CAST(%(end)s AS DATE)
ORDER BY date

Four details in that query are load-bearing, and three of them we got wrong before we got them right:

• by dayRates move. Pricing a 30-day window at one rate reintroduces the same class of error in miniature, so each day's credits are priced at that day's rate — and the billing rollup had to be regrouped by day to match.
• −7 daysThe window is padded a week backwards. Rate rows can have gaps, and the first days of a report would otherwise find nothing to inherit from.
• USD onlyRate-sheet rows arrive in the organisation's billing currency. Rendering a euro rate under a $ is not a rounding error, it is a false statement, so non-USD organisations fail loudly with instructions instead.
• locatorThe one that nearly shipped silently wrong. It gets its own section.

Everything in ACCOUNT_USAGE is scoped to the account you are connected to. That is the mental model you bring to ORGANIZATION_USAGE, and it is wrong. The name is the warning: it holds one row per account per date, for every account in the organisation.

Drop the account_locator filter and the query still runs. It still returns one row per date, because you grouped or iterated by date. It just returns whichever sibling account's row landed last. Your credits get priced at another account's rate — and since attribution and reconciliation read the same source, both sides move together and stay perfectly consistent with each other while being wrong.

The fix resolves CURRENT_ACCOUNT() once and binds it as a parameter. And when the locator cannot be resolved, the adapter skips the rate sheet entirely and falls back to the flat rate rather than reading the view unscoped — a known approximation being strictly better than a confident wrong answer.

A rate that looks more plausible is not evidence. The check that matters is whether the dollars reconcile against ORGANIZATION_USAGE.USAGE_IN_CURRENCY_DAILY — the view behind what Snowflake actually invoices. Same day, three ways of computing it:

To the cent, against Snowflake's own figure. The flat rate was off by 23% on the same credits.

ORGANIZATION_USAGE is not readable on every account, and getting to it is a larger ask than the grant the rest of the tool needs. In an ORGADMIN-enabled account, only ACCOUNTADMIN has privileges on the shared SNOWFLAKE database by default. Reaching the view from a read-only reporter role means an administrator granting the relevant database role — or the SNOWFLAKE.ORG_USAGE_ADMIN application role on an organisation account. Worth being upfront that this is a heavier permission than ACCOUNT_USAGE needs, not a formality.

And one case is not a permissions problem at all: accounts on a contract signed through a Snowflake reseller cannot read this view at any privilege level. For them — and for anyone who simply will not get the grant — a flat rate remains the only option available, which is why it survives as a documented fallback rather than being deleted. The difference now is that the report says which one it used.

What changed is that this is now stated rather than assumed. The preflight check probes the view over the same window the report will use, and fails loudly on two conditions: unreadable, and readable-but-zero-USD-rows. The second matters more than it looks — a non-USD organisation returns rows happily, just none in dollars, and without that check it would flat-rate every credit while the report claimed account-rate accuracy.

Per-query attribution also only ever covers compute. Idle warehouse time and cloud-services credits are real money that no query-level view can attribute, and the report states that share instead of quietly folding it in. Getting the rate right does not change what is attributable — it only means the part we do attribute is priced at your rate rather than a brochure's.