> ## 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. # Cash, and how long it lasts > The dated view of money in and money out: the five sources behind it, why the near view leans on the bank balance and the far view on the forecast, runway measured to your declared floor rather than to zero, the five capital scenarios, and the confidence floors below which a runway figure is withheld. Revenue tells you what you earned. Cash tells you what you can spend, and the two are rarely the same in the same month. An invoice raised in March that pays in May is revenue in March and cash in May, and the gap between those two facts is where companies get caught. Beacon builds a **dated** view of money in and money out, and from it a runway curve. Everything on this page is designed and not built. No cash or runway figure is published today, and no bank or ledger connection currently feeds one. This page describes the model so it can be reviewed before it is built, not behaviour you can rely on now. ## What Beacon reads | Source | What it supplies | How often | | - | - | - | | **Bank and payment accounts** | The balance | Daily — the anchor for the near-term view | | **Accounting — receivables** | Per-invoice ageing: issued, due, expected, amount, status | On your accounting sync | | **Accounting — payables** | Per-vendor ageing: invoice date, due date, scheduled payment, amount | On your accounting sync | | **Payroll or HR** | The payroll calendar — dates, headcount, gross cost | On its own cadence | | **Beacon** | The revenue forecast | Each lock cycle | **The near-term view leans on the bank balance and the far view leans on the forecast**, and they meet in the middle. The daily balance anchors roughly the first quarter of the curve, where what is actually going to happen is mostly already invoiced or already scheduled. Beyond that, the forecast carries it. **None of this raw detail is stored in Beacon.** Your invoice-by-invoice receivables, your vendor-by-vendor payables and your daily balances stay in the systems that own them and are read when the curve is built. What Beacon holds is the dated position that comes out. **And there is exactly one revenue forecast in the chain.** The cash view does not build its own view of revenue — it reads the single forecast and applies timing to it. See [One forecast, not two](/one-forecast). ## The cash position curve The output is a dated line: for each period, money expected in, money expected out, and the position at the end. Getting there means answering when, not just how much. Beacon works out an **expected receipt date** per invoice rather than assuming the due date is the paid date, and it uses the recognition-to-cash lag you confirmed against each spend category rather than assuming a cost leaves your account the day it is recognised. Neither is guessed silently: the lag is observed from your own aged creditor history and then confirmed by you. **Payment dates from your accounting system are not used yet.** Accounting systems don't reliably record which payment settled which invoice, so a paid date read from them can be confidently wrong. Until Beacon can check that for the system you run, receipt timing follows the invoice — when it was issued, when it was due, and when it stopped being open — and the gap between due and paid is not modelled. The ageing of what customers still owe is not affected. Around the line sits a **confidence corridor** — not a single optimistic thread but a range that widens as the forecast gets further out and as your burn gets more volatile. ## Runway is measured to your floor, not to zero This is the single most important thing on this page. Beacon's runway number is **the number of months until cash reaches the floor you have declared**, not the number of months until the account is empty. Nobody operates to zero. You have a level below which you would already be doing something different, and that level is what runway is measured against — so the number stays decision-relevant rather than theatrical. The curve runs **24 months**, monthly, and that horizon is fixed rather than something the system will stretch to make a number look better. Alongside the months, Beacon reports a **trajectory**: whether runway is *extending*, *holding* or *contracting*. That is the second derivative of the curve, and it is often the more useful of the two — eighteen months and contracting is a different company from fourteen months and extending. ## Where you stand against your own plan Your chosen growth plan carries a runway threshold. Beacon reports where you sit against it in three states, with a **six-month buffer** by default: | State | Meaning | | - | - | | **Coherent** | Runway is above the threshold plus the buffer | | **Approaching** | Runway is inside the buffer — above the threshold, but not by much | | **Breached** | Runway is at or below the threshold | The point of *Approaching* is that it fires before anything is wrong, while there is still time to change something. ## The five capital scenarios Beacon overlays a fixed set of five, and reports the runway each one produces and the date by which a raise would have to happen. | Scenario | What it assumes | | - | - | | **No raise** | Nothing comes in | | **Bridge** | A bridge round — roughly twelve further months | | **Next round** | A standard next round — roughly twenty-four further months | | **Downshift** | You move deliberately to a more conservative plan | | **Forced transition** | The plan changes because cash forced it | **Beacon will not authorise, commit to or execute any of these.** A capital event is a human decision that Beacon records; it is never a computed outcome. Nothing here starts a raise, signs anything, or moves money — see [Boundaries](/boundaries). ## When Beacon stops publishing a runway number A runway figure is only as good as the cash curve under it, and Beacon says so rather than presenting every number with equal confidence. * **Below a composite confidence of 60**, the corridor widens substantially — the number is still shown, with the uncertainty visible. * **Below 40**, automatic publication pauses. The figure is not quietly published with a caveat nobody reads; it stops until someone looks. This is the same discipline as everywhere else in Beacon: a figure that cannot be trusted is withheld rather than dressed up. See [How confident a number is](/how-confident-a-number-is). ## Two levels of detail, and how you get the second The cash model runs in two modes, and the first one works from day one. **Reduced** builds burn from operating expenses against a revenue-only cash curve. It is real, it is useful, and it is what you get before the cost chain is complete. **Full** builds burn net of cash margin, which needs the cost-to-serve and margin work to be running first — see [Cost and margin](/finance/cost-and-margin). Beacon moves between them when the upstream work lands, and tells you which one is behind the number you are looking at rather than switching silently. ## Open periods, and locking a number A cash figure computed over an accounting period that is still open is **provisional**. It is computed and shown and marked as such, and it is not citable as a settled figure until the period closes. A runway figure is only sealed with **both** your CEO's and your CFO's confirmation — one without the other does not rebase the number. See [Period close and corrections](/period-close) and [Sealed and live figures](/sealed-and-live). ## Related The three finance systems Beacon reads, and the twelve areas built on them. The cost chain that unlocks the fuller of the two burn models. Why the cash view reads the forecast rather than building its own. The confidence measures, and the floors below which a figure is withheld. What provisional means, and what happens when a closed period is restated. Why nothing here moves money, issues an invoice, or commits you to a raise. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.