> ## 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. # Deal likelihood — how it is calculated > Every rule behind the figures on the Deal likelihood page — which deals count as open, how they are grouped, how close windows work, how your CRM's stage percentages are read and applied, how size against the usual is found, and what is not calculated yet. ## What it is Measured. The figures on the [Deal likelihood page](/modules/deal-likelihood) are counts and sums over your open deals, worked out every morning by fixed, written rules. Nothing on the page today is Beacon's estimate: where a chance of closing is applied, it is the percentage **your CRM** sets for the deal's stage, and the page says so. The same deals and the same stage settings always give the same figures. This article is the one the page's *how it is calculated* link opens. It sets out each rule in turn. Beacon's own likelihood for each deal is a published value with its own definition — [deal likelihood score](/definitions/deal-probability) — and it is not calculated yet. ## Which deals count A deal is **open** when its current stage is on a pipeline Beacon holds and your CRM does not mark that stage as closed. Won and lost deals are not open and are left out of every figure. A deal whose current stage Beacon cannot find among your pipeline's stages is not written. It is counted by name in the morning run's log, never placed in a guessed stage. For each open deal the morning run notes which deal it is, its stage, its customer's name, the customer's **size group** (such as Enterprise, Mid-market or Small business, or *Unsegmented* when the customer has none) and the customer's fit band once [Customer fit](/modules/customer-fit) gives one. ## The groups Every open deal counts in several groups at once: | Group | Which deals it holds | | - | - | | **All** | Every open deal | | **Each size group** | The open deals whose customer is in that size group | | **Each stage** | The open deals at that stage | | **Within 30 days** | Deals your CRM expects to close in the next 30 days, counting today | | **Within 60 days** | Deals expected to close in the next 60 days — including those within 30 | | **Within 90 days** | Deals expected to close in the next 90 days — including those within 60 | | **Past close date** | Deals whose close date in your CRM has already passed | The three close windows **add up as they go**: a deal due in 20 days is in all three. A deal with no close date in your CRM is in none of them. The days to close are the whole days from the morning of the run to the close date in your CRM, counted in UTC. They turn negative once the date has passed. ## Your CRM's stage percentages Your CRM lets you set a percentage on each pipeline stage — for example *Discovery* 10%, *Evaluation* 30%, *Proposal* 60%, *Contract sent* 85%. Beacon reads each stage's percentage from your pipeline settings every day. A percentage outside 0–100% is refused, never rounded into range, and that stage is treated as having none. **These percentages are your setting, not Beacon's likelihood.** The page always words them as *your CRM says*. They give every deal at a stage the same chance, whatever its size, customer or pace — the very thing Beacon's own likelihood is built to replace. Beacon never treats them as its own likelihood. ## Likely ARR at your CRM's stage percentage For each open deal: * **ARR** is the deal's amount in your CRM, read as yearly recurring revenue, in your reporting currency. * **Likely ARR** is the deal's ARR times your CRM's percentage for its stage. A deal on a stage with no percentage has no likely ARR. For each group, **open ARR** is the sum of its deals' ARR, and **likely ARR** is the sum of its deals' likely ARR. The page also counts how many of a group's deals sit on a stage that carries a percentage, so a total that leaves some deals out says so. **Every product and every sum here is your data store's own formula or roll-up. Beacon's code never multiplies or adds them.** The morning run writes which deal is in which group; the store does the arithmetic, where it can be reproduced. The **Expected to close** figures on the page are the likely ARR of the *Within 30, 60 and 90 days* groups — your CRM's view, counted by the close date in your CRM. ## Size against the usual For each group, the morning run finds the **middle open-deal ARR** — the median of the ARR values its deals carry. With an even number of deals, it is the average of the two in the middle. Deals with no amount are left out. Each deal's **size against the usual** is its ARR divided by the middle ARR of its size group, rounded to two decimals: 1.0× is the usual size, 2.0× twice it. The median is the one value the morning run works out itself, because the data store has no median function; it is declared, versioned and reproducible like every other rule. ## Deals that close or move When a deal is won or lost, or a group no longer applies, its record is marked as no longer current and taken out of every group. **It is kept, never deleted**, so the totals count only today's open deals while yesterday's can still be reproduced. ## Not yet calculated How the following are worked out is not yet written down, or waits for data Beacon does not read yet, so the page says **Not yet calculated** rather than showing a number: * **Each deal's own likelihood** — how each of its five parts (customer fit, momentum, engagement, deal economics, buying intent) turns what Beacon reads into a score from 0 to 100 is not written down; each stage's range needs more of your deals to have closed; and contacts and activity on deals are not read from your CRM, so engagement has nothing to read. * **How sure Beacon is**, the **expected close date** and the **expected contract**, which come with the likelihood. * **Likely pipeline value** and **expected to close** on Beacon's side, the **risk tiers**, and every **alert** that needs the likelihood. * **Time against the usual**, which waits for Pipeline velocity's usual times per segment and stage. * **The deal-economics check**, which waits for margins from Finance and the cost to win a customer from Marketing. Until those exist, no likelihood is written anywhere, and Beacon does not invent one. ## Where it comes from | Source | What it supplies | Required | | - | - | - | | Your CRM (HubSpot) — deals | Each deal's stage, amount and close date | Yes — the module starts when the CRM is connected | | Your CRM (HubSpot) — pipeline settings | Each stage's label, place on the pipeline, whether it is closed, and its percentage | Yes | | Your CRM (HubSpot) — companies | The customer behind each deal and its size group | Yes | | Customer fit | Each customer's fit band | Adds to it — not given yet | | Your billing | Nothing for this module. Beacon runs no module without billing connected | Must be connected | ## How fresh it is Once a day, straight after the morning load from your CRM, which starts at 05:00 UTC. The page shows when it last ran. A deal moved in your CRM during the day shows its new stage, amount or close date after the next morning's run. Every figure carries the run it came from, the version of the rules it was worked out under, and what was read — so it can be reproduced from the same inputs. ## Currency and rounding ARR and likely ARR are stated in your single reporting currency. Your CRM's percentages are shown as whole percents. Size against the usual is a ratio with no currency, to two decimals. ## What it is not * **Not Beacon's likelihood.** Every chance on the page today is your CRM's stage percentage. The [deal likelihood score](/definitions/deal-probability) is Beacon's own, and it is not calculated yet. * **Not a forecast.** Likely ARR at your CRM's percentage is a weighting your CRM already implies. The Sales forecast is built on Beacon's likelihood, not on this. * **Not [deal health](/definitions/deal-health).** That asks whether a deal becomes a good customer if it closes; this asks whether it closes. * **Not a change to your CRM.** Beacon reads your deals and pipeline settings and writes nothing back. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.