What Stripe's Revenue Recovery Analytics Doesn't Tell You

Why This Dashboard Deserves a Closer Look

If you bill subscriptions through Stripe, you already have a recovery dashboard. Stripe's revenue recovery overview shows how much subscription volume failed, how much came back, and your recovery rate. For many teams it's the only place they ever look at failed payments.

It's a good dashboard. It's also built to answer one question — "how is recovery going overall?" — and not the questions you actually need answered before you change anything: which failures are recoverable, what is recovering them, and how much recurring revenue is at risk right now.

This guide walks through what each metric really measures (straight from Stripe's documentation), where the blind spots are, and how to fill each one.

What Stripe's Recovery Analytics Shows

The overview lives in the Dashboard under Billing → Revenue recovery. According to Stripe's docs, it covers recurring subscription payments only, and excludes the first invoice payment following a trial. Keep that scope in mind — it matters later.

The Four KPIs

| KPI | Stripe's definition | |-----|---------------------| | Failed payments | Volume of subscription payments that failed on the first attempt | | Failure rate | Percentage of subscription payment volume that failed on the first attempt | | Recovered payments | Volume recovered through Stripe-managed retries or emails, plus other recovery methods you use | | Recovery rate | Percentage of failed subscription volume recovered by any means |

Two things stand out. First, everything is measured in payment volume (money), not in customers or subscriptions. Second, "recovered" means recovered by anything — Stripe's retries, Stripe's emails, or whatever else you run.

The Breakdowns

Below the KPIs, Stripe offers three charts and a table:

• Recovery breakdown — splits failed volume into Recovered, Not recovered, and In recovery (still being retried).
• Recovered volume by method — Retries (Stripe retries), Emails (Stripe emails), and Other (charge attempts made through the API or the Dashboard, which Stripe says can include third-party email campaigns, in-app flows, and other retry algorithms).
• Failed volume by decline reason — the top five decline codes by failed payment volume.
• Top customers in recovery — customers whose payments recently failed and are still being attempted by Stripe, with the failed amount and customer tenure.

That's a solid overview. Now for what it leaves out.

Gap 1: "Other" Is a Black Box

Stripe credits recoveries to three buckets: its own retries, its own emails, and Other. Everything that isn't Stripe-managed lands in Other — a third-party dunning tool, an in-app banner, a manual retry from your support team, a custom retry script.

If you run more than one of these, the dashboard can't tell you which one is working. You'll see Other go up or down, but not whether it was your emails, your in-app prompt, or a teammate clicking "Retry" in the Dashboard.

Stripe's docs also don't spell out how a combined recovery is attributed — for example, a customer who clicks a link in an email, updates their card, and is then charged on the next scheduled retry. Treat method attribution as directional, not exact.

How to fill it: Attribute at the source. Any tool you add should record its own touchpoints (email sent, link clicked, card updated) against the invoice ID, so you can join that to the invoice's paid event. This is also how you should judge a vendor's claims: ask exactly what they count as "their" recovery.

Gap 2: You See What Fails, Not What Recovers

The decline-reason chart shows the top five decline codes by failed volume. That answers "what's failing most?" It doesn't answer the more useful question: "which failures come back, and which never do?"

That distinction drives every decision you make about recovery:

• A large insufficient_funds bar is often fine — it's a soft decline and frequently succeeds on a later retry.
• A smaller expired_card or do_not_honor bar may be where the real losses are, because retries alone rarely fix them. The customer has to act.

Without recovery rate per decline code, you can't tell whether your retry schedule is the problem, your emails are, or neither. And the chart stops at five codes, so a long tail of smaller codes stays hidden.

How to fill it: Pull failed charges with their outcome details (via the API or Sigma), group by decline code, and check which of those invoices later reached paid. Our decline code library explains what each code means and whether a retry can succeed — for example, insufficient_funds versus do_not_honor.

Gap 3: Volume Isn't MRR at Risk

Every KPI is a payment-volume figure. That's the right unit for "how much money failed," but it's the wrong unit for "how much recurring revenue am I about to lose."

A few ways the two diverge:

• An annual plan that fails counts at its full annual amount in one month, even though it represents one-twelfth of that in MRR.
• Multiple retries of the same invoice are one failed payment in Stripe's view — good — but a customer with two failing subscriptions shows up as two amounts rather than one at-risk customer.
• The dashboard doesn't show how many subscriptions are sitting in past_due right now, which is the most direct measure of revenue that will churn if nothing happens.

How to fill it: List subscriptions with status=past_due and normalize each price to a monthly amount. That number — MRR currently at risk — is the one to compare against the cost of any recovery effort. Our guide to finding failed payments in Stripe walks through the filters, and the past_due vs unpaid vs canceled breakdown explains what each status means for your revenue.

Gap 4: This Month's Numbers Are Always Incomplete

Stripe is upfront about this: volume shows as In recovery while retries are still scheduled, and your recovery rate for the current and previous month can temporarily drop until all automatic retries have been attempted.

In practice, that means:

• The months you care most about (the recent ones) are the least reliable.
• If you change a setting — say, extend your retry window — you won't see a clean before/after for weeks.
• Comparing this month's recovery rate to a benchmark will make you look worse than you are.

How to fill it: Judge recovery on cohorts that have finished recovering. If your retry window is two weeks, compare months that ended at least two weeks ago. When you benchmark, use fully matured months only — our recovery rate benchmarks explain how different sources define the metric so you compare like with like.

Gap 5: Trial Conversions Are Invisible

The overview excludes the first invoice payment following a trial. For a trial-based SaaS, that's often the payment most likely to fail: the card was entered weeks ago, it may be a prepaid or virtual card, and the bank has never seen a charge from you before.

Those failures don't show up in your failure rate or your recovery rate at all. If your trial-to-paid conversion looks weaker than expected, some of the gap may be payment failures you've never been shown.

How to fill it: Query invoices with billing_reason = subscription_create or the first subscription_cycle after a trial, and check their payment outcome separately. Treat trial-conversion failures as their own funnel stage.

Gap 6: The Customer Table Forgets People

Top customers in recovery lists customers whose payments are still being attempted by Stripe. It's genuinely useful for spotting a high-value account that deserves a personal email.

But once Stripe's retry schedule ends, those customers drop off the table. Depending on your settings, their subscription becomes unpaid, canceled, or stays past_due — and they're no longer "in recovery." These are exactly the customers where a human touch or a save offer might still work, and they've just left the one list you were watching.

How to fill it: Keep your own list of subscriptions that ended recovery without paying, and review it weekly. If you're choosing between marking subscriptions unpaid or canceled at the end of retries, read what happens in each case first — the choice determines whether those customers can be recovered at all.

Gap 7: No Retry Diagnostics

The overview tells you retries recovered some amount. It doesn't show how many attempts it took, or where in the schedule recoveries happen.

The data exists. Each invoice has an attempt_count (attempts from the perspective of the retry schedule) and a next_payment_attempt timestamp. From those you can answer:

• Do most recoveries happen on attempt 2, or attempt 6?
• Are later attempts recovering anything, or just generating more declines?
• How many invoices are stuck with no next attempt scheduled?

Stripe's docs also note that after a non-retryable decline, retries continue to be scheduled but only execute if a new payment method is obtained. So a high attempt_count on a hard decline doesn't mean the card was charged six times — it means the invoice is waiting on the customer.

How to fill it: Pull invoices from the last 30–90 days with attempt_count > 0 and plot recoveries by attempt number. If late attempts rarely succeed, your retry window isn't the lever — customer communication is. Our retry schedule guide and recommended Stripe recovery settings cover what to change.

Gap 8: No Card or Geography View

The overview doesn't break failures down by card brand or card country. That's where a lot of fixable problems hide:

• A spike in failures from one country can point to issuer behavior or 3D Secure requirements (authentication_required).
• A single card brand failing disproportionately can point to a network-level issue.
• Prepaid or virtual cards concentrated in one segment can explain a stubbornly high failure rate.

How to fill it: Group failed charges by payment_method_details.card.brand and payment_method_details.card.country. Compare each group's share of failures to its share of total volume — the outliers are where to dig.

How to Fill the Gaps: Three Options

| Option | What it takes | Best for | |--------|---------------|----------| | Stripe Sigma | SQL in the Dashboard; a paid add-on in live mode (free in sandboxes) | Teams comfortable with SQL who want recurring custom reports | | API or CSV export | Script against invoices, charges, and subscriptions, or export and work in a spreadsheet | Developers who want full control; one-off deep dives | | Free audit | A restricted read-only key or a CSV export; about 3 minutes | Getting the answers above without writing queries |

Several vendors offer free audits with different scopes and access requirements — we compared the free Stripe churn audits side by side.

If you'd rather not write the queries, the free Rechurn audit covers most of the gaps in this article in one report: MRR at risk from past_due subscriptions, failed payment volume for the last 30 days, recoverable subscriptions, a failure-reason breakdown by decline code, retry pattern analysis, and a card brand and country breakdown — plus an estimated recovery range and a playbook for your top failure reason. It needs no account; you use a restricted read-only key (or a Stripe CSV export), the key is checked to be read-only and discarded after the report, and you can export everything to CSV.

Where the Dashboard Is Still the Right Tool

None of this means you should ignore Stripe's overview. It's the fastest way to:

• Spot a sudden jump in failure rate (a processor issue, a pricing change, a wave of expiring cards).
• Check that Stripe's retries and emails are turned on and doing something.
• Find a high-value customer who's currently failing and deserves a personal note.

Use it as a smoke alarm. Just don't use it as the diagnosis — it tells you there's a fire, not which room it's in.

Key Takeaways

1. Stripe's recovery analytics is volume-based and subscription-only — it excludes the first payment after a trial, so trial-conversion failures never appear
2. "Other" hides attribution — if you run more than one recovery method outside Stripe, the dashboard can't tell you which one works
3. You see what fails, not what recovers — the decline chart shows the top five codes by failed volume, not recovery rate per code
4. Volume isn't MRR at risk — count past_due subscriptions and normalize to monthly to see what you're about to lose
5. Recent months are always incomplete — judge recovery on cohorts that have finished their retry window
6. The customer table forgets people — once retries end, at-risk customers drop off the list
7. The raw data exists — attempt_count, decline codes, and card details are all in the API, Sigma, or a free audit