Someone clicked cancel. Which month actually lost the customer?

A customer requests cancellation on January 28. Their paid term ends February 14. On February 10 they change their mind. Where does the lost customer belong in your monthly report?

For a paid-account churn measure, nowhere. There was a real cancellation request in January and a real reversal in February. Converting the January click into a lost account makes your cancellation flow look worse and your February win-back program look better than either deserves.

Keep the three clocks separate

Stripe supports an immediate cancellation and cancellation at the end of the paid period. Setting a subscription to cancel at period end sends an update event; a subscription ending sends a deletion event. A scheduled cancellation can be reversed before it takes effect. Decide which access rules your own application applies, then check them against billing state. Stripe’s cancellation guide

An account with two products can cancel one and keep paying for the other. That can reduce recurring revenue while your count of paying accounts stays unchanged. Specify whether the chart on the wall measures subscriptions, accounts or recurring revenue.

If the account has never paid, start by separating unfinished trials from first-payment outcomes. That guide uses app-store examples; map the principle to your own billing provider before applying it.

Reconcile five rows before trusting a dashboard

Take five anonymized accounts: one immediate cancellation, one scheduled cancellation, one reversal, one customer with two subscriptions, and one whose renewal payment failed. For each, reconstruct the state from the billing records and your entitlement history. Mark what happened at the end of the month. Apply your actual retry and grace-period policy to the failed payment.

A worked example: 100 accounts were paying at the start of January. Ten clicked cancel. Four reversed before their terms ended, three have access through February, and three lost their last paid subscription in January. With no other losses, that cohort’s January paid-account churn is 3/100. The ten requests still belong in a separate measure of cancellation intent. For the three with February end dates, wait to see what happens.

Deduplicate webhook deliveries by event ID. When deliveries arrive out of order, reconcile the relevant subscription state before changing access. Keep historical transitions for reporting so that a later reversal does not erase the original request. Stripe’s webhook delivery guidance

When the five cases are ready, challenge your churn definition with Marc Louvion’s AI mentor ↗. Share anonymized states and dates, including the account with two subscriptions.

Choose the interview from the right list

For feedback on the cancellation experience, talk to people who requested cancellation, including some who stayed. For feedback on why customers stopped paying, sample accounts after their last paid term ended. Keep failed payments in a separate column from voluntary departures. An expired card and a product that no longer solves the job call for different follow-up questions.

You can run this reconciliation in a spreadsheet before touching the dashboard. If five rows cannot be explained in plain language, a fancier churn chart will only hide the ambiguity.

When deciding whether to buy more customers, model acquisition payback using the renewal loss at the actual billing boundary. Counting a scheduled cancellation as an immediate loss would change both the paid-access period and the service costs you expect to incur.

If the decision is a monthly versus annual offer, compare the discount with renewal timing and service obligations. Earlier cash and higher contribution are different outcomes; the worked example holds the customer horizon fixed.