Why 'Canceled' Isn't 'Churned' (and How It Wrecks Your Metrics)

It's the single most common mistake in subscription analytics, and it quietly poisons the most important retention number you have. A cancellation is not churn. Treat them as the same thing and your churn rate becomes both inaccurate and early.

Here's the distinction, why it matters more than it sounds, and how to get it right.

The difference in one line

Canceled (scheduled cancellation): the customer has turned off auto-renew, but they're still paying through the end of the current period. They still have access. MRR is unchanged today.
Churned: the subscription has actually ended — the period lapsed, access was revoked, the money stopped. This is when MRR drops.

A customer who cancels on the 3rd but is paid through the 30th has not churned. They might even change their mind before the 30th. Counting them as churned on the 3rd is simply wrong.

Why this wrecks your metrics

If you record churn at the moment of cancellation instead of the moment the subscription ends, three things break:

Your churn rate is overstated. You're counting revenue as lost while it's still being collected.
Your timing is wrong. Losses show up days or weeks early, smearing your monthly cohorts and making trend analysis unreliable.
You react to phantom problems. You see a churn spike, scramble to fix "retention," and the customers in question were never actually gone — some renew or un-cancel.

Worse, the reverse error hides churn: if you only look at "active" subscriptions and never model the transition out of paying, you can miss churn entirely when access lapses silently.

The correct model: track the transition, not the flag

The reliable approach treats a subscription's state, not a single boolean:

A subscription is "paying" when it's active or pending_cancellation (scheduled to cancel but still within the paid period).
Churn fires only on the transition out of paying — when the state moves to ended / access revoked.
A reversal of a scheduled cancellation just clears the pending flag. No MRR movement, no churn, no expansion — nothing moved.

In ledger terms: a scheduled cancellation produces no delta. Only the actual end produces the negative churn delta. This is the rule that keeps churn honest.

How the platforms express it

Each merchant-of-record platform encodes this differently, which is part of why hand-rolled tracking gets it wrong:

Polar distinguishes subscription.canceled (still paying → pending, not churn) from subscription.revoked (access revoked → churn).
Lemon Squeezy can have cancelled = true while the subscription is still active until period-end; churn is when it actually expires/ends.
Paddle signals scheduled cancellations distinctly from the subscription actually ending.

If your spreadsheet just watches for the word "cancel," it will count all three platforms wrong.

A quick gut check

Ask yourself: "Is this customer still paying me right now?"

Yes → not churn, even if they've scheduled a cancellation. Flag it as pending and watch it.
No, access has ended → that's churn. Record the MRR loss now.

How Throughlines handles it

Throughlines enforces canceled ≠ churned as a core rule, identically across every platform:

It tracks each subscription's normalized state and only records churn on the transition out of paying.
A scheduled cancellation is flagged as pending and keeps contributing to MRR until access is actually revoked.
Un-canceling clears the pending flag with zero movement.
The result shows up in a clear MRR-movement waterfall, so you can see real new/expansion/contraction/churn/reactivation — not phantom churn.

Because the same logic runs across Polar, Paddle, and Lemon Squeezy, your churn number means the same thing no matter where the customer pays.

The takeaway

"Canceled" is an intention; "churned" is an outcome. Record churn only when the subscription actually ends — and treat scheduled cancellations as pending revenue that's still yours until proven otherwise. Get this one rule right and your retention metrics finally tell the truth.

See honest churn across all your platforms →

This is the correctness principle behind everything Throughlines computes. Related reading: How to track MRR on Lemon Squeezy · Consolidating MRR across MoR platforms