How to measure churn in Stripe, and the six ways the obvious number is wrong

Stripe is the most honest record of churn most SaaS companies have. It knows who cancelled, who stopped paying, who downgraded, and when. It also produces a churn rate on the dashboard that is technically correct and rarely the number anyone meant to ask for. This post is about the gap between the two: what Stripe measures, what you probably need, how to compute it, and the six ways the calculation goes wrong quietly.

What Stripe measures

Stripe's Billing analytics show subscriber churn: the subscriptions that ended in a period as a share of those active when it began, over a trailing window. That is logo churn. It is useful, and it is one of three numbers. Stripe does not present revenue churn, gross versus net retention, or involuntary churn as headline figures. Those come from the data, not the dashboard.

The three numbers, and where each lives in Stripe

The third row is the one Stripe makes uniquely possible. A subscription that ended carries cancellation_details.reason: payment_failed means the charges kept failing until the subscription lapsed, cancellation_requested means somebody chose to cancel. Nobody outside your billing system can make that distinction, and it is the distinction that decides what to do, because involuntary churn is typically 20-40% of the total and the only kind that a sequence of emails reliably recovers.

The six ways the number goes wrong

1. The denominator is end-of-period

Dividing churned MRR by end-of-month MRR flatters the rate, because the end-of-month figure includes the month's new sales. The denominator is always the MRR, or the subscriber count, at the start of the period. This is the most common error and the easiest to make in a spreadsheet, where the end-of-month total is the cell you happen to have.

2. Trials are counted as churn

A subscription in trialing that ends without converting is a failed trial, not a churned customer. It never paid. Counting it inflates logo churn and, on a product with a free trial, can double it. Filter to subscriptions that had at least one paid invoice before they ended.

3. Monthly invoices are counted as renewals

On a month-to-month plan, an invoice paying is not a decision. The card was charged. Treating every monthly invoice as a renewal produces a renewal rate in the high nineties that means nothing, and buries the accounts whose real decision point is an annual term or a contract end date. Monthly plans are continuous; renewal analysis belongs to terms with an actual end.

4. Downgrades are missing from revenue churn

Logo churn cannot see a customer who dropped from $2,000 a month to $400. Revenue churn must. A downgrade is a change in subscription items or quantity; the lost MRR is the difference between the old and new monthly value, and it belongs in the numerator alongside outright cancellations. Skipping it is how a book with “3% churn” loses 15% of its revenue.

5. Churned customers still carry their MRR

When a subscription ends, the customer row does not vanish. In an export, or in any system that mirrors Stripe, a churned customer often keeps the MRR they used to pay until something explicitly zeroes it. Every read of “total MRR” or “revenue at risk” then has to exclude ended subscriptions, and the one that forgets quietly reports revenue from customers who left months ago.

6. The renewal date silently disappeared

This one is specific and worth knowing. In API version 2025-03-31, Stripe moved current_period_start and current_period_end from the subscription object onto each subscription item. Code that reads them from the subscription gets nothing back, and a missing field is not an error. Every renewal date downstream becomes a guess, with no log line to say so. We found it the hard way: 500 customers synced from a real account, zero contracts with a term. Read the period from items.data[].current_period_end.

A worked example

Say the book on 1 August has 400 active paid subscriptions worth $180,000 MRR. During August, 12 subscriptions end: 8 with cancellation_requested (worth $4,100 MRR), 4 with payment_failed ($1,300). Six more customers downgrade, for $2,600 of lost MRR. Three trials expire without converting.

• Logo churn: 12 ÷ 400 = 3.0%. Not 15 ÷ 400: the trials never paid.
• Gross revenue churn: (4,100 + 1,300 + 2,600) ÷ 180,000 = 4.4%. The downgrades are more than half the involuntary loss and would be invisible to logo churn.
• Involuntary share: 4 of 12 logos, $1,300 of $8,000 MRR. A third of the cancellations were never a decision, and that third is the part a recovery sequence can address.

From measurement to prevention

Once involuntary churn is separated out, it stops being a retention problem and becomes a billing-operations one, with a known fix: a decline-code-aware recovery sequence with a one-click pay link. The rest, the cancellations that were decisions, is where health scoring and outreach earn their keep, and it is smaller than the headline number suggested.

One caution on projecting recoveries. A backtest can tell you how many of your past failed payments never settled and what they were worth. It cannot tell you what share a sequence would have recovered, because that depends on your customers, your pay link, and your timing. A tool that quotes a recovery percentage before it has run on your book is quoting somebody else's.

Frequently asked questions

Where this comes from

The six distortions are the ones Exeechain's Stripe sync has had to correct in its own reads, each found by comparing what the sync wrote against the Stripe account it read from. The benchmark ranges in the FAQ are industry ranges, not measurements Exeechain took. To get your own numbers, the leak scan reads a Stripe account read-only and reports the failed payments that never settled, by customer, with the dollars attached.