Voluntary vs Involuntary Churn: How to Tell Them Apart

What is the difference between voluntary vs involuntary churn?

Voluntary vs involuntary churn is a question of who ended the subscription. Voluntary churn is a customer deciding to cancel, and involuntary churn is a payment failing until the subscription lapses without the customer ever choosing to leave. The first is a decision you can influence with the product and the offer. The second is a billing failure you can recover with mechanics.

That sounds tidy, and in a report it looks tidy. In a billing export it is messier. A customer who ignores three failed-payment emails is technically involuntary in most systems and voluntary in every way that matters. A customer who cancels the day after a decline may have decided long before. Most of this article is about drawing the line honestly, then working out how hard each side is to fix.

The audience here is a brand at roughly $3M–$30M revenue on Shopify Plus or another paid subscription platform, with recurring revenue large enough that a percentage point of churn is a line in the budget. If you sell a handful of subscriptions from a hobby store, you do not need a segmentation exercise, and this article is not written for you.

What this page adds

Most pages on voluntary churn vs involuntary churn stop at definitions and a list of tactics. This one adds two things: a way to classify ends that are neither clean nor obvious, and an effort-to-fix assessment that scores each type against your own systems. No vendor publishes the second, because a vendor sells the fix.

How do you tell voluntary and involuntary churn apart in your data?

You tell them apart by the origin of the final event. If a customer-initiated action ended the subscription, it is voluntary. If a system action ended it after payment attempts failed, it is involuntary. Everything depends on your billing platform recording that origin, so check first that the end reason is stored as a field and not inferred later from status names.

Three fields carry most of the work: the end timestamp, the end reason, and the payment status of the last attempt. Add the decline code or error message from that attempt if your payment processor returns one. With those four you can classify most ends in a single query.

The classification rules that hold up

Start with a simple rule set, then handle exceptions on purpose.

1. Customer clicked cancel in the portal, or asked support to cancel: voluntary.
2. Subscription ended by the system after the retry schedule ran out: involuntary.
3. Subscription ended after a failed payment, but the customer cancelled before retries finished: voluntary, with a “cancelled during dunning” tag.
4. Chargeback or dispute closed the subscription: a third bucket, reported apart.
5. Paused and never resumed: voluntary, dated to the pause, not to the day the system gives up.

Rule 3 is where most reporting goes wrong. A subscriber who cancels in the middle of a recovery sequence is often counted as recovered-and-lost or as involuntary. Counting them as voluntary keeps the involuntary rate honest, because your retry logic did not fail them. Your message, or their view of the price, did.

The passive case

Passive voluntary churn is the awkward one. The customer received the failed-payment notice, understood it, and chose not to act. Your system logs a payment failure and closes the subscription. Nothing in the billing data says otherwise.

To find these, join billing to your email or messaging data. A subscriber who never opened any notice, never clicked the card-update link and never contacted support after a failure is a different case from one who opened the link and abandoned the form. The first probably did not see the notice at all (an email deliverability problem, so a payment recovery problem). The second saw it and hesitated. Both are recoverable; neither is a clean voluntary or involuntary label.

Do not try to solve this by guessing. Add a column called end_origin with the values customer, system, dispute and unknown, and let unknown be honest. A report with a visible unknown share is more useful than one that guessed it away.

What does each type of churn look like side by side?

The two types differ on cause, timing, evidence, lever and reporting. Read the table for the working differences, then use the sections that follow for what each row means in practice.

Take from the table that the two sides have different owners. Voluntary churn belongs to whoever owns the customer experience, and involuntary churn belongs to whoever owns billing. When one team is asked to own both, the billing side usually waits.

How big is each side?

Published numbers are rough and vendor-reported. Baremetrics has reported that around 9% of monthly recurring revenue is lost to failed payments. Paddle, through its ProfitWell data, has reported that 20–40% of churn is involuntary. Treat both as orientation, not targets. The definitions behind them differ from yours, and your split depends on your billing model, card mix and country mix.

Here is a hypothetical, labelled as illustrative. A brand with 2,000 active subscribers loses 100 of them in a month. If 30 of those ends followed a failed charge and 70 followed a customer cancel, the split is 30 involuntary and 70 voluntary. Involuntary is the smaller number of subscribers, but it is the number you can most likely move without changing the product. Your own figures replace these; the method is the point. For the wider benchmark picture see average churn rate for subscription services.

How hard is each type to fix? The effort-to-fix assessment

Effort to fix depends on five factors, and you score each one for both types before deciding where to start. A five-factor assessment is more useful than an industry average, because it uses your own data and your own systems. No vendor publishes one, since the honest result is sometimes “you don’t need our product first”.

Score each factor 1 (easy), 2 (moderate) or 3 (hard), separately for voluntary and involuntary. Add up the five. The lower total is the cheaper place to start. These are structural scores from your own judgement, not measured values.

Scoring involuntary churn

Involuntary churn tends to score low on test speed and reversal cost, because a failed charge produces an outcome quickly and retry rules can be reverted. It scores higher on system access when a subscription app controls the billing schedule and hides the retry settings. Some apps expose retry rules; others use a fixed schedule you cannot edit. Find out which you have before you plan anything.

Cause clarity is often the surprise. Many brands hold decline codes in their payment processor but never bring them into the same report as the subscription status. The codes separate “card expired” (recoverable with an updater or a message) from “do not honour” (which may need the customer to call the bank) and from suspected fraud (which you should not retry at all). Read how to reduce involuntary churn for the levers, and involuntary churn for the definitions.

Scoring voluntary churn

Voluntary churn scores high on almost everything. The cause is rarely one thing, ownership is split between product, marketing and support, and a change to the offer may take several billing cycles to read. Reversal cost is the worst factor: a discount you have given cannot be taken back without a second cancellation event, and a cancel flow that adds friction can trigger disputes.

Voluntary churn is not the wrong problem for all that. It is often the larger one. It means the first work is diagnostic, and a cancel-reason survey that people actually answer is worth more than a new offer. Our subscription retention service covers that side. The article you are reading stays on classification and on the recovery half.

A worked example of the assessment

Take a hypothetical brand on a Shopify subscription app. Its involuntary scores: cause clarity 2 (decline codes exist but sit in the processor), system access 3 (the app fixes the retry schedule), ownership 1 (finance owns it), test speed 1, reversal cost 1. Total 8. Its voluntary scores: cause clarity 3, system access 1, ownership 3, test speed 3, reversal cost 3. Total 13.

The involuntary side wins on effort. The one blocking item is system access, so the first job is confirming whether the app’s retry settings can be changed or whether recovery has to run outside it. That question decides the plan, and you would never find it from a definition page.

What breaks when the two get mixed up?

Mixing them up breaks the decisions that depend on the split. A blended rate hides which lever moved, and a wrong label sends the fix to the wrong team. The failure is rarely dramatic. It shows up as a recovery project that “worked” on paper and a churn rate that did not move.

Four misclassification cases cause most of it.

Retries that run after the customer cancels

A customer cancels in the portal while a retry is still scheduled. If the platform does not cancel the pending retry, the card may be charged after cancellation. The support ticket that follows is a refund, a dispute risk and a mislabelled row: the subscription shows a payment success after a customer cancel. Check that a cancel event clears every scheduled retry. Try it with a test subscription before you rely on it.

Dunning emails that look like cancel prompts

A poorly written failed-payment notice can read like a warning that the account is closing. Some customers answer by cancelling on purpose. Those ends look involuntary in the system and are voluntary in fact. If cancels spike shortly after a notice goes out, the message is creating voluntary churn from involuntary events. Rewrite it around one action, updating the card, and read dunning management for the sequence structure.

Renewal dates that drift

Some brands let billing dates drift after a failed retry, so a customer’s next charge lands on a different day than before. That can move a subscriber from one cohort to another mid-analysis, and it makes month-over-month comparison unreliable. Anchor the analysis to the original renewal date, and keep the retry attempts attached to it.

Fraud and disputes counted as churn

A subscription closed after a chargeback is not a normal churn event. Some cases are genuine fraud, some are customers who disputed the charge rather than cancel. If both flow into the involuntary bucket, the rate looks worse than the recovery process deserves. Our fraud and chargebacks service and the piece on ecommerce chargebacks cover the dispute side. Here the rule is only to keep it out of your rates.

Who should fix which one first?

Fix involuntary churn first if your data shows a large share of subscription ends following a failed charge, if billing is owned by one team, and if you can edit retry rules. Fix voluntary churn first if most ends follow a customer click and your cancel reasons point to one recurring cause, such as delivery timing or first-box disappointment.

Neither answer is universal. The five-factor assessment is the way to decide, and it takes an afternoon.

Who involuntary-first is not for

A brand whose failed-payment rate is small should not spend a quarter on retry tuning. If failed charges are a small slice of your ends, the work will not move total churn much, however tidy the project. Likewise a brand whose subscription app cannot expose payment data at all should not start there until it has a way to read the decline codes.

Who voluntary-first is not for

A brand with no reliable cancel-reason data should not start with new offers. You would be guessing, and a discount is hard to retract. Get the reason field working, wait a couple of cycles, and start with the reason that recurs. A brand whose recurring revenue is a small part of total sales may also do better to work on acquisition or on one-off orders.

Who neither is for

Merchants below the published $3M floor, or with a one-off product and no recurring billing, do not have this problem in any measurable form. Read the general retention material instead, starting with customer retention in ecommerce.

Which churn numbers should you report?

Report three numbers monthly: voluntary rate, involuntary rate, and the unknown or dispute share. Compute all three on the same subscriber base at the start of the period, so they add up to the blended rate and nobody argues about the denominator.

A useful addition is the recovery rate: of the subscribers who hit a failed charge, what share ended up paying again? That is the direct measure of your recovery work. It sits next to the involuntary rate rather than inside it, because a rise in failures can push the involuntary rate up even when recovery improves.

To size the prize before you commit, use the failed payment calculator. It works from your own volumes, so it gives you a figure that belongs to your business and not to an industry average. The failed payment and involuntary churn benchmark sets out how the published ranges are built and where they stop being comparable.

Keep the definitions written down

Write the classification rules in one shared document and version them. When someone changes the retry schedule, the billing date or the cancel flow, the rules may need to change. A dashboard whose definition changed silently in March will show a “trend” that is really a re-labelling.

What should you do this quarter?

Run the classification, score the five factors, and pick one side. Four steps are enough.

1. Add an end_origin field and back-fill twelve months of ends using the classification rules.
2. Join the last payment status and decline code onto each involuntary end.
3. Score both types with the effort table and note the blocking factor.
4. Pick the lower total, set one owner, and write down how you will read the result.

The step teams get wrong is the second. The classification is done in a spreadsheet by one analyst, nobody joins the decline codes, and the recovery work starts from a guess about what the failures are. Ten minutes with the processor’s decline report changes the plan.

Involuntary churn is a payment recovery problem, and it is usually the cheaper half of the split to fix once you can see it. Pointerflow’s payment recovery service covers retry schedules, card updating, failed-payment messages and the reporting that separates recovered revenue from voluntary cancels, so the two are not blurred again.