SAP is publishing how it controls its own AI bill
SAP has pulled AI token spending into its regular finance planning processes, and the trigger will be familiar to anyone whose first AI invoice beat the pilot estimate. ERP Today, in a September 18 piece bylined Senior Editor Adam Pitman, reports that SAP found rising usage from both employees and automated agents could produce costs out of proportion to the work, enough for the piece to describe the exposure as a triple-digit-million-dollar financial risk.
ERP Today attributes the framework to SAP Chief Controlling Officer Lukas Deutsch and SAP Financial Management Chief Marketing Officer David Imbert, who outlined how the company has been testing and refining the approach internally. Four levers did the containing: token caps, model routing, tool rationalization, and pushing cost ownership closer to the teams consuming the tokens. A vendor explaining how it holds down its own AI bill beats most vendor guidance, because those are the levers its customers will be reaching for next.
A token cap is a decision about who gets told no
Caps sound simple. A working one needs metering that attributes consumption to a workload, a team, or an agent identity rather than to the one shared key everybody uses, a point in the request path where the limit gets enforced, and a defined behavior at the moment it is reached. That last piece is where the argument happens, because a hard stop, a downgrade, a queue, and a page to a human land on somebody's Tuesday in different ways.
Agents sharpen it. An agent stuck in a retry loop spends with nobody watching, which is why AI agents need a pause button and why runtime policies at an AI gateway do more real work than a monthly report. Leave room for exceptions too, because somebody will hit a cap during quarter close, and if the only way through is a four-day ticket, teams will route around it on a key that has no limit.
Model routing is a finance decision that engineers make
Routing means the cheap request goes to the cheap model. Doing it on purpose requires classifying request types, harder than it sounds, plus an evaluation set that tells you whether the cheaper route made the answer worse. Without that evidence, routing is cost cutting you cannot defend. The first time a sales team says the assistant got dumber, someone will ask whether routing caused it, and a shrug means the route gets reverted along with the savings.
Routes also have to change without a deployment. Model prices and quality move quarterly, and if switching a route means waiting for a release train, the finance decision lands three months late. That is the job a control plane for enterprise AI is supposed to do, and most teams have not built it yet.
Tool rationalization is the lever nobody volunteers for
ERP Today does not spell out what SAP means by tool rationalization, and our read is the ordinary version. Agents carry a set of tools, every tool description rides along in the context of every call, and tool catalogs grow faster than anyone prunes them. Redundant tools cost tokens on every request and cost accuracy too, because a model choosing between four overlapping options picks wrong more often.
The work is unglamorous: an inventory of every tool an agent can reach, a named owner for each, and a retirement list with dates on it. Teams that have run a retirement list alongside modernization know how that meeting goes. Nobody objects to the principle, and everybody objects to their own tool being on the list.
Cost ownership only works if the team can change the cost
Pushing cost ownership closer to the consuming teams has the most organizational teeth of the four, and it is the easiest to fake. Showing a team its monthly token number takes an afternoon. Giving that team the authority to switch the model, rewrite the prompt, or retire the tool driving the number takes a conversation with whoever owns the platform.
A number without that authority becomes a blame line on a report, and teams learn to argue about attribution instead of reducing spend. The same thing happens with the real cost of an unused license, where the department getting billed has no way to release the seat. Tag the call, not the invoice. Rebuilding who spent what from a monthly statement arrives too late to change behavior.
Lower consumption is the wrong target
The most useful line in the piece argues against the obvious reading. ERP Today is explicit that reducing consumption is not the goal in itself, and that a workload can justify higher token use when it produces enough business value to offset the cost. A program that only measures spend will cut the workloads that were paying for themselves, and it will cut them first, because those carry the biggest numbers.
SAP's worked example is its own AI developer tooling, which increased the rate at which developers got code changes approved and incorporated by a mid-double-digit percentage. More tokens bought more shipped work there, and a cap tuned purely for savings would have slowed that down while showing a green number on the finance report. Value measurement is the hard half of this program, and every team will argue about the denominator, the same fight we worked through in clean core is a budget decision.
What the article does not quantify
Mid-double-digit percentage is a characterization, and the piece gives no exact figure behind it. There is no baseline either, so a rate climbing off a low start reads differently from one climbing off a healthy number. The triple-digit-million figure describes a risk the levers helped contain, not savings booked, and SAP's own token spend before or after does not appear.
How the caps get enforced, which models sit on which routes, and how many tools got cut are all absent, which makes this a shape to copy rather than a benchmark to quote at your CFO. So take one question into your next planning meeting. When an agent hits its cap at three in the afternoon on the last day of the quarter, what happens, and who gets the call? If nobody in the room can answer, the cap lives on a slide and not in the request path.
