00 — Product
Status: draft
Audience: anyone designing or building RevRec Next
What we sell
Finance teams need to recognize revenue correctly under ASC 606 / IFRS 15 while Chargebee (billing) keeps changing — upgrades, credits, usage, custom terms — and the GL must stay clean.
RevRec Next is the revenue subledger:
| Capability | Customer outcome |
|---|---|
| Contracts & POs | Promises are explicit; amendments are policy, not archaeology |
| Recognition schedules | Deferred / unbilled match the standard |
| Close | Period lock, recognize, recon |
| Journals | Summarized posts to GL; detail stays in the subledger |
| Reporting | Waterfall, SaaS metrics, drill to contract/line |
| AR (Accounting Premium) | Sibling view on the same billing facts |
Public positioning reference: Chargebee Revenue Recognition.
Competitive / inspiration north star: Zuora Revenue — same product class (ASC 606 revenue subledger + close + reports). We take outcomes, not architecture. Scope tiers: 12-zuora-north-star-scope.md.
Product aims (why this exists)
The two anchor aims, then the supporting aims. If an aim is missing, add it here — this is the canonical list.
| # | Aim | What it means | Priority |
|---|---|---|---|
| A1 | Support end use cases | Finance/RevOps can onboard, close, amend, audit, and report without spreadsheets — see 10-use-cases-and-flows.md | Anchor |
| A2 | ASC 606 / IFRS 15 correctness | Five-step engine + modifications; recognition timing ≠ billing timing done right — see 01, 11 | Anchor |
| A3 | Audit & compliance | Every balance traces to a source event and a named policy; SOX-friendly, deterministic, replayable | High |
| A4 | Fast, trustworthy close | Explicit period state machine, recognize, journal post, lock — not a file job side effect | High |
| A5 | Disclosures | Deferred rollforward + RPO (remaining performance obligations, ASC 606-10-50) available as reports | High |
| A6 | Reporting & SaaS metrics | Deferred waterfall, ARR/MRR/NRR, drill to contract/line | High |
| A7 | AR / cash sibling (Accounting Premium) | Invoices, payments, CNs, aging as a projector on the same facts | Medium |
| A8 | Multi-entity / multi-currency | Functional currency + FX per entry; consolidation-ready | Medium |
| A9 | Operable & scalable | Owned extract; parallel by tenant/contract; a fat tenant never blocks the fleet | Medium |
| A10 | Extensible source model | Chargebee first; other sources via adapters emitting the same events | Later |
Everything in this repo should trace back to one of these aims. New complexity without an aim + demand + policy is suspect (see Stance in README).
In scope
- Chargebee as first source (bulk / poll / realtime over time)
- ASC 606 five-step engine + modifications
- AR / cash application as sibling projector (AC Premium)
- Ops store for mutable subledger state
- Analytics sink (e.g. ClickHouse) for heavy reporting
- Owned extract (Temporal-shaped) — not a permanent Hotglue dependency
Out of scope (for this product)
- Catalyst / Billing→ERP (NetSuite, Xero sync) — parallel product world; do not mix into RevRec design
- Replicating Hotglue
contracts.pyjoin logic as the definition of recognition - Non-Chargebee taps as day-one requirements (adapters later)
- Cloning Zuora RevPro internals (RC grouping template sprawl, Workbench UX, Hotglue CSV parity)
- Full enterprise Zuora parity on day one (multi-book, LT/ST, cost amortization, VC analyzer) — see 12 Later / Out
In-scope direction is the Zuora-class product outcome: finance-owned ASC 606 subledger, close, journals, waterfalls/disclosures, audit — Chargebee-native first. Exact tier cuts live in 12-zuora-north-star-scope.md until locked by ADR.
Correctness bar
Correct = ASC 606 + audit trail + close + journal integrity.
Not the bar = byte-identical OrderDetails / BillingSchedule CSVs vs today’s Hotglue output.
Shadow-compare during migration: accounting equality (amounts by period, by contract), not sheet equality.
Default merchant path (optimize for this)
Most SaaS:
- One performance obligation
- Ratable over a known term
- Invoices update billing / deferred — they do not invent the contract
Everything harder (multi-PO SSP, usage constraint, fancy CN policy, ramps) is an explicit feature on the same API — not a second ETL universe.
Open product questions
Track answers in decisions/ when locked.
- Is Chargebee subscription (+ contract_term) the Step-1 contract, or do we keep a sales-order abstraction?
- What % of volume is single-PO ratable vs multi-element / usage / PS?
- Are ramps / IBM first-class in Billing, or inferred today?
- Shared ledger core for RevRec + AC, or two projectors on shared facts?
Related
- Domain: 01-domain-asc606.md
- Architecture: 02-architecture.md