Key Takeaways
- SAP package licence optimisation appears straightforward — identify unused packages and remove them to reduce costs. In practice, it is one of the highest-risk licensing activities enterprises undertake.
- Six specific risks can convert optimisation into compliance exposure — from over-removal of packages still in use to engine licence consumption traps that trigger back-licence claims years later.
- Audit discovery risk is structural — SAP frequently initiates enhanced audits after observing package removals, using audit rights to challenge the basis for those removals and recover previously unclaimed licensing fees.
- Mitigation requires independent measurement, comprehensive integration mapping, and detailed documentation — before any package is removed from your licence portfolio.
SAP package licence optimisation looks straightforward on paper. You conduct a usage analysis, identify packages your organisation is not consuming, remove them from your licence agreement, and capture immediate cost savings. In practice, organisations that follow this approach frequently discover during their next SAP audit that the packages they removed were still in use through channels they had not identified. The result is a non-compliance finding that SAP converts into a back-licence claim covering months or years of estimated usage.
SAP package licence optimisation risks are not theoretical. They are embedded in the structure of how SAP measures usage, how third-party integrations consume package functionality, and how SAP's audit procedures challenge the documentation supporting optimisation decisions. This article covers the six primary risks every enterprise faces when optimising package licences, the mechanisms through which those risks materialise, and the specific mitigation strategies that have proven effective in defending against audit challenge.
For context on the broader SAP package licence optimisation landscape, see our complete enterprise guide to SAP package licence optimisation. This article focuses exclusively on risk identification and mitigation.
SAP Package Licence Optimisation Series
Risk #1: Over-Removal — Packages in Use Through Indirect Access
The Over-Removal Trap
The most common SAP package optimisation failure occurs when organisations remove packages they believe are unused, only to discover during audit that the packages were actively in use through indirect access channels. This risk is particularly acute in enterprises with complex integration architectures, extensive automation, and third-party system dependencies.
How this materialises: Your usage analysis tool (commonly USMM or SAP Solution Manager) measures direct SAP user access to package functionality. It does not reliably measure access through middleware platforms, RPA automation, API-driven integrations, or third-party applications that call SAP modules indirectly. A package removal decision based on "zero direct users" may still leave the package actively consumed by automated processes, external systems, or background jobs that the original usage analysis did not identify.
A manufacturing enterprise removed SAP Production Planning (PP) package functionality after USMM measurement showed no direct users over a 6-month analysis window. Six months later, an SAP audit uncovered that their ERP automation system made automated API calls to PP module functions for production schedule synchronisation. The "unused" package was generating transaction volume continuously. SAP claimed 18 months of unlicensed usage and issued a back-licence demand of €420,000.
Mitigation strategy: Before removing any package, conduct a comprehensive third-party integration audit in addition to direct usage measurement. Map every external system, API integration, automation workflow, and middleware platform that connects to your SAP environment. For each integration, determine which SAP modules and packages it consumes. This step requires technical involvement — it cannot be completed through SAP's standard measurement tools alone. Document the integration mapping in detail and retain it for audit defence. Only remove packages after confirming that no integration depends on their functionality.
Risk #2: Engine Licence Consumption Traps
SAP Engines and Back-Licence Claims
SAP engine licences — SAP Process Integration (PI), SAP HANA, SAP Analytics Cloud, SAP Commerce Cloud, and others — operate on a different licensing model than traditional user-based packages. Engines are licensed based on consumption metrics: transaction volume, data volume stored, number of transactions processed, or API calls executed. The contract typically specifies a volume commitment. If actual consumption exceeds the committed volume, SAP generates an overage claim.
The trap: Enterprises frequently fail to measure actual engine consumption accurately during optimisation activities. They contract for a given transaction volume based on estimates made at contract signature, deploy the system, and never verify whether actual consumption is within the contracted volume. Growth in API usage, expansion of integration scope, or increases in data volume processed by engines all generate consumption growth. When SAP's STAR tool or similar measurement mechanism detects that actual consumption exceeds the contract, the result is a back-licence claim for the entire period of overage — potentially spanning 24–36 months.
A global financial services organisation contracted for 500,000 monthly SAP PI transactions. Two years later, an SAP audit revealed that actual monthly transaction volume had grown to 1.2 million — significantly exceeding the contract. SAP calculated the overage across 24 months and issued a back-licence demand for additional PI licensing covering the period of excess consumption. The financial impact: €680,000 in back-licence fees.
Mitigation strategy: Establish independent measurement of engine consumption immediately after engine deployment and conduct measurement on a quarterly basis. Use SAP's measurement tools (STAR, USMM) plus independent verification tools where available. Compare actual consumption to contracted volume quarterly and flag consumption drift toward the contract ceiling. As consumption approaches 85% of contracted volume, initiate engagement with SAP account management to adjust the contract before an overage condition exists. For PI, Analytics Cloud, and other measurable engines, maintain detailed consumption logs that demonstrate your measurement rigor in case of audit. When consumption has clearly grown, adjust the contract proactively — it is significantly more defensible than having SAP discover the overage during an audit.
Risk #3: Indirect Access Through Packages and API Consumption
Packages Consumed by Non-SAP Systems
SAP's indirect access definition creates a structural risk in package optimisation: any system that reads or modifies SAP data — whether it is a third-party application, an external cloud platform, a partner system, or a customer-facing portal — can be interpreted as consuming the SAP packages those systems call. The breadth of this definition means that package optimisation based on user counts may significantly underestimate true package consumption.
Specific exposure vectors: API gateways that expose SAP data to external partners; web services that allow third-party applications to query package data; master data management platforms that synchronise data with SAP; eCommerce systems that pull inventory or pricing data from SAP packages; customer portals that provide visibility into SAP business documents; and integration platforms that transform SAP data for consumption by downstream systems. If any of these systems are active, and they consume functionality housed in SAP packages you have removed, you have created a non-compliance condition.
A retail enterprise removed a custom logistics package from their licence portfolio after determining that their logistics team had been eliminated in a 2023 restructuring. Six months later, during audit, SAP identified that the enterprise's warehouse management system — deployed in 12 distribution centres — was making continuous API calls to that same logistics package for shipment tracking and inventory coordination. The removal had converted the enterprise into a non-compliant state. SAP issued a back-licence claim covering the entire period since package removal, which spanned 8 months and amounted to €280,000.
Mitigation strategy: Expand your pre-removal audit beyond direct user measurement to include all integration points where external systems consume package functionality. This requires detailed technical review of your integration architecture and explicit sign-off from technical teams responsible for API gateways, data synchronisation, and third-party system connections. For every package removal, require integration architects to explicitly confirm that no external system will be affected. Document this confirmation in writing. Additionally, implement a monitoring mechanism that alerts your team if external systems attempt to access package functionality after the package has been removed — this serves both as a safety check and as evidence of your diligence if audit ever occurs.
Risk #4: FUE Calculation Inflation and USMM Measurement Error
How SAP Overcounts Usage and Inflates Licence Requirement
Full Use Equivalent (FUE) calculations are central to SAP's licensing model for certain packages and user types. FUE is a normalized metric that aggregates different usage patterns into a single comparable unit. The problem is that SAP's calculation methodology, as implemented in USMM, systematically overestimates FUE requirements because it counts time-series usage data aggregated at the module level rather than the functional transaction level. This causes SAP to claim that users require higher user-type classifications than their actual functional usage justifies.
How inflation occurs: USMM records every transaction executed in an SAP module. If a user executes 15 transactions in MM (Materials Management) and 12 transactions in MM within a single month, USMM aggregates this as "27 transactions in a module where the threshold for Professional User classification is X transactions," even if the user is performing a small subset of truly professional functions. The USMM calculation does not distinguish between one-off queries, read-only transactions, and truly complex modifications. The result is systematic over-classification of user types.
In one defence engagement, SAP's USMM measurement claimed that 340 users required Professional User classification. Our independent analysis — using the same USMM data but aggregating at the functional transaction level rather than the module level — demonstrated that 260 of those users performed limited, repetitive transactions that would qualify them for Limited Professional or Employee user status. The methodology difference generated a claimed overage equivalent to 80 unnecessary Professional User licences. SAP's original audit position would have cost the enterprise €1.2M in reclassification fees.
Mitigation strategy: Before accepting any SAP audit finding that reclassifies users or recalculates FUE requirements, engage independent audit defence counsel to review the USMM data and methodology used by SAP. The data is defensible — USMM correctly measures transaction volume. The interpretation is where error typically occurs. Request granular USMM logs and conduct your own functional analysis. Challenge SAP's FUE calculation explicitly, particularly if it results in user-type reclassification. Do not treat USMM output as auditor-proof truth — it is a measurement tool that requires interpretation, and that interpretation is frequently disputable.
Risk #5: Migration Risk — Package Reassignment During ECC to S/4HANA Conversion
Lost Perpetual Rights and Forced Transitions
When organisations migrate from ECC to S/4HANA, their SAP contracts frequently contain migration clauses that establish rules for how existing packages and rights transfer to the new environment. Some migration clauses include language that removes perpetual licence rights to ECC packages and requires subscription-based licensing for equivalent S/4HANA functionality. Other clauses prevent running legacy ECC systems in parallel during migration, eliminating the organisation's flexibility to validate the new environment before decommissioning the old one.
The specific risk: If your organisation holds perpetual licence rights to specific ECC packages, those rights have commercial value — typically 10–15% of the original licence cost annually in third-party support contexts. A migration clause that converts perpetual rights to subscription rights surrenders this value permanently. Similarly, if a migration clause prohibits running ECC and S/4HANA in parallel, your organisation loses the option to pilot the new system against live data before committing to cutover. This elimination of parallel running increases migration risk, extends implementation timelines, and reduces your negotiating power with SAP.
A manufacturing organisation owned perpetual ECC licences for multiple packages valued at approximately €200,000 annually in third-party support arrangements. When they initiated S/4HANA migration, SAP's migration addendum converted all perpetual ECC rights to 3-year subscription arrangements for S/4HANA equivalents. The contract prevented running ECC and S/4HANA simultaneously. The organisation lost both the perpetual asset value and the ability to run systems in parallel. The migration forced an accelerated cutover timeline that increased implementation costs by approximately €500,000.
Mitigation strategy: Any S/4HANA migration agreement requires independent review by SAP migration licensing counsel before execution. The review must specifically address: (1) whether existing perpetual ECC package rights are preserved or converted to subscription; (2) whether the contract permits parallel running of ECC and S/4HANA systems during migration; (3) what specific conditions trigger mandatory ECC decommissioning; and (4) whether any package functionality that currently justifies perpetual licensing will be sunset after migration. Document the commercial value of your existing perpetual rights and ensure the migration agreement preserves or explicitly compensates for this value. Parallel running capability is worth negotiating for — do not surrender it without understanding the operational cost of accelerated cutover timelines.
Risk #6: Audit Trigger Risk — Audit Enhancement After Package Removal
Why Package Optimisation Activates SAP Audit Escalation
SAP's audit methodology includes a specific escalation trigger: when SAP observes that an organisation has removed packages from their licence portfolio, audit intensity frequently increases. This is not coincidence. SAP's view is that if an organisation is actively managing their licence position, they are a higher-risk audit candidate — they have sophisticated licensing knowledge and may be operating at the margins of their contractual rights. The response is enhanced audit scrutiny, expanded data requests, and more aggressive measurement and challenge of the organisation's remaining licence position.
How audit escalation operates: After a package removal, SAP account management flags the account as "high scrutiny." The next scheduled audit becomes an "enhanced audit" rather than a standard review. Enhanced audits request system access to production environments, demand detailed documentation of integration architecture, require explanation of how remaining packages are consumed, and initiate more aggressive FUE calculations and user-type reclassification analysis. The result is frequently a combination finding: "your documented removal was appropriate, but our enhanced audit identified these other issues in your remaining licence position" — followed by substantial claims.
An enterprise successfully negotiated a package removal that resulted in €220,000 in annual savings. Three months later, SAP initiated an enhanced audit triggered by the removal. While confirming that the package removal was appropriate, the enhanced audit generated findings in other areas — FUE calculation challenges, user-type reclassification claims, and indirect access claims — that totalled €1.8M. The package optimisation that was intended to reduce costs ultimately increased exposure.
Mitigation strategy: Before undertaking any package licence optimisation, engage SAP audit defence counsel to conduct a comprehensive pre-audit review. The review should identify all potential audit exposure in your remaining licence position so you understand the audit risk associated with the optimisation activity. If audit defence counsel identifies substantial exposure elsewhere, the optimisation may increase overall risk rather than reduce it. Additionally, when you do proceed with optimisation, document the decision process in detail: include usage analysis, integration mapping, functional review, and explicit sign-off from technical teams. This documentation becomes your audit defence if SAP challenges the removal. Finally, consider staging optimisation activities — remove packages in smaller batches rather than making large changes at once. Smaller changes trigger less intense audit escalation than wholesale portfolio restructuring.
Critical: Documentation is Your Audit Defence
If you remove packages without documented evidence of your decision process, you have no audit defence. SAP will challenge the removal and demand back-licensing. Every package removal must be supported by: (1) usage measurement output, (2) integration mapping confirming no external systems depend on the package, (3) technical sign-off from stakeholders responsible for relevant systems, and (4) explicit confirmation from SAP Licensing Experts or similar counsel that the removal is defensible. Without this documentation, do not proceed with removal.
Comprehensive Mitigation Framework
The six risks above are not independent. They interact. Package removals trigger audit escalation (Risk #6). Escalation leads to FUE recalculation challenges (Risk #4). Audit review discovers indirect access consumption the original analysis missed (Risk #3). The mitigation approach must therefore address risk holistically, not individually.
| Risk | Primary Cause | Detection Mechanism | Mitigation Action |
|---|---|---|---|
| Over-Removal (Indirect Access) | Packages in use through integration channels not measured by USMM | Audit discovery of API consumption or automated process access | Comprehensive integration mapping; third-party system audit; technical sign-off |
| Engine Licence Trap | Consumption grows beyond contract; not measured or monitored | SAP audit measurement; STAR tool output exceeds contract | Quarterly independent consumption measurement; contract adjustment before overage |
| Indirect Access (API/Portal) | External systems consume package functionality; not acknowledged | Audit discovery of API calls or portal access logs | Integration architect sign-off; monitoring of external API consumption |
| FUE Inflation | USMM overestimates FUE and user classification requirements | Audit finding of user-type reclassification | Independent FUE analysis; challenge USMM methodology; engage audit counsel |
| Migration Risk | Migration clause removes perpetual rights or parallel running | Contract signature; perpetual asset surrendered | Pre-signature migration audit; preserve perpetual rights; negotiate parallel running |
| Audit Escalation | Package removal triggers enhanced audit; discovers other exposure | Audit scope expansion after removal | Pre-optimisation audit defence review; staged removals; comprehensive documentation |
Best Practices for Safe Package Optimisation
Given the risk environment, what does defensible package licence optimisation look like? We recommend a staged, documented, counsel-reviewed approach:
Six-Step Safe Optimisation Process
Step 1 — Audit Defence Pre-Review: Before analysing any package for removal, engage SAP audit defence counsel to review your broader licence position for potential audit exposure. If significant exposure exists elsewhere, optimisation may increase overall risk. If your position is defensible, proceed.
Step 2 — Comprehensive Usage Analysis: Use USMM plus SAP Solution Manager to measure direct usage of the package. Run analysis over a minimum 6-month period. Do not rely on single-month data.
Step 3 — Integration Mapping: Conduct detailed technical review of all integrations consuming the package. Include APIs, middleware, external systems, automation workflows, RPA bots, and background jobs. Obtain written confirmation from integration architects and technical teams.
Step 4 — Engine Consumption Analysis: If the package removal will affect any engine-licensed services, verify that engine consumption is within contract and establish baseline measurement for ongoing monitoring.
Step 5 — Documentation and Counsel Review: Compile usage analysis, integration mapping, technical sign-offs, and engine consumption baseline into a single document. Have SAP audit defence counsel review the complete package before removal. Make removal only after counsel approval.
Step 6 — Post-Removal Monitoring: After removal, monitor for any access attempts to the removed package. Maintain all documentation and measurement data for minimum 3 years to support audit defence if SAP challenges the removal.
This process is more rigorous than most organisations currently follow. It adds 4–8 weeks to any optimisation initiative. The benefit is that it makes the removal defensible against audit challenge and significantly reduces the risk of back-licence discovery. Given that a single audit finding can generate €500K–€2M in claims, the time investment is justified.
Frequently Asked Questions
📬 SAP Licensing Risk Intelligence
Get Expert SAP Optimisation Analysis — Free
Independent assessment of your SAP package licence position, audit risk, and optimisation opportunities. No SAP affiliation. Confidential advisory.