MRR Recovery Calculation: Formula and Methods

What is MRR Recovery Calculation

MRR recovery calculation is the quantitative method used to measure monthly recurring revenue that has been successfully recaptured from subscriptions that previously failed payment processing, entered dunning flows, or were canceled. This metric isolates revenue that would have been permanently lost without intervention, tracking the financial impact of payment retry logic, account updater services, dunning campaigns, and customer win-back initiatives.

Core MRR Recovery Formula

The standard calculation subtracts baseline MRR from total recovered MRR within a defined period. The formula is:

MRR Recovered = (Successful Retries MRR + Reactivated Subscriptions MRR) - Control Group MRR

Successful Retries MRR represents revenue from subscriptions that failed initial payment but succeeded on subsequent retry attempts. In Stripe's system, this includes charges that initially returned decline codes such as insufficient_funds (decline code), card_declined (generic decline), or expired_card (decline code) but later processed successfully through invoice.payment_succeeded webhook events.

Reactivated Subscriptions MRR counts revenue from subscriptions that fully canceled (subscription.deleted event) but were subsequently reinstated through customer action or win-back campaigns.

Control Group MRR accounts for natural recovery—subscriptions that would have succeeded without intervention. Industry estimates suggest 8-12% of failed payments self-resolve when customers update payment methods independently.

Tracking Recovery by Source

Effective MRR recovery calculation segments revenue by recovery mechanism:

Automated Retry Recovery tracks MRR regained through programmatic payment retry schedules. Stripe's Smart Retries automatically attempt failed payments using machine learning to optimize retry timing. Calculate this by summing invoice amounts where invoice.payment_failed was followed by invoice.payment_succeeded without customer intervention between events.

Dunning Campaign Recovery measures MRR recovered through email notification sequences that prompt customers to update payment methods. Track this by monitoring subscriptions where customer.updated or payment_method.attached events occur within the dunning window (typically 7-14 days) and correlate with subsequent successful payments.

Account Updater Recovery isolates MRR from cards automatically refreshed by Visa Updater or Mastercard Automatic Billing Updater services. In Stripe, this appears as card.updated events followed by successful charges without customer action.

Time-Based Attribution Windows

MRR recovery calculations require defined attribution windows to prevent double-counting. Standard windows include:

• Immediate recovery: 0-48 hours post-failure (typically automated retries)
• Short-term recovery: 3-14 days (dunning campaigns)
• Long-term recovery: 15-60 days (win-back efforts)
• Extended recovery: 60+ days (reactivation campaigns)

Each window should be calculated independently to understand which interventions drive recovery at each stage.

Net Recovery Rate Calculation

The recovery rate percentage contextualizes absolute MRR recovered:

Recovery Rate = (MRR Recovered ÷ MRR at Risk) × 100

MRR at Risk includes all subscription revenue that entered a failed payment state during the measurement period. Industry benchmarks suggest recovery rates between 30-45% for B2C SaaS and 50-65% for B2B subscriptions, though these vary significantly by payment failure type.

Stripe-Specific Implementation

When calculating MRR recovery using Stripe data, query invoices where status transitioned from past_due to paid. The invoice.payment_succeeded event includes previous_attributes showing the state change. Sum the amount_paid values for these invoices within your measurement period.

For subscription-level tracking, monitor when subscription.status moves from past_due or unpaid back to active. The subscription object's current_period_start and current_period_end timestamps help attribute recovery to specific monthly cohorts.

Excluding False Positives

Accurate MRR recovery calculation requires filtering out scenarios that inflate numbers:

• Exclude subscriptions where payment method changed before first retry (customer-initiated, not recovery-driven)
• Remove subscriptions that resumed at lower pricing tiers (count only the maintained MRR portion)
• Filter out subscriptions where failure resulted from fraud prevention rules rather than legitimate payment issues
• Exclude trials converting to paid (new MRR, not recovered MRR)

The Stripe API's charge.outcome.type field distinguishes between issuer_declined (legitimate recovery opportunity) and blocked (fraud prevention), enabling proper segmentation.