The Front Door Has a Meter On It!

Over the last two articles we looked at what SAP's EU commitments changed for perpetual on-premise estates, and how to use the flexibility they created. There is a line in Part 2 worth pulling back out.

None of it touches cloud subscriptions. The remedies apply to perpetual licences. The part of your estate that is growing fastest, and where SAP is most actively building new commercial ground, was never in scope.

Over the same period SAP has made three announcements that, taken separately, are each unremarkable. It signalled an ambition for consumption to reach a materially larger share of cloud revenue, directionally around a third by the end of the decade. It published an updated API policy routing agentic and generative AI access to SAP data through SAP's own endorsed pathways. And it made its agent development tooling free through to the end of 2026.

Read together, against an estate where you have just been handed new leverage on the old commitments and none on the new ones, they describe a commercial position a great many organisations are quietly accepting while their attention is elsewhere.

SAP has real reasons for tightening API access: a single prompt to an AI agent can generate thousands of API calls in patterns transactional systems were never designed to absorb, and interfaces built for SAP's internal use were repurposed by third parties for years without proper authentication or audit trails. Any vendor running a shared platform would have to address that eventually.

The customer side is just as real. Consumption terms rarely arrive on their own. They sit inside a RISE agreement, a SuccessFactors renewal, a BTP schedule or a Business Data Cloud addendum, alongside the commercial points the organisation consciously convened to discuss. We see them approved rather than negotiated, with no owner and no model, because nothing in the process prompts the commercial analysis that would show the implications of what is agreed. That is understandable. It is still a decision.

The updated API policy sorts SAP's interfaces into three groups: published APIs, documented in the SAP Business Accelerator Hub (https://api.sap.com); non-published APIs, internal and used at your own risk; and a small set explicitly prohibited.

The clause that matters restricts using SAP APIs for interaction or integration with semi-autonomous or generative AI systems that plan, select, or execute sequences of API calls, except through SAP-endorsed architectures. In practice those are SAP's own: Joule, the Agent Gateway and MCP Gateway on Integration Suite, and the Agent2Agent protocol. A third-party agent is not prohibited outright, but it reaches SAP by delegating the work to Joule rather than calling SAP's APIs itself. Traffic that once ran directly between your systems and your data now runs through infrastructure the vendor meters.

The policy has teeth. RFC-based access to the ODP data replication API, which a substantial proportion of SAP customers have relied on for extraction into external analytics platforms, was blocked from June this year. That change deserves its own article and will get one. For now it is enough to note the policy is not aspirational.

SAP wants more revenue from consumption. The API policy means agentic access increasingly runs through SAP's metered infrastructure. And consumption products, in our experience, carry the least flexible commercial terms in SAP's portfolio.

We are not suggesting the policy was designed to produce that result. We do not need to. Your exposure is the product of three separately announced facts whatever the reasoning behind each, and it is the exposure, not the intent, that shows up in a future budget.

This is also where public analysis stops, because it has to. Commentary can tell you what a service costs today. It cannot tell you what an agreement permits to change tomorrow, because those schedules are not public documents. In our experience they repay careful reading, and the mechanisms determining what a unit costs, and how many units an action consumes, are rarely where you would expect to find them.

A seat licence has one lever and you hold the input. Cost follows headcount. You know that number and can argue about it from a position of knowing what you are arguing about.

A consumption agreement has two levers and the vendor holds both. The first is what a unit costs. The second, less visible and generally more valuable, is how many units a given action consumes. Move either and the bill moves, and the second can move without anything in your environment changing. A schedule that fixes the first and stays silent on the second has fixed the half that was easier to defend. Anyone can argue about the cost of a consumption unit, but assessing the impact of a small uptick in the conversion rate of units to actions that no one paid attention to in the first place is a much tougher ask.

Then add the agentic multiplier. An agent run is not one action but a sequence: retrieving context, reasoning, calling, checking, writing back. The consumption rate lever carries far more force in an agentic world than it ever did for integration traffic, because each unit of business activity now sits on a variable number of billable actions rather than a fixed one.

Volume does not help you either. Many of these products carry no tiering at all. Under a seat model, buying more usually buys a better rate as a matter of course. Here, scale often brings no rate improvement, so growth in usage translates directly into growth in cost with nothing pushing back the other way.

Consumption terms are agreed at the point of least usage and tested at the point of most. What makes that dangerous is not the volume. It is that nothing in the process prompts the commercial analysis that would show what those terms are worth at scale. Especially if you’re committing to usage “units” without being clear on what you’re going to use them on.

On a renewal there is nothing obvious to trigger it. The commercial position is like for like and the working assumption is that nothing has changed. On a new agreement, the analysis and the negotiating effort go to the headline commercial points, which is where the business case is won or lost. The conditions sitting underneath, what a unit costs, what an action consumes, who is able to change them and on what notice, are accepted rather than negotiated.

That structure was set against a volume you were not using. Then the transformation works, volumes rise, and you scale into a commercial structure nobody analysed, built for a volume nobody was running. It does not improve on its own.

The cycle applies here almost too neatly. Exposure created during Project and Implementation surfaces in Hesitation and Deviation, when invoices arrive against a usage pattern nobody modelled. It then constrains Retain or Exit, because by then the estate is built on the vendor's runtime. Leverage is lowest exactly when cost is highest.

The free window sits inside this. SAP has made design-time access to its agent tooling free through to the end of 2026 under fair-use limits, and has not published what gateway throughput, agent-to-agent consumption or data egress will cost in 2027. That will catch people. But it is the smaller problem. The larger one is the terms you have already agreed for consumption you have not started.

An API policy published after you signed your agreement is not automatically binding on you. Whether it is depends on how your contract defines Documentation, and on what limits exist on SAP's ability to change terms unilaterally, particularly where a change would materially degrade functionality you have paid for. That differs contract to contract, and the policy document cannot settle it.

This is where we consistently see two different reviews conflated. A legal review answers whether the policy has validly become part of your agreement. A commercial review answers what leverage you hold and what it should cost to resolve, regardless of how the legal question lands. Different questions, different expertise, and answering one does not answer the other.

Uncertainty carries its own cost. Where organisations are unsure where the line sits, they tend not to push against it. They stop, and the roadmap slips without anyone deciding that it should.

The obvious objection is that you cannot negotiate protection for a programme you have not designed. Most organisations we talk to sit somewhere between a proof of concept and a plan, and few can say with confidence which agents they will run in three years, on whose platform, at what volume.

You do not need to know what you will build to negotiate the structure you will build it under. Rate certainty for the term, protection on the consumption rate as well as the unit price, notice before terms change, spend ceilings, and the right to re-baseline once your usage profile settles are protections against uncertainty rather than against a specific plan. They are worth more when the plan is unclear, not less, because they cover the range of outcomes instead of one point on it.

What matters more than knowing your roadmap is knowing when your next negotiation is. Whatever it is nominally about, a RISE renewal, an S/4 business case, a SuccessFactors extension, it is the vehicle. Consumption terms get set in agreements ostensibly about something else, which is how the exposure is created and equally how it gets fixed. The organisations that end up well protected are rarely the ones with the clearest AI strategy. They are the ones who recognised the deal in front of them was the moment to ask.

In the meantime there is work you can do without SAP's cooperation. Inventory your integrations, flagging anything non-published or feeding an autonomous process. Find every consumption schedule you are party to and put it through proper commercial analysis, not just a read. Establish which dependencies sit on promotional terms that expire. And if your perpetual estate is in play because of the EU commitments while your cloud position is being set at the same time, treat them as one negotiation rather than two. The leverage you hold on one is the leverage you can spend on the other.

This is the work Precipio does. We are an independent SAP strategy and licensing advisory, and we work with SAP customers in the New Zealand market, so the local context is familiar ground. We take no commissions from SAP and none from the integrators we might recommend, so the advice is shaped by the outcome you need and by nothing else.

Sign up to our insights on SAP licensing, commercial strategy and deployment, and tell us which areas you are focused on so we can send you the ones that matter. If you would rather talk it through against your own estate, get in touch and we will make the time.