SAP Named User Licence Negotiation: Right-Sizing Before Renewal to Create Real Leverage
SAP's named user model is among the most deliberately complex in enterprise software. Misclassification inflates costs. Over-provisioning is systemic. This paper delivers the methodology and negotiation framework to convert utilisation data into credible reduction leverage.
Executive Summary
SAP's named user licence model — spanning Professional, Limited Professional, Employee, and Self-Service user types — is purpose-built to maximise licence revenue. The classification rules are complex, the boundaries between user types are intentionally ambiguous, and SAP's own measurement tools are calibrated to assign the highest applicable user type to every individual who touches the system. The result, across virtually every SAP deployment Redress has assessed, is systematic over-classification and over-provisioning that inflates annual maintenance and subscription costs by 25–35%.
This is not a compliance problem — it is a commercial one. Enterprises are paying for user types they don't need and user quantities they don't use. The opportunity sits in converting forensic utilisation data into negotiation leverage before the next renewal, when SAP's willingness to discuss commercial flexibility is at its highest.
25–35% of named user licences in a typical SAP deployment are either over-classified, under-utilised, or entirely dormant.
This is the average across 100+ Redress assessments. The range spans 18% at well-governed organisations to over 45% at enterprises that have never conducted an independent user audit.
The cost differential between Professional and Limited Professional users is 60–70% — making misclassification the single most expensive licence error in the SAP ecosystem.
A single user incorrectly classified as Professional rather than Limited Professional costs the enterprise $3,000–5,000 per year in excess maintenance. Multiply by hundreds of users and the exposure is material.
SAP's License Administration Workbench (LAW) systematically over-classifies users by assigning user types based on available authorisations rather than actual usage.
LAW measures what a user could do, not what they actually do. This means a user with broad authorisations who only performs limited functions is classified — and priced — at the highest tier their authorisations permit.
Enterprises that right-size before renewal achieve 2–3× better negotiation outcomes than those that negotiate pricing alone.
Discount negotiation without quantity and classification optimisation is negotiating the rate on an inflated base. Right-sizing the base first, then negotiating the rate, compounds the savings.
The RISE with SAP migration creates a one-time window to reset user classifications — but SAP's conversion methodology preserves existing over-classification by default.
Enterprises moving from on-premises to RISE inherit their current named user structure unless they intervene. The migration is the optimal moment to right-size, but only if the audit happens before the conversion, not after.
SAP's Named User Licence Model: Structure, Pricing & Deliberate Complexity
SAP's named user model assigns a licence type to every individual who accesses the SAP system, with the licence type determining the annual maintenance or subscription fee. Unlike concurrent user models (where you pay for simultaneous usage), the named user model charges for every provisioned user regardless of how frequently — or infrequently — they access the system. This structural choice is the foundation of SAP's licence revenue and the source of the over-provisioning problem.
The Four User Types
Full access to all SAP functionality. Designed for users who perform transactional activities across multiple modules — creating purchase orders, processing invoices, managing production orders, running MRP. The broadest access level and the most expensive. SAP's default classification for any user with access to core transactional functions.
Restricted to a defined set of SAP transactions. Intended for users who perform a narrow range of activities — time entry, travel expense submission, quality inspection recording. The boundary between Professional and Limited Professional is where most misclassification occurs, because the qualifying transaction lists are complex and SAP interprets them expansively.
Self-service HR functions only — viewing pay slips, updating personal information, submitting leave requests. Strictly limited to ESS (Employee Self-Service) transactions. Any access beyond ESS functions triggers reclassification to Limited Professional or Professional. Large organisations often have thousands of Employee users, making even small misclassification rates material.
Read-only or very limited interaction. Designed for external parties — suppliers checking PO status, customers viewing order status. The most restrictive user type with the narrowest set of permitted activities. Rarely the source of significant over-spend, but often under-utilised as a classification option for internal users with genuinely read-only needs.
The Classification Rules Problem
The distinction between user types is governed by SAP's named user classification rules, which map specific SAP authorisation objects and transaction codes to user types. The rules are documented in SAP's price list and associated documentation — but they are neither simple nor intuitive. A single authorisation object assigned to a user's role can elevate them from Limited Professional to Professional, even if they never execute the associated transaction. This means that authorisation design — which is typically managed by the Basis or security team with no commercial awareness — directly determines licence classification and cost.
The commercial implication is significant. Most enterprises design SAP authorisations for operational convenience, not licence optimisation. Roles are built with broad access to avoid change request overhead, and users are assigned multiple roles to handle edge-case responsibilities. Each broad role and each additional assignment carries a licence classification risk that is invisible to the teams making the decisions — until measurement time, when SAP's tools capture the full authorisation footprint and assign the highest applicable user type.
Key Insight
SAP's user classification model creates an incentive misalignment inside the enterprise. The Basis and security teams optimise for operational efficiency (broad roles, easy access). The procurement and commercial teams optimise for cost (minimal licences, correct classifications). These objectives are in direct tension, and without deliberate governance, operational convenience wins — at the enterprise's commercial expense.
The User Classification Audit Methodology
A credible user classification audit is the foundation of any SAP licence negotiation. Without forensic utilisation data, right-sizing conversations with SAP devolve into assertions versus counter-assertions — and SAP's measurement data always wins in the absence of an independent alternative. The following methodology produces the evidence base required to negotiate with confidence.
Extract the Complete User Master
Pull the full user master record set from all production SAP systems (ECC, S/4HANA, BW, CRM, SRM, SCM, GRC, Solution Manager, and any satellite systems). Include user ID, user type assignment, last logon date, password status, and lock status. This extraction establishes the total named user population — the denominator against which all analysis is measured.
Map Authorisation Profiles to Classification Rules
For every active user, extract the complete authorisation profile — all roles, all authorisation objects, and all transaction codes accessible through those roles. Map each user's authorisation footprint against SAP's named user classification rules to determine the classification-as-measured — the user type SAP's tools would assign. This reveals the gap between what SAP says you need and what your authorisation design actually requires.
Analyse Actual Transaction Execution History
Extract 12–18 months of transaction execution logs (SM20 security audit log, STAD statistical records, or table USR02 combined with transaction logs). For each user, identify which transactions they actually executed versus which transactions their roles theoretically permit. This is the critical distinction: classification-as-measured (based on authorisations) versus classification-as-used (based on actual activity). The delta between these two figures is your over-classification exposure.
Identify Dormant and Inactive Users
Flag users who have not logged in within the past 90, 180, and 365 days. Cross-reference against HR data to identify users who have left the organisation, changed roles, or moved to positions that no longer require SAP access. Dormant users represent the simplest savings opportunity — these are users you are paying for who generate zero business value from SAP access.
Model Reclassification Scenarios
For every user where the classification-as-used is lower than the classification-as-measured, model the authorisation changes required to support the lower classification. Quantify the role redesign effort, the security change management overhead, and the annualised licence savings. Produce a prioritised list of reclassification candidates ranked by savings-per-user and implementation complexity.
Produce the Independent Licence Position Document
Consolidate all findings into a single evidence document: total users by type (measured vs. optimised), dormant user count, reclassification opportunities with financial impact, and a comparison against SAP's own LAW measurement output. This document becomes the factual foundation for all renewal negotiations — a counter-narrative to SAP's measurement that is grounded in actual usage, not theoretical access.
Why Independence Matters
SAP's own measurement tools (LAW, USMM) produce data that SAP uses to determine your licence position — and therefore your commercial obligations. An enterprise that relies exclusively on SAP's tools to understand its own licence position is allowing the vendor to define the negotiation baseline. Independent measurement using transaction logs and authorisation analysis produces a materially different — and almost always more favourable — picture.
Shelfware Exposure & Over-Provisioning: What the Data Shows
Across more than 100 SAP deployment assessments, Redress has compiled consistent data on the scale and nature of over-provisioning in enterprise SAP environments. The patterns are remarkably consistent across industries, geographies, and SAP product versions — suggesting that the over-provisioning problem is structural to the named user model itself, not the result of individual enterprise mismanagement.
| Over-Provisioning Category | Typical Range | Median | Primary Driver |
|---|---|---|---|
| Dormant Users | 8–15% of total named users | 12% | Employee turnover without offboarding process; role changes without access review |
| Over-Classified Users | 10–18% of total named users | 14% | Broad authorisation roles; LAW measurement based on access rather than usage |
| Under-Utilised Professional Users | 5–12% of Professional users | 8% | Users assigned Professional for occasional tasks that could be handled by workflow or delegation |
| Duplicate Users | 2–5% of total named users | 3% | Multiple user IDs for same individual across systems; test users still active in production |
| Total Over-Provisioning | 25–35% of total licence spend | 30% | Compound effect of all categories |
The Financial Impact
To illustrate the financial scale: consider an enterprise with 5,000 named SAP users paying an average blended maintenance rate of $2,800 per user annually — a total licence maintenance spend of $14M per year. A 30% over-provisioning rate represents $4.2M in annual excess spend. Even after accounting for the cost of remediation (authorisation redesign, role restructuring, governance implementation), the net savings in the first year typically range from $2.5M to $3.5M, with the full $4M+ in annualised savings realised from year two onward.
These figures do not include the indirect savings from negotiating lower rates on the reduced base. Right-sizing the user population by 25–35% changes the commercial dynamic of the renewal conversation entirely — SAP is no longer negotiating the rate on a growing estate; they are defending against a reduction that directly impacts their revenue from the account. This dynamic shift is the core strategic value of right-sizing before renewal.
The RISE Dimension
For enterprises evaluating or committed to RISE with SAP, the named user over-provisioning problem carries forward into the subscription model unless deliberately addressed. RISE user classifications mirror the on-premises named user types, and SAP's conversion methodology maps existing classifications directly — preserving whatever over-classification exists in the current environment. Enterprises that right-size before RISE conversion lock in a lower, cleaner user base; those that convert first inherit the full over-provisioning burden at subscription rates that are typically higher per user than on-premises maintenance.
SAP's Measurement Tools: How LAW & USMM Over-Classify
Understanding how SAP measures your licence position is essential to understanding why over-classification is so pervasive. SAP's primary measurement tools — the License Administration Workbench (LAW) and the User System Measurement Module (USMM) — operate on a methodology that is technically defensible but commercially biased toward higher classifications.
The Authorisation-Based Methodology
Both LAW and USMM classify users based on assigned authorisations, not actual usage. The tools examine each user's complete authorisation profile — every role, every authorisation object, every transaction code accessible through those roles — and classify the user according to the highest-tier access available to them. If a user has a role that includes a single Professional-tier transaction code, they are classified as a Professional user — even if they have never executed that transaction and never will.
This methodology is not technically incorrect. SAP's licensing terms state that classification is based on the functionality available to the user, not the functionality they use. But this contractual position creates a commercially perverse outcome: it makes authorisation design — a technical decision made by Basis administrators — the primary determinant of licence cost. And because authorisation design is almost universally optimised for operational convenience rather than licence minimisation, the measurement outcome is almost universally inflated.
Common Over-Classification Patterns
Composite Role Inheritance
Enterprises commonly build composite roles that aggregate multiple single roles for administrative convenience. A composite role assigned to a Limited Professional user may contain a sub-role with a single Professional-tier authorisation object — elevating the entire user to Professional classification. The offending authorisation may be buried three layers deep in the role hierarchy and invisible to anyone not conducting a forensic analysis.
Wildcard Authorisation Values
Authorisation objects configured with wildcard values (e.g., activity type = '*') grant theoretical access to all activities within that object — including activities that trigger Professional classification. Even if the user's operational role only requires read access, a wildcard configuration is interpreted by LAW as full transactional access and classified accordingly.
Cross-System Aggregation
LAW aggregates authorisations across all SAP systems in the landscape. A user who is correctly classified as Limited Professional in the ECC production system but has a residual test role in the development system may be classified as Professional based on the combined authorisation footprint. This cross-system aggregation catches enterprises that maintain clean production environments but neglect development and quality assurance system hygiene.
Fiori App Mapping Gaps
With the shift to SAP Fiori, many enterprises deploy Fiori apps that map to backend transaction codes. The Fiori app may present a limited, self-service interface — but the backend authorisation required to execute it may include objects that trigger Professional classification. This disconnect between the user experience (simple self-service) and the authorisation requirement (Professional-tier objects) is a growing source of misclassification in S/4HANA environments.
Emergency Access (Firefighter) Residuals
Emergency access provisioning (SAP GRC firefighter IDs or equivalent) grants temporary elevated access for break-fix scenarios. When emergency access sessions are not properly closed or the temporary roles are not revoked, the elevated authorisations persist in the user's profile — and LAW classifies them as if the emergency access is permanent. This is particularly insidious because the user and their manager may be entirely unaware that the elevated access still exists.
"SAP's measurement tools answer the wrong question. They tell you what your users could do based on their authorisations. They don't tell you what your users actually do — which is the only question that matters for right-sizing."Redress Compliance — SAP Practice
The Right-Sizing Negotiation Framework
Right-sizing is not an end in itself — it is the mechanism for creating negotiation leverage. The framework below converts audit findings into a structured negotiation position that SAP's account team must respond to with substantive concessions rather than deflection.
Quantify the Reduction Opportunity
Translate audit findings into a specific, defensible reduction proposal: the number of users by type to be removed or reclassified, the annualised savings, and the authorisation changes required to support each reclassification. This proposal must be grounded in evidence — transaction logs, utilisation data, dormancy analysis — not assertions. SAP's account team will challenge every reduction, and only data-backed positions survive scrutiny.
Present the Reduction Before Pricing
Introduce the right-sizing analysis to SAP before engaging on pricing or commercial terms. This is a deliberate sequencing decision. If you negotiate pricing first and right-size second, SAP will argue that the agreed pricing assumed the current user base and cannot accommodate a reduction. If you right-size first, the pricing negotiation happens on the optimised base — and every percentage point of discount applies to a lower cost foundation.
Negotiate the Reclassification Methodology
SAP will dispute reclassifications that are based on usage rather than authorisation. The negotiation is about the measurement standard: SAP's position is authorisation-based; your position is usage-based. The compromise is typically an agreement to remediate authorisations (remove the offending objects/roles) within a defined period, with the reclassification taking effect upon remediation. This requires coordination between the negotiation team and the Basis/security team to ensure remediation is technically feasible.
Lock In the Optimised Base
Once right-sizing is agreed, ensure the renewed agreement reflects the optimised user base — not the pre-audit base with a promise to reduce later. The contractual user counts should reflect the right-sized population from day one. Any remediation that cannot be completed before the renewal effective date should be covered by a transition provision with a defined completion timeline, not left as an open obligation.
Negotiate Pricing on the Reduced Base
With the user base optimised, negotiate pricing independently. SAP's starting position will factor in the revenue impact of the reduction — which means their pricing flexibility may actually decrease because the account is already contributing less. Counter this by presenting the total contract value across the renewed term and demonstrating that a competitive rate on the optimised base still delivers meaningful revenue to SAP. Position the rate negotiation as the commercial conversation, not the reduction.
Establish Ongoing Governance
The right-sizing benefit erodes within 18–24 months without governance. New users are provisioned with broad roles. Temporary access becomes permanent. Offboarding processes fail to revoke access consistently. Build a quarterly user review cycle — automated where possible — that catches reclassification drift before it compounds. The governance investment is a fraction of the savings it protects.
Common SAP Renewal Traps & How to Avoid Them
SAP's renewal process contains several structural elements designed to preserve existing revenue and resist reduction. Recognising these patterns is essential to navigating the negotiation without conceding ground unnecessarily.
The "Measurement Is the Contract" Position
The Indirect Access Overhang
The RISE Conversion Deflection
The "Growth Guarantee" Requirement
The Renewal Timing Squeeze
Recommendations: 7 Priority Actions
The following actions are derived from Redress engagement experience across 100+ SAP named user assessments. They are ordered by implementation priority and designed to create maximum leverage for your next renewal.
Conduct an Independent User Classification Audit 12–18 Months Before Renewal
Do not rely on SAP's LAW or USMM output as your licence position. Commission an independent audit that compares classification-as-measured (SAP's authorisation-based view) against classification-as-used (actual transaction execution). The delta between these two views is your negotiation leverage. Start early enough to complete remediation before the renewal conversation begins.
Eliminate Dormant Users Immediately
Dormant users — those who haven't logged in within 180+ days — are the lowest-effort savings opportunity. Cross-reference the user master against current HR data, lock or delete accounts for departed employees, and revoke access for users who have changed roles. This cleanup can typically be executed within weeks and produces immediate, defensible user count reductions.
Remediate Authorisations Before Requesting Reclassification
SAP will only accept reclassifications that are supported by the authorisation profile. Before presenting your right-sizing proposal, implement the authorisation changes — remove the roles, objects, and transaction codes that trigger higher-tier classification for users whose actual usage supports a lower tier. This converts your usage-based analysis into an authorisation-based position that SAP's own tools will validate.
Right-Size Before RISE Conversion
If you are evaluating or committed to RISE with SAP, complete the named user optimisation before the conversion, not after. RISE user classifications mirror on-premises types, and SAP's conversion methodology maps existing classifications directly. Entering RISE with an inflated user base locks you into subscription rates on over-provisioned quantities for the duration of the RISE contract.
Address Digital Access Proactively
Conduct your own Digital Access (indirect access) assessment before SAP raises it. Understand your exposure from third-party system integrations (Salesforce, ServiceNow, portals, EDI) that create or modify SAP records without a named user login. Control the compliance narrative on both named user and Digital Access dimensions to prevent SAP from using one as leverage against the other.
Sequence Right-Sizing Before Pricing Negotiation
Present the right-sized user base to SAP before discussing rates. Negotiate pricing on the optimised base, not the inflated one. This sequencing decision compounds your savings: every percentage point of discount applies to a lower cost foundation, and SAP's pricing response accounts for the reduced revenue base rather than treating the reduction as a separate concession.
Implement Ongoing Licence Governance
Right-sizing without governance is a one-time exercise whose value degrades within 18–24 months. Implement a quarterly review cycle: automated user activity monitoring, authorisation change impact assessment, new-hire provisioning reviews, and offboarding compliance checks. The governance cost is a fraction of the savings it preserves — and it ensures the optimised position carries forward into subsequent renewals.
How Redress Can Help
Redress Compliance's SAP Practice provides end-to-end named user licence advisory services — from forensic user audits through negotiation support and ongoing governance. We operate with zero vendor affiliations, no reseller agreements, and no referral fees — ensuring our recommendations serve your commercial interests exclusively.
Named User Classification Audit
Forensic analysis of your SAP user population — authorisation profiles, transaction execution history, dormancy assessment, and misclassification identification across all production systems.
Right-Sizing Strategy
Reclassification modelling, authorisation remediation planning, and savings quantification. We produce the evidence-based reduction proposal that survives SAP's scrutiny.
Renewal Negotiation Support
Shadow advisory or active negotiation support throughout the SAP renewal process. We sit alongside your team in every SAP meeting, providing real-time guidance, counter-proposal development, and escalation management.
Digital Access Assessment
Independent analysis of indirect/Digital Access exposure from third-party integrations. We quantify the risk and build a compliance position that covers both named user and Digital Access dimensions.
RISE Conversion Advisory
Pre-conversion user optimisation for enterprises moving to RISE with SAP. We ensure you enter the subscription model with a clean, right-sized user base — not the inflated estate that SAP's default conversion would preserve.
Ongoing Licence Governance
Quarterly review programme to prevent reclassification drift, catch dormant users, monitor authorisation changes, and ensure the optimised position carries forward into subsequent renewal cycles.
100% Independent Advisory
Redress maintains zero vendor affiliations, no reseller agreements, and no referral fees with SAP or any SAP partner. Our only commercial relationship is with you — ensuring our analysis and recommendations are always aligned with your interests, not the vendor's. This independence is not a positioning statement; it is a structural commitment that defines how we operate.
Book a Meeting
Schedule a confidential consultation with our SAP Practice team. We'll review your current named user position and identify specific right-sizing opportunities ahead of your next renewal.