SAP S/4HANA RISE: Contract and Licensing Challenges

SAP S/4HANA RISE: Contract and Licensing Challenges

Overview of SAP S/4HANA RISE:

RISE with SAP S/4HANA (often called RISE with SAP) is SAP’s subscription-based cloud offering that bundles its flagship S/4HANA ERP and related services into a single contract.

Launched in 2021, RISE is positioned as a “business transformation as a service” solution to streamline customers’ path to S/4HANA.

It includes the S/4HANA software itself, infrastructure (cloud hosting on SAP’s data centers or hyperscalers such as AWS, Azure, and GCP), technical services, and support in a single package.​

SAP manages much of the system operations and maintenance under RISE, reflecting SAP’s strategic pivot to a cloud-first model​

Importantly, RISE is a cloud-exclusive program, available only for cloud deployments (public or private cloud editions of S/4HANA), and is delivered via a subscription license model.​

SAP has been heavily prioritizing RISE as the go-forward option for customers moving to S/4HANA, especially as the legacy SAP ECC product’s support approaches its 2027 end-of-mainstream-maintenance deadline​

Read SAP ECC End of Life and RISE with SAP.

💡 Make Smarter Licensing, Contract, and Cloud Decisions with Confidence

• Avoid overpaying for user licenses and cloud capacity by learning to right-size your SAP RISE subscription.
• Understand the true financial trade-offs: subscription fees vs. perpetual license value, infrastructure bundling, and support scope.
• Gain visibility into hidden costs often overlooked, from indirect access to BTP overages and contract renewal uplifts.
• Discover how mid-size companies have negotiated better deals, secured future flexibility, and maintained control post-transition.
• Free up IT and procurement capacity by simplifying contract management — without locking your organization into restrictive long-term terms.

Download CIO & Procurement Playbook: Transitioning to SAP RISE with S/4HAN

Key Differences from Traditional SAP Licensing Models

RISE with SAP represents a significant shift from SAP’s traditional licensing approach.

In the past, most SAP ERP customers purchased perpetual licenses for on-premise deployments – a one-time license fee that granted indefinite usage rights – and then paid annual support fees for updates.

Under RISE, this model is replaced by a subscription license. Customers pay a recurring fee (e.g., annual) for the right to use S/4HANA, typically including software usage, support, and cloud infrastructure costs in a combined bundle.​

It converts SAP from a capital expenditure (CapEx) purchase to an operating expense (OpEx) service. Another major difference is that RISE consolidates multiple elements into a single agreement with SAP.

In contrast, a traditional setup might involve separate contracts, such as one with SAP for software and another with a hosting provider or hardware vendor.

RISE’s single-contract approach simplifies procurement and gives the customer a central point of accountability.

However, it also introduces new considerations, such as relying on SAP to interface with the chosen hyperscaler (the cloud infrastructure contract is between SAP and the cloud provider, not directly between the customer and, for example, AWS), which can reduce the customer’s direct control over infrastructure details.​

Additionally, RISE is inherently cloud-centric; unlike traditional licensing, it does not support on-premise deployment. Customers who “RISE” must run S/4HANA in SAP’s cloud or an SAP-managed private cloud environment.

They cannot simply apply the RISE subscription to their self-managed data center.

Table-stakes differences include no upfront license purchase (subscription only), no customer-owned infrastructure required, and a shift from perpetual to time-bound usage rights.

In short, RISE’s subscription model differs from SAP’s historical perpetual license model, offering simplicity, bundled services, and less flexibility to deviate from SAP’s standardized cloud terms.

Read SAP Licensing Changes and the 2027 Deadline.

SAP Licensing Models

Subscription vs. Perpetual Licensing:

SAP now offers traditional perpetual licenses and newer subscription models; understanding the distinction is crucial.

A perpetual license involves a one-time upfront fee to own the software indefinitely, typically accompanied by annual maintenance fees of around 20% for support and updates.

In contrast, a subscription license is essentially a rental – the customer pays recurring fees (e.g., monthly, quarterly, or annually) to use the software for the duration of the contract, and support and upgrades are usually included in that fee.​

For example, SAP S/4HANA on-premise is often sold via perpetual licenses plus annual maintenance, whereas S/4HANA Cloud (and RISE with SAP) is sold via subscription. Perpetual licensing favors those willing to invest upfront and want long-term control.

You can technically run the software as long as you want, even if you stop paying maintenance, although updates will no longer be available.

Subscription licensing appeals to those who prefer lower initial costs and the flexibility of a pay-as-you-go (PAYG) model, but it requires ongoing payments to maintain access.

In the RISE context, there is no perpetual option; RISE is 100% subscription-based, converting what was previously a license-and-maintenance model into a unified subscription service.

This means RISE customers do not own the software licenses outright; instead, they can use S/4HANA if their subscription is active.

One practical effect of this shift is on accounting and budgeting, specifically the comparison between CapEx and OpEx, as well as long-term negotiating leverage.

Once a company moves to a subscription model, SAP discontinues the sale of new perpetual licenses for that environment.

SAP has explicitly positioned RISE as the exclusive way to obtain new S/4HANA capabilities, eliminating the option to purchase additional perpetual licenses for that installation in the future.

This lock-in to subscription can have financial implications over time, so companies must weigh upfront savings against long-term costs.

Read our article SAP S/4HANA Licensing: Models, Costs, and Strategic Considerations for CFOs and IT Leaders.

Cloud-Based vs. On-Premise Considerations

SAP’s licensing model also differs depending on deployment. An on-premise deployment (or customer-managed private cloud) typically uses traditional licensing.

The customer buys perpetual licenses and is responsible for provisioning hardware, installing the software, and managing maintenance and upgrades.

This gives the customer maximum control and the ability to customize, but it also means a higher burden of responsibility and upfront costs.

In contrast, a cloud-based deployment (such as SAP S/4HANA Cloud or RISE with SAP) utilizes a subscription model, shifting much of the operational burden to SAP.

In a cloud model, SAP (along with its infrastructure partner) manages the servers, handles updates and patches, and provides the system as a service.

Thus, the subscription fee includes the software license, as well as hosting, maintenance, and support services.​

For example, SAP S/4HANA Cloud (public edition) is a multi-tenant SaaS. SAP updates it quarterly, and all customers run the latest version.

In contrast, S/4HANA on-premise customers must schedule and execute their upgrades.

The trade-offs revolve around flexibility vs. convenience. On-premise allows extensive customization (tailored modifications to code, unique configurations) and may be necessary for industries with strict data residency or control requirements.​

Cloud versions enforce more standardization; certain deep customizations might not be allowed, especially in the public cloud edition, but offer agility and automatic access to new features.

From a licensing perspective, on-premise deals often involve a complex mix of user licenses and engine metrics.

In contrast, cloud deals simplify many of these into per-user or capacity subscriptions. Additionally, cloud contracts have defined terms (e.g., a 3-year RISE subscription), after which they must be renewed, potentially with price changes.

In contrast, a perpetual on-prem license grants the right to use forever (with optional yearly maintenance). In summary, cloud licensing offers simplicity and outsourced management at the cost of some control.

On the other hand, on-premises licensing offers control and flexibility but at the expense of greater complexity and higher capital costs.

Today, enterprises often consider a hybrid approach, keeping some systems on-premises and some in the cloud, to balance these factors, which we will discuss later.

Read our SAP Rise Negotiation Guide.

User-Based and Consumption-Based Pricing Structures

SAP’s licensing has historically been user-based, but it also includes elements based on consumption.

In a user-based model, the primary metric is the number of named users, often categorized by type (e.g., Professional User, Functional User, Employee Self-Service user, Developer, etc.).

Each user license authorizes an individual to use SAP according to their role, and pricing is based on a per-user seat.​

Named-user licensing (which can represent 40–70% of contract cost)​dominated most traditional SAP ERP contracts.

​In addition, SAP sells module or engine licenses tied to specific functionality and measured by consumption metrics, such as the number of orders processed, the amount of revenue managed, or the number of CPU cores utilized.​

These are consumption-based licenses, meaning the cost is based on usage volumes or data metrics rather than a flat per-user fee​.

Modern SAP environments increasingly introduce consumption metrics for indirect usage and cloud services.

For instance, SAP’s Digital Access model (for indirect document access) charges based on the number of business documents created or viewed via non-SAP applications.

A clear shift to usage-based licensing covers scenarios where external systems interact with SAP.

Similarly, SAP’s cloud platform services, such as the Business Technology Platform, often use a credit system or metered consumption (e.g., CPU hours, memory, transactions).

RISE, with SAP’s licensing structure, blends these concepts. RISE uses Full User Equivalents (FUEs) as the metric for S/4HANA Cloud, especially in the private edition.

FUEs aggregate different user types into a single weighted metric – for example, 1 “Advanced” user equals 1 FUE, while 1 “Core” user might count as 0.2 FUE, and so on. This allows a mix of user roles to be covered by a total FUE count.​

This approach allows customers to have various user types without micromanaging each category’s license count (you contract for a total FUE number)​.

It’s still fundamentally user-based (since the FUE count is derived from user roles).

Still, it’s authorization-based rather than strictly named-user count, which counts the total authorized usage capacity.

One challenge to note is that SAP’s cloud subscriptions, including RISE, are often charged based on authorizations rather than actual usage, which can sometimes be less cost-efficient if many users are licensed but not all are actively using the service.

Studies have found that authorization-based licensing is typically 50–150% more expensive than usage-based licensing.​

In other words, if you pay for 100 users, whether or not they all use the system fully, you might spend more than a model that charges for actual transactions or hours used.

This emphasizes the careful sizing and optimization of user licenses in a RISE contract. To summarize, SAP licensing spans user-based, module-based, and consumption-based paradigms.

RISE simplifies some of the complexity by rolling many metrics into the FUE (user-based) model, but customers should still be aware of underlying consumption factors (like indirect document counts or BTP resource usage) that could invoke additional fees outside the core subscription​

A balanced understanding of user counts and consumption metrics is key to avoiding surprises.

SAP Rise Contractual Challenges

Adopting SAP S/4HANA via RISE introduces several contractual challenges that differ from traditional SAP agreements.

Executives and legal teams should pay special attention to the structure of the RISE contract and the obligations it imposes on both parties.

Key Contract Terms and Obligations

RISE with SAP contracts are comprehensive and bundle many previously separate components.

Key terms cover software usage rights (the S/4HANA cloud subscription for a certain number of users/FUEs), service levels and support, cloud infrastructure provisioning, and the division of responsibilities between SAP and the customer.

A notable aspect is the RACI for operations – SAP assumes tasks such as system monitoring, backups, and updates, particularly for the public cloud edition.

At the same time, the customer retains responsibility for business processes, user management, and configuration. Navigating these extensive service descriptions can be complex.

Companies must delineate what is in scope and what is out of scope under the RISE contract. For example, standard RISE may include one production and some non-production environments, basic SAP Basis administration, and certain SAP Cloud Platform services.

However, anything beyond (additional test systems, extra integrations, third-party add-ons) might not be included by default.

It is easy to assume something is covered, only to find later that it isn’t—careful review is essential.​

Without a comprehensive strategy, customers can overlook the nuances of the RISE deal and mistakenly believe they have more services or fixed terms than are provided​.

Important contract terms to scrutinize include the subscription term length, renewal handling policies, pricing structure, any built-in escalators, data center location, data protection terms, uptime guarantees (SLA), and SAP’s audit and access rights to your systems for compliance purposes.

One obligation in RISE is that the customer must commit to the cloud subscription for the term – there is no early exit without penalty in most cases.

Unlike some SaaS offerings that allow scaling down, a RISE contract typically locks in a specific capacity (e.g., number of FUEs and particular cloud resources) for the duration.

This makes understanding your needs upfront very important.

Additionally, because SAP bundles infrastructure, customers do not have a direct contract with the hyperscaler; instead, SAP manages that relationship.​

As a result, any changes you need to make to your cloud environment (such as scaling up capacity or changing regions) must be negotiated through SAP under the terms of the RISE agreement.

Legal teams should also note the liability and indemnity clauses. For instance, SAP’s liability for outages is usually limited to service credits, and the contract may cap SAP’s overall liability.

Customer obligations typically include timely payment of subscription fees, compliance with usage limits (such as not exceeding the licensed number of users or storage), and cooperation during SAP audits.

If the customer has existing SAP licenses being replaced by RISE, the contract may require them to be terminated or put in storage to prevent “double dipping.”

Overall, the RISE contract is a lengthy, interwoven document that combines aspects of software licensing, cloud service agreement, and support contract.

It requires a thorough review so that executives understand what they are signing.

Key terms, such as renewal conditions, price increase provisions, and termination assistance, should be explicitly understood and, if possible, negotiated to be more customer-friendly than SAP’s default.

Read our SAP Rise Negotiation FAQs.

Negotiating SAP RISE Agreements

Negotiating a RISE contract can be challenging due to its complexity and SAP’s leverage.

Unlike a simple license sale, a RISE deal encompasses software, infrastructure, and services, which means negotiating multiple dimensions.

Enterprises should prepare meticulously to approach this. 

Preparation starts with knowing their current environment and needs: Before entering RISE negotiations, analyze their existing SAP usage and licenses.

This analysis helps determine the appropriate subscription size and can prevent over-licensing.

For example, suppose you currently have far more named users on paper than are actively used.

In that case, you’ll want to right-size during the RISE migration. A “solid analysis” of current license assignments can avoid unnecessary costs and prevent the FUE count from being exceeded.​

In one case study, a customer optimized their user licenses and reduced the required FUEs by 227, resulting in significant cost savings.

This usage data provides evidence to negotiate a subscription that fits your actual usage, not SAP’s list count.

When discussing terms with SAP, focus on flexibility and future protections.

By default, certain protective clauses common in traditional contracts may be absent in a RISE proposal – for instance, rights of renewal at a capped price increase, the ability to reduce users or swap licenses for other products, or price locks for adding additional users are not initially offered by SAP’s standard RISE terms​.

Customers need to proactively negotiate these. It’s wise to ask for features like a cap on annual price increases (or a fixed renewal price), the right to scale the subscription up or down after a certain period, and “swap rights” that allow you to repurpose part of your subscription toward other SAP cloud services if needed.

If your business might change, try to build in accommodations (for example, if you divest a division, can you reduce the user count accordingly?).

Renewals deserve special attention – you don’t want to be hit with a steep increase after the initial term, so negotiating predictable renewal terms is crucial.

Another negotiation angle is clarifying the scope and responsibilities.

Since the bundle includes many services, ensure that the contract documents, such as the Scope of Services or SLA documents, are included and clearly understood.

If you require specific services (e.g., integration support, data migration assistance, or additional sandbox systems), negotiate them into the deal upfront.

Anything not specified in writing in the contract will likely incur extra costs later.

Ensure that you discuss indirect access and third-party interface terms during the negotiation. If you have a scenario that might otherwise incur indirect usage fees, clarify how it will be handled under RISE.

Sometimes, SAP can include certain indirect usage rights or offer a discount on a Digital Access license as part of the package. Read more about the impact of digital access on RISE contracts.

Engaging SAP in a RISE negotiation also often involves their cloud value advisors or sales executives, who may push the “business transformation” value over the nitty-gritty terms.

Your team, including legal, needs to focus on the contractual details and not get swept up in just the high-level pitch.

If possible, leverage benchmarks and expert advisors: knowing what discounts or concessions similar customers obtained can bolster your position.

Third-party consulting firms or SAP licensing specialists (familiar with RISE deals) can provide insight into where SAP has flexibility.

Key items to negotiate or verify include data residency commitments (important for legal compliance), exit provisions (what happens if you don’t renew—ensure you have a right to get your data and perhaps run the system in read-only), and the audit process (e.g., some customers seek a clause to use SAP’s License Management tools annually and true-up proactively instead of surprise audits).

In summary, treat a RISE negotiation like a large outsourcing contract – cover all bases from performance to price protections.

With a clear strategy, securing a RISE agreement that aligns with your business goals and avoids common traps is possible.

Read about SAP Rise vs Grow.

SAP Rise: Hidden Costs and Unexpected Licensing Fees

One of RISE’s promises is a simplified, all-in-one invoice, but that doesn’t mean all costs are obvious upfront.

There are several areas where hidden or unexpected costs can emerge, and savvy customers will address these proactively:

• Cloud Infrastructure and Sizing Costs: In RISE, SAP essentially resells your cloud infrastructure, provided by a hyperscaler, as part of the package. However, SAP’s pricing to you may include a markup or, at the very least, is not transparent, line by line. SAP may receive incentives or discounted rates from cloud providers, but these savings are not typically passed on to the customer​in detail. As a result, you might be paying a premium for convenience. Without transparency into infrastructure costs, knowing your fair price is hard.
  Additionally, if SAP initially sizes your environment incorrectly (too low), you may need to increase the resources later, which can result in additional costs. Conversely, you may be paying for unused capacity if the system is oversized. This sizing risk is a hidden factor – clients have reported concerns that they lack visibility into how the underlying cost structure is built, creating uncertainty about whether a direct cloud contract might have been cheaper.
• Indirect Usage and Third-Party Interfaces: As mentioned earlier, indirect access can result in unexpected license fees. If, for example, you have a third-party e-commerce system that pulls/pushes data to S/4HANA and haven’t licensed that interaction via SAP’s indirect use policy, SAP could later claim additional fees. Many customers have been “blindsided by additional fees” in the past for indirect use. Under RISE, ensure that your subscription covers these scenarios. SAP might include a certain amount of Digital Access (document-based licensing) in your contract or require you to purchase it separately. An audit could reveal indirect usage and trigger unbudgeted costs if this isn’t addressed. The bottom line is to inventory all third-party integrations with SAP and discuss them with SAP to avoid surprises. It’s often possible to negotiate a known quantity of indirect usage into the deal or, at the very least, to be clear on how it will be measured and charged.
• SAP BTP and Ancillary Services: RISE with SAP bundles some use of the SAP Business Technology Platform (BTP) – for example, it might come with a starter package of BTP credits or certain cloud services. However, you incur additional consumption charges if you exceed the scope. Workloads or extensions built on BTP (for example, using it for custom applications or complex integrations) consume credits. Once the included amount is exceeded, you pay per use. These costs can be difficult to predict and escalate quickly if you heavily use analytics, integrations, or IoT scenarios on BTP. Many companies fail to factor this in during their budgeting process. The advice is to ask SAP exactly what BTP services are, how much usage is included in the RISE subscription, and what the overage rates are. Some RISE contracts include a fixed amount of BTP usage (such as several credits per year) – note that number. If your digital strategy involves significant expansion on BTP, consider negotiating a larger allotment upfront or a cap on BTP costs.
• Migration and Implementation Costs: Although not a “license fee,” the effort to move to RISE can introduce hidden costs that organizations should prepare for. For example, data migration tools, testing, retraining users, and reimplementing custom code (especially when moving from on-premises, highly customized environments to a cleaner cloud environment) all carry costs. SAP does offer some tools as part of RISE, such as the SAP Readiness Check. There may also be limited use of SAP MaxAttention or advisory services. Still, many services are out of scope and require either SAP consulting or a third-party system integrator (SI), which is an additional expense outside the RISE contract. It’s essential not to assume RISE is a turn-key migration; it primarily involves licensing and technical infrastructure. Implementation services are usually separate.
• Future Growth and Volume Changes: If your business grows (in terms of transactions, data volume, or users) beyond the contracted amount, you may incur unexpected charges. A RISE contract may stipulate additional fees for excess storage, extra users beyond the FUE count, higher API call volumes, and other similar conditions. These are often at higher marginal rates. Without careful planning, a surge in usage could result in a budget overrun. This is where negotiating some headroom or flexible add-on rates can save money. If you expect growth, consider locking in pricing for additional blocks of users or extra storage now, rather than at the moment of need, when SAP may charge list prices.
• Vendor Lock-In Costs: RISE, by design, increases dependency on SAP’s ecosystem. The cost can be prohibitive if you become dissatisfied and want to switch to another cloud or even return to on-premises solutions. Data extraction, license conversion, and possibly repurchasing perpetual licenses are all factors that contribute to the cost. In essence, the lack of an easy exit is itself a “cost” – it gives SAP leverage to raise prices at renewal, knowing switching out is painful. Analysts have warned that moving off or seeking alternative solutions without incurring significant expense is difficult once you are locked into RISE’s bundled model. This isn’t a direct fee, but it is a financial risk. To mitigate this, try negotiating terms that at least contemplate a transition, such as assistance with data export or a conversion right to a standard S/4HANA license if needed. Even if SAP is reluctant, consider these options.

In summary, while RISE simplifies many known costs into a single line item, hidden costs can still arise from indirect access, cloud resource overages, scope creep, and lock-in. Due diligence and negotiation can reduce these surprises.

Companies should model different scenarios (best-case, expected, and growth) to see how costs might evolve and ensure the contract has provisions or transparency to manage these costs effectively.

Asking SAP tough questions about “What is not included that I might have to pay for?” is a prudent step. With eyes open, you can enjoy the simplicity of RISE’s model while avoiding the common financial pitfalls.

SAP Rise Compliance and Risk Management

Moving to a RISE with the SAP model does not eliminate the need for vigilance in license compliance—in some ways, it changes the risk landscape.

Executives and legal professionals must manage traditional SAP licensing risks, such as indirect access, audits, and enforcement actions, within the context of a cloud subscription.

Indirect Access Risks

Indirect access (also known as indirect use) is one of the thorniest issues in SAP licensing. It occurs when users or systems that are not directly logged into SAP nevertheless interact with SAP data—for example, a third-party application that queries SAP to retrieve information or a web portal that creates an order in SAP on behalf of a customer.

In SAP’s view, these interactions still require licensing, even if no named SAP user is involved, which has led to high-profile compliance disputes.

Companies have faced financial penalties and legal disputes over indirect access.​

For instance, the Diageo case (2017) famously resulted in a multi-million-pound judgment for SAP when the court found unlicensed indirect use via Salesforce integration.

SAP’s response to the outcry was to introduce a Digital Access licensing model, rather than licensing each external user; Digital Access licenses the documents (sales orders, invoices, etc.) created or accessed indirectly​

This model can mitigate risk by providing a predictable metric for indirect usage, such as counting document types. It was offered as part of a one-time compliance program to help customers become compliant.

For RISE customers, it’s critical to understand that indirect access rules still apply.

Just because you are in the cloud doesn’t mean you have carte blanche for any number of interfaces.

You must have the appropriate licensing if a third-party system connects to your S/4HANA Cloud. SAP may include some level of Digital Access in RISE contracts, but this needs to be verified.

During negotiation or contract review, look for terms addressing “indirect usage” or “SAP Digital Access.” If these terms are not specified, assume they are not covered and may incur additional fees.

The best practice explicitly clarifies this: either obtain a clause that permits your current known interfaces (e.g., between SAP and an XYZ system) under the subscription or plan to license Digital Access separately.

Also, consider technical measures – SAP provides an estimation tool for digital access document counts; use it to gauge your exposure.

The risk of non-compliance due to indirect use

SAP can audit and back-charge for unlicensed use. This could happen even under RISE, as SAP could claim you exceeded fair use by allowing too many outside systems to create SAP transactions, for example.

While legal arguments about indirect usage have been contentious, the prudent approach is to avoid the fight by licensing properly or obtaining written assurances.

Involving your legal team to review how the contract defines the “Use” of the software is recommended. If it’s broad (as many SAP contracts cover direct or indirect usage), assume indirect scenarios count against your license.

Some RISE customers negotiate a certain number of “external participant” user licenses or an add-on digital access package.

In summary, indirect access remains a significant compliance risk: it can generate “unexpected additional licensing fees” if not accounted for​

Proactively manage it by understanding how data enters or leaves your SAP system through non-SAP channels and ensuring those channels are licensed.

With S/4HANA (cloud or on-premises), the Digital Access document approach is recommended to stay compliant. Many organizations are taking SAP up on this to avoid per-user charges for every external party.

Executives should treat indirect access not as an arcane detail, but as a potential financial liability that requires a clear resolution through contract, internal policy, or both.

SAP Rise Audit Rights and Compliance Obligations

SAP has robust audit rights written into its contracts, and RISE agreements are no exception.

Typically, the contract grants SAP the right to perform license compliance audits, which may include requiring the customer to run measurement programs or allowing SAP auditors to review usage data.

Under traditional on-premise deals, SAP’s License Audit team (recently renamed Global Adoption and Insights & License Compliance, GAILC) regularly audits customers’ deployments.​

These audits verify that the number of users, engines, and other metrics does not exceed the licensed limit. Non-compliance can result in a formal notice and a requirement to purchase additional licenses or subscriptions to cover the excess, often within a short timeframe.

In a RISE scenario (cloud subscription), the mechanics differ slightly: since SAP manages the system, they have even more direct visibility into usage.

SAP can monitor user counts, data volume, and activated features in the cloud service. They will still conduct formal audits if necessary, but some compliance checks may occur continuously.

The contract’s audit clause likely allows SAP to verify that you haven’t, for example, created more user accounts than your FUE allowance or connected unlicensed third-party systems. Learn more about FUE vs traditional user licensing.

Customers are obligated to cooperate with audits; failing to do so may be considered a breach of contract. This means providing necessary system access or reports to SAP’s auditors on request.

From a risk management perspective, companies should view SAP audits as inevitable. SAP audits every customer periodically, often every 1-2 years, unless they are part of a special program.

Being unprepared for an audit can lead to nasty surprises. SAP audits can be rigorous, and a lack of preparation can result in compliance fines or a sudden need to purchase additional licenses.​

This is true whether you’re on RISE or on-prem. A good practice is to conduct regular internal audits of your SAP usage.

Many firms run SAP’s measurement tools, such as USMM and LAW, every quarter to track license consumption.

By doing this, you can catch if, for instance, your user count is creeping above your contracted FUEs and take corrective action (such as archiving some users or purchasing additional capacity preemptively) before SAP’s official audit. Internal license compliance reviews should be part of your IT governance.

Another aspect is audit preparedness: have an internal team and process ready for when an audit notice arrives.​

This team (including IT asset management, SAP basis team, and legal or contract managers) should know what to gather and how to respond.

Ideally, maintain clear documentation of your entitlements (contracts, order forms, and specific metric definitions) and current usage metrics.

That way, if SAP’s numbers differ, you can have an informed discussion.

Also, be aware of your rights: SAP’s audit clause often states audits should be done during normal business hours and not unreasonably interfere with operations – you can schedule and manage the process professionally.

For RISE customers, a unique compliance obligation may be ensuring that only authorized users access the system.

Since SAP manages the environment, it may enforce license limits technologically (e.g., not allowing you to create more users than you have purchased).

However, you should not rely on that entirely; contractually, you remain responsible for not exceeding the usage limit.

Additionally, RISE contracts may specify compliance with usage reporting; some cloud contracts require the customer to self-report any usage that isn’t automatically tracked. Review your agreement to determine if you are required to periodically certify compliance.

Audit rights also extend to indirect use (as discussed) and proper user classification.

If users are misassigned (such as someone performing heavy work but only licensed as a light user), that’s a compliance issue. The audit might catch it if they interview people or check transaction logs.

SAP’s audit and compliance framework remains effective in the cloud era.

Customers must uphold their end by monitoring usage and staying within bounds. Regular internal checks, thorough documentation, and cooperative yet cautious responses to SAP audits will help reduce the risk of compliance surprises.

The goal is to avoid “true-up shock,” where an audit reveals you are under-licensed, and you must scramble to allocate a budget for an unplanned purchase.

By treating compliance as an ongoing process – effectively self-auditing – you can make any necessary adjustments within your timeline and budget cycle, rather than SAP’s.

SAP’s Approach to Licensing Enforcement

SAP’s approach to enforcing its licensing policies has historically been strict, which remains true with S/4HANA and RISE.

The company’s software is mission-critical for many customers, and SAP uses that position to insist on compliance.

Enforcement can range from soft approaches (such as account executives urging you to purchase enough licenses or offering a deal to transition to a new model) to more stringent measures (auditors issuing formal compliance reports or even taking legal action if negotiations fail).

Notably, SAP has demonstrated its willingness to litigate in extreme cases – the indirect access disputes with large customers have proven that point. In most situations, however, SAP prefers to turn compliance issues into sales opportunities.

For example, if an audit reveals that you have 500 users exceeding your license, SAP will quote you the cost to rectify the issue (often at a standard discount or list price).

They might also use it as a chance to pitch moving to RISE or a different model that “solves” the compliance issue. It’s a carrot-and-stick dynamic.

With RISE, SAP’s enforcement might manifest as follows: if you consistently exceed your contracted metrics (for example, regularly using more storage or more users), SAP will enforce an upgrade of your subscription.

The contract likely grants SAP the right to adjust your fees if you exceed usage for an extended period.

They may also enforce technical limits – for instance, capping system usage or issuing warnings.

Ultimately, since RISE is a subscription service, the key enforcement point is renewal. If you’ve been out of compliance or SAP knows you have limited alternatives, they may drive a hard bargain when renewing the contract.

It’s also important to recognize SAP’s strategic direction: SAP is highly motivated to transition customers to the cloud and subscription model (RISE) and away from perpetual licenses. They have informed investors of their intention to phase out the perpetual license business in favor of cloud growth.​

This means that the enforcement of legacy licensing might become even stricter, prompting customers to make conversions.

For example, a customer out of compliance with ECC might be told, “Instead of paying a huge penalty, why not move to RISE?

We’ll give you a clean slate.” From SAP’s perspective, that achieves compliance and moves the customer to the desired model.

Executives should be aware of this dynamic—sometimes, a compliance issue can be leveraged by the customer to negotiate a better RISE deal, trading something SAP wants for something the customer needs.

SAP’s enforcement also extends to the proper usage of contractual benefits.

If your RISE contract includes features such as two free sandbox systems or some BTP credits, using them without proper licensing beyond the specified limits constitutes a violation, for which SAP will eventually enforce fees.

Staying within the lines of the contract not only avoids penalties but also prevents giving SAP any additional leverage.

On the other hand, SAP has introduced some customer-friendly programs, such as the Digital Access Adoption Program (DAAP)​, which offers discounted packages for indirect access licensing to encourage customers to settle the issue rather than fight.

This suggests that SAP’s enforcement approach can strike a balance between firmness and incentives. Essentially, “we’ll enforce strictly, but we’ll also give you a reasonable path to compliance if you cooperate.”

For legal teams, it’s wise to capture any such commitments or programs in writing.

For example, if SAP offers you the option to adopt digital access at a discount for X years, ensure that this is written into an agreement or documented in correspondence.

In summary, SAP, as a licensor, is vigilant and assertive. Companies should assume that any significant licensing shortfall will be discovered and must be addressed.

The era of leniency (“we won’t true-up if you’re a bit over”) is largely over if it ever existed. Especially with today’s analytics, SAP knows how customers use its software.

The best defense is actively managing compliance and keeping an open and careful dialogue with SAP.

If you encounter a compliance issue, approach it as a negotiation: understand SAP’s goals and pressures (for instance, their cloud targets) and see if you can align a resolution that benefits your organization’s roadmap.

Transitioning from Legacy SAP Licensing to RISE

For organizations with a history of SAP usage (e.g., running SAP ECC or SAP S/4HANA under traditional licensing), moving to RISE with SAP is not just a technical upgrade – it’s a fundamental change in licensing and contractual terms.

This transition phase presents challenges and implications that require careful planning.

Migration Challenges and Licensing Implications

SAP has clarified that transitioning an existing customer to S/4HANA (especially under RISE) typically involves a contract conversion.

In other words, you will swap your old license agreements for new ones. SAP recently removed some older conversion options from its price list, narrowing customer choices.

As of mid-2023, customers on SAP ECC who want to move to S/4HANA have two main options: either a full contract conversion to the new S/4HANA licensing (perpetual) or adopting RISE with SAP (subscription)​

The “product conversion” path, which allowed for a more piecemeal mapping of old licenses to new ones, has been removed. Now, SAP expects a wholesale conversion to the new model.

If you sign up for RISE, your existing SAP ERP license and maintenance agreement will likely be terminated or transitioned.

SAP will typically provide credit for the remaining value of your licenses and maintenance, especially if you have a significant amount of unused software or prepaid support. However, the conversion negotiation can be complex.

A major implication is that once you move to RISE, you cannot return to your old licenses. Your perpetual licenses may be surrendered or placed in an inactive state.

SAP’s policy is that “the right to revert to a perpetual model is not typically provided once you go with RISE.”​

In plain terms, it’s a one-way street.

After converting to RISE, if you later decide the cloud isn’t for you, you will not automatically get your old on-prem licenses back. You would likely have to purchase new licenses, and SAP may no longer sell the old type.

This underscores the importance of being sure about the move to RISE. Executives should understand that RISE is generally a long-term commitment to SAP’s cloud ecosystem.

Handling Existing Investments

Many enterprises have significant investments in SAP licenses and may have years of prepaid maintenance already in place.

During the transition, maximizing the value of those investments is crucial. SAP has programs, such as license conversion credits, that apply a portion of what you’ve already paid to the new subscription.

For example, if you have a large shelf of unused SAP licenses, during a contract conversion, SAP might allow you to discontinue them and offer a discount on the new S/4HANA licenses or RISE subscription.

However, often, it’s not a dollar-for-dollar credit. Negotiation is key here: try to bring as much value as possible.

If you’re midway through a support period, ensure you’re not double-billed (you may need to align the start of RISE with the end of a maintenance period you’ve already paid for).

Some customers phase out the conversion to avoid financial write-offs.

For example, they might retain some less-used systems on existing licenses to continue utilizing what they have purchased while migrating core systems to RISE.

This can be tricky because SAP prefers an all-in migration, but partial conversions have been done depending on the leverage.

Parallel Use and Migration Periods

A practical migration challenge is that you will likely run your old system and the new S/4HANA (RISE) system in parallel during data migration, testing, and cutover.

SAP generally permits this under “temporary dual usage rights.”

In past conversions, SAP allowed customers to continue running their legacy SAP system during a transition period while the new system was being built.

This was explicitly permitted under both product conversion and contract conversion, allowing businesses to make a gradual transition.​

In a RISE scenario, SAP typically provides a window (typically 6 or 12 months) to operate your ECC or old environment in read-only or limited capacity while S/4HANA comes online. It’s important to get this in writing.

Ensure the contract (or an accompanying letter) states that you have the right to use the old system until a certain date for the transition.

Also, clarify if users can update the old system or only extract data – often, SAP expects no new transactional use in the old system once you go live on S/4HANA.

From a licensing perspective, during this overlap, you might technically need both sets of licenses.

SAP usually waives the need to pay duplicate maintenance during the approved transition period. However, clarity is still needed to avoid compliance issues.

Do not simply assume you can keep the old system up as long as you want – failing to decommission it after the allowed period could result in an audit finding (post-transition) that you are still using the retired licenses improperly.

Data Archiving and Read Access

One nuance: Even after a full cutover, companies often want to keep an archived copy of the old ERP for reference purposes (such as compliance and historical reporting).

Under a traditional license, that was fine; you owned it.

Under a conversion, you must negotiate an extended right to access historical data.

SAP sometimes grants a “Right to Use legacy system for read-only” for a specified number of years as part of the conversion. This is particularly important for legal and audit purposes on your end.

Discuss how you’ll access old data (via an archive, a third-party decommissioning tool, or keeping the system in a read-only state) and ensure SAP’s agreement allows it.

The migration to RISE has licensing implications that must be managed with the technical project.

Plan the contract conversion carefully, considering factors such as timing (to align with project milestones), credit for existing licenses, the dual-use period, and the lock-in effect.

It’s often useful to have a licensing specialist or negotiator alongside your implementation team, so that as the system is built, the contracts stay in sync, and you don’t end up in a gray area.

SAP Rise Hybrid Models and Coexistence Strategies

Not every enterprise will move everything to RISE at once – or at all.

Many will operate in a hybrid model, where some SAP workloads are in the cloud under RISE, and others remain under traditional licensing.

This can be due to phased migration plans, business decisions to keep certain systems on-premise, or regulatory reasons.

A hybrid approach can give a company the “best of both worlds,” allowing them to take advantage of RISE for some systems while retaining on-premise control.​

SAP supports this scenario and, in fact, explicitly markets “Hybrid” as an option: you might run an S/4HANA digital core via RISE but keep, say, an SAP BW or an industry solution on your infrastructure.

Coexistence requires careful thinking through integration and licensing boundaries. Consider an example: a company keeps its manufacturing plant systems on-premise (perhaps due to latency or customization needs) but moves its corporate financials to RISE S/4HANA Cloud.

These two systems will exchange data. From a licensing perspective, the on-prem system still uses perpetual licenses, and the cloud uses subscriptions.

You must ensure compliance in both domains. Users accessing both systems may need licenses for both (e.g., a plant user might still require an ECC user license and count toward the FUEs for S/4HANA if they use both).

No single license covers an on-prem and cloud system simultaneously – two contracts will govern you. One strategy is to coordinate the license types to avoid duplication.

For instance, you might minimize overlapping functionality so that users of System.

A doesn’t need System B, but that’s not always practical.

Another strategy is negotiating bundled pricing if SAP is amenable, such as a discount on remaining on-premises licenses when adopting RISE for part of the estate.

Technical integration in a hybrid scenario can also trigger indirect usage considerations. Suppose you’re on-prem and SAP sends data to the cloud (SAP S/4HANA).

Does SAP consider that indirect use? If both systems are properly licensed, exchanging data between two licensed SAP systems shouldn’t incur an extra fee.

However, clarity is still important—ensure that such integration is explicitly stated and not counted as third-party usage in your RISE contract.

When non-SAP systems are involved in a hybrid landscape (which they likely are, such as a CRM or a legacy system feeding SAP), manage them in the same manner as discussed earlier for indirect access.

From a contractual standpoint, running a hybrid means maintaining at least two sets of agreements: the RISE contract for the cloud and your existing license and support agreements for what remains outside RISE.

SAP’s sales team may push to convert everything, but you can opt for a partial conversion.

For instance, some customers convert licenses for one SAP system to RISE but keep their other contracts unchanged. SAP has offered “carve-out” arrangements to facilitate this.

Ensure that any licenses outside RISE are sufficient and appropriately restricted to the systems you keep on-prem.

Sometimes, SAP will adjust your entitlement during a partial conversion; for example, you trade in some user licenses but keep others for the on-premises portion.

Legally, it’s advisable to include language in your RISE contract acknowledging any integration with on-premises systems and confirming that SAP won’t be held against you.

Also, keep any existing discounts or special terms on your perpetual licenses for the portion you retain.

Sometimes, when customers renegotiate for RISE, they inadvertently relinquish favorable terms they had on the legacy side. Be cautious to preserve what you need for the systems that will coexist.

In a positive light, a hybrid model can be a transition strategy.

You might have a 5-year plan to move fully to the cloud, but you typically start with a hybrid approach. This can spread costs and mitigate risk (not “betting the business” on one big bang migration).

SAP recognizes this, and though they prefer a faster move, they will generally support phased approaches if the customer insists.

Some customers even employ a “pilot” approach: they move a smaller subsidiary or a particular module to RISE, evaluate the benefits, and then decide on a broader migration.

This is a sound strategy if you manage the license contracts accordingly to avoid paying for redundant coverage.

In summary, hybrid SAP environments will be common.

To do them successfully, maintain clarity on which licenses cover which users/systems, double-check integration points for compliance, and communicate clearly with SAP about your landscape so that your contracts reflect reality.

Although they may require more management overhead, they can save money and risk compared to an all-or-nothing move.

SAP Rise Cost Optimization Strategies for Enterprises

Transitioning to RISE, or generally modernizing SAP licensing, offers opportunities for cost optimization – if done thoughtfully.

Here are some strategies enterprises should consider:

• License Audit and Cleanup Before Transition: Conduct a thorough license audit of your existing SAP deployment to ensure a seamless transition to RISE. Identify inactive users, duplicate accounts, and users with overly high license types. By cleaning up (removing or reallocating those licenses), you can often reduce the baseline count you need to carry into the subscription. The example from the USU study showed a company with 1,000 users, but optimizing the number of FUEs needed from 487 to 260 is a dramatic savings. This kind of optimization (sometimes called license “right-sizing) directly lowers costs because RISE pricing is tied to that user count. Action item: Use tools or services to optimize named user licensing before negotiating the RISE agreement. SAP’s License Administration Workbench or third-party tools can help find these inefficiencies. Then, negotiate your RISE based on the optimized numbers, not the raw historical ones.
• Leverage Competitive Bids and Benchmarks: Even though SAP is unique, you can still create a sense of competition. For example, evaluate S/4HANA on-prem vs. RISE vs. third-party hosting. If you get a quote for running S/4HANA on Azure yourself (including license, Azure costs, and support) and compare it to RISE’s cost, you will have a benchmark. If RISE is significantly more, you have data to negotiate a better price with SAP (or consider not doing RISE). Internally, show SAP that you’ve done the math: SAP claims RISE can save 20% TCO in some cases​ – ask them to prove it for your case. If your analysis shows otherwise, use that in negotiations.
• Contract Length and Timing: SAP often gives better discounts for longer-term commitments. If you have budget stability and strategic certainty, opting for a 5-year subscription term instead of a 3-year term could yield a lower annual rate. However, be cautious: a longer term = a longer lock-in. Another timing strategy is to align your RISE purchase with SAP’s quarter or year-end – SAP may be more generous with discounts when it needs to meet sales targets. From the customer side, initiate your RISE contract at the optimal time relative to your existing contracts – for example, start right after your current maintenance period ends so you don’t “waste” the maintenance you paid for. Avoid periods where you would have to double pay (unless SAP gives a credit).
• Scale and Phasing: If moving simultaneously is too costly, consider phasing and staggering the investment to spread the costs over time. Consider moving some users to a first go-live and then gradually ramping up. In a RISE context, this means initially subscribing to fewer FUEs and then including contractual provisions to expand later at a locked-in discount. You could negotiate something like this: “Year 1 for 500 users at $X, and an option to increase to 800 users in Year 2 at the same per-user rate.” This prevents SAP from charging a premium when you scale up. Be careful: if you underbuy and try to add later without pre-negotiation, you might pay higher’ list’ subscription rates.
• Monitor and Optimize Cloud Usage: Once on RISE, treat it not as a fixed cost but as something you can optimize year over year. For instance, if you realize after a year that only 70% of your users are actively using the system, you might consider adjusting the license mix (perhaps more users could be of the “self-service” type rather than the “professional” type). While reducing contracted numbers mid-term is difficult, you can use this data at renewal to adjust downwards or push for better terms. Additionally, keep an eye on BTP consumption and other metered services – put governance in place so developers don’t accidentally spin up services that incur high charges. Often, cost overruns come from a lack of monitoring. Set up alerts or limits for cloud usage where possible.
• Indirect Access Risk Mitigation to Avoid Future Costs: As discussed, proactively address indirect access as part of cost optimization. While taking SAP’s offer for Digital Access at a discounted rate now might cost some money, it could save a lot more by avoiding a future audit penalty. Spending a bit to de-risk an indirect use scenario can be considered an investment to prevent a larger unplanned expense.
• Utilize SAP Programs and Incentives: SAP sometimes offers special incentives, such as a 1-year free BTP trial with RISE or conversion credits for certain products. Stay informed about these. For example, SAP’s RISE value calculator and incentive programs could be used to your advantage​. If SAP is pushing a new thing (like “GROW with SAP” for mid-market), even if it’s not directly for you, you might reference it to get comparable benefits. Also, if you’re a strategic customer for SAP, they might throw in some extras – maybe training credits or additional cloud services, which, while not the direct licensing cost, save you money elsewhere.
• Third-Party Support (if staying on legacy for a while): This is tangential, but some companies reduce costs by moving their legacy SAP support to a third party, such as Rimini Street, for a couple of years to save on maintenance fees and then allocate those savings toward the RISE subscription. This is a complex decision with risks, but it’s a tactic some use to afford the move to S/4HANA. Essentially, they stop paying SAP maintenance (if off contract or willing to accept risk) for the old system during the last 2-3 years of ECC, then use that budget to fund the new project.

Overall, cost optimization in SAP licensing is an ongoing process, not a one-time task. Moving to RISE simplifies certain cost line items, but it’s not automatically the cheapest route – you must actively negotiate and manage it.

Enterprises should involve their procurement and financial analysts early in the project planning to model different scenarios.

Remember, optimizing costs should never sacrifice compliance—the goal is to achieve the needed functionality and legal compliance at the lowest total cost of ownership (TCO).

With diligent planning and negotiation, many organizations have significantly reduced their SAP licensing costs (or at least achieved greater value).

For instance, optimizing licenses before migration was shown as a best practice by SAP experts, who note that reviewing and right-sizing licenses based on actual usage is critical before moving to S/4HANA or RISE​

These steps can free up a budget that can be reinvested in the digital transformation rather than just “keeping the lights on” for licensing.

Best Practices for SAP Rise Contract Negotiation and Compliance

Negotiating a complex agreement like RISE with SAP and managing ongoing compliance requires a strategic, well-informed approach.

Below are best practices and considerations to help executives and legal teams secure favorable contracts and maintain compliance over the long term.

Legal and Strategic Considerations

• Involve Stakeholders Early: Ensure that representatives from legal, procurement, IT, and SAP collaborate. A RISE deal isn’t just a legal document; it affects IT operations and financials. By incorporating cross-functional input, you can identify potential issues (for example, IT might highlight a necessary service that legal can then ensure is included in the contract).
• Clarity of Scope and Definitions: Insist on precise definitions in the contract. Ambiguity is the enemy. Define what a “user” is for licensing purposes, what “metrics” (like FUE or digital documents) mean exactly, and list which SAP components are included. Often, RISE includes core ERP, but does it also include a Solution Manager? Do you have access to specific SAP Fiori apps or integrations with other SAP cloud products? If it’s not spelled out, assume it’s not included. Ensuring clear documentation of terms and conditions prevents misunderstandings later​. For example, clearly define the boundary of indirect use by explicitly stating how third-party scenarios will be handled, so both parties are aware of the rules.
• Negotiating Audit Provisions: You can discuss the process while SAP maintains audit rights. Try to insert language that any audit will be conducted with reasonable notice (e.g., 30 days’ notice) and during normal business hours, etc. You might also consider negotiating to share the SAP audit results and allow for discussion before making any formal compliance claim. Some customers negotiate a right to remedy within a certain period before SAP can escalate the issue. At the very least, be aware of the audit clause and perhaps add an addendum that clarifies how indirect access will be assessed (since that’s often the trickiest part of an audit, objectively).
• Renewals and Escape Clauses: Consider the implications beyond the initial term. Negotiate renewal terms now – for instance, an option to renew for X years at no more than a Y% price increase. If you can’t get a fixed cap, try for at least a first renewal cap. Also, consider an exit strategy: While SAP may not let you easily revert to on-premise, you can still plan an exit from RISE (e.g., moving to a different SAP offering or simply discontinuing use). Negotiate assistance at the end of the term, like data export services or a provision that SAP will cooperate if you transition away. Perhaps include a clause that allows you to terminate early if certain SLA failures occur consistently. This is rare with SAP, but it’s worth considering.
• Liability and Risk Allocation: Ensure the contract has a balanced view of liabilities. SAP often limits its liability heavily. Verify if these limits align with your risk profile. For example, if an SAP failure causes downtime in your business, what remedies do you have? Usually, service credits are available, so check if they’re meaningful. Also, check intellectual property indemnification clauses. SAP typically indemnifies you for IP infringement by their software – make sure that’s included, especially with cloud services. For compliance risk, note if the contract states that you are responsible for certain types of misuse by users, etc., and manage that internally.
• Document Everything: During negotiation, you’ll have many discussions and emails. Keep a paper trail. If SAP makes a promise verbally (“Oh, don’t worry, that’s included”), get it in writing or add it to the contract. Internal documentation is also key – once the contract is signed, have a clear internal document summarizing all key obligations, so your operations team knows what to comply with. Many issues arise simply because the people managing the system are not fully aware of what was agreed upon in the contract.
• Utilization of External Expertise: Engage SAP licensing experts or legal advisors who have experience with RISE contracts. They can bring knowledge of what’s negotiable. Sometimes, knowing that another client has a particular term can give you the confidence to request it as well. SAP’s negotiators often do this; if you’re new to it, having experienced counsel can level the playing field.
• Strategic Alignment: Align the contract with your business strategy. If your company plans to make acquisitions, consider how new acquisitions using SAP will be handled under this contract (can they be added easily?). If you plan divestitures, consider whether licenses can be transferred or removed. If you have a large digital innovation plan, ensure the contract doesn’t hinder your use of SAP’s new technologies (or non-SAP ones). Try to future-proof the contract to the extent possible, knowing you cannot predict everything.

Common Pitfalls to Avoid

Several pitfalls have recurred over the years of SAP licensing, and being aware of them can save a lot of trouble.

Here are common pitfalls in SAP contracts and licensing to avoid​

1. Ignoring Actual Usage Metrics: A common mistake is signing a license for a specific number of users or usage amount and then failing to accurately track actual usage. This can lead to two bad outcomes – either overutilizing (and thus being out of compliance) or underutilizing (and thus paying too much for shelfware). Avoid this by instituting regular usage reviews. If you have 100 licenses but only 80 active users, consider reducing them at renewal. If you have integrations or indirect usage that generates documents, monitor these counts to ensure they align with your licensed usage. In short, don’t set and forget your licenses – manage them actively​.
2. Overlooking Product Scope: Some customers assume that getting S/4HANA covers everything ECC did and more. In reality, S/4HANA (especially in the cloud) may not include certain functionalities that were previously separate (for example, solutions like SAP APO or SAP SRM are separate from S/4). It’s a pitfall not to understand what you’re getting. Similarly, with RISE bundling, one might think, “We have RISE, so we have rights to all SAP cloud products” – not true, it’s still specific. Always check the scope of products and services covered​. If your business relies on a specific module, ensure it is listed in the module list. If not, plan to license it separately or find an alternative. Also, be mindful of what geographies or entities are covered. SAP licenses are usually enterprise-wide, but if you have subsidiaries using SAP, they’re all named in the contract, as affiliated companies are allowed to use it.
3. Neglecting License Upgrades/Changes: SAP software and the licenses evolve. A pitfall is signing a long-term deal and not adjusting it when SAP makes a relevant change. For example, SAP might introduce a new feature in S/4HANA that could benefit you, but if your contract doesn’t allow it, you might ignore it. Or SAP might deprecate a package and replace it with another – if you’re not paying attention, you might miss an opportunity to swap to a more efficient licensing metric. Keep in touch with SAP about product roadmaps. If SAP is moving towards a new licensing approach (like they did with Digital Access), evaluate if opting in benefits you. As one best practice, understanding SAP’s roadmap can increase your leverage and help you avoid being stuck on old, costly licenses​. For instance, knowing that SAP plans to phase out a certain license might allow you to negotiate a transition on your terms rather than SAP’s.
4. Underestimating Future Growth: Negotiating for the present and forgetting the future is a common mistake. Many fall into the trap of not planning for business growth or contraction. If your user count could double in three years due to expansion, and you haven’t secured price protections, you’ll face a budget problem. Conversely, if you might divest or shrink, locking in too high a commitment is wasteful. The pitfall is a lack of flexibility. To avoid this, incorporate scaling mechanisms. Perhaps consider tiered pricing (if we add X users, the price per user decreases or remains the same). Or at least have a framework for adding users (or even removing them, though SAP rarely allows reductions mid-term). The idea is not to get caught off guard by your business’s success (or reorganization)​. Overestimating needs is costly (resulting due to a lack of clear documentation and governance in shelfware), and underestimating and buying ad hoc is also costly (due to premium rates). Aim for accuracy and include safety margins or options.
5. Lack of Clear Documentation and Governance: Sometimes, companies sign a deal, but the relevant details are lost internally. For example, three years later, an IT manager might not be aware of the rule that states a certain system can only be used in a specific way. That’s when compliance issues happen. Avoid the pitfall of poor internal handover. After negotiation, create a summary of key license metrics, restrictions, and obligations. Internally published guidelines: e.g., “No connecting a new third-party system to SAP without clearing it with the licensing team,” or “User IDs must be cleaned up every quarter.” Also, document any special deals – if SAP gave you 100 extra user licenses for free to cover a subsidiary, note it so you don’t accidentally forget and think you’re overusing them. In the contract, ensure everything is written down – verbal assurances mean little later​. If something isn’t in the final contract, assume you do not have that right or concession. It’s better to over-document than under.

Avoiding these pitfalls largely comes down to diligence: know your usage and contract, and keep things clean and communicated.

Regular reviews, both internal and with SAP at true-up times, will catch many of these issues before they become major problems.

Future-Proofing SAP Rise Licensing Agreements

“Future-proofing” refers to designing your SAP agreements to accommodate evolving technology and business needs.

While no contract can cover every future scenario, you can incorporate provisions and strategies to maximize flexibility:

• Stay informed about SAP’s product strategy: SAP is continuously evolving – for example, pushing the cloud, introducing new services (such as AI and machine learning add-ons), or even packaging offerings like the recent GROW with SAP for mid-market companies. Monitor SAP announcements and discuss with your account executive how new offerings might fit your plan. If you foresee adopting some new SAP service (e.g., a new industry cloud module or an SAP AI service), it might be wise to negotiate a framework now. Perhaps an addendum to the contract states that you can pilot new SAP services for free for 3 months, or at least language that if you adopt new SAP cloud services, they co-terminate with your RISE and align with similar discounts. The idea is to avoid having completely separate negotiations from scratch for each new thing. SAP’s cloud focus is clear (they are aggressively driving customers to it), so future-proofing means embracing that and securing favorable terms for it early if possible.
• Modularity and Swap Rights: Consider incorporating swap rights or the ability to reallocate investments. For example, you may have invested heavily in an SAP module that your business might phase out in a few years. A swap right could allow you to convert those licenses to another SAP product of equal value. Or, in RISE, if you decide to switch from a private to a public cloud edition, is there a path without penalty? Or, if you want to shift your deployment from Azure to AWS (a different hyperscaler) for strategic reasons, can you do that within RISE? These kinds of provisions make your agreement more resilient to change. SAP won’t allow all swaps freely, but you may be able to get specific ones that matter to you.
• Economic Clauses for Changes: Consider including economic reopener clauses to address potential changes. For instance, if SAP’s pricing model changes significantly (they sometimes introduce new metrics or remove old ones), you can renegotiate relevant contract parts. One example is if SAP changes the definition of a FUE or license type. In this case, the customer can stick with the old definition for the term or renegotiate. It’s hard to get such clauses, but they underscore to SAP that you expect fairness if they alter the game. Also, negotiate that if SAP offers better terms to similar customers or a general program of improved terms (say, they suddenly allow some free inclusion you didn’t get), you should be able to get that, too. Essentially, it is a “most-favored-nation” type clause, although SAP rarely agrees to it explicitly. If market standards change, you can still attempt to include language about good-faith renegotiation.
• Ensure Flexibility for Mergers & Acquisitions: If your company is growing through acquisition, ensure the contract allows you to add newly acquired entities without incurring outrageous fees. On the other hand, if you divest part of the company, can those licenses be transferred, or can you reduce the number of licenses? SAP contracts often say licenses aren’t transferable outside the corporate family, but you can sometimes negotiate carve-outs to allow business transfers. In this sense, future-proof means your SAP contract doesn’t become a blocker in an M&A event. Legal teams should align the SAP agreement with likely corporate development activities.
• Digital Transformation and Third-Party Tech: Plan for Integration with Non-SAP Technology. You will likely use other cloud services, such as Salesforce or ServiceNow. Ensure that nothing in the SAP contract forbids or penalizes that. SAP sometimes tries to position itself as the center of IT, but you need freedom. Future-proofing ensures you can use a different analytics tool or multi-cloud strategy without breaching your SAP terms. Generally, SAP contracts don’t prevent it, but be aware of wording that might imply restrictions on benchmarking or using third-party services in conjunction with SAP. Remove or negotiate those out.
• Periodic Review and Optimization: Establish a process to review your SAP licensing position annually, or more frequently. The idea of future-proofing isn’t just at signing; it’s a continuous process. Each year, ask: Are we using what we thought we were using? Has SAP released something new that renders some licenses obsolete or offers a cost-benefit? Are we still getting value for money? By doing this, you can adjust proactively. Perhaps you negotiate an amendment mid-term to adjust metrics or take advantage of a new bundling SAP offer rather than waiting 5 years and realizing you missed out. SAP licensing is not static, so your management shouldn’t be, either.
• Partner with SAP (but verify): Engage with SAP as a partner in your success, but verify their honesty. If you have a good relationship with SAP, they may proactively advise you on more efficient licensing (this does happen in some cases, especially if it aligns with their goals). For example, they might ask, “We notice you’re using a lot of X; it might be cheaper if you moved to our new Y license.” Evaluate those suggestions; sometimes, they truly are win-win. Other times, they might be more of a win for SAP. Use independent analysis to verify the claims. Being open to new models while protecting your interests is a balancing act.

In essence, future-proofing ensures your SAP agreement can accommodate change with minimal friction.

While you can’t foresee everything, you can establish principles in the contract: flexibility, clarity, and options for renegotiation when needed.

With diligent ongoing license management, you will be in a strong position to handle any changes, whether they originate from SAP’s side or your business’s evolution.

Read about our SAP Advisory services for Rise.

☁️ How Redress Compliance Helps You Navigate SAP RISE | Make the Right Decision, Avoid Lock-In

Do you want to know more about our SAP Advisory Services?