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 the path to S/4HANA for customers. It includes the S/4HANA software itself and infrastructure (cloud hosting on SAP’s data centers or hyperscalers like AWS, Azure, and GCP), technical services, and support in one 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 – it is 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.

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 (e.g., annual) fee for the right to use S/4HANA, and this fee typically includes 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 many elements into one agreement with SAP. In contrast, a traditional setup might involve separate contracts (one with SAP for software, another with a hosting provider or hardware vendor, etc.). RISE’s single-contract approach simplifies procurement and gives the customer one central point of accountability​.

However, it also introduces new considerations, like 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, say, AWS) – this 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 needed, and a move from perpetual to time-bound usage rights.

In short, RISE’s subscription model differs from SAP’s historical perpetual-license model​ , offering more simplicity and 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 both traditional perpetual licenses and newer subscription models, and understanding the distinction is critical.

A perpetual license involves a one-time upfront fee to own the software indefinitely (typically accompanied by ~20% per year in maintenance fees 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 contract term, and support/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 who want long-term control (you can technically run the software as long as you want, even if you stop paying maintenance, albeit without updates).

Subscription licensing appeals to those who prefer lower initial costs and the flexibility of an OPEX model – but it requires continued payments to maintain access​.

In the RISE context, there is no perpetual option; RISE is 100% subscription-based, converting what used to be a license+maintenance model into a unified subscription service. This means RISE customers do not “own” the software licenses outright; instead, they get the right to use S/4HANA as long as their subscription is active.

One practical effect of this shift is on accounting and budgeting (CapEx vs OpEx) and long-term negotiating leverage. Once a company moves to subscription, SAP discontinues the sale of new perpetual licenses for that environment​.

SAP has explicitly positioned RISE as the exclusive way to obtain net-new S/4HANA capabilities, eliminating the option to buy additional perpetual licenses in the future for that installation​. 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 ability to customize, but it also means a higher burden of responsibility and upfront cost​.

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

In a cloud model, SAP (and/or 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 and 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, whereas 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 those into a per-user or capacity subscription. Additionally, cloud contracts have defined terms (e.g., 3-year RISE subscription), after which they must be renewed, potentially with price changes.

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

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

User-Based and Consumption-Based Pricing Structures

SAP’s licensing has historically been user-based but includes consumption-based elements. 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 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 (e.g., number of orders processed, amount of revenue managed, 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/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 (like the Business Technology Platform) often use a credit system or a metered consumption (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 = 1 FUE, 1 “Core” user might count as 0.2 FUE, etc., allowing 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) often charge based on authorizations rather than actual consumption, which can sometimes be less cost-efficient if many users are licensed but not all are active. Studies have found that authorization-based licensing can be 50–150% more expensive than true usage-based licensing on average.​

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 carefully sizing and optimizing 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.

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 takes on tasks like system monitoring, backups, and updates (especially 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 vs. 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 provided​.

Important contract terms to scrutinize include the subscription term length (and how renewal is handled), pricing structure and 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 checks).

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 might allow scaling down, a RISE contract typically locks in a certain capacity (e.g. number of FUEs and specific cloud resources) for the duration.

This makes understanding your needs upfront very important. Additionally, because SAP is bundling infrastructure, customers do not have a direct contract with the hyperscaler; SAP manages that relationship.​

As a result, any changes you might need to your cloud environment (scaling up capacity, changing regions, etc.) 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 (not exceeding licensed users or storage, for example), and cooperation during SAP audits. If the customer has existing SAP licenses being replaced by RISE, the contract may require those 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 demands thorough review so that executives understand what they’re signing.

Key terms like 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.

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 spans software, infrastructure, and services, which means multiple dimensions to negotiate.

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 overshooting the required FUE count.​

In one case study, a customer optimized their user licenses and reduced the required FUEs by 227, yielding 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 things 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” allowing 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 uptick after the initial term, so negotiating predictable renewal terms is critical​.

Another negotiation angle is clarifying the scope and responsibilities. Since the bundle includes many services, ensure that the contract documents (like the Scope of Services or SLA documents) are appended and clearly understood.

If you require certain services (e.g., specific integration support, data migration assistance, or extra sandbox systems), negotiate them into the deal upfront. Anything not in writing in the contract will likely cost extra later.

Make sure to discuss indirect access and third-party interface terms during negotiation. If you have a scenario that might otherwise incur indirect usage fees, clarify how that 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).

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 only in 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.

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 (from a hyperscaler) as part of the package. However, SAP’s pricing to you may include a markup or at least is not transparent line-by-line. SAP may receive incentives or discounted rates from the cloud providers, but these savings are not usually passed on in detail to the customer​. As a result, you might be paying a premium for convenience. Without transparency into the infrastructure cost, knowing your fair price ​is hard. Additionally, if SAP initially sizes your environment incorrectly (too low), you may need to increase the resources later, leading to additional costs. Conversely, you might be paying for unused capacity if it’s 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 lead to surprise 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 were “blindsided by additional fees” in the past for indirect use​. Under RISE, you need to 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. If this isn’t addressed, an audit could reveal indirect usage and trigger unbudgeted costs. Bottom line: inventory all third-party integrations to SAP and discuss them with SAP to avoid “gotchas.” It’s often possible to negotiate a known quantity of indirect usage into the deal or at least 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 instance, 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 budgeting. 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 (like several credits/year) – know 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, re-training users, and reimplementing custom code (especially if moving from on-prem highly customized to a cleaner cloud environment) all carry costs. SAP does offer some tools as part of RISE (like the SAP Readiness Check, and there may 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 SI – an additional spend outside the RISE contract. It’s important not to assume RISE is a turn-key migration; it’s primarily the licensing and technical infrastructure. Implementation services are usually separate.
• Future Growth and Volume Changes: If your business grows (transactions, data volume, users) beyond the contracted amount, you may face unexpected charges. A RISE contract might stipulate additional fees for excess storage, extra users above the FUE count, higher API call volumes, etc. 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, try to lock in pricing for additional blocks of users or extra storage now rather than at the moment of need when SAP could charge list prices.
• Vendor Lock-In Costs: RISE, by design, increases dependency on SAP’s ecosystem. If you become dissatisfied and want to switch away (say to another cloud or even back on-prem), the cost to do so can be prohibitive. Data extraction, license conversion, and possibly needing to re-buy perpetual licenses are all cost considerations. 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 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 (e.g., assistance with data export, a conversion right to a standard S/4HANA license if needed, etc., even if SAP is reluctant).

In summary, while RISE simplifies many known costs into one line item, hidden costs can 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 them.

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.

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, now woven into a cloud subscription context.

Indirect Access Risks

Indirect access (indirect use) is one of the thorniest issues in SAP licensing. It occurs when users or systems 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 the risk by providing a predictable metric for indirect usage (counting document types). It was offered under a one-time adoption 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 is something to verify.

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

The best practice explicitly clarifies it: either get a clause that your current known interfaces (e.g., between SAP and XYZ system) are permitted 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 (SAP could claim you exceeded fair use by letting too many outside systems 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.

Involve your legal team to review how the contract defines the “Use” of the software. 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-prem), 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 needs clear resolution via contract or internal policy (or both).

Audit Rights and Compliance Obligations

SAP has robust audit rights written into its contracts, and RISE agreements are no exception. Typically, the contract will grant SAP the right to perform license compliance audits, which could 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 check that the number of users, engines, and other metrics do not exceed what is licensed. 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 formally audit if needed, but some compliance checking may happen 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. Customers are obligated to cooperate with audits – failing to do so could 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 treat SAP audits as inevitable (SAP tends to audit every customer periodically, often every 1-2 years, unless you are in a special program).

Being unprepared for an audit can lead to nasty surprises. SAP audits can be rigorous, and unpreparedness 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 (like USMM and LAW for on-prem and user lists for cloud) 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, they might enforce license limits technologically (e.g., not allowing you to create more users than purchased).

But you should not rely on that entirely; contractually, you remain responsible for not exceeding use. Also, 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 see if you must periodically certify compliance.

Audit rights also extend to indirect use (as discussed) and proper user classification. If users are misassigned (like someone doing 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.

In summary, SAP’s audit and compliance framework continues to operate in the cloud era. Customers must uphold their end by monitoring usage and staying within bounds. Regular internal checks, good documentation, and cooperative yet careful responses to SAP audits will reduce the risk of compliance surprises.

The goal is to avoid “true-up shock,” where an audit finds you under-licensed, and you must scramble to find a budget for an unplanned purchase. By treating compliance as an ongoing process – effectively self-auditing – you can make any necessary adjustments on 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 (like account executives urging you to buy enough licenses or offering a deal to transition to a new model) to hard lines (auditors issuing formal compliance reports or even legal action if negotiations fail).

Notably, SAP has shown it is willing to litigate in extreme cases – the indirect access disputes with large customers proved that point. In most situations, however, SAP prefers to turn compliance issues into a sales opportunity.

For example, if an audit finds 500 users over your license, SAP will quote you the cost to rectify it (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 (say you regularly use more storage or more users), SAP will enforce an upgrade of your subscription. The contract likely gives SAP the right to adjust your fees if you exceed usage for a sustained period.

They may also enforce technical limits – for instance, capping system usage or issuing warnings. Ultimately, since RISE is a subscription, the big 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 important to recognize SAP’s strategic direction, too: SAP is highly motivated to transition customers to the cloud/subscription model (RISE) and away from perpetual licenses. They have told investors their intention to taper off the perpetual license business in favor of cloud growth.​

This means that the enforcement of legacy licensing might become even stricter to push customers into 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 turned into leverage for the customer to negotiate a better RISE deal (trading something SAP wants for something you need).

SAP’s enforcement also extends to the proper usage of contractual benefits. If your RISE contract includes something like two free sandbox systems or some BTP credits, using beyond those without proper licensing is a violation that SAP will eventually enforce fees on. So, staying within the lines of the contract not only avoids penalties but also avoids 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 that issue rather than fight.

This indicates that SAP’s enforcement approach can be a mix of firmness and incentive—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 (e.g., if SAP offers you an option to adopt digital access at a discount for X years, have that written into an agreement or at least 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 to actively manage compliance and keep an open if careful, dialogue with SAP. If you find yourself in 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 brings challenges and implications that must be planned for.

Migration Challenges and Licensing Implications

Contract Conversion

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 a more piecemeal mapping of old licenses to new ones) is gone; 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 usually give you credit for the remaining value of your licenses/maintenance (especially if you have a lot of unused software or prepaid support), but 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’d likely have to purchase new licenses (and SAP may not even be selling the old type anymore).

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 perhaps years of pre-paid maintenance. During the transition, maximizing the value of those investments is crucial. SAP has programs (like 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, in a contract conversion, SAP might allow you to discontinue those and maybe give a discount on the new S/4HANA licenses or RISE subscription.

However, often, it’s not a dollar-for-dollar credit. Negotiation here is key: try to bring over as much value as possible. If you’re mid-way through a support period, ensure you’re not double-billed (you might align the start of RISE with the end of a maintenance period you already paid).

Some customers phase out the conversion to avoid financial write-offs. For example, they might keep some less-used systems on existing licenses to continue utilizing what they bought while moving core systems to RISE. This can be tricky because SAP prefers an all-in migration, but partial conversions have been done depending on 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 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 for a transition period while the new system was built—this was explicitly allowed under both product conversion and contract conversion so businesses could gradually transition.​

In a RISE scenario, SAP usually gives you a window (say 6 or 12 months) to operate your ECC or old environment in a 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, but again, clarity is 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 lead to an audit finding (post-transition) that you were improperly still using the retired licenses.

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 (for compliance, historical reporting, etc.). 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 X years as part of the conversion. This is very important for legal and audit reasons on your side.

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

The migration to RISE has licensing implications that must be managed alongside the technical project. Plan the contract conversion carefully: the timing (to align with project milestones), the credit for existing licenses, the dual-use period, and the lock-in effect.

It’s often useful to have a licensing specialist or negotiator involved in parallel with your implementation team so that as the system gets built, the contracts are kept in step, and you don’t end up in a gray area.

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 might need licenses in both (e.g., a plant user might still need 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 try 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 (like a discount on remaining on-prem licenses when adopting RISE for part of the estate).

Technical integration in a hybrid scenario can also trigger indirect usage considerations. Suppose your on-prem SAP sends data to the cloud SAP (S/4HANA). Does SAP consider that indirect use? Typically, if both systems are properly licensed, exchanging data between two SAP systems you licensed shouldn’t cause an extra fee.

But clarity is still good—ensure that such integration is expected 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, e.g., a CRM or a legacy system feeding SAP), manage those just as discussed earlier for indirect access.

From a contractual standpoint, running hybrid means maintaining at least two sets of agreements: the RISE contract for the cloud and your old license/support agreements for what remains outside RISE. SAP’s sales team might push to convert everything, but you can choose a partial conversion.

For instance, some customers convert licenses for one SAP system to RISE but keep another contract 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 – e.g., you trade in some user licenses but keep others for the on-prem portion.

One must also consider operational complexity: hybrid means two different release cycles (cloud S/4 gets updates more frequently; on-prem, you update on your schedule), two different support models (cloud issues, you go to SAP cloud support; on-prem issue,s you might use your internal team or SAP support depending on your support contract). It’s manageable but requires planning.

Legally, it’s worth including language in your RISE contract to acknowledge any integration with on-prem systems and confirm that SAP won’t count against you.

Also, keep any existing discounts or special terms on your perpetual licenses in place for the portion you retain – sometimes, when customers renegotiate for RISE, they accidentally give up 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 start with a hybrid. 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 use a “pilot” approach: move a smaller subsidiary or a particular module to RISE, evaluate the benefits, and then decide on 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.

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 before converting 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 maintaining 1,000 users but, through optimization, reducing from 487 FUEs to 260 FUEs needed​ – that’s a dramatic saving. 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 RISE. 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 (license + Azure cost + support), and compare it to RISE’s cost, you will have a benchmark. If RISE is significantly more, you have data to push SAP for a better price (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 3 years could yield a lower annual rate. However, be cautious: a longer-term = 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 they need to hit 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’d have to double-pay (unless SAP gives a credit).
• Scale and Phasing: If moving simultaneously is too costly, consider phasing and staggering the investment. Maybe move some users to a first go-live and then ramp up. In a RISE context, that means initially subscribing for fewer FUEs and then including contractual provisions to expand later at a locked discount. You could negotiate something like: “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 under-buy 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 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 look to adjust the license mix (perhaps more of them could be “self-service” user types rather than “professional”). 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 part of cost optimization, proactively address indirect access (as discussed). 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 (for example, 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 cost by moving their legacy SAP support to a third party (like Rimini Street) for a couple of years to save maintenance fees and then put 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 negotiate and manage it actively. Enterprises should involve their procurement and financial analysts early in the project planning to model different scenarios.

Remember, optimizing cost should never sacrifice compliance—the goal is to achieve the needed functionality and legal compliance at the lowest TCO. With diligent planning and negotiation, many organizations have significantly reduced their SAP licensing spend (or at least gotten more value for it).

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 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 legal, procurement, IT, and SAP end-user representatives collaborate. A RISE deal isn’t just a legal document; it affects IT operations and financials. By having cross-functional input, you can catch potential issues (for example, IT might highlight a needed service that legal can then ensure is 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 do you get Solution Manager? Do you get certain 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, delineate the boundary of indirect use: explicitly state how third-party scenarios will be handled so that both sides know 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 negotiate that SAP share audit results and allow discussion before making any formal compliance claim. Some customers negotiate a right to remedy within a certain period before SAP can escalate. 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: Think 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 might not let you revert to on-premise easily, you can still plan an exit from RISE (e.g., moving to a different SAP offering or just ending 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 if certain SLA failures occur consistently, you have a right to terminate early (this is rare with SAP, but you can raise it).
• Liability and Risk Allocation: Ensure the contract has a balanced view of liabilities. SAP often limits its liability heavily. Check if those limits are acceptable to 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 see if those are meaningful. Also, check intellectual property indemnification clauses (SAP typically indemnifies you for IP infringement by their software – make sure that’s in there, especially with the cloud). For compliance risk, note if the contract says you’re 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 aren’t fully aware of what was agreed in the contract.
• Use of External Expertise: Engage SAP licensing experts or legal advisors who have done RISE contracts. They can bring knowledge of what’s negotiable. Sometimes, knowing that another client has a particular term can empower you to ask for it, too. SAP’s negotiators do this often; 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 acquisitions, consider how new acquisitions using SAP will be handled under this contract (can you add them easily?). If you plan divestitures, consider whether licenses can be transferred or removed. If you have a big digital innovation plan, ensure the contract doesn’t hinder using 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 classic mistake is to sign a license for a certain number of users or amount of use and then never track actual usage. This can lead to two bad outcomes – either over-utilizing (and thus out of compliance), or under-utilizing (and thus over-paying 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, keep an eye on those counts so they align with what you licensed. 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 that ECC did, plus more. In reality, S/4HANA (especially in the cloud) might not include certain functionalities that were separate before (for example, solutions like SAP APO or SAP SRM are separate from S/4). It’s a pitfall to not 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 particular module, ensure it’s listed. 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 when SAP changes something relevant. 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 dialogue with SAP on 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 easy. Many fall into the trap of not planning for business growth or contraction. If your user count could double in 3 years due to expansion, and you didn’t secure 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 negotiate tiered pricing (if we add X users, the price per user goes down or stays the same). Or at least have a framework for adding users (or even removing, though SAP rarely allows reduction mid-term). The idea is not to get caught off guard by your business’s success (or reorganization)​. Overestimating needs is costly (shelfware), and underestimating and buying ad-hoc is also costly (premium rates). Aim for accuracy and include safety margins or options.
5. Lack of Clear Documentation and Governance: Sometimes companies sign the deal, and then relevant details get “lost” internally. For example, three years later, an IT manager might not know the rule that says a certain system can only be used in X 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 publish 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, document it so you don’t accidentally forget and think you’re overusing. 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 before they become big problems.

Future-Proofing SAP Licensing Agreements

“Future-proofing” means designing your SAP agreements to adapt to changing technology and business needs.

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

• Stay Informed of SAP’s Product Strategy: SAP is continuously evolving – for example, pushing the cloud, introducing new services (AI, machine learning add-ons, etc.), or even packaging offerings like the recent GROW with SAP for mid-market. 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 add-on to the contract says you can pilot new SAP services for 3 months free, 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 getting favorable terms for it early if you can.
• Modularity and Swap Rights: Try to build in swap rights or the ability to reallocate investments. For example, maybe you 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 private to public cloud edition, is there a path without penalty? Or if you want to shift your deployment from Azure to AWS (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 might get specific ones that matter to you.
• Economic Clauses for Changes: Consider including economic reopener clauses. For instance, if SAP’s pricing model changes significantly (they sometimes introduce new metrics or remove old ones), you can renegotiate relevant parts of the contract. One example could be if SAP changes the definition of a FUE or license type, 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 a “most favored nation” type clause, though again, SAP rarely agrees explicitly, you can still try for language about good faith renegotiation if market standards change.
• Ensure Flexibility for Mergers & Acquisitions: If your company is growing by acquisition, make sure the contract allows adding newly acquired entities into the fold without outrageous fees. On the flip side, if you divest part of the company, can those licenses be transferred, or can you reduce the count? 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 probably use other cloud services (Salesforce, ServiceNow, etc.). Ensure 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 is ensuring you retain the option to use a different analytics tool or multi-cloud strategy without breaching your SAP terms. Generally, SAP contracts don’t prevent it, but watch out for 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: Build a process to review your SAP licensing position annually (or more often). The idea of future-proofing isn’t only at signing; it’s continuous. Each year, ask: are we using what we thought? 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 keep them honest. If you have a good relationship with SAP, they might proactively advise you of more efficient licensing (it does happen in some cases, especially if it aligns with their goals). For example, they might say “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 that arise, whether they originate from SAP’s side or your business’s evolution.

Conclusion

Summary of Key Takeaways

SAP’s RISE with S/4HANA represents a paradigm shift from traditional SAP licensing – moving from individually negotiated perpetual licenses and on-premise management to an all-encompassing subscription service.

This shift offers potential benefits in simplicity and agility but also introduces new challenges and considerations. Understanding the differences (subscription vs. perpetual, cloud vs. on-premise, user vs. consumption metrics) is foundational for any executive making decisions in this area.

RISE simplifies contracting (one master agreement for software, infrastructure, and services) and can accelerate cloud adoption, but it comes with trade-offs like reduced flexibility, long-term commitment to SAP’s cloud, and a need to carefully manage what is and isn’t included​

Contractual and Licensing Challenges

Executives and legal teams should approach a RISE contract with eyes wide open. Key contract terms – from SLAs to renewal clauses – must be negotiated to protect the company’s interests because SAP’s standard terms will favor SAP. The bundle of services in RISE shifts much responsibility to SAP but also places the onus on the customer to stay within prescribed usage levels or face extra fees.

If not anticipated, hidden costs can erode the expected TCO savings, whether indirect access fees, additional BTP consumption charges, or simply paying for unused capacity. Compliance doesn’t become moot in the cloud; compliance monitoring remains paramount.

Companies must diligently manage user access, integration usage, and other license metrics to avoid compliance issues – SAP’s audit rights persist, and their enforcement remains vigorous.

Transitioning from legacy licensing to RISE is as much a contractual negotiation as it is a technical migration. It requires aligning old and new agreements, handling legacy investments, and possibly running hybrid landscapes. Each of these steps has potential pitfalls (like dual usage rights or losing the safety net of perpetual licenses) that must be managed with careful contractual safeguards.

Recommendations for Executives and Legal Teams

Entering a RISE agreement (or any major SAP licensing decision) should be considered a strategic project. Do your homework and enlist expertise. Before signing, perform internal audits and usage analysis to determine exactly what you need—and negotiate based on that data.

Benchmark SAP’s proposal against alternatives to make an informed case for better terms. Negotiate thoroughly, covering not just price but future flexibility: push for terms on renewals, scalability, and clear scope definitions.

Getting favorable terms upfront is far easier than changing the contract later. During the contract’s life, establish governance to monitor compliance and value received continuously. Make license management a regular agenda item, not an afterthought.

This will help you catch any issues early – for example if your user count is trending above your entitlement, you can address it proactively rather than reactively under audit pressure.

Legal teams should pay particular attention to indirect use, audit, data handling, and termination clauses. Where possible, embed provisions that allow the company to adapt – e.g., rights in events of mergers/acquisitions and clarity on data extraction at the end of the term.

Also, maintain a productive relationship with SAP account management; open communication can sometimes lead to new licensing options or programs that could benefit your company (for instance, SAP sometimes quietly pilots new pricing models with friendly customers – an informed customer could take advantage of that).

However, never rely solely on SAP’s word – always get commitments in writing and validate claims (such as cost savings or included features) against independent sources or SAP’s documentation.

The lessons are still relevant for organizations not yet ready for RISE: optimize what you have, plan your roadmap, and keep your options open. SAP is clearly steering customers towards subscription cloud models​, so even if you stay on-premise for now, understanding these dynamics will help you eventually navigate the pressure to move.

In closing, RISE with SAP can deliver value—such as faster time to innovation and relief from infrastructure management—but it requires careful contract navigation and vigilant compliance oversight.

By applying the best practices outlined – from negotiation preparation​ to avoiding common pitfalls​ – executives and legal professionals can ensure that their SAP licensing agreements truly support the business’s goals rather than hinder them.

With a well-structured contract and proactive license management, companies can confidently embrace SAP’s latest technologies, knowing they have mitigated the major risks and secured a fair, flexible deal for the future.

When evaluating RISE (or any major change in SAP licensing), keep the organization’s long-term digital strategy focused. Does the contract enable or constrain our strategic objectives? Use that question as the guiding light.

Many CIOs and CFOs ask this as they weigh SAP’s cloud push. The answer will differ for each company, but armed with knowledge of the key issues and a clear strategy for negotiation and compliance, you will be positioned to make the best decision and drive a successful outcome.​

The goal is to transform with SAP on your terms—achieving innovation and cloud benefits while controlling costs and risks in a manner acceptable to your enterprise. With diligence and savvy negotiation, this balance is achievable.

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