Dunning Management

Say your SaaS company loses 3.2% of MRR to involuntary churn every month: customers whose subscriptions lapse because a payment failed, not because they wanted to cancel. At $500K MRR, that is $16,000 a month lost to a gap in billing and collections, not to a sales problem. Dunning management is the process that closes that gap. It recovers revenue from failed subscription payments through a structured sequence of automated retries, customer notifications, and account actions. The term dunning comes from traditional debt collection, but in a subscription business the process is rarely adversarial. It is a payment recovery workflow built to keep customers subscribed when they don't realize their payment failed. Involuntary churn, meaning cancellation caused by payment failure rather than a deliberate customer choice, is one of the most recoverable revenue losses a subscription business has. Unlike voluntary churners, most of these customers never meant to leave. A well-configured dunning process recovers a significant share of that revenue before accounts cancel.

How dunning management works in a subscription context

A dunning sequence starts when a recurring billing attempt fails. It usually runs on a set timeline (day 1, day 4, day 7, day 10 after the failure) and combines two types of action: payment retries and customer communications. Retries try to capture the payment again without the customer doing anything, which works for soft declines that often clear on their own. Communications tell the customer about the failure and give them a direct way to update their payment method. You need both. Retries alone leave money on the table when the card is permanently invalid and has to be replaced. Communications alone don't recover anything when the customer never sees the email. The timing between the two matters. If a retry succeeds before the customer opens the first email, the sequence should stop automatically; failure notices sent after the issue is resolved only cause alarm. If the retry fails and the customer updates their card through the email link, the system should retry the new method immediately instead of waiting for the next scheduled date. All of this depends on tight integration between the dunning system, the billing engine, and the payment processor, which makes dunning management a system design problem as much as a messaging one.

Smart retries, multi-channel touchpoints, cancel thresholds

Smart retry logic uses historical payment success patterns to time retries for when they are more likely to go through. Common rules include early morning retries (when daily bank processing begins), mid-week timing (Tuesday through Thursday typically outperforms Monday and Friday), and avoiding month-end, when processor queues are heavy. The gain over a fixed retry schedule is real but often smaller than vendors claim. The bigger driver of retry success is decline code segmentation. Hard declines should not be retried at all: the payment method is permanently invalid, and retrying wastes processor capacity while telling the card network the account is a problem. Multi-channel dunning also beats single-channel. Email open rates are too low for email-only dunning to work, and a significant portion of payment failure notices are never seen. In-app notifications (shown when the customer logs in, independent of email) and SMS (high open rates, read immediately) make it much more likely the customer acts. The cancel threshold, the point at which the subscription is canceled if payment hasn't been recovered, is a major configuration decision. Too short (3 days) and you cancel customers who would have fixed the payment within a week. Too long (21 days) and you have provided three weeks of service without payment to customers who aren't coming back. Most companies settle on 7 to 14 days, calibrated against their own recovery timing data.

How platforms handle it

Billing platforms usually implement dunning as a workflow configuration. You set the retry schedule (day 1, day 3, day 7 after failure), the communication triggers (email on day 1, in-app on day 3, SMS on day 5), the message content and escalation tone, and the terminal action at the end of the sequence (cancel, pause, or flag for manual review). How much you can configure depends on the platform. Some offer a fixed dunning sequence with little customization. Others let you run separate sequences by customer segment (high-value customers get a longer window and a personal outreach step), by decline code (hard declines trigger immediate notification and no retries; soft declines trigger retries with gradual escalation), and by subscription tier (enterprise customers get a manual review step instead of automatic cancellation). Platforms that advertise smart retries vary widely in what the algorithm does. Some use simple timing rules. Others use machine learning models trained on payment success patterns across their customer base. To evaluate smart retries, ask for recovery rate data: specifically, the percentage of soft-decline payments recovered through retries alone, with and without the smart retry algorithm. A description of how the algorithm works is not enough.

Questions to ask

• What is your current involuntary churn rate (MRR lost to payment failure cancellations as a percentage of total MRR), and how does it trend month over month?
• Is your dunning sequence differentiated by decline code, or does it apply the same retry schedule to hard declines and soft declines?
• Does your dunning system stop the notification sequence automatically when a payment is recovered, or do customers continue to receive failure notifications after resolving the issue?
• Which channels does your dunning communication use: email only, or also in-app notifications and SMS?
• Can you configure different dunning sequences for different customer segments, such as longer windows for high-value customers and shorter ones for low-value?
• Are you tracking recovery rate by dunning step (which email, which retry attempt, which channel) so you can see where the sequence breaks down?

Common mistakes

The most direct configuration mistake is running the same dunning sequence regardless of why the payment failed. Hard declines (stolen card, closed account) should trigger immediate customer notification with no retries. Soft declines (insufficient funds, do not honor) should trigger a retry sequence with gradual escalation. Retrying hard declines wastes attempts, annoys the card networks, and delays the notification the customer actually needs. Treating every failure the same conflates two different problems: a payment method that needs replacing and a temporary shortfall that needs a retry at the right moment. The second major mistake is not tracking recovery rate by dunning step. Without step-level data, you can't tell whether the sequence is too short, too long, on the wrong channels, or escalating too hard. Companies that measure only the aggregate recovery rate (the percentage of all failed payments recovered) can't tune the sequence, because they don't know which steps drive recovery and which ones generate unsubscribes from the notification emails. If you are weighing a platform change to fix this, the billing software ROI calculator helps size the case.

Comparing billing platforms

Billing platforms separate on mid-cycle change: an upgrade, a downgrade or a cancellation part way through a period is where proration and revenue schedules diverge. Once dunning management is settled as a requirement, read the Billing Software category guide for how the market splits, then weigh the BILL profile against the Versapay profile on that requirement rather than on the feature list. Our BILL pricing breakdown records what the vendor publishes and what is quote-based. The HighRadius against Versapay comparison sets two of them side by side on the same criteria. Before you book demos, put your own numbers through the billing ROI calculator so the business case is written down before a vendor writes it for you.

Dunning Management questions

Related terms

Billing Mediation, Proration, and Recurring Billing come up in the same workflow as dunning management, and the rest of the billing platforms cluster is indexed in the finance operations glossary.