What Stripe's MRR report still doesn't tell you

Stripe’s MRR analytics is genuinely good now. The Billing overview shows an MRR growth waterfall that separates new, expansion, contraction, churn, and reactivation. You can click into a movement and see which customers drove it. There’s cohort retention, trial conversion, ARPU, and LTV. If you looked a few years ago and wrote it off, it’s worth another visit.

So this isn’t a “Stripe can’t do analytics” post. It’s narrower and more useful than that. There are a handful of questions the native MRR reporting still can’t answer, and they tend to be the exact ones you’re asking when revenue is actually on the line. Here they are, straight from how Stripe defines the metric.

It shows run-rate, not committed revenue

Stripe’s MRR is a snapshot of what your currently active subscriptions would bill. It’s a run-rate. What it doesn’t reflect is what you already know is coming: the customer who set a cancellation for the end of next month, the account that agreed to downgrade at renewal, the annual contract lapsing in three weeks. A subscription already flagged to cancel at period end, for instance, keeps counting in full toward MRR right up until the term closes. Those are committed changes, and until the day they take effect they don’t move the number. Committed MRR, the figure that nets known future changes against today’s run-rate, is often the one you actually want at close, because it’s the one you can still act on. It isn’t in the report.

It won’t tell you if price or seats moved the number

Stripe’s waterfall tells you MRR expanded or contracted, and by how much. What it won’t tell you is what moved it: a price change or a change in quantity. For a per-seat product those are opposite stories. Twenty thousand of expansion because a customer added forty seats is healthy adoption; the same twenty thousand from a list-price increase is not. And a contraction because an account is shedding seats is one of the earliest churn signals you can get, long before anyone cancels. Stripe reports the dollar movement and its type, but never the price-versus-quantity split underneath it, so seat erosion sits in the same contraction bucket as a discount.

It doesn’t separate a cancellation from a failed payment

In Stripe’s own definitions, a subscriber churns when their subscriptions are “canceled or marked as unpaid.” Those are two very different problems wearing the same label. A cancellation is a customer who decided to leave, a product or value question. An unpaid subscription is very often a card that expired or a charge that failed, a billing problem you can usually recover with a retry or a quick nudge. The churn metric lumps them together, so you can’t see how much of this month’s loss is voluntary versus how much is involuntary payment failure sitting there waiting to be won back. And before a failing account even reaches that point, a subscription stuck in past_due keeps counting at full value in MRR, so the revenue quietly at risk is invisible inside the top-line number.

Even for the voluntary half, the report won’t tell you why. Stripe can collect a cancellation reason, but only from a fixed five-option list, only when a customer leaves through the self-serve portal, and only on that one subscription’s page. There’s no aggregated view of why customers are leaving, no reason captured for the accounts that churned any other way, and no room for reasons that fit your business instead of Stripe’s five.

It reports the past, it doesn’t project the future

Everything in the native analytics describes what already happened: MRR to date, churn last period, retention by cohort. That’s the right foundation, but none of it answers where MRR is headed. There’s no forward projection, no way to model what happens if a cohort renews at 85 percent, and no timeline of which renewals are coming and how much revenue rides on each. When someone asks what next month looks like, or which of next quarter’s renewals are most exposed, the dashboard can only tell you what last month did.

Where SubscriptionMonitor fits

SubscriptionMonitor keeps the same MRR base Stripe uses, including past_due and cancel-at-period-end subscriptions, but it breaks out what that single number hides. Its Revenue Dashboard shows committed MRR (CMRR) next to your run-rate, netting out the cancellations and downgrades already scheduled, so cancel-at-period-end revenue leaves the committed view before it leaves your account. A quantity lens splits every movement into price-driven and seat-driven, so seat erosion surfaces as its own signal instead of hiding inside contraction. Delinquent Revenue isolates the MRR still sitting in past_due and failed-payment states, the at-risk revenue you can act on. Retention separates voluntary cancellations from failed-payment churn, and lets you tag any churned account with your own custom reasons and see them broken down, so “why are we losing customers” has an answer beyond Stripe’s five canned options. Forecasting projects MRR under different scenarios, and a renewal wall lays out which renewals are coming over the next month to year, ranked by revenue exposure and risk, so you can work the future instead of only reporting the past.

Stripe will tell you your MRR, accurately and in real detail. These are the few questions that begin where its report ends.