Token Observe vs spreadsheets and billing consoles
Finance owns the total. This owns the shape — a vendor, a tool, a team and an owner email on every line.
The spreadsheet is free, already written, and right for a small estate.
A spreadsheet needs no deployment, no backup owner and no security review, and it can hold a subscription that has never appeared on an invoice — a trial, a personal card, a line buried in a larger cloud bill. Token Observe cannot do that at all: an import finds what the invoice lists. If one person can name every AI service the business pays for without asking anyone, the spreadsheet is not failing.
The billing console wins on a point this never argues with. It is the vendor’s own record of what you were charged, and the only place a subscription can actually be cancelled. Token Observe imports a copy; it cannot end a seat. The ledger here is append-only too, so a wrong line is corrected by a credit rather than edited in place — right for evidence, slower for a typo.
Token Observe and spreadsheets and billing consoles, row by row
The places these two actually differ, one row at a time.
One total per vendor per month. Correct, and the only shape it comes in.
The same amounts, per currency, subscription and API apart, each line naming a vendor, a tool, a team and an owner.
Whoever remembers. A sheet is updated by the person who thinks of it, and a billing account is not a team.
A charge binds to a register entry only when vendor, tool, team and owner all match. A mismatch is refused rather than attributed to the nearest thing.
The email thread where somebody said yes, findable if you remember the search terms.
One of three authorization states, defaulting to unknown. Reads need viewer rank, writes need operator rank, and every change is audited.
A tab nobody filled in and a tool with no spend look identical.
A source nobody has connected reads as unknown rather than zero, and the estate report hard-codes its own completeness to false.
- beat 01Name the caller
- 1Authenticate
- 2Resolve the agent
Nothing is decided for an anonymous caller. The key resolves to one registered agent with a named owner, and its roles, its ceilings and any stop switch in force are read live from the store on every request rather than from a cached copy — so a suspension takes effect on the next call instead of after a redeploy.
- beat 02Start the record, then read what is being sent
- 3Open the trace
- 4Sanitise
- 5Scan
The trace is opened before anything can refuse the request, which is why a blocked call is recorded as thoroughly as one that went through. Only then is the text normalised and scanned — in that order, so the detectors see what the model will actually read rather than what a human reviewer can see.
- beat 03Decide once
- 6Govern
- 6bIntersect with the named human
- 7Enact
One function returns one verdict: allow, block, or hold it for a named person to approve. Every check lives in that one place rather than scattered along the path, which is what makes it possible to read your rules and know what they actually do.
- beat 04Send it, and only then spend the money
- 8Route
- 9Call upstream
Routing fixes which provider and model will really serve the call, so where an agent has a USD ceiling it is tested against the price you will actually pay rather than the one the caller typed. Routing is also the last step that can still refuse locally: after it, the request has left your network.
- beat 05Govern the answer, then count the cost
- 10Govern the response
- 11Meter and record
A tool call the model proposes is judged before it reaches your agent. Metering runs last and on every ending, including the refusals and the streams a client abandoned halfway — because the tokens were spent either way and a partial trace is still evidence.
Step names and their grouping are the product’s own, and the order is encoded in the evaluator rather than drawn for the page.
The input is a file you map, not a credential you grant.
There is no billing connector, and the product’s own gap list names live billing adapters as not built. What you supply is a file: you map the charge lines out of the export finance already produces onto a ten-column import template — external id, vendor, tool, team, kind, currency, amount, charge date and the two service-period dates — and the dashboard validates it and shows you the parsed lines before anything is written. An unknown column or inconsistent attribution refuses the batch whole, and one import is bounded to 1,000 lines.
One credential does exist, and it belongs on a page about credentials. Two scheduled pull connectors ship — GitHub Copilot seat spend and Cisco Umbrella activity — each holding a narrow, read-scoped credential you supply into somebody else’s console, off until you set it and not needed to import an invoice. The defensible line is no standing broad credential into your stack, not none at all.
Unknown is the default, and unknown is never zero.
The register defaults to unknown, and that is the reason the thing can be trusted. A tool that defaults to approved reports an estate that has been vetted when what actually happened is that nobody looked. An entry stays unknown until a named person makes it approved or prohibited, and the change is audited with that person on it.
- Coverage is its own axis
- A source nobody has connected reports no traffic, and no traffic reads as clean on every chart ever drawn. The estate report sets its own completeness to false and lists why.
- Where approval suppresses a finding
- The seat-spend detector reads the register first, so a subscription you have approved is not reported as unauthorised seat spend. Billing reconciliation, network egress, the key audit and IDE telemetry do not consult it.
Which of the two you should actually put in.
Read the left one first. If two of those describe you, buy the other thing. If the right column describes you, the next step is thirty days with the source on your own hardware.
When to choose spreadsheets and billing consoles
- One person can name every AI service the business pays for, without asking anyone. The spreadsheet is being kept by somebody who knows.
- The AI bill is one vendor, on one card, in one currency. An owner on every line is a lot of structure for a list of one.
- Nobody outside IT has asked the follow-up question yet. While the total is all anyone wants, the total is doing its job.
- You want the number to go down rather than explained. This attributes spend and records decisions; only the vendor can end a seat.
- You want the subscriptions found for you. An import finds what the invoice lists, so anything nobody has invoiced you for stays outside it.
When to choose Token Observe
- You gave the CFO a number off the card statement, and the next question was which teams, which tools and who approved them.
- The bill is now several subscriptions plus a metered API account, in more than one currency, and the spreadsheet reconciles against neither.
- Somebody has left and you cannot say which of their subscriptions are still being paid for, or who owns them now.
- The billed figure and the metered estimate have to stay apart, because a blended total is the one number the invoice will never agree with.
If the left-hand column describes you, that is still worth an email: a straight answer costs both of us less than an evaluation that ends in the same place.
See the thirty-day evaluationThe other comparisons
The other 6 categories, each opening with the case for the alternative.
Does it connect to our billing, or to the vendor consoles?
No. There are no billing connectors and no vendor console reads: what the product holds is an operator-supplied vendor master bill. You map your finance export onto the import template and post it, as CSV in the dashboard or as the same fields in JSON. Two scheduled pull connectors do ship — GitHub Copilot and Cisco Umbrella — and they are seat and network evidence rather than billing, each on a narrow read-scoped credential you supply and can withhold.
Will it find the subscriptions we have forgotten about?
No, and this is the sharpest limit on the page. An import finds what the invoice lists, so a subscription never invoiced to an account you export from stays unknown until a person registers it. The shadow-AI radar reconciles evidence you feed it — bills, network egress, service-account keys, IDE telemetry — but a network feed gives you a destination rather than a transcript, and a hostname is not a verified identity. Chasing a finding stays your work.
Can it give us one AI number for the board?
Not one. It gives you two and refuses to add them. A subscription invoice is money that has already moved; a metered token estimate is a calculation over observed traffic using a price table, and a blended total is true of neither. Currencies work the same way: each is reported as billed, and no exchange rate is applied anywhere.
Tell us which way you are leaning, and why.
Write to hello@tenhaw.com with your AI vendor list and last month's invoices. 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