It's just software. What's there to negotiate?

"It's just software. There's nothing to negotiate." It is a reasonable thing to think. Cloud has made SAP feel like any other subscription: pick the service, agree a price, sign. The paperwork looks standard, the legal team clears it, and everyone moves on to the part that feels like the real work, the implementation.

Two things are true at once, and holding both is the point of this piece. SAP, like any vendor, writes its agreements to protect its own commercial position. That is legitimate and expected. And customers, treating cloud purchases as routine procurement, rarely bring the commercial scrutiny these agreements deserve. Unplanned cost lives in the gap between those two facts, and in our experience it is a wide gap and it can impact the long term success of SAP capabilities in your organisation.

You do not have to take our word for it. SAP publishes a sample.

You do not have to take our word for it. SAP publishes a draft of its cloud terms which in our experience is reasonably accurate, and among them is a sample partner agreement set for test, demonstration and development services, marked "not for signature." The example we refer to here was the version published and available on SAP's website as at 06 August 2026; published terms change over time, which is rather the point. The specific numbers in a sample are not what matters, and they are not what a customer signs. The structure is what matters, because the structure is what carries, unchanged, into the commercial agreements customers do sign.

Take one line from those published terms. On changes to the agreement, SAP reserves the right to "change any or all parts of this Agreement," and provides that "if Partner does not terminate within such period, the changes are deemed to be accepted by Partner." Read that again. The default is not that both parties agree a change. The default is that the change stands unless you actively object inside a short window. That single clause tells you most of what you need to know about where the terms sit.

Read it structurally and the partner agreement example puts almost every lever that determines the cost on SAP's side of the table.

SAP can change how much of your allowance a service consumes. The rate that converts your actual use into units drawn down is SAP's to revise. Lift it, and the same activity, unchanged on your side, consumes more.

SAP can change what each unit costs. The fee is SAP's to amend, and the overage rate moves with it. So two separate levers sit with the vendor: how fast you consume, and what each unit of consumption costs.

What you do not use, you lose. Unused capacity is forfeited at the end of each period rather than carried forward.

Put those together and the picture is clear. You are agreeing, in advance, to a rate of consumption and a price you do not yet know, on terms that can move, governed by lists you do not control. That is the constraint, and it is visible in a public sample.

The uncomfortable part is that the same structure already sits inside commercial agreements that organisations have signed, reviewed and filed. We see it regularly. And those agreements went through legal review, and legal review did its job. It confirmed the contract was enforceable and the clauses were sound. That is a genuinely different question from what the contract will cost you and how that cost can move. A clean legal sign-off tells you the agreement is well constructed. It does not tell you it is well priced, or that the price will hold. Legal and commercial review answer different questions, and in most cases only one of them was ever asked.

The AI dimension sharpens this. Right now, AI use cases in most SAP estates are still maturing, and AI is rarely the centre of the deal being negotiated. That is exactly why the pricing structure around it slips through. Nobody scrutinises the terms governing something that is not yet material. But AI is, on almost every roadmap we see, a large and significant future spend area. Accepting a structure like this for it now, while it is small and unwatched, locks in the terms for the one area most likely to grow, before you have any leverage over it.

Want to know whether a structure like this is already in your own agreements? We run a short commercial review that reads them the way SAP wrote them.

The sample shows the shape. Here is where it bites, and what to negotiate.

Cloud Platform Enterprise Agreements, CPEA or BTPEA, run on that same structure. You commit to a pool of credits, usually at a discount, and services draw them down at a per-unit rate. The terms typically allow both levers to move: the per-unit rate can rise, so a service consumes more credits for the same work, and the price of each credit can rise, so every credit costs more. Nothing forces SAP to use both, but the agreement usually leaves it free to, and if they move together they compound. The exposure is real whether or not it is ever applied, which is why it is worth closing off in the agreement rather than assuming it will sit unused.

The movement that runs hardest against the logic of the model is a rising credit price. We have seen a credit price lifted year on year while a customer sits on unused credits: consumption flat, headroom available, cost still rising. A consumption model is meant to sell you one thing above all, that you pay for what you use, so this is exactly what the agreement should be pinned down to prevent.

If an increase is warranted at all, it should be capped at CPI and confined to one lever, not both. In our view the per-unit rate can move within a CPI cap while the credit is protected as a stable unit of account, because that keeps the model honest: stable consumption, stable cost. Holding the rate and indexing only the credit is a defensible alternative. What should not stand is both moving, uncapped, year after year.

Many customers buy for today and assume the standard increase in their contract will govern the next purchase. It often does not. We see published list prices (i.e. BTP Cost Calculator) move materially year to year, sometimes above 6% in a single year, and the increase compounds. That drift stays invisible until the moment it matters: when you want more of the same, or when you expand in line with your roadmap, and find the business case has moved out from under you.

This is the investment cycle piece seen from the buying side. If your medium-term requirements were never disclosed and priced at the start, the drift lands on you later, at the worst time. A commitment that felt almost certain stalls. Momentum you paid dearly to build leaks into confusion and frustration, and the confidence to proceed drains with it. In the cycle, this is precisely where an organisation slides out of the honeymoon and into hesitation.

The shift from perpetual to subscription is, for some organisations, a generational chance to reset the commercial baseline rather than carry old assumptions forward. The choice within the subscription world matters just as much, and it is not specific to any one product. The same discipline applies to Ariba, to SuccessFactors and across the wider cloud portfolio.

Where consumption is predictable and stable, an always-on deployment such as Integration Suite is a good example. A subscription with a capped uplift can buy cost certainty and often better value. It's public knowledge that CPEA discounts are capped at 40%, and in some cases SAP justifies less. A subscription indexed to CPI can beat a consumption deal whose discount is limited. Where demand is variable or seasonal, the reverse can hold: consumption lets quiet periods offset the busy ones, and the saving can outweigh the lower discount.

It is not clear-cut. Early CPEA engagements priced Integration Suite very low before SAP ramped it up the per unit cost, a reminder that yesterday's attractive rate is not a promise. Every situation needs modelling on your own patterns of use, now and over the medium term. And when you renegotiate or restructure, measure what you stand to lose: favourable price holds from your original agreement can quietly disappear in the new one unless you negotiate to keep them.

Customers are, understandably, excited when a significant incentive arrives from SAP or a hyperscaler to support a project. Originally these sat on top of the best available price, offered to accelerate a decision. We now see something more concerning, with customers so pleased by an incentive that they compare theirs against other customers' rather than against their own future cost.

Here is the mechanism to watch. An incentive can balance the proposal across the first term, typically three to five years, while the underlying discount beyond that horizon stays thin. Anchor on five-year TCO and SAP will optimise for exactly that window, with the incentive masking a weak long-term rate. It surfaces at renewal, when the incentive is gone and the higher base remains, then compounds. The question to ask of any incentive is not how large it is, but what it is really buying, and what the number looks like the day after it expires.

Every lever above is negotiable, but only while you hold the leverage to move it, and leverage follows the investment cycle. It is highest at the project and implementation stages, when SAP wants the deal and the terms are still being shaped. It fades through the honeymoon. By the time you reach retain or exit, a renewal is just that, a renewal. Change the terms then and you are not renewing, you are renegotiating, from a weaker position, carrying every lever we have described. The structure in the sample is built for exactly this: on renewal, the consumption rate, the fee and your forfeiture window are all SAP's to move at once.

Organisational momentum peaks during the project. Negotiating leverage is strongest before the deal is signed. 

Which is why the most expensive habit is to sign the large agreement now and hope to fix it in a smaller upsell later. The upsell does not restore your leverage. It spends what little you have left on a fraction of the scope. The moment to negotiate the caps, the price holds, the future requirements and the subscription-versus-consumption choice is the significant purchase in front of you. Do not waste it.

So, is there anything to negotiate? There is a great deal, and the discipline that captures it is not complicated, though it has to happen before you sign.

Disclose your medium-term requirements and put them on the table, so the agreement is priced for where you are going, not only for where you are. Model your consumption and both cost levers, so you see the exposure before it arrives. Separate the commercial review from the legal one, and make sure someone is actually asking the commercial question. Cap and confine price movement: CPI on a single lever, rather than open-ended increases on several. Protect the price holds worth keeping and read every incentive for what it costs you once the first term is over.

Most of this is invisible from inside the excitement of a new project, which is exactly why it gets missed, and exactly why it pays to have people alongside you who know which items to pursue and, as importantly, how to create the environment in which SAP agrees to them. When you hold the leverage, spend it well.

The best part, get this right and watch your SAP program accelerate and deliver value for years ahead.