Top 20 Things Every ITAM Professional Needs to Know About SAP S/4HANA License Management and Negotiations

Top 20 Things Every ITAM Professional Needs to Know About SAP S/4HANA License Management and Negotiations

SAP S/4HANA license negotiation is a high-stakes challenge for ITAM professionals managing enterprise software.

With the shift to S/4HANA, organizations face new licensing models, intricate contract terms, and potential pitfalls, from RISE with SAP cloud bundle lock-ins to SAP indirect access fees (now monetized via SAP Digital Access).

A successful S/4HANA contract strategy requires understanding the full landscape: license types and metrics, audit clauses, migration programs, third-party support options, and savvy negotiation tactics.

This pillar guide distills the top 20 things every IT asset manager and sourcing leader should know about optimizing SAP S/4HANA license management and negotiations.

Armed with these insights, you can secure flexibility, control costs, and ensure compliance in your SAP agreements.

1. Master the SAP S/4HANA License Models (Perpetual, Subscription, RISE, Hybrid)

SAP S/4HANA Licensing Models Explained: Perpetual, Subscription, RISE, and Hybrid

SAP S/4HANA offers multiple licensing models, each with pros and cons for cost and flexibility:

• Perpetual (On-Premises) – You purchase S/4HANA licenses outright (CapEx) and deploy on your infrastructure. There’s a high upfront cost, followed by ~20% annual support fees for maintenance and upgrades. The upside: you own the licenses with indefinite usage rights, even if you stop paying maintenance (though you’d forego updates). This model gives maximum control; you can choose where to host and even pause support, but you carry infrastructure costs and responsibility for keeping systems current.
• Subscription (SaaS or Hosted) – Instead of buying licenses, you pay a recurring subscription (OpEx) for S/4HANA, often hosted in SAP HANA Enterprise Cloud or a public cloud. This is like leasing a car instead of buying. The subscription typically bundles the software license, infrastructure hosting, and standard support into one monthly/annual fee. There’s a lower upfront cost, and SAP manages updates/upgrades for you. However, if you stop subscribing, you lose the right to use the software altogether. This model provides agility (scaling up or down at renewals) but can cost more over a long horizon and locks ERP spend into ongoing budgets.
• RISE with SAP (All-in-One Cloud Bundle) – RISE is SAP’s flagship cloud offering launched in 2021, packaging S/4HANA Cloud (private or public edition) with cloud infrastructure, SAP basis services, and support under a single contract. It’s marketed as “business transformation as a service.” The catch: RISE is subscription-only and requires you to trade in or relinquish existing perpetual licenses for credits. You’re essentially renting a fully SAP-managed environment. This one-stop shop simplifies vendor management (“one hand to shake”). Still, bundling means less flexibility – you can’t separately choose a different cloud provider or drop a component like a database or support without leaving RISE entirely. Hybrid deployment (some systems in your data center, some in the cloud) isn’t an option under a pure RISE deal.
• Hybrid Approaches – Many enterprises adopt a mix. For example, you might keep some on-premise S/4HANA systems under perpetual licenses (or Bring Your License in a cloud IaaS environment) while using S/4HANA Cloud subscriptions for certain new installations or regions. SAP supports hybrid licensing, but careful coordination is needed to avoid overlapping costs or compliance issues. The S/4HANA licensing model is modular enough to let you combine deployment types, just ensure contractually that you have the right to deploy in both scenarios.

Why it matters: Choosing the right model is foundational. It impacts TCO, cash flow (CapEx vs. OpEx), upgrade cadence, and leverage in negotiations.

Evaluate your company’s appetite for upfront investment, control requirements, and long-term roadmap.

Many companies conduct a 5-10 year cost comparison of on-prem vs. cloud vs. RISE before making a decision.

Often, a hybrid strategy can balance risks – e.g., keep core systems on owned licenses for stability, use cloud subscription for fast innovation projects.

Read SAP S/4HANA Licensing Overview.

2. Understand the S/4HANA Modular Structure (Digital Core + Add-Ons)

SAP S/4HANA Licensing: Digital Core vs Add-Ons (Modular Licensing Explained)

SAP S/4HANA’s licensing is modular. You start with the Digital Core (Enterprise Management) and then license additional modules (“engines”) as needed:

• Digital Core: The base S/4HANA package includes the essential ERP functions (Finance, HR, Manufacturing, Sales, Procurement, etc.). SAP has bundled more functionality into the core than in ECC, sometimes in a simplified form. For example, S/4HANA comes with embedded analytics, and basic versions of Extended Warehouse Management (EWM) or Transportation Management are included in the core license for many customers. This means you might not need separate licenses for capabilities that used to be standalone in ECC, if the embedded version meets your needs. Always verify what “embedded” covers – it may be limited scope (e.g., basic warehouse management vs. advanced).
• Add-On Modules (Engines): For advanced or industry-specific capabilities, S/4HANA still uses separate licenses. These add-ons often use metrics aligned to business usage rather than named users. For instance, you might license SAP Treasury based on the number of bank accounts, Advanced Supply Chain Planning by the number of products or planning runs, Extended Warehouse Management (advanced) by the number of warehouse sites or transaction volume. Hundreds of such metrics exist, from revenue-based licensing to order counts. It’s critical to identify which modules you truly need and understand their metric licensing. By an operational metric, this means you must forecast growth (e.g., if your order volume doubles, license requirements (and costs) could double too).
• Modularity = Flexibility: The upside of SAP’s modular approach is that you “pay-as-you-grow”. You can start with core ERP and then activate extra modules later as the business requires. You’re not forced to buy an entire suite upfront if you won’t use it. This can control initial costs. However, it requires diligence to scope your requirements – ensure that the modules you do need are included. If the Digital Core or existing licenses don’t cover a critical process, you must budget for that engine license. A common trap is assuming something is included, only to face an additional purchase later (e.g., realizing advanced Trade Compliance or Global Tax functionality costs extra).
• No Double Licensing: One nice change in S/4HANA’s approach – if a user exclusively uses a separately licensed engine and does not use the core ERP, you may not need to assign them a core user license. This avoids double-licensing a user for both the core and an add-on. For example, if you have a team that only works in a standalone SAP CRM add-on integrated with S/4, those users might only need the CRM engine license, not an S/4HANA named user. Always check SAP’s rules on this to avoid unnecessary user licenses.

Why it matters:

Understanding the modular structure helps you avoid buying what you don’t need and ensures you don’t miss what you do need.

In negotiations, line-item definition clarity is key – make sure each licensed component (especially engines) is clearly defined in the contract, including metrics and entitled use, so there’s no ambiguity later.

If your S/4HANA contract is cleanly modular, you can often negotiate carve-outs or swaps (dropping an unused module, or substituting one engine for another of similar value) during renewals – something to strive for to keep flexibility.

Read Differences Between SAP ECC and SAP S/4HANA Licensing.

3. Classify Users by License Type (Professional, Functional, Self-Service, etc.)

SAP S/4HANA Licensing: Cut Costs with Smart Named User Classification

Not all SAP users are created equal – nor should they be priced equally. S/4HANA (on-premise) revamped the traditional named user license categories into a simpler tiered model:

• Professional Use: Full operational access across all applicable modules. These are your power users and typically the most expensive named license. In ECC days, this was “Professional User” and could list for ~$3k–6k one-time (plus maintenance). In S/4, Professional remains the top tier. Any user performing broad transactions in multiple functional areas likely needs this.
• Functional Use: A mid-tier license for users working in a specific domain or a limited set of modules (analogous to ECC’s Limited Professional). For example, a procurement clerk who only uses procurement and perhaps inventory transactions might be a Functional user. This license costs less (often 50% or less of a Professional user price).
• Productivity or Employee (Self-Service) Use: A low-level license for casual, infrequent tasks or self-service scenarios. Think of employees who just enter timesheets, or managers who approve workflows, or run simple queries. These were known as Employee or ESS users in ECC. They are the cheapest named user licenses (often a few hundred dollars list price).
• Developer and Other Special Roles: S/4HANA also has developer licenses (for non-production use, mainly for configuring and coding) and likely a few specialized types (like SAP Runtime professional if only using certain systems, etc.). Developer licenses often cost similar to Professional in S/4 (since a developer can potentially do anything in the system), and typically each developer needs both a developer license for non-prod and a normal user license if they access production.

License type matters immensely for cost.

A Professional user might cost 4-5x a Functional user, or 10x a Self-Service user. In one real-world S/4HANA deal, Professional users were about $4,000 each, while limited users were under $1,000.

Therefore, optimizing user classification is the fastest way to save on licenses.

Every user should be evaluated: what transactions do they perform? Many could likely be downgraded to a lower category if they don’t need full access.

For instance, a department manager who mostly runs reports and approves requisitions might not need a Professional license if no hands-on transactional work beyond their department.

Also, SAP’s audit tools will flag any users not assigned a license type and count them as Professional by default.

So it’s crucial to maintain proper assignments in the user master. Implement a process to regularly review user roles vs. license type and adjust down where appropriate.

Some organizations perform quarterly internal license true-ups to reclassify users who have reduced usage.

Negotiation tip:

Get clarity on the named user definitions in your contract. Ensure the contract (or an attached document) defines what a “Professional Use” vs. “Functional Use” user can do. This prevents SAP from later claiming a user should be in a higher category. Standard definitions exist, but if you have edge cases, clarify them.

And if you suspect SAP’s delivered license types don’t fit your user population well, discuss during negotiation if there’s a need for a custom license type or a more granular tier (occasionally, very large customers negotiate unique user definitions, though SAP tries to avoid that now).

At minimum, know your user counts in each category and negotiate the price for each accordingly – don’t just accept SAP’s first allocation or pricing.

Read SAP S/4HANA Licensing Costs and Models for CIOs, Procurement, and Finance

4. Leverage Full User Equivalents (FUE) in Cloud Contracts

SAP S/4HANA Licensing: FUE Model Explained for Cloud & RISE with SAP

In SAP’s cloud licensing (including S/4HANA Cloud and RISE with SAP), the concept of Full User Equivalents (FUEs) is central.

This is essentially a credit-point system for user licensing, designed to provide flexibility in user mixes:

• What is an FUE? Think of it as a weighted unit of user capacity. SAP assigns a weighting factor to each user license type. For example, 1 “Advanced” user = 1.0 FUE, 1 “Core” user = 0.2 FUE, 1 self-service user = 0.033 FUE (illustrative ratios). These categories map roughly to Professional, Functional, and Employee tiers, respectively (SAP sometimes uses slightly different names in the cloud context).
• How it works: Instead of contracting for, say, 100 Professional + 300 Functional + 600 Self-service users separately, you might contract for a pool of FUEs that covers all usage. For instance, those numbers might equate to 1001 + 3000.2 + 600*0.033 ≈ 100 + 60 + 19.8 ≈ ~180 FUEs total. Your subscription might simply say you are entitled to 180 FUEs, which you can allocate across user types as needed. This approach simplifies the contract on paper (one metric instead of three categories of counts). It also provides some agility: if you later decide you need more heavy users and fewer light users, you can reallocate within that FUE pool (to a point) without amending the contract.
• Pitfalls of the FUE model: The flexibility comes with complexity under the hood. Estimating FUE needs requires accuracy. If you overestimate and buy too many FUEs, you’re overpaying (since you pay per FUE). If you underestimate or misclassify and use more FUEs than purchased, you’re non-compliant and could face a true-up or audit exposure. A common mistake is misclassifying users to reduce FUE count – e.g., labeling a power user as a “Core” user (0.2 FUE) when in reality their activities should count as Advanced (1 FUE). In an audit, SAP will recalculate based on actual usage patterns and roles, and you could be found significantly short on licenses. The opposite issue also happens: some customers, unsure of categorization, assume many users need the highest category (1 FUE each), resulting in an overly high FUE count and cost.
• Managing FUEs: If you go with an FUE-based contract, invest time in mapping each user role to SAP’s user definitions carefully upfront. SAP provides guidance on what constitutes an Advanced vs Core user – use it, and leverage tooling or expert services to simulate your user base in FUE terms. Also note, FUE contracts often have a minimum purchase (e.g., RISE private cloud might have a 40 FUE minimum buy-in), so even if your math says 30 FUE, you pay for 40. Finally, remember that, unlike named-user licenses (where excess users can sometimes be addressed via swapping licenses around), FUEs are more rigid until renewal – you generally cannot reduce the FUE count mid-term if you over-estimate, so getting the number right is critical.

Why it matters:

FUE licensing is meant to simplify user-based subscriptions, but it introduces a layer of abstraction that can obscure actual usage.

During negotiations, ensure you get transparency by having SAP show how many of each user type they assumed in the FUE calculation and the ratio.

Also, negotiate what happens if your user mix shifts.

For example, if you anticipate a scenario of more light users and fewer heavy users in year 2, can you adjust the mix without increasing cost (assuming total FUE stays the same)?

Knowing these details will help you avoid over-committing or falling foul of compliance in an FUE model.

Read SAP S/4HANA On-Premise vs Cloud Licensing.

5. Grasp Indirect Access vs. Digital Access Licensing

SAP S/4HANA Licensing: Indirect Access vs. Digital Access Explained

One of the thorniest SAP licensing issues historically is indirect access – when people or systems use SAP functionality without directly logging into SAP.

Classic example: a customer portal or a mobile app that creates an order in SAP in the background.

Under old ECC licensing, SAP often required a named user license for each individual or device that triggered SAP transactions indirectly.

This led to high-profile disputes (e.g., the Diageo case where SAP sought license fees for Salesforce-to-SAP interactions).

S/4HANA introduced a new model called Digital Access to tackle this in a more modern way:

• Digital Access = Document Licensing: Instead of licensing the users of third-party systems, SAP licenses the outcomes in S/4HANA. SAP identified 9 document types that are the most common results of digital integration (e.g., Sales Order, Invoice, Delivery, Purchase Order, etc.). Under Digital Access, if external systems create or read those documents in S/4, you need to license those documents. Typically, this means purchasing “Document Packs” – e.g., in blocks of 1,000 documents/year for each document type or an allotment of total document count. For instance, 10,000 sales orders generated via non-SAP front-ends would consume 10 packs (if sold in packs of 1k).
• Transparency and Predictability: The idea is that documents are easier to count and forecast than tracking each technical user or integration. It shifts the licensing to something more directly tied to business activity – if your digital channels drive a lot of orders, you pay for that volume. This can prevent scenarios where, say, 500 indirect users caused 5,000 orders and SAP demands 500 user licenses (which might cost far more than 5,000 documents). Under ECC indirect rules, any third-party use required a named user; under Digital Access, those 5,000 orders might be, for example, five packs of documents – potentially a lower cost. It also removes the ambiguity of “who is a user?” – you pay for the documents regardless of who or what created them.
• Not Automatic – You Must Opt In: Digital Access is optional. Customers can still stick with traditional named-user licensing for external access if they prefer (SAP still allows an “Indirect Static Read” user or a blanket technical user license approach in some cases). To use Digital Access, you essentially sign up for that model in your S/4HANA contract and likely purchase a certain initial number of document packs. If you do nothing, your default position is still that any indirect usage could be subject to named user requirements, and in an audit, SAP could assess documents retroactively and charge you then. If you don’t license Digital Access upfront, SAP auditors may count your documents later and present an unexpected bill. So it’s important to decide your approach rather than ignoring the topic.
• Audit and Compliance Implications: The Digital Access model, introduced a few years ago, came with an Adoption Program – SAP for a while offered existing customers a deal to estimate their document usage and convert some existing license value to cover digital access (often with some free documents included). Check if such programs are (or will be) available to you – they can ease the transition. If you embrace Digital Access, monitor usage of those documents just as you would user counts. Staying within purchased volumes is key because excess will require true-up purchases. On the plus side, this model means SAP auditors focus on document counts rather than hunting for “ghost users” in your system, which can be a more straightforward compliance exercise if you have good system analytics.
• Remaining Risks: Digital Access covers the creation of documents. What about read access? SAP’s policy generally is that static read-only scenarios (e.g., an external system querying SAP data that doesn’t result in new records) may be allowed if you negotiate it – hence the recommendation to include an “Indirect Static Read” clause that permits certain data exports without extra fees. If you don’t, even read access by an external app could be interpreted as “use.” Additionally, Digital Access doesn’t automatically cover other SAP products (like if Salesforce queries SAP, that’s S/4’s digital access; but if Salesforce updates SuccessFactors, that’s a different SAP product’s licensing). So, consider your whole SAP landscape.

Key point:

Indirect access hasn’t gone away in S/4HANA – but you have a clearer way to license it. You need to make a conscious choice: stick with traditional named users (and possibly over-license to cover all external parties), or adopt Digital Access document licensing.

Most modern SAP contracts lean toward the document model because it’s more predictable and often cost-effective for large external user bases.

Just be sure to negotiate the terms of it in your contract, rather than leaving it vague.

6. Mitigate Digital Access Costs and Indirect Use Risks

Having an indirect/digital access strategy is essential to avoid nasty surprises. Here are practical steps to manage this area:

• Audit Your Integrations: Before moving to S/4 (or ASAP if you’re already live), catalog every third-party system, interface, and custom application that connects to SAP. Identify what actions they perform – do they create any of the nine document types in SAP? Do they just read data? For example, if you have an e-commerce website creating sales orders in S/4HANA or a CRM pulling customer data from S/4, list those out. This assessment tells you your indirect usage footprint.
• Decide Named Users vs. Document License: For each integration, determine if it’s better to cover it via existing named user licenses or via Digital Access. If an external system is used by a handful of internal users, sometimes adding a few user licenses for them (or using existing ones) is sufficient. But if it involves thousands of external users or high-volume document creation, Digital Access is likely more economical. SAP’s Digital Access Adoption Program (if still available) can offer a one-time conversion where you trade some license capacity for a chunk of digital documents – consider leveraging that if offered.
• Negotiate Contract Clauses: As part of your S/4HANA agreement, explicitly address indirect usage. Ideally, include:
  • An Indirect Static Read clause – this allows certain read-only access by external systems without additional licensing. For example, a third-party business warehouse pulling data from SAP for reporting, or exporting SAP data to a data lake, should not require extra licenses if it’s read-only and static (no updates back into SAP). Many customers successfully negotiate this clause so that pure data replication or viewing isn’t charged.
  • Definition of “Use” and “User” – ensure the contract definitions don’t inadvertently count API calls or non-human devices as users. Clarify that automated system access is covered under the document model or technical user licenses as appropriate, not counted as separate named users.
  • Digital Access terms – if you go with document licensing, nail down the price per document or per pack, which document types are covered, and if possible, negotiate some included volume or discount on overages. For instance, you might get SAP to include X number of documents free per year, or agree that any documents over your contracted amount will be charged at the same discounted rate as the initial packs (versus list price). If you have clout, you could even negotiate a cap: e.g., if document counts explode unexpectedly, there’s a maximum fee or a chance to true-up at a fixed price. The goal is to avoid open-ended liability.
• Monitor Continuously: Implement monitoring on interfaces. S/4HANA provides a Digital Access Evaluation Tool that can count the relevant documents created. Use it periodically to ensure you’re within your licensed amounts. Also, monitor changes – if IT is adding a new integration or digital channel, assess the indirect licensing impact before it goes live. It’s easier to address licensing upfront than retroactively in an audit.
• Educate Stakeholders: Ensure your architects and developers understand that connecting a new system to SAP has license implications. Sometimes projects spin up a quick integration without involving license management – that’s a risk. Set up a governance step that triggers a license review whenever a new SAP integration is initiated (e.g., does it add new users or increase document volume?).
• Be Ready to Optimize: If you find that certain integrations are generating high volumes of documents of a certain type, see if you can mitigate. For example, some customers filtered out trivial updates or batched transactions differently to reduce document count. It’s somewhat extreme, but if digital access costs become an issue, you may optimize business processes to stay within thresholds (much like optimizing cloud consumption).

Remember:

Indirect usage is a classic audit hotspot. Don’t leave it to chance. By proactively setting the rules in your contract and keeping an eye on usage, you transform indirect access from a lurking liability into a budgeted, manageable cost.

As one recommendation puts it: Never assume indirect use is free – if it’s not explicitly free, it’s not free!.

7. S/4HANA Migration Is Not a Free Technical Upgrade

SAP S/4HANA Licensing: Why ECC to S/4 Migration Isn’t a Free Upgrade

One of the biggest misconceptions among SAP customers is that moving from ECC to S/4HANA is just an upgrade that shouldn’t cost licenses.

In reality, S/4HANA is treated by SAP as a new product line – you can’t use your old ECC license to run S/4.

This means new licenses are required, either via fresh purchase or a conversion program. If you simply install S/4 without a new contract, you would be out of compliance.

Key points to know:

• Budget for New Licenses: Companies have been caught off guard by this. Perhaps millions were spent on ECC licenses over decades, yet moving to S/4 can mean spending millions more. Make sure executives understand early: without a negotiated transition deal, we essentially pay for S/4HANA from scratch. This should be budgeted as part of the migration project (license cost can be one of the largest components of S/4 transformation budgets, aside from implementation services). Starting financial planning 1-2 years in advance is wise.
• 2027 End of ECC Support Deadline: SAP has set a date (currently end of 2027, with possible extended maintenance to 2030 for extra fees) to end mainstream support for ECC. This creates a ticking clock that SAP sales will use as leverage. Delaying S/4 adoption will likely mean higher support costs on ECC (SAP has already added a premium for extended ECC support). Conversely, moving sooner can bring incentives – SAP often provides extra discounts or credits to early movers to drive S/4 uptake. Don’t expect those incentives to get better over time; typically, they taper off as the deadline nears, and SAP knows many customers have no choice.
• Plan the Transition Path: There are generally two paths – “Product Conversion” (largely obsolete now) and “Contract Conversion” (the main approach, covered in the next point). Regardless, it’s not automatic. You need to engage SAP (and possibly a licensing partner) to choose the best method. If you just buy S/4 licenses outright without conversion, you may be forgoing credits for your ECC investment. If you wait until 2028, you might lose negotiating leverage and face a rushed, expensive deal under time pressure. Early planning (at least 12-18 months before your desired go-live) is recommended.
• Parallel Running Costs: Consider that during the migration, you might run ECC and S/4 in parallel (for testing, phased rollout, etc.). This can mean temporary double costs – paying maintenance on ECC and subscription/support on S/4. SAP does not automatically give a break for that overlap. You should factor this into the budget and, if possible, negotiate some accommodation (for example, some clients negotiate a short period of free S/4 use for testing, or tapering ECC maintenance down as users migrate). It won’t be free, but being aware prevents budget shock.
• Extended Support vs. Third-Party: If you truly can’t move by 2027, one expensive option is paying SAP’s extended maintenance (which might be +2% or more on fees per year). Another is switching to third-party support for ECC to bridge the gap (more on that in point 17). Either way, those costs should be weighed against the cost of accelerating the S/4 project. Sometimes paying a bit more in license conversion now is cheaper than 3 years of hefty maintenance premiums on ECC.

Bottom line:

From a licensing perspective, treat S/4 migration as a chance to renegotiate your relationship with SAP. It’s a “re-buy” of your ERP rights, so you want to get it right.

Leverage the situation (SAP wants you on S/4; you want a fair deal) – that means not just accepting list prices or standard terms.

If you go in thinking it’s just a technical upgrade, you’ll lose that leverage and might end up overpaying for S/4 or scrambling under time pressure later.

Instead, engage early, do your homework, and turn the migration into an opportunity to optimize your SAP investment.

8. Use SAP’s License Conversion Programs and Credits

SAP S/4HANA Licensing: How to Maximize ECC Credits in a Contract Conversion

To ease the financial impact of moving to S/4HANA, SAP has offered license conversion programs for existing customers.

These programs are essentially about giving you credit for the investment you’ve already made in ECC licenses, applied toward your new S/4 licenses – but the devil is in the details and negotiation.

Two main programs (historically):

• Product Conversion: An older program (now largely phased out) that allowed swapping certain ECC licenses for equivalent S/4 licenses on a product-by-product basis. For example, you could convert an ECC Financials user license to an S/4HANA Finance user license at some ratio. This was somewhat rigid and had many conditions. Very few customers use this now because SAP moved to the next approach.
• Contract Conversion: The prevalent method today. Think of it as trading in your old contract for a new one. SAP will evaluate the net value of your existing ECC licenses (typically based on what you paid and how much support value they carry) and then offer a credit of some sort toward the S/4 licenses you need. It’s more flexible than product conversion – you don’t have to match one-for-one on license types; instead, you negotiate an overall deal. In effect, you terminate your ECC license contract (or a portion of it) and sign a new S/4 contract. The credit from the old is applied to reduce the cost of the new.

How to maximize the value:

• Clean House First: Before you go into a contract conversion negotiation, perform an internal license audit on ECC. Identify shelfware, inactive users, and unused engines. Why? Because SAP will not give you credit for licenses you’re not using. If 15% of your users never log in, or you have modules installed but not really utilized, SAP’s assessment will deem them of little value (and rightly so). It’s better if you can terminate or drop those licenses before conversion (if your ECC contract allows) or at least exclude them from the conversion count so that you’re not trading them in for zero credit. Some contracts allow a “partial termination” of unused licenses at renewal – consider doing that to streamline what you need credit for.
• Know Your Maintenance Base: Typically, the credit SAP offers is related to the support fees you’ve been paying. For instance, SAP might say: “We’ll credit you X years’ worth of maintenance on the licenses you give up.” If you’ve been paying $1M/yr in ECC maintenance, they might offer a credit of, say, $2M toward S/4 (just an illustrative example). Another approach SAP uses is to map your licenses to approximate S/4 equivalents and give a percentage off the S/4 list price. Reports from customers vary – some have gotten 40-80% of their original license value as credit, while others have gotten much less. The range is wide because it depends on how much of your ECC footprint will be used in S/4 (SAP is less generous if you own products that have no S/4 equivalent or that you never deployed).
• Negotiate, Negotiate: The conversion offer from SAP is negotiable. Don’t take the first quote. Use the looming ECC deadline as leverage (SAP needs these conversions, too). If they initially offer 50% credit, push for a higher percentage. Emphasize your long loyalty and significant spend on maintenance over the years as justification for more credit. If you have shelfware that you cannot drop, argue for at least some value for it (especially if it was SAP’s idea you bought it!). The goal is not to leave money on the table – every percent more in credit is less cash outlay for you.
• Ensure Incentives Are Included: If SAP’s trying to hit a quarterly number, they might throw in extra incentives – e.g., “We’ll extend your ECC support at no charge for 6 months during the transition” or “We’ll give you 2 free years of SAP Cloud Platform if you sign now.” These are valuable; get them in writing (likely in the contract or an amendment). Sometimes these extras are not in the boilerplate proposal and only come out if you ask or hint you’re considering delaying your decision.
• Future-Proof the Conversion: One risk is converting all your licenses and later realizing you needed more of something or less of something. In the contract conversion, try to build in flexibility – e.g., maybe convert 90% of your licenses and leave 10% as an optional component that you could still use on ECC if needed for a while (this is complex, but some negotiate “coexistence” periods). Also, clarify what happens if you need to true-up S/4 licenses later – do you get the same discount/credit applied? Ideally yes.

Also, note that if you move to RISE with SAP (subscription), that is effectively a contract conversion too – you discontinue maintenance on on-prem licenses and start fresh with a subscription.

In a RISE deal, those old licenses are gone (not parked for later).

Make sure SAP gives you appropriate credit for them in the RISE pricing.

For example, if you had $5M of ECC licenses, you should see some significant incentive on your RISE quote reflecting that (either a big discount on subscription or some free services). If it’s not evident, call it out.

Takeaway: SAP’s conversion programs are designed to reduce the cost barrier to S/4HANA, but they are also somewhat opaque.

By analyzing license usage and leveraging data to push SAP, you can transform conversion into a “license exchange” that favors you, not just SAP.

Aim to carry over maximum value from ECC to S/4, minimize waste (shelfware), and lock in any special incentives during the deal.

9. Structure Multi-Phase Migrations to Minimize Double Costs

Not every company will migrate to S/4HANA in a big bang.

Many will do a phased migration – whether by module (e.g., Finance first, then Sales), by business unit or region, or by a two-tier model (keeping ECC for some legacy operations while new acquisitions go to S/4).

When planning a phased approach, licensing and costs must be carefully managed to avoid paying twice or falling out of compliance:

• Parallel Production Environments: During migration, you might have ECC and S/4 running side by side. For example, in year 1, you move half of your users to S/4, while half still use ECC. If you’ve done a contract conversion (traded in ECC for S/4 licenses), technically, you shouldn’t be using ECC anymore – that’s a problem. To accommodate this, negotiate temporary usage rights for ECC post-conversion. SAP has been known to allow a defined coexistence period where you can continue to run ECC for a set time, even after converting licenses, to facilitate the transition. This usually needs to be explicitly agreed upon. It might involve keeping a portion of ECC licenses active until those users move. Work with SAP on a migration license plan: for example, you convert 50% of licenses in Phase 1 (and give up the rest later), or you get an allowance to run ECC for X months for free or reduced cost. The goal is not to provide full support to a dwindling ECC user base while also paying for S/4.
• Extended Dual Maintenance: If SAP doesn’t allow partial conversion (they prefer a clean cut-over in many contracts), an alternative is to time the conversion such that you minimize overlap. Perhaps you keep your ECC contract until near the end of the project, and only convert when ready to flip remaining users. In the interim, yes, you’ll pay maintenance on ECC and maybe subscription on S/4 for early movers, but try to keep that period short. Some clients opt for a slightly higher cost as an operational expense of migration, rather than complicating contracts, but this approach is not tenable over a long period.
• Retain Some ECC Licenses if Needed: In a multi-phase plan, consider retaining a small quantity of ECC licenses for legacy systems that might not migrate at all. For instance, perhaps an old manufacturing plant will stay on ECC for a couple more years after corporate has moved to S/4. If you convert everything to S/4, that plant is unlicensed. One approach is negotiating a carve-out in the contract: you might convert most licenses but keep a subset of ECC licenses valid (and on support) for use in specific legacy operations until a certain date. This is tricky and SAP sales might resist (since they want you 100% on S/4), but if it’s a deal-breaker for you, they might allow a portion of ECC to continue. Typically, you’d continue paying maintenance on that portion. Alternatively, you could use third-party support for those remaining ECC systems, though that has its challenges as mentioned earlier.
• User Migration and License Swapping: As users move from ECC to S/4, make sure you reassign licenses appropriately. Named users cannot be double-counted. If your contract conversion gives you S/4 licenses for specific users, ensure those users are removed from ECC license counts so you’re not out of compliance on the ECC side. This is more of an internal management point – a user shouldn’t consume an ECC Professional license and an S/4 Professional license at the same time if one person just changed systems. Coordinate with auditors or SAP to clarify how to handle this during the transition. Often, SAP’s audit team can work with you if they know a migration is in progress (they might exclude certain counts if provided evidence). But it’s better to have it formally allowed via contract.
• Environment Licensing: Remember that S/4HANA (especially on-prem) might require new non-production systems (sandbox, test, etc.). Typically, SAP doesn’t charge for non-production systems as long as the users accessing them are licensed (and you have the proper license for the software itself). Ensure that your sandbox and project systems for S/4 are covered. Suppose you are a new S/4 customer (no prior ECC). In that case, SAP often gives developer/test licenses at no additional cost, but check the contract language around “Use of the software in non-Production environments is allowed for development, testing, backup, etc.” – you want that explicitly stated to avoid any doubt.

Licensing strategy for phased projects:

It might be beneficial to negotiate a progressive payment schedule – e.g., pay for 50% of the licenses now, 50% next year – aligning with your deployment waves.

Alternatively, consider negotiating a subscription for S/4 that starts at a lower number of FUEs and ramps up as you onboard more users (cloud contracts can sometimes include growth ramps).

This way, you’re not paying full price Day 1 while half your business is still on ECC.

The main point: Communicate your migration plan to SAP during negotiations.

If they understand the rollout, they may offer a tailored licensing approach rather than a one-size-fits-all contract. You can then bake in provisions that save cost during the transition and avoid inadvertently violating license terms.

The worst-case scenario is signing a standard S/4 contract and later discovering that you weren’t supposed to use ECC for 6 months alongside it, which can lead to audit issues. Plan it, negotiate it, and document it.

10. Watch Out for Hidden Cost Drivers (HANA DB, Architecture, Add-Ons)

SAP S/4HANA Licensing: Hidden Costs You Must Address Before Signing

When budgeting and negotiating for S/4HANA, it’s easy to focus on application licenses and user counts.

But there are less obvious cost drivers that can significantly impact your total cost:

• SAP HANA Database Licensing: Unlike ECC, which could run on third-party databases (Oracle, SQL Server, etc.), S/4HANA requires the SAP HANA in-memory database. Database licensing is separate from S/4 application licensing if you deploy on-premise (or in a cloud IaaS). SAP typically offers a HANA “runtime” license for S/4 – this is a restricted-use DB license, only to be used underneath SAP applications. It comes at a cost of roughly 15% of the value of the SAP application licenses. For example, if you bought $1 million in S/4 licenses, the HANA runtime might be $150k. Alternatively, suppose you want to use HANA for other custom or third-party applications too. In that case, you need a full-use HANA license, which is priced by memory (e.g., per 64GB block) and can be very expensive, often running into high six or seven figures for large systems. Many customers stick to runtime licenses to save costs. If you go RISE or SAP’s cloud, the HANA license is bundled in the subscription fee (you don’t see it as a separate line item), but trust that its cost is factored in. Negotiation tip: If on-prem, see if SAP will include the HANA runtime license in a bundle or discount it as part of your S/4 deal. It’s often overlooked in negotiation, but it can be a big number.
• System Architecture (HA/DR, Multi-Instance): S/4HANA on-premise licensing is generally per system (production system) for engines and per user for named users, so running multiple application instances (prod, test, etc.) doesn’t multiply license cost for the application. However, HANA database licensing can be affected by architecture. For instance, if you have a secondary HANA instance for high availability or disaster recovery, do you need a license for it? SAP’s policy allows for a limited use HA/DR installation without additional license if it’s truly passive and only used during failover. Still, the rules must be followed (e.g., you can’t actively use the secondary). Make sure you understand those rules to avoid inadvertently needing a second HANA license. In the cloud (RISE), if you need additional non-production systems beyond what’s included, SAP might charge extra. For example, RISE private edition might include one sandbox, one dev, one QA, and one prod. If you need a second QA or a training system, that could be an extra cost. Clarify environment entitlements in the contract to avoid surprise charges.
• Geographic Deployment Costs: If you plan to deploy S/4HANA in multiple regions (for performance or legal reasons), note that in RISE contracts, you typically choose a primary data center region, and additional ones might cost more. Also, data egress or network costs in the cloud might not be included. These are small relative to license costs, but can add up if not accounted for.
• Integration and Middleware: S/4HANA often goes hand-in-hand with SAP Cloud Platform Integration (CPI) or the broader SAP Business Technology Platform (BTP) for building extensions and interfaces. While S/4HANA licensing doesn’t cover BTP services, you might find you need to subscribe to some BTP usage (e.g., if you want to use Fiori mobile services or integration adapters). Third-party interfaces might also require SAP Gateway or SAP PO (Process Orchestration) licensing if not already licensed. During negotiation, discuss what tools you’ll use for integration – if SAP PO was used in ECC, do you have the right to use it with S/4? (Usually yes if you maintain that license.) If you plan to shift to SAP’s Integration Suite (BTP service), that’s a separate subscription – sometimes SAP will bundle a bit of it in a large deal.
• Custom Development Impact: If you plan heavy custom development on S/4, consider the cost of developer licenses (as mentioned, developer users might need full licenses) and also any SAP Cloud ALM or Solution Manager usage. SAP requires Enterprise Support for you to use Solution Manager fully (which you’d have if you pay maintenance). SAP Cloud ALM (Application Lifecycle Management) is a cloud service included for free with RISE and also now with on-prem support contracts – ensure it’s available if you need it, and check if any limitations (maybe user limits, etc.) so you don’t inadvertently need extra licenses for ALM tools.
• Growth of Data and Users: A hidden cost can be success itself – if your business grows, transactions grow, etc., you might outstrip initial license counts or HANA memory. It sounds obvious, but we’ve seen companies budget just enough for today and not include headroom. If you double your user count in 3 years due to acquisitions, have you locked pricing for additional users? If not, those new users might come at higher rates. Same with data: if your database size grows and you need to upgrade your HANA license tier (for full-use HANA, larger memory tiers cost more), that’s an extra cost outside the S/4 licenses.

In negotiation, ask SAP for a full breakdown of what’s needed to run S/4: application, database, infrastructure, integrations, etc. This is essentially a mini “solution architecture” discussion.

It ensures you identify all components. For each component, decide: do we have it already, do we need to buy it, or can we get it bundled/discounted?

By anticipating these “satellite” costs, you can either negotiate them into your S/4 deal (e.g., ask for X amount of BTP credits at no charge, or get a discount on a HANA full-use license if needed).

Budget properly so you’re not scrambling for more funds later. This diligence separates a smooth S/4 adoption from one riddled with cost overruns.

11. Understand RISE with SAP Pitfalls vs. Traditional Licensing

RISE with SAP deserves its focus because it’s not just a licensing model, it’s a packaged cloud offering that changes the game (and the rules of negotiation).

While RISE can simplify your move to the cloud, be aware of these pitfalls compared to traditional on-prem or DIY cloud licensing:

• All-in-One Bundling = Less Flexibility: RISE bundles S/4HANA software, the HANA database, infrastructure (on SAP’s chosen cloud or SAP datacenters), and basic support services into one contract. This “one throat to choke” approach is convenient, but if one element of the bundle doesn’t meet your needs, you’re stuck. For example, if SAP’s cloud infrastructure is underperforming or too costly, you can’t move your S/4 system to AWS or Azure on your own – not without completely exiting RISE. In a traditional model, you could host SAP anywhere or switch providers without needing SAP’s permission (as long as licenses are valid). With RISE, SAP is your landlord; leaving means moving out entirely. This lock-in can be risky if your business wants cloud portability or multi-cloud strategies.
• Limited Negotiable Components: In a custom on-prem license deal, you can negotiate many pieces – license discounts, maintenance terms, infrastructure separately with another vendor, etc. RISE contracts are more standardized; SAP often positions them as non-negotiable boilerplate aside from the FUE count and price. While that’s not entirely true (everything is negotiable to some extent), customers have found that RISE has fewer levers. Certain terms SAP might budge on in on-prem (like price caps, renewal flexibility) are tougher in RISE deals because SAP has a global template they try to stick to. Also, because SAP is providing the infrastructure and basis services, they factor in fixed costs/margins that they are reluctant to break out or discount heavily. You might get a better discount on pure software than you will on the full RISE bundle.
• Surrendering License Ownership: When moving to RISE, you usually must terminate or shelve your existing licenses. SAP gives you credit for them (hopefully), but as mentioned, you lose the perpetual rights. The implication: if down the line you’re unhappy with RISE, you cannot fall back to your old ECC or even a self-hosted S/4 without starting over license-wise. You’re trading the flexibility of owning software for the convenience of a rental. That’s fine if you never intend to leave, but it shifts leverage to SAP – they know if you don’t renew RISE, you have nothing to run your business on. In a traditional model, if SAP tried to hike maintenance or prices too much, you could, in theory, keep using your older software or delay upgrades. With RISE, stopping payments means the software automatically turns off. This makes renewal negotiations trickier (SAP knows you can’t walk away easily).
• Cost and TCO Considerations: SAP often touts that RISE can have a lower TCO by bundling and cloud efficiencies. It’s true that you avoid some capital expense and possibly reduce internal support staff needs. However, watch for hidden costs in RISE:
  • Resource limits: The RISE contract will have specific sizes for your systems (e.g., how many application servers, how much memory, and I/O performance). If your usage exceeds those, SAP will charge extra. A common story: additional storage in RISE can be pricey, or adding an extra test system might come at a premium. Ensure you understand the included vs. extra services.
  • Long-term subscription costs: Year 1 of RISE might be attractive (SAP often gives a first-year discount or incentives like free migration tools). However, over 5 years, compare the total spend to a traditional model. Many have found that while RISE saved them effort, it didn’t save money in the long run; it could cost more after the initial term once SAP’s standard annual increases kick in. Always run a 5-10 year cash flow comparison. For instance, maybe RISE is $X million per year, all-inclusive. A comparable on-prem scenario might be $Y million upfront + infra + support. Depending on Y and infrastructure costs, on-prem might break even or be cheaper by year 4 or 5. SAP loves to bundle soft benefits in their RISE value prop (like “faster innovation” or reduced downtime costs) – be objective and crunch the numbers.
  • Cloud-specific charges: If you require extra services like high availability setups across regions, advanced security, or compliance services, etc., check if RISE includes them. You might be surprised that certain things (like a secondary DR site in a different geography) could be an add-on cost. In a DIY cloud model, you might optimize costs by shopping around or only paying for what you use; in RISE, it’s a black box fee covering everything, which could pad some margin.
• Standardized Contract Terms: RISE agreements often have set renewal terms and uplifts. For example, it might allow SAP to increase the subscription fee by a certain percentage at renewal. If that’s not capped, you could face a large jump. Make sure to negotiate a cap on RISE renewal increases (even if SAP says “our standard is 5% max,” get it in writing if possible). Also, check the contract length – many RISE deals are 3 or 5 years. If you want a shorter commitment, SAP may charge more. If you lock into a long-term contract, ensure you have exit clauses for cause or SLA failures (like, if service levels aren’t met repeatedly, can you terminate early without paying the full remaining fees? It’s rare to get, but ask).

Mitigation: If you decide RISE is strategically right (and it does have benefits: quicker implementation, SAP-managed operations, potentially faster access to innovations), mitigate these pitfalls by negotiating hard on key points.

Bundle in as much as you can (so you don’t get nickel-and-dimed later), insist on transparency (e.g., ask SAP to show a breakdown of software vs infrastructure vs services in the price – they won’t give you their cost.

However, you can identify if the deal is overly expensive in one area and demand contractual protections (caps, SLA remedies, etc.).

Also, consider a RISE suitability assessment – some independent advisors or SAP’s services can analyze if RISE or on-prem makes more sense for you.

It might be that a “private cloud, bring your own license” approach (hosting your perpetual licenses on Azure/AWS with a partner) gives a better blend of flexibility and cost, if RISE doesn’t.

In summary, RISE with SAP can be a great solution, but it’s not automatically the best financial deal or the most flexible.

Know what you’re trading off.

And if you go RISE, lock down the contract so you don’t encounter unpleasant surprises in year 2 or 3 when you’re fully dependent on SAP’s cloud.

12. Proactively Manage Audit Risk and Compliance

SAP license audits are a regular part of life, at least for those on traditional licensing. Even cloud subscriptions can be “audited” (SAP will verify user counts and usage against your contract).

A key part of license management is to stay ahead of audits and negotiate terms that make audits less painful:

• Know Your Contract’s Audit Clause: Virtually every SAP license agreement includes an audit clause granting SAP the right to audit your usage. Typically, it says something like SAP can audit with X days’ notice, during normal business hours, not more than once per year, etc. If it doesn’t have those limitations, negotiate them in. For example, ensure it explicitly says “no more than once per year” and requires reasonable advance notice (30 days or more). Also, specify that audits should be conducted in a manner that minimizes disruption (e.g., remotely or in collaboration with your team) – SAP usually runs scripts (like USMM/LAW reports) rather than sending a swarm of auditors on-site these days.
• Implement Continuous License Management: Don’t wait for an SAP audit to check your compliance. Use the SAP License Administration Workbench (LAW) and related tools to measure your license consumption at least annually (quarterly is even better). By doing an “internal audit,” you can find issues on your terms. If you discover, say, 50 more users in a certain category than you have licenses for, you can address it via a purchase or re-allocation without the pressure of an official audit finding. Additionally, monitoring helps catch misclassified users, indirect usage, etc., so you can adjust proactively. Many ITAM teams produce an annual compliance report for management – this not only avoids surprises, it also demonstrates good governance if SAP ever questions your controls.
• True-Up Provisions: As discussed in point 13, negotiate a cure period or true-up clause that essentially decriminalizes slight overuse. If an audit finds you over, you should be able to buy the shortfall at your normal discounted rate, without penalties. Ideally, your contract states that if you have a compliant true-up process, any findings will be remedied by purchasing additional licenses rather than paying fines. This turns audits into less of an adversarial event and more of a reconciliation.
• Limit Auditor Access: Be cautious about what data you provide. SAP typically will ask for user lists, license assignments, and activity info. They don’t necessarily have the right to all your sensitive data or to interview employees without coordination. It’s good to have a single point of contact (usually the SAP license manager or ITAM lead) through whom all audit communications go. And consider NDAs and confidentiality – ensure SAP (and any third-party audit firm they use) signs that they will keep your data confidential and only use it for audit purposes. This is usually in the contract, but double-check.
• Document and Justify: Keep records of any non-standard usage that you believe is compliant. For example, if you have a third-party system accessing SAP and you’ve counted those users under a particular license type, document that decision. In an audit, if SAP says, “Hey, what about these users coming from Salesforce?”, you can show “we allocated 20 professional licenses to cover them” or “we have a side letter covering indirect read access.” It preempts arguments.
• Avoid Surprise with Communication: If you undergo major changes (like a merger adding a bunch of users, or deploying a new SAP module you hadn’t licensed before), consider informing SAP or at least addressing it promptly. If you merge with a company that has 100 SAP users and you let them use your SAP system, technically, those users need to be licensed under your contract. If you do nothing, an audit will flag it. If you proactively reach out to SAP (or handle via a contract change), you can negotiate licenses for them calmly rather than under audit pressure. Sometimes SAP even grants a grace period for integrating new acquisitions, but only if discussed openly.

Negotiation angle: If audits are a major concern, you can attempt to negotiate more audit restrictions, though SAP will never remove its audit rights entirely.

Some customers have received language stating that “audits will be conducted by SAP employees (not contingent fee auditors)” to avoid aggressive third-party auditors, or that “if an audit is initiated, it will follow XYZ process and timelines”.

At a minimum, ensure the contract states that you receive the audit results and have a period to discuss/clarify them before any formal claim is made – you don’t want SAP directly approaching your executives, claiming non-compliance, without giving you a chance to review the findings.

In essence, treat license compliance as an ongoing duty, not a once-in-three-years fire drill. By the time SAP knocks on your door, you should largely know what they will find.

And by setting the rules of engagement through contract terms, you make the audit procedure more fair and less disruptive. A well-managed SAP estate with clear audit terms is usually not a source of unpleasant surprises.

13. Negotiate True-Up and Flexibility Clauses for Growth

Your organization will evolve – employee counts change, business units get added or divested, transaction volumes shift.

Your SAP contract should have built-in flexibility to accommodate this without punitive costs.

Two key mechanisms to focus on are true-up clauses and growth provisions:

• Annual True-Up (Cure Period): This is a contract clause that allows you to self-report any license shortfall periodically (e.g., once a year) and purchase the additional licenses at your pre-negotiated discount, with no penalties. In effect, it’s an agreed-upon process to stay compliant. For example, suppose you licensed 1,000 users but deployed 1,050 during the year. With a true-up, you can tell SAP at year-end and buy 50 more at your normal price. SAP then considers you fully licensed – no back maintenance, no fines, no breach of contract. Without a true-up, those 50 extra users might be seen as unlicensed usage, and an audit could hit you with list price charges plus back-dated support. Many modern SAP contracts, especially with large customers, include an “Additional Use” or true-up clause – but if yours doesn’t, it’s worth requesting. It turns compliance into a collaborative approach rather than a witch hunt.
• Mid-Term Expansion Flexibility: In cloud subscriptions, usage can sometimes grow faster than anticipated. Let’s say you suddenly need 200 extra users for a project mid-year. If you just add them, SAP might charge a premium (since it’s outside the contract). To avoid this, negotiate an elasticity clause – the ability to add users or capacity during the term at the same rates or predefined rates. Possibly set a threshold: e.g., you may add up to 10% more users in a year at the same per-user price, with the contract fee increasing accordingly. This prevents the scenario of “Oh, you need 100 more users now? That’ll be at list price until renewal.” SAP might resist open-ended flexibility (they want to upsell you), but even a limited buffer is helpful.
• Growth Caps (Volume Discounts): SAP pricing often has volume tiers (the more you buy, the cheaper per unit). Oddly, this can mean if you just exceed a tier, you pay disproportionately more. A savvy move: if you’re near a tier boundary, negotiate a price lock for the next tier or commit to a bit higher quantity to get a lower price. As an example from earlier, buying 6,001 FUEs might drop the unit price significantly vs 5,000. You could negotiate that if you do exceed a certain volume, the lower tier price kicks in automatically. Or negotiate a blended price that anticipates some growth. The key is not to be caught in a situation where growth pushes you into much higher unit costs.
• Downward Flexibility (Shelfware Reduction): We talk a lot about adding licenses, but what if you need fewer? Traditionally, SAP didn’t allow dropping license counts until perhaps a contract renewal, and even then, maintenance is “all or nothing” (they often wouldn’t let you drop support on licenses you don’t use, without terminating the whole contract). Try to negotiate a true-down option at renewal – the right to reduce user counts or remove unused components when renewing a subscription or support term, without penalty. For example, you sign a 3-year cloud deal for 1,000 users, but at renewal for the next term, you only need 900 (due to efficiencies or divestitures). You want to renew for 900 at the same discount percentage. Many vendors resist lowering numbers (revenue decrease), but if you can anticipate possible downsizing (maybe one division might be sold off), put a clause that you can adjust down by X% at renewal. It gives you agility and prevents paying for shelfware indefinitely.
• Merger/Acquisition Flexibility: Another angle – if your company is acquisitive, what’s the process to rapidly extend licenses to a newly acquired entity? Can you get a standing discount for any additional licenses needed due to M&A? Conversely, if you divest a part of the company, can those licenses transfer, or can you terminate a portion? These situations are tricky, but raising them upfront is better than dealing with them later. Some contracts allow license transfer to affiliates or divested units for a fee – know your rights on assignment.

In practice: Bring scenarios to the negotiation table.

Ask SAP, “What if we grow 20% – how will additional licenses be priced?” and “What if we shrink – can we drop some licenses?” The answers should be codified in the contract.

Also, align any true-up timing with your budgeting cycle. Many do it annually, which is fine. If your fiscal year is Jan-Dec, maybe true-up every Jan for simplicity.

One more tip: If you do negotiate a true-up clause, be sure to use it. Some companies forget to self-report, thinking it’s optional and they’ll just wait for an audit – bad move.

If the clause is there, follow the process (it’s in good faith, and SAP will expect you to).

It’s better to true-up voluntarily than to trigger an audit by ignoring known overuse.

14. Tackle Shelfware and Unused Licenses

Despite best efforts, many SAP customers end up with shelfware – licenses purchased and never deployed, or no longer used. Shelfware is essentially wasting money (and then paying maintenance on top of it).

Here’s how to manage it:

• Avoid Overbuying Upfront: The best defense is not creating shelfware in the first place. In negotiations, SAP sales may tempt you with volume discounts – “if you buy 1,000 users instead of 800, we’ll give you 20% off the unit price.” That can be false economy if you only ever use 800; you’re paying support on 200 idle licenses. It’s often smarter to buy what you need now (maybe a slight buffer) and then deal with future needs via true-ups or separate purchases, even if the unit price is a bit higher. The incremental cost of buying later is usually far less than the cost of carrying unused licenses for years. Push back on hypothetical growth bundles – you can say, “I’ll take the 800 now at the best price you can do, and let’s put in a provision to price protect the next 200 when I need them.”
• Conduct Regular Usage Audits: Just as you check for under-licensing, also scan for over-licensing. Identify licenses or modules not being utilized. For named users, LAW reports can show users with no activity – if dozens of “Professional” users haven’t logged in for 12 months, why keep paying for them? Revoke or reassign those licenses to others. For engines, review if that engine is really in use (e.g., did you implement that SAP CRM you bought, or was the project shelved?). Create an internal report of unused licenses and quantify the cost (maintenance on that shelfware costs X per year). This builds the business case to address it.
• Negotiate Exchange/Retirement Rights: In your SAP contract or at renewal, seek a clause to swap or terminate unused licenses. SAP historically had a hard “no partial termination” policy – you couldn’t just drop support on 50 licenses without dropping it on all. But some customers have negotiated exceptions. For example, a clause that says at renewal, you can retire up to 10% of licenses without penalty or exchange them for other licenses of equal value. Or a one-time swap: “Customer may convert up to $500k of unused licenses to a different SAP product license at no additional cost.” These are not standard, but if shelfware is significant, make it a sticking point. SAP would rather reallocate your spend than lose it entirely if you threaten to walk away from those unused licenses by not renewing them.
• Shelfware to Cloud Credit: Some clients negotiated the ability to use on-prem shelfware value as credit toward cloud subscriptions. For example, those 200 unused ECC users – can their value be applied if you later subscribe to, say, SuccessFactors or Ariba? It’s not typical, but if you’re doing a big shift (like moving some processes to the cloud), ask if the shelfware can be repurposed. SAP’s answer might be to do a contract conversion (as covered), where, effectively, shelfware gets minimal credit, but again, ask explicitly for better terms on shelfware. Show them it’s in their interest – if you can’t find a way to utilize the shelfware value, you might consider third-party support or not buying additional SAP products at all.
• “Use it or Lose it” Deadlines: If you had to over-purchase due to a deal, set an internal deadline – e.g., “If this module isn’t implemented by next year, we will look to eliminate it.” Sometimes shelfware is a result of changing priorities (you bought licensing for a project that then got canceled). Don’t hold onto the notion “maybe we’ll use it someday” if it’s unlikely. Better to approach SAP and say, “We have this module not in use. Instead of us dropping maintenance (and you losing that revenue), can we swap it for something we need?” That conversation can lead to a mutually beneficial swap.
• Don’t Pay Maintenance on Unused Software: This may seem obvious, but if something is truly shelfware and you have no plan to use it, paying 22% per year on it is a waste of money. In some cases, you might decide to terminate support on that portion even if SAP doesn’t allow partial termination easily. It might involve a tough conversation or legal negotiation, but if it’s significant dollars, it’s worth it. Alternatively, park those licenses on third-party support (yes, third-party support will even support software you aren’t using, which doesn’t make a ton of sense, but it’s a way to cut that cost by 50%). Then, if you need that software again, you can potentially reinstate it (though SAP might charge for back-maintenance if you return it).

Communication with SAP:

When negotiating flexibility for shelfware, frame it as a win-win: “If you let us adjust our licenses to match usage, we’ll invest in areas we need and continue our partnership.

If not, we might be forced to consider alternatives (like not renewing certain licenses or moving off maintenance).” SAP would prefer to keep you as a customer in all areas, even if it means shifting some value around.

Finally, once you’ve tackled shelfware, track license utilization on an ongoing basis. Make it a KPI for your team: e.g., “licensed vs deployed” ratio. Keep it high (close to 100% usage). That ensures you’re extracting full value from what you pay SAP.

Shelfware reduction can directly free up budget that you can use for new initiatives (or to negotiate a better discount on an expansion because you’re not wasting money elsewhere).

15. Define Your Scope of Use and User Definitions Clearly

SAP contracts are full of fine print that defines how you can use the software. Understanding and negotiating these scope clauses can prevent unintentional compliance issues.

Focus on these areas:

• Affiliated Companies / Licensee Definition: Ensure the contract’s definition of “Customer” or “Licensee” includes all the legal entities you need it to. If your SAP contract is with ABC Corp, does it allow usage by ABC Corp’s subsidiaries, joint ventures, or future acquired companies? Often, standard terms limit use to the legal entity signing and its majority-owned affiliates. Suppose you have a complex corporate structure or plan to acquire companies. In that case, you want broad wording – e.g., “Customer, its wholly-owned or controlled affiliates, and any entity which Customer may acquire during the term.” This avoids needing separate licenses for each entity. If you do carve out a business or spin-off, ensure the contract allows a transfer of appropriate licenses to that entity (or at least allows them to continue using the software for a transition period).
• Geography and Site Limitations: Sometimes older contracts had clauses like “software may only be used at the licensed site or in X country.” Modern S/4 contracts usually allow global use, but double-check. Remove any restrictions that don’t make sense – e.g., if it says “for use in North America only,” and you have a global operation, strike that or change to “worldwide.” Cloud contracts will specify data center regions – ensure the region meets your data residency needs (EU, US, etc.) and that you can change region if needed (some allow a relocation at renewal or such).
• Third-Party and Outsourcing Use: Standard SAP agreements often say licenses are for the internal business purposes of the Customer. This implies that third parties (contractors, service providers) who use SAP to perform services for you might require special permission. Suppose you outsource some business process (like payroll or manufacturing) to a third party, and they need access to your SAP system. In that case, they should be covered under your licenses (usually by assigning them named user licenses). However, some contracts forbid use if the third party is using the software for their own business or other clients. To be safe, add a clause allowing Third-Party Agents or Contractors to access and use the software on your behalf, under your license umbrella. You remain responsible for compliance, but SAP agrees that those users don’t need separate licensing. This is crucial in today’s world of MSPs and BPOs.
• Service Bureau / Commercial Use: If you ever intend to use SAP to provide services outside your organization (even just reports or hosting for a partner), note that standard licenses prohibit using SAP to process data for third parties. That’s called a service bureau restriction. If your business model allows for this (for example, if you’re a manufacturer running a portal for distributors that connects to SAP), clarify it. Usually, SAP will want a special license or wording for that. If it’s not core to your usage, just be aware not to violate that inadvertently.
• Environment and Copy Usage: Ensure the contract clarifies that you can make copies of the software for backup, archive, testing, etc. SAP usually allows this (and for cloud, they handle it). If you have any unique needs, such as running a dedicated DR instance, specify that it’s permitted without additional license as long as it’s idle except in disaster scenarios. (SAP’s policy is generally supportive of this scenario, but documenting it is advisable.) Also, if you want to use production data in a non-prod system for testing (which can create indirect access scenarios), clarify any licensing impact. Generally, if non-prod is covered, using production data is fine, but be aware of scenarios where testing might generate a large number of documents that SAP might count (digital access).
• Metric Definition Clarity: For any engine or metric-based licenses, make sure the metric is unambiguously defined. If it’s “orders”, are those line items or header orders? If “revenue”, is it total company revenue or a specific division? Contracts often reference SAP’s official price list definitions – ask for those if unclear. You don’t want an argument later over what constitutes a “user” or a “transaction”. The more clarity in the contract, the less room for audit disputes.
• Indirect Use Terms: We’ve covered this, but just to reiterate in scope: define “Use of the Software” to exclude authorized indirect scenarios. E.g., “Use of the Software by third-party systems that only read data (static read) shall not count as Use requiring a license.” This single sentence, if SAP agrees, can save you a lot of headaches.

In summary, treat your SAP contract not just as a purchase order, but as a usage rulebook. Go through those terms with legal/IT and imagine “what if” scenarios. What if we reorganize the company? What if we hire contractors?

What if we deploy in a new country? What if we integrate a new app? For any scenario where the contract language is fuzzy or restrictive, discuss with SAP and adjust it.

It’s much easier to handle this upfront than to litigate later whether something was allowed or not. SAP is more amenable to reasonable scope expansions before the contract is signed (when they want the sale) than after, so use that leverage.

16. Lock In Price Protections and Renewal Terms

Negotiating the initial price of an SAP deal is only half the battle.

The other half is ensuring that the price doesn’t skyrocket later through maintenance increases or renewal terms. Price protections are critical in any long-term software relationship:

• Annual Maintenance Cap: For on-premise licenses, you’ll pay annual maintenance (support). SAP has historically increased the maintenance percentage occasionally (e.g., from 18% to 20% to 22% over many years), and in recent times, they’ve added inflationary increases (5% in 2024 for standard support, for example). Negotiate a cap on your maintenance fee increases. It could be as simple as “SAP shall not increase the annual maintenance fee by more than 3% per year”. Or if possible, “maintenance fee percentage remains at X% for Y years.” While SAP often has policies (they announced those 5% increases globally), enterprise customers with clout have gotten exceptions by having it in their contract that maintenance is fixed or capped. Even if you accept some increase, set a hard ceiling to prevent surprises.
• Subscription Renewal Cap: For cloud subscriptions (like S/4HANA Cloud or RISE), the initial term might be discounted, but then SAP’s standard approach is to renew at “then-current list price” or apply some increase. You want to cap this. For example: “Upon renewal, the yearly subscription fee shall not increase by more than 5% over the prior term”. Without this, you could face a much bigger jump. We’ve seen cases in the past where a cloud service was sold cheap initially and doubled at renewal because the customer was locked in. Don’t let that happen – lock your renewal pricing framework. Even better, try to negotiate price locks for a multi-year term: e.g., a 5-year deal with a fixed annual fee or a predetermined slight uptick. If you’re committing long-term, SAP might agree to fix the price (or only tie increases to a known index or CPI).
• Clause for Additional Purchases: If there’s a chance you’ll need more licenses mid-term (very likely in most cases), ensure your contract allows additional purchases at the same discount percentage as the initial buy. This is often standard in SAP deals: they might include a rider that any additional licenses of the same type purchased within X years get the same % discount as this deal. If it’s not in there, ask for it. Also, if you foresee needing entirely new products, you could negotiate “most favored” status – e.g., for any new SAP products you adopt, they’ll apply at least Y% discount or better. SAP may not agree to a blanket price for all products, but if there are specific ones (like “we plan to add Ariba in year 2”), get a price hold on that too.
• Avoid Auto-Renewal Gotchas: Many cloud contracts auto-renew for the same term length unless notice is given 60-90 days before the end. That’s fine, but ensure you know the window and ideally extend it. Negotiate perhaps a 90 or 120-day notice period, and also request that SAP send a renewal reminder. Some customers have gotten clauses like “SAP will notify Customer of upcoming renewal 120 days in advance” – helpful so you don’t miss the window (though you should track it yourself too). If you miss a notice and auto-renew, consider setting it to auto-renew on a shorter term (like month-to-month or one year) to avoid being locked into a full term inadvertently.
• Renewal Flexibility: When that renewal time comes, you want to leverage. One way is to ensure you have co-termination of licenses. If you have multiple SAP contracts (e.g., some cloud services and some on-prem), align their end dates to facilitate renegotiation as a package if needed, rather than staggered renewals where SAP can play one against the other. If you’re large, consider an Enterprise Agreement concept where you roll up all licenses into one renewable agreement, then you can potentially reallocate licenses within it at renewal. This is advanced, but some have negotiated a “pick what you need each renewal” structure (often only with huge spend, though).
• Protect Discounts at Renewal: If you got 50% off in the initial deal, don’t let SAP say at renewal, “Oh, that was promotional, now it’s list price.” You want contract language that the discount or pricing basis carries forward. Possibly, “Renewal pricing will be based on the same baseline and discount as the initial term, subject only to the annual cap mentioned.” If not explicitly stated, SAP might try to re-price. Pin them down that your starting point for renewal is the current price, not some arbitrary list.
• Cap Support Fee Base if Partial Shelfware Remains: One tricky area – if you dropped some licenses from use but still have them technically, SAP might charge support on all licenses owned, not just used (since maintenance is on licenses purchased). If you have shelfware you can’t drop (e.g., you bought perpetual licenses you don’t use but can’t get rid of), try at least to cap the maintenance on those or carve them out. In some cases, customers negotiated to remove certain licenses from the maintenance base, essentially dropping support on them. If you can’t, you’re stuck paying, which is why the earlier point 14 is important to allow you to drop unused licenses.

Negotiate like a multi-year chess game:

Don’t just focus on this year’s cost – think of what SAP might charge in 3, 5, 7 years.

Build guardrails in the contract. SAP sales folks might say, “We don’t usually increase beyond inflation” – that’s nice, but get a hard number or formula in the contract, not a verbal assurance.

For example, the link increases to CPI (Consumer Price Index) with a maximum of, say, 3%. That’s reasonable and gives SAP cover (“we’ll adjust for inflation but no more”).

By setting these protections, you ensure that the value you negotiate today isn’t lost tomorrow.

Many companies negotiate a great initial deal and then passively let costs soar later, effectively undoing the savings. Don’t be one of them; lock it in!

17. Consider Third-Party Support to Reduce Costs

While SAP would prefer all customers stay on its maintenance, the reality is that third-party support providers (like Rimini Street, Spinnaker, Support Revolution, etc.) have emerged as an alternative for SAP and Oracle products.

For ITAM professionals, understanding this option is important both as a cost-saving measure and a negotiation lever.

What is third-party support?

It means instead of paying SAP for support and updates, you pay another company (often at 50% of SAP’s maintenance fee or less) to provide support for your existing SAP software.

They typically cover break-fix support, tax/regulatory updates, and technical assistance, but do not provide new SAP versions or enhancements.

Essentially, you’ll be frozen on the software version you have (they’ll help you keep it running).

When does it make sense? If you have stable SAP systems that you don’t plan to upgrade for a long time, third-party support can save a lot of money.

For example, if you’re going to remain on ECC 6.0 for the next 5 years without moving to S/4, you might consider third-party support after SAP’s mainstream support ends (2027) or even before, to save those hefty maintenance fees.

Some organizations that decide not to move to S/4HANA at all (or to delay beyond SAP’s support window) use third-party support to bridge the gap at a lower cost.

Key benefits:

• Cost Reduction: Typically, third-party support is around 50% of your current support fees. If you’re paying $1M/year to SAP, they might charge $500k. That’s immediate savings to your IT budget. Over several years, that adds up and can be reinvested elsewhere (perhaps even funding an S/4 project when you’re ready).
• Extended Support Life: Third-party providers often pledge to support your version for 15+ years, far beyond SAP’s timeline. For instance, Rimini Street has announced they’ll support ECC 6.0 (and even S/4HANA if someone left SAP support) through at least 2035 or 2040. This removes the pressure of the 2027 deadline if you’re not ready to migrate.
• Personalized Service: Many customers report that these providers can offer more responsive, personalized support (since you are a big fish to them, versus one of thousands to SAP). They may even help with custom code issues, which SAP standard support doesn’t (SAP only supports standard code).

Key trade-offs and risks:

• No Upgrades: Once you leave SAP support, you do not have the right to new versions or patches from SAP. That means no S/4HANA unless you buy licenses anew, no new Enhancement Packs, etc. Suppose you intend to eventually move to S/4 or any SAP cloud product. In that case, you’ll have to re-engage with SAP (likely via buying new licenses or paying back maintenance for reinstatement, which SAP typically doesn’t allow easily – they’d rather sell you S/4 new). So, going third-party is best when you plan a long freeze or are ok with potentially not upgrading through official SAP means.
• Reinstatement Penalties: If you leave SAP support and later want to return, SAP’s policy requires you to pay all back-maintenance fees for the period you were gone (or purchase new licenses). This can be cost-prohibitive. So it’s not a trivial decision – it’s somewhat one-way unless you have a strategy. For instance, some leave SAP support for ECC to save money now, and when they’re ready for S/4, they just buy S/4 (maybe with some conversion discount but effectively a new contract) – skipping the need to reinstate ECC support. That can work. But know that you can’t just hop out and in without incurring costs.
• Legal/Liability Concerns: Third-party support has been subject to legal battles (Oracle vs Rimini, etc.), but at this point, it’s generally considered legal if done right. SAP might not like it, but they can’t cancel your perpetual license for using third-party support. However, do check your contract: make sure there’s no clause prohibiting sharing certain intellectual property or support materials. Most customers have navigated this fine. Essentially, you may have to stop using SAP’s support portal, notes, etc., and rely on the third-party for all fixes. The third-party provider will typically guide you on what’s allowed.
• No Support for New SAP Purchases: If you buy new licenses or move to the cloud, you’d be under SAP support for those. So you might end up with a hybrid situation – some systems on third-party support, new S/4 on SAP support. That’s doable, but it adds complexity.

Negotiation lever:

The mere possibility of moving to third-party support can be powerful leverage with SAP. It essentially says, “If you don’t give us a good deal, we have an alternative – we don’t need to stay on your maintenance.”

This is especially useful if you’re close to the end of ECC support and still haven’t committed to S/4. SAP knows some customers will jump ship for support rather than pay high fees for an uncertain future.

We have seen SAP offer better discounts or extended support with less/no premium to customers who were evaluating third-party support as a serious option.

In one case, a company secured a deal with SAP, agreeing to hold their maintenance flat (0% increase and extended timeline) if they would not go to Rimini – essentially, SAP negotiated to keep them.

Suppose you want to use this as leverage. In that case, you must signal credibly: perhaps engage in an assessment with a third-party vendor (SAP’s sales reps might catch wind), or directly tell SAP during a renewal conversation that you are considering third-party support. Be careful to maintain a professional tone – it’s not a threat, it’s just business.

Combining with S/4 plans:

Some customers use third-party support for ECC now to save money, which they then use to fund the S/4 migration a couple of years later. When they’re ready for S/4, they negotiate a fresh deal with SAP.

That’s a valid strategy: you reduce cost during the “wait” period.

Just ensure you coordinate the timing so that you don’t end up in a bad negotiation spot (if SAP knows you have to come back for S/4 by a deadline, they might play hardball – but if they value winning you back from third-party, they might offer enticements).

In summary, third-party support is an arrow in your quiver. Even if you ultimately stay with SAP, knowing this market and option can help you evaluate SAP’s value proposition more critically. And suppose maintenance fees on unused or stable systems are killing your budget.

In that case, it’s a legitimate option to cut costs, freeing money for innovation (possibly even to invest in S/4 when the time is right).

Always weigh the long-term implications, but as an ITAM professional, you should be conversant in this area and incorporate it into your SAP strategy discussions.

18. Time Your Negotiations with SAP’s Sales Cycle

“Timing is everything” applies strongly in SAP negotiations. SAP, like many software vendors, has sales targets and fiscal year pressures that you can leverage to get a better deal.

Here’s how to use timing to your advantage:

• Know SAP’s Fiscal Year: SAP’s fiscal year is the calendar year (ending December 31). That means Q4 (Oct–Dec) is typically a rush for them to close deals. You’ll often see SAP pull out all the stops to get deals in by the end of the year. Similarly, the end of quarters (particularly Q4 and Q2) can be crunch times. If you can align your negotiation to close around late December, you’re likely to get the sales team’s maximum attention and flexibility. They may have last-minute “sweeteners” to close you. For example, in Q4, they might have additional discount authority or special promotions – perhaps an extra set of users free, or extra services thrown in – that they wouldn’t offer in Q1 when there’s less pressure.
• Leverage Quarter-End Deadlines: It’s a classic tactic: let the clock work for you. If SAP quotes you terms in July, but you sense you could do better, consider (if your project timeline allows) dragging the negotiation into Q3/Q4. As the quarter-end (or year-end) approaches, the rep is sweating to hit quota. They might come back with, “If you can sign by September 30, we can give an additional 5% discount,” or “we can include that extra dev system at no charge.” Be mindful: don’t overdo it and slip past the date entirely – you need to be prepared to sign when the iron is hot, or you could lose the offer. If you go past year-end, the urgency resets, and you might lose leverage.
• Use SAP’s Sales Incentives: SAP occasionally runs special incentive programs (especially around S/4HANA adoption). For instance, they had programs for Digital Access where if you signed by a certain date, you got free document licenses. Alternatively, they might offer a “Q4 deal” where converting to S/4 now would entitle you to X% credit, plus free SAP Learning Hub licenses or other benefits. Stay informed via your SAP account executive or user groups about such programs. If you hear of one, time your negotiations to take advantage. Sometimes, just asking “Are there any quarter-end promotions we could benefit from if we sign now?” can prompt the rep to reveal something.
• Letters of Intent (LOIs) for Time Extensions: What if you truly can’t finalize the deal paperwork by the quarter-end but want the discount that’s being offered contingent on that timing? Enter the Letter of Intent (LOI). An LOI is a tool where you sign a non-binding letter by the deadline, indicating your intent to purchase under certain terms, and SAP then reserves the discount for you for a short period (maybe 30-60 days) while you finalize contracts. SAP benefits because they might be able to count it in their pipeline or sometimes even in bookings (depending on how rigid they are – usually they can’t count it as a sale, but it at least signals progress). You benefit by not losing the deal perks even if your legal review takes a bit longer. If you go this route, ensure the LOI explicitly states the key commercial terms (price, quantities, any special concessions) and a commitment that SAP will honor these in the final contract if signed by X date. It’s not as solid as a contract, but it’s something.
• Beware the Year-End Crunch on Your Side: While delaying to Q4 is good for leverage, remember everyone is trying to close in Q4. That means SAP’s contracting departments get busy, and your procurement and legal might be swamped with other year-end deals. Don’t leave complex issues to solve at the very last minute – use the earlier part of the year to hash out major points, and leave only final signatures for Q4 if possible. Also, be cautious about SAP’s attempts to rush you: sometimes they’ll say “we need this signed by Dec 31 or the offer is off the table.” That might be true (from their perspective), but make sure you don’t sign something incomplete or unfavorable just due to time. If needed, use an LOI or get a short extension (“we’ll sign Jan 5, give us the same deal”).
• Multi-Year and Budget Cycles: Consider your fiscal year. If you have a budget that expires, that can counter-leverage. But if you have the flexibility to pre-spend, a Dec deal might let you use up your budget and secure a good price. Conversely, if your budget cycle is different (say, FY ends in March), you might coordinate with that. Just be aware how it aligns with SAP’s calendar – sometimes a compromise date (like end of Q1) can also yield deals, especially if Q4 slipped and SAP needs Q1 recovery.

Vendor Sales Behavior:

It’s worth noting that SAP salespeople have quotas and accelerators. It’s rumored that in some years, SAP gave a bonus if a customer signed a RISE deal by year-end.

Knowing these internal drivers (via industry intel or your friendly sales rep’s hints) can guide timing. For example, if they’re pushing RISE and you’re negotiating one, doing it in the timeframe they’re incentivized could maximize your discount.

In essence, treat the negotiation timeline as strategically as the content. Patience can pay off in thousands or millions of savings.

However, don’t let an internal project deadline force you into negotiating in a low-leverage period.

If you know you need something by June, consider starting earlier or delaying the project start to align with a better deal window, especially if the cost difference is significant.

19. Leverage LOIs, Side Letters, and Contract Redlines

Successfully negotiating an SAP agreement often requires going beyond the standard order form. You’ll want to employ tools like redlining contracts, using side letters, and possibly Letters of Intent (LOIs) to capture all agreed-upon terms and nuances.

Each serves a purpose:

• Redline the Contract: SAP will often provide you with their standard license agreement (or cloud subscription agreement) and order form. Do not assume it’s non-negotiable boilerplate – almost everything in an SAP contract can be negotiated if you have justification and leverage. Work with your legal counsel to redline (edit) the contract language. Key sections to scrutinize: audit clause, indirect use definition, limitations of liability, performance warranties, data protection, assignment rights, governing law, etc. For example, you might redline the audit clause to add the provisions we discussed about notice and frequency. Or add a sentence to the usage definition to allow third-party use. SAP might push back on some changes, but often you can reach a middle ground. The SAP legal team is accustomed to receiving redlines from large clients; they maintain an approved alternate wording library for many clauses, so feel free to ask. Don’t be afraid to mark up the document heavily; you won’t get what you don’t ask for.
• Side Letters (Ancillary Agreements): Sometimes, there’s a very specific assurance or concession that SAP’s standard contract doesn’t accommodate well. Enter the side letter. This is a separate letter or agreement, signed by both parties, that outlines particular terms. Common uses of side letters in SAP deals include:
  • Clarifying indirect use handling (“For the avoidance of doubt, SAP will not require additional licenses for the scenario described as XYZ in Appendix A.”).Performance or project assurances (“SAP will ensure that the customer’s ECC system remains supported through Dec 2028 under the existing contract terms, notwithstanding the transition to S/4HANA.”).Future credits or protections (“SAP agrees that if Customer purchases SAP Product ABC by the
  end of 2024, Customer will receive a 60% discount on that purchase.”). True-up terms not in standard contract (“As per discussions, SAP will allow the customer a one-time reduction of users at the end of year 2, documented separately herein.”). Side letters are useful because SAP’s lawyers might not want to change the boilerplate for one customer (as it sets a precedent), but they might sign a one-off letter addressing your concern. Just make sure someone with authority at SAP signs it and references the main agreement so it’s legally linked. Keep side letters with your contract – during audits or disputes, you may need to produce them to show your special terms.
• Letters of Intent (LOI): We touched on LOIs in the timing section. An LOI is a document stating the key business terms and the intent to enter into a contract. It’s usually non-binding regarding actually purchasing, but it might be binding on confidentiality or exclusivity for a period. LOIs come into play if time is short or some approval is lagging. For instance, an LOI can lock in the negotiated 70% discount and the product list, provided you sign a final contract by, say, next month. It gives both parties comfort that the deal is in motion. One caution: LOIs are not a substitute for a contract – if things fall apart, the LOI won’t enforce the deal (unless it’s drafted to be binding, which most aren’t). But it can be a useful tool to satisfy quarter-end pressures while final paperwork continues. If you sign one, keep the momentum to finish the actual contract.
• Document Everything Agreed: Throughout negotiations, you might have a running list of things SAP said yes to (e.g., “okay, we’ll allow that affiliate use” or “we’ll include 100 extra user licenses at no cost for your test system”). Make sure every single one ends up either in the main contract, an amendment, or a side letter. If it’s not written, it’s not real. People change, memories fade – what the sales VP promised over a phone call won’t hold weight in 2 years when you try to enforce it. It’s your job as the customer to ensure all promises are captured. A good practice is to send confirmatory emails after calls: “Just to confirm, SAP agreed that… [list terms]. We will incorporate this into the agreement.” This helps prevent any “misunderstandings” later.
• Use Precise Language: Whether in the contract or side letters, use clear, unambiguous wording. If a term can be read two ways, it will cause trouble. For example, if negotiating a price cap, specify “shall not increase by more than 3% per year during the initial term or any renewal term” – rather than a vague “will not materially increase.” If defining an indirect use scenario, spell it out: “e.g., data exports via SAP standard APIs to non-SAP systems for read-only display shall not require additional licenses.” Get as specific as possible. It might make the text longer, but it prevents loopholes.
• Signatures and Approvals: Ensure the right entities sign. If your parent company is negotiating but a subsidiary holds the licenses, figure out if you need both on the contract. Ensure the person signing for SAP is authorized (usually a VP or higher for contracts, but they’ll handle that). And for side letters, usually it would be signed by an SAP contracting officer or VP as well, not just the sales rep.

Think of your contract negotiation like closing all the doors and windows through which risk or ambiguity could slip in.

Redlines close the big doors in the main contract, side letters patch the oddly shaped windows of unique terms, and LOIs help bridge timing gaps.

Finally, organize your final contract package:

Keep the main agreement, order forms, appendices, side letters, etc., together in a repository. Over time, ensure that successors in ITAM know these exist.

Many times, companies have negotiated great terms but then lost track of a side letter, and an audit team from SAP (which might not even know about it) presses an issue until you scramble to find that letter. Maintain a “contract bible” with all components.

Negotiating isn’t just about price; it’s also about getting the right protections and clarity. With thorough documentation via these tools, you’ll set the foundation for a much smoother relationship with SAP post-signature.

20. Benchmark Your Deal and Seek Expert Advice

Knowledge is power in any negotiation.

For SAP licensing, that means benchmarking and potentially bringing in outside expertise to ensure you’re getting the best deal possible and not overlooking any pitfalls.

• Use Benchmark Data: SAP doesn’t publish its price list or discount ranges publicly, which puts customers at a disadvantage. To counter this, gather benchmarks:
  • Talk to peers in user groups (ASUG, DSAG, etc.). Many companies won’t share exact numbers due to confidentiality, but you can get ballpark figures like “we got roughly 60% off on a S/4 deal with 1000 users” or “SAP offered us RISE at $X per FUE.” This helps you gauge if SAP’s offer to you is reasonable or not.
  • Look at industry research. Some analyst firms or IT consultancies publish reports on SAP pricing trends (for example, Redress Compliance or Gartner might have anonymized data). Even anecdotal information, such as “Professional user list price is around $4000,” or typical discounts of 50%+ for ECC to S/4 conversions, can strengthen your negotiation stance. If SAP offers only 20%, you can question it armed with the knowledge that others got more.
  • Understand ranges: e.g., we know Professional user SaaS might be $200/user/month list. If you have 1000 users, that’d be $2.4M/year list. Many deals of that size might close at half that or better. So if SAP quotes you $2M/year, you know it’s not their best. You might aim for $1.2M. Having these targets based on data prevents you from either overpaying or asking for the impossible (if you demanded 90% off, that might be unrealistic and stall negotiations).
• Calculate TCO/ROI: Run your numbers on the long-term costs and returns. If you can demonstrate to internal stakeholders (and even to SAP, to justify your requests) that “Staying on ECC plus third-party support for 5 years costs X, moving to S/4 now under these deal terms costs Y, and yields Z benefits”, it clarifies the value. If Y is significantly higher than X, you have a case to SAP that their proposal doesn’t make financial sense, and they need to improve it or risk you sticking with the status quo. Conversely, if SAP sees you’ve done the math and S/4 can save money under certain conditions, they might be more willing to meet those conditions to close the deal. Internally, having ROI analysis helps get leadership buy-in for pushing back on SAP or for allocating budget to a well-negotiated deal.
• Engage Independent SAP Licensing Advisors: There are firms (like Redress Compliance, SAP Licensing Experts) that specialize in SAP licensing advisory. They often have extensive benchmark data and experience from many negotiations. Engaging them can provide:
  • Benchmark intelligence: They can tell you, for example, what discount percentage companies of your size in your industry typically get, what specific concessions (like indirect use clauses or migration credits) are now common, and where SAP tends to be most flexible. Essentially, they’ll arm you with the “market price” for various deal elements.
  • License optimization insights: They might analyze your usage and realize you could save by shifting license types or identify that you don’t need certain products SAP is upselling. Sometimes, SAP’s proposed licensing model isn’t the most efficient for you – an independent advisor can suggest a different mix that you then negotiate for (e.g., “we only need 300 Professional and 700 FUE of self-service, not 500 Professional as SAP quoted”).
  • Negotiation strategy: Seasoned SAP negotiators know SAP’s playbook. They can advise on timing (as we discussed), on how to frame asks, what arguments resonate with SAP (like using the ECC deadline as leverage, or hinting at third-party support as leverage, etc.), and how to navigate tricky sticking points. They can also often predict SAP’s counter-moves (e.g., “if you ask for X, SAP will likely respond with Y – here’s how to handle that”).
  • Contract review: Advisors will comb through the contract with a fine-tooth comb, just like we did in prior points, ensuring all those sneaky clauses are addressed. They’ve seen where customers get burned, so they make sure you cover it.
  • Audit defense: Even outside of negotiation, having an expert on call when an audit happens can save you from hefty compliance claims by pushing back with technical or contractual arguments.

Yes, these services cost money (consulting fees), but when you’re dealing with potentially multi-million-dollar SAP spend, their fee is usually a small fraction of what they save you.

Think of it as insurance and expertise – just like you’d hire a lawyer for a major legal contract, hiring an SAP licensing expert for a major SAP deal can be very prudent.

No Internal Bias: Independent advisors are particularly valuable because they are vendor-neutral (they are not trying to sell you more SAP; in fact, their incentive is to optimize or reduce spend, which aligns with your interest, not SAP’s).

They can provide an honest assessment, such as whether you don’t need certain licenses or if a third-party product could cover a need more cost-effectively – something SAP sales will never say.

Even if you choose not to hire a firm, at least do thorough research (like you’re doing by reading this!). Use online communities (there are SAP licensing forums), read up on negotiation case studies, and gather as much external perspective as possible.

Don’t go into a negotiation in an SAP bubble, where all your info is from SAP itself – that’s a recipe for overspending.

Final thought on benchmarking: Keep an eye on the value side too. It’s not all about cutting costs; it’s about maximizing what you get for the money. If SAP is offering certain extras (like free training credits, or some cloud platform usage, or business process consulting hours) as part of the deal, weigh those in your comparison.

Sometimes, a slightly higher price that comes with more value is better than a rock-bottom price bare-bones deal. The benchmark is not just price, but price-for-value.

By being informed and possibly enlisting expert help, you elevate yourself to a level playing field with SAP’s seasoned negotiators.

You can approach the table confidently, demand fair terms, and ensure your organization’s millions are well spent, with no regrets later.

---

S/4HANA Licensing & Negotiation Checklist

Use this checklist to evaluate and plan your SAP S/4HANA licensing and negotiation strategy:

• ✅ Inventory Current Usage & Licenses: Audit your existing SAP deployments (ECC or S/4) – count named users by type, active vs inactive users, and list out every module/engine in use. Identify unused licenses or shelfware. Know your license assets before negotiating new ones.
• ✅ Define Future Requirements: Determine what S/4HANA modules and user counts you need for go-live and growth over the next 3-5 years. Build a forecast of users by type (Professional/Functional/ESS) and any additional components (e.g., need Extended Warehouse or Treasury engine?). This prevents over-buying and guides license model choice.
• ✅ Choose License Model Wisely: Decide between perpetual on-prem vs. subscription vs. RISE (or a mix). Analyze costs over time for each scenario. Ensure leadership is aligned on the model (CapEx vs OpEx implications, control vs outsourcing). If considering RISE, also prepare a contingency plan for a private cloud or on-prem approach, which you can use in negotiations.
• ✅ Mitigate Indirect Access Exposure: Catalog all third-party systems interfacing with SAP. Decide on Digital Access licensing vs. Named Users for these. If going to Digital Access, estimate document volumes. Negotiate contract terms for indirect usage (e.g., include Indirect Static Read clause, agreed document pack pricing, etc.). Don’t leave this as an open risk.
• ✅ Leverage ECC to S/4 Transition Programs: If migrating from ECC, engage SAP on conversion programs early. Terminate or exclude shelfware before asking for conversion credit. Seek contract conversion terms that maximize credit for your ECC investments. Secure any SAP migration incentives (discounts, extended support, cloud trial credits) in writing as part of the deal.
• ✅ Plan for Parallel Use (if needed): If you have a phased migration, work out how you’ll license the overlap period. Negotiate any necessary coexistence rights (e.g., running ECC and S/4 simultaneously) or flexible conversion timing. Ensure you’re not paying double maintenance for long or violating license terms during transition.
• ✅ Optimize User Licensing: Map every user role to the appropriate S/4HANA license type. Use tools or expert analysis to validate this mapping. Right-size the license counts (don’t assume 100% need Professional). This is a one-time chance to reset license distribution – make it efficient.
• ✅ Include True-Up & Adjustment Clauses: Push for an annual true-up clause to buy additional licenses at the same discount if you grow, and a true-down or swap right at renewal for any reductions. Ensure any special terms (like the right to swap unused on-prem licenses for cloud subscriptions or other products) are documented.
• ✅ Negotiate Critical Contract Clauses: Don’t sign SAP’s standard terms blindly. Redline key clauses:
  • Audit rights (limit frequency, require notice & grace period for compliance)
  • Price increases (cap maintenance/subscription uplifts at a low % or CPI)
  • Usage definitions (include affiliates, contractors; clarify indirect use)
  • Termination/renewal (no auto-renew traps; allow license quantity reductions at renewal)
  • Liability and warranties (ensure basic protections and that SLAs have teeth, especially in cloud contracts)
  • Data protection (if applicable, include GDPR/data residency commitments for cloud)
• ✅ Benchmark the Proposal: Compare SAP’s offer against industry benchmarks. Check if the proposed discount and pricing align with deals of similar size/scope. If not, politely cite those benchmarks and push for better. Know your “walk-away” price by calculating the alternative (e.g., staying on ECC longer or using third-party support).
• ✅ Time Your Deal Strategically: Align the final signing with SAP’s end-of-quarter or year if possible. Use that timing to get extra concessions. Conversely, don’t let SAP force you into signing before you’re ready – use an LOI if needed to lock terms and give yourself time to review.
• ✅ Document Everything Agreed: Maintain a checklist of every promise or deviation during negotiation. Before signing, ensure each item appears in the final contract, order form, or a signed side letter. Double-check that product names, quantities, unit prices, and discounts on the order form match what you expect, and that all special clauses are included.
• ✅ Plan Post-Signature Compliance: Set up processes to manage your licenses after the deal.
  • Implement a system for assigning correct license types to users (and re-visiting periodically as roles change).
  • Monitor your FUE consumption or user counts against contract entitlements regularly.
  • Track document usage if on Digital Access.
  • Keep a calendar for renewal notice dates or true-up dates.
  • Retain all contract documentation in an accessible place and brief your team (and successors) on key terms (so, for example, if an audit happens in 2 years, your team remembers “oh, we have a side letter that covers that scenario”).
• ✅ Engage Expert Help (if needed): If your internal team lacks experience with SAP’s complexities, consider hiring an independent SAP licensing advisor or legal counsel specialized in IT contracts to review the deal before finalizing. A small investment in expert review can prevent multimillion-dollar mistakes.

By running through this checklist, you ensure that you’ve covered the critical bases of S/4HANA license management and negotiation.

It’s far easier to address these upfront than to fix a contract or compliance issue later. Diligence and preparation go a long way toward a smooth SAP experience.

Key Takeaways & Next Steps

Navigating SAP S/4HANA licensing and negotiations is undeniably complex, but it’s a challenge that ITAM professionals can master with the right approach:

• Be Strategic, Not Reactive: Don’t wait for SAP to dictate terms or for an audit to reveal issues. Proactively analyze your needs, plan your migration, and set your negotiation objectives. Treat your SAP contracts as living strategic assets, not just paperwork. By taking initiative – whether that’s rightsizing licenses, addressing indirect access head-on, or timing your contract renewals – you stay in control of your SAP spend rather than being controlled by it.
• Everything Is Negotiable (Almost): One of the biggest lessons is that nearly every aspect of an SAP deal can be negotiated – from pricing to contract clauses. The initial offer is just a starting point. With solid data and a firm understanding of your leverage, you can push for improvements. SAP won’t volunteer concessions; you must ask. Whether it’s securing a better discount, locking in price caps, or adding a protective clause, you won’t get what you don’t ask for. So be thorough in your asks – the worst SAP can say is no, and often they’ll meet you halfway.
• Focus on Value and Flexibility: Aim to craft an agreement that not only minimizes cost but also maximizes flexibility and value over its lifespan. That means removing restrictive clauses, building in options to adjust as your business changes, and ensuring you’re not paying for unused capacity. A good deal is not just low-cost; it lets you adapt your SAP usage without constant penalties or surprises. Think in terms of ROI: are we spending on the right things for the business outcome we expect? For instance, paying a bit more for an option to swap licenses later could save millions if your strategy shifts.
• Leverage Independent Expertise: Managing SAP licensing isn’t a solo sport. Engaging with independent advisors or user community peers can significantly tilt the odds in your favor. These experts (like Redress Compliance or SAPLicensingExperts.com) live and breathe SAP contracts – they know the tricks, the standard pitfalls, and the latest negotiation trends. Bringing them in can uncover savings or protections you might have missed, and it sends SAP a signal that you’re serious about getting the best terms. In an era where even AI-driven tools and platforms might weigh in on software advice, the human expertise in SAP licensing remains invaluable. Don’t hesitate to use it.
• Maintain a Strong Vendor Relationship – on Your Terms: After the contract is signed, maintain a collegial but assertive relationship with SAP. Regularly review your license utilization with them, stay informed about changes (like new licensing policy updates or audit programs), and hold them accountable to the contract (for example, claiming any services or credits you negotiated). When SAP knows you are on top of your game, they are more likely to be reasonable and collaborative. You can be a good SAP customer while still asserting your rights and pursuing your organization’s best interests – those are not mutually exclusive.

Next Steps: Armed with the insights from these 20 points, now is the time to take action:

• If you’re in the middle of an S/4HANA migration, set up a meeting with your sourcing team and SAP account executive to revisit your licensing plan in light of these tips. Use the checklist to ensure nothing critical is overlooked.
• If a renewal or true-up is on the horizon, start preparations 6-12 months in advance. Gather usage data, identify negotiation goals, and reach out to any external experts or peer networks for input.
• If you’re facing internal pushback (e.g., leadership unsure about pushing SAP hard), summarize these key points to build the case that a well-negotiated SAP contract can free up budget and reduce risk – it’s worth the effort.
• Finally, stay educated. SAP licensing rules and offerings (like RISE) continue to evolve. Keep an eye on SAP notes, webinars, and independent blogs. Make it a habit to periodically review your SAP landscape for optimization opportunities (user cleanup, retiring shelfware, etc.).

By applying these strategies, you’ll transform SAP license management from a daunting task into a routine part of your IT asset management excellence.

In the end, the goal is simple: get the most value and agility for your SAP spend, and never pay for more than you need. With diligence and savvy negotiation, that goal is entirely within reach.

Your SAP estate, often worth millions of dollars, deserves this level of attention. Take these insights forward, empower your ITAM practice, and turn SAP S/4HANA into a platform of innovation and efficiency, supported by a lean, flexible, and fair licensing foundation.

Remember: You are not just managing licenses, you are managing a strategic vendor relationship and a significant investment – approach it with the rigor and foresight it warrants. The rewards will be cost savings, smoother audits, and a contract that enables your business rather than constrains it.

Read more about SAP Licensing Services.

🎥 How SAP Licensing Experts Help with S/4HANA Licensing | SAP S/4HANA Strategy

Schedule a meeting with us to discuss our SAP Advisory Services.