How to Calculate Churn Rate: Formulas, a Worked Example and the Involuntary Part (2026)

Churn rate is the share of customers you lose in a period: customers lost divided by customers at the start, times 100. If you began the month with 1,000 customers and 40 left, churn was 4%. The formula is easy; the work is in choosing what counts as "lost", what counts as "at the start" and, for a subscription business, how much of the loss was a decision and how much was a payment that simply broke.

Most churn guides stop at one formula. This one gives you the formulas you actually need, a worked example with every number shown, the way Stripe defines churn in its own analytics (it is not the textbook version), and a method for splitting the total into voluntary and involuntary churn using data you already have in Stripe. That split is the part that changes what you do on Monday: voluntary churn is a product and pricing problem, while involuntary churn is a billing problem you can often fix in days. If you need the definition first, start with what involuntary churn is, then come back.

What is the formula for customer churn rate?

Customer churn rate = (customers at the start of the period − customers from that starting group who are still customers at the end) ÷ customers at the start × 100. In everyday terms: take the people you had on day one, count how many of them are gone by the last day, and divide.

The detail that trips people up is the word "from that starting group." If you began October with 1,000 customers, signed 80 new ones and ended with 1,040, the net change is +40, but that is not the churn. Churn is the 40 of the original 1,000 that left, which is why 1,000 + 80 − 40 = 1,040. Two ways to get it wrong are very common:

• Using net growth. A fast-growing company can have high churn and still show rising customer counts. Churn measures leakage, not growth.
• Counting customers who joined and left inside the period. If someone signs up on 3 October and cancels on 20 October, they were not in the starting group. Some teams include them in the numerator anyway, which inflates churn. Pick a rule, write it down and use it every month.

What does a worked example look like?

Here is one month for a made-up subscription business. The numbers are illustrative, not from Revova or any customer; they are chosen so the arithmetic is easy to follow and so the voluntary and involuntary parts are visible.

Two things to take from the table. First, the 18 involuntary customers are not a statistic about unhappy people: they chose nothing. Second, the share (45%) is far larger than people expect, and the rate (1.8% a month) looks harmless until you annualize it, which we do below. If you want to compare your own split with published ranges, our involuntary churn benchmarks by industry article collects them, and how much revenue is lost to failed payments shows the dollar view.

How do you calculate revenue churn?

Revenue churn works the same way as customer churn, with monthly recurring revenue (MRR) in place of a head count. Gross revenue churn = (churned MRR + contraction MRR) ÷ MRR at the start × 100. Net revenue churn = (churned MRR + contraction MRR − expansion MRR) ÷ MRR at the start × 100. Contraction is a downgrade or discount that reduces MRR without cancelling; expansion is an upgrade, extra seats or an add-on.

Extending the example: MRR on 1 October is $50,000. The 22 voluntary churners averaged $60 a month ($1,320) and the 18 involuntary churners averaged $40 ($720), so churned MRR is $2,040. Downgrades removed another $600 (contraction), and upgrades added $1,500 (expansion).

Gross revenue churn is the honest measure of leakage; net revenue churn tells you whether growth in existing accounts is covering it. Which one matters depends on the question. For "how much do we lose to failed payments" use gross (expansion cannot recover a payment that failed). For "is the installed base growing without new sales" use net.

How does Stripe define churn rate?

Stripe Billing analytics uses a slightly different formula, and if you compare its chart with a spreadsheet number you will see a gap that is not a bug. From Stripe's documentation: the subscriber churn rate is the number of subscribers who churned in the past 30 days, divided by the active subscribers 30 days ago plus the new subscribers added in the past 30 days. Its own example: 1,000 subscribers at the start, 100 added, 100 churned, so churn is 100 ÷ 1,100 = 9.1%.

Three more rules from the same page matter for anyone dealing with failed payments:

• A subscriber churns when all their subscriptions are canceled or marked unpaid. The unpaid status counts even though the subscription still exists, which is good news for accuracy: those customers have stopped paying.
• Active subscribers include past_due. MRR is the sum of the monthly-normalised value of active and past_due subscriptions, so customers in the recovery window still count toward MRR until they are canceled or unpaid.
• Free plans and trials are excluded. Active subscribers only counts subscribers with positive MRR.

Apply Stripe's formula to our example and you get 40 ÷ 1,080 = 3.7%, against 4.0% for the textbook version. Neither is wrong. Pick one, label the chart, and do not mix them in the same report. For the meaning of the statuses behind this, see past_due vs unpaid vs canceled, and for the invoice side of a failed payment (the invoice stays open, there is no failed status) read Stripe invoice statuses explained.

How do you split voluntary from involuntary churn in Stripe?

Use the cancellation reason Stripe records on the subscription, plus the status for customers left unpaid. Each subscription object has a nullable cancellation_details field with a reason, and the API documents three values:

Then add the subscriptions your settings left unpaid instead of canceling, because Stripe keeps those alive but stops collecting. If your failed-payment setting is "mark the subscription unpaid," the payment_failed reason never appears for those customers and a count that only looks at canceled subscriptions will undercount involuntary churn badly.

The trap: your own cancellations after failed payments

A common practice is to cancel a delinquent subscription by hand, or with a script, after a few weeks of non-payment. In Stripe that is a cancellation through the API, so the reason is cancellation_requested, which reads as voluntary. The customer never asked. If you do this, tag the cancellation yourself (for example in subscription metadata) or add a comment in the cancellation details, and count those as involuntary. Otherwise your voluntary number is padded and your involuntary number is understated, and you will under-invest in recovery.

Why look at cohorts as well as a monthly rate?

A single monthly rate blends customers who signed up last week with customers who have been paying for three years, and those two groups behave very differently. In many businesses new customers churn faster, because some were never a good fit and their first renewal is the first time a card is tested against a real recurring charge. Check whether that is true for you rather than assuming it. A cohort view fixes the blending by following each month's group of new subscribers on its own.

Stripe's retention-by-cohort view assigns each subscriber to the month they first started a paid subscription and shows how many remain in each later month. Its documentation gives the arithmetic for a steady churn rate: at 10% monthly churn, a cohort keeps 90% after month one, 81% after month two, 73% after month three, 66% after month four and 59% after month five. In other words, retention is the churn rate compounded, which is the same idea as the annual formula below. If your real cohort curve drops faster in months one to three than that straight-line maths predicts, your early lifecycle (onboarding, the first renewal, the first card test) is where to look. If it drops at the first renewal specifically, compare the decline codes on those first-renewal failures with your later ones.

The same cohort view works for the involuntary slice. Plot the share of each cohort lost to failed payments by month since sign-up. A bump at month 12 or 13 on annual plans, or a steady trickle on a base with many older cards, tells you whether you need renewal-time work or a general expiring-card fix.

How do you handle annual plans and mixed monthly and annual customers?

Calculate them separately, then combine. A blended monthly rate hides the fact that annual customers can only churn at renewal. If 600 of your 1,000 customers are on annual plans, about 50 of them come up for renewal in an average month, so the annual group is a small slice of the "at risk" population each month and a big, lumpy one in the months when many renewals bunch together (often January, or the month of a big launch).

A workable approach: report monthly-plan churn as a monthly rate, report annual-plan churn as the share of renewals that did not renew (customers who reached renewal and left, divided by customers who reached renewal), and weight them if you want a single headline. The renewal rate is the more useful number for annual plans because it directly answers "of the people we could have kept this month, how many did we keep?" It also exposes the involuntary risk: an annual renewal is one large charge on a card that may have last been used a year ago, so a failed renewal is more likely and more expensive. Read how to reduce annual plan renewal failures if that describes your base.

How do you pull the numbers out of Stripe?

There are three routes, from least to most work.

1. The Billing overview and Churn page. Stripe shows subscriber churn rate and churned revenue, lets you export metrics, and exposes a Customer MRR changes log with every new subscriber, upgrade, downgrade, reactivation and churn. It does not split by reason, but the log is the best starting point for a spreadsheet.
2. The API. List canceled subscriptions, filter by the date they ended and group by cancellation_details.reason. The snippet below does this for one month and is fine for small and medium accounts.
3. Events and webhooks. Record customer.subscription.deleted and invoice.payment_failed as they happen into your own table. Stripe's events list goes back only 30 days, so if you want history you have to start storing it now.

// churn-split.mjs: count canceled subscriptions that ended in a window, by reason.
// Run with: node churn-split.mjs   (uses a restricted read-only key in STRIPE_SECRET_KEY)
import Stripe from 'stripe'

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY)
const from = Date.UTC(2026, 9, 1) / 1000    // 1 Oct 2026, 00:00 UTC
const to   = Date.UTC(2026, 10, 1) / 1000   // 1 Nov 2026, 00:00 UTC

const counts = { payment_failed: 0, cancellation_requested: 0, payment_disputed: 0, unknown: 0 }

for await (const sub of stripe.subscriptions.list({ status: 'canceled', limit: 100 })) {
  if (!sub.ended_at || sub.ended_at < from || sub.ended_at >= to) continue
  const reason = sub.cancellation_details?.reason ?? 'unknown'
  counts[reason] = (counts[reason] ?? 0) + 1
}

console.log(counts)   // involuntary = payment_failed (+ unpaid subscriptions, listed separately)

Whichever route you choose, keep a monthly table with the same columns: customers at start, new, voluntary lost, involuntary lost, customers at end, MRR at start, churned MRR, contraction, expansion. Calculating everything from that table in a spreadsheet beats trusting five different dashboards. If webhooks are part of your pipeline, read why missed webhooks quietly cost revenue before you build on them.

How do you turn monthly churn into annual churn, and what is a customer worth?

Compound it. Annual churn = 1 − (1 − monthly churn)¹². A 4% monthly rate is not 48% a year; each month's churn applies to the customers who remain, so 0.96¹² ≈ 0.613, which means about 61% of a starting group is still there after 12 months and about 39% is gone. The same maths applied to the involuntary part alone says a 1.8% monthly rate removes about 20% of a cohort in a year.

Stripe's subscriber lifetime value uses the same idea: average revenue per user divided by the subscriber churn rate. At $50 ARPU and 4% churn, lifetime value is about $1,250; if involuntary churn fell from 1.8% to 0.9%, total churn would drop to 3.1%, and the same ARPU would be worth about $1,613. That is a 29% increase in customer value from fixing payments alone, with no change to product, price or marketing. The lifetime value formula is a rough estimate, as Stripe itself notes, but the direction is not in doubt.

What is the difference between payment failure rate and involuntary churn?

The failure rate is how often a charge fails; involuntary churn is how often a failure ends the relationship. They are linked by your recovery rate. Using the example again: suppose 36 customers had a payment fail during October (a 3.6% failure rate on 1,000 customers) and 18 were recovered. The recovery rate is 50%, and the involuntary churn is the other 18, or 1.8%.

This is useful because it separates two problems. A rising failure rate points at the cards: more expired cards, a new payment method mix, a country with high decline rates. A falling recovery rate points at your process: retries, emails, the update-card experience. Treat them as separate lines on your dashboard. Our guides to soft versus hard declines and Smart Retries explain how to move the recovery side.

How do you check that your numbers are right?

Reconcile before you interpret. Four checks catch most errors:

1. The roll-forward must close. Customers at start + new + reactivated − churned must equal customers at the end. If it is off by even one, find the customer before you publish the number.
2. Compare with Stripe's chart using Stripe's formula. Recompute churn with the denominator set to starting plus new subscribers. If you still disagree with the Churn page by more than a rounding error, you are counting a different population, often trials, free plans or a second subscription per customer.
3. Check the involuntary count against payment events. Every involuntary churner should have at least one invoice.payment_failed event before the subscription ended. If a customer has none, they probably cancelled for another reason.
4. Look at five real customers. Open five of the "involuntary" customers and read the timeline: failed payment, retries, emails, end. If three of them cancelled after replying to an email, your split is wrong.

Not all involuntary churn can be recovered

Calling a loss "involuntary" does not mean it was winnable. Some failed payments end in an account closure, a stolen-card block or a hard decline that no retry will change; the customer has to supply a new payment method, and some will not even read the email. That is why published recovery ranges cover part of failed charges, not all of them, and why we split declines into soft and hard in the first place. Track your own recovery rate for a few months before setting a target, and treat the unrecoverable remainder as a floor.

What are the common mistakes when calculating churn?

• Mixing definitions. Comparing your spreadsheet (starting customers) with Stripe's chart (starting plus new) and concluding something changed.
• Ignoring annual plans. A customer on an annual plan can only churn once a year, so monthly churn on a blended base looks artificially low in most months and spikes at renewal. Measure annual and monthly plans separately, or use a cohort view. We cover the annual-renewal failure pattern in how to reduce annual plan renewal failures.
• Counting trials. A free trial that ends without converting is a conversion problem, not churn. Stripe leaves trials out of its active subscriber count.
• Counting reactivations as new customers. If a customer who failed in October returns in December, count them as a reactivation, or your churn and acquisition numbers both lie.
• Forgetting the lag. Failed-payment churn lands a retry-window after the failure. Judge a retry change over at least two windows.
• Treating a tiny base as a trend. With 120 customers, two cancellations move churn by 1.7 points. Use three-month averages.

What should you do with the numbers?

Read them as a decision tree rather than a scoreboard. These are rules of thumb, not benchmarks:

1. Involuntary share above a third of total churn. Billing deserves attention before product. Start with retries and emails: what dunning is and how to set up pre-dunning are the two setup guides we would read first.
2. Failure rate rising, recovery rate flat. Look at the payment method mix and decline codes, and consider the card-update path from our guide to the Stripe customer portal.
3. Recovery rate falling. Check retry settings, email deliverability and whether customers are reaching a working update page.
4. Voluntary churn rising. This is the product question: pricing, onboarding, competition. A cancel flow that asks why and offers a pause can help, but it is a different project from payment recovery. Our overview of how to reduce SaaS churn covers both sides.
5. A backlog of old failures. If failed payments from before you set anything up were never chased, a one-time scan is worth doing; see the historical payment recovery guide.

A monthly churn table you can copy

Build this once and fill it in on the same day each month. Every figure in this article can be derived from these columns, and keeping one row per month gives you the trend line that matters more than any single number: whether voluntary churn, involuntary churn and the recovery rate are each moving the way you expect after you change something. Write the definition you chose (starting customers or Stripe's starting-plus-new) at the top of the sheet so a colleague, or you in six months, does not quietly switch it.

Frequently asked questions