> ## 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. # Account object > The sixteen values Beacon publishes on an account, their types and methods, and which doors each one is available through. The account object carries sixteen values at one row per customer account. `as_of` accompanies every one of them on every door. The names, types and availability below are fixed. No read interface or MCP tool serves them yet — this page publishes the shape ahead of the doors. ## Example payload ```json theme={null} { "object": "account", "id": "acct_2f9c4b1e", "as_of": "2026-08-17T06:00:00Z", "lifecycle_stage": "steady_state", "segment": "enterprise_multi_year", "health_score": 72, "churn_risk": 31, "expansion_readiness": 64, "cost_to_serve": 14.2, "cost_to_serve_amount": 5960, "fit_score": 81, "customer_value": "high", "mrr_band": "25k-50k", "net_revenue_retention": 1.08, "renewal_date": "2027-03-31", "usage_trend": "rising", "active_users": 148, "last_active_date": "2026-08-16" } ``` ## Attributes | Value | Type | Method | What it holds | | ----------------------- | ------------------------------------------------------------------ | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `as_of` | Timestamp, UTC | System | The moment the values in the response were computed. Present on every response and every property. | | `lifecycle_stage` | String, one of eight ordered stages | Measured | The stage the account occupies after its sale closes. [Definition](/definitions/lifecycle-stage) | | `segment` | String, a segment label from your own set | Measured | The commercial group the account belongs to. [Definition](/definitions/segment) | | `health_score` | Number, 0–100 | Measured | How strongly the account is progressing through its lifecycle, measured against the pace typical for its segment. Higher means stronger progression. [Definition](/definitions/health-score) | | `churn_risk` | Number, 0–100 | Measured | How likely the account is to churn, where higher means greater risk. [Definition](/definitions/churn-risk) | | `expansion_readiness` | Number, 0–100 | Measured | How ready the account is to expand, where higher means greater readiness. [Definition](/definitions/expansion-readiness) | | `cost_to_serve` | Number, percentage of recurring revenue | Measured | What the account costs to serve over the trailing twelve months, as a share of its recurring revenue over the same period. Higher means more expensive to serve. [Definition](/definitions/cost-to-serve) | | `cost_to_serve_amount` | Number, reporting currency | Measured | The same cost as a currency amount over the trailing twelve months. [Definition](/definitions/cost-to-serve) | | `mrr_band` | String, a band | Measured | The recurring-revenue band the account falls in. The exact figure is not published on this object. | | `net_revenue_retention` | Number, a ratio | Measured | Recurring revenue kept from the customers held at the start of a period. [Definition](/definitions/net-revenue-retention) | | `fit_score` | Number on the read interface and MCP tools; a band on the CRM door | Modelled | How closely the account matches your ideal customer profile. The model version and the as-of accompany the score. | | `customer_value` | String, a band | Modelled | The account's value band. | | `renewal_date` | Date | Measured | The date the current contract comes up for renewal. | | `usage_trend` | String, one of `rising`, `flat`, `declining` | Measured | The direction of product usage at account grain. | | `active_users` | Integer | Measured | Active users on the account. An aggregate — no per-person row is published. | | `last_active_date` | Date | Measured | The most recent day of recorded product activity on the account. | ## Availability ✓ available by default · ⊕ available after an opt-in that states who becomes able to see the value · — not available. | Value | Read interface | MCP tools | CRM property | CRM name | Audience ceiling | | ----------------------- | -------------- | --------- | ------------ | -------------------------------------- | ----------------- | | `as_of` | ✓ | ✓ | ✓ | `beacon_as_of` | `operational` | | `lifecycle_stage` | ✓ | ✓ | ✓ | `beacon_lifecycle_stage` | `operational` | | `segment` | ✓ | ✓ | ✓ | `beacon_segment` | `operational` | | `health_score` | ✓ | ✓ | ✓ | `beacon_health_score` | `operational` | | `churn_risk` | ✓ | ✓ | ⊕ | `beacon_churn_risk` | `operational` | | `expansion_readiness` | ✓ | ✓ | ⊕ | `beacon_expansion_readiness` | `operational` | | `cost_to_serve` | ✓ | ✓ | ⊕ | `beacon_cost_to_serve` | `operational` | | `cost_to_serve_amount` | ✓ | ✓ | ⊕ | `beacon_cost_to_serve_amount` | `operational` | | `mrr_band` | ✓ | ✓ | ⊕ | `beacon_mrr_band` | `operational` | | `net_revenue_retention` | ✓ | ✓ | ⊕ | `beacon_net_revenue_retention` | `operational` | | `fit_score` | ✓ | ✓ | ⊕ | `beacon_fit_band` · `beacon_fit_as_of` | `operational` | | `customer_value` | ✓ | ✓ | ⊕ | `beacon_customer_value_band` | `leadership-only` | | `renewal_date` | ✓ | ✓ | ✓ | `beacon_renewal_date` | `operational` | | `usage_trend` | ✓ | ✓ | ✓ | `beacon_usage_trend` | `operational` | | `active_users` | ✓ | ✓ | ✓ | `beacon_active_users` | `operational` | | `last_active_date` | ✓ | ✓ | ✓ | `beacon_last_active_date` | `operational` | No value on this object is published on the events door. Beacon publishes no event catalogue. `cost_to_serve_amount` is a money value. It is stated in your single reporting currency, and every read of it is recorded in the access log. `cost_to_serve` is a ratio of two figures in that currency, so it carries no currency of its own. `fit_score` and `customer_value` are modelled composites, so they land in your CRM as bands — `beacon_fit_band` and `beacon_customer_value_band` — while the exact `fit_score` stays on the read interface and MCP tools, where the model version and the as-of travel with it. ## Freshness | Value | Recomputed | Sealed | | --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- | | `lifecycle_stage` | When a transition is confirmed at 70% confidence or above | No seal of its own | | `segment` | When the account crosses a segment boundary; the full set is reviewed quarterly | No seal of its own | | `churn_risk` · `expansion_readiness` | Daily on triggering events, and in full on the first business day of each month | Monthly, with the input weights re-fitted and sealed quarterly | | `net_revenue_retention` | Within 60 minutes of a change at source | At each monthly close; the quarterly close seals the three monthly seals together | | `fit_score` | On its recalculation cycle, with the weight profile and tier thresholds snapshotted | On the same cycle | | `health_score` | Nightly, and on a stage transition, a milestone completion or a material change in any input | No seal of its own | | `cost_to_serve` · `cost_to_serve_amount` | On the first business day of each month, and within four hours of a severity-one support escalation, a professional-services overrun of 20% or more, an infrastructure cost rise of 25% or more month over month, or a change of customer-success owner | Monthly, with the segment cost norms recalibrated and sealed quarterly | | `usage_trend` · `active_users` · `last_active_date` | On change at source | No seal of their own | A correction arriving after a seal is recorded as a named adjustment in the current period. A sealed figure is never quietly restated. ## Versioning The published object is versioned separately from Beacon's internal model. A value is never removed from a published version — it is deprecated, and the removal lands in the next version. A published name is permanent; a rename ships as a redirect.