Why your Stripe MRR is wrong

Credit where due: Stripe's Billing analytics has grown up. It normalises annual plans to monthly, excludes one-time charges and taxes, and always subtracts permanent discounts. The problem is no longer sloppy arithmetic — it is that Stripe's MRR is built on a specific set of documented definitional choices, and the danger is assuming those choices match yours. Several of them are configuration toggles you may never have opened.

The drift matters because MRR is the denominator of everything: growth rate, churn rate, NRR, quick ratio. A definition mismatch of a few percent quietly reshapes every metric built on it — and it compounds exactly when you scrutinize it least, in the months everything looks fine.

The gaps that remain in 2026, roughly in order of damage:

• Usage-based revenue is excluded entirely — Stripe's MRR counts no metered products, so a usage-priced business systematically underreports its recurring revenue.
• Past-due subscriptions still count as MRR — revenue that may never arrive is in the headline number until the subscription is cancelled or marked unpaid.
• Discount toggles — permanent discounts are always subtracted, but time-boxed coupons and one-off discounts only reduce MRR if you switched the setting on.
• Gross volume is not MRR — the payments charts show cash where it landed, so a $1,200 annual prepay reads as a January spike; quoting those charts as recurring revenue is the classic conflation.
• Prorations and mid-cycle plan changes — upgrade credits and partial invoices are billing artifacts, not recurring revenue; any pipeline that sums invoices mixes them in.
• Refunds and disputes — cash went back out, but the subscription object looks the same, so MRR doesn't move.
• Multi-processor reality — Stripe only sees Stripe; PayPal, wire-transfer enterprise deals and app-store revenue live outside its MRR entirely.

Rebuild MRR from first principles instead of reading it off a billing dashboard: normalise every active subscription to its true monthly recurring value — post-discount, prepays spread across their term, non-recurring charges excluded — then reconcile month-over-month movement into exactly five buckets: new, expansion, contraction, churn and reactivation. If the movements don't sum to the change in total MRR, the model is wrong somewhere, and the reconciliation tells you where.

This is the discipline every serious subscription-analytics setup enforces, whether built in-house or bought. The test of a trustworthy MRR is not that it matches Stripe — it is that every dollar of change is attributable to a named movement on a named account, across every processor you use.