Top 10 SAP On-Premise License Compliance Issues
SAP license compliance is a complex challenge that can carry multi-million-dollar risks for enterprises.
This article highlights the top 10 SAP on-premises license compliance issues, from indirect access and user misclassification to engine overuse and contract pitfalls, and advises CIOs/CTOs on avoiding costly audit surprises.
The key message: Proactive license management and understanding SAP’s rules are crucial to prevent compliance gaps before they impact your IT budget.
Indirect Access and Third-Party Usage
One of the most notorious SAP compliance issues is indirect access, when third-party systems or external users interact with SAP data without a direct SAP login.
Classic examples include customer or partner portals, e-commerce websites, or IoT devices that create or retrieve data from SAP.
Many companies have been caught off guard by this: SAP requires a license for any user or system that indirectly uses SAP. High-profile cases underscore the risk – in one legal dispute, SAP claimed over £50 million in fees from Diageo for unlicensed indirect use, and sought $600 million from AB InBev in another case.
These eye-popping numbers highlight how serious indirect access compliance can be. SAP’s newer “Digital Access” model offers a way to license this by counting documents (e.g., number of sales orders, invoices) instead of requiring named-user licenses for every external user.
Still, many on-premise SAP customers haven’t fully assessed their indirect usage. Ignoring indirect access is dangerous – an audit could reveal that integrations like CRM systems or websites have created SAP transactions without proper licensing.
To stay safe, companies should inventory all interfaces in SAP and decide whether to cover them via named user licenses or adopt a document-based Digital Access license.
The cost can be significant (for example, 200,000 unlicensed sales orders via a webshop might equate to tens of thousands of dollars in fees), so it’s better to address it proactively than to face a surprise bill.
Misclassified User License Types
Another top compliance issue is misclassification of SAP users. SAP on-prem licenses come in tiers (e.g., Professional, Limited Professional, Employee Self-Service, Developer, etc.), each with different usage rights and price points.
A common pitfall is assigning users the wrong license type, accidentally or in an attempt to save costs.
For instance, a power user performing broad transactions should have a Professional User license. Still, an audit will flag them as under-licensed if they were incorrectly given a cheaper “Limited” license.
Conversely, some organizations err by not specifying a license type for certain system users—those users then default to Professional in SAP’s audit tools, potentially inflating compliance gaps.
The impact of misclassification can be severe financially. A Professional license often costs several thousand dollars (one-time, plus ~22% yearly support), whereas a Limited or Employee license might be a fraction of that.
Multiply that difference across dozens or hundreds of users, and you see the exposure.
Below is a simplified comparison of common on-premise SAP user licenses and their scope:
| User License Type | Typical Cost (One-Time + Annual Support) | Intended Usage Scope | Compliance Risk if Misused |
|---|---|---|---|
| Professional User | ~$3,000–$4,000 + 22%/yr support | Full use of all SAP modules and functions | Misclassifying a heavy user as lower type causes under-licensing (audit shortfall). |
| Limited Professional | ~$1,500–$2,000 + 22%/yr support | Restricted scope (specific modules/tasks) | If user performs broader tasks than allowed, they actually require a Professional license. |
| Employee Self-Service | ~$500–$1,000 + 22%/yr support | Self-service only (e.g. HR data, time entry) | Using for operational tasks (beyond self-service) violates license terms – needs upgrade to higher license. |
| Developer User | ~$1,000+ + 22%/yr support (often add-on) | SAP development and configuration activities (non-production use) | If a developer also executes business transactions in production, a Professional license is required in addition to developer license. |
Preventing misclassification requires diligent user management. Based on job duties, every SAP user account should be assigned the correct license type.
It’s wise to map job roles to appropriate license categories (e.g., a finance clerk = Limited Pro, a department manager approving requests = Employee Self-Service, etc.) and review these assignments regularly.
Additionally, monitor “license drift.” Over time, a user’s role may change, and they might need a higher license, or vice versa. Periodic internal audits help catch users who had the wrong license before SAP.
In summary, ensure that no user is left as “unclassified” and that the license types match what each person does in SAP.
Inactive and Duplicate User Accounts
SAP’s named-user licensing counts every individual user ID that exists and is not explicitly retired. This means inactive accounts (for former employees or consultants who left) and duplicate accounts (the same person having two IDs) can needlessly drive up your license count and compliance risk.
It’s not uncommon in large SAP environments to find 10–15% of user accounts are dormant or redundant, for example, an employee who left a year ago but whose SAP login remains active, or a single employee who has separate accounts in multiple systems (like ECC and BW) that weren’t linked.
In an audit, SAP’s tools will count each account as a separate user unless you have cleaned or properly consolidated them using SAP’s License Administration Workbench (LAW).
The compliance issue here is that you might appear to exceed your purchased license quantities simply because of poor housekeeping.
The financial hit can be significant: imagine paying maintenance on 100 extra “ghost” users that aren’t needed, or being told you need to purchase additional licenses for accounts not in use. The solution is straightforward: regular user cleanup.
Integrate SAP user management with HR offboarding so that when an employee exits, their account is promptly deactivated or deleted.
Schedule routine checks (at least quarterly) to remove or lock any user IDs that haven’t been used in 90 days. Also, LAW can detect duplicate users across systems (e.g., if Jane Doe has accounts in both CRM and ERP, ensure SAP knows it’s one person, not two).
Keeping the user list lean and accurate reduces compliance exposure and saves on license costs.
Engine License Overuse and Package Metrics
Beyond user licenses, SAP also sells packages or engine licenses for specific functionalities measured by metrics like transactions, revenue, number of employees, or database size.
Examples include SAP Payroll (licensed by employee count), SAP Warehouse Management (by number of warehouse bins or lines), or SAP HANA database runtime (by gigabytes of memory).
A major compliance issue arises when organizations exceed the licensed metrics for these engines.
For instance, if your contract permits up to 1,000 employees on SAP Payroll and your HR system now has 1,100 active employees, you’re 100 over the limit – an audit will flag this under-licensing.
Similarly, if you licensed a CRM module for up to 1 million business partner records and the business grew beyond that, or a Sales and Distribution engine by annual order value and surpassed that threshold, you are out of compliance.
The cost impact here is an immediate “true-up” requirement—you’d need to purchase the additional capacity (often at list price) and possibly pay back maintenance for the period of overuse.
For example, 100 extra Payroll employees might require buying 100 more user licenses or an engine expansion, which could cost tens of thousands of dollars plus recurring support fees. To avoid nasty surprises, companies should continuously monitor engine usage metrics.
Many SAP systems provide usage reports for engines (e.g., number of employee master records, number of material transactions, etc.).
Assign an owner to each metric (e.g,. HR owns the employee count, finance owns the revenue metric) and review them against your license entitlements at least yearly.
If you see growth nearing a licensed limit, you have two choices: optimize usage (if possible) or proactively negotiate an additional license before an audit forces you to.
Staying ahead of engine usage trends ensures you’re not unknowingly running at 110% of your licensed capacity.
Using Development/Test Licenses in Production
SAP provides lower-cost licenses and systems for non-production environments, such as developer user licenses (for programmers) and test or training systems.
These are great for their intended purpose, but a serious compliance issue occurs when they are misused in production. One scenario is a developer license misuse: A developer license allows users to configure and write code in development or QA systems.
It is not supposed to be used to perform regular business operations. Suppose a person with only a Developer user license starts executing transactions in the production system (say, entering orders to test something or fixing data).
In that case, they technically require a full Professional license for that activity. Another scenario is when customers use specially-licensed “test” or “evaluation” software in production.
SAP sometimes offers temporary or trial licenses for non-production use (e.g., an IDES system for training or demo).
If such a system is inadvertently (or intentionally) used to run production workloads or to serve extra users without proper licenses, it’s a compliance violation.
Similarly, using a training client or sandbox for additional users without licenses as a live system is prohibited. The principle is that all use of SAP, in any environment, ultimately needs to be covered by an appropriate license.
To stay compliant, ensure that: 1) all developers who occasionally need to work in production have a business user license as well, if required; 2) all non-production systems are correctly classified and only accessible to properly licensed named users; and 3) no “test” named users are being used by real individuals to bypass licensing.
Auditors will scrutinize whether any users classified as “Test” in your user measurement are active in production—a red flag that can lead to back-charges.
The best practice is to keep non-prod usage strictly separate and monitored, and when in doubt, license a user’s highest level of access across environments.
Contract Ambiguities and Organizational Changes
Sometimes, the biggest license compliance issues arise not from technical usage but from contractual misunderstandings. SAP agreements are intricate, and older contracts may contain opaque clauses that can trip up customers.
For example, a contract might define “Use” to include any third-party access, effectively requiring you to notify or license indirect use (this was the crux of the Diageo case – the contract language allowed SAP to charge for Salesforce-to-SAP connections).
You might inadvertently breach such clauses if you aren’t aware of them.
Unclear contract terms around things like “multiplexing” (using a middleware or shared login to funnel many users, which SAP disallows without proper licensing) or definitions of user types can also lead to compliance issues.
IT leaders and license managers must read the SAP software use rights document and specific contract terms.
Many compliance issues arise simply because the customer didn’t fully understand a restriction – for instance, thinking a certain type of partner or affiliate use was permitted when it was not.
Another area to watch is organizational changes such as mergers, acquisitions, or divestitures. SAP licenses are typically tied to a legal entity or a defined scope of business.
If your company acquires another company and allows those new employees to use your SAP system, are they covered under your licenses?
Often, standard named-user licenses extend to affiliates under the same corporate group, but the contract may require that those affiliates be majority-owned or listed.
Conversely, if you spin off a division, can they continue to use the SAP environment? Failing to sort out licensing during M&A can leave whole groups of users operating without valid licenses.
There’s also a geographical aspect: some contracts might be limited to certain regions or subsidiaries. Using the system outside the agreed scope (like a global subsidiary that wasn’t included originally) could technically be out of compliance until you add them to the contract.
The key advice here is to update your SAP agreements whenever your business changes. Seek amendments or riders from SAP to cover new entities or usage patterns.
Also, regularly review contract terms with your legal or SAM team so you’re aware of any “gotchas” (such as needing to inform SAP of indirect use or restrictions on virtualization).
By preemptively addressing contract ambiguities and aligning your license scope with your current business, you avoid nasty surprises where SAP says, “You broke the contract.” In other words, don’t assume – verify your rights in writing.
Shelfware and Unused License Risk
Not all SAP compliance issues involve doing too much—sometimes, it’s about owning more than you use. Shelfware refers to licenses you purchased but aren’t utilizing (sitting “on the shelf”).
At first glance, having extra licenses isn’t a compliance problem (if anything, it means you’re over-licensed). However, shelfware can become an issue in two ways.
First, companies often continue paying hefty annual maintenance (support fees) on these unused licenses, which wastes budget.
CIOs might try to cut costs by terminating maintenance on unused components or reducing license counts, but SAP’s policies make this difficult.
Typically, SAP does not allow dropping a subset of licenses from your maintenance agreement unless you discontinue that software.
For example, if you bought 1000 user licenses but only use 800, you can’t simply stop paying support on the 200 excess without SAP’s approval; doing so unilaterally could put you out of compliance with your support contract.
Second, organizations that attempt to “eliminate” shelfware by repurposing it incorrectly might violate licensing rules.
An example would be using a spare engine license for a different project or subsidiary that was not originally licensed. The safest approach to shelfware is to engage SAP or an authorized reseller to see if you can optimize those unused licenses.
Sometimes SAP may allow a one-time license swap or credit (for instance, trading shelfware licenses’ value towards a new product, or converting on-prem licenses to cloud subscriptions via programs like SAP Cloud Extension).
From a compliance perspective, remember that just because you have extra licenses doesn’t give carte blanche to expand usage beyond contract terms. Always ensure any license redeployment aligns with contract definitions.
In summary, while unused licenses aren’t a compliance violation, mishandling them can lead to trouble. From a cost governance view, shelfware is money wasted, so it’s an issue that CIOs should address through careful license portfolio management.
Recommendations
In large SAP environments, prevention is far better (and cheaper) than a cure.
CIOs and CTOs should take the following actions to mitigate SAP license compliance risks:
- Conduct regular internal audits of SAP licensing (at least annually, ideally quarterly). To catch issues early, simulate an SAP audit using tools like USMM and LAW.
- Maintain a detailed license inventory and usage log. Track all SAP entitlements you own and map them against current usage (users and engines). This makes it easy to spot under- or over-utilization.
- Enforce strict user management processes. Immediately deactivate accounts of departed staff and eliminate duplicate user IDs. Tie SAP user provisioning/de-provisioning to HR events and review user lists periodically.
- Right-size user licenses continuously. Implement a policy to review users’ roles vs. their assigned license type. Downgrade licenses for users who don’t need high-level access and upgrade those who do, before an audit compels it.
- Monitor indirect access closely. Document all third-party systems interfacing with SAP. Decide on an indirect licensing strategy (named users vs. SAP Digital Access) and use SAP’s estimation tools to quantify indirect document usage regularly.
- Keep tabs on engine metrics. Assign owners to each SAP package license metric (financial, HR, etc.) and check actual usage against licensed limits. If you’re approaching a threshold, plan a true-up or optimization in advance.
- Educate and involve stakeholders. Ensure project managers, integration architects, and business units know licensing impacts. Include a licensing checkpoint in the plan for any new SAP integration or major user addition.
- Review contracts and stay updated. Have your team periodically read through SAP license agreements, use-rights documents, and any new amendments. If unclear, seek clarification from SAP or a licensing advisor. This prevents misunderstandings of obligations.
- Plan for organizational changes. If a merger, acquisition, or divestiture is on the horizon, proactively discuss how licenses will be handled with SAP. Obtain contract addendums to cover new users or carve-outs for divested units to remain compliant.
- Consider professional tools or services. For very large SAP landscapes, dedicated license management software (e.g., Snow, Flexera, VOQUZ) or consulting experts can help continuously analyze license use and optimize your compliance position.
By following these steps, enterprises can dramatically reduce the risk of an SAP audit becoming a financial nightmare. Staying disciplined and informed is key; it’s much easier to handle compliance in-house than under the pressure of SAP’s auditors.
FAQ
Q1: How often does SAP audit its customers, and what triggers an audit?
A1: SAP typically has the right to audit customers annually (as per most contracts), though in practice, many large enterprises get audited every 2-3 years. Triggers can include significant increases in usage, new implementations, M&A activities, or even random selection. Major contract changes or approaching the end of a license agreement can also prompt an audit. Essentially, if SAP’s data or your communication suggests you might be out of compliance (for example, you suddenly added a lot of users or a new interface), an audit could be initiated.
Q2: What is the best way to prepare for an SAP license audit?
A2: Preparation should be an ongoing process. Maintain an accurate inventory of all licenses and current usage. Perform “mock audits” internally using SAP’s measurement tools (USMM and LAW) to see exactly what SAP would find. Address any shortfalls by reallocating licenses or purchasing additional ones before the official audit. It’s also wise to assemble a cross-functional team (IT, SAM, finance, legal) that will manage audit communications and ensure data is pulled correctly for SAP when the time comes.
Q3: What exactly counts as indirect access, and how can we license it properly?
A3: Indirect access means any access to SAP functionality or data that doesn’t occur through a direct SAP GUI/login by a named user. Examples include external applications (like a web portal, mobile app, or third-party software) that query or update SAP data via interfaces, or a single licensed user funneling data for many others. To license it, you have two main options: Named user licenses for each external user (sometimes impractical for large populations like customers), or SAP’s Digital Access (Document) license, which covers a certain number of document transactions (sales orders, etc.) generated indirectly. Many customers evaluate the volume of documents created by integrations to decide if the digital document model is cost-effective compared to naming every external user. A combination approach is often used, and it should be negotiated with SAP as part of your contract.
Q4: How can we determine if our users are correctly classified in the right license type?
A4: Start by mapping each user’s job role and transactions to the appropriate license category definition (in SAP’s Software Use Rights document). You can also analyze usage data: SAP’s user statistics (via transaction ST03N or audit logs) can show what transactions each user executes. If a user with an “ESS/Employee” license creates purchase orders (a heavy transaction), that’s a red flag. Conversely, if someone has a Professional license but only ever displays reports, they might be a candidate to downgrade to a cheaper license. Regularly review these mappings and consider using tools that automatically suggest optimal license types based on actual usage. Engaging with SAP or a licensing expert to run an inspection (without formally auditing) can also help validate your classifications.
Q5: What should we do with unused SAP licenses – can they reduce our costs?
A5: Unused licenses (shelfware), unfortunately, can’t simply be “returned” for a refund, and if you’re paying maintenance on them, you’re entitled to support, but not getting value from it. You generally cannot drop maintenance for a partial set of licenses without SAP’s agreement (they often have all-or-nothing policies on a product). However, you can raise the issue during contract negotiations or annual true-ups. For example, SAP might allow you to reallocate that value by converting older shelfware into credit for new licenses or cloud subscriptions. Another approach is to plan during a S/4HANA migration or big contract renewal: that’s a prime time to negotiate on shelfware (maybe trading it in as part of an enterprise agreement). In the meantime, you should certainly stop assigning new users to expensive license types if cheaper ones are available – utilize the licenses you have fully to avoid buying more unnecessarily.
Q6: Are SAP S/4HANA license compliance issues different from SAP ECC (older ERP)?
A6: The core principles are the same, since S/4HANA on-premise still uses named user and package licenses. However, S/4HANA introduced some new user categories (e.g., “Functional” vs. “Productivity” users) and a new metric framework called FUE (Full Usage Equivalent) for bundling user types. Compliance issues like indirect access, misclassification, and engine overuse still occur in S/4HANA, just under possibly new names. Additionally, when transitioning from ECC to S/4HANA, companies must be careful to convert licenses properly – unconverted legacy users or unused components might cause compliance gaps if not mapped to the new scheme. In short, S/4HANA doesn’t eliminate compliance concerns; you still need vigilant license management. The good news is that SAP has provided some audit tools updates for S/4, and the Digital Access model also applies to it. Ensure you read the S/4HANA licensing handbook to understand any compliance-related changes.
Q7: What are some signs that we might be out of compliance (before an official audit)?
A7: There are a few warning signs: If your SAP user count in the system is approaching or exceeding the number of licenses you purchased, that’s obvious. Also, you might have latent shortfalls if your business has grown significantly (more employees, more transactions) since your last true-up without a corresponding license increase. Technical signs include: many users showing as “Professional (Unclassified)” in SAP’s user measurement report (LAW) – this indicates missing classifications which SAP will count at highest cost; any module usage metric that’s grown beyond initial estimates (e.g., sudden increase in sales order volume if orders license you). Another red flag is if you’ve integrated new third-party applications to SAP (for example, a new e-commerce front end) but haven’t revisited licensing – indirect access could be quietly accumulating. Essentially, if your SAP landscape has expanded or changed substantially since your last license review, there’s a risk your compliance position has drifted and needs a check.
Q8: How can third-party license management tools help with SAP compliance?
A8: Third-party SAP license management tools (such as Snow Optimizer for SAP, Flexera’s SAP module, VOQUZ Lucent, etc.) can greatly enhance visibility. They connect to your SAP systems and continuously analyze user activity, authorization roles, and consumption metrics. These tools often recommend optimizing license assignments (for example, identifying 50 users who could be downgraded to a cheaper license). They will simulate audit results at the push of a button. They can also track indirect usage by examining interface logs or document counts. Essentially, they automate much of the heavy lifting of internal audits and produce reports highlighting real-time compliance risks. For a CIO/CTO, you can catch and fix issues on the fly rather than scrambling once a year. While these tools come with a cost, organizations with very large or complex SAP environments often find that the savings from license optimization and avoided audit penalties far exceed the tool cost. They supplement (not a replacement for) good governance but provide a safety net and data-driven insights to proactively manage SAP licenses.
Q9: What should we do if SAP finds us non-compliant during an audit?
A9: First, don’t panic or become adversarial; treat it as a business negotiation. SAP will typically present a report showing the shortfalls (e.g., X number of missing Professional users or engine overages). You should carefully validate those findings – sometimes errors or misunderstandings occur (for instance, duplicate users counted or some users could be reclassified to reduce the gap). Engage your internal team or a licensing expert to verify SAP’s numbers. Once the compliance gap is agreed upon, the discussion turns to remediation. This usually means purchasing the required licenses and paying maintenance backdated when the usage exceeded entitlement. This is where negotiation is key: you might negotiate a discount, or argue for some credit if you plan to expand SAP usage anyway. Ensure that any settlement or purchase to resolve the audit also addresses the root cause (e.g., if indirect access was the issue, maybe negotiate a digital access package moving forward). Finally, use the experience as a lesson – implement stronger internal controls so it doesn’t repeat. Remember that maintaining a constructive relationship with SAP while firmly advocating for your company’s interests is the best approach in an audit resolution.
Q10: Are there any license compliance issues unique to global SAP deployments?
A10: In global deployments (multi-country, multi-subsidiary SAP systems), legal entity and geographic restrictions are one unique challenge. You must ensure your license agreements cover all the entities using the system. For example, if only your North American subsidiary was originally licensed and now your European branch is on the same SAP system, you might need a contract extension. Language or local regulatory requirements usually aren’t a direct license issue, but data residency could require separate instances (with licensing implications). Another issue is ensuring global user consolidation – the LAW tool can consolidate user counts across systems. Still, you need to correctly map users with accounts in different regional SAP instances to avoid double-counting. Time zone and system copy practices (like creating a clone of production for testing in another region) also must be managed – that clone should be flagged as a test system so it doesn’t count as a second production in the audit. Finally, global organizations often have interfacing between regional systems, which counts as indirect use if not all parts are under one corporate agreement. The bottom line is to treat a global SAP landscape as one big license scope puzzle – get clarity from SAP on how your contract defines “enterprise” or “site” and ensure.
Read about our SAP License Optimization Service.
