AI spend and subscriptions
What you were billed and what you were metered, recorded as two numbers and never added into one.
This one sits outside the eleven-step request path: it governs what happens around a governed call rather than inside one.
the whole pathOn this page
The AI bill nobody in the business can explain
Ask a finance team what AI costs the business this month and the honest answer is usually a number with a shrug attached. Some of it is on the corporate card as monthly subscriptions, one per tool, several of them signed up for by whoever needed them first. Some of it is metered API usage on an account somebody in engineering owns. Some of it is inside a larger cloud bill. And some of it is a seat that a person who left in March is still paying for.
The tooling that exists mostly makes this worse rather than better, because it produces one confident total. A dashboard that adds a £120 monthly subscription to an estimated £340 of token usage shows you £460, and £460 is not a number that appears anywhere else in your business. It does not match the vendor invoice, because half of it was never invoiced. It does not match the gateway, because half of it never went through one. When somebody checks — and on a spend question somebody always checks — the tool loses its credibility over arithmetic rather than over anything it got wrong about AI.
The second failure is quieter and worse. A tool that reports zero for a source nobody has connected looks exactly like a tool reporting zero for a source with no usage. One of those means you are fine and the other means you are blind, and a dashboard that renders them identically will be read as the first one every time.
So Token Observe reports two numbers rather than one, labels every figure with where it came from and what period it covers, and treats a source it cannot see as unknown rather than as nothing. It is a less satisfying screen than a single headline total. It is one you can take into a conversation with the person who signs the invoices.
How it actually works
- 01
Register the subscription against an exact owner
Each entry names a vendor, a tool, a team and an owner email, with vendor and tool normalised to lowercase so the same service registered twice with different capitalisation does not become two entries. Reads need viewer rank, writes need operator rank, both are scoped to the user's team, and every mutation is audited. - 02
Import the invoice, as CSV or as JSON
The dashboard ships a CSV template with bounded parsing and a preview before anything is written; the same data can be posted as JSON. Each line carries an external id, vendor, tool, team, owner, kind, currency, amount, charge date and service period. Credits are negative amounts, and amounts support up to eight decimal places. - 03
Reject an import rather than half-apply it
Unknown fields, credentials in metadata, inconsistent attribution and invalid periods are all rejected. Imports are bounded to 1,000 lines and 2 MiB. If one identity in the batch reuses an existing team, source and external id with different data, the import returns a conflict and rolls back entirely — a partially applied invoice is harder to correct than a rejected one. - 04
Bind a charge to its register entry, or leave it unbound
An optional subscription id binds a subscription charge to the register entry it belongs to, and the vendor, tool, team and owner must match on both sides or the line is refused. The binding is optional because a charge that arrives before anyone registered the subscription is still evidence worth keeping. - 05
Report billed and estimated side by side
Subscription and API amounts are reported per currency with their evidence counts, and no currency conversion is performed anywhere: a euro charge is reported in euros. Actual API invoices are never added to token-price estimates. Totals are calculated over all scoped charges even though charge detail and the register are capped at 1,000 rows, and any truncation is stated explicitly rather than left for the reader to notice. - 06
Reach it from an agent, with an explicit grant
The MCP server exposes a spend report that returns the estate figures under the same team scope as the dashboard. The calling subject needs an explicit report grant and a report-team grant; being assigned to a team does not by itself confer reporting access, which is the distinction that stops an agent reading the estate simply because it belongs somewhere.
Why a bill and an estimate stay apart
A subscription invoice is a fact about money that has already moved. A token-price estimate is a calculation over observed traffic using a price table. They answer different questions, they have different error bars, and only one of them will ever appear on a bank statement.
Adding them is tempting because it produces the single figure an executive asks for. It is also how a spend tool becomes unusable: the blended number cannot be reconciled against the vendor invoice, cannot be reconciled against the gateway, and gets quietly discounted by everyone who tries. Reporting the two separately means a slightly harder screen and a number per column that somebody can actually check against a source document.
The same discipline applies across currencies. No conversion is performed, because a converted total embeds a rate and a date that the report would then have to defend, and the rate you used is never the rate finance used.
- Billed
- What an invoice line says, per currency, with its source, its charge date and the service period it covers. Retained without proration: a period that straddles a reporting window is not sliced.
- Estimated
- What metered traffic through the gateway is calculated to have cost, recorded separately and never folded into the billed figure.
- Unknown
- A source nobody has connected. Reported as unknown rather than as zero, because those two look identical on a chart and mean opposite things.
Importing the same invoice twice
Finance exports get run more than once. Somebody re-runs last month's export to check a figure, a scheduled job retries after a timeout, two people import the same file on the same afternoon. A spend ledger that treats each of those as new charges doubles the total and takes a while to be noticed.
Identity here is the combination of team, source and external id, and it is expected to be stable across exports. An identical reimport adds no spend. A reimport that reuses an identity with different data is a conflict rather than an update, because the safe reading of the same id carrying a different amount is that something upstream changed in a way a person should look at.
Corrections are made by issuing separately identified credit or adjustment lines rather than by editing history, which keeps the ledger append-only and leaves the correction visible as a correction.
POST /api/estate/charges/import
{
"source": "finance-export",
"lines": [{
"externalId": "invoice-2026-09-line-1",
"vendor": "anthropic",
"tool": "claude",
"team": "Engineering",
"ownerEmail": "owner@example.com",
"kind": "subscription",
"currency": "GBP",
"amount": 120,
"chargedAt": "2026-09-01T00:00:00Z",
"periodStart": "2026-09-01T00:00:00Z",
"periodEnd": "2026-10-01T00:00:00Z"
}]
}What the product will not work out for you
Two limits here are worth knowing before you plan a rollout around this, because both need a person rather than a setting.
The first is allocation. Splitting one invoice across several teams requires a reviewed allocation that somebody decides; the product will not infer it. The second is duplicate detection across sources: Token Observe cannot identify two differently labelled copies of the same real-world bill. If the same charge arrives once from a finance export and once from a vendor portal under different identities, it is two charges as far as the ledger is concerned.
There is also a data-protection consequence that is easy to miss. Billing and subscription records contain owner identities, and the trace erasure route erases trace evidence rather than this ledger. The invoice and register ledger, and its backups, belong in your documented retention and lifecycle scope as a separate item.
What this does not do
Stated here rather than discovered during an evaluation. Every line below closes off a reasonable assumption a reader would otherwise carry into a proof of concept.
- It does not discover subscriptions on its own. An import finds what the invoice you gave it lists, and a service nobody has invoiced or mentioned stays invisible to it.
- There are no live billing adapters yet. Nothing reconciles continuously against a real vendor record; what ships is the register, the import path and the provenance on both sides.
- It never converts currencies, so there is no single consolidated total across currencies to report to a board.
- It cannot recognise two differently labelled copies of the same real-world bill as one charge.
- It will not allocate one invoice across teams for you. That is a reviewed decision a person makes.
- Registering a subscription changes nothing at the vendor: it does not cancel anything, alter a payment plan, or enforce any control on an endpoint.
- Estate reporting is not a complete claim about the business. An invoice, a network observation or a missing trace cannot establish comprehensive coverage, and the reports say so rather than implying completeness.
If one of those limits is the thing that decides it for you, say so and you will get a straight answer about whether it is on the roadmap or out of scope.
Talk it throughWhat this leans on
Approved and unauthorised AI
Approved, prohibited, unknown — and unobserved kept separate from clean, because those two are not the same finding.
Spend controls
Hard USD ceilings, per-minute rate limits and a kill switch, all decided before the request leaves your network.
AI conversation evidence
What the AI was asked and what it returned, redacted before it is stored and bounded before it is kept.
Does it add my subscription costs to my API usage to give one total?
No, deliberately. Subscription charges and metered token estimates are reported as separate figures per currency, with their evidence counts, and actual API invoices are never added to token-price estimates. A blended total reconciles against neither the vendor invoice nor the gateway, so the first person to check it stops trusting the tool. Two numbers you can each trace to a source are more useful than one you cannot.
What happens if the same invoice is imported twice?
Nothing is added. Import identity is the combination of team, source and external id, and an identical reimport is recognised and ignored. If the same identity arrives with different data it is treated as a conflict rather than an update: the import returns an error and rolls back completely, on the reasoning that the same reference carrying a different amount is something a person should look at rather than something a job should silently overwrite. Corrections are issued as separately identified credit or adjustment lines.
Will it find AI subscriptions nobody told us about?
Not by importing invoices, which find only what those invoices list. Unregistered services can surface through the observation side of the product — the approved-AI classification uses observed activity and known browser AI destinations — but that is evidence about a destination rather than proof of a subscription, and a hostname without a verified owner cannot establish that a particular person's subscription is authorised. Treat the register as the record you build deliberately and the observations as leads to investigate.
Can an agent read the spend report over MCP?
Yes, with an explicit grant. The MCP server exposes a spend report that can include the estate figures, returned under the same team scope the dashboard applies. The calling subject needs an explicit report grant plus a report-team grant for the team in question; membership of a team does not by itself confer reporting access. Trace content is governed separately again and needs its own exact grant, so an agent that can read spend totals cannot thereby read conversations.
Prefer to ask a person? Write to us →
Bring us the agent you are least comfortable with.
Write to hello@tenhaw.com with what your agents do, which providers they call and what would have to be true for you to put something in front of them. James Rooney replies. You will get a straight answer about whether Token Observe fits, including when it does not.
no form · no qualification step · no sales desk · the other three ways in