Resources

How to Measure Dunning Performance: 7 Metrics

Most subscription businesses cannot answer a simple question: of the payments that failed last month, how many did dunning actually save — and how many would have recovered anyway? Without that answer, dunning is judged on vibes and whatever total happens to be on a dashboard.

This guide defines the seven metrics that measure dunning performance properly: recovery rate, recovered revenue, save rate, time-to-recover, cost per recovery, incremental recovery over native tools, and involuntary churn rate. Each gets a formula and a warning about how it misleads. The thread through all seven is attribution — knowing what your dunning caused, versus what it merely witnessed. How Swipe Again handles that counting is on how we count.

Before the metrics: fix the cohort and the window

Every metric below is calculated on a cohort: payments that failed in a defined period. Two rules keep the cohort honest.

First, judge a cohort only after its recovery window has closed. Payments recover over days of retries and card updates. Measuring last week's failures, while many are still mid-recovery, understates every rate and makes recent performance look artificially worse than older, fully-resolved performance.

Second, count each failed payment once. A payment that fails, is retried, and finally succeeds is one failed payment and one recovery — not three failures and one recovery. Decide whether you track by payment or by subscriber, write it down, and do not switch mid-year. Most arguments about dunning numbers are really arguments about unstated definitions.

The 7 dunning metrics

1. Recovery rate

Recovery rate = payments recovered ÷ payments that failed in the cohort × 100.

This is the headline metric: of the payments that broke, what share did you collect in the end? Its weakness is blindness to value — it counts a small monthly payment and a large annual payment as equals — which is why it is never reported alone. Segment it by decline type and by new versus renewal failures at minimum; a blended rate can improve purely because the mix of failures got easier, with no change in your dunning at all.

2. Recovered revenue

Recovered revenue = the sum of the amounts of all payments recovered in the cohort.

This is the money version of the recovery rate, and the number finance will care about. Report it next to the revenue that failed in the same cohort — the total at risk — so it reads as "recovered out of what was on the table," not a floating total. It also keeps large payments visible: a strategy that recovers fewer payments but more annual-plan revenue may be the better strategy, and only this metric shows it.

3. Save rate

Save rate = subscribers retained after dunning ÷ subscribers who entered dunning × 100.

Recovery rate counts payments; save rate counts people. They differ when a subscriber has multiple failed payments, or a payment is recovered but the subscriber cancels anyway. Save rate answers the retention question — how many subscribers who hit a failure are still subscribers at the end of the window — and is the metric to watch if your goal is shrinking churn rather than maximising collections in a single month.

4. Time-to-recover

Time-to-recover = the average (or median) number of days from first failure to successful collection, across recovered payments in the cohort.

Speed matters for three reasons. Cash collected sooner is cash you can use. Subscribers in a failed-payment state longer are in limbo longer, and every extra day is another chance for them to give up and cancel voluntarily on top of the payment problem. Finally, time-to-recover exposes where recovery happens: if most recoveries land in the first few days, your later touches may be doing little; if they spread across the whole window, cutting the window short would cost real money. The median is usually the more honest summary, because a few very slow recoveries can drag an average around.

5. Cost per recovery

Cost per recovery = total dunning cost for the period ÷ payments recovered in the period.

Total cost means everything the recovery effort costs: software fees, per-message charges, and any performance fees, for the same period as the recoveries counted. This metric is where pricing shapes become visible. A flat fee produces a cost per recovery that falls as you recover more. A fee charged as a share of recovered revenue produces a cost per recovery that rises with the value of each payment saved. Neither shape is automatically wrong — but you cannot compare tools, or judge whether dunning pays for itself, until cost sits in the same table as the recoveries.

6. Incremental recovery over native tools

Incremental recovery rate = recovery rate with the added system − recovery rate from native tools alone, measured on comparable cohorts.

This is the most important metric on the list and the hardest to measure honestly. Your billing platform already retries failed payments on its own. Some recoveries credited to an added tool would have happened anyway, through native retries, a routine card update, or the subscriber simply having funds a few days later. Incremental recovery asks what the added layer caused on top of that baseline. It cannot be measured while two systems retry the same payments on overlapping schedules — the credit becomes unassignable, which is why the attribution section below insists on one coordinated schedule. Without an incremental figure, you know dunning happened. You do not know what it earned.

7. Involuntary churn rate

Involuntary churn rate = subscribers lost to unrecovered payment failure in the period ÷ subscribers at the start of the period × 100.

This is the failure metric: the subscribers dunning did not save, expressed as churn. It connects dunning to the number executives already watch. Track it alongside voluntary churn, not blended into it. If total churn rises while involuntary churn falls, your problem has moved to the product or pricing side, and more dunning effort will not fix it. If involuntary churn rises, work the metrics above in order — they usually show whether the cause is more failures, weaker recovery, or slower recovery.

Metric	Question it answers	Unit
Recovery rate	How many failed payments did we collect?	Payments
Recovered revenue	How much money came back?	Dollars
Save rate	How many subscribers stayed?	Subscribers
Time-to-recover	How long does recovery take?	Days
Cost per recovery	What does each save cost?	Dollars per recovery
Incremental recovery	What did the added system cause?	Points over baseline
Involuntary churn rate	How many subscribers did failure cost us?	Share of base

Attribution: the caution that protects every metric above

Attribution errors do not announce themselves. They produce a clean dashboard that is wrong, and decisions get made on it for quarters. Three rules keep it honest.

Run one coordinated schedule, not two competing ones. If your platform retries on its own timetable while a second tool retries and emails on another, the subscriber gets duplicate messages, the payment gets retried at clashing times, and when it succeeds, both systems claim it. Coordinated means one retry sequence, one message sequence, one record of what touched the payment and when. If a tool cannot coordinate with native retries, treat its reported numbers as unverified.

Measure one system at a time when you change something. Changing your retry schedule, email copy, and software in the same month guarantees you will never know which change moved the recovery rate. Change one variable, let a full cohort resolve, compare against the previous comparable cohort, then change the next thing. It is slower, and it is the only version that produces knowledge instead of anecdotes.

Stamp the mechanism at the moment of recovery. Record what immediately preceded each success — a smart retry, a card update, a save offer — at the time it happens. Reconstructing causes later from timestamps over-credits whichever system reports last or loudest. An honest setup also keeps a category for recoveries with no clear cause, rather than forcing every success into a flattering bucket. If you are evaluating tools against these rules, our comparison of failed payment recovery software shows how different products describe their counting — compare definitions, not just dashboards.

Putting the seven metrics to work

Assemble the metrics into one recurring report on a fixed cadence — monthly works for most businesses, once cohorts have had time to resolve. Keep the layout identical every period, and keep raw counts next to every percentage so anyone can recheck the arithmetic. A ready-made layout is in our recovery KPI template.

Read the report in a fixed order. Start with involuntary churn rate: did payment failure cost us more or fewer subscribers? Then recovery rate and recovered revenue: is the engine improving? Then time-to-recover and cost per recovery: at what speed and price? Finally, incremental recovery, reviewed whenever a tool, schedule, or sequence changes: is the added layer still earning its place?

Common measurement mistakes

• Judging a cohort before its window closes. Recent performance always looks worse mid-recovery. Compare only fully resolved cohorts.
• Double-counting recoveries across systems. If native retries and an added tool both claim the same payment, your total can exceed the payments that actually came back.
• Reporting recovery rate without recovered revenue. A rate can rise while the money falls, if the mix shifts to smaller payments.
• Including tool cost nowhere. Recovery totals quoted gross of software and performance fees overstate what dunning earned.

The bottom line

Measure dunning on a closed cohort, with seven numbers: recovery rate, recovered revenue, save rate, time-to-recover, cost per recovery, incremental recovery over native tools, and involuntary churn rate. Define each once, count each payment once, run one coordinated schedule, and change one thing at a time. That discipline is what turns dunning from an activity into a number you can defend.

Frequently asked questions

What is the most important dunning metric?

Recovery rate is the headline metric because it shows what share of failed payments you collected. Incremental recovery is the most decision-relevant, because it shows what your added system caused beyond what native retries would have recovered anyway. Report both, with recovered revenue beside them.

How is the dunning recovery rate calculated?

Divide payments recovered by payments that failed in the same cohort, then multiply by 100. Count each failed payment once, and calculate only after the cohort's recovery window has closed, so payments still mid-recovery do not understate the result.

What is the difference between recovery rate and save rate?

Recovery rate counts payments: how many failed charges were eventually collected. Save rate counts subscribers: how many people who entered dunning are still subscribers at the end of the window. They differ when a subscriber has multiple failed payments, or recovers a payment but cancels anyway.

Why does dunning attribution matter?

Because some failed payments recover on their own through native retries or a routine card update. If two systems work the same payment on overlapping schedules, both may claim the same recovery and the total becomes fiction. One coordinated schedule, and a mechanism stamped at recovery, keep the credit honest.

How often should dunning performance be reviewed?

Monthly suits most subscription businesses, because it matches the billing cycle and gives each cohort time to finish its recovery window before being judged. Review incremental recovery additionally whenever you change a tool, schedule, or sequence, comparing fully resolved cohorts before and after.