Key Takeaways

  • Sharing USMM data with SAP during baseline assessment creates audit intelligence that SAP leverages in future audits
  • User reclassification creates audit risk if not properly documented and defended before implementation
  • Indirect access assessment exposes technical debt that becomes SAP audit leverage if undiscovered
  • Classification errors in baseline can worsen your position if auditors identify them first
  • Over-correction of licences creates compliance risk if you shed licences you technically need
  • Contract interpretation errors in baseline may invalidate your reclassification claims

SAP Licence Baseline Benchmarking Risks: Why Caution Matters

SAP licence baseline benchmarking is not risk-free. In fact, the data you extract and the reclassifications you make during baseline assessment can become the foundation of SAP's next audit if not managed with strategic precision. We have seen enterprises run baseline assessments that uncovered cost reduction opportunities, only to trigger audits that resulted in far larger exposure than their original over-licensing ever warranted. The difference was not the baseline work itself—it was the risk blind spots that went unaddressed.

When you embark on baseline benchmarking, SAP's role in the process changes your risk calculus. If you share your findings with SAP before you understand the implications, you transition from a buyer controlling information to a buyer providing SAP with an audit roadmap. If you implement reclassifications without defending them against likely audit challenges, you create compliance exposure. If you fail to assess indirect access during baseline, you leave an open vulnerability that auditors will exploit.

Baseline benchmarking is essential. But it must be executed with eyes open to the risks.

The Central Risk: Data Exposure and Audit Intelligence

The most significant risk in baseline benchmarking is self-inflicted: sharing your user data with SAP before you fully understand what SAP will do with that information. This is the trap that many enterprises fall into when working directly with SAP on baseline assessment.

Here's the typical scenario: An enterprise runs a baseline assessment, finds over-licensing, and decides to file for audit reconciliation with SAP. The company shares USMM export data, LAW position, and reclassification plans with SAP. SAP accepts the correction, adjusts the contract, and everyone moves forward.

Eighteen months later, that same enterprise's next audit targets the data they shared during the baseline reconciliation. SAP's auditors request documentation for every reclassification decision. They challenge the transaction analysis that justified moving users from Professional to Limited Professional. They question dormant account deactivations that happened months ago. They identify indirect access that wasn't formally addressed. The original baseline assessment, intended to protect the enterprise, has instead become the audit blueprint.

This happens because SAP treats baseline data as audit intelligence. When you voluntarily share your USMM export, you're providing auditors with a documented baseline for future enforcement. If auditors can show that you had visibility into your over-licensing (because you shared the baseline with them) and failed to correct it fully, that becomes a liability. "You knew about these dormant accounts in December 2023. Why were they still active in March 2024?" The baseline date becomes the starting point for enforcing licence correction.

Risk Mitigation: Control Your Information Disclosure

If you are working with an independent advisor on baseline assessment, do not share the raw baseline data or detailed reclassification analysis with SAP until you have fully modeled the cost impact and established your negotiating position. Here's the sequence that reduces risk:

  • Run baseline internally or with an independent advisor. Extract USMM, LAW, activity data. Classify users. Identify dormant accounts. Complete the analysis without SAP involvement.
  • Model cost scenarios. Quantify the impact of various reclassification levels: conservative (safe reclassifications only), moderate (broader reclassifications with supporting documentation), aggressive (maximum cost reduction with heightened audit risk).
  • Determine your position. Decide which scenario aligns with your risk tolerance and contractual justification. Prepare documentation that supports your position.
  • Initiate conversation with SAP from strength. When you contact SAP, you're not asking for validation of baseline findings. You're informing them of adjustments you've made to your user estate and requesting contract amendment: "We've optimized our user licensing. Our current active user count is X. We're requesting adjustment to our LAW entitlement from Y to X, effective [date], with corresponding adjustment to maintenance costs."
  • Limit data sharing. Share only the information necessary to support your position: final active user count, relevant contract language, cost adjustment request. Do not share transaction logs, dormant account lists, or detailed reclassification analysis unless SAP specifically challenges your position.

This approach maintains your information advantage. You control what SAP knows about your user estate. You establish facts before SAP can challenge them. You negotiate from documented strength rather than audit exposure.

The Classification Error Risk

Misclassification During Baseline Can Worsen Your Audit Position

User classification is the operational heart of baseline benchmarking. But classification errors create compounding risk. When you reclassify a user from Professional to Limited Professional, you are making a legal claim about that user's licence requirements under your SAP agreement. If the classification is wrong, the reclassification is indefensible.

A common classification error occurs when enterprises reclassify based on job title rather than system usage. An "analyst" is assumed to be a Limited Professional candidate. But if that analyst runs complex reports, customizes queries, or accesses configuration tools, they may legitimately require Professional access. If you reclassify this user to Limited Professional to cut costs, and SAP's auditors review their activity logs, they will immediately identify the misclassification. At that point, you're not just liable for the licence cost—you're liable for the entire period the user was "misclassified," which SAP will extend back to the date of your baseline assessment or even further.

Classification Criteria That Reduce Risk

To minimize classification risk, anchor reclassification decisions in documented criteria that SAP will find difficult to challenge:

  • Transaction usage analysis: Document the specific transactions each user runs. Users who run only a limited, repeating transaction set are candidates for Limited Professional. Users who run more than 200 distinct transaction codes typically require Professional access.
  • Role-based justification: Link classification to formal SAP roles. If a user is assigned to roles that explicitly restrict certain modules or transaction families, Limited Professional classification is defensible. If roles map to broad access, Professional is required.
  • Access to restricted modules: Any access to financial reporting, GL posting, fixed assets, or HR master data modification justifies Professional classification. Limited Professional users should be restricted from these areas.
  • System configuration access: Users with access to customizing, Workbench, or development objects must remain Professional. Development system access should never trigger production licensing.
  • Exception documentation: If a user's transaction pattern is atypical, document the exception clearly. "This Limited Professional user has approval authority for purchase orders up to $100k, which justifies a broader transaction set than typical Limited Professional users."

When auditors request justification for your reclassifications, these documented criteria become your defense. You're not saying "we believe this user should be Limited Professional." You're saying "this user's SAP role permits only these transactions, which are explicitly covered under the Limited Professional licence type per our agreement."

The Dormant Account Risk

Identifying and deactivating dormant accounts is a core baseline outcome. But dormancy itself carries audit risk if not properly defined and supported.

A user with zero logins in 12 months is unambiguously dormant. You can deactivate this account with confidence. But a user with logins in months 1-6 and zero logins in months 7-12 is in a grey zone. Is the account genuinely dormant, or has the user been on extended leave, sabbatical, or temporary assignment elsewhere? If you deactivate and the user returns in month 13, you have a compliance issue.

When baselining dormant accounts, apply stricter criteria than you might initially consider:

  • Zero logins in the past 18 months (not 12), or
  • Zero logins in the past 12 months with documented verification that the user has been separated from the company or permanently reassigned

Document the deactivation dates and the logic for each account. If auditors question a deactivation later, you have dated evidence of why the account was removed.

Indirect Access Assessment Risk

Exposing Your Indirect Access Vulnerability

Indirect access—users accessing SAP without named user accounts through Fiori apps, mobile apps, APIs, or partner portals—is SAP's most aggressive audit focus. Baseline benchmarking requires you to identify your indirect access exposure. But identifying exposure creates risk if you then fail to address it.

Here's the risk cycle: During baseline assessment, you discover that 2,000 employees access your employee self-service portal (ESS) via a Fiori app. You document this as "indirect access exposure" in your baseline report. You decide to file a contract adjustment based on your other findings but don't address the 2,000 ESS users in the adjustment. Three years later, SAP's auditors find the same 2,000 users in your baseline documentation and demand licensing for indirect access retroactively. Because you identified the exposure but didn't address it contractually, SAP positions it as willful non-compliance.

Indirect Access Mitigation Strategy

When you identify indirect access during baseline, you have three options, and you must choose one formally:

  1. License the indirect access. If indirect access is substantial, negotiate pricing with SAP or accept the cost as part of your enterprise footprint. This is the most expensive but safest option contractually.
  2. Restrict access to a defined, licensed set. If your indirect access is primarily ESS (self-service, learning, personal data) and not system-wide, you can make a contractual claim that ESS access does not require named user licensing. Document this claim formally in a contract amendment: "Indirect access to employee self-service functions does not require additional user licensing under this agreement."
  3. Implement technical controls to limit indirect access. Configure your Fiori launchpad, mobile applications, and API consumers to restrict access to specific functions that don't trigger licensing requirements. Document the technical architecture that supports your claim.

The key: Make a decision during baseline and document it formally in writing to SAP. Do not leave indirect access in a grey zone. Unresolved grey zones become audit vectors.

For comprehensive strategy on defending your indirect access position, engage the SAP indirect access advisory service.

Technical Debt and Contract Interpretation Risk

Licence Baseline Legacy Systems

Many enterprises discover during baseline assessment that their system contains years of technical debt: batch user accounts that were created for integrations and never deactivated, generic accounts shared across teams, system service accounts that don't align with current architecture. This technical debt creates two risks:

  • Deactivation risk: If you deactivate accounts that are actually still in use (batch processes, background jobs), you create operational risk. You damage production systems before you realize the account was critical.
  • Audit risk: If auditors identify that you had accounts you couldn't justify, they assume all such accounts require licensing until proven otherwise. "This account was created in 2019 and you can't explain what it does? It's a Professional user. Pay for it."

Technical Debt Mitigation

When baselining accounts with unclear purpose or status:

  • Coordinate with your technical SAP team (BASIS, ABAP, integration teams) to verify whether each questioned account is still active.
  • For batch and service accounts, verify that they are configured as "batch only" or "service user" type in SAP, which may exempt them from named user licensing depending on your contract.
  • Document your investigation results. "Account BATCH_GL_001: Verified with SAP BASIS as dedicated batch user for nightly GL consolidation. Classified as batch-type user, exempted from named user licensing per agreement clause X."
  • If an account truly cannot be explained, deactivate it only after confirming with process owners that it is not in use.

Contract Interpretation Risk

Every reclassification claim in your baseline is implicitly a legal interpretation of your SAP licence agreement. If your interpretation is wrong, your reclassifications are indefensible. Common interpretation errors include:

  • Misinterpreting user type definitions: Your agreement may define "Limited Professional" more restrictively than SAP's system defaults. You assume any user with a subset of transactions qualifies. Your agreement may say Limited Professional users cannot access reporting modules. Misread this, and your reclassifications fail audit.
  • Misunderstanding module-based restrictions: Some agreements restrict certain modules (like human capital management or finance) to named user licensing, while other modules allow broader access. If you don't identify these restrictions, you may over-classify or under-classify users.
  • Misinterpreting the FUE (Full Use Equivalent) allocation model: RISE with SAP contracts allocate access via FUE rather than named users. Misunderstanding FUE carries risk. If your agreement grants 100 FUE and allows allocation across multiple named users, exceeding 100 named users requires additional FUE allocation—not additional named licensing.

Before implementing reclassifications from your baseline, have an independent licensing advisor review your contract interpretation. The cost of contract review is far less than the cost of misunderstood terms.

Over-Correction and Compliance Risk

The Danger of Too-Aggressive Cost Reduction

Baseline assessment often uncovers 20-35% potential cost reduction. The temptation is to pursue the full amount. But over-aggressive correction creates compliance risk that can exceed the cost savings.

If you reclassify 500 users from Professional to Limited Professional, but 50 of them truly need Professional access and you didn't realize it, you have created licence non-compliance for those 50 users for the entire period they were Limited Professional. When auditors identify this, SAP will claim non-compliance and seek retroactive payment not just for the 50 users but often for broader penalties.

A more risk-managed approach:

  • Identify all potential reclassification candidates during baseline.
  • Segment them into confidence levels: high confidence (clear transaction restriction), medium confidence (likely but some exceptions possible), low confidence (borderline).
  • Implement only high and medium confidence reclassifications in your first adjustment cycle. This realizes 70-80% of your cost savings with lower risk.
  • Defer low confidence reclassifications to a second cycle after you have built historical evidence that your medium confidence reclassifications are holding up in audits.
  • Monitor your reclassified users for 6 months post-implementation. If auditors challenge the reclassifications, you have active evidence that the users are operating successfully under the new licence type.

This staged approach is more conservative but significantly reduces your audit exposure.

Protect Your Baseline Assessment Against Audit Risk

Our advisors help enterprises navigate baseline benchmarking risks, from data protection strategies to contract-defensible reclassifications. Get expert guidance before you make changes that create liability.

Schedule Risk Review

Frequently Asked Questions

Should we share baseline data directly with SAP or keep it internal?

+

The safest approach is to complete your full baseline assessment internally or with an independent advisor, establish your final position, and then approach SAP with a contract adjustment request rather than a baseline "for validation." If you share raw baseline data with SAP, you're providing audit intelligence. If you approach SAP with your final numbers and documented position, you're negotiating from strength. Only share data that directly supports your specific contract adjustment request.

What's the safest threshold for deactivating dormant accounts?

+

Zero logins in 18 months (not 12) is the safest criterion, with documented verification that the user has been permanently separated or reassigned. If you use a 12-month threshold, require explicit business confirmation that the user will not require access in future months. Document deactivation dates and logic for audit trail. Even then, consider a "soft deactivation" first: disable login for 90 days while keeping the account active, giving business units a chance to object if the account is still needed.

How do we defend reclassifications if SAP auditors challenge them?

+

Documentation is your defense. For each reclassified user, you should be able to produce: transaction usage logs showing the specific transaction codes the user runs; SAP role assignments that explicitly permit or restrict certain functions; how the usage pattern aligns with your licence agreement's definition of the licence type; and the date the reclassification was implemented. If your documentation is clear and thorough, auditors cannot claim the reclassification was arbitrary.

What's the timeline risk if we identify indirect access in baseline but don't address it?

+

This is high risk. If you document indirect access exposure in baseline and don't formally address it in a contract amendment (either by licensing it, explicitly exempting it, or restricting it), SAP can claim willful non-compliance in a future audit. The timeline for retroactive enforcement can extend 3-5 years back from the audit date. The cost exposure grows exponentially. Resolve indirect access claims during baseline before they become audit liabilities.

Is it better to implement all reclassifications at once or phase them?

+

Phasing is lower risk. Implement your highest-confidence reclassifications first (often 60-70% of your total opportunity), monitor for 6 months, and implement additional reclassifications in a second phase if the first phase holds up. This gives you active evidence that your reclassifications are sustainable and also provides time to correct any errors you identify in the first phase before they become audit issues.

Related Resources

Explore more on baseline benchmarking risks and enterprise protection strategies: