RISE Contract Checklist: Critical Clauses and Terms Every SAP Customer Must Negotiate

rise contract checklist

RISE with SAP consolidates software licenses, cloud hosting, and support into one SAP-controlled subscription. This one-stop bundle simplifies billing – but it also amplifies your risk if you overlook the fine print.

Every term in a RISE contract can impact your costs, flexibility, and compliance. Before you sign a RISE with SAP agreement, scrutinize it clause by clause.

Below is a practical checklist of key terms and clauses to evaluate and negotiate in your RISE contract. Read our overview article, RISE with SAP Contracts: Negotiation Guide & Key Considerations.

Expert Insight: In RISE, every clause is a cost lever – or a trap. Treat the contract like source code: audit it line by line.

Core RISE Contract Components

A RISE contract isn’t a single document. It’s a package of components, each with its own terms and potential pitfalls. Make sure you obtain and review all of the following pieces:

ComponentDescriptionKey Risk Area
Subscription Order FormDefines your licensed usage (Full User Equivalents, or FUEs), the subscription fees, and the contract term length.Renewal uplifts; volume of usage risk if your needs change.
GTC (General Terms & Conditions)SAP’s master terms governing the contract (liability, termination, warranties, etc.).Potential lock-in provisions and limited termination rights.
Service Level Agreement & Service DescriptionDetails service levels for uptime, support response, and what services are included in RISE.Ambiguous remedies if SAP misses performance targets (SLA without penalties).
Data Processing Addendum (DPA)Covers GDPR compliance, data privacy, and data export terms.Data control and residency constraints.
Conversion Addendum(If you’re an existing SAP customer converting licenses) Outlines how existing licenses/maintenance payments are credited into the RISE subscription.Double payment risk if credits for your prior investments aren’t honored.

Each of these documents contains critical terms. Don’t assume any “standard” appendix is harmless – hidden restrictions often lurk in the attachments.

Negotiation Tip: Review every attachment in full. SAP often tucks key limitations or obligations into the annexes of a RISE deal. Nothing is “boilerplate” – read it or risk unpleasant surprises later.

1. Scope of Service & Included Components

Start by verifying the scope of services. Ensure the contract explicitly names every product and service you expect under RISE. This means listing the exact S/4HANA edition you’re getting (e.g. S/4HANA Cloud, private or public edition), the hosting model or provider (SAP’s datacenter or a specific hyperscaler like AWS/Azure), any included SAP BTP credits, and all tools or services for migration.

Avoid vague wording like “including (but not limited to)…” or “illustrative examples” of included components – if a component isn’t explicitly written in the order form, assume it’s not included in the price.

Equally important is clarifying who does what in the RISE scope. Does SAP handle the migration of your existing systems to the cloud, or is that on you (or a partner)? If the salesperson promised migration assistance or specific extras, get it in writing.

Roles and responsibilities should be unambiguous: for example, if a System Integrator will do the implementation or if SAP provides any migration factory services, the contract must reflect that. Never rely on verbal assurances when it comes to scope – put all expectations into the contract language.

Expert Insight: If it’s not in the RISE order form, it’s not included – no matter what the salesperson said. Insist that every promised service or component is listed in black and white.

2. Term & Renewal Uplifts

Pay close attention to the term length and renewal terms. RISE contracts typically run for 3 to 5 years. What happens at the end of that term is where costs can skyrocket.

Standard SAP wording often says the renewal will be at “then-current list pricing.” In plain English, that means SAP can charge whatever the official price is in a few years, potentially wiping out any initial discount and leading to a massive renewal uplift.

Negotiate protections up front for the renewal:

  • Cap the renewal increase – e.g. “price uplift not to exceed 3% per year.” This converts an unknown future price into a predictable, modest rise.
  • Require advance notice – e.g. 120 days minimum notice before renewal. This gives you time to push back or consider alternatives if SAP tries to raise rates or change terms.
  • Allow volume adjustments at renewal – Build in the option to revisit your FUE count or scope at renewal. Your business might shrink or grow; you want the ability to decrease users or switch components without penalty when renewing.

To illustrate the importance: if your initial deal was heavily discounted, you don’t want SAP to remove that discount at renewal.

For example, imagine your first term was priced at $2 million/year after a 40% discount off the list. If the contract simply says “renewal at the current list,” SAP could come back with a list-price bill (potentially 60–70% higher). Instead, lock in that the renewal price is tied to your current net price, only adjusting by the agreed cap.

Sample Clause: “Renewal pricing shall not exceed the prior year’s subscription fee by more than 3%.” This kind of clause guarantees a manageable increase and avoids a shockingly large uplift.

3. Lock-In and Exit Terms

One of the biggest risks of RISE is lock-in. SAP bundles everything, which is great until you try to leave.

The contract often stipulates that if you terminate early, you owe 100% of the remaining fees as a penalty – effectively, you’re locked for the full term with no way out except paying in full. Even after the term, if you don’t renew, you could lose access immediately. Negotiating exit terms is therefore critical.

Focus on securing:

  • Termination rights for cause – Ensure you can terminate the contract if SAP truly fails to meet obligations (e.g. repeated SLA violations) without paying the full remaining term. This gives you some escape hatch if SAP doesn’t deliver.
  • Defined exit assistance period – For end-of-term or early exit, negotiate an exit assistance window (60–90 days is common). This means SAP must continue to support you for a couple of months as you transition off RISE, so your business isn’t cut off overnight.
  • Data retrieval rights – The contract should guarantee that you can export your data (and not just raw data, but in a usable format) at no additional cost if you leave. Also, clarify how long SAP will retain your environment for data extraction after termination (for example, “environment remains accessible for 30 days post-termination for data download”).

Make sure the contract answers, “What happens after the contract ends?” Will you still have any access to your systems or data? Ideally, you want a clause allowing read-only access for a short time or a commitment that SAP will provide a full data dump. Without these, the day your contract ends, your lights go out.

  • Checklist – Exit Terms: Before signing, double-check that you have:
    • Termination rights for cause (serious breach by SAP).
    • A defined exit assistance period (e.g. 60–90 days of post-termination support).
    • Guaranteed data export in a usable format at no cost.

Expert Insight: Lock-in isn’t just financial – it’s operational. If your exit rights and post-termination access aren’t clearly spelled out, you’re effectively trapped. Make sure the contract lets you leave on your terms, not just SAP’s.

4. Co-Termination of Other SAP Products

Be wary of SAP trying to co-term your other SAP agreements with your RISE contract. It’s common for SAP to suggest aligning the end-dates of related products (like Ariba, SuccessFactors, SAP Analytics Cloud, etc.) so everything renews at the same time under the RISE umbrella. On paper, one renewal date for all SAP services sounds convenient – but it kills your flexibility.

If all products co-terminate, you lose the ability to drop or renegotiate one product independently. For instance, if you’re unhappy with SuccessFactors, you can’t threaten to non-renew it without jeopardizing your whole RISE ERP deal, because they’re tied together. SAP gains leverage while you lose it.

Negotiation moves:

  • Keep separate renewal cycles. Push back on contractual language that bundles other services into the RISE term. It’s usually better that, say, your HR cloud (SuccessFactors) or procurement cloud (Ariba) remain on their own contracts or at least separate schedules.
  • If you must co-term, carve out rights. If SAP insists on co-termination for a discount, negotiate the right to reduce the scope or remove a product at renewal without affecting the rest. Get that in writing.

Negotiation Tip: Don’t tie all your SAP products together. Co-terming everything under RISE may simplify paperwork, but it eliminates leverage. Keep at least one major product on its own cycle so you maintain the option to switch or negotiate it separately.

5. FUE Metrics and Role Mapping

RISE with SAP introduces a new metric called Full User Equivalents (FUEs) for licensing.

This is how SAP measures your usage instead of traditional named user licenses. It’s critical to understand and validate how your users translate into FUEs, because an incorrect mapping can inflate your costs significantly.

What to watch:

  • Understand the conversion: Ask SAP to show the math of how they calculated your FUE count. For example, SAP often says 1 FUE = 1 “Advanced” user, or 5 “Core” users, or 30 “Self-service” users. Ensure the contract documents the exact conversion factors being used for your user types.
  • Validate user roles: Review all the user categories in your environment (professional users, functional users, employees, developers, etc.) and confirm how each category counts toward FUEs. If SAP is assuming more high-level users than you actually have, they might be overstating the FUEs you need.
  • Avoid over-allocation: Sometimes SAP’s proposal might pad the FUE count “just in case.” Negotiate it down to what you realistically need, with a buffer for growth.

Include a clause for usage flexibility. Business needs change, and you don’t want to be punished for minor fluctuations:

  • For instance, negotiate a ±10% FUE allowance each year. This means if your user count goes a bit above your contracted FUE, you won’t be immediately out of compliance (and likewise, if it dips, you aren’t overpaying without recourse). This acts as an annual buffer for normal growth or seasonal variations, with true-up or down at renewal.

In summary, demand transparency on how FUEs are calculated and ensure it’s fair. Ideally, attach an exhibit to the contract listing the user roles and how they equate to FUEs. That way, there’s no ambiguity later.

  • Checklist – FUE and Users: Make sure the contract:
    • The document clearly lists all user types and how they convert to FUEs (the formula or table is documented).
    • Uses a realistic user count for pricing (challenge any FUE number that seems high for your organization).
    • Allows ~10% flex in FUE consumption above/below the contracted amount without immediate penalty.

Avoid double costs, RISE Migration Considerations for Existing SAP Customers: How to Transition Without Double-Paying or Losing License Value.

6. Infrastructure & Hosting Terms

Since RISE includes the cloud infrastructure (hosting) as part of the package, nail down those details in the contract.

You should know where and how your SAP systems will run, and what SAP’s responsibilities are for keeping them running.

Key points to clarify:

  • Hosting provider and location: The contract should name the hosting environment. Is SAP hosting your S/4HANA in its own data centers, or on a hyperscaler like AWS, Azure, or Google Cloud on your behalf? This matters for compliance and performance. If you have a preference or requirement (e.g., “must be hosted on Azure in the EU region”), get that explicitly in the agreement.
  • Responsibilities for maintenance: Define who manages what at the infrastructure level. Patching, updates, and backups – typically, SAP handles these under RISE, but ensure the contract states it. If your system needs a critical patch, SAP should be obligated to apply it promptly. Clarify the process for scheduled downtime, maintenance windows, and how/when you’ll be informed of changes.
  • Security and liability: With SAP running the infrastructure, push for clarity on security responsibilities. For example, if there’s a security breach or data loss on the cloud platform, does SAP take accountability? They might resist strong liability here, but it’s important to have language about security measures, breach notification, and support in remediation if something goes wrong.

Crucially, lock in the Service Level Agreements (SLAs) for availability and performance of the cloud environment:

  • Uptime commitment: Insist on a high uptime percentage. For instance, SAP may offer 99.5% by default; you might negotiate 99.7% or higher uptime monthly. Each .1% matters when you calculate downtime hours per year.
  • Service credits: The SLA should have teeth. If SAP fails to meet the uptime or other performance metrics, you should receive service credits or refunds. A promise of uptime means little if there’s no remedy. Make sure the contract spells out the credit calculation (e.g., X% of the monthly fee credited for each hour of downtime beyond the SLA).
  • Global coverage: If you have operations in multiple regions, ensure the SLA applies to all relevant data centers or has local region commitments, not just a vague global average.

Sample Clause: “SAP shall ensure a monthly uptime of at least 99.7% for the RISE services in all contracted regions. Failure to meet this SLA will entitle Customer to service credits equal to [specific %] of the monthly fee for each percentage point (or part thereof) below 99.7%.”

By getting specifics like the above in writing, you protect yourself in case of prolonged outages or poor performance.

Read our contract checklist, RISE Contract Checklist: Critical Clauses and Terms Every SAP Customer Must Negotiate.

7. Support & SLA Provisions

RISE with SAP includes support for the cloud services, but the level of support can vary.

You need to pin down support terms and SLAs (Service Level Agreements) beyond just uptime. Essentially, when you have an issue, how fast will SAP respond, and what happens if they don’t?

Ensure the contract covers:

  • Incident priority definitions: How does SAP classify a P1 (Priority 1) vs P2 issue, etc.? For example, a production system down might be P1, a minor bug P3, etc. These definitions should be clear so there’s no arguing over severity when something goes wrong.
  • Response and resolution times: For each priority level, the SLA should state SAP’s response time and perhaps a target resolution time. E.g., “P1 – response within 1 hour, restore service within 4 hours” as a target. These numbers need to meet your business requirements – negotiate them if you have more stringent needs.
  • Escalation path: Make sure there’s an agreed process for escalation. If a critical issue isn’t resolved in the expected time, how do you escalate to SAP’s senior engineers or management? The contract or support policy should list contacts or an escalation ladder.
  • Continuous support vs. business hours: Confirm if support is 24×7 for critical issues (it should be for P1 incidents in a global business). If it’s only 8×5 by default, negotiate 24×7 coverage for high-severity cases or overall if you need it.

Critically, look at what remedies exist if SAP misses these support commitments. Many standard contracts have no penalty for slow response – you don’t want that.

While you might not get SAP to provide a refund for every missed SLA, you should push for service credits or fee waivers for major support failures. At minimum, establish a process in the contract: for example, if SAP repeatedly fails to meet the SLA, you have the right to escalate to an executive or even terminate if it’s egregious (this would be extreme, but it gets their attention).

Also, consider adding a governance clause that requires a quarterly service review meeting with SAP. In this meeting, you and SAP review performance against SLAs, discuss any issues, and plan improvements.

Having this in the contract ensures SAP stays accountable throughout the term, not just at renewal time.

Expert Insight: If the SLA doesn’t include credits or consequences, then it’s just a promise, not a protection. Don’t accept fluffy assurances – make sure there’s some bite if SAP falls short on support.

8. Pricing, Discounts & Indexation

The pricing terms in your RISE contract will determine your IT budget for years, so they must be crystal clear and locked down. Here’s what to cover:

Net vs. List Pricing: Ensure all prices in the contract are based on the net negotiated rate, not SAP’s list prices. For example, if SAP’s list price for your bundle is $5M/year but they gave you a 50% discount to $2.5M, the contract should treat $2.5M as the base going forward. Without this, a clause like “prices at renewal per then-current list” could let SAP revoke your discount later. Instead, insist that any increases or calculations (for adding users, etc.) apply to your current paid price.

Discount and rebate terms: If you negotiated any special discounts or one-time credits (such as a first-year discount or credits for unused on-premise licenses via the Conversion Addendum), ensure they are clearly documented.

Also, confirm if the discount is conditional (e.g., tied to signing by a certain quarter, or maintaining a certain product) and what happens if those conditions change.

Indexation and currency clauses: Many multi-year cloud contracts include clauses for inflation (indexation) or currency exchange fluctuations:

  • Cap inflation adjustments: If SAP insists on an inflation clause, set a low cap (e.g., max 2-3% per year). Better yet, try to remove it if possible by arguing that the multi-year price already factors in expected inflation.
  • Currency considerations: If you’re paying in a currency that’s not your local currency, or if your use spans countries, be careful. Negotiate either a fixed exchange rate for the term or a narrow band. Prevent SAP from suddenly raising fees due to currency swings.
  • Multi-region charges: If your RISE covers multiple regions, confirm that things like data transfer or regional surcharges are included or capped. No hidden fees creeping in later.

Price breakdown transparency:

RISE is a bundle of many components (software, database, infrastructure, support).

Ask for a breakdown of costs in your proposal or contract. For example, out of your total annual fee, how much is allocated to the S/4HANA software vs. the infrastructure vs. other services? SAP may resist giving detailed breakdowns in the contract itself, but you can often get it in writing during negotiations.

This helps you benchmark – maybe SAP’s infrastructure component is priced much higher than if you bought cloud directly. That knowledge is leverage to negotiate a better overall price.

To put things in perspective, consider some real-world pricing: For a mid-sized deployment (around 1,000-1,500 users), RISE with SAP might be quoted around $150–$180 per user (FUE) per month (lower end for public cloud edition, higher for private edition). That means roughly $2–3 million per year in subscription fees.

Now imagine SAP’s standard terms allowing 5-10% annual “indexation” on top of that – you could be facing hundreds of thousands more in year 2 and beyond. This is why nailing down caps and fixed terms on pricing is so important. Likewise, if your deal included a big up-front discount, ensure you don’t lose it at renewal due to vague wording.

Negotiation Tip: Unbundle the bundle. SAP’s RISE pricing wraps software, hosting, and services into one number – your job is to unpack it. By understanding each piece and its cost, you can benchmark what you should be paying and push back on any inflated component.

9. Data Ownership & Residency

Your corporate data is lifeblood – never leave its ownership or location in question. In a RISE contract, you need strong terms around data ownership, data access, and data residency:

Data ownership: The agreement must state clearly that you retain ownership of all your data.

Any data you store or process in SAP’s cloud (including backups and even system logs that contain your business information) should be acknowledged as your property.

This seems obvious, but confirming it in the contract protects you against any ambiguity. It also ensures SAP can’t, for example, claim anonymized usage data or metadata and prevent you from accessing it.

Data access and export: One of the biggest fears in a cloud deal is, “Can I get my data back out?” Negotiate a clause that gives you the right to export your data at any time, and especially at contract termination.

The export should be in a usable format (not a proprietary dump that only SAP can read) – common formats like CSV, database backup files, etc., depending on the system. And crucially, make it free or included.

You don’t want to find out that getting your own data will cost you professional services fees. Ideally, also include that SAP will provide reasonable assistance to ensure the data migration out is successful if you leave.

Data residency and locality:

If your industry or local laws require data to reside in certain locations (for example, personal data staying within the EU, or within a specific country/state), the contract must reflect that.

Ensure the RISE contract specifies the primary and backup data center locations for your systems. For instance, “Primary Data Center: Frankfurt (Germany); Disaster Recovery: Amsterdam (Netherlands)” – whatever fits your requirements.

Also, include wording that SAP will not move your data to other regions without your approval. Sometimes SAP might want flexibility to optimize resources globally, but if data residency is important to you, lock it down to specific regions.

Sample Clause: “Customer data shall remain the exclusive property of the Customer. SAP will store and process Customer’s data only in the Customer-designated regions (e.g. EU-West data centers) and not transfer it outside those regions without prior written consent.”

This sample language covers both ownership and residency. It ensures you own the data and restricts where SAP can host it. Tailor the region to whatever is relevant (could be country-specific or just say “within the United States” or similar, as needed).

By securing these points, you protect yourself from scenarios such as discovering your data was replicated to a server in another country against your policy, or having trouble retrieving data when you need it. Data control is a non-negotiable in any cloud contract.

Read our tips on how to negotiate, Negotiating a RISE with SAP Deal: How to Secure Favorable Terms and Avoid Hidden Traps.

10. Audit and Compliance Rights

Moving to a subscription model like RISE involves significant changes, but it doesn’t automatically eliminate audits. SAP can and will audit customers to verify compliance, even in the cloud.

The contract should outline what rights SAP has to audit your usage and how those audits will be conducted. Your goal is to make any audit limited, predictable, and fair:

Limit the scope: Specify that SAP’s audit rights apply only to the RISE environment and usage. For example, SAP might want to check that you haven’t exceeded your FUE count or that you’re not using services beyond what you bought.

That’s fine – but ensure they cannot trawl through unrelated systems or data. If you also have some on-premise SAP systems not under RISE, those should be out of scope unless explicitly stated. Keep the audit focus on the subscription services in question.

Frequency and notice: Include a clause on how often SAP can audit (e.g., “no more than once per year, unless a material issue is found”) and requiring advance notice (e.g., 30 days written notice). No one wants a surprise audit letter demanding immediate attention. Advance notice allows you to gather data, personnel, and ensure business continuity while the audit happens.

Audit procedure: It’s wise to have a defined procedure. For instance, audits should occur during normal business hours, and SAP should coordinate with you on the method (perhaps you provide them with system usage reports instead of having them deploy tools on your systems).

If you have sensitive environments, you might negotiate to perform the measurements yourself under SAP’s guidance rather than giving SAP direct access. The contract could state that the audit will be conducted in a manner that does not interfere with your operations.

Confidentiality: Ensure the audit results and any data collected are treated as confidential and used solely for compliance verification. You don’t want your usage data shared around or used for sales targeting without your consent.

Cost and liability: Typically, if an audit finds you out of compliance by a significant margin, you’ll have to pay true-up fees (and possibly back fees). That’s expected. However, if you are found to comply, you shouldn’t have to pay for the audit.

Negotiate for SAP to cover the audit costs (reasonable auditors’ fees, etc.) if no material violation is found. This discourages frivolous audits. Also, ensure any true-up process is reasonable – e.g., you get 30 days to pay any shortfall or the option to incorporate it into the subscription in the future, rather than immediate penalties.

  • Checklist – Audit Terms: Confirm your contract includes:
    • Limited scope: Audit rights are restricted to RISE subscription usage data and systems, not your entire IT landscape.
    • Notice & frequency: SAP must give adequate notice (e.g., 30 days) before an audit and cannot audit more than once per year without cause.
    • Defined process: Audits will follow a defined procedure agreed by both parties, and avoid undue disruption.
    • Cost fairness: If the audit finds you in compliance or with only minor discrepancies, SAP bears the audit cost. You only pay (true-up fees or audit costs) if a significant compliance breach is confirmed.

Taking the time to negotiate these audit terms will save you headaches later. It puts guardrails around SAP’s compliance checks and ensures you’re treated fairly in the process.

RISE Negotiation Traps to Avoid

Throughout your RISE contract review, keep an eye out for subtle “traps” – clauses or omissions that can bite you later.

Here are common pitfalls in RISE with SAP agreements and how to avoid them:

  • “Illustrative Scope” Language: Watch for any wording that says the scope or included services are “illustrative” or “for example.” This non-committal language means the list of included components isn’t binding. Trap: SAP could later claim something isn’t included and bill you extra. Solution: Remove fuzzy scope terms and list all included components explicitly (no “etc.” – make it concrete).
  • Automatic Renewal: Some RISE contracts auto-renew for the same term (another 3-year term, for instance) unless you cancel way in advance. Trap: You might miss a tight notice window and get locked in for extra years. Solution: Eliminate automatic renewal clauses. Require that renewal must be mutually agreed in writing, or at least give yourself a very clear, lenient notice period to opt out. Never let a contract renew by silence.
  • Bundling of Multiple Products: As mentioned with co-termination, SAP may bundle various cloud services into one contract. Trap: You lose flexibility to drop or replace any single service because they’re all tied together in pricing and terms. Solution: Negotiate separate order forms or schedules for each major product, or explicit rights to scale them independently. Keep some leverage by not putting all eggs in one basket.
  • Uncapped Renewal Pricing: The default SAP approach is to hit you with the full list price at renewal (which could be a 20%, 30%, or even higher jump). Trap: If you overlook adding a cap or fixed pricing for renewal, you could face budget-busting increases. Solution: As discussed, cap those uplifts (e.g., ≤3% annually) and get it in the contract. Also, align it such that it’s 3% on your current price, not the list.
  • Data Exit Restrictions or Fees: Sometimes the DPA or other annex might say that data export or extensive data requests will incur fees, or that certain data (like system logs or configurations) is SAP’s IP and not provided. Trap: When you try to leave, you might find you have to pay to retrieve data, or you can’t get important metadata at all. Solution: Negotiate an explicit clause that all customer data and related system data will be made available to you upon exit at no additional cost. Strike any clause that undermines this. Essentially, no “ransom” for your data.

Expert Insight: SAP isn’t hiding these gotchas – they’re printed in plain English, just buried in 20+ pages of Ts&Cs and annexes. Stay alert and assume nothing. If a protection isn’t in writing, it doesn’t exist.

Final RISE Contract Review Checklist (Before Signature)

Before you sign your RISE with SAP contract, run through this final checklist and make sure you’ve covered all critical areas:

  • ✔️ Defined scope with all components named: Every product, module, and service you expect is explicitly listed (specific S/4HANA edition, included systems like SolMan, any BTP services, third-party apps, etc.). Nothing is assumed or “to be detailed later.”
  • ✔️ Renewal uplift capped: The contract limits any renewal price increase to a fixed percentage (e.g. 3% per year), avoiding a reversion to full list prices. You have at least 120 days to decide on renewal terms.
  • ✔️ Data ownership and export rights: It’s stated that you own your data, and you have the right to retrieve all your data (including backups and logs) in a standard format when needed — especially at contract end — without extra fees.
  • ✔️ Separate terms for other SAP products: Any SAP cloud services or licenses outside of RISE are either kept on separate agreements or clearly separated in the RISE contract. Co-termination and bundling have been avoided or minimized to preserve flexibility.
  • ✔️ FUE count and flexibility verified: The FUE calculation is documented and makes sense for your user base. A ±10% user count flexibility (buffer) is included so normal business changes won’t break the contract.
  • ✔️ Hosting and SLA details confirmed: The contract names the hosting provider (and data center region) for your RISE systems. Uptime SLA is agreed (with credits for shortfalls) and support response times for critical issues are defined.
  • ✔️ Pricing breakdown and indexation checked: You understand the cost breakdown. All fees are based on net negotiated rates. Any inflation or currency adjustment clauses are capped or removed. No hidden charges for standard operations.
  • ✔️ Conversion credits or license value recognized: If you’re moving from on-prem, the contract gives you credit for your existing licenses/maintenance (so you’re not paying twice for the same software). This could be a discounted first-year rate or a formal credit amount – make sure it’s in there.
  • ✔️ Exit and rollback provisions: If you converted perpetual licenses to RISE, you have a clause about what happens if you leave RISE (e.g., the right to re-activate your old licenses or a window to transition). There is a defined exit process with assistance and no penalties beyond any remaining fees.
  • ✔️ Thorough legal review of all terms: Your legal/procurement team has read every document and appendix (GTC, SLA, DPA, order form, etc.). All unusual or risky clauses (like indemnities, liabilities, data use, termination, governing law) have been vetted and negotiated as needed. In short, no “blank spaces” in understanding the contract.

Use this checklist as your final pass. If anything above is missing or weak in your RISE contract, go back to SAP and address it before signing. RISE with SAP can deliver great value and simplicity, but only on a contract that protects your interests as much as it does SAP’s.

Read about our SAP Advisory Services.

author avatar
fredrik.filipsson
Fredrik Filipsson is the co-founder of Redress Compliance, a leading independent advisory firm specializing in Oracle, Microsoft, SAP, IBM, and Salesforce licensing. With over 20 years of experience in software licensing and contract negotiations, Fredrik has helped hundreds of organizations—including numerous Fortune 500 companies—optimize costs, avoid compliance risks, and secure favorable terms with major software vendors. Fredrik built his expertise over two decades working directly for IBM, SAP, and Oracle, where he gained in-depth knowledge of their licensing programs and sales practices. For the past 11 years, he has worked as a consultant, advising global enterprises on complex licensing challenges and large-scale contract negotiations.
Scroll to Top