Sum of normalised plan amounts across active subscriptions, the SaaS north-star metric.
At a glance
The contracted recurring revenue across all active Stripe subscriptions, normalised to a monthly equivalent. MRR is the bedrock metric for any subscription business because it answers the single most important question merchants ask: “what revenue do I have under contract for next month, before I do anything new?” Unlike trailing revenue (a backwards-looking number) or total charge volume (a noisy mix of one-time and recurring), MRR strips the business down to its forward-looking recurring base.
Calculation
Calculated automatically from your Stripe data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A SaaS-on-Stripe brand selling team productivity software with a mix of monthly, annual, and per-seat plans. Snapshot taken at 09:00 UTC on Wednesday 15 May 26.
What the per-cohort view is telling us:
- **The 64,800 is the highest-MRR cohort despite being only 240 customers, which is the classic SaaS pattern of “land-and-expand”. Each Pro per-seat customer averages 79 for Pro flat-rate, indicating these accounts are scaling internally.
- The Pro per-seat tier is the engine of MRR growth. A 10 percent expansion in Pro per-seat customers (240 → 264) at the current 6,480 MRR, vs the same 10 percent growth in Pro monthly (1,150 → 1,265) at 9,085 but requiring 4.8x more customers. The Vortex Mind Customer Recovery Opportunity report should prioritise expansion within Pro per-seat accounts because the unit economics are dramatically better than acquiring net-new Pro monthly customers.
-
The annual cohorts are stickier but discount-loaded. The Starter annual cohort at 29 for Starter monthly represents a 17 percent discount. Whether that 17 percent is recovered through (a) reduced churn (annual customers churn at ~3 percent vs ~6 percent for monthly) or (b) reduced billing-failure rate matters for the unit economics. Pair with
stripe_recurring_failure_rateandstripe_involuntary_churnto verify. - The 87 past_due subscriptions contributing 1,287 to $1,716 over the next two weeks absent operational intervention. Brands with weak dunning communications can expect losses at the higher end of that band.
-
The 312 trialing subscriptions represent forward MRR pipeline. At industry-typical 25-40 percent trial-to-paid conversion rates, expect 78-125 trial conversions to close within the next 14-30 days, adding roughly 9,000 MRR depending on which plan tier they convert into. The
stripe_alert_3ds_failureand trial-conversion friction cards surface where the trial-to-paid conversion is breaking. - Enterprise multi-year prepay distorts the interpretation. The 4 Enterprise multi-year customers prepaid 6,668 of that contributes to current MRR. The remaining $80,000+ in deferred revenue sits on the balance sheet. Brands with significant multi-year prepay should track ARR alongside MRR because MRR understates the contracted-revenue book during prepay accumulation periods.
- Decompose new vs expansion vs contraction vs churn MRR, the four MRR-movement components. Net New MRR = New MRR + Expansion MRR - Contraction MRR - Churn MRR. The
stripe_mrr_movementcard breaks the period change into these components. A drop in net MRR usually concentrates in one component, churn or contraction; isolating which lets the team target the fix. - Pair with
stripe_active_subscriptions. If MRR fell but active sub count is steady, the issue is contraction (downgrades, seat reductions) rather than cancellations. The fix is in customer success and product engagement, not in retention. - Cross-reference with
stripe_involuntary_churn. A spike in past_due-to-canceled transitions points to billing-system issues (expired cards, smart-retry failures, dunning email gaps) that recover with operational tightening rather than product or pricing changes. - For seat-based plans, layer the seat-count view from
stripe_seat_expansion_rate. Per-seat plans drift in MRR even at a steady customer count if seats expand or contract. A flat customer count with shrinking seat counts is a leading indicator of net-revenue retention drift. - Annual cohort renewals are a separate risk surface. Every annual customer hits a renewal moment 12 months after their start date. The
stripe_annual_renewal_pipelinecard surfaces upcoming renewals; an unaddressed annual-renewal failure delivers the entire annualised MRR drop in one billing cycle, which can cause sudden MRR cliffs.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look in Stripe’s own dashboard:- Stripe Dashboard → Billing → Subscriptions for the live list of active subscriptions with their plan amounts and recurring intervals.
- Stripe Dashboard → Billing → Overview has Stripe’s own MRR widget. This is the closest 1-to-1 comparison to this card and uses substantially the same calculation (active-only, normalised to monthly, multi-currency summed arithmetically).
- Stripe Sigma (the SQL query interface, available on Stripe Plus) for custom MRR reporting using the official
subscriptionsandsubscription_itemstables. Sigma is the source-of-truth for MRR queries because it bypasses any UI-layer rounding or sampling.
Cross-connector reconciliation:
Quick rule for support tickets: if a merchant says “Stripe Dashboard shows 310k” in the same period, walk through the table above in order. Past_due treatment is the single most common cause of this specific gap. The next-most-common is trial-inclusion toggle state; the third is discount-basis convention. For brands using Chargebee or Recurly as the system of record, those tools’ MRR figures should be the canonical source rather than Stripe’s; the Stripe MRR view in that case is the “MRR currently flowing through Stripe” subset rather than the brand’s full subscription book.
Known limitations / merchant FAQs
Why is my MRR lower than my last month’s revenue? Three common causes. (1) One-time charges: setup fees, overage charges, prorations, and one-shot purchases that contributed to last month’s revenue do not count in MRR. Thestripe_total_revenue card includes everything; MRR is recurring-only. (2) Annual prepays: a customer who prepaid 1,200 to last month’s revenue but only $100/month to MRR. (3) Refunds and cancellations: revenue recognises at charge time and reverses on refund, while MRR drops only when the underlying subscription cancels.
Should I track MRR or ARR?
Both, depending on audience. MRR is operational (used by customer success, finance ops, growth marketing for monthly tracking) and ARR is strategic (used in board reports, fundraising decks, and external benchmarks). The two are mathematically identical (ARR = MRR × 12) so there is no information difference, just framing. Most brands report both with a note that ARR is “MRR × 12” to avoid implying ARR is a separate calculated figure.
My MRR jumped 8 percent overnight. Did something break?
Possibilities, in order of likelihood. (1) A new pricing tier launched and existing customers were migrated. Stripe records this as new subscription items at higher prices; the migration moment shows as a step-change. (2) A coupon expired: time-bound discounts (e.g. “first 3 months 50 percent off”) roll off automatically; if a cohort of subscriptions hit their coupon-expiry on the same day, MRR jumps. (3) A subscription state-correction: subscriptions stuck in past_due for an extended period that suddenly resolved to active (perhaps via a successful retry after a card update) lift MRR back up. Pair with stripe_dunning_recovery_rate to see if recovered past_due is the cause. (4) A new annual cohort renewed and converted from monthly to annual at a different price point. (5) Genuine new business that hit on a single day, less common but possible if a marketing campaign or partnership launched.
Why does my MRR include subscriptions whose latest charge failed?
Past_due subscriptions remain in MRR because the contract is still in force. The customer has not cancelled; the most recent charge failed but Stripe is attempting recovery. Industry data suggests 60-70 percent of past_due subscriptions are recovered; only 30-40 percent transition to canceled. Excluding past_due from MRR over-corrects, you are then under-reporting MRR by the recoverable portion. The right approach is to track MRR and “MRR-at-risk” (sum of past_due MRR) separately so the merchant can see the headline number plus the risk overlay.
How do I model net-revenue-retention from this card?
NRR (Net Revenue Retention) = (starting MRR + expansion - contraction - churn) ÷ starting MRR. For the cohort starting at month T-12, look at their MRR contribution in month T (after expansions and contractions and churns) and divide by their MRR at T-12. Healthy SaaS NRR is 100-110 percent (the cohort net-grows even after losing some customers); best-in-class is 120 percent+ (expansion dominates churn). The stripe_mrr_movement card surfaces the components needed for this calculation.
My company uses Chargebee/Recurly/Stripe Billing for subscription management. Which MRR is canonical?
The system of record. If Chargebee is the source-of-truth for subscription state (and Chargebee tells Stripe what to charge), then Chargebee’s MRR is canonical and Stripe’s MRR shows only the subset that actively flowed through Stripe in the period. If Stripe Billing is the system of record (subscriptions managed directly in Stripe), then Stripe’s MRR is canonical. Brands sometimes have both: Stripe Billing for direct sales, Chargebee for enterprise contracts. In that case the canonical MRR is the sum, and each card shows its slice.
Why does Vortex IQ show MRR for a customer who cancelled yesterday?
Snapshot timing. The MRR card refreshes on a schedule (typically every 6 hours); cancellations between refreshes show in the card on the next refresh. Stripe Dashboard is real-time and reflects the cancellation immediately. For point-in-time reconciliation, anchor both views to the same as_of timestamp.
Can Vortex IQ trigger MRR-recovery actions?
Vortex Mind’s Customer Recovery Opportunity report uses MRR-at-risk as one of its inputs and generates merchant-side Actions when recoverable MRR exceeds a threshold. The Vortex IQ engine surfaces the opportunity (which subscriptions are past_due, which annual renewals are upcoming, which seat-counts are contracting); the merchant’s customer success team executes the outreach inside their own tooling.
Is MRR the right metric if I sell mostly one-shot products with a few subscription add-ons?
Probably not as a headline metric. MRR is the right metric for businesses where recurring revenue is the dominant story; for primarily transactional businesses (ecommerce stores selling products with optional subscription add-ons), stripe_total_revenue and the order-frequency cards from the upstream commerce platform tell the bigger story. A useful rule: if recurring revenue is more than 30 percent of total revenue, MRR matters; under 30 percent, it is an interesting subset metric but not the headline.