How to calculate NRR from Stripe data

More than it used to. Stripe's Billing analytics now includes revenue retention by cohort, which visualises how each signup month's revenue holds up over time — genuinely useful for spotting trends. What it does not hand you is the headline NRR your board and investors will quote: a single number, on your cohort definition, reconciled across everything you sell.

The gaps are structural. Stripe's view excludes usage-based revenue, sees only Stripe (not PayPal, wires, or app stores), and bakes in definitional choices — past-due handling, discount toggles — that may not match how you want to report. For anything beyond a directional read, you compute NRR yourself from the underlying objects.

Step one: normalise. For every subscription, compute its true monthly recurring value — post-discount, annual and multi-month prepays divided across their term, one-time charges and setup fees excluded. Do this per customer, not per subscription, so an account with two plans is one row. This normalised table, snapshotted monthly, is the foundation every retention metric stands on.

Step two: fix a cohort and difference the snapshots. Take all customers paying at the start of the period and their summed MRR; twelve months later, sum the same customers' MRR — everyone who churned counts as zero, everyone who expanded counts in full, and customers acquired since are excluded. Divide end by start: that is NRR. Classify the per-account deltas into expansion, contraction and churn along the way, and the movements must reconcile to the total — if they don't, the normalisation has a hole.

The usual suspects, in rough order of damage:

• Prorations and plan-change credits — sum invoice line items naively and every mid-cycle upgrade double-counts; always derive MRR from the subscription state, not the invoices.
• Cancel-at-period-end — a subscription flagged to cancel is still active today; decide whether your NRR treats it as retained until it actually ends (convention: yes).
• Past-due limbo — Stripe keeps past_due subscriptions in MRR; your NRR needs an explicit rule for when unpaid becomes churned.
• Usage-based components — metered revenue needs its own normalisation (usually trailing average), or usage-heavy accounts look like wild expansion-contraction swings.
• Multi-currency — convert at a fixed reference rate per period, or FX moves masquerade as expansion and contraction.
• Customer identity — mergers, duplicate customer records and processor migrations silently break cohort tracking; NRR is only as good as your account matching.

Reconcile in both directions. Your NRR should be consistent with your GRR plus expansion (the gross-to-net spread), and net revenue churn should be its mirror — 105% NRR means −5% net churn, computed from the same cohort. Numbers that disagree share a definition bug, and the disagreement points at it.

Then compare the trend — not the level — against Stripe's own cohort retention chart. The levels will differ for all the reasons above; the shapes should rhyme. A hand-rolled NRR trending up while Stripe's cohort view trends down means one of you is wrong, and it is worth finding out which before the board deck does.