> ## Documentation Index
> Fetch the complete documentation index at: https://docs.beaconrevenue.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Churned recurring revenue

> Recurring revenue lost from customers who went to zero — one of five closed movements, why the amount published is what they were paying before they left, and how it differs from counting customers.

## What it is

`churn_mrr` is [recurring revenue](/definitions/mrr) lost from customers whose recurring revenue went to zero in the period.

**The amount published is what they were paying before they left**, not the zero they went to. The zero is the state they are in now; the movement is the revenue that walked out.

Three kinds of churn land here, and they are kinds of one movement rather than three movements: **voluntary** — the customer cancelled; **involuntary** — a failed payment, an expired card, a billing failure that deactivated the subscription; and **silent** — a subscription still nominally active with no usage over a configured period, reclassified as churned. They are worth telling apart operationally, because involuntary churn is a billing problem rather than a relationship one, but they are one figure here.

## The five movements

Every change in recurring revenue between one period and the next is exactly one of five movements, and the set is closed:

| Movement | What moved |
| - | - |
| [New](/definitions/new-mrr) | Revenue from a customer with no prior history |
| [Expansion](/definitions/expansion-mrr) | An increase for a customer you already had |
| [Contraction](/definitions/contraction-mrr) | A decrease for a customer who stayed |
| [Churn](/definitions/churn-mrr) | A customer's revenue going to zero |
| [Reactivation](/definitions/reactivation-mrr) | Revenue returning from a customer who had previously churned |

Recurring revenue at the end of a period is recurring revenue at the start, plus new, expansion and reactivation, less contraction and churn. Because the five do not overlap and nothing falls between them, nothing is counted twice and nothing is lost.

**Each is published as the amount that moved.** Which movement it is carries the direction; the figure does not.

**Revenue that did not move is not a movement.** A customer paying the same as last period, and a customer who is inactive, are both baseline retained revenue. Neither is one of the five, and neither is published as one. In particular, a customer who churned in an earlier period and is still at zero is not churning again — they left once.

## How it is calculated

Measured. Where a subscription's recurring revenue was above zero and is now zero, the earlier figure is churn. Every such subscription in the period is added together.

## Where it comes from

Billing invoice lines. Billing is the required connection.

Silent churn additionally depends on product usage being read, since it is defined by the absence of usage rather than by a billing event. Without a usage source, a nominally-active subscription that nobody uses continues to count as retained revenue.

| Where it is available | |
| - | - |
| Read interface | Yes, with an opt-in |
| MCP | Yes, with an opt-in |
| Events | Yes, with an opt-in |
| CRM property | Yes, with an opt-in |

<Note>
  No read interface or MCP tool serves this value yet — the table above publishes the shape ahead of the doors.
</Note>

**Where the choice is made.** This value is not open by default on any door. The choice happens when a reader grant that reaches it is issued or widened, when you subscribe to events, or when you turn the CRM property on. Whoever makes it is shown who becomes able to see the value, and their yes is recorded — holding a grant is no longer enough on its own.

## How fresh it is

**How often this refreshes before a period closes is not declared, and that is stated rather than filled in.** A figure's refresh cadence is the cadence of the lock that freezes it, read at the part of Beacon that owns the figure; the movements live in Beacon's shared core, which no single part owns, so there is nothing yet to read a cadence from. It will be filled in, not quietly.

Once the period is closed the figure is fixed inside the locked record for that period. A late-recorded cancellation arriving after that is a named adjustment in the current period, not a restatement of a sealed one.

## Currency and rounding

In your single reporting currency. **It is an aggregate, so it travels with two facts rather than four** — your reporting currency, and the kinds of anchor its components were pinned under, given as a list even when the list has one entry. It carries no single anchor date and no single billing currency, and that absence is stated rather than filled.

Beacon applies no rounding of its own.

## What changes it

A customer's recurring revenue reaching zero — by cancellation, by billing failure, or by a silent-churn reclassification. A correction to an invoice line in the period. A customer returning does not reduce it; that is [reactivation](/definitions/reactivation-mrr), published separately.

## What it is not

* Not [`logo_churn`](/definitions/logo-churn). That counts customers; this weighs revenue. The two diverge whenever the customers who left were larger or smaller than your average, and reading them together is what tells you which.
* Not [`contraction_mrr`](/definitions/contraction-mrr). A customer still paying something has contracted, not churned.
* Not a churn rate. It is an amount, not a proportion. Beacon publishes no company-level churn percentage — the retention ratios are [gross](/definitions/gross-revenue-retention) and [net revenue retention](/definitions/net-revenue-retention), and the count measure is logo churn.
* Not a negative number. It is the size of what was lost.
* Not [`churn_risk`](/definitions/churn-risk). That is a forward-looking measure on one account; this is revenue that has already gone.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.