as_of and computed_at.
This is the object recurring revenue is actually built from. Not the subscription — the line. A subscription says an agreement exists; the line says what was charged, for what, and for which period. When those two disagree, the line is what happened.
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.
invoice_line_item. The collection name is not published yet — it lands with the API reference rather than being fixed here.
Example payload
Attributes
One amount, three conventions, one published basis
Every billing and accounting system reports a line amount slightly differently, and the differences are the kind that produce a wrong figure which still balances.- Some publish the amount in minor units — cents rather than euros.
- Some publish a figure that includes tax, with the tax broken out beside it.
- Some publish a figure that excludes tax already, and a sibling field on the same line that includes it — with the same name another system uses for the opposite thing.
The period is the value that varies most by source, and it is stated rather than smoothed over
How much Beacon knows about which months a line covers depends on where the line came from. Both dates delivered. Subscription platforms typically publish a start and an end on each line. The period is read directly and the amount is spread across exactly the months it covers. Two lines on one invoice covering different periods — an annual subscription and a quarterly true-up — are handled correctly, because each line carries its own window. One date delivered. Some accounting systems publish a single service date per line. That says when the period starts but not how long it runs, so the length comes from the product’s declared billing cycle. Accurate where the product is billed the way it is declared; not where the same product is sold on two different billing cycles. No date delivered. Some accounting systems publish nothing at line level at all. Every line on the invoice inherits the invoice’s own date, and the length again comes from the declared billing cycle. On this path, two lines covering genuinely different periods cannot be told apart from what the source sends — and Beacon says so rather than presenting a figure with a confidence the data does not carry. Where the period cannot be established, the figure is marked provisional. Storing the line makes the ambiguity visible and checkable. It does not make it resolvable, and the two are not the same thing.How a line becomes monthly revenue
The amount is spread across the calendar months the period covers, rather than landed whole in the month of the invoice. The parts always sum back to the line — spreading redistributes a figure, it never changes its total. A one-off charge does not spread. It is not recurring revenue, and it is not treated as a short subscription.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, derived the same way as on the invoice.
Freshness
A line can be spread across several periods, and it is sealed into each of them. That is deliberate: a locked month has to be reproducible from the lines that produced it, and a line covering twelve months contributed to twelve locks.
Retaining the lines behind a sealed period — so that re-running a locked month reproduces it rather than re-querying a source that may have been restated since — is a commitment Beacon is building to, not one it meets today. It is stated here because it is the reason the lines are kept at all, and because a reproducibility promise that is not yet met should be visible rather than assumed.