Voluntary vs involuntary churn: how to tell them apart in Stripe

Voluntary churn is a customer deciding to leave. Involuntary churn is a customer leaving because a payment failed and nobody fixed it. They need opposite fixes, so keep them as two numbers. In Stripe you can separate them with two rules, and I explain both below along with the cases where the line is blurry.

What is the difference in one sentence?

Voluntary churn begins with a decision. Involuntary churn begins with a card, a limit or a bank that said no. The customer may have wanted to stay the whole time.

The reason this matters is practical. If a quarter of your lost recurring revenue is a payment problem, a better cancel page changes nothing for that quarter. If most of it is a decision, better card retries change very little. Mixed together, the average hides both.

How do I tell them apart in Stripe?

Stripe records a cancellation reason on the subscription, and payment_failed is one value. That catches the clear cases. It misses subscriptions that ended after an unrecovered failed invoice without carrying that reason.

My rule counts a cancelled subscription as involuntary when it had at least one paid invoice and either:

1. the cancellation reason is payment_failed, or
2. its last invoice failed, was never recovered, and the cancellation came within 45 days of that invoice.

Every other cancelled paying subscription goes to voluntary. The full procedure is in what involuntary churn is and how to measure it.

Where does the line get blurry?

In a few places, and I would rather list them than pretend they do not exist:

• A customer who ignores the failed-payment email on purpose. They look involuntary in the data, but the real cause was a decision. Stripe cannot show intent.
• Disputes. I count them with voluntary cancellations.
• Voided invoices. I treat them as lost. If the customer voided the invoice by choice, that overstates the involuntary side.
• Your own settings. If your billing settings or code cancel unpaid subscriptions after a period, those cancellations may carry no payment reason.

The 45-day window is a judgment call. If your retry schedule is longer, widen it and write down that you did.

What do the fixes look like?

For involuntary churn, the work is about money and timing. Ask for a new card with a one-click link, send a card-update email before the card expires, and match retries to the cause. An expired card will never succeed on a retry. A temporary shortfall often will. I cover the steps in how to recover failed payments on Stripe subscriptions.

For voluntary churn, the work is about listening. Ask the reason before the customer leaves, then offer the lever that matches it: a pause for someone not using the product right now, a lower tier for someone who says it costs too much, a one-time credit only where your margin allows. Offers must be priced against margin so that a save is not bought at a loss. See how to build a reason-first cancel flow.

What does the split look like in a real report?

I can only show a synthetic one. In my sample report for a fictional company, Lumenfold Analytics, 233 subscriptions were cancelled by choice and 177 through card failures, and involuntary churn is 45.0% of the cancelled monthly value. The figures are made up so the right answer is known. They are not a benchmark, and I do not use benchmarks in the report. Your split could be far lower or far higher.

You can see how the split is laid out at the sample report.

Which one should I fix first?

The one that is bigger in dollars in your own data, discounted for how sure you are of the fix. Payment recovery is usually the cheaper job, because the customer already wanted to stay. But usually is not always. If your split shows involuntary churn is a small share, spend your time on the cancel flow.

The number to compute is involuntary value divided by involuntary plus voluntary value, using monthly recurring value. That share is the first thing I look at in any account.

How do I report the split to my team?

Give the dollars per month for each side, the number of subscriptions behind each, and the involuntary share of cancelled value. Add the window and the two rules: the payment_failed reason, and the failed-and-unrecovered last invoice with cancellation within 45 days. Without the rules, someone will recompute the share with a different definition and the discussion will be about the method.

Say also what the split does not show. Stripe cannot tell a customer who missed the email from one who ignored it on purpose, and it cannot see saves made by email or support. Those caveats belong next to the number, not in a footnote nobody reads.

Does the split change over time?

It can. If you improve payment recovery, the involuntary share should fall, and a rising voluntary share then is partly a sign that the fix worked. That is why I recompute with the same rules on a schedule and look at the trend of the share, not only the dollars.

What if I have only a handful of cancellations?

Then the split is noise. With fewer than about 30 events in a bucket, I treat a figure as direction, not a result. If you are a small business, count by hand, read each cancelled account, and decide case by case. A spreadsheet will give you more insight than a model at that size.

If you have roughly 2,000 or more paying customers, the counting across thousands of invoices is where care matters, and the Revenue Leak Report does it for $490. It is delivered within 48 hours of my receiving a restricted read-only Stripe key.