What AI tool spend on expense reports proves
It proves which tools were bought with company money and claimed back. It does not prove which systems those tools reached, whose account they used, or what they changed.
The reports land on the fifth. Support reimbursed one person's assistant seat. Finance put an automation tool on a departmental card. A sales manager charged API credits. Legal expensed a per-seat plugin for a contract tool. None of the four lines is large, and none was approved as a program. AI tool spend on expense reports is how a lot of finance leads learn that adoption already happened.
That makes the report a useful inventory and a weak control. A receipt records a purchase. It does not record a tool call. The gap between the two is the thing worth closing, and closing it is not a procurement decision.
Four departments, four different problems on one report
The four lines look alike in the ledger and behave nothing alike in practice. Sort them before you decide anything.
A reimbursed assistant seat means one person signed in to a consumer plan with a work email. Whatever they connected, they connected as themselves, and nobody else can see what. An automation tool on a departmental card usually means a stored credential running unattended, on a schedule nobody reviews. API credits on a card mean somebody holds a key, and a key is a bearer credential that works for whoever has it. A per-seat plugin means a second vendor sits between an app and a model, with its own permission model. Where that plugin is an app inside an assistant, the assistant's own admin controls may already cover it: on ChatGPT Business, Enterprise and Edu, admins turn an app on or off for the whole workspace (OpenAI's admin controls page, checked October 2026).
Only the first of those is really about a person. The other three are about standing credentials. That distinction decides what you do next, and it is invisible in the expense category.
The spend the report never sees
An expense report sees reimbursed purchases. It misses everything free, everything paid personally, and everything running locally.
Unpaid tiers produce no receipt. A personal card produces no receipt you will ever read. A local MCP server, which is a small program on a laptop that hands an AI client tools, produces no receipt at all. None of the AI client admin pages read in October 2026 documents an inventory of them: not Claude Code's managed MCP settings, and not Cursor's MCP documentation, both checked October 2026. For the discovery side of this, start with finding the MCP servers people installed and with what a browser extension log actually proves.
So treat the four lines as a floor, not a census. They tell you which departments have already decided AI is part of the job. They do not tell you how many people act on that decision without filing anything. If the unattended automation line is the one that worries you, tracing a single unsanctioned automation is the closer read.
Does one endpoint make the AI line items smaller?
Usually not. Consolidating is a governance argument first and a cost argument second, and a post that sells it the other way around is selling you something.
Elaichi lists Gold at $15 per user per month in USD, or $10 per user per month billed annually, which is $120 per user per year. Elaichi has two plans, Gold and Black, and every new organization starts on a 14-day Gold trial that needs no payment details. The pricing page quotes some countries regionally, so check it for your own figure rather than trusting this one. The page is headed "One plan. Priced per human.", which is the honest summary: you pay for people, not for the agents working on their behalf.
So Elaichi adds a line. The reimbursed assistant seats stay exactly where they are, because Elaichi is not an assistant and does not replace Claude or ChatGPT. What can come off the report is narrower: a per-seat bridge somebody bought to connect one app to one model, an automation subscription whose only job was moving records between two systems, and the API credits a team charged because nobody gave them a sanctioned path. Whether those actually come off depends on your four lines, not on ours. If you want the shape of the per-seat and per-call tradeoff before you model it, the pricing-model comparison sets it out.
Three seat classes cost nothing extra, which matters for this conversation. Guest, Billing Admin and Auditor are free seats. A compliance reviewer added as an Auditor does not take a billable seat, and a Billing Admin who only manages the subscription does not either.
What consolidating actually changes
It changes the address, the identity and the record. Those three are the governance case.
Claude, ChatGPT and Cursor all sign in to the same Elaichi address, https://api.elaichi.ai/mcp, over OAuth. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. There is no per-person or per-team URL to hand out, and no API key to paste. Each person connects their client once and approves their own grant, which is the standing permission an AI client holds for that person in that organization. Every request re-reads it.
Because the grant names a person, every tool call runs as that person. A restriction, which is a rule saying which connectors and tools a role or one member may reach, then narrows what they can run. Restrictions target a role or a single member, not a team and not the organization as a whole, so an approved-apps list is written on the roles people hold. Role and restriction changes reach every surface within about two minutes. Revoking a grant, removing a member or suspending one is effective on the next call.
And every call that reaches execution is written to the audit log, with the person, the connector, the connection and the MCP client that made it. One log, across all the apps in the connector catalog, whatever vendor made them. That is the difference from four tools on four cards: one record instead of four vendors' dashboards, each with its own idea of who a user is.
The evidence a finance lead can hand to a reviewer
The audit log is the part that survives a question six months later. It is also the part with real edges, so know them before you promise anything.
Elaichi keeps 90 days of audit history. Each connected-tool entry names the person, the tool, the connection it ran on, how approval was given and what it touched, and the console can export the current view as CSV with its filters applied. Any member can read their own activity; reading the whole organization's needs the audit permission, which Org Owner, Org Admin and the free Auditor role hold. For a longer history, export to your own Datadog comes with the Black plan, which is launching soon.
The edges: a call refused for a missing scope writes no entry, because that refusal happens before anything runs. Listing tools and searching them are not audit entries either. And nothing in this log sees a person pasting a customer list into a chat window, which is a different problem with a different answer, covered in why people paste customer data into assistants and in what CASB and DLP can and cannot see. If the question is specifically what an access review needs, the access review evidence piece is the closer fit.
When the right answer is to do nothing yet
If the four lines are four people using assistants on public information, you do not need a control plane. You need to say so in writing and move on.
The test is not the dollar amount. It is whether any of those tools holds a credential to a system of record. One person summarizing public documents in a paid assistant is a subscription question. One automation tool holding an admin key to your accounting system is a governance question, and it would be a governance question at zero dollars. When you do not need an MCP gateway yet walks that line in more detail.
Two cases genuinely argue against consolidating now. If every tool on the report is already a vendor's own assistant running inside that vendor's product, under that vendor's permissions, a second layer buys you one audit log and not much else. And if nobody will own the roles, restrictions and offboarding afterwards, buying the endpoint just moves the mess to a new place. Governance is work, and the work is the product.
Where to start after the next expense cycle
Start with the credentials, not the receipts. The receipts are the prompt; the credentials are the exposure.
For each of the four lines, write down one thing: which company system it can reach, and on whose account. A reimbursed assistant seat with nothing connected is a line item. An automation tool holding a finance credential is a standing grant that no offboarding process knows about. Stopping personal API keys is usually the first thing to fix, because a key keeps working after the person who created it leaves.
Then decide what each team is allowed to reach before you decide what to buy. MCP governance covers how roles and restrictions get written, and the team playbooks show the order a single team is set up in. Buying the endpoint is the easy part. Deciding that sales reads the CRM as themselves, and that nobody's assistant deletes anything, is the part that holds.
