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.
| What it counts | Sum across subscription records where status = active of (items.data[].price.unit_amount × items.data[].quantity) normalised to a monthly equivalent. Normalisation rules: daily prices ×30, weekly prices ×4.33, monthly prices passed through directly, yearly prices ÷12. Multi-month and multi-year intervals (e.g. interval = month, interval_count = 3 for quarterly) are normalised by ÷ interval_count. |
| Active vs trialing vs past_due | active only. Trialing subscriptions (the customer is in a free trial period) do NOT count toward MRR until they convert to paid status. Past_due subscriptions (the renewal charge failed but Stripe is still attempting recovery) DO count, because the contract is still in force; once the subscription transitions to unpaid or canceled it drops out. The stripe_active_subscriptions card uses the same active-only filter. |
| Currency | Multi-currency without FX. Each subscription’s MRR is calculated in its own currency. A USD-primary brand with EUR + GBP subscriptions sees three currencies summed arithmetically. Use the per-currency view from stripe_revenue_by_currency for the unambiguous breakdown, or normalise externally to the brand’s reporting currency. |
| Fees / processing cost | Gross. Stripe processing fees (~2.9 percent + 30¢ for cards) are not deducted. The “what I’ll actually keep” view is approximated by MRR × 0.97 for typical card-mix subscription brands, or stripe_net_revenue for a precise post-fee figure on realised revenue. |
| Discounts and coupons | Applied. Stripe applies coupons and percent-off discounts at the price level before MRR calculation, so a 80/month MRR. Trial coupons that reduce price to 0 MRR until the trial converts. Some merchants prefer the “list-price MRR” view that ignores discounts; this is available via the optional mrr_basis = list_price configuration. |
| Quantity | Multi-seat and multi-quantity subscriptions are summed correctly. A team-tier subscription at 250/month MRR. The subscriptions.items.data[].quantity field drives the multiplication. |
| Refunds | NOT deducted. MRR is a forward-looking contracted-revenue metric, so historical refunds do not change today’s MRR figure. A customer who is refunded but whose subscription stays active continues to contribute their full MRR. If they cancel, the cancellation drops the MRR; the refund itself does not. |
| One-time invoice line items | Excluded. One-shot purchases, prorations, setup fees, and overage charges are not part of MRR. Only the recurring price components count. The stripe_total_revenue view captures everything including one-shots. |
| Multi-product subscriptions | Each subscription_item within a single subscription contributes its own MRR component; a subscription with three products (base + two add-ons) sums all three to the subscription’s total MRR contribution. |
| Annual prepay treatment | An annual subscription paid up-front for 100/month MRR even though no cash flows in months 2-12. This is the standard SaaS-industry convention: MRR is recognised contracted revenue, not realised cash. The cash-flow view sits in stripe_payouts_pending and account balance cards. |
| ARR conversion | ARR = MRR × 12. Many merchants prefer ARR (annual recurring revenue) for board reporting because it is comparable to top-line revenue figures. The stripe_arr sibling card surfaces this directly when merchants want to skip the multiplication. |
| Time window | 30D vsP (30-day point-in-time snapshot vs same time 30 days ago). MRR is a stock metric (snapshot at a moment) rather than a flow metric (sum over a period); the comparison is point-in-time vs point-in-time, not period sum vs period sum. |
| Alert trigger | drop >10 percent vsP (10 percent decline in 30 days indicates either a major customer cancellation cluster or a billing-system failure dropping subscriptions to past_due/canceled status). |
| Sentiment key | revenue_trend |
| Roles | owner, finance |
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.| Plan tier | Active subs | Monthly normalised price | MRR contribution |
|---|---|---|---|
| Starter monthly ($29/mo) | 1,840 | $29 | $53,360 |
| Starter annual ($290/yr, 17% discount) | 620 | $24.17 | $14,985 |
| Pro monthly ($79/mo) | 1,150 | $79 | $90,850 |
| Pro annual ($790/yr) | 480 | $65.83 | $31,598 |
| Pro per-seat ($15/user/mo, avg 18 users) | 240 | $270 | $64,800 |
| Enterprise annual ($24,000/yr) | 18 | $2,000 | $36,000 |
| Enterprise multi-year (3-year prepay $60,000) | 4 | $1,667 | $6,668 |
| Trialing (not yet converted) | 312 | n/a | $0 |
| Past_due (renewal failing, recovery in progress) | 87 | varies | $4,290 |
| Account total | 4,749 (excl. trialing) | $302,551 |
- **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
| Card | Why merchants reach for it |
|---|---|
stripe_arr | Annual Recurring Revenue, computed as MRR × 12. The board-reporting framing for MRR. |
stripe_active_subscriptions | The customer-count denominator alongside MRR’s revenue figure. ARPU = MRR ÷ active subscriptions; comparing both gives a cleaner read than either alone. |
stripe_mrr_movement | Decomposes MRR change into New / Expansion / Contraction / Churn. Critical for understanding why MRR moved, not just that it moved. |
stripe_involuntary_churn | The billing-failure-driven churn component. Recoverable through dunning, smart retries, and updated card-on-file flows. |
stripe_voluntary_churn_rate | The customer-initiated cancellation rate. Reflects product satisfaction and pricing fit rather than payment infrastructure. |
stripe_seat_expansion_rate | For per-seat plans, the seat-count change rate. Drives MRR even at steady customer counts. |
stripe_recurring_failure_rate | The renewal-charge failure rate. Leading indicator for involuntary churn. |
stripe_dunning_recovery_rate | The percentage of past_due subscriptions recovered to active. Measures the effectiveness of the billing-failure response process. |
stripe_annual_renewal_pipeline | Upcoming annual renewals, sized as MRR-at-risk. Helps prevent sudden MRR cliffs from annual-cohort failures. |
stripe_total_revenue | The total charge volume including one-shots and prorations. Use alongside MRR to size the recurring vs one-shot mix. |
stripe_net_revenue | Post-fee, post-refund realised revenue. The “what we keep” view alongside MRR’s “what we have under contract” view. |
stripe_xc_recoverable_revenue | Cross-channel view combining MRR-at-risk with recoverable declines, dunning queue, and upgrade pipeline to size the next-30-day forward revenue picture. |
Klaviyo klv_revenue_per_recipient | The marketing-side recurring-customer engagement view. Subscription brands with strong MRR but weak email engagement are at higher long-term churn risk. |
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.
| Reason | Direction | What to do |
|---|---|---|
Trial inclusion convention. Stripe Dashboard’s MRR widget excludes trialing subscriptions by default but has a UI toggle to include them; Vortex IQ excludes trialing by default and has a separate mrr_with_trial card for the included view. | Stripe Dashboard higher if toggle enabled, otherwise matches | Confirm the Dashboard toggle state when reconciling. |
| Discount handling. Stripe Dashboard sometimes shows “list-price MRR” (pre-discount) for forecasting; Vortex IQ shows “realised MRR” (post-discount, what you actually bill). | Stripe Dashboard often higher during heavy discount periods | Use the mrr_basis = list_price configuration if the merchant prefers list-price MRR for board reporting. |
| Multi-currency. Both views sum arithmetically without FX. No reconciliation difference here. | Match | n/a |
| Snapshot timing. Vortex IQ snapshots at refresh time (typically every 6 hours); Stripe Dashboard is real-time. Subscription state changes (new sub, cancellation, status transition) between the snapshot and the comparison can cause divergence. | Either direction | For board-reporting, anchor both views to the same point-in-time using the as_of parameter. |
| Past_due treatment. Stripe Dashboard’s MRR widget excludes past_due subscriptions by default; Vortex IQ includes past_due because the contract is still in force. | Vortex IQ higher when past_due rate is high | This is the most common source of reconciliation gap. The Vortex IQ view is the right one for runway calculations; the Stripe view is the right one for “MRR I will actually collect this month”. Both have valid uses. |
| Quantity changes mid-cycle. Subscriptions where the seat count changed mid-cycle have a small period during which the old quantity and new quantity overlap (Stripe handles this with prorations); the MRR snapshot during this overlap can show either old or new quantity depending on the snapshot timing. | Either direction | Negligible at scale; ignore for portfolios above ~500 subscriptions. |
| Comparison | Expected relationship | When divergence is legitimate |
|---|---|---|
stripe_mrr ↔ Recharge mrr | Independent for Shopify subscription brands using both | Recharge MRR includes Recharge-managed subscriptions; Stripe MRR includes Stripe Billing subscriptions. The two should sum to the brand’s total subscription book if both are connected. |
stripe_mrr ↔ Chargebee mrr | Should match if Chargebee is the system of record | Brands using Chargebee for subscription management with Stripe as the payment processor should see Chargebee MRR ≥ Stripe MRR (Chargebee includes any non-Stripe-paid subscriptions plus Stripe-paid subscriptions). |
stripe_mrr ↔ Recurly mrr | Should match if Recurly is the system of record | Same logic as Chargebee. |
stripe_mrr ↔ Internal accounting (deferred-revenue ledger) | Stripe MRR ≥ accounting MRR for a given month if multi-month prepays | Accounting recognises revenue ratably, so multi-month prepays show as deferred revenue on the balance sheet rather than MRR. The reconciliation works through the deferred-revenue rollforward. |
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.