The 8 contract building blocks that determine costs and flexibility

The Anatomy of an SAP Contract.

SAP contracts are more than cloud hosting. They are multi-layered commercial constructs with levers that require active governance.

8
Contract building blocks
4
RISE options
100%
public SAP sources

How a RISE contract is structured

A RISE with SAP contract consists of multiple layers. The Order Form forms the individual core — it references standard documents that SAP publishes on the Trust Center. These reference documents define SLAs, responsibilities and scope. Both levels are relevant for sound contract governance.

Contract structure — layer by layer

Order Form Customer-specific: Solutions, System Sizing, Software Subscriptions (formerly: licences) and their conversion dates, ACV, term
Schedules A: Cloud Supplement · B: Support Policy · C: Service Level Agreement · D: Data Processing Agreement · E: General Terms & Conditions
Appendices System Landscape & Sizing · Pricing & Commercial Terms · Transition Plan / Timeline
Reference documents (SAP Trust Center) Service Description Guide (SDG) · Roles & Responsibilities · Enhanced Operations Service Description

The 8 building blocks in detail

Each area contains governance-relevant aspects that should be actively managed.

📈
Block 1
ACV & Commercial Commitment

The Annual Contract Value (ACV) is the customer's annual payment obligation across the full contract term. It is the central financial figure of a RISE contract and the basis for many derived values, among them BTP credits, package budgets and maintenance reduction.

Understanding the ACV mechanics Upward adjustments are possible and expected by SAP. If additional usage is not reported, SAP can charge a surcharge of up to 30%. Downward adjustments are often provided for in the contract but limited in practice: credit frequently cannot be carried into other contract years, or only in part.
Discuss ACV optimisation → Schedule a call
📋
Block 2
Order Form, Sizing & Software Subscriptions

The Order Form is the core of the contract. It defines the solutions booked, the system sizing (tiers, vCPU, RAM, storage), the contractual term and the software subscriptions. In a migration from on-premise, existing licences are converted into cloud subscriptions with defined conversion dates.

Sizing and subscriptions carry equal weight System sizing is dimensioned at contract signature based on the requirements known at that time. Downsizing options during the term provide room to adjust. Equally relevant: the software subscriptions and their conversion dates. Exactly when a given licence turns into a subscription has a significant effect on annual cost and should be planned deliberately.
Review sizing and subscriptions → Schedule a call
Block 3
SLA & Availability Governance

SAP defines system availability at several levels, depending on the RISE option and the tier type (production vs. non-production). The standard SLA is 99.5% (PCE) or 99.7% (RISE). Upgrades to 99.9% are available.

Is the SLA sufficient, and how do you govern without penalties? SLA penalties (service credits) are marginal in practice. They do not work as a commercial lever. The more relevant question is whether the agreed availability is sufficient for your business processes, and how to govern a contract when financial penalties are not the driver. That calls for operational governance: regular monitoring, clear escalation paths and defined expectations towards SAP.
Set up SLA governance → Schedule a call
🛡
Block 4
Disaster Recovery

Disaster recovery is not automatically part of RISE. DR has to be ordered explicitly as a separate SKU, with different RTO/RPO options that differ considerably in cost and recovery time.

Differentiate by business criticality RTO options (4h vs. 12h) and RPO (0 to 90 minutes) differ considerably in cost. Differentiating by the actual business criticality of each system allows the DR investment to be allocated deliberately, with recovery capability that matches each system.
Discuss DR strategy → Schedule a call
🔧
Block 5
Maintenance, Upgrades & Downtime

SAP defines maintenance windows per system tier. These windows affect availability and need to be reflected in project planning and in day-to-day operations.

Upgrades as a planning factor Four hours per month per tier is the standard for planned maintenance. Additional downtime for upgrades, security patches and kernel updates is often left out of the project timeline. That creates conflicts in critical project phases.
Optimise maintenance planning → Schedule a call
Block 6
BTP & Cloud Platform Services

SAP Business Technology Platform (BTP) is an integral part of every RISE contract and at the same time the area with the greatest governance need. BTP is billed through CPEA credits (Cloud Platform Enterprise Agreement).

Why BTP deserves particular attention CPEA credits are calculated at roughly 1% of net ACV (minimum EUR 10,000, maximum EUR 20,000 per year) and have fixed validity periods. At the same time BTP is the central platform for extensions, integration and innovation. Systematic monitoring makes sure the credits are spent on current and planned initiatives.
Set up BTP governance → Schedule a call
💰
Block 7
Package Budgets, Funding & Maintenance Reduction

Many RISE contracts include package budgets for migration, implementation or innovation, often split into phases. Maintenance reduction additionally governs which share of existing on-premise maintenance cost is credited against the RISE contract.

Allocate budgets in time Package budgets have defined validity periods, typically 24 months from contract start. Allocating them to concrete initiatives early makes sure the funds are used as planned. Maintenance reduction has a contractually defined cap. The conditions for full crediting vary, and often the migration has to be completed within a specific window.
Discuss budget governance → Schedule a call
🚪
Block 8
Exit, Renewal & Transition

RISE contracts have defined terms (typically 3 to 7 years), notice periods and renewal conditions. Several transition options provide flexibility, provided they are reviewed in time.

Start 12 to 18 months before contract end Structured renewal preparation starts 12 to 18 months before the contract ends: review market options, build a negotiating position, assess transition scenarios. The earlier the process starts, the more room there is to shape the outcome.
Plan renewal strategy → Schedule a call

RISE options overview

Contract components and scope vary depending on the chosen option.

Base

Base Option

Standard S/4HANA Cloud Private Edition. Cloud infrastructure, basic support and defined SLAs.

Premium

Premium

Extended services, higher SLAs, additional cloud features and enhanced support.

Premium Plus

Premium Plus

Maximum scope with Clean Core Enablement, extended BTP services and SAP Business AI.

Tailored

Tailored Option (PtO)

Individual sizing, tailored configuration. For complex landscapes with specific requirements.

Discuss your contract building blocks in detail

In a confidential conversation, we assess together which areas are relevant for your situation.

Schedule a contract conversation

What is where? — Quick Reference

All reference documents are publicly available on the SAP Trust Center.

Your question Look up in Source
Which SLA applies to my system? Service Description Guide (SDG) SDG v9 →
Who does what for maintenance & updates? Roles & Responsibilities R&R v3 →
What is included for BTP? Cloud Supplement + Pricing & Packaging Supplement v11 →
How does Disaster Recovery work? Roles & Responsibilities + SDG R&R v3 →
What notice periods apply? General Terms & Conditions (GTC) SAP GTC →
How is my data protected? Data Processing Agreement (DPA) Trust Center →
How is the ACV defined? Order Form + Cloud Supplement Supplement v11 →

Next step: Platform or Govern

If you want to govern your contract landscape yourself, start with the Platform. If accountability and ongoing governance are required from day one, explore Govern.