SAP License Agreement Structure
- Scope of Use: Defines authorized software, user number, and agreement duration.
- Rights Granted: Details on usage rights, including copying and modifications.
- Customer Obligations: Covers software payment and compliance with SAP’s Licensing rights.
- Maintenance and Support: Terms for receiving SAP services.
- Termination: Conditions and consequences for agreement termination.
SAP License Agreement Structure and Clause
SAP’s on-premises licensing for ERP (whether legacy SAP ECC or modern SAP S/4HANA) is notoriously complex and filled with pitfalls. A typical SAP license agreement can span dozens of pages of definitions and terms.
There are thousands of licensable SAP items and dozens of user license types and metrics, making it challenging for organizations to align what they’ve purchased with what they use. The stakes are high: misjudging these terms can lead to compliance audits, unbudgeted fees, or paying for “shelfware” (unused licenses) year after year.
This playbook—written in an independent, advisory tone—breaks down the structure and key clauses of SAP ERP license agreements (excluding cloud subscriptions like RISE with SAP) and provides CIOs with guidance on managing risk and cost proactively.
We cover legacy ECC agreements and newer S/4HANA contracts, highlighting how to protect your organization’s interests through savvy contract management and negotiation.
Legacy ECC vs. S/4HANA Contracts: Key Differences
While SAP ECC and S/4HANA are both licensed as on-premise ERP software, there are some notable differences in their contract structures and terms:
- User License Categories Evolve: ECC and S/4HANA use the named-user model with tiered user types. In ECC contracts, common user categories include Professional, Limited Professional, Employee Self-Service, etc. S/4HANA agreements refined these definitions (e.g., renaming “Limited Professional” to Functional User, and introducing Productivity User for self-service roles). The fundamental tiers remain similar, but newer S/4 contracts have more standardized definitions for each user type. CIOs should map older user licenses to the S/4 terminology during migrations to ensure the equivalency of rights.
- Digital Access vs. Indirect Use: Indirect usage (third-party systems or users accessing SAP data) was a gray area in many ECC-era contracts. SAP’s 2017 lawsuit against Diageo (over Salesforce users indirectly querying SAP) was a wake-up call, with SAP claiming ~£54 million in fees. New S/4HANA contracts offer an optional Digital Access model (document-based licensing) to handle indirect access more transparently. This means that instead of requiring extra named-user licenses for indirect users, SAP can license certain document transactions (sales orders, invoices, etc.) created via non-SAP systems. Legacy ECC agreements won’t mention “Digital Access” explicitly – it must be added via contract amendment if adopted. Organizations sticking with the traditional model must ensure the contract’s definition of “users” covers third-party access to avoid surprise fees.
- Database and Infrastructure: ECC could run on third-party databases (Oracle, SQL Server, etc.), often licensed separately. S/4HANA requires the SAP HANA database. S/4 contracts, therefore, include terms for HANA licensing – either a restricted-use “runtime” license (typically ~15% of the application value) or a full-use HANA license (priced by memory or cores). This can significantly impact costs. CIOs negotiating S/4 deals must verify if the HANA runtime is included and sufficient; if a full-use HANA is needed (e.g., to run non-SAP applications on the same database), it can double the database cost if not planned. This is a new consideration compared to ECC contracts.
- Contract Language and Structure: Legacy ECC agreements often have more customized wording (many were negotiated a decade or more ago and amended over time). S/4HANA contracts today tend to use SAP’s latest standard T&Cs, which may include updated clauses around support, audit, and use definitions. For example, SAP’s modern Software Use Rights documents clarify usage definitions and might be incorporated by reference. CIOs reviewing a new S/4 contract should not assume it’s identical to their ECC deal – subtle changes in definitions (for indirect use, user metrics, etc.) can occur.
- Maintenance and Support Alignment: If you are transitioning from ECC to S/4HANA, SAP often provides license conversion programs. Under these, your existing ECC perpetual licenses can be converted to S/4HANA licenses, usually at no new license cost (since you already paid for ECC) but with some adjustments in annual maintenance fees. It’s important to negotiate how the maintenance base is calculated post-conversion. Also note that SAP’s Enterprise Support (a premium support tier) is now the default for S/4HANA in many cases. Enterprise Support carries a higher fee (~22% + 2-4% of license price) than the older Standard Support (~22%). Some older ECC contracts might still be on Standard Support – moving to S/4 could implicitly push you into the higher support cost unless you negotiate otherwise.
(In the sections below, we discuss each major element of SAP license agreements in detail, relevant to both ECC and S/4HANA on-premise contracts.)
License Metrics and User Types
Named Users – The Foundation: SAP primarily licenses its ERP software per user. Every individual who accesses the SAP system (directly or via certain interfaces) needs their license. Unlike some software models, SAP does not allow sharing licenses or concurrent user floats – if 100 people use SAP at various times, you need 100 named user licenses (even if only 50 are on at once).
Each user license is categorized by type, reflecting the scope of the user’s activities. User licenses typically account for 40–70% of the total contract value in an SAP deal, so getting the categories right is critical.
Common User License Categories: A typical SAP contract will define several classes of users, for example:
- Professional User – A full-access license that permits using all standard SAP functionality, including configuration and high-level tasks. These are the power users or broad role users (e.g., an SAP finance manager or IT administrator) who need unrestricted access. Professional users are the most expensive category per user.
- Limited Professional / Functional User – A license for users who work in a specific functional area or have a narrower scope of use. For instance, a sales clerk entering orders, or an accounts payable clerk processing invoices. These users perform regular transactions but with limited scope (they wouldn’t typically configure the system or use every module). In ECC contracts, they might be called Limited Professional, while S/4HANA uses terms like Functional User. This category costs less than a Professional user (often significantly cheaper), reflecting the restricted usage rights.
- Employee Self-Service (ESS) / Productivity User – A low-level license for infrequent users who only perform self-service tasks or very limited operations. Examples are employees who just enter their time sheets, file expense reports, or view their HR data. These licenses are priced very low per user. In S/4HANA agreements, SAP often labels this as a Productivity user or similar, whereas older contracts might say ESS user. They cannot perform core transactions beyond their self-service scope.
- Developer (and Other Technical Users) – Typically, SAP also offers a Developer user license for those who write ABAP code, create custom programs, or technically manage the system. Developers usually require deep access in development environments. Some contracts bundle a few developer licenses with the software, but large teams may need to license them explicitly. Developer users often have similar access rights as Professional users (in non-production systems), but are meant for engineering staff. Depending on the contract, there may also be categories like Business Analytics/Business Expert users for heavy reporting users, and Test or Communication User licenses for technical integration accounts.
License Metrics for Engines/Modules: In addition to user licenses, SAP agreements often include “engine” or package licenses measured by metrics other than users. For example, you might license SAP’s ERP core to users. Still, add-on products (like SAP Payroll, SAP HCM, SAP CRM, or industry solutions) could be metered by things like the number of employees, revenue, the number of orders processed, or other business metrics.
These are specified in the contract’s price list with a defined unit (e.g., “SAP Payroll—licensed for 5,000 employees”). Each such metric is effectively its license pool. Managing these requires tracking the particular metric in your business (e.g., actual employee count vs. licensed count).
For example, you might exceed your licensed metric if you licensed SAP Extended Warehouse Management by “number of warehouse transactions per year,” and your activity grows.
Understanding and periodically checking these metrics is crucial to avoid compliance issues. SAP has over 100 engine metrics across its product catalog, so focus on those relevant to your deployment. Ensure every metric’s definition is crystal clear in the contract (how it’s counted, what constitutes usage, etc.).
Example: An SAP ERP contract might include 500 Professional Users, 1,000 Employee Users, and an engine license for SAP Payroll for 5,000 employees. In this case, you must ensure no more than 500 individuals perform high-level tasks, no more than 1,000 employees access self-services, and that your HR headcount doesn’t exceed 5,000 without additional licensing. Each of these figures can be audited. Misclassification (e.g. using an Employee license for someone who actually performs tasks requiring a Professional license) is a common compliance issue that can lead to audit findings.
Key Considerations for CIOs: Ensure your team maintains a user license assignment procedure – every SAP account should be mapped to the correct license type based on the user’s role. Regularly review user lists to remove or reassign licenses when people leave or change roles (licenses can be reassigned internally, so unused ones can be allocated to new hires without buying more).
For engine metrics, set up internal tracking (or use SAP’s measurement tools) to monitor consumption of licensed metrics (e.g,. document counts, employees, revenue). Avoid “license creep” where users are all left as the default (Professional) due to convenience – it’s worth the effort to classify them properly and save on license fees. Also, scrutinize any special product licenses and their units; if a metric is likely to grow (say, your business is expanding), negotiate a buffer or a scalable pricing model upfront.
Indirect Access and External Use
One of the most infamous SAP licensing “gotchas” is indirect access – when users or third-party systems interact with SAP data without directly logging into SAP. In an ECC environment, this might occur if, for example, a non-SAP e-commerce website pulls customer or order data from SAP, or if employees access SAP through a third-party mobile app.
The contract’s default position is that any SAP functionality or data usage requires an appropriate license, even if mediated by another system. Many CIOs were caught off guard by this in the past. The landmark SAP vs. Diageo case in 2017 illustrated the risk: SAP sought approximately £54 million for unlicensed indirect use when Diageo’s Salesforce system was querying SAP data. This case signaled to the industry that even read-only access or data interchange can trigger license obligations.
SAP’s response introduced a new licensing approach for indirect usage in the S/4HANA era: the Digital Access Document Model. Rather than requiring a named user license for every possible indirect user (which was impractical), SAP’s digital access model defines certain business “documents” (Sales Orders, Invoices, Purchase Orders, etc.) and charges license fees based on the number of those documents created or accessed via third-party applications.
Customers can purchase document pack licenses (e.g. in blocks of 1,000 documents) for these indirect interactions. This model, offered from 2018 onward, aimed to provide a predictable metric for indirect usage. However, it’s optional – if a customer doesn’t adopt digital access licensing, SAP can still enforce the older rules (i.e., counting indirect users as named users) during audits.
CIOs must actively decide how to handle indirect access: either negotiate and embrace the digital document licenses or ensure the contract permits their specific indirect use cases under existing named-user licenses.
Mitigating Indirect Access Risk: The best defense is clarity and proactivity. Inventory all third-party systems interfacing with SAP, downstream or upstream. For each, determine what data flows and who (or what) initiates the SAP interaction. This should be discussed with SAP during contract negotiations. Whenever possible, get specific contract language to address these scenarios.
For example, smart customers negotiate an “Indirect Static Read” clause, which permits certain types of read-only data exports or reports from SAP to external systems without requiring extra licenses. (An Indirect static read typically means data extracted on a schedule, not updated in real time, and not modified once outside SAP—often allowed license-free if defined correctly.)
Also, define “use” and “user” in the contract: ensure it’s explicit whether an external application or API call constitutes a user. If you intend to use SAP data for a public website or partner access, spell that out and agree on a licensing approach upfront. Addressing it in the contract is much safer than arguing about it during an audit.
Digital Access Agreements: If you opt for SAP’s digital access license model, nail down the details. The contract should list which document types are licensed and the volume included. For instance, if you agree to license 100,000 digital documents per year, it should say which types (SAP’s model covers 9 document types by default) and the price per block if you exceed that.
Understand that if you don’t have a digital access agreement and are later found to have indirect usage, SAP may count the documents retroactively and bill you at list price. This “audit surprise” can be extremely expensive. Thus, if indirect usage is significant for your business (e.g., many orders coming from a web store into SAP), it may be wiser to proactively license digital access at a negotiated rate rather than face unplanned fees. SAP sometimes offers steep discounts on digital access licenses (they had programs like a 90% discount for early adoption) – negotiate these as needed, but ensure the contract records the discount and the metric.
In summary, treat indirect access as a known risk and manage it: get it in writing what is allowed. For peace of mind, you might also include a clause stating that if some indirect usage that wasn’t explicitly discussed is discovered, you can license it at standard rates before SAP pursues legal remedies.
While SAP may not readily agree to forgiving all indirect use, having any “cure” period or predefined pricing in the contract is better than an open-ended exposure. Many CIOs also engage independent licensing experts (like Redress Compliance) to review integration architectures and ensure indirect use is properly licensed. This outside perspective can be invaluable, since SAP’s own sales team might downplay a risk until it becomes a compliance issue later.
Audit Rights and Compliance Safeguards
Every SAP license agreement contains an audit clause granting SAP the right to inspect your usage and verify compliance. SAP typically initiates an audit annually (sometimes the clause says no more than once per year, except for cause).
In practice, SAP regularly exercises this right by asking customers to run measurement tools (like SAP USMM and License Administration Workbench (LAW) reports) and submit the data. Audits can also involve SAP scripts or even on-site reviews in some cases. From a CIO’s perspective, an audit is disruptive and potentially expensive if it finds you under-licensed, so the contract’s audit provisions should be managed to prevent a worst-case scenario.
Key audit clause elements to negotiate:
- Advance Notice: Ensure the contract stipulates that SAP must provide reasonable notice (e.g., 30 days written notice) before an audit. This at least gives your team time to prepare data and ensure key staff are available.
- Frequency and Scope: Try to cap formal audits to no more than once yearly (unless a material issue is found). Also, define the scope: for instance, the audit should be limited to using SAP products you’ve licensed and exclude irrelevant data. If you have multiple SAP systems, clarify if each system can be audited separately or all at once.
- Method and Interference: You might include language that audits will be conducted to minimize business disruption, for example, that any on-site activity will be during normal business hours, or that SAP’s auditors must comply with your security and privacy policies. While SAP won’t relinquish its right to audit, it often will accept reasonable limits like these.
- Confidentiality: Add a clause that any information uncovered in the audit will be used solely to verify compliance and cannot be improperly disclosed. (SAP’s standard contracts typically have confidentiality provisions, but it’s good to reiterate this around audits, especially if you’re giving them sensitive usage data.)
- True-Up Period: Most importantly, include a “cure period” or true-up mechanism. If an audit finds you short on licenses, you can purchase the necessary licenses at your pre-negotiated discount rates without penalty. We cover true-ups in the next section, but from an audit clause perspective, you want the contract to say something like: “Customer shall have 60 days to acquire any additional licenses required to resolve compliance gaps identified by the pricing and discounts of this agreement.” This way, an audit doesn’t automatically mean list price fees or breach of contract – you can fix the issue under normal commercial terms.
In addition to contract terms, prepare internally for audits. Maintain detailed records of license assignments, keep snapshots of user counts, and even consider running SAP’s license measurement tools quarterly yourself. This lets you find and correct discrepancies (e.g., a user with the wrong license type) before SAP does. It’s also wise to have one team or person responsible for SAP license management so that you can respond confidently if an audit notice comes.
If the contract allows it, you may even do a self-audit report to SAP annually (some agreements have language for customer self-declaration, especially if a true-up model is in place). By demystifying the audit process and setting ground rules in the contract, CIOs can turn the audit clause from a major risk into a manageable routine.
Remember: the goal isn’t to avoid audits entirely (unlikely with SAP), but to prevent ambush – no surprise $10M findings because you already knew where you stood and had the contractual right to rectify issues on your terms.
True-Up Mechanisms for License Growth
Business needs aren’t static – over 5 years, a company might add new SAP users, expand into new modules, or integrate additional systems. Without provisions for this growth, any usage beyond your initial licenses is technically non-compliant until you buy more (and SAP could penalize you in an audit for that interim).
This is where a true-up clause becomes incredibly valuable. A true-up (or periodic reconciliation) mechanism lets you proactively adjust licensing on a scheduled basis, rather than constantly worrying about crossing the line.
Under a negotiated true-up clause, you and SAP agree that once per period (typically yearly), you can review your license usage. If you have exceeded your entitlements (e.g. you used 10 more Professional Users than you purchased, or your engine metric went 5% over), you simply report that and purchase the additional licenses at the pre-agreed price/discount.
There would be no penalties or back-dated fees if you true-up in good faith. Essentially, it’s like an honor system with a safety net: you promise to pay for what you used, and SAP agrees not to punish the overuse as long as it’s corrected at the true-up point.
Why True-Up Helps: It transforms the dynamic with SAP from punitive to cooperative. You acknowledge that forecasting exact needs is hard, so both sides plan for a reasonable adjustment process.
This avoids scenarios where an audit finds you 50 users over and SAP tries to charge full list price plus maintenance back-charges for those 50 – instead, you’d buy them at your normal discount when you realized the need. True-ups also help budgeting: CIOs can anticipate some annual growth and budget license additions rather than potentially huge unplanned purchases.
If possible, negotiate specifics such as:
- The true-up happens annually at renewal time (or another set date).
- You will be charged the same unit price as the original purchase for additional licenses. (If your initial deal got 50% off SAP list price, ensure that the discount carries forward to true-up units. Otherwise, SAP might agree to sell you shortfall licenses at a much higher price, negating the benefit.)
- Ideally, any new licenses bought via true-up are co-terminus with the original agreement and carry the same maintenance percentage. This keeps everything aligned.
Some SAP contracts don’t include an automatic true-up by default, but you can request it. SAP may be amenable, especially if you present it as “we want to stay compliant, help us do so systematically.” True-up clauses are more common in large enterprise agreements or SAP Unlimited License Agreement (ULA) structures, but even standard deals can incorporate elements.
CIO Tip: If SAP resists a formal true-up clause, another approach is negotiating conditional remedies. For example, you could insert language in the audit clause (as mentioned) that if minor overuse is found, you can purchase licenses at contract rates to cover it. That’s effectively a true-up on the backend.
The goal is to avoid any scenario where SAP can leverage compliance gaps for outsized revenue. Independent licensing advisors often consider true-ups a top recommendation – asking for it in initial negotiations is easier than begging for mercy during an audit.
Price Protections and Caps
Negotiating a sizable discount on an SAP deal is only half the battle – the other half protects that deal’s value over time. If left unchecked, SAP agreements allow various fees to increase year over year, potentially eroding your savings and blowing up the total cost of ownership. The two main areas to watch are annual maintenance fees and future purchase prices.
Maintenance Fee Increases: SAP’s standard support fees have historically been about 22% of the net license price annually (or higher if Enterprise Support). However, SAP reserves the right to increase maintenance rates over time.
In recent years, SAP has raised maintenance fees, citing inflation – for instance, in 2023, many customers saw a 3.3% increase, up to 5% in 2024. Without contractual caps, these increases can compound. Over a decade, a 5% yearly hike would make your maintenance 63% more expensive than when you signed the deal, potentially wiping out any upfront discount you achieved.
To combat this, savvy customers negotiate a cap on maintenance escalation. For example, you can stipulate “maintenance fees shall not increase by more than 3% per year”, or tie it to a public index (e.g., CPI inflation) with a maximum. Some even negotiate a freeze for a few years – e.g,. no increase for the first 3 years of support, to stabilize costs. It’s critical to get this in writing. Do not rely on verbal assurances that “SAP usually keeps increases small” – a change in policy or economic conditions can change that, and you’ll have no recourse if the contract is silent. If SAP pushes back, point out that many enterprise software vendors offer caps or fixed maintenance terms, and that your CFO needs cost predictability.
Another maintenance-related protection is ensuring the maintenance base is your actual price. Suppose you got an unusually deep discount on licenses. In that case, SAP sometimes tries to calculate the 22% support fee on the list price (a practice known as “pegged maintenance” or calculating on unrealized license value).
For example, if a $1M list price license was sold to you for $500k, 22% of the list would be $220k, but 22% of what you paid is $110k. You want the latter. Explicitly state in the contract that maintenance is X% of the net fees paid by the customer. Otherwise, your effective maintenance rate could be double what you think. Independent experts have flagged this tactic, and CIOs should be alert.
Price Holds for Expansion: Another common clause is a “price protection” or price hold on future purchases. When you negotiate a big SAP deal, you might only purchase what you need then, but expect to buy more licenses later as you grow or roll out to more users. Without protection, those later purchases could be at a much worse discount (especially if the initial deal was tied to a large volume).
Negotiate a provision such as: “For X years, additional licenses of the same type may be purchased at the same unit price (or same discount percentage) as the initial purchase.” This locks in your discount for expansions. For example, if you bought 1,000 Professional User licenses at $1,000 each (50% off list), the contract could allow you to buy up to 500 more at $1,000 each within the next two years.
Otherwise, SAP might charge $2,000 each (list price) for those new users later, claiming the original discount was only for the big initial purchase. A price hold ensures consistency and can save millions if your SAP footprint grows. Also, consider locking in the price list – SAP updates list prices periodically, so either tie additional purchases to the current price list or cap any list increase.
Multi-year Subscription Deals: (Briefly touching on cloud/subscription, though not the focus here.) If you ever sign a multi-year subscription (for products like SuccessFactors, Ariba, or if considering RISE in the future), it is vital to cap renewal uplifts.
Many cloud contracts auto-renew with a clause like “at SAP’s then-current rates,” which could mean a big jump. Apply the same idea: negotiate a clear cap on any subscription renewal increase, or fix the renewal price in advance. While this playbook excludes cloud product details, the principle of price protection applies universally.
In summary, guard your deal’s value. Without these clauses, the attractive TCO you present to your board today might quietly worsen over time due to compounding fees. By capping increases and locking in discounts, CIOs ensure that cost projections remain accurate and that SAP can’t gradually undermine the agreement’s economics.
Maintenance and Support Terms
Annual maintenance (support) fees are an inevitable part of SAP ownership for most on-premise customers – this cost often equals 20–22% of your license spend every year. Over 5 years, you will likely pay more in maintenance than you did upfront for the licenses. Therefore, understanding and negotiating the maintenance/support clause is essential for long-term cost management.
Support Levels – Standard vs. Enterprise: SAP offers different support tiers. Standard Support historically costs ~18–22% of license fees and covers basic support, fixes, and minor updates. Enterprise Support is a premium level (now the default for new agreements) that can cost around 22% + an additional 2–4% (so roughly 24–26% of license fees annually). Enterprise Support includes enhanced services like faster response SLAs, more proactive support, and additional tools.
Check your contract to see which level you are subscribing to. If Enterprise Support isn’t necessary for your needs, you could try negotiating for Standard (though SAP has been phasing it out for new deals). At minimum, lock in the percentage in the contract so it doesn’t jump unexpectedly. Also, watch out for clauses that let SAP unilaterally move you to a higher support tier or change the program – you want consistency unless you choose to upgrade.
Maintenance Coverage: The support clause will detail what you get for that fee – usually the right to contact SAP support for issues, access to patches and legal/regulatory updates, and importantly, the right to download and implement new versions of the software (this is how customers with ECC licenses can technically download S/4HANA if it’s considered a successor product they have rights to).
Ensure the contract states you are entitled to all updates and new releases for products under maintenance. If SAP has announced an end-of-support date (for example, ECC mainstream maintenance currently ends in 2027), clarify what happens then. Perhaps negotiate that you can extend support (at a price) or convert those licenses to something else (like S/4) as part of your maintenance benefits. This is forward-looking, but crucial for strategic planning.
Co-Termination and Proration: If you purchase additional licenses mid-year, SAP will typically prorate the maintenance fee to align with your existing maintenance renewal date (this is known as co-termination).
For example, if your annual maintenance renews every January 1 and you buy more users in July, you’ll pay 6 months of maintenance for those new users for the first partial year. Ensure the contract explicitly states that it’s standard practice, but clarity helps avoid double billing. Also, all your licenses should ideally renew on the same date for simplicity.
Right to Reduce Support Scope: One contentious area is the ability to drop maintenance on unused licenses (shelfware). SAP’s standard policy is “all or nothing” – you either keep maintenance on your whole license estate or you terminate support entirely. They do not make it easy to selectively turn off support for a subset of users or a module you’re not using. However, this is negotiable in some cases.
If you have significant shelfware, you might push for a clause that allows you to reduce your licensed volume at renewal (essentially a partial termination of support) without terminating the whole agreement. SAP often resists because they don’t want customers dropping support on any piece (they fear it sets a precedent). However, some customers have obtained one-time rights to cut, say, 10% of users from support or to “swap” licenses. If SAP won’t allow it, another approach is to move those unused licenses to a separate contract that you can terminate.
This is complex and usually needs expert help – the takeaway for a CIO is to avoid over-committing in the first place (so you don’t pay maintenance for nothing), and if you find yourself with shelfware, consider engaging SAP about some relief or a trade-in (as described in the shelfware section).
Third-Party Support Option: A big bargaining chip in recent years is the emergence of third-party support providers (like Rimini Street) who offer support for SAP products at roughly 50% of SAP’s fee, albeit without access to new SAP releases.
Some organizations have leveraged the threat of moving to third-party maintenance to negotiate a better deal from SAP on support costs. For example, if SAP knows you are evaluating dropping their support, they might offer a discount on maintenance or other concessions to keep you. In one negotiation scenario, a customer managed to cap SAP maintenance at 19% (down from 22%) by indicating they might otherwise go to a third-party provider.
If you go down this road, negotiate a reinstatement clause: if you leave SAP support (say for 2 years on third-party) and want to return, SAP normally charges back maintenance for the gap period. Try to get a clause waiving or limiting that, so you aren’t financially barred from returning. This is difficult, but even having it on the table can pressure SAP to offer a more palatable deal upfront.
In summary, maintenance is a recurring cost that often grows. As CIO, treat the support clause with as much weight as the initial license prices. Negotiate the rate, protect against increases, and align support terms with your business needs (service levels, coverage period, etc.).
Ensure you know the process if you ever want to terminate maintenance – usually, you must give notice (e.g., 3 months before renewal). If you do terminate, you keep the perpetual license to use the software, but lose support and updates in the future.
That may be a viable strategy for stable systems (some companies freeze an ECC system and drop maintenance to save cost, if they don’t need updates). But be aware of the trade-offs and have any re-entry terms pre-negotiated. Above all, don’t pay for support you don’t need – optimize the level and scope of maintenance to fit your actual usage of SAP.
Shelfware and Unused Licenses
“Shelfware” refers to software licenses you’ve purchased but aren’t using in production. In the SAP world, shelfware is a common and expensive problem: organizations often overbuy licenses during initial negotiations due to vendor pressure (“buy more now for a bigger discount”) or over-optimistic growth projections. Those unused licenses then sit idle, but you continue paying maintenance on them year after year, consuming budget with no return on investment.
Studies and anecdotal evidence suggest that it’s not unusual to find 20–30% of users or modules underutilized in large SAP environments. For example, a company might have licensed the SAP CRM module but never fully deployed it, or purchased 1,000 Professional User licenses but only 800 people use SAP regularly.
Since SAP agreements don’t let you easily give licenses back, those extra 200 licenses are “shelfware,” incurring 22% annual support fees for nothing. Over a few years, the maintenance on shelfware can equal or exceed the license’s cost.
How to mitigate shelfware risk:
- Prevent Overbuying at the Start: The best cure is prevention. Be very realistic about your needs during negotiations. SAP sales reps will offer attractive bundle deals (“if you license an extra 500 users now, we’ll apply a higher discount across everything”) or pitch future needs (“you’ll expand to new subsidiaries, so buy the licenses now”). It’s tempting, but remember that every license you buy is a perpetual cost (maintenance). It can be wiser to start with what you need now or in the near-term, even if that yields a bit less discount, than to lock in a bunch of shelfware just to get a bigger discount. Do the math: a 10% better discount on license fees might be negated by a few years of maintenance on unused users. CIOs should challenge assumptions on growth and only pay for reasonably certain requirements. You can always buy more later (especially if you’ve negotiated price holds as discussed).
- Negotiate Flexibility: If you must commit to a larger number of licenses (perhaps due to an enterprise agreement or a corporate directive), try negotiating license exchange or retirement options. For example, include a clause allowing you to swap unused licenses for other SAP products of equal value. SAP has occasionally allowed customers to convert shelfware into credits toward new software (especially cloud products). Another angle is a true-down at renewal (for subscriptions) or a one-time reduction right for perpetual licenses. While SAP won’t refund you for licenses, they might let you stop paying maintenance on certain unused components if you commit to investing in something new. The key is to get any such arrangement in writing. Suppose your contract says you can exchange 100 unused Supplier Self-Service licenses for 100 Employee Self-Service licenses, or drop maintenance on a retired module and apply that budget to a new SAP cloud service. In that case, that’s gold – it gives you a path to recoup value from shelfware.
- Ongoing License Management: Treat SAP licenses as a living portfolio. Conduct periodic internal reviews (at least yearly) to identify underutilization. If a certain module isn’t used, consider consolidating users off it and talking to SAP about options (perhaps they’ll propose a swap to something you will use). If hundreds of user licenses are unassigned, see if you can reduce your named user allocations formally (in case an audit counts named users by what’s assigned in the system – unassigned licenses usually aren’t a compliance issue, but you’re paying maintenance regardless). Sometimes, just demonstrating to SAP that you are aware of shelfware and are unhappy paying maintenance on it can lead them to offer a compromise in your next negotiation (they might bundle some new functionality or give a credit for those idle licenses to keep you happy).
Remember that once you’ve bought perpetual licenses, SAP’s default stance is “no backsies.” They won’t buy them back or voluntarily reduce your maintenance base. Thus, CIOs should bake shelfware avoidance into their procurement strategy from day one. If you end up with shelfware despite best efforts, use it as a bargaining chip: for instance, “We have $500k of licenses not in use – we’d rather spend some of that on new SAP innovations. How can we repurpose that investment?”
Independent licensing experts can help quantify your shelfware and suggest creative contract terms to mitigate costs. The goal is to minimize paying for shelfware in the long term, either by not having it or finding a way to make it useful (or at least not paying maintenance on it forever). By actively managing this, CIOs can trim waste and ensure IT spend is aligned with actual business usage.
Scope of Use and License Assignment
SAP license agreements limit how much of the software you can use (users and metrics) and how and where you use it. The scope of use clauses defines the boundaries, including geographic use, legal entity restrictions, and permitted business scenarios. CIOs must pay attention to these terms to avoid unknowingly violating them as the business evolves.
Geography and Entity: Many SAP contracts specify that the software is licensed for use in certain countries or regions and by the legal entity (company) that signed the agreement (and its affiliates, if defined). If your organization operates globally or has multiple subsidiaries, ensuring the contract’s definition of “Customer” includes all the entities that will use the system is critical. If you implement SAP in Europe under a contract signed by your US parent company and later a branch office in Asia (a different legal entity) starts using it, you want that to be allowed. An ambiguous contract could technically limit usage to the entity that signed, meaning other affiliates’ use is unlicensed. Always list out or broadly define affiliate usage rights. Similarly, if there are any explicit country restrictions (less common in modern contracts, but sometimes certain export-controlled countries might be excluded), know them. Ensure your planned deployments (e.g., a backup instance in another region, or a roll-out to a foreign subsidiary) are covered under the license grant.
Internal vs External Use: SAP licenses are generally for your company’s internal business purposes only. Running an external service bureau or offering SAP functionality to third parties (like using your SAP system to service external clients) is typically disallowed unless explicitly licensed (SAP has separate provider licenses for that scenario). Make sure if you have any setup where a partner or customer interacts with your SAP system (beyond just indirect use) that it’s addressed. Also, if you outsource some operations (say, a BPO firm runs your accounts payable using your SAP system), the contract should allow third-party consultants or contractors to use the software on your behalf. Usually, this is permitted if those users are counted under your named user licenses and you remain responsible for compliance. But it’s best to explicitly mention that “Third-party service providers acting on the customer’s behalf may use the software, provided that use is only for the customer’s internal operations.”
Technical Boundaries: Some older contracts had clauses preventing using certain SAP licenses in a “commercial processing” environment for third parties, etc. Also, if you intend to deploy SAP on cloud infrastructure or in a new technical way, ensure nothing in the contract prohibits it. For on-prem licenses, SAP generally doesn’t care if you run it on AWS or your data center, as long as access is per the license terms. However, double-check if any clause ties the software to a named installation or hardware – this is rare nowadays (SAP has become flexible on virtualization, etc., compared to decades past).
Mergers, Acquisitions, Divestitures: A vital but often overlooked clause is what happens if your company’s structure changes. By default, SAP does not allow free transfer of licenses to another independent entity. If you spin off a division into a new company, that new company can’t automatically take the SAP licenses with it unless SAP approves (and they might demand fees or a new contract). Likewise, suppose you acquire a company and want to bring them onto your SAP system, strictly speaking. In that case, only your originally licensed entities can use the software, not the newly acquired legal entity (unless you add them to the contract). This is where an assignment clause is important: negotiate that you can assign or transfer the agreement in the event of internal reorganizations, merger,s or divestitures. For example, “Customer may assign licenses to any Affiliate or successor entity in the event of a merger, acquisition, or divestiture, with notice to SAP.” SAP may want to approve such transfers, but try to get language that approval “shall not be unreasonably withheld” or that it’s automatic for affiliates under your control. The contract’s definition of Affiliate should be broad (e.g., >50% owned). This protects you from having to re-buy licenses for a part of the company that gets restructured.
Consequences of Scope Violations: If you use SAP out of scope (say, your contract says Europe only and you roll it out in Asia), SAP could consider that a breach and demand additional fees for the unlicensed usage. Usually, they’d prefer to sell you the proper license extension, but this can become a negotiation pain point during an audit. Avoiding the issue by aligning the contract to your operational reality and plans is better. Think ahead 5-10 years: if you might expand to new regions or divest a business unit, bake flexibility in now.
Bottom line: The agreement clearly defines the who, where, and how of usage. List all named affiliates who can use the software, or use a generic definition covering present and future controlled entities. Ensure the territory is worldwide if possible (why limit yourself if you can avoid it).
And include any special arrangements (contractors, hosted environments, etc.). Eliminating ambiguity prevents SAP from later saying “you weren’t allowed to do that” and charging more. A well-crafted scope clause means you can adapt your SAP landscape to business changes without constantly renegotiating the license rights.
Termination and Renewal Rights
Traditional on-premise SAP licenses are perpetual – once purchased, you have the right to use the software indefinitely (subject to compliance). However, the support contracts and subscription licenses have renewal and termination conditions that need attention. Plus, even perpetual agreements can have termination clauses related to breach or other extraordinary events.
Termination of Perpetual License Agreements: Generally, you wouldn’t terminate a perpetual license for convenience – you own it. The contract might allow termination for breach (e.g., if you violate terms and don’t cure, SAP can terminate your license, which is extremely rare and a nuclear option). More relevant is the termination of the maintenance agreement. Maintenance (support) is typically an annual contract that auto-renews. SAP’s standard approach is that you can terminate support with a written notice (often 3 months before the renewal date).
If you terminate support, you can still legally run the software but lose access to support, updates, and fixes beyond that point. Be sure you understand the notice period in your contract to avoid auto-renewal. Some contracts might bury that in the SAP Partner or SAP Support terms. Always diary the renewal notice deadline and set reminders, even if you plan to keep support forever – having the option is leverage.
One restrictive policy to be aware of: SAP historically insisted on an “all-or-none” maintenance approach. This means you can’t typically drop maintenance on just a subset of your licenses – if you want to reduce maintenance, the default rule is to terminate it on your entire SAP estate with that contract. SAP does this to prevent customers from cherry-picking what to support.
However, as mentioned, you can negotiate exceptions. If you foresee not needing a particular component, try to carve it into a separate order form so its support can be ended independently. Or negotiate language that, at renewal, you can elect not to renew support on certain licenses. Without such clauses, SAP can expect to refuse partial cancellations.
Termination of Subscription Licenses: (While this playbook focuses on on-prem, some may have hybrid contracts.) If you have any SAP cloud subscriptions or time-limited S/4HANA private cloud deals, those have a fixed term (e.g., 3 or 5 years).
Early termination is usually not permitted except for cause. If you try to end a subscription early, the contract will penalize you for paying the remaining term’s fees. Essentially, you’re locked in for the term. Ensure this is clearly understood internally – there is no easy exit if you’re unhappy after 1 year into a 3-year cloud deal. You can negotiate a buy-out at best, but that’s at SAP’s discretion.
So choose your subscription commitments carefully. Also, those contracts often auto-renew for another term or year if you don’t give notice within a window (60-90 days before expiration is common). Missing that notice can lock you in unintentionally. Insist that SAP sends an official reminder 2-3 months before the notice deadline (some customers get this in the contract), although you should still track it yourself.
Renewal Flexibility: For maintenance and subscriptions, try to build flexibility when the term ends. For maintenance on perpetual licenses, renewal is usually year-to-year, and you can cancel any year with notice (or switch to third-party support). For cloud, you might negotiate that after the initial term, you can opt for a shorter renewal (e.g., annually instead of another full 3-year lock).
If you have a large subscription, maybe negotiate a volume reduction option at renewal, such as the ability to drop 10% of users without penalty if your needs change. SAP may not willingly allow a reduction in a renewed term, but it’s worth asking, especially if your usage has decreased.
Another angle is to avoid silent auto-renewal for long terms. You could negotiate that after the initial term, it converts to a month-to-month or quarterly renewal unless a new agreement is signed, though SAP seldom agrees to that for big contracts; it sometimes works for smaller cloud services. At a minimum, get clarity that the contract ends on a set date unless renewed in writing, so you’re not surprised.
Termination Assistance: One minor but important clause: if you choose to terminate (especially a cloud service), ensure there’s language about data retrieval and transition assistance. For example, if you end a cloud subscription, SAP should allow access to your data for a certain period or help export it. In on-prem, if you drop support, SAP isn’t obligated to do anything further, but for cloud, they often provide 30-60 days post-termination to extract data. Ensure that’s documented so you aren’t scrambling to get your data out.
Protecting Your Rights: CIOs should ensure that exit terms are well-understood and calendared. Nothing is worse than wanting to renegotiate a contract and finding out you missed the notice and got locked in. It’s advisable to have your procurement or IT asset management team maintain a contracts calendar.
Also, consider including a clause that SAP must negotiate in good faith a renewal, not that it guarantees pricing, but just that both sides will discuss renewal terms at least X days before term end. This can force an earlier engagement so you’re not last-minute.
In summary, plan your endgame at the start. Know under what conditions you can walk away or downscale, and what you must do procedurally to execute that. You avoid feeling trapped by having an exit strategy (even if you never use it). This leverage can psychologically even the playing field when it comes time to renegotiate – SAP knows you have the option (contractually and organizationally) to say no and change course if the deal doesn’t make sense anymore.
Negotiation Best Practices and Levers
Negotiating with SAP is more about managing future risk than getting a good price today.
Here are key levers and strategies CIOs and procurement leaders can use to improve their position:
- Leverage Independent Expertise: SAP licensing is complex, and SAP’s sales team naturally favors SAP’s interests. Engage independent licensing experts (e.g. Redress Compliance or similar firms) to advise on your contract. They can benchmark your deal, identify hidden risks, and suggest clauses (many of those covered above) that protect you. Independent advisors bring experience from many SAP negotiations – they know what concessions SAP has given other customers and can help you ask for the same. This is especially useful for indirect use issues, optimizing user license mix, and verifying that SAP’s proposals meet your needs without overselling. An expert on your side can often pay for themselves many times over in cost avoidance. Importantly, they provide an unbiased second opinion – something SAP won’t do for you.
- Maintain Competitive Tension: Even if you plan to stick with SAP, let it be known that you have options. CIOs can subtly remind SAP that third-party support exists, or that there are alternative solutions for certain modules (for example, if SAP’s terms are too inflexible, you might consider a different HR or CRM system). It will be more flexible if SAP believes it could lose maintenance revenue or additional module sales. As noted, some customers successfully negotiated maintenance rate reductions by signaling their willingness to switch to third-party support. You don’t need to antagonize the vendor, but a smart CIO keeps SAP aware that complacency could cost them your future business. This can translate into better discounts and contractual terms now.
- Avoid One-Sided Bundles: When SAP offers big bundles (e.g., a software suite for a single price), ensure you understand each component’s licensing. Sometimes bundles hide shelfware or future costs. It may be better to separate a bundle into line items with respective prices and metrics – this transparency ensures if you drop something, you know its value, or if usage grows, you know how it will be measured. Also, be wary of bundles that mix cloud and on-prem or mix different metrics, as they can complicate compliance tracking. Simplify where possible.
- Explicitly Document Everything: Any special deal you negotiate, get it in writing in the contract or order form. Verbal or email promises (e.g., “SAP will not audit you for indirect usage if you move to S/4HANA” or “we’ll allow you to swap licenses later”) are not enforceable. It must be part of the contract if something is important to you. Use an appendix or addendum if needed to capture unique terms. Ensure the language is unambiguous. For example, specify the credit amount or formula if negotiating a conversion credit (trading some licenses for others). If you expect a certain level of customer success assistance from SAP, write it in.
- Think Long Term (5–10+ Years): SAP systems tend to be long-lived. Negotiations should not just be about the immediate purchase but about the lifecycle. Discuss future projects – if you know you’ll consider S/4HANA in 3 years, maybe negotiate conversion rights now (like “the customer may exchange their ECC licenses for equivalent S/4HANA licenses at no additional license cost”, which SAP has offered in some cases for loyal customers). If you anticipate moving to the cloud, negotiate framework terms (e.g., the value of unused on-prem licenses can be credited to cloud subscriptions). You can embed some flexibility or roadmaps in the contract by anticipating change.
- Keep Some Budget in Hand: Don’t necessarily max out your budget in the initial deal. If SAP believes they’ve gotten every possible dollar now, you have less leverage later. It’s sometimes strategic to hold back a bit – you can say, “We can’t go further now, but maybe next year if things go well, we’ll invest in another module.” This keeps SAP interested in your success and maintaining a good relationship, which can translate to better treatment (like free training credits or a favorable amendment later). Always have a walk-away point and be willing to use it.
- Decouple Project Negotiations from Licensing (when possible): SAP often ties software sales with services or incentive programs. Try to negotiate software licenses separately on their own merits. Get separate quotes if you also need SAP implementation services or cloud infrastructure. This prevents confusion where discounts in one area are traded for concessions in another that might not be obvious. As a CIO, fight for clean and comprehensible terms.
- Use Timing to Your Advantage: SAP (like many vendors) has quarterly and annual targets. The end of Q4 (around December) is often when SAP is eager to close deals and might be more flexible on price and terms. If you have the luxury of timing, negotiate near SAP’s fiscal year-end to potentially get better discounts or contract terms. However, be cautious – time pressure can cut both ways, so ensure you thoroughly review the contract and do not rush into a bad deal just because of a deadline.
- Cite Precedents and Peers: When asking for a clause (say, an indirect use clause or a price cap), it helps to mention that “we understand other SAP customers have gotten this.” While specifics are usually confidential, SAP reps know what’s been approved in other negotiations. They may relent if they realize your requests are industry-standard or common (which many of the ones in this playbook are). If they claim “we never do that,” having external validation (via your independent expert or user community) that it has been done takes away that argument.
Ultimately, successful negotiation with SAP is about shifting risk away from you and keeping future costs predictable while enabling SAP to make the sale. Aim for a win-win: you get a fair deal with protections, and SAP gets a satisfied customer who will likely stay and grow.
A collaborative tone helps, but don’t shy away from asserting your non-negotiables (e.g., “We must have a cap on maintenance increases – it’s a board requirement for budget stability.”). Prepare thoroughly, involve your legal counsel to review wording, and use the leverage you have (your business is valuable to SAP). Negotiate like your organization’s future depends on it – because in terms of financial and operational impact, it does.
Actionable Recommendations for CIOs
In conclusion, here is a checklist of clear actions CIOs can take to protect their organizations in SAP license agreements:
- Inventory and Baseline Your Licenses: Establish a precise record of what SAP licenses you own, what each allows, and your current usage. Use SAP’s LAW tool or third-party tools to regularly measure named users and engine metrics. This baseline will inform all negotiations and compliance efforts.
- Identify Risks and Gaps: Analyze your SAP environment for indirect usage, shelfware, and any areas where usage might exceed entitlements. Proactively address these – for example, if a third-party system accesses SAP, decide whether to license it (digital access or named users) rather than wait for an audit. If 200 licenses are unused, flag them for potential reallocation or contract adjustment.
- Prioritize Key Contractual Protections: When reviewing or renegotiating contracts, focus on the clauses with the biggest financial impact over time. Caps on maintenance increases, clear indirect access terms, true-up rights, and shelfware flexibility should be on your list. Don’t let these slide in favor of a slightly better upfront discount – a 5% one-time discount is easily dwarfed by years of 5% annual maintenance hikes if uncapped.
- Engage Stakeholders Early: When planning an SAP contract change, involve your procurement, legal, and finance teams early. Ensure everyone understands the long-term implications of terms. For instance, legal should review the audit and liability clauses; finance should model the 5-year TCO with different maintenance growth scenarios. Bring this holistic perspective to the negotiation table.
- Use External Benchmarks: Leverage benchmarks from peer companies or advisors to set realistic expectations. Know what a typical SAP discount is in your industry/region, what true-up clauses others have obtained, etc. This prevents you from accepting subpar terms simply because SAP says so. The SAP user community and independent consultants can be valuable sources of such insight.
- Negotiate in Writing and Iterate: Don’t accept the first draft. Redline the SAP contract documents to insert the protections discussed. It may take multiple rounds – SAP might push back on some items. Be persistent and explain why it’s important. If you justify them, SAP will often concede on terms that don’t immediately affect their license revenue but protect you (like notice periods, some audit terms, transfer rights).
- Plan for Renewal and Beyond: When a new contract is signed, set up processes to manage it. Calendar the renewal and notice dates, schedule internal audits every 6-12 months, and monitor usage trends. If you anticipate needing more licenses, engage SAP well before you run out – perhaps you can negotiate an add-on with the same favorable terms. If you’re approaching an end-of-support date (2027 for ECC, for example), start exploring your options (upgrade, third-party support, etc.) at least 1-2 years ahead.
- Educate Your Team: Ensure your SAP admins and IT staff know the basics of your license rules (e.g., they shouldn’t create generic user accounts or let contractors use the system without informing license management). A compliance-aware culture prevents accidental violations. Also, procurement and project managers need to be informed that any new SAP functionality or integration needs a licensing check. Designing solutions correctly is easier than fixing them later under audit pressure.
- Regularly Review New SAP Offers: SAP’s licensing policies and offerings evolve (e.g., new licensing models, incentive programs). Keep abreast of announcements (perhaps via Gartner, user groups, or independent blogs). Sometimes SAP introduces something that could benefit you, for example, a limited-time program to convert unused on-prem licenses to cloud credits. Being aware allows you to take advantage of or negotiate at the right time.
- Stay Firm but Constructive: Finally, approach SAP as a long-term partnership – assert your requirements firmly, but strive for a constructive relationship. A collaborative negotiation (with both parties seeking solutions) often yields better results than an adversarial one. If SAP reps see you as knowledgeable and fair, willing to buy what you need but insistent on fair terms, they are more likely to escalate and approve your special requests. If something isn’t going your way, don’t be afraid to escalate within SAP’s management; larger customers, in particular, can leverage executive channels to get approvals on non-standard terms when justified.
By following these steps and the guidance in this playbook, CIOs can navigate SAP license agreements with far greater confidence. The goal is to avoid surprises—no surprise bills or restrictions—and ensure your SAP investment truly serves the business effectively over its full lifespan.
