RISE with SAP Add-On Licensing: Key Questions to Ask SAP

"What specific services consume BTP credits in our proposed RISE configuration, and what is the per-unit consumption rate for each?"

SAP's proposals typically specify total BTP credit allocation without defining the activities that consume those credits or their consumption rates. Without this information, it is impossible to assess whether the included allocation is adequate. If SAP cannot provide this, it is a strong signal that the included allocation is insufficient for your actual integration needs.

"If we exceed the included BTP credit allocation during the contract term, what is the rate for additional credits, and is that rate contractually fixed?"

The rate for top-up BTP credits is one of the most commercially consequential terms in a RISE agreement. SAP's default is to leave top-up pricing as "prevailing list price at time of purchase" — meaning they can charge whatever they want when you are mid-contract and dependent on the platform. Require a fixed top-up rate as a percentage of your original contracted price, stated in the Order Form.

"Do unused BTP credits carry over at the end of each subscription year, and if so, for how long and under what conditions?"

The standard RISE contract does not include BTP credit carryover rights. Credits that are unused at year-end expire. For enterprises in the early phases of deployment, when BTP integration is still being built out, this means paying for credits you cannot yet use. Carryover rights are achievable through negotiation but must be explicitly written into the Order Form.

"Can you provide consumption benchmarks from comparable deployments — similar industry, similar user count, similar integration complexity — to validate that the proposed credit allocation is adequate?"

SAP will typically resist providing benchmark data, citing customer confidentiality. A refusal to provide any benchmark data, however, is itself informative: it means you should assume the proposed allocation is likely insufficient and model your own consumption before committing. See our cost optimisation article for consumption modelling guidance.

"For each optional module in the proposal (Signavio, SAC, Datasphere, etc.), what is the exact pricing metric, the unit rate, the minimum commitment, and the escalation mechanism at renewal?"

Optional modules are almost always presented with bundled pricing that obscures the per-unit economics. You need the exact metric (per user, per process, per document) and the rate for each metric to evaluate whether the module is appropriately sized and priced, and to identify what overage looks like in practice.

"Is Signavio priced on a per-active-user basis, a per-process-transformation basis, or another metric, and how does SAP define each of those metrics in the contract language?"

Signavio's pricing metrics are defined in the contract in ways that can be interpreted broadly by SAP at renewal. "Active user" definitions and "process transformation" counts are subject to SAP's measurement methodology, which consistently favours higher counts. Understanding the exact definition before you sign is essential to avoiding overage claims based on expanded interpretations post-signature.

"If we choose not to renew an optional module at the end of its initial term, what is the process, notice period, and commercial consequence?"

SAP's contracts frequently include auto-renewal provisions for optional modules that renew at prevailing list price unless the customer provides written notice of non-renewal within a defined window — typically 60-180 days before renewal. If you miss that window, you are committed to another year or more at an escalated rate. Understanding the notice mechanism and building it into your internal contract management calendar is commercially critical.

"What is the renewal price escalation cap for each optional module, and is that cap contractually guaranteed or advisory?"

SAP's standard contracts include language that allows renewal price increases within a defined cap — but the cap is often high (5-8% annually), and "advisory" caps that are not contractually binding provide no genuine commercial protection. Require that any price escalation cap for optional module renewals is stated as a contractually binding maximum in the Order Form, not a stated intention subject to market conditions.

"What third-party systems in our proposed integration landscape will generate digital access obligations, and what is the per-document rate for each document type (Order, Delivery, Invoice, Material)?"

SAP must be able to identify which of your planned integrations create digital access exposure and at what per-document rate. If they cannot specify this before signature, demand that they conduct a document volume analysis as a condition of contract engagement. Our indirect access advisory service provides this analysis independently.

"Is a flat-fee digital access package available that covers our documented document volume, and if so, what are the terms and overage rates above the included entitlement?"

Flat-fee digital access packages remove the unbounded cost exposure of per-unit pricing. SAP does offer these, but they are not presented in standard proposals — they must be requested. The negotiation centres on your documented volume, a reasonable buffer, and a defined overage rate that applies to volumes above the flat-fee entitlement.

"On what basis has the proposed user type split (Professional, Limited Professional, Employee) been determined, and can you provide a role-by-role classification breakdown for validation?"

SAP's proposed user classification is almost always weighted toward Professional users — the highest-priced tier. Without a role-by-role breakdown, you cannot validate whether the classification reflects your actual operational user base. Demanding this breakdown, and then conducting an independent classification review, routinely identifies 15-30% reclassification opportunity.

"If our USMM measurement post-go-live identifies a different user count or user type distribution than the contracted baseline, what is the commercial process for addressing the difference?"

The measurement reconciliation process is the mechanism SAP uses to convert compliance gaps into additional licence fees. Understanding the process before you sign — including measurement timelines, dispute procedures, and the commercial treatment of user type reclassification — positions you to manage the first post-go-live measurement from a position of preparation rather than surprise.

"What is the base renewal price for the RISE subscription at the end of the initial term, and is that price a fixed amount, a percentage escalation from original pricing, or subject to prevailing market rates?"

This is the question SAP most consistently refuses to answer with commercial certainty. "Subject to prevailing market rates at renewal" means SAP can price the renewal at whatever they choose, relying on your switching costs to prevent departure. Require renewal price certainty — either a fixed renewal price or a capped escalation from original pricing — as a contractual provision, not a verbal assurance.

"If our business grows during the contract term and we exceed contracted user counts or BTP credit allocations, what commercial process governs the expansion, and are expansion prices pre-defined?"

Growth scenarios that trigger mid-contract expansion conversations are opportunities for SAP to extract premium pricing from a committed customer. Pre-defining expansion pricing in the original contract — at rates that represent a defined percentage above or in line with original committed rates — prevents this dynamic and gives you commercial certainty for scaling decisions.

"What is included in the SAP Enterprise Support tier within RISE, and what specific services are excluded that would require a Premium Plus upgrade?"

Enterprise Support is packaged in a way that creates a clear path to Premium Plus upsell. Understanding precisely what is and is not included — Technical Quality Manager access, Mission Critical Support SLAs, dedicated operational support engineers — allows you to evaluate whether the premium tier justifies its cost increment for your specific deployment context. Our support cost reduction service provides this analysis independently.

"Who owns the data within the RISE cloud environment, and what are our rights to data portability, data extraction, and data deletion upon contract termination?"

Data sovereignty and portability rights are frequently underspecified in RISE contracts. SAP's standard terms include data portability provisions, but the timelines, formats, and costs associated with data extraction upon termination are important to understand before commitment. A contract that makes data exit operationally difficult or prohibitively expensive strengthens SAP's negotiating position at every subsequent renewal.

"Can we receive a copy of the complete proposed Order Form and all associated T&Cs, support maintenance schedules, and service descriptions at least 30 days before the proposed signature date?"

SAP's standard practice is to provide complete contract documentation very close to the proposed signature date, under the pressure of a closing deadline. Requiring a 30-day review window for all contract documentation — not just the commercial summary — is a reasonable and professionally standard request that SAP should accommodate for any enterprise-scale commitment.

"Please provide a full Bill of Materials with component-level pricing for every product, metric, volume, and unit price in the proposed agreement. This is a condition of our engagement."

This is not strictly a question but a demand. It belongs in this list because SAP consistently tries to avoid providing it. The full BoM is the starting point for every meaningful RISE commercial analysis. See our negotiation strategies article for the full tactical approach to extracting the BoM from SAP's commercial team.