Skip to main content

​
Revenue recognition: read deferred vs recognized schedules

The Revenue recognition page (/billing/revenue-recognition) turns the money you collected up front — committed-use commitments and subscription invoice lines — into two ledger questions a finance team answers every month: how much is earned, and how much is still deferred. The page renders the ratable straight-line schedule per contract and the recognized-to-date versus deferred-remaining split as of the reporting date. This guide is the finance-ops walkthrough for that surface. Read the endpoint semantics first in Revenue recognition; this guide adds the reporting workflow — paced for RevOps and Finance admins on the owner, admin, or billing roles. The loop:
  1. The deferred-vs-recognized model and the ratable schedule the page renders.
  2. Attach the contract to a cost center and pull the schedule per department.
  3. Read recognized-to-date vs deferred balance on the dashboard page.
  4. Reconcile against statements and model what-if before you commit.
  5. Run the month-end close checklist.

​
1. Deferred vs recognized for committed-use and subscription contracts

Deferred revenue is a liability until it is earned. Two contract shapes in your account carry it:
  • Committed-use commitment — a negotiated prepaid monthly commit. The total contract value is the monthly commit × the whole months in the term; recognition runs straight-line over the term. When the commitment carries no term dates the schedule falls back to the current billing period, so a schedule always exists (its source renders as committed_use / Committed use in the page).
  • Subscription invoice lines — each positive-amount line on a subscription invoice recognizes over its own service window; when the line has none the window falls back to the invoice’s billing period, then the invoice-date month (its source renders as subscription / Subscription).
Recognition within a window is straight-line by day: each calendar month earns a share proportional to the window days inside it, so February earns less than January on a flat-rate schedule. A cumulative rounding method keeps the period entries summing to the contract total exactly — the final period absorbs the residual cent. The ratable schedule is the per-month table the page renders under the contract card: one row per calendar month with the amount recognized in that month, summed so the entries always equal the contract total. The page itself is read-only; every call recomputes the schedule from live contracts at request time. Limits to remember when you read the numbers:
  • Credit and zero-amount invoice lines do not recognize and are excluded.
  • The rollup requires one currency (commitment currency, else first subscription-line currency, else USD).
  • Subscription history comes from the most recent invoice page (up to 50 invoices).
The endpoint semantics are in full in Revenue recognition — this guide assumes them.

​
2. Attach the contract to a cost center, then pull the schedule

Revenue attribution per department starts with a tag. Set the metadata.cost_center label on the sends that consume the committed budget (exact convention in the Cost-center chargeback guide). Then attribution for the revenue side runs one contract at a time:
  1. Tag sends where the charge should land — the same tag drives the department-first chargeback rollup and the cost-center statement cards on the Records page (/billing/records) and the Cost centers page (/billing/cost-centers).
  2. In the Revenue recognition page, filter the contract into the right cost-center view — a committed-use card for the monthly-commit contract, a subscription card for the recurring invoice line. Page filters respect the tag on the source rows.
  3. Pull the schedule once the contract is attached — the API keeps the same filter grammar:
Each card carries a source badge (Committed-use or Subscription), the service window dates, the recognized/deferred split, and the month-by-month schedule table. Until a contract is attached to a cost center the schedule still renders — the card is just attributed to the unallocated bucket.

​
3. Read recognized-to-date vs deferred balance

Open Dashboard → Billing → Revenue recognition (/billing/revenue-recognition). The page reports as of the current time; for a fixed reporting date pass as_of on the API. Gated to owner, admin, or billing, matching the API.
  • Stat cards — total contract value, recognized to date, and deferred remaining across all contracts.
  • Recognized by period — the cross-contract table of revenue per calendar month, ascending.
  • Per-contract schedule cards — one card per contract with source badge, service window, recognized/deferred split, and the per-month table.
An account with no committed-use commitment and no subscription invoices sees an empty state that explains when schedules appear — nothing is broken; attach a contract and the page fills in. The dashboard reads the same two endpoints the API serves (/billing/revenue-recognition/schedule and /billing/revenue-recognition/summary), so the figures you paste into a journal match the API reply exactly.

​
4. Reconcile with statements and the what-if simulator

Statements — the monthly wallet summary in Billing → Statements (/billing/statements) — are the authoritative record of wallet movement for the same window. Confirm two things at close: the recognition period’s recognized-to-date total reconciles against the wallet’s closing balance from the statement (no orphan ledger drift), and the deferred remainder still sits in the liability bucket. The full statement export workflow is in Billing ops: invoices, statements, and pay by link. What-if simulator — the Pricing simulator (/billing/simulator) replays your recorded traffic through a candidate rate card over a 1–90 day look-back. Use it before you negotiate a new committed-use term so the recognition schedule you commit to is sized against real usage. The deeper walkthrough is in What-if pricing simulator. Pay-by-link accrual — a payment link still awaiting collection is accrued revenue on the ledger even though no wallet statement exists yet; the statements list skips it, so treat it as an accrual entry until the payment settles.

​
5. Month-end close checklist for finance

A reproducible close for the August period, run by a Finance admin:
  1. Fix the reporting date. Pull the summary with an explicit as_of=2026-08-31 so reruns of the close reproduce identical figures.
  1. Journal the split. Post recognized_to_date and deferred_remaining from the summary into your journal, using the contract_id mapping your finance team set once (committed-use for the commitment, else the invoice and line identifier).
  2. Anchor the dashboard read. The recognition page already reflects the contract as of the current time — read it over the same window you posted in step 2 and confirm the two match.
  3. Catch the pay-by-link accrual. Treat uncollected payment links as accrual entries until settlement; only then recognize.
  4. Confirm the statement window. Statements up to 60 months are authoritative for the same period; reconcile against the closing wallet balance to rule out orphan ledger drift.
  5. Archive the JSON. The response schema is stable and integer-exact, so the connector or export path you used at close keeps working month over month without remapping.