> ## 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.
# What Beacon builds from your finance systems
> The finance systems Beacon reads, the single table your chart of accounts becomes, the three questions asked of every account category, and the twelve areas of financial intelligence built on top — with an honest note on which of them run today.
Beacon reads three kinds of finance system: your **accounting ledger**, your **billing system**, and your **bank and payment accounts**. It reads all three the same way — read-only, on a schedule you set — and it writes back to none of them.
What it keeps is narrower than that sounds, and the narrowness is deliberate. Beacon does not hold a copy of your ledger. It holds your **chart of accounts**, classified once by you, and it holds **posted entries anchored to a period**. Your invoice lines, your aged debtor and creditor records and your daily bank balances stay at source and are read when a figure needs them. Everything else on this page is built from those, plus what your billing system already knows about subscriptions.
This page describes a designed model. The classification scheme and the allocation rules below are settled; the recurring-revenue figures publish today; most of the ledger-side figures are specified and not yet built. Each section says which.
## The three systems, and what each one unlocks
| System | What Beacon reads | What it unlocks |
| - | - | - |
| **Accounting** | Chart of accounts, posted ledger entries, aged debtors and creditors | Gross margin, cost to serve, fully-loaded acquisition cost, payback |
| **Billing** | Subscriptions, invoice lines, products and billing cycles | Recurring revenue and every movement in it, retention, cohort economics |
| **Banking and payments** | Balances and transactions | Cash timing accurate to the day, and the cash side of runway |
**Billing alone gets you a long way, and accounting is what turns revenue into economics.** Without an accounting connection Beacon can tell you what you earn and how it moves; it cannot tell you what it costs you to earn it. The named degraded behaviour matters here: a missing source narrows what is published, it never causes a figure to be estimated quietly. See [Connect your tools](/connect-your-tools) for what each connection unlocks and what breaks without it, and [When a source is missing](/when-a-source-is-missing) for how that is handled.
## Your chart of accounts becomes one table you classify once
Every chart of accounts is different, and none of them is organised the way a subscription business thinks. Yours is organised for your filed accounts. Beacon does not ask you to change it, and does not ship its own.
Instead it pulls your categories in as they are — the live account code, the category name, the parent path, whether the row is postable or a heading, and whether it is active, inactive or archived — and asks you to answer a small number of questions about each one. That classification is **per category, not per transaction**. It is stable across periods, it is a form rather than a project, and it does not grow as your ledger grows.
**Heading rows are excluded by construction.** A grouping row that carries no postings of its own is marked as such and is left out of every cost pool. Without that, classifying a header would double-count every child amount up the hierarchy — which is the single most likely way a cost figure comes out silently wrong.
## The three questions asked of every account category
| Question | Answers | When it is asked |
| - | - | - |
| **What kind of cost is this?** | Revenue · Cost of service · Cost of acquisition · Product development · General and administrative · Non-operating · Out of scope | Every category, always. Exactly one answer |
| **Which part of serving?** | Support · Professional services · Customer success · Infrastructure | Only when the answer above is cost of service |
| **Which part of winning?** | Marketing · Sales · Blended | Only when the answer above is cost of acquisition |
**The first question is the one that stops two teams counting the same money.** Cost of service and cost of acquisition is the line between what you spend keeping customers and what you spend winning them; marketing and sales is the line inside the second. Both are answered as a stored value on the category rather than asserted in a report, so nothing downstream can quietly disagree.
**Beacon proposes, you decide, and the difference is recorded.** Each category arrives pre-filled from your own account codes and names, and carries a state saying whether that is still just Beacon's proposal, whether you confirmed it, or whether you overrode it. A proposal never counts as an answer: no cost-to-serve figure computes until every postable, non-archived category has been confirmed or overridden by a person.
**Two further things are recorded that most tools throw away.** Your ledger's own classification for each category is kept verbatim, unmapped, so Beacon's view and your filed accounts can be shown side by side and every reclassification is visible rather than buried. And where a category has a known lag between when a cost is recognised and when it is actually paid, that lag is recorded against the category — observed from your aged creditor history and confirmed by you, never assumed to be zero.
**Where a single account genuinely mixes two kinds of cost** — a salaries account spanning support engineers and R\&D — the split is a declared, version-pinned rule, not a judgement made per transaction. The rule is recorded, so the same inputs always produce the same split.
## From a company-level pool to a single customer
Classification gives you a total per kind of cost per period. Most of the questions worth asking need that spread across customers, and the spread is a stated rule rather than an even smear.
| Serving cost | How it is spread | If the source is missing |
| - | - | - |
| **Support** | Ticket-weighted, by volume and severity | Seat-weighted from subscriptions |
| **Professional services** | Direct — these are already per customer | The layer goes inactive. It is never estimated |
| **Customer success** | Logged time per account | Modelled from territory size, account count and meetings |
| **Infrastructure** | Cloud cost-allocation tags per account | Usage-weighted |
**Every pool has to add up.** The shares across customers within one pool and one period sum to exactly 1.00. Where a pool cannot be fully spread, the remainder is carried to an explicit unallocated bucket and shown to you. It is never netted away, and it is never distributed across customers to make the arithmetic close.
**Where you run a payroll or HR system, that system is the source for people cost, not the ledger.** People cost is built there at position level with an itemised burden, which is more granular and more complete than the rollup a ledger's payroll lines carry. The ledger reconciles to it and any unexplained difference is surfaced rather than absorbed. Exactly one of the two supplies the amount for any given pool and period, so the two can never both count it.
## An open period is never quietly counted
Accounting periods reopen and figures get restated. A figure Beacon computes over a period that is still open is computed, shown, and **labelled provisional** — it is not citable as a sealed number and does not enter the permanent record. It is re-taken when the period closes, or accepted explicitly with the difference shown. Periods close on your accounting calendar, not on Beacon's. See [Period close and corrections](/period-close) and [Sealed and live figures](/sealed-and-live).
## The twelve areas built on top
| Area | What it answers |
| - | - |
| **Revenue intelligence** | What your recurring revenue is, and every movement in it |
| **Revenue forecasting** | One forecast of that revenue, assembled from sales, customer and marketing inputs |
| **Margin and contribution** | What revenue contributed after the cost of serving it |
| **Cashflow** | Dated cash in and out, and the cash position at the end of each period |
| **Runway and capital** | How long the money lasts, and when a raise has to happen |
| **Budget** | What was allocated, what moved, and whether the plan still hangs together |
| **Variance and attribution** | Where you came out against plan, and which cause explains it |
| **Scenario and sensitivity** | What changes if an assumption changes, and which assumptions matter |
| **Go-to-market efficiency** | Magic number, burn multiple, rule of 40, and payback |
| **Growth intelligence** | Whether the growth target and the plan beneath it still agree |
| **Financial authority** | The spending and planning bounds you set, and what happens at the edge of one |
| **Financial calibration** | Whether the models above are still tuned to how your business actually behaves |
Two further areas are specified and not yet designed into this layer: **cost and opex forecasting**, and **usage-based revenue** for consumption pricing.
## What runs today
**Thirteen figures publish today, all at company and period**, and all of them are revenue-side: recurring revenue, ARR, the five movements that explain the change between two months, gross and net retention, logo churn, contribution margin and the two margin indices. They are documented one article each, and the object they sit on is at [Company and period](/data-model/company-period).
**The ledger side is designed and not yet built.** The classification scheme on this page is ratified and the field-level design for the chart of accounts and for posted entries is written and approved, but neither table exists in a customer instance yet, and the accounting connection is scheduled rather than live. Nothing on this page is running against your ledger today.
**Contribution margin is the one figure that already crosses the line**, and it is worth understanding what it is not: it is Beacon's view of what your revenue contributed after attributed serving cost, not gross margin as your accountants report it and not a statutory figure. See [Contribution margin](/definitions/contribution-margin).
## What is not here yet
* **Cash, runway and burn.** Designed in detail and described at [Cash and runway](/finance/cash-and-runway), with no figures published.
* **Budget, variance, scenario and efficiency.** The same — described at [Plan, budget and variance](/finance/plan-budget-and-variance) and [Efficiency and growth](/finance/efficiency-and-growth), specified but not published.
* **A ledger-entry or account-category reference page.** These get object pages of their own once the values they carry have public names, types and per-door availability settled, in the same way the account and company-period objects did.
* **Anything Beacon writes back.** There is nothing on the roadmap of this page that changes a number in your ledger, issues an invoice, or moves money. See [Boundaries](/boundaries).
## Related
The thirteen financial figures that publish today, their types and where each one reaches.
What it costs to serve a customer, and what they contribute after that cost.
Dated money in and out, and how long the money lasts against your own floor.
One committed plan, the scenarios around it, and why you came out somewhere else.
Magic number, burn multiple, rule of 40 — and whether you are on the plan you chose.
What each connection unlocks, and what is unavailable without it.
The accounting, billing and banking systems Beacon reads, and how each is read.
How an open period is handled, and what happens when a figure is restated.
The one cost-fed figure published today, and what it deliberately is not.
The objects Beacon publishes, the doors they reach, and how availability is marked.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.