Involuntary churn: the revenue you lose to failed payments, and how to get it back

Some churn is a customer deciding to leave. The rest is a card expiring while its owner still loves your product, and it is the most fixable number in your entire retention stack: nobody has to be convinced of anything, a payment just has to succeed.

That second kind is involuntary churn, and depending on whose data you read it accounts for somewhere between a fifth and a third of all SaaS churn. If your gross churn is 3% monthly, up to a point of it may be payments failing, which means the cheapest retention project you will ever run is in your billing settings, not your product roadmap.

Voluntary vs involuntary

The distinction is who acted:

They also deserve different accounting. A cancellation is churn the day it happens. A failed payment is not churn yet: it opens a recovery window, and how you count MRR during that window decides whether your churn rate is real. More on that below.

Why cards fail

Knowing the failure reasons matters because they recover differently:

• Expired cards. The classic. Highly recoverable: card networks push updated numbers, and retries against the refreshed card just work.
• Insufficient funds. Recoverable with timing: a retry aligned to the start of the month, or after payday, succeeds where the day-of retry failed.
• Bank declines and fraud blocks. The bank said no. Retries alone often lose here; the customer has to act, which is what dunning email is for.
• Authentication required. In 3DS markets, a renewal can fail waiting for a verification only the customer can complete.

Configure the free fixes first

Before paying anyone a percentage of recovered revenue, take the recovery your billing provider gives away. On Stripe, that is three settings most accounts have never opened:

1. Smart Retries. Stripe retries failed payments on a machine-learned schedule instead of fixed intervals. Turn it on, give it a window of at least two to three weeks.
2. Automatic card updates. Stripe participates in the card networks' updater programs, so expired and reissued cards refresh without the customer typing anything. This is the single highest-yield item on this list.
3. Failed payment emails. Stripe can email the customer a hosted page where they update the card themselves. Enable it, and set the final action (cancel the subscription vs mark it unpaid) deliberately rather than by default.

Paddle, Creem and Asaas ship equivalents of most of this. The general rule holds across all of them: the platform's built-in recovery is free and captures the easy majority, and every paid tool is competing only for what is left after it.

Dunning, and how to count MRR while it runs

The retry window has a name: dunning, the process of retrying and nudging until the payment recovers or you give up.

The accounting rule matters more than it looks: a subscription in dunning stays in MRR, with the exposure reported separately as past-due MRR. Book churn on the day a card bounces and you will record churn on Tuesday and reactivation on Friday for a customer who never knew anything happened; both numbers become fiction, and they do not cancel out. Churn is booked when dunning actually gives up. The long version of that argument, plus the other MRR edge cases, lives in what is MRR.

Measure the exposure before fixing it

You cannot prioritize what you have not sized. The number to watch is past-due MRR: how much recurring revenue is currently sitting on failed payments, and on which customers, because six failing $20 cards and one failing $500 account are different emergencies.

Kometrics tracks this as a first-class number: past-due exposure per customer, with failed payments feeding the risk score beside usage collapse and renewal proximity, so the about-to-churn list is one screen:

app.kometrics.com/risk

Honesty about the boundary: Kometrics measures involuntary churn and shows you where it concentrates; it does not run recovery. There is no retry engine or card-update email in the product, deliberately. The measuring is free under $1,000 MRR.

When paid recovery earns its fee

The dedicated tools (Baremetrics Recover, Paddle Retain, Churnkey and friends) layer better dunning email, in-app banners, card-update campaigns and tuned retry timing on top of what the platform does. They typically price as a share of what they recover, which makes the decision arithmetic:

• Under roughly $10K MRR, the platform's free recovery is usually enough; your absolute losses are small and a percentage fee buys little.
• Past that, size your remaining leak first (past-due MRR that ultimately churns each month), then trial one tool against it. If it recovers more than it costs, it stays.
• If you bill through Paddle, Retain is the natural first look; on Stripe, Recover and Churnkey are the usual candidates.

FAQ

What percentage of churn is involuntary?

Published figures cluster between 20% and 40% of total churn for SMB SaaS. Your own number is knowable: count churned subscriptions whose final event was a failed payment rather than a cancellation.

How long should dunning run?

Two to four weeks is the common range. Shorter forfeits the recoveries that come from next month's paycheck or a reissued card; much longer mostly delays the inevitable and drags past-due MRR around with it.

Does a failed payment count as churn?

Not immediately. It opens the dunning window; churn is recorded if and when recovery gives up. Booking it as churn on day one overstates both churn and reactivation.

Do annual plans have involuntary churn?

Yes, concentrated at renewal: one payment a year means one chance to fail, on a card that has had twelve months to expire. The failures are rarer but each one is twelve times the MRR, so watch past-due on annuals specifically.