as_of and computed_at.
This is where you tell Beacon what you sell and how you sell it. Almost everything on it is your declaration rather than a reading — which is what makes it the object you are asked to confirm during setup.
The names, types and availability below are fixed. No read interface or MCP tool serves them yet — this page publishes the shape ahead of the doors. Two values,
is_recurring and billing_interval, are also published ahead of the field that will hold them.product. The collection name is not published yet — it lands with the API reference rather than being fixed here.
Example payload
Attributes
Why the billing cycle matters more than it looks
It is often the only thing that says which months a charge belongs to. When your billing runs through a subscription platform, each invoice line usually arrives with the period it covers attached — a start date and an end date — and Beacon uses those directly. When your billing runs out of an accounting system, that is frequently not true. QuickBooks and Xero carry no delivery dates at all. Some systems carry a single service date, which tells Beacon when a line starts but not how long it runs. Where the period is not delivered, Beacon uses the billing cycle you declare here to work out how far the charge extends, and spreads it across the months it covers rather than dropping the whole amount into the month the invoice was raised. An annual invoice recognised entirely in one month is the single most common way a recurring-revenue figure goes wrong, and it goes wrong in a way that still looks plausible on the page. Where an invoice line does carry its own period, that period wins. The declared billing cycle is the fallback and the answer for open-ended pricing — not an override of evidence you actually sent. Where the declared billing cycle and your actual invoicing disagree, Beacon shows you the disagreement rather than resolving it. If a product is declared annual and the invoices for it arrive monthly, that is surfaced for you to settle. Beacon does not silently pick one.The billing cycles that do not imply a length
Three of the eight values say how you bill without saying how long a period runs.weeklyis shorter than the month Beacon reports in.multi_yearis longer than a year, but two years and five years are both multi-year and they spread differently.customhas no length by definition.one_offdoes not recur at all, so there is no period to spread.
Availability
Nothing on this object is served on any door today, and which values will be available on the read interface, in MCP tools, on events and as CRM properties has not been settled for this object yet. It is left unstated here rather than guessed at, and it lands with the same act that publishes the collection. What is settled is the audience ceiling: every value on this object sits atoperational. The catalogue is company-wide and carries no role gating of its own — there is no money on this object and nothing here is scoped to leadership.
What your billing or accounting system changes
Whether the catalogue arrives at all. Subscription platforms publish a product catalogue you can read. Accounting systems publish an item list, which is close but not identical — it mixes things you sell with things you buy, and some of it is inventory rather than product. Where Beacon reads an item list, it is filtered and then confirmed with you rather than trusted as a catalogue. Whether the billing cycle is there to read. No accounting system publishes a billing cycle on an item. That is the reason this value is declared rather than read, and the reason you are asked to confirm it during setup rather than after a figure looks wrong.Freshness
A change to a declared value does not rewrite a sealed period. Periods that are already locked keep the values that produced them, so a figure you signed off stays reproducible. The new value applies from the next open period onward.