The credit-based cost model

CLOUD COMPUTE            SNOWFLAKE COMPUTE
─────────────────────────────────────────────────────────────
m5.large × 730 hours     warehouse credits consumed
× $/hour                 × $/credit for your edition

The instance existed     The warehouse only consumed while
whether or not you       it was RUNNING A QUERY, and it
used it.                 auto-suspends when idle.

COMPUTE (the majority of most bills)
  warehouse credits consumed × per-edition credit rate
  Credits scale with warehouse SIZE: each step up the
  size ladder roughly doubles the credits per hour.

STORAGE
  per-table ACTIVE BYTES
  Charged on what the table actually occupies, including
  the overhead of Time Travel and Fail-safe retention.

WAREHOUSE SIZE     RELATIVE CREDIT BURN
  X-Small                1×
  Small                  2×
  Medium                 4×
  Large                  8×
  X-Large               16×
  ... and onward

A query that finishes in 60s on a Medium may finish in
35s on a Large. It did not cost less: it burned 8× the
per-hour rate for 58% of the time, which is MORE.

The optimization question is never "is it fast enough".
It is "does doubling the size more than halve the runtime".
Below that line, sizing up costs money.

ZopNight's figure   derived from ACCOUNT_USAGE warehouse
                    credit consumption × edition rate

The customer's own  the SAME ACCOUNT_USAGE billing views

So a disagreement is almost always one of three things:
  1. edition mismatch   ZopNight has the wrong per-credit
                        rate for this account
  2. window mismatch    ACCOUNT_USAGE views have their own
                        latency; comparing today to today
                        will disagree
  3. storage excluded   one side is comparing compute-only
                        against compute-plus-storage

THE COMPLAINT
  "ZopNight says $41,200 last month. Our Snowflake bill
   says $48,900. You're under-reporting by 16%."

STEP 1: SPLIT COMPUTE FROM STORAGE
  ZopNight, compute:      $38,900
  ZopNight, storage:       $2,300
  ZopNight, total:        $41,200

  The finance figure came off the invoice, which also
  included:
    data transfer                       $1,100
    Snowpipe / serverless features      $4,800
    materialized-view maintenance       $1,800
  ─────────────────────────────────────────────
                                        $7,700

  $41,200 + $7,700 = $48,900. Exact.

STEP 2: WHAT THIS ACTUALLY REVEALED
  Nobody was wrong about the money. But the $4,800 of
  serverless spend was invisible to the team until this
  comparison, and it was 10% of the bill.

  The Snowpipe file-batching signal (L4) exists for
  precisely this: many small files ingested individually
  burn far more than the same volume batched.

STEP 3: THE CHECK THAT SETTLES IT
  Run the credit query yourself in Snowflake and compare
  to ZopNight's compute figure for the same window. Same
  source, so they should agree to rounding. If they do
  not, check the account's EDITION first: a Standard rate
  applied to an Enterprise account is the usual cause.

1. Find your account's edition:                _________
   Does the per-credit rate ZopNight shows match that
   edition's published rate?                    Y / N

2. Split last month in ZopNight:
   compute $ ________   storage $ ________

3. Ask finance for the invoice total:  $ ________
   The gap:                            $ ________
   Name what lives in the gap (serverless features, data
   transfer, MV maintenance):
   ______________________________________________

4. Take your largest warehouse. What size is it?  ______
   Ask the owning team the only question that matters:
   "if we dropped it one size, would the jobs still
   finish inside their window?"      answer: ________

5. Find one table whose active bytes are large relative
   to its usefulness. Check its Time Travel retention:
   ______ days. Retention above 1 day on a rebuildable
   staging table is pure storage cost.