What Beacon builds from your finance systems

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.

​

The three systems, and what each one unlocks

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 for what each connection unlocks and what breaks without it, and 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

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. 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 and Sealed and live figures.

​

The twelve areas built on top

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. 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.

​

What is not here yet

• Cash, runway and burn. Designed in detail and described at Cash and runway, with no figures published.
• Budget, variance, scenario and efficiency. The same — described at Plan, budget and variance and 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.

​

Related