> ## 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. # Recurring revenue > Your company's recurring revenue in a period, as an exact figure — what counts as recurring, why it is built from invoice lines rather than typed, and why it is exact here and banded on an account. ## What it is `mrr` is your company's recurring revenue for a period: the contracted amount that repeats, normalised to a monthly figure and added up across every active subscription. It is published as an exact figure, in your reporting currency, at one figure per period. Only revenue that repeats counts. One-off charges — onboarding, professional services, training, setup, implementation projects, milestone payments — are not recurring revenue. They are real money and they reach your cash figures; they are outside this one. **It is exact here, and banded on an account.** On the [account object](/data-model/account) the same kind of figure is published as `mrr_band`, and no exact amount is published there today. Your company total is published as it stands. ## How it is calculated Measured. ```text theme={null} For each recurring invoice line: monthly value = line total / number of months in its service period mrr = the sum of those monthly values, across every active subscription ``` A line billed annually contributes a twelfth of its total to each month it covers; a quarterly line contributes a third; a three-year term contributes a thirty-sixth. That is what keeps a monthly customer and an annual customer comparable rather than making the annual one look twelve times larger in the month they pay. A line is treated as recurring where the product is a subscription or a recurring add-on, where the billing cycle is monthly, quarterly, semi-annual or annual, where the line is explicitly flagged as recurring, or where the contract behind it bills periodically. **Recurring revenue is built, never typed.** A monthly or annual figure entered by hand in a CRM or a billing tool is not used, even where one exists. The figure is assembled from invoice lines every time. A recurring line with no service period cannot be normalised, so it is raised as a data issue rather than counted or guessed at. ## Where it comes from Billing invoice lines. Billing is the required connection: with no billing there is no recurring revenue at all, and nothing on this object is computed without it. | 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. **The records behind this figure are already read by your accountants.** It comes out of the same locked period records an external auditor holds a standing, regulated read on. That is a fact about those records rather than about this interface — the audit read is not a Beacon door, and nothing Beacon publishes widens or narrows it. ## How fresh it is **How often this refreshes before a period closes is not declared, and that is stated rather than filled in.** The rule Beacon follows is that a figure's refresh cadence is the cadence of the lock that freezes it, read at the part of Beacon that owns the figure. Recurring revenue, its movements and the retention ratios live in Beacon's shared core, which no single part owns — so there is nothing yet to read a cadence from. This says so rather than carrying a plausible number. It will be filled in, not quietly. Once the period is closed the figure is fixed inside the locked record for that period. A correction arriving after that — a backdated invoice, a retroactive amendment, a late-recorded cancellation — is recorded as a named adjustment in the current period. A sealed figure is never quietly restated. ## Currency and rounding The figure is in your single reporting currency. The revenue behind it was converted where it was recorded, under the rules set out in [currency](/currency); no second conversion happens when it is added up. **It is an aggregate, so it travels with two facts rather than four.** It is assembled from many contracts, each converted at its own point. So it carries your reporting currency and the kinds of anchor its components were pinned under — a billing event, a contract effective date, a plan rate; one, two or all three, always given as a list even when the list has one entry. It does not carry a single anchor date or a single billing currency, because it does not have one. That absence is stated rather than filled: never a blank, never a placeholder date, never a `mixed`. The list also never says which contract took which kind. Beacon applies no rounding of its own. A screen or an export may round for display; the value as published is not rounded to a whole thousand or a whole million. ## What changes it The five movements, and nothing else: [new](/definitions/new-mrr), [expansion](/definitions/expansion-mrr), [reactivation](/definitions/reactivation-mrr) raise it; [contraction](/definitions/contraction-mrr) and [churn](/definitions/churn-mrr) lower it. A correction to an invoice line changes it, through the period the line belongs to. A change in your reporting currency changes the currency the whole figure is stated in. A one-off charge does not change it at all, however large. **Refunds made in Stripe are not read today.** Recurring revenue from Stripe is stated before refunds: a refund by itself does not lower this figure, and Beacon does not estimate the refunded amount. ## What it is not * Not invoiced or collected revenue. This is a run rate over contracts in force, not a record of what was billed in the period or what was paid. * Not the revenue your accountants recognise in the period. Recognition follows accounting policy over what was delivered; this follows contracts that repeat. Beacon publishes no recognised-revenue figure today. * Not cash. One-off fees, timing of payment and collection all sit outside it. * Not [`arr`](/definitions/arr). That is this figure stated annually, and there is no separate annual calculation. * Not [`segment_total_arr`](/definitions/segment-total-arr). That is one segment's share of recurring revenue, stated annually; this is the whole company, stated monthly. * Not a forecast. It is what is on the books for the period, not what the period is expected to hold. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.