> ## 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. # Invoice object > The eight values Beacon publishes about each invoice — who it was raised on, when, in what currency, what it totalled and what is still owed. The invoice object carries eight values about each invoice you raised, at one row per invoice, and two timestamps that accompany every one of them on every door: `as_of` and `computed_at`. An invoice is the document. **The money on it is described on its [lines](/data-model/invoice-line-item)** — 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. On the read interface this object is `invoice`. **The collection name is not published yet** — it lands with the [API reference](/api-reference) rather than being fixed here. ## Example payload ```json theme={null} { "object": "invoice", "id": "inv_2026_0412", "as_of": "2026-08-05T06:00:00Z", "computed_at": "2026-08-05T06:11:48Z", "invoice_number": "INV-2026-0412", "account_id": "acct_3391", "issue_date": "2026-07-01", "due_date": "2026-07-31", "currency": "EUR", "invoice_total": 22140.00, "amount_due": 22140.00, "status": "posted" } ``` ## Attributes | Value | Type | Method | What it holds | | - | - | - | - | | `as_of` | Timestamp, UTC | System | The moment the value describes. Present on every response and every property. | | `computed_at` | Timestamp, UTC | System | When Beacon last read or worked the value out. Present on every response and every property. | | `invoice_number` | String | Measured | Your own reference for the invoice, as it appears on the document. **Not an identifier** — it is not guaranteed unique across systems, and Beacon does not join on it. | | `account_id` | String | Measured | The customer account the invoice was raised on. | | `issue_date` | Date | Measured | The date the invoice was issued. **On accounting sources this is the only date a line inherits** — see below. | | `due_date` | Date, or null | Measured | The date payment is due. Read for one purpose only — see below. | | `currency` | String, ISO 4217 | Measured | The currency the invoice was raised in. Present on every invoice: an amount without a currency tag is not a figure. | | `invoice_total` | Number, in the currency above | Measured | The total of the invoice **including tax**. This is the document total, not a revenue figure — see below. | | `amount_due` | Number, in the currency above | Measured | What is still outstanding. **This is the value receivables and cash forecasting are built on.** | | `status` | String | Measured | The invoice's state, **in your accounting system's own vocabulary** — see below. | ## 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](/data-model/invoice-line-item). 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](/data-model/product) 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 at `operational`.** 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 | Value | Recomputed | Sealed | | - | - | - | | All values | On each sync from your billing or accounting system | Inside the locked record of the period the invoice's revenue was recognised in | | `amount_due` | On each sync, and whenever a payment is allocated against the invoice | As at the lock, alongside the receivables position of that period | **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. ## Versioning The published object is versioned separately from Beacon's internal model. A value is never removed from a published version — it is deprecated, and the removal lands in the next version. A published name is permanent; a rename ships as a redirect. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.