When is a customer churned: at notice, or at the end of the paid period?

At the first month with zero MRR after the last active month. A customer whose final invoice covers March churns in April, whatever the notice date. Notices are useful leading indicators; they are not churn.

Is a paused subscription churn?

Not if the gap closes within the reactivation window: MRR is held at the pre-gap level and no movement is recorded, with the hold logged as an assumption naming the customer. A gap longer than the window is churn at the gap start and reactivation on return.

Why is the default reactivation window three months?

Three months is a deliberate midpoint: long enough to absorb ordinary billing irregularity such as a delayed invoice or a late renewal, short enough that a genuinely departed customer is not carried for two quarters. Lengthening the window converts churn-and-reactivation pairs into pauses, so churn falls and retention rises by construction; a window materially longer than the billing cycle it absorbs is the tell that it was chosen to flatter.

Does a failed payment count as churn?

Only if it becomes a billing gap that outlasts the window. A payment that fails and is recovered within three months is a pause; one never recovered is churn from the first unbilled month. The standard does not distinguish voluntary from involuntary churn, because the revenue file does not record intent.

How is a customer who is silent at the data cutoff treated?

As right-censored, not as a completed gap. If every contract expired before the silence began, it is definite churn. Otherwise it is indeterminate: the configured trailing-gap policy applies, the default being churn at the gap start, a warning-severity exception names the customer, and the alternative reading is recorded so the toggle restates cleanly.

Is reactivation included in NRR?

By default, yes: a customer who returns within the window rejoins the numerator, because they were part of the base and their return is a genuine recovery. With `nrr.reactivation_inclusive` set to false, any customer with a churn event inside the window is removed from the base entirely, so a departure-and-return cannot be presented as retention.

SoF Standard Definitions v1.0

Pause, churn, and the reactivation window

A short billing gap that closes is a pause. A long one is churn and a win-back. A gap still open at the cutoff is judged separately.

Also Reactivation window · Win-back · Billing gap treatment · Right-censored churn

Rohit Agarwal Reviewed Sep 2026

The standard

A completed billing gap no longer than the reactivation window is a pause: MRR is held at the pre-gap level and no movements are recorded. A completed gap longer than the window is churn at the gap start, reactivation on return. A gap still open at the data cutoff is right-censored and governed separately.

At a glance

Formula: gap within the window → pause, MRR held · gap beyond the window → churn at the gap start, reactivation on return · gap open at the cutoff → trailing-gap policy
Unit: months
Bounded: n/a
Defaults: reactivation_window_months = 3 · trailing_gap_policy = churn_at_gap_start
Biggest lever: The window — lengthening it converts churn-and-return pairs into pauses and lifts retention by construction
Read with: MRR · Churn analytics · The register
Appears in: Churn schedule · Retention basis · Register
Switches: 2 · 0 locked — see the choices

What it measures

A customer bills, stops for two months, then bills again. Did they churn and come back, or did they never leave?

Nothing in the data answers this. The revenue file records absence, not intention. Yet the answer moves churn, retention, new business and cohort curves simultaneously — which makes it exactly the kind of choice that must be made once, explicitly, and disclosed, rather than made implicitly by whichever analyst wrote the query.

How it is computed

For each customer, the MRR series is scanned for runs of zero months that occur after the customer has been active at least once. Leading zeros — before the first activity — are not gaps; the customer had not yet arrived.

Each zero-run is then resolved by two questions: does it end? and how long is it?

Completed gap, length ≤ window → pause. MRR is held at the pre-gap level for every month of the gap. The customer never drops to zero, so no churn and no reactivation appear. An assumption is logged naming the customer, the gap start, the length, and the held amount; an informational exception records the gap.

Completed gap, length > window → churn and reactivation. The series is left at zero, which produces churn at the gap start and reactivation on return through the ordinary movement rules. An exception records both dates.

Open gap at the cutoff → right-censored. The rule above speaks to completed gaps; a customer inactive at the cutoff may be gone, or may return next month into data that does not exist yet. Two sub-cases:

Contracts all expired before the gap began → definite churn. Expiry without renewal is not ambiguous, and the standard says so rather than hedging.
Otherwise, gap shorter than the window → genuinely indeterminate. The configured trailing_gap_policy applies (default: churn at gap start, the conservative reading), a warn-severity indeterminate_churn exception is raised naming the customer, and the alternative is recorded so the toggle restates cleanly.

Worked example

Window = 3 months. Cutoff = December.

Customer	Pattern	Treatment
A	Bills Jan–Mar, silent Apr–May, bills Jun+	2-month gap ≤ 3 → pause; MRR held at March level through Apr–May; no movements
B	Bills Jan–Mar, silent Apr–Aug, bills Sep+	5-month gap > 3 → churn in Apr, reactivation in Sep
C	Bills Jan–Oct, silent Nov–Dec, contract runs to next June	Open gap, 2 months < window → indeterminate; policy applied, flagged `warn`
D	Bills Jan–Oct, silent Nov–Dec, contract ended in October	Open gap, contracts expired → definite churn in Nov

A and B differ only in the length of a silence. Their retention contributions, churn counts and cohort curves diverge entirely — from one configuration value.

The choices that change the number

reactivation_window_months (default 3). The dominant lever. Lengthening it converts churn/reactivation pairs into pauses: churn falls, retention rises, new-business-adjacent reactivation falls. Shortening it does the reverse. The default of 3 is a deliberate midpoint: long enough to absorb ordinary billing irregularity (a delayed invoice, a renewal processed late), short enough that a genuinely departed customer is not carried for two quarters.
trailing_gap_policy. churn_at_gap_start (default) treats right-censored silence as departure — conservative, and the reading a buyer will apply. hold_as_paused treats it as continuing. Every affected customer is individually listed, so the difference can be examined name by name rather than argued in the abstract.

How it is misread

Window chosen to flatter. A twelve-month reactivation window means almost nobody ever churns; retention approaches 100% by construction. The tell is a window materially longer than the billing cycle it is meant to absorb.

Pause treatment applied to right-censored gaps. The most common quiet error: holding MRR for customers who have simply gone silent at the cutoff, which props up closing ARR with customers who may already be gone. The standard separates the completed case from the censored one precisely because the evidence is different.

Reactivations counted as new. Discussed under movements; it originates here.

What it cannot tell you

No window can distinguish a paused customer from a departed one at the time. The rule is a disclosure convention, not a discovery. What it guarantees is that the same rule was applied to everyone, that every affected customer is named, and that changing the rule restates every dependent number rather than quietly changing one.

How to state it

A disclosure that travels with the number. Replace the braces; keep the parenthesis.

Churn recognized under a 3-month reactivation window; gaps open at the cutoff treated as churn (SoF Standard v1.0)

Before you quote it

Window stated, and no longer than the billing cycle it absorbs?
Right-censored customers listed by name?
Pauses logged as assumptions with the held amount?
The same window used in MRR, churn and NRR?

Switch	Default
`reactivation_window_months`	`3`
`trailing_gap_policy`	`churn_at_gap_start`	alternative `hold_as_paused`

What it measures#

How it is computed#

Worked example#

The choices that change the number#

How it is misread#

What it cannot tell you#