> ## 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. # Contract term > How long a contract runs, in months, the three states it passes through from assumption to confirmed, and what happens to it at renewal. ## What it is Measured. How long this contract runs, in months. A plain number that carries more weight than it looks like it should: revenue recognition, cash flow projection, renewal timing and expected account value are all built on it. **Beacon reads this value, it does not derive one.** It comes from your CRM or your contract system, and the only thing Beacon does to it is track how confident it is in it. ## How it is calculated It is not calculated. It passes through three states, and knowing which one you are looking at matters more than the number. | State | Where the value comes from | How to read it | | ------------- | -------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- | | **Predicted** | Before there is any contract data, from the typical term for this segment adjusted for fit and deal size | An estimate. Useful for early forecasting, not for anything committed | | **Assumed** | From the contract template for this segment, market and tier, once a deal is qualified | A default. Marked as template-derived on the record, so it is never mistaken for a confirmed value | | **Confirmed** | From the contract itself, at the point the deal is marked won | The real term. Locked at that point | Each confirmed field replaces its assumption and raises Beacon's confidence in the contract as a whole. That confidence is published — you can see how much of a contract is confirmed rather than assumed, and forecasts built on a mostly-assumed contract are labelled as such. **No deal can be marked won without a contract record being created.** If that fails, the deal is put back to its previous stage and someone is told — the term does not quietly go missing. ## Where it comes from | Source | What it supplies | Required | | ------------------------------------------------------------------- | ------------------------------------------------------------------------ | -------------------------------------------------- | | Your CRM — contract or post-close deal record | The confirmed term, along with start date, billing cycle and product mix | Yes, unless a contract system is connected instead | | Your contract system — DocuSign, PandaDoc, Ironclad, Salesforce CPQ | The same, where contracts live there rather than in the CRM | Alternative to the above | | Your contract templates, by segment and tier | The assumed term before close | Yes | **These two paths are alternatives, not additions.** Beacon does not mind where contracts live; both produce the same record and the same forecasting behaviour. The template library is the part that needs work up front. Where no template matches a deal's segment, market and tier, Beacon falls back to a default, flags it as low confidence and tells your operations team there is a gap. And template defaults are not replaced by figures drawn from your own history until at least twenty contracts have completed in that segment and tier. ## How fresh it is Updated on any change to a mapped field in your CRM or contract system, on any manual update, and on a stage change — plus a daily pass. Status changes take effect immediately rather than waiting for the pass. Every response carries two timestamps. **`as_of` is the moment the value describes. `computed_at` is when Beacon last worked it out.** Read both rather than assuming a cadence. ## Currency and rounding Neither applies. It is a whole number of months, and it holds no money value. The 12, 24 and 36 month options you may see in a template are that template's defaults, not a limit on what Beacon will accept. Any term your systems record is published as recorded. ## What changes it **Before the close**, freely — each confirmation replaces an assumption. **At the close it locks.** From that point the term describes what was signed. **At renewal a new contract record is created**, ninety days ahead of the renewal date, carrying its own term. The previous one keeps its history rather than being overwritten, so a term that shortened from 24 months to 12 at renewal is visible as a change rather than a correction. A material departure from your template — a term well outside the norm for that segment — is flagged for review and the contract is held out of committed pipeline until someone confirms it was intended. ## What it is not * **Not a predicted term.** Before close, Beacon estimates the likely term from segment history. This is what the contract says. * **Not the [renewal date](/definitions/renewal-date).** The term is a duration; the renewal date is a point in time, and it comes from your billing system rather than your contract. * **Not the contract's financial forecast.** Beacon builds a monthly revenue timeline, invoice schedule, cash flow projection and recognition schedule from the contract. **None of that is published on the account** — this row carries the term and nothing else. * **Not an expected term.** Beacon separately works with a probability-weighted expected length for margin projection. That is a forecast; this is the commitment. This value is read from your systems rather than produced by Beacon, which means it is described here by where it comes from rather than by a published field contract. That is a known gap on Beacon's side and is being closed; the value itself is accurate.