You Sign One Page. You Agree to 25 Documents.

Edition 6 of Unfiltered: SAP Public Cloud — published on LinkedIn on 20 September 2026. This is the canonical sapperment edition.

The Good, The Bad & The Ugly of buying SAP Public Cloud.

You do not sign one contract with SAP.

You sign an order form — and that order form incorporates a stack of other documents by reference. SAP’s own sample cloud order form lists six, the order form itself among them. [1]

Six is the floor, not the count. The list multiplies on contact with a real purchase: each subscribed service carries its own service description, each product family its own supplement, bundled components their own terms, AI capabilities their own, and a Master Cloud Customer Agreement its own schedules. In the stacks I have negotiated, a Cloud ERP purchase with a handful of adjacent services passes twenty-five documents before anyone has read a page.

Count your own. That register is decision four below, and it is the only way to know which number applies to you.

That is not a legal technicality. It is the commercial architecture of the deal.

Public Cloud promises a simpler starting point.

Choose the capabilities your business needs. Identify the people who need access. Agree a price per user, per month.

That is a commercial model a leadership team can discuss without first attending a licensing workshop.

But the questions become more interesting when the business changes.

What happens when you need fewer users? When responsibilities move between teams? When you add another company? When the capability you thought was included turns out to have a separate limit?

The user price starts the conversation. The contract decides how it continues.

The Good: PUPM makes the starting point clearer

SAP’s current Public Cloud approach to direct human access uses per-user-per-month pricing: PUPM. Different user types provide different rights, depending on the packages purchased. Finance, supply chain, operational work and self-service do not all require the same entitlement. [2]

That gives the buyer a useful starting point: connect the subscription to the work people perform.

Which capabilities does the finance team need? Which employees only approve requests or record time? Which roles require broader operational access?

Those are business questions. They should shape the quotation.

There is one distinction worth making immediately: a user is not simply someone who logged in this month. SAP’s July 2026 service-use descriptions define the relevant user metric through authorisation to access the service. Low activity alone therefore does not establish a lower licence requirement. The same document retains FUE-based GROW offerings, so the actual product and agreement still determine which model applies. [3]

The improvement is an easier basis for discussing scope and cost. It still requires an accurate picture of the business.

SAP also publishes its standard agreements, service descriptions and pricing information. Buyers have material to examine before committing.

Complex does not mean hidden. But public does not mean read.

The Bad: The monthly rate is only one part of the economics

“Per user, per month” describes how a price is expressed.

It does not, by itself, tell you the billing frequency, contract duration or when you can reduce the commitment.

SAP’s published Supply Chain pricing illustrates this clearly: monthly user prices appear alongside contract durations of one to three years and automatic renewal. A monthly price and a multiyear commitment can coexist quite comfortably. [4]

The customer needs to distinguish four things:

• The rate: what each purchased user type costs.
• The scope: which capabilities and additional entitlements that purchase provides.
• The commitment: the quantities and duration you agree to.
• The change rights: when and how you can adjust them.

Even the advertised price needs context.

SAP’s US Finance Base page states a minimum of 15 users while displaying its headline rate for a band of 25–39 users. The minimum quantity and the displayed price band are different conditions. You cannot simply multiply the advertised rate by whichever headcount you choose. [5]

Different paragraph. Same money.

A lower unit price can also become an expensive achievement if securing it requires buying substantially more capacity than the business needs.

The negotiation should therefore test the complete commitment:

What will we spend over the initial term? What happens at renewal? What will additional users cost? Which capabilities, capacity or consumption sit outside the user subscription?

Then test the downside.

If the business needs 80 users next year instead of 100, what can actually change, and when?

That is a scenario to negotiate before signature.

What the rate does not decide: a worked example

Two buyers. Same business, same advertised rate, same three-year term. To keep the arithmetic about structure rather than price, call the advertised per-user rate 1.0 rate unit per user per month. No figure below is an SAP price.

Buyer A takes the headline. One hundred users, the advertised band, automatic renewal, no change rights negotiated.

Buyer B buys the business it has. Sixty users, plus a negotiated right to add up to forty more at the original rate. B also negotiated a right to reduce quantity at renewal — that right sits outside the three years below and contributes nothing to any number here.

Then the business changes, as it does.

If it grows to one hundred real users. A has already paid for them: 1,200 rate units a year, 3,600 across the term. B adds forty in year two at the protected rate: 720, then 1,200, then 1,200. That is 3,120. B arrives at exactly the same place for thirteen per cent less, and the difference is not a discount. It is a clause.

If it only ever needs seventy. A still pays 3,600, because the thirty entitlements it never used cannot be released mid-term. B pays 720, then 840, then 840. That is 2,400, one third less. Demand never fell in either scenario; A simply committed to a hundred and the business arrived at seventy.

Notice what is doing the work. The saving comes from committing to the quantity the business actually had. The price protection does not create it — it stops the saving being taken back when the forty are added at whatever the rate has become by then.

Flexibility is rarely free, so assume B paid a premium per user for those rights. The question is what premium is worth paying. In the growth case B stays ahead until the premium reaches about fifteen per cent. In the overbuy case it stays ahead until about fifty per cent.

That is the whole argument in one number: the change rights are worth more than the rate wherever the committed quantity and the real one diverge.

The Ugly: One business service can carry several sets of rules

From the business’s perspective, this is one ERP investment.

Contractually, the commitments are distributed across documents: the order form, product terms, service descriptions, support arrangements, SLA, data-processing terms and general conditions. SAP itself describes the cloud service description as a product-specific collection of documents. [1]

The risk comes from reading one document and assuming it answers the whole question.

Take availability

SAP’s general cloud SLA, version August 2023, specifies 99.7% monthly production availability. Yet the August 2024 GROW Public Edition supplement replaces that target with 99.9% for the covered core base and premium service. Bundled cloud services are excluded from that uplift. [6][7]

Reading only the general SLA would miss the product-specific improvement. Applying the improved target to everything bundled into the purchase would overstate the coverage.

Then there is the remedy. Under that general SLA, a credit requires a documented claim within 30 business days after the relevant month ends. The availability target, exclusions and claim procedure need to be read together. [6]

The business question is therefore more useful than the headline percentage:

Which part of our process is covered by which commitment, and who acts when it fails?

The same discipline applies at renewal

Do not assume that every new document published online changes your existing agreement. Equally, do not assume that the original document remains applicable forever.

For example, SAP’s July 2026 Public Edition/GROW service-use descriptions distinguish the order’s effective date from actively renewing subscriptions, for which they specify the then-current service-use description. That makes renewal a moment to review scope as well as price. [3]

Read the incorporation language, update provisions and order of precedence in your own agreement.

A negotiated sentence may change the standard position. An exception may apply to one service but leave another untouched.

That is why storing the signed order form alone is insufficient.

Five decisions before the signature

1. Buy the rights people need.

Map real processes and responsibilities to the applicable user types and packages. Check additional entitlements and their limits. A package name is the beginning of that assessment.

2. Calculate the whole commitment.

Build the cost across the initial term: user quantities, applicable rates, separately charged components and agreed increases. Make the renewal assumptions visible. Keep implementation and operating costs in the wider business case.

3. Test growth and contraction.

Model three situations: more users, fewer users and a different mix of capabilities. Establish what can change during the term, what requires renewal and what requires a new agreement.

4. Establish which wording controls.

Create a register of the incorporated documents and save their applicable versions. Identify product-specific overrides, customer-specific amendments and the rules for later updates.

5. Give the agreement an owner after signature.

Assign responsibility for quantities, entitlements, notice dates, renewal preparation and service-credit claims. Connect procurement, finance, the application owner and the business. Put decisions into a calendar early enough to act.

My take

Public Cloud deserves credit for making the commercial starting point more understandable.

PUPM helps leaders relate the subscription to people and capabilities. It also makes the next questions harder to excuse leaving unanswered.

Which rights are we buying? Which quantities are we committing to? What flexibility do we retain? Who will check whether the investment delivers?

I would bring those questions into the negotiation alongside the discount.

A good agreement should support the business you expect to run, and give you understood options when that expectation changes.

A reference for the people who sign

For the vocabulary behind these decisions, keep the sapperment contract reference nearby:

SAP Contract Terms A–Z — what each term means and how negotiable it is

Use it to prepare the questions. Resolve them against the documents governing your agreement.

Beyond the signature: two further reads

The contract establishes the commitment. These two perspectives follow what happens next.

Michael Crawley · sapperment · 2026

When Does Customer Success Become Value Realisation Rather Than Adoption Reporting?

High licence consumption can look reassuring without demonstrating a business result. Michael explains how to establish what changed, quantify its value and help the customer articulate the outcome. A useful next step after asking whether you bought the right entitlements.

Katarina Lantuh · sapperment · 2026

The Offer Changed. Did the Business?

A new commercial model has consequences throughout Quote-to-Cash. Katarina examines how pricing decisions travel through contracts, fulfilment, billing, incentives and customer expectations. Launching the offer is only the beginning.

The rate is the part of the deal that is advertised. The commitment and the change rights are the part that decides what you pay. One is on a web page; the other is in documents you have to ask for, read and keep.

Buy the second one as carefully as you compare the first.

Andreas BORN · sapperment · 2026

Notes and sources

What the argument rests on. One measured pair: SAP’s general cloud service-level agreement and the GROW Public Edition supplement state different availability commitments for the same service, and the supplement excludes bundled cloud services from the improvement [6][7]. Two published documents, one purchase. The answer sits in the more specific one, which is not the one most buyers read. Everything else here is either document structure, which is checkable in the sources below, or illustration, which is labelled as such.

What is illustration. The two-buyer comparison uses a normalised rate unit and invented quantities. It contains no SAP price and predicts no outcome. It exists to show how the arithmetic behaves when change rights differ. Neither scenario models falling demand: in both, the business needs at least sixty users throughout, and the second is a case of over-committing rather than shrinking.

How sensitive the illustration is. The thirteen and thirty-three per cent gaps assume both buyers negotiated the same unit rate. If Buyer B paid a premium for flexibility, B stays ahead up to roughly a fifteen per cent premium in the growth case and roughly fifty per cent in the overbuy case. Both thresholds assume that premium applies to every one of B’s user charges, with no separate option fee and no other cost differences. The gap narrows; the direction does not change within that range, which is the point. Two constructed scenarios show how the arithmetic behaves; they say nothing about how often each one occurs.

On the dated examples. The service-level figures cited are the versions published at the dates named. They illustrate how documents in one stack interact, not a universal statement of today’s entitlement. Your offering, jurisdiction, document versions and signed agreement determine what actually applies.

1. SAP — Agreements, Trust Center: the cloud-contract building blocks and the document families. https://www.sap.com/about/trust-center/agreements.html
2. SAP Learning — Understanding subscription licensing: per-user-per-month pricing and user types. https://learning.sap.com/courses/exploring-sap-cloud-erp/understanding-subscription-licensing_b664e32d-b9fb-487f-8f64-5f19894d3d9f
3. SAP — S/4HANA Cloud Public Edition and GROW with SAP, Service Use Descriptions, v7, July 2026: the user metric defined by authorisation; FUE-based GROW offerings retained; effective date against actively renewing subscriptions. https://assets.cdn.sap.com/agreements/product-use-and-support-terms/service-description-guides/sap-s4hana-cloud-public-edition-and-grow-with-sap-s4hana-cloud-service-use-descriptions-english-v7-2026.pdf
4. SAP — Supply Chain pricing: monthly user prices alongside one to three-year durations and automatic renewal. https://www.sap.com/products/scm/pricing.html
5. SAP — Financial Management pricing, US: minimum of 15 users with the headline rate displayed for a 25–39 band. https://www.sap.com/products/financial-management/pricing.html
6. SAP — Service Level Agreement for SAP Cloud Services, v8, August 2023: 99.7% monthly production availability, exclusions, and the credit claim within 30 business days. https://assets.cdn.sap.com/agreements/product-use-and-support-terms/cls/en/service-level-agreement-for-sap-cloud-services-english-v8-2023.pdf
7. SAP — GROW with SAP S/4HANA Cloud supplement, v8, August 2024: 99.9% for the covered core base and premium service, bundled cloud services excluded. https://assets.cdn.sap.com/agreements/product-use-and-support-terms/cls/en/grow-with-sap-s4hana-cloud-supplement-english-v8-2024.pdf
8. sapperment — SAP Contract Terms A–Z: 43 terms, each with its own page and sources, plus the document index.

Sources checked on 18 September 2026.

sapperment is independent and not affiliated with SAP SE. All contractual mechanics cited are from SAP’s publicly published documents. This edition provides a commercial perspective, not legal advice.