June 22, 2026 · 7 min read · Finance operations
Who owns the AI budget?
Four teams have a real claim, and handing it to any one of them fails in a way you can predict. The workable answer is a split. Engineering owns the choice, finance owns the size of the pot, purchasing owns the contract, security owns the gate — and all four read the same numbers.
If you are between 50 and 500 people, you are probably having this argument right now. Engineering says it should own AI tools, because it is the only team that can tell whether a tool works. Finance says it should own them, because it is the only team on the hook for the total. Purchasing says nobody told it about the contract until three weeks before auto-renew. Security says it is being asked to rubber-stamp.
All four are right. The failure is not that the wrong team won the argument. It is that in most companies the argument was never settled, so ownership falls to whoever noticed the invoice. KPMG's Q2 2026 Global AI Pulse surveyed 2,145 C-suite leaders across 20 countries. It found 42% have only partial sight of AI spending, and only 7% report a proven return on AI. The split inside that is the part worth reading twice. Among leaders who can see their costs clearly, 15% report a proven return. Among those who cannot, 3%. Seeing what you spend is not a reporting nicety. It is five times the outcome.
The four claimants, honestly
Engineering
The case. Engineering is closest to the value. It is the only team that can tell a tool that changed how work gets done from one that produced a demo. It can decide in days rather than a buying cycle, which matters in a category where the products change every quarter. And engineers are the ones who route around a slow process, so a process they do not own tends not to survive.
How it fails. Engineering has no reason to cut. A seat is a paid license for one person, and a $40/month seat that a developer likes is not worth an engineering leader's political capital to remove. There are hundreds of them. Engineering also cannot see what finance has to defend: the total, the growth rate year over year, the board question about why the software line moved 40%. Engineering owning this alone produces spend that is defensible one line at a time and indefensible in total.
Finance
The case. Finance owns the totals, the forecast and the discipline. It is the only team that sees AI spend against everything else competing for the same money, and the only one that will notice when a line grows faster than the business.
How it fails. Finance cannot tell a $200/month tool that pays for itself from a $200/month tool that does not. Both look the same in the books. So when the cut comes, it lands as a flat percentage across the whole category rather than on the tools that are not earning. That strips out good spend and bad spend in the same proportion, and it teaches engineering to stop telling finance about new tools. Blunt cuts are not a character flaw in finance. They are what happens when dollars are the only data available.
IT and purchasing
The case. Purchasing owns the vendor relationship, the renewal calendar and the bargaining position. It is the team that knows when a contract auto-renews, what right you hold to cut seats you do not use at renewal, and what similar companies paid. That knowledge is worth real money at renewal, and no other team has it.
How it fails. Purchasing usually gets pulled in too late, so it is processing a decision rather than shaping one. And it tends to treat AI tools as ordinary software, which they are not. An ordinary software contract is a seat count times a price. An AI contract has a usage part that can run past the seat line entirely, and playbooks written for seat-based software have no clause for that.
Security
The case. Security has a real interest here, and one you cannot negotiate away. Code leaves your environment. Prompts hold customer data. Model providers have retention policies that vary and change. This is a real gate, and skipping it is not a cost saving.
How it fails. Treating security as the budget owner. Security's job is to say whether a tool is allowed, not whether it is worth the money. Those are two questions with two kinds of proof behind them. And a slow gate creates the exact problem it exists to prevent. An engineer who cannot get a tool approved in six weeks puts it on a personal card and expenses it. That is how shadow AI spend starts — AI tools bought on personal cards, outside of purchasing — and it is invisible to every control you just built.
A slow approval gate does not stop AI spend. It moves it somewhere you cannot see it.
The split that works
Not a winner. A split of four separate decisions that are being treated as one.
- Engineering owns the choice. Which tools, for which teams, at what coverage. Engineering proposes and defends what gets adopted, and reports how deeply the tools get used — not just whether seats went out, but whether anyone opened them.
- Finance owns the size of the pot and the reporting standard. The total, the forecast, the account structure everything rolls up to, and the definition of what counts as proof. Finance does not pick tools. It sets the budget the picking happens inside, and the format everyone reports in.
- Purchasing owns the contract. Term, commitment level, the right to cut seats at renewal, renewal dates, negotiation. Brought in before the decision is final, not after.
- Security owns the gate. A clear yes or no on data handling, with a published deadline for the answer. Not a vote on cost.
And here is the condition that makes the split work rather than add meetings: all four read the same numbers. One set of figures. One definition of a seat. One definition of what counts as used. One place the token spend appears — a token is the unit AI vendors bill for, roughly a few characters of text. In most companies this is the real failure. Not that ownership is unclear, but that engineering is looking at a vendor console, finance at an export from the books, purchasing at a contract, and the four documents disagree. Agreeing on one shared list of buckets for AI costs — accountants call it a chart of accounts — settles more of this argument than any org chart change.
The RACI, in practice
A RACI is a grid of who does what. Four letters: A for the person on the hook, R for the person doing the work, C for who gets asked first, I for who just gets told.
| Decision | Engineering | Finance | Purchasing | Security | |---|---|---|---|---| | Approve a new tool | A | C | C | A (gate) | | Hand out and reclaim seats | A | I | C | I | | Review seat use (monthly) | R | A | C | I | | Own the meter (token run-rate) | R | A | I | I | | Run the renewal | C | C | A | I | | Set the reporting standard | C | A | I | C | | Data handling and access review | C | I | I | A |
Two rows deserve attention.
The seat-use review needs a rhythm, not a project. Monthly is enough. It should take twenty minutes and produce one output: seats to reclaim before the next renewal window. Quarterly is too slow to matter at renewal. Weekly is theater.
The meter is the row that is always unassigned. The meter is the part of the bill that goes up with use. Ask most companies who owns the token run-rate and you get a pause. Engineering assumes finance is watching the total. Finance assumes engineering is watching the usage. Nobody is watching how fast it is changing, which is why Zylo's 2026 SaaS Management Index found 78% of IT leaders hitting unexpected AI or usage charges. A line nobody owns does not stay flat. It floats.
The problem gets harder as the meter grows
Here is the issue underneath all of this: the person who picks the model is not the person who owns the budget.
Someone changes a default model in a config file. Token cost per call moves by a factor of two or three. No purchase order, no approval, no note to finance. The same goes for an agent that starts running on every pull request instead of on request. It is a workflow choice with a budget consequence that nobody filed as a budget decision.
Seat-based control has no answer to this, because it was built for a world where spend changes when someone signs something. As usage spend grows as a share of the AI line, ownership has to shift from approving purchases to watching the run-rate. That is a FinOps job — FinOps is the team that watches cloud and software spend — not a purchasing one. Most companies are running the wrong playbook for the mix of spend they now have. What that does to forecasting, where the two lines behave nothing alike, is covered in how to forecast next year's AI budget.
Where to start if you have one hour
Assign the meter. Name a person, not a team. Give them the monthly run-rate, the tripwire thresholds, and standing permission to raise a flag without it counting as an escalation.
Then put a renewal calendar in front of all four teams, and pick the next renewal as the forcing event. Nothing aligns four groups faster than a dated deadline with money attached. That is also why building a proof pack ahead of the renewal tends to settle the ownership question in practice, without a reorg.
The honest caveats
This is an opinion about how to organize, not a counted finding. The KPMG link between seeing your costs and proving a return is real and large, but it is a link across self-reported survey answers. Companies that can see their costs clearly are probably better run in several other ways too, and that may be doing some of the work the visibility gets credit for. The grid above is a starting point that will need rewriting for your structure. A 60-person company where the CTO and CFO talk daily needs less of this than a 400-person company with three engineering groups, and both will find rows that do not apply. And no ownership model recovers spend on its own. It decides who is on the hook when the numbers are bad, which is needed and not enough.
Find your recoverable AI spend
Spendassay turns this from an afternoon of spreadsheets into a live, proof-level audit with the recovery attached.