> ## 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. # Segment recurring revenue > The recurring revenue held by one segment, how it inherits your reporting currency without a second conversion, and what the opt-in on every door is for. ## What it is `segment_total_arr` is the recurring revenue held by one segment: the recurring revenue of every account in that segment, added together. It answers the question the account count cannot. A segment can hold a tenth of your accounts and a third of your revenue, and until both figures are on the page neither is readable on its own. It counts recurring revenue only — the contracted amount that repeats. One-off fees and services sit outside it, and so does anything invoiced but not recurring. ## How it is calculated Measured. The recurring revenue of each account in the segment is added up, over the membership in force at the time. Every account belongs to exactly one segment, so no revenue is counted in two segments at once. The accounts contribute the same recurring-revenue figures published elsewhere in Beacon. Nothing is re-derived here and nothing is adjusted: if an account's recurring revenue is one figure on its own record, it is that same figure inside the segment total. ## Where it comes from Billing, through the accounts in the segment. Billing is the required source: with no billing connection there is no recurring revenue on any account, so there is none to total. | 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 — see below | 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 figure 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 figure, and their yes is recorded — holding a grant is no longer enough on its own. That is a rule about where the value may travel, not about who inside your company may look at it. **The CRM and event doors carry a further consequence.** Every read of the figure through Beacon is recorded in the access log; once it sits on a CRM record or has been sent to an event destination, that tool's own permissions govern who reads it from then on and Beacon can no longer record who did. **And what accompanies it there is not settled.** This is an aggregate, assembled from many parts each converted where it was recorded, so it travels with your reporting currency and the kinds of anchor its parts were pinned under — and it carries no single anchor date and no single billing currency, because it does not have one. Through the read interface and through MCP all of that travels with the figure automatically, in the same response. A CRM property holds one value. **The table above says the door is open behind an opt-in; it does not say the rendering is finished.** That is being worked out and will be stated here when it is. ## How fresh it is Recalculated each cycle, over the membership in force at that cycle. It moves for two different reasons, and they are easy to confuse. Revenue changes — an expansion, a contraction, a churn, a new customer. And membership changes — an account moving from one segment to another moves its revenue with it, lowering one total and raising another without any customer paying a different amount. ## Currency and rounding The figure is in your single reporting currency, and it inherits that currency rather than converting into it. The account revenue behind it has already been converted where it was recorded, using the rules set out in [currency](/currency); no second conversion happens when the accounts are added up. That is what keeps a segment total and the account figures behind it in agreement. 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 A contract changing value. An expansion, a contraction or a churn inside the segment. A new customer being placed in it. An account moving segment, which changes two totals at once. An approved merge, split or rename, which re-cuts the whole set. A change in your reporting currency, which changes the currency the whole figure is stated in. ## What it is not * Not your company's recurring revenue. It is one segment's share of it. * Not a forecast. It is what is on the books now for the accounts currently in the segment, not what the segment is expected to hold. * Not invoiced or collected revenue. Recurring revenue is a run rate, not a record of what was billed in a period or what was paid. * Not [`segment_account_count`](/definitions/segment-account-count). More accounts does not mean more revenue, and the two are published together for exactly that reason. * Not an average or a per-account figure. Dividing it by the account count gives an average that no article defines and that a small number of large accounts will distort. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.