What SAP’s New AI Pricing Actually Asks of Utilities
The following Utility Voice was authored by Marc Rosson, Community Connector at Utility.Community.
For two years, the honest answer to “what does SAP’s AI cost?” was that nobody knew. Capabilities shipped inside releases. They were demonstrated at Sapphire. And then a utility CIO would ask a straightforward question — what is bundled, what triggers a charge, and how is that charge calculated once this moves from a demo into a live billing process — and the room would go quiet.
That has changed. SAP has published a coherent structure: a Base AI tier that is free or included in the user subscription, and a Premium AI tier that is metered. More capability moved down into the standard entitlement than most of us expected. The agent layer is priced on work performed rather than access granted.
This is a better model than what came before it. It is also the moment the risk became visible, and visible is not the same as new.
There is a reason to deal with it now. As of the July 2026 renewal cycle, use-based pricing is reported to be the default for SAP cloud renewals rather than an opt-in construct, and the terms that govern it — unit price, bundled allowance, overage rate — are set on the order form. Whatever you do not ask for at signature is not a roadmap conversation you can reopen later. It is a rate you now pay.
Layer One: The Bundle Actually Moved
Start with what improved, because it genuinely did.
Joule Base — natural-language interaction across SAP applications — is free, and Embedded AI is included in the user subscription. If your relationship with SAP AI to date has been “conversational front end on top of IS-U and S/4HANA Utilities,” a meaningful part of that now sits inside the entitlement you already pay for. What meters is the part that acts: Joule Agents and custom agents, per action; Document AI and document grounding, per request or record; Joule for Consultants, a named user.
The logic is sound. A per-seat model was never going to survive an architecture explicitly designed to reduce the number of seats. If agents absorb work previously done by people, charging by the person is a self-cancelling business model. SAP moved the meter to where the work happens. That is intellectually honest.
The problem is what “per action” means, and SAP has not defined it with the precision a utility budget requires.
Layer Two: The Decoupling
Here is the mechanism, and it is the whole article.
SAP’s direction is that assistants orchestrate agents. A user no longer requests one action. They state an intent. The assistant then decides how many agents are needed, which tools each one calls, how many steps each runs inside the ERP, and what to do when a step fails. For example, in the EAM space, the Asset and Service Assistant orchestrates AI agents available in multiple different EAM modules. In one use case, it calls agents for Asset Performance Alerting, Maintenance Request Initiation, Maintenance and Service Dispatch, and Technician Briefing.
So the thing being metered is not the request the user made. It is everything that request set off.
An analyst types “reconcile the unbilled revenue variance for the Northern district.” Behind that sentence: a plan, retrieval calls, model invocations, tool calls into the billing tables, a verification pass, a retry when one call returns nothing, a handoff. One intent in. An unknown quantity of billable activity out — sized not by the person who typed it, but by the orchestration layer.
This is not a flaw. It is the entire point of the Autonomous Enterprise. The value proposition is precisely that you stop specifying steps. But if you stop specifying steps, you also stop being able to forecast the step count, and the step count is the O&M charge for usage.
Buyer-side licensing analysts have begun benchmarking this. The construct is prepaid credits — AI Units — metered per action and pooled across the tenant, with an allowance bundled per Advanced Full User Equivalent and an overage rate once the pool is spent. Benchmarking across roughly three to four dozen cloud agreements between 2024 and 2026 puts that overage at eight to eighteen cents per action, against an allowance in the low hundreds of actions per Advanced FUE, with agents drawing at several multiples of an interactive prompt. Treat the numbers as third-party observation, not SAP list pricing. Treat the shape as real, because the shape is what matters.
And the shape has a specific consequence for us. The same analysts note that scheduled agents draw at every step, on a timer. Now consider our processes. Utility work is heavily scheduled — billing runs, meter data validation, estimation, exception handling, outage restoration workflows, month-end close. None of it is interactive. It fires on a calendar. An agent fleet pointed at those processes generates consumption on nights, weekends, and holidays: the exact hours nobody is watching a dashboard.
Layer Three: “Outcome” Is Doing Work It Hasn’t Earned
Watch the vocabulary carefully in every deck you see this fall, because there is a real distinction being blurred.
The agentic pricing taxonomy sorts into roughly four models: per agent, for availability; per activity, per metered action; per output, per tangible deliverable; and per outcome, when a defined business result is achieved.
SAP is doing per activity. The marketing language reaches for per outcome.
The difference is not semantic. It is a question of who absorbs failure. Under genuine outcome pricing — and there are vendors doing this, charging per resolved support case only when the resolution passes verification — the vendor eats the cost of retries, failed plans, clarification loops, and abandoned attempts. Under per-activity metering, the customer does.
SAP is not an outlier, and the industry is converging here rather than away: Salesforce moved Agentforce from per-conversation to per-action credits inside a year, and Microsoft meters Copilot Studio in message credits. The direction of travel is toward the customer absorbing the step count.
Agent workloads are recursive. An agent plans, calls tools, observes results, adjusts, retries what failed, sometimes starts over. In a mature process that overhead is modest. In year one against a thirty-year-old IS-U configuration with a decade of custom exception handling, it will not be. And every retry is a metered action.
So when the recommendation is “start with your messiest process, because that is where the value is” — understand that your messiest process is also your highest attempt-to-success ratio, and you are paying per attempt.
Call it what it is: per unit of work. Not per outcome. Insist on that language in your own internal documents, because the word you use will quietly shape the business case you build.
Layer Four: The Prudency Problem
A regulated utility does not simply have a budget. It has a budget it must defend. IT and shared-services spend flows into a rate case, gets tested by intervenors, and is judged against a prudency standard: was this a reasonable expenditure, reasonably incurred, by a reasonable operator, given what was knowable at the time?
Now try that with a metered agentic line item. “We forecast four hundred thousand dollars and it came in at one-point-one million” is survivable if you can explain the variance. “We could not forecast it, because the orchestration layer determines consumption and we have no visibility into how many agent steps an intent triggers before we commit to it” is not an answer. It is an admission that you deployed a cost driver you could not measure.
We have been here before, one layer up, and did not win decisively. Because on-premises software can be capitalized and rate-based while a subscription is typically expensed, the investor owned utilities carry a structural bias toward owning rather than subscribing, for the public utilities its different but managing actuals to a budget is the same. This difference has nothing to do with which choice serves customers better. NARUC passed a resolution in 2016 urging commissions to address exactly this, and has kept at it since, publishing a commissioner primer covering SaaS, cloud computing and AI. New York moved, allowing certain prepaid software arrangements to earn a return under its REV proceedings. But Illinois is the cautionary half, usually left out: after studying the question from 2017, the Illinois Commerce Commission rejected a cloud cost-recovery rule in July 2020 on a 3–2 vote, the chair finding it lacked a necessary consumer-protection mechanism. A decade of advocacy has produced a mixed record.
Metered AI is that same fight one layer down, with a worse fact pattern. A SaaS subscription is at least a fixed, forecastable operating expense. A metered agent fleet is a variable one, and the variable is set by an orchestration layer you do not control. If we could not reliably win capitalization for a predictable subscription, we should not assume anyone will wave through an unpredictable one.
Which means the requirement for our sector is not a better negotiated rate. It is instrumentation. Three things to ask for now, in contract language, not in a roadmap conversation:
Pre-execution cost estimation. Before an intent is dispatched, the assistant should return an estimated action count and cost band. Not a guarantee — an estimate, with a confidence range. If the orchestration layer is smart enough to plan the work, it is smart enough to price the plan.
Consumption telemetry that maps to how a utility accounts for work. Be precise here, because SAP will correctly point out that consumption reporting already exists — AI Unit visibility through the BTP cockpit and SAP for Me, plus published sample tooling that watches daily consumption and alerts as it approaches a configured limit. That is real. But what ships is tenant-level, and the reporting is described as running a day or more behind actual consumption. A tenant total on a lag is a reconciliation tool. It is not a control and it is not evidence: you cannot cap what you learn about after the fact, and you cannot allocate to a rate case what you cannot attribute to a named process. The ask is not “give us a dashboard.” It is per-process attribution, close enough to real time to act on.
A hard cap with an alert threshold, not just a rate. The allowance, the unit price, and what the analysts call the agentic multiplier are three separately negotiable terms. Flexibility without a ceiling is unbounded cost with better branding. Worth knowing: the licensing-advisory community now names a hard cap with an alert threshold as one of the four terms to settle on the order form — while reporting that it has rarely been asked for. That is not evidence it cannot be had. It is evidence that almost nobody has tried.
Other vendors resell bought-in, floating model costs too. Salesforce publishes a credit rate card. Microsoft publishes Copilot Studio credit packs at a stated price. Both chose to publish a per-unit price and sell prepaid capacity against it. SAP has not — it chose pass-through metering without a published rate. That is a defensible commercial choice, but it is a choice — and that matters, because a term you believe is structural is a term you will never ask to change.
Arizona is running this in the open right now
If this sounds theoretical, it is not, and the place to watch is next door to several of you.
In March 2026, Commissioner Lea Márquez Peterson opened Docket No. AU-00000A-26-0060 at the Arizona Corporation Commission — “In the matter of researching and discussing the use of Artificial Intelligence to more efficiently and reliably deliver energy and water to customers.” Regulated electric, gas, and Class A and B water companies were asked how they use AI in planning and forecasting, storm response, and equipment procurement. A workshop is expected before year end.
Read that scope again, because what is absent is the point of this article. The inquiry asks utilities how they use AI. It does not ask what AI costs, how it is budgeted, or how it will be recovered. The first state-level AI inquiry in our industry has no cost question in it.
The responses tell the same story. Salt River Project filed a voluntary response on April 30 — voluntary because SRP, as a public power district, is not subject to Commission jurisdiction for this docket, which makes it an act of good citizenship rather than compliance. It is a serious document. SRP describes evaluating every AI technology through architectural review, cybersecurity assessment, legal and compliance oversight, and risk management evaluation; performing vendor due diligence and supply chain risk assessments covering security controls, data handling practices and contractual safeguards for third-party and cloud AI; and refusing autonomous AI control of bulk electric system operations or safety-critical functions. That is a mature governance posture, and more than most utilities could produce on short notice.
It also contains no discussion of cost. Not budget, not consumption, not recovery. I do not read that as an oversight on SRP’s part, because the Commission did not ask. It is the cleanest illustration available of the gap: our most careful utilities are governing AI thoroughly along every axis the question was framed around, and the meter is not one of them.
The encouraging half is that the mechanism already exists. SRP’s supply chain risk assessment already validates vendor data handling practices and contractual safeguards. That is exactly where a metered agent layer and its consumption terms belong. Nobody needs to invent anything. The existing gate simply has not been pointed at the meter.
Layer Five: The Surface Nobody Has Priced Yet
One more thing. It is not strictly a pricing question, but it arrives on the same truck.
Joule Work Desktop — the desktop client in SAP’s Joule Work family, alongside the mobile client — is a separate, standalone surface. Unlike embedded Joule, which runs inside SAP applications, it operates at the level of the machine, across local files and desktop applications, and does not require an SAP connection to be useful. It reaches general availability in the back half of this year, which is to say now, not eventually.
When I first drafted this section, SAP had published nothing about how that surface handles data. That is no longer true, and the change deserves to be stated fairly. SAP now describes the desktop app as working with local files inside a secure sandbox, and says files are not automatically uploaded to SAP cloud systems. Governance is described at platform level — role-based access, data permissions, policy controls, auditability.
So the objection is no longer silence. It is narrower, and harder to wave off.
“Not automatically uploaded” is a carefully bounded claim. It tells you the product does not sweep your drive. It does not tell you what is transmitted when a user points the assistant at a local document, which is the entire use case. SAP has published detailed data-protection documentation for Joule and for the mobile Joule Work client — local encryption, cached content handling, defined retention on telemetry — and there is no equivalent statement for the desktop surface. It is easy to read the mobile documentation and believe you have your answer; they are different products. Nor is there independent verification: the most detailed public walkthrough I can find is a reconstruction whose author states plainly that he has no access to the product. The security claims are, at this moment, vendor assertions nobody outside SAP has tested.
For most industries that is a procurement footnote. For us it is not. The local files on a utility engineer’s laptop include one-line diagrams, substation configurations, protection settings, and vulnerability assessments — material that falls under CEII handling requirements and in some cases NERC CIP information protection obligations. It includes customer data that never lived in SAP. A machine-level assistant reading that directory is a new data-handling boundary, on a surface that does not require an SAP connection and therefore may never have passed through the same architecture review as the rest of your Joule rollout.
Ask for the data-handling statement for Joule Work Desktop specifically: retention, storage location, whether desktop content accumulates into persistent organizational memory, and whether any of it informs model improvement. If your utility already runs supply chain risk assessments on cloud AI services, as SRP describes doing, this surface belongs inside that process.
Honest Caveats
Several things cut against the argument above, and they should be said plainly.
The pricing is better, not worse. It would be easy to read this as a complaint. It is not. A published structure with a defined free tier is a substantial improvement over two years of “it depends,” and SAP moved first among the major ERP vendors on bundle clarity.
Metering may prove cheaper than seats. If your agent adoption is genuinely narrow — a few well-defined processes, moderate volume — a pooled allowance may cost materially less than licensing every user for capability most touch twice a month. The unbounded-cost scenario is real but not universal, and assuming the worst case is its own kind of error.
The benchmark figures are third-party, not SAP list. The rates circulating in the advisory community come from renewal benchmarking across a few dozen agreements. They are directionally useful and consistent with what competitors publish openly. They are not a quote. Do not build a board slide on them without validating against your own paper.
SAP has shipped more visibility than my framing might suggest, and my main ask is genuinely hard. Cockpit-level AI Unit reporting exists today; my objection is to granularity and lag, not to the existence of the capability, and that distinction deserves to be made accurately in your internal write-ups. Pre-execution estimation is also technically nontrivial — an orchestration layer that plans dynamically cannot always know its step count in advance, particularly when the plan branches on data it has not yet retrieved. A confidence band is achievable. A guaranteed number probably is not, and demanding one may simply stall the conversation.
This may be transitional. Agentic pricing models are barely eighteen months old, and Salesforce alone changed its twice inside a year. By the time most utilities run agents at scale the industry may have converged on something more predictable, and those of us who spent 2026 negotiating hard caps will look like we were fighting the last war. I do not think so. But I have been wrong about the pace of this before.
What Are You Seeing?
I would like to hear from our community. Make this a topic you bring up with others at SAP for Utilities. We need leaders like SRP that are contributing to the PUC discussions. If you know of others, please share.
First: has anyone successfully negotiated a hard cap or an alert threshold on AI consumption, and what did it cost you elsewhere in the agreement? The advisory community says it is achievable and rarely requested. I would rather hear it from a co-op or a municipal that actually signed one.
Second: how are you planning to treat metered AI consumption in your rate case? We already have half a precedent and it is not encouraging — cloud capitalization has been contested since 2016, New York moved, Illinois declined. Metered consumption is a harder version of the same argument. So the question is not really “O&M or capital.” It is whether anyone is preparing to defend a variable, vendor-metered operating expense in front of a commission, and what evidence they intend to bring.
Third: has anyone put Joule Work Desktop through a security architecture review? If so, what did your team ask for, and what came back? And if you already run supply chain risk assessments on cloud AI services, has anyone extended that gate to consumption terms as well as data handling?
There is a natural place to take this up in person: SRP is presenting at SAP for Utilities in San Antonio in October, along with a number of the utilities furthest along on this. If Arizona holds its workshop before year end, the question of what AI costs and how it gets recovered ought to be in the record before that workshop, not after it. We also have a working group forming around Autonomous Enterprise readiness on Utility.Community, and this is the next thing it should take up.
The meter is on. The question is whether we instrument it before the first unexplained expenses start to materialize in our G/L or after.