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 and were demonstrated at Sapphire. And then a utility CIO would ask what is bundled, what triggers a charge, and how that charge is 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. 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.

One note on how to read what follows. Every consumption claim in this article is one of three things, and I have tried to make it visible which one. SAP-published fact, which I cite to SAP’s own material. Third-party benchmark, which I attribute to the firm that produced it. And my own inference and recommendation, which I mark as mine. Where a sentence does not tell you which it is, assume the third.

There is a reason to deal with it now, and it is SAP’s own timetable rather than an analyst’s reading of one. SAP says it plans to introduce the new Premium AI commercial model in a phased rollout during Q3 2026 — which is to say now — with agents becoming the core of Premium AI and commercialized through AI Unit consumption, most generative AI features moving down into Base AI at no additional cost, and the existing per-user-per-month packages phased out as they go.

The terms that govern use-based pricing — 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. SAP’s Base AI tier — natural-language interaction with Joule across SAP applications — is free or included in the user subscription, and it reaches further than most of us expected. Base even covers document grounding against your own content, with the catch that indexing that content requires an additional AI service: retrieval is bundled, the indexing underneath it is not.

The meter is no longer the mystery. The workload is.

SAP has now published the basic economics of its 2026 AI-agent model: an agent action consumes 0.02 AI Units, and SAP list-prices an AI Unit at €7. The commercial unit is clear, and SAP deserves full credit for that. What remains unclear — and it is the whole of what follows — is how many billable agent actions a real business process will generate once autonomy enters the workflow.

An agent can reason, invoke skills and tools, branch, retry, hand work to another agent, and continue until it reaches an outcome. That is a description of what the software is designed to do, not a billing rule, and I am careful not to assert otherwise. But it is the reason your exposure is not a function of how many people you license. It is driven by what the AI is allowed to do, and how often it does it.

Keep two meters apart while you are at it. The FUE, the Full Use Equivalent — not, as it is often misrendered, a full user equivalent; “Advanced” is a use type, not part of the acronym — is how SAP counts your licensed users. The AI Unit is how SAP counts consumption. They do not convert into one another and they are not billed together, and a vendor conversation that lets them blur is a conversation you will lose.

It is worth being exact about what SAP has and has not done. SAP has defined the unit: an action is a distinct operation an agent performs while completing a task within an agent run, and an agent run contains one or more actions. SAP has published the rate. What SAP has not published is enough implementation detail for a utility to predict how one of its own business processes maps onto that count. The problem was never the definition. It is the mapping.

That changes the architecture and procurement question. For a regulated utility, AI consumption needs to be forecastable, attributable, governable, and contractually bounded before autonomous workloads become production O&M. The question is no longer “What does SAP charge for AI?” It is “Can a utility predict and control what an autonomous SAP process will cost?”

Layer Two: The Decoupling

Here is the mechanism that drives the workload.

SAP’s direction is that assistants orchestrate agents, and this is SAP’s own description rather than my characterization of it. SAP describes Joule Agents as selecting from a set of tools — skills, other agents, third-party applications — executing their plans and then reasoning over the results, and separately describes agentic orchestration in which Joule autonomously chooses the combination of agents and skills needed for a multistep objective. A user no longer requests one action. They state an intent.

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. How many actions is that? I cannot tell you, and neither, so far, can SAP’s published material. SAP’s definition of an action does not establish that each item in that list is separately metered. What it establishes is that the count is set by the orchestration layer rather than by the person who typed the sentence.

SAP quantifies the fan-out elsewhere. It defines a request as any interaction with a language model, and states that for Joule for Consultants each question asked and answered typically counts as nine requests. Nine — on an assistant considerably simpler than the orchestrated agent fleet described above.

On the rate itself SAP is unambiguous: in 2026, every agent action consumes 0.02 AI Units. One uniform price per action, across agents, whatever the agent is doing. Alongside it SAP publishes the rates for the other consumption-based features — Document Grounding at 0.005 AI Units per record, SAP Document AI embedded edition at 0.1 per request, Joule for Developers at 0.007 per request. And SAP is explicit that the uniform rate is not the end state: the same material carries a note that tiered pricing for actions will be introduced in Q3 2026.

A note on vocabulary, in an article whose central move is watching vocabulary. SAP’s word here is action, and I use it. Step invites you to count the things you can watch an agent do. Action is whatever SAP’s meter counts, which is not necessarily the same list.

A published rate tells you the price of one action. It does not tell you how many actions a business process will generate — and on that, SAP says the quiet part itself. Its own commercial material states that the total AI Unit consumption depends on the agent and the work it performs. That is SAP conceding, in SAP’s own words, the precise proposition this article exists to establish. I would rather quote them than argue with them.

Be precise about the chain. The action count drives AI Unit consumption; AI Unit consumption converts to money at €7 a unit less your discount; and AI Unit consumption is the variable operating cost. Both conversions are published. Neither of them tells you the action count, and the action count is the only number that matters to a budget. AI Units themselves are purchased annually in blocks of one hundred, drawn from a central pool, and expire at the end of the contract term.

The exposure needs narrowing before it will survive a skeptical CIO. The loose version — that a metered agent fleet runs up charges against our billing runs overnight — is wrong: billing execution, validation and estimation are deterministic, high-volume and already automated, and the last place you would point a reasoning agent. The real exposure sits one tier above, in exception handling. Estimation failures, unbilled revenue variances, disputed reads, restoration workflow exceptions, month-end items that will not clear. Smaller than the batch by an order of magnitude, which is what makes it a credible agent target — but still scheduled work, firing when the batch finishes at two in the morning, and the highest attempt-to-success-ratio population in the estate. It lands in exactly the 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. That four-way split is Zuora’s, and I am naming the source deliberately.

SAP is doing per activity. The language around it drifts toward per outcome — in decks, in briefings, in the way “autonomous” gets used to mean “you are buying the result.” The difference is not semantic. It is a question of who absorbs failure. Under per-activity metering, the work that does not succeed is still work you paid for: additional attempts can generate additional actions, and actions draw on the meter. Under genuine per-outcome pricing the vendor carries that. I am not claiming SAP has published a rule making each retry separately billable — it has not.

Nor is outcome pricing pure in practice. Intercom’s Fin, the reference case at ninety-nine cents per resolution, counts a customer who reads its answer and simply leaves as an assumed resolution and bills for it. The part worth stealing sits elsewhere on the same pricing page: Fin charges at most once per conversation, however many procedures it runs internally. Asking SAP to adopt that construct is a negotiating position of mine, not a finding about SAP’s model.

Salesforce is the more instructive comparison. It went furthest down the per-action road and then came partly back — Flex Credits in May 2025 at roughly ten cents per standard action, with the older two-dollar-per-conversation option retained rather than replaced, then per-user licensing from $125 per user per month in late 2025, with the seat restored as the primary wrapper. Three pricing models now run simultaneously on one product. The stated reason was budget predictability. That is our argument, made by somebody else’s CFO. Microsoft, meanwhile, meters agents in Copilot Credits and enforces purchased capacity monthly, to the point of denying service. The hard ceiling I am about to ask SAP for already exists at a competitor.

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?

“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 actions 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. The shorthand is that on-premises software can be capitalized and rate-based while a subscription is expensed — but treatment actually turns on the arrangement and the jurisdiction, so what survives is a bias, not a rule. For an investor-owned utility, whose earnings run through rate base, the difference between an asset and an expense is a difference in return. For a public power district, a municipal or a co-op, that tilt is absent — but the cost still has to be recovered and managed to a budget, and the forecasting problem is identical.

The record is genuinely mixed. NARUC passed a resolution in 2016 urging commissions to address exactly this and convened a webinar on cloud and AI in electric utilities in December 2024. Illinois is the cautionary half: after studying the question from 2017, the Illinois Commerce Commission rejected a cloud cost-recovery rule in July 2020 on a 3–2 vote. A Kennesaw State working paper from late 2024 identifies, out of FERC Form 1 filings, a cohort of utilities that obtained cloud regulatory-asset treatment from roughly 2018 onward — an unpublished working paper, not a regulatory order, and I use it as an indication rather than a proof.

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.

What we should negotiate

What follows is opinion. First, the arithmetic that frames it: at €7 list and the published rate of 0.02 AI Units per action, one agent action costs about fourteen euro cents at list, before any discount. The nominal economics are now simple arithmetic. The utility problem was never the price of an action. It is the number of actions.

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. A plan that branches on data it has not yet retrieved genuinely cannot know its own action count in advance, and demanding a guaranteed number will simply stall the conversation. But a layer smart enough to plan the work is smart enough to bound the plan, and a bound is what a budget actually needs.

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, and a pricing FAQ that claims real-time balance visibility. That is real, and I take it at face value. But what SAP’s published material establishes is a balance you can read, not an attribution you can defend. You cannot cap what you can only observe 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. Flexibility without a ceiling is unbounded cost with better branding. Microsoft enforces exactly this ceiling on Copilot Studio today, to the point of denying service, and Intercom ships hard limits on Fin resolutions as a customer-facing setting. Two vendors ship the thing by default, which disposes of the only objection a vendor can reasonably raise to it: a hard consumption ceiling is technically and commercially feasible. Whether it gets asked for is a separate question, and that one is ours.

On the price itself, SAP list-prices an AI Unit at €7.00 — the figure appears in SAP’s own Learning material, in an SAP-authored Community post giving the minimum purchase as one hundred AI Units at €7.00, and in SAP’s external commercial deck. That deck is worth reading closely on overage, because excess use is not billed at your contracted rate. SAP’s stated formula reduces your line-item discount by thirty points before applying it, floored at zero: a customer negotiated to forty percent off pays overage at ten percent off, €6.30 per AI Unit rather than the €4.20 their contract rate would imply. The deck scopes that formula to the per-user-per-month packages — the ones being phased out — so ask your account team where the overage penalty lands in the new model. A published list price gives you a ceiling rather than a bill, because your actual rate is set by the discount on your order form. But a ceiling is a great deal more than nothing. It is the number you negotiate down from.

Those three asks reduce to six questions you can put on paper and hand to an account team. They are the most reusable thing in this article:

How many actions will a given business process generate, in our configuration?
What precisely constitutes one action in each agent implementation we are licensing?
How do retries, branches and tool invocations map onto actions?
Can consumption be attributed to a named business process or cost center?
Can we impose a hard ceiling, and what happens at it?
Can SAP return a pre-execution estimate, or a bound, before an intent is dispatched?

Questions one through three are the ones with no published answer today. That is the gap, stated as narrowly as I can state it.

Arizona is running this in the open right now

On March 24, 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.” Her letter asks regulated electric, natural gas, and Class A and B water service companies to file on their exploration or use of AI in their operations, and it lists the topics she wants covered:

Storm response
Customer systems
Asset management
Planning and forecasting of energy load and water demands
Procurement of electric and water resources equipment
Grid, power plants and water distribution and treatment systems operations and maintenance
Other topics

Seven topics. Initial filings were requested by April 30, and the letter proposes a workshop on the information gathered by the end of the year.

Now read the paragraph that sits immediately above that list. “As the regulatory agency responsible for ensuring reliability and affordability,” the Commissioner writes, “it is important to ensure we are utilizing artificial intelligence in a secure manner to protect and enhance our energy grid and water infrastructure.” Affordability is named there as the Commission’s own responsibility — and then the same sentence turns, in its second half, to security. Affordability appears exactly once in that letter and never returns. Not one of the seven topics asks what AI costs, how it is budgeted, or how it will be recovered.

That is a sharper finding than saying the docket forgot about money. The docket did not forget. It named affordability as the reason for asking, and then asked seven questions that cannot produce an answer about it.

The responses tell the same story. Salt River Project docketed a voluntary response on April 30 — voluntary because SRP, as a public power district, is “not a regulated utility subject to the Arizona Corporation Commission’s jurisdiction for purposes of this docket.” It is a serious document: AI at SRP is evaluated through governance processes covering architectural review, cybersecurity, legal and compliance oversight and risk management, and SRP “does not permit autonomous AI control of bulk electric system operations or safety-critical functions.” That is a mature posture, and more than most utilities could produce on short notice.

Here is the part I keep coming back to. The filing runs a little over nine hundred words. In all of it, a money word appears exactly once, and it is on the other side of the ledger: the wildfire cameras deliver “lower suppression costs.” No budget. No consumption. No recovery. Put the two documents side by side and the symmetry is almost too neat: the question mentions money once, as the affordability it is responsible for, and the answer mentions money once, as a cost AI reduces. Neither of them mentions the price of the AI.

I do not read that as an oversight on SRP’s part, because the Commission did not ask. 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 “contractual safeguards” for cloud AI, which is the same gate a consumption term would pass through. Nobody needs to invent anything.

Both documents are in Docket No. AU-00000A-26-0060 on the Arizona Corporation Commission’s eDocket, docketed March 24 and April 30, 2026. They are short. If you only read one thing behind this article, read those.

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 is three surfaces, not one. A web client is the primary environment. A mobile client is already generally available. And there is a desktop app, which 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 is not generally available today — SAP’s Sapphire 2026 Innovation News Guide puts GA for Joule Work and Joule A2A at Q4 2026, planned. What exists now is Early Adopter Care: SAP employees plus selected customers on macOS and Windows, under NDA, on real machines. That is exactly the condition under which a new data-handling boundary gets crossed before anybody writes it into a review.

SAP describes the desktop app as working with local files inside a secure sandbox, and says files are not automatically uploaded to SAP cloud systems. That 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 — and SAP has published detailed data-protection documentation for Joule and for the mobile client, but no equivalent statement for the desktop surface.

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 in many cases carries CEII or BES Cyber System Information handling obligations. Because the surface does not require an SAP connection, its boundary is not the one your embedded Joule assessment looked at. Evaluate it separately, in your own architecture and security review. 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.

Honest Caveats

Several things cut against the argument above, and they should be said plainly.

The pricing is better, not worse. A published structure with a defined free tier is a substantial improvement over two years of “it depends.” Salesforce publishes a Flex Credits rate card, Microsoft publishes credit rates, and SAP publishes an AI Unit list price. Three vendors, three published structures, and no ranking from me.

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.

I removed the third-party benchmark figures rather than lean on them. They came from one firm’s renewal benchmarking across a few dozen agreements, they were never SAP’s published terms, and SAP has since published enough of its own rate card that the argument stands without them.

SAP has shipped more visibility than my framing might suggest, and my main ask is genuinely hard. Cockpit-level AI Unit reporting exists today. What remains is granularity, not the existence of the capability. Pre-execution estimation is also technically nontrivial, and a vendor is entitled to say so.

This may be transitional — though less so than I first thought. Intercom launched Fin on ninety-nine-cent outcome pricing in early 2023, which makes the practice about three and a half years old, and Salesforce alone now runs three models on a single product. An approach that has had three years to settle and has instead multiplied is not obviously about to converge.

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.

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? 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? 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?

There is a natural place to take this up in person: SRP is presenting at SAP for Utilities in San Antonio in October. 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 argument here is not that SAP has a mysterious meter. It no longer does: SAP has published the meter, the rate per action, and the list price of a unit. The argument is that publishing the meter is not the same as making consumption predictable, and predictable is what a prudency standard requires.

The meter is on, and we can now read it. The question is whether we can forecast it before the first unexplained expenses start to materialize in our Cost of Service, or only after.