> ## 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. # Reactivated recurring revenue > Recurring revenue from customers who had previously churned and came back — one of five closed movements, and why it is kept apart from new business. ## What it is `reactivation_mrr` is [recurring revenue](/definitions/mrr) from customers who had previously churned and have come back. It looks identical to new business in the numbers — a subscription at zero, then above zero — and it is a different commercial fact. Winning a lapsed customer back and winning someone who has never bought are different achievements, cost different amounts, and say different things about the business. Beacon separates them on history rather than on amount. ## 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. ## How it is calculated Measured. Where a subscription's recurring revenue was zero and is now above zero, **and that subscription has earlier history of recurring revenue above zero**, its full recurring revenue is reactivation. Every such subscription in the period is added together. The returning customer does not have to come back at what they were paying before. The amount published is what they are paying now, whether that is more or less than when they left. ## Where it comes from Billing invoice lines, and the history of the subscriptions behind them. Billing is the required connection, and history is what makes this figure possible at all. **This is the figure most exposed to how far your billing history can be read.** Where a returning customer is set up as a fresh subscription rather than resuming their old one, or where history does not reach back past the gap, the return is indistinguishable from a new customer and is published as new business. That understates this figure and overstates new — it does not affect the company total, which is the same either way. | 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 | No read interface or MCP tool serves this value yet — the table above publishes the shape ahead of the doors. **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, and a later correction is recorded as a named adjustment in the current period. ## 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 previously churned customer starting to pay again. A correction to an invoice line in the period. Better subscription history, which can move revenue out of new business and into this figure without any customer doing anything differently. ## What it is not * Not [`new_mrr`](/definitions/new-mrr). Same shape, different history — and the whole reason both exist is that the difference is worth seeing. * Not a reversal of [`churn_mrr`](/definitions/churn-mrr). The churn stays recorded in the period it happened; this is a separate movement in the period the customer returned, and the two do not net off. * Not part of [net revenue retention](/definitions/net-revenue-retention) or [gross revenue retention](/definitions/gross-revenue-retention). Both read the customers held at the start of the period; a customer who was at zero then is not among them. * Not a win-back rate. It is an amount of revenue, not a proportion of lapsed customers recovered. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.