as_of and computed_at.
An invoice is the document. The money on it is described on its lines — this object holds the header: who it went to, when, in what currency, and what is still outstanding.
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. The collection name is not published yet — it lands with the API reference rather than being fixed here.
Example payload
Attributes
The due date is never used to decide which months a charge covers
This is the most expensive mistake available on this object, and it is worth stating before you meet it. The due date is when payment is expected. It is not when the service was delivered. Using it to place revenue in months shifts every figure by exactly your payment terms — and on a monthly invoice with thirty-day terms the result looks completely reasonable, which is what makes it dangerous. A whole year of revenue lands one month late and nothing about the numbers announces it. Beacon reads the due date for one thing: the gap between billing and cash. It never enters a revenue period.The invoice total is not a revenue figure
invoice_total includes tax. Recurring revenue is measured before tax and after discounts, so the document total and the revenue the invoice produces are different numbers and are meant to be. The revenue comes from the lines, each carrying its own amount on a stated basis — see the invoice line item object.
If you are reconciling, reconcile invoice_total to your ledger and the line amounts to your revenue. Comparing one to the other will not balance, and should not.
The status is your system’s word, not Beacon’s
Accounting and billing systems each use their own set — draft, open, posted, authorised, paid, void, and others besides, with different meanings behind the same words. Beacon publishes the status as delivered and labels which system it came from, rather than flattening several vocabularies into one and losing what each meant. If you are filtering on it, filter per source system.What your billing or accounting system changes
Whether the invoice date means anything for revenue. On a subscription platform it usually does not need to — each line carries the period it covers, and the line’s period is used. On an accounting system it frequently does: no delivery dates are published, so the invoice date is the only date a line has, and the product’s declared billing cycle supplies the length. That is a real difference in precision between sources, and Beacon states it rather than presenting both as equivalent. Whether the balance is delivered or derived. Some systems publish an outstanding balance on the invoice directly. Others publish the payments allocated against it and expect the balance to be worked out. Both routes reach the same value; the second one requires that Beacon reads your payments, which is why payments are being brought into scope rather than skipped. That work is not finished — where your system does not publish a balance directly, this value is not available yet.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. Receivables detail is read at full company scope by finance roles below leadership level, so the ceiling does not rise — the same derivation the cash object uses.
Freshness
An invoice can change after it is raised, and the two cases behave differently. A payment against it moves
amount_due and nothing else. A restatement or a credit changes the revenue, and where that touches a period already locked, the locked figures stand and the correction is carried forward and shown as a correction — rather than the sealed period being quietly rewritten underneath you.