> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Revenue recognition: read deferred vs recognized schedules

> Walk the deferred-revenue workflow end to end — the ratable schedule model, attaching contracts to a cost center, reading recognized-to-date vs deferred on the Revenue recognition page, reconciling with statements, and the month-end close checklist.

# 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](/billing/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](/billing/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](/guides/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:

```bash theme={null}
curl "https://api.orbit.devotel.io/api/v1/billing/revenue-recognition/schedule?as_of=2026-08-31" \
  -H "X-API-Key: dv_live_sk_your_key_here"
```

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](/guides/billing-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](/guides/whatif-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.

```bash theme={null}
curl "https://api.orbit.devotel.io/api/v1/billing/revenue-recognition/summary?as_of=2026-08-31" \
  -H "X-API-Key: dv_live_sk_your_key_here"
```

2. **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).
3. **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.
4. **Catch the pay-by-link accrual.** Treat uncollected payment links as
   accrual entries until settlement; only then recognize.
5. **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.
6. **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.

***

## Related

* [Revenue recognition](/billing/revenue-recognition) — the endpoint
  semantics behind every figure on this page.
* [Billing overview](/billing/overview) — the wallet, committed-use
  contracts, statements, and pay-by-link surfaces.
* [Cost-center chargeback](/guides/cost-center-chargeback) — the
  `metadata.cost_center` tagging convention.
* [Billing ops: invoices, statements, and pay by
  link](/guides/billing-invoices-statements-and-pay-by-link) — the statement
  export workflow and pay-by-link accrual handling.
* [What-if pricing simulator](/guides/whatif-pricing-simulator) — candidate
  rate-card replay before you commit a term.