What is involuntary churn, and how do you measure it in Stripe?

Involuntary churn is the revenue you lose when a customer did not decide to leave. The card failed, nobody got them to fix it, and the subscription ended. You can measure it from Stripe data alone, but only if you count it the same way every time. This article shows the counting rules I use, and where they can mislead you.

What is involuntary churn?

It is a cancellation that began with a failed payment, not with a decision. The customer still wanted the product. The card expired, hit its limit or was replaced, the renewal failed, and the follow-up either never came or came too late.

Voluntary churn is the opposite: the customer chose to cancel. The two need different fixes. A failed card needs a card-update flow and well-timed retries. A customer who chose to leave needs a reason-first cancel flow and an honest offer. If you add both into one churn number, you will not know which fix to build first.

How is it different from a failed payment?

A failed payment is an event. Involuntary churn is one possible outcome of that event. Many failed payments recover: a retry succeeds, or the customer updates the card. Those recovered invoices are not churn, and they should not be counted as churn.

So there are two numbers, and they should not overlap:

• Failed payments never recovered: invoices whose first attempt failed and that ended up lost, with the subscription still alive.
• Involuntary churn: subscriptions that ended because of a failed payment.

When a subscription is cancelled after a lost invoice, I count the value once, under involuntary churn. If you count it in both places you will overstate the problem.

Can I just read it from the Stripe dashboard?

Partly. Stripe records a cancellation reason on the subscription, and payment_failed is one of the values. That is a good start, but it is not the whole picture. Some subscriptions end after an unrecovered failed invoice without carrying that reason, for example when your own settings or code cancel them.

The rule I use to catch both cases is this. A cancelled subscription counts as involuntary if it had at least one paid invoice and either of these is true:

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

The 45-day window is a judgment call. It is wide enough to catch slow retry schedules and narrow enough not to blame a payment failure for a cancellation months later. If your retry schedule is longer, widen it and write down that you did.

How do I measure it, step by step?

Here is the procedure. It works in a spreadsheet or a script, and it is what my own report tool does.

1. Pick a window. I use the last 365 days. If the account is younger, use its real age, with a floor of 30 days, so the monthly average is not inflated.
2. List cancelled subscriptions in the window. Keep only those with at least one paid invoice. A trial that never paid is a different leak and does not belong here.
3. Flag the involuntary ones with the two-part rule above.
4. Value each one by its monthly recurring value: list price times quantity, with yearly and weekly plans converted to a monthly figure.
5. Add them up and divide by the months in the window. The result is dollars per month lost to involuntary churn.
6. Do the same for voluntary cancellations, then compute the share: involuntary value divided by involuntary plus voluntary value.

That share is the number to look at first. It tells you how much of your cancelled revenue was a payment problem rather than a decision.

What does the result look like?

Here is an example, and it is not a real customer. My sample report uses a fictional company, Lumenfold Analytics, with synthetic data that I built so the right answer is known. In that data, 177 subscriptions ended through card failures and 233 were cancelled by choice, and involuntary churn is 45.0% of the cancelled monthly value. It comes to about $929 a month on an $80,330 base.

Do not read that as a benchmark. I do not use industry averages in the report, and I would not trust a number I could not tie to a real account. Your split could be far lower or higher. The point of the exercise is to get your own split.

You can open the full synthetic report at retivo.digital/sample-report to see how the four numbers are laid out.

Which mistakes make the number wrong?

These are the ones I check before I trust a result.

• List price instead of cash collected. Using list price before coupons slightly overstates accounts with heavy discounts. Say so when you report it.
• Mixed currencies. If you bill in more than one currency, either convert at a rate you state or leave the other currencies out and say how many subscriptions that excludes.
• Voided invoices. I treat a voided invoice as lost. If a customer voided it on purpose, that overstates the loss.
• Young failures. An invoice that failed last week may still be in retry. It is not lost yet, so leave it out of the recovered-or-lost split.
• Small samples. With fewer than about 30 events in a bucket, treat the figure as direction, not a result.
• Invisible saves. Stripe does not see a save made by email, in-app message or your support team. Your real number of unsaved cancellations is lower than what Stripe shows.

What do I do with the number once I have it?

Write down three figures and keep them next to each other: the dollars per month lost to involuntary churn, the share of cancelled value it represents, and the recovery rate on failed first payments. Together they say whether the problem is that cards fail a lot, that recovery is weak, or that most of your churn is a choice.

Then re-run the same calculation on a schedule, with the same rules, so a change you make shows up as a change in the number and not as a change in the method. If you adjust a rule, such as the 45-day window, record the date and recompute the older periods as well.

Is involuntary churn the first thing I should fix?

Not automatically. If the split shows involuntary churn is a small share of what you lose, a better cancel flow will earn more than a better dunning sequence. If it is a large share, fixing payment recovery is usually the cheapest work, because the customer already wanted to stay.

I would not guess. Measure the split, then decide. If you want a second pair of eyes on the method, I have written up the recovery side in how to recover failed payments on Stripe subscriptions.

When is it worth paying someone to run this?

If you have fewer than roughly 2,000 paying customers, do it yourself. There are too few events per bucket for a paid analysis to say much, and a spreadsheet is enough. I say the same to people who ask me directly.

If you have more, the work is mostly careful counting across a lot of invoices. The Revenue Leak Report does that for $490. You send a restricted read-only Stripe key, and the report arrives within 48 hours of my having the key. It shows four leaks in dollars per month: failed payments not recovered, trials that did not convert, cancellations with no save attempt, and downgrades. Involuntary churn is part of it, along with the top three fixes. Nothing in your Stripe account is changed, and the key can be revoked the moment the report is delivered.

The report is a read of your history. It does not prove that any fix will work. That proof comes later, from a holdout group, and only if you choose to run a pilot.