Net revenue retention for product teams: define the event-to-cohort contract

Define net revenue retention from the recurring revenue of a starting customer cohort, then reconcile expansion, contraction and churn without adding new customers. Keep the period, currency and adjustment policy with the calculation.

Fix the starting cohort and revenue basis

Select the customers with qualifying recurring revenue at the opening boundary and define that revenue measure. A recurring run rate, recognized revenue, cash receipts and raw metered events are different inputs. Choose one and explain it. Record timezone, currency, treatment of annual plans and any excluded one-time fees or taxes. An account that becomes a customer midway through the period belongs outside the starting cohort for this calculation. Use stable customer identifiers; a renamed workspace should not look like churn plus a new sale simply because its display label changed.

Current primary documentation

Classify every change before aggregating

Stripe’s NRR explanation uses starting recurring revenue plus expansion, minus contraction and churn, relative to the starting base. Map each ledger change to a customer in that fixed cohort. Define reactivation and correction policies rather than letting them vary by reporting run. Usage-based products need a clear timing rule because consumption, invoice finalization and payment can occur in different periods. A product meter proves usage under its contract; it does not automatically define recurring revenue for NRR. Ask the finance owner to approve the measure before using it in formal reporting.

Reconcile the executed synthetic example

The local fixture opens with A at 100 units, B at 200 and C at 300, for a 600-unit starting base. A expands by 50, B contracts by 50 and C churns by 300. The ending revenue for that original cohort is 300, producing 300/600 or 50% NRR. A new customer D contributes 400 units and is explicitly excluded. Those are invented units and fictional customers. The script checks the arithmetic and stores the ledger with the result; it does not verify accounting policy or any real company’s financial performance.

NRR = (600 + 50 - 50 - 300) / 600 = 0.50
New-customer revenue of 400 is excluded.

Keep currency and adjustments reproducible

For multiple currencies, document the conversion source and whether opening and closing values use constant currency or period-specific rates. Record credits, refunds and backdated corrections with the policy version and effective period. Avoid overwriting the source ledger to make a report match an expected percentage. A reconciliation should explain starting balance, classified changes and ending cohort balance, with an unresolved bucket for entries that lack evidence. If opening recurring revenue is zero, report NRR as undefined for that cohort instead of dividing by zero or substituting a flattering value.

Use NRR to ask a product question

A cohort bridge can point toward failed activation, removed seats, lower usage or changed contracts, but the number alone cannot explain why customers changed spending. Connect a reviewed account change to permitted product evidence without exposing private billing details in analytics. Retain the extract, transformation and definition so a later period can be compared consistently. This guide is a metric implementation example, not investment advice. A founder review should see both the arithmetic and the limits, including the size and composition of the starting cohort and any incomplete billing periods.

Usage-based billing for AI SaaS: make every charge explainable

MVP evidence investors can inspect

Bring the reviewed revenue definition and a synthetic ledger to map billing events into a reproducible cohort bridge.

B2B SaaS development: scope and acceptance