What it is
Measured. The date this account’s subscription next comes up for renewal. It is the shortest definition in Beacon and one of the most load-bearing. Renewal forecasts, retention plays, revenue at risk and the timing of nearly every customer-facing prompt are anchored on it. Beacon does not work this date out. It reads it. The value is the one your billing system holds, normalised onto the account and republished. There is no formula, no weighting, no adjustment and no estimate. If the date is wrong here, it is wrong in billing, and billing is where it gets fixed.How it is calculated
It is not calculated. It is taken from the subscription record in your billing system, alongside the subscription’s start date, end date and billing frequency. What Beacon adds is the join: it confirms that the subscription in billing and the account in your CRM are the same company, so the date lands on the right account. Where that join cannot be made, the account’s readiness is reduced and the problem is surfaced rather than the date being attached to a guess.Where it comes from
Beacon reads billing from Stripe, Chargebee and Recurly.
There is no reduced form of this value. Billing is not one of several sources that improve it — it is the only source there is. Without a billing connection the subscription record is never created, the date does not exist, and a request for it returns a named reason. Beacon does not estimate a renewal date from a contract term, a start date, or anything else.
This is also the one connection whose absence stops more than one value. Billing is a required connection for Beacon to reach the point where it can forecast at all; every other source has a defined reduced mode, and billing does not.
How fresh it is
As fresh as the last sync from your billing system. The sync interval is set for your company rather than fixed, so read the timestamps rather than assuming one — and Beacon reduces an account’s readiness, and says so, when a source falls behind the interval you set. Every response carries two timestamps.as_of is the moment the value describes. computed_at is when Beacon last worked it out. For a date read straight from one source those sit close together, which is not true of most values.
Currency and rounding
Neither applies. It is a date.What changes it
A change in your billing system, arriving at the next sync. That is the only thing. A renewal does not overwrite it — a renewed subscription carries the next date forward, and the history of what came before is kept. Beacon’s own renewal activity, including the prompts that begin ninety days out, reads this date and never writes it.What it is not
- Not a predicted renewal date. While a deal is still open, Beacon builds a provisional shape of the contract it would become, including an expected renewal date. That is a prediction on an open deal. This is a fact about a live subscription. They exist at different points and are never the same record.
- Not the subscription end date. They are separate fields on the subscription record, and Beacon publishes this one.
- Not contract term. The term is how long the contract runs. This is when the next renewal falls.
- Not a renewal likelihood. Beacon holds a separate view of how likely a renewal is. This is only when.
- Not something Beacon can correct. If your billing system holds the wrong date, Beacon publishes the wrong date. It has no authority to adjust it and does not try.