SAP user licensing is one of the fastest areas to generate savings. Named user misclassification, dormant accounts, and system measurement misunderstandings collectively cost enterprises millions per year. This guide provides CFOs and procurement leads with a structured methodology to audit, classify, and optimise SAP user licences — cutting costs without disrupting business operations.
SAP's named user licensing model assigns each individual user a licence type based on their heaviest system activity. The five core types in most SAP agreements are fundamentally different in capability, cost, and appropriate use case. Understanding the distinctions between them is the foundation of any optimisation programme, because misclassification — particularly assigning higher-tier licences than the user's transaction footprint requires — is the single largest source of SAP licence waste.
Professional User licence holders have full access to all SAP transactions within their licensed systems. This is the highest-tier licence type and the most expensive. Professional licences are appropriate for power users in finance, procurement, supply chain, and materials management roles who require deep transactional access. A typical SAP organisation should have 10–15% Professional users at most; percentages above 20% are often indicators of misclassification.
Limited Professional User licences provide access to a defined, contractually-specified subset of SAP transactions. SAP defines limited professional licences in the contract as applying to specific transaction groups — for example, approval workflows, reporting, and specific functional module transactions. Limited Professional is appropriate for managers, team leads, and functional users who perform approvals, confirmations, and role-specific workflows but don't need full transactional access.
Employee User licences (formerly called Employee Self-Service or ESS) provide read-only access to personal data and basic self-service transactions — leave requests, payslips, personal information maintenance, and view-only access to assigned documents. Employee User is the most cost-effective licence type and is appropriate for the majority of an organisation. Shop floor workers, administrative staff, and employees who access SAP only for self-service functions should be classified as Employee User.
Developer licences grant access to ABAP development tools, the Basis workbench, transport management, and debugging facilities. Developer licences are required for ABAP programmers, Basis administrators, and SAP technical staff who work on system configuration and customisation. Organisations often over-license developers; not all IT staff working on SAP projects need Developer licences, only those directly performing development or system administration work.
Test licences are intended for non-production systems only — testing environments, quality assurance, training systems, and sandboxes. Test licences carry no cost and are unlimited in number, but SAP reserves the right to audit test system access and may challenge misuse of Test licences in production scenarios.
| Licence Type | Typical Users | Key Restrictions | Relative Cost |
|---|---|---|---|
| Professional User | Finance, Procurement, SD, MM power users | None — full access to all transactions | High |
| Limited Professional User | Managers, approvers, report users | Limited to defined transaction set per contract | Medium |
| Employee User | Shop floor, HR self-service, administrative staff | Self-service only, no transactional access | Low |
| Developer | ABAP developers, Basis administrators, technical staff | Development and Basis tools only | Medium-High |
| Test | QA teams, testing, training, sandbox access | Non-production systems only | Free |
Most SAP estates carry between 20% and 35% excess licence cost. Understanding the root causes of over-licensing is critical because unless the underlying drivers are addressed, optimisation savings will revert within 12–18 months as the estate naturally drifts toward misclassification again.
Want independent help negotiating better terms? We rank the top advisory firms across 14 vendor categories — free matching, no commitment.
Stale accounts are one of the most common and easiest-to-address sources of waste. Users who have left the company, transferred to other organisations, or gone on extended leave often remain active in SAP for months or years. Each stale account continues to be counted as a named user in SAP's measurement process. A typical enterprise with 5,000 active SAP users often has 200–400 stale accounts consuming unnecessary licence seats.
Misclassification upward occurs when users are assigned to a higher licence type than their transaction footprint justifies. This is often driven by convenience — assigning every manager a Professional licence "just in case" rather than analysing their actual transactions — or by risk aversion in IT teams that prefer to over-license rather than risk access restrictions. This pattern compounds over time; organisations that start with a 25% Professional User base often reach 35–40% within five years without active governance.
Role creep happens when users accumulate roles over time. A user initially assigned roles for their primary job function gets additional roles assigned for project work, temporary responsibilities, or cross-functional initiatives. When the project ends, the roles are rarely removed. Over three to five years, a single user may have 8–12 roles assigned, many of which are no longer relevant. SAP's measurement system classifies the user based on the highest-tier transaction in any of their assigned roles, meaning role creep directly drives licence type escalation.
Developer licence overuse is particularly common in IT departments. A systems administrator needs to access development tools occasionally; they are assigned a Developer licence for convenience. A business analyst supporting Basis projects receives a Developer licence despite not writing ABAP code. Over-licensing developers is less costly than over-licensing Professional users, but even a 20-person IT team with 5–6 unnecessary Developer licences costs €30,000–50,000 per year in unnecessary spending.
Satellite system users present a consolidation challenge. Users who access the main ERP system, plus Business Warehouse (BW) for analytics, plus Solution Manager for incident reporting, get counted separately in each system's user list. In measurement consolidation, these should be counted as a single user at the highest licence tier required across all systems. Organisations that don't consolidate properly end up paying for multiple licence seats for the same individual.
SAP's User and System Measurement (USMM) report captures the HIGHEST licence-triggering transaction accessed in the measurement period — which is typically 12 months. A user who ran a single Professional-level t-code once in 12 months will be classified as Professional for the entire measurement year, regardless of whether they never accessed it again. This makes measurement-based optimisation challenging because the measurement window is backward-looking, not forward-looking.
SAP's User and System Measurement (USMM) report is the authoritative record of your licence position. Understanding how USMM works is essential to understanding what your measurement result means and how to optimise against it. USMM is not a simple user counter; it is a sophisticated classification engine that analyses authorisation data, consolidates users across the system landscape, and assigns each user a licence type based on contractually-defined rules.
The USMM tool (accessed via transaction USMM in SAP) extracts active user accounts from each system, analyses the roles and individual authorisations (profiles) assigned to each user, determines the highest-tier licence type that the user's authorisations justify, and transmits the consolidated result to SAP's backend systems via the System Landscape Directory (SLD) or the Licence Audit Workbench (LAW) application. This transmission happens automatically if you have SLD connectivity; SAP can also receive manual uploads of measurement reports if your architecture doesn't support automated SLD connections.
USMM's classification logic is based on authorisations assigned, not transaction usage logged. This is a critical distinction. A user who has been assigned the role CFIN_ACCOUNTANT (Chief Financial Officer Finance role) will be classified as a Professional User even if they never log into the system or access any transactions. The measurement system assumes that if a user has been granted a Professional-tier role, they should be classified as Professional.
Engine licences (such as ICM — Interactive Capacity Management — or HR engine licences) are measured separately from named users in many SAP systems. These are licensing units assigned to specific system functions rather than to individuals, and they are tracked in a different measurement stream. Your measurement result will separate engine licences from named users, and both must be reviewed and optimised.
Indirect or digital access — RFC (Remote Function Calls) from external systems, APIs, integration scenarios — is measured differently from direct user access. SAP classifies these as either licence-triggering (requiring a named user or licence unit) or non-triggering, depending on the integration pattern and your contract terms. This is a sophisticated area where specialist interpretation is often required.
Run USMM in simulation mode (without posting results to SAP) at least 60 days before your contractual measurement date. This gives you time to clean up and reclassify users before the official measurement is transmitted to SAP and locked into your licence position for the next 12 months. If you discover overage at the official measurement, you will incur a true-up charge.
| USMM Classification Driver | What Triggers It | Optimisation Lever |
|---|---|---|
| Authorisation profile contains Professional t-codes | Single professional transaction in any assigned role | Remove unused roles; re-role the user to Limited Professional equivalent |
| Multiple roles assigned from different licence tiers | Role accumulation over time without cleanup | Role consolidation exercise; remove roles no longer required for current job |
| User is marked "active" in user master record | Account not locked despite user leaving the company | Implement deactivation-of-leavers process integrated with HR |
| User has Developer authorisations assigned | Developer role or Basis administration profile | Audit actual development activity; downgrade access-only users |
| User has zero logins in 12-month window | Account inactive but still marked active | Confirm with manager; lock and schedule deletion after 30-day grace |
A structured four-phase approach to SAP user licence optimisation minimises disruption, builds organisational buy-in, and delivers measurable cost reduction. The timeline is typically 90–120 days for a full optimisation programme, depending on organisation size and the extent of role complexity.
Get the IT Negotiation Playbook — free
Used by 4,200+ IT directors and procurement leads. Oracle, Microsoft, SAP, Cloud — all covered.
The discovery phase establishes a baseline and builds the data foundation for the entire programme. Your SAP Basis team extracts a full user list from each SAP system using transaction SU01 (User List) or SU10 (User List by Criteria). The report includes user ID, user name, user type, active/inactive status, role assignments, and last login date. For each system in your landscape (ERP, BW, CRM, Solution Manager, SuccessFactors, etc.), extract the user list independently.
Map each user to their business function (Finance, Procurement, HR, IT, etc.) and cost centre. Identify users who have left the company by comparing the SAP user list to the current HR master file. Identify contractors and seasonal users whose access should be terminated. Document the current licence count by type and by system. This baseline establishes where you are starting and will be compared against the optimised state to calculate savings.
The usage analysis phase builds an evidence base for reclassification decisions. Run SM20 (Security Audit Log) analysis for a 30- to 90-day window to capture which transactions each user actually accesses. This is different from their authorisations — SM20 shows real activity. For users showing zero logins, run BA (Batch Administration) analysis and login frequency reports to confirm inactivity.
Identify users with zero logins in the past 90 days — these are candidates for immediate lock-down. For users with activity, compare the transactions accessed to their assigned roles. A user assigned five roles but accessing transactions from only one role is a candidate for role consolidation. A Professional user whose usage pattern consists only of ESS transactions and report viewing is a candidate for reclassification to Employee User or Limited Professional.
Flag Developer users and validate that their usage pattern actually involves development work. Basis administration, system monitoring, and infrastructure work do not necessarily require Developer licence classification; these users may be candidates for downgrade to a more appropriate licence type.
The reclassification phase implements the changes identified in analysis. Lock and schedule deletion of stale accounts — this should be done in coordination with HR and with a 30-day grace period to catch any data integrity issues. Remove unused roles from active users. Work with functional leaders to consolidate role assignments so that each user has the minimum role set required for their job function.
For users identified as candidates for reclassification, work with their managers to confirm that the new licence type will support their access needs. Reclassify users to their appropriate licence tier. Restructure Developer accounts; if a Basis administrator only needs monitoring and troubleshooting access occasionally, they may qualify for a Limited Professional licence rather than full Developer access.
Document all changes with business justification. This documentation will be important if SAP challenges your measurement in an audit.
The governance phase prevents licence creep from recurring. Implement a joiner/mover/leaver (JML) process where HR system events (new hire, role change, termination) trigger SAP access provisioning and deprovisioning. Establish quarterly licence review checkpoints where IT and Finance jointly review new user creations and significant role assignments for licence impact.
Define role assignment approvals that require explicit assessment of licence impact — if assigning a new role will escalate a user's licence classification, this should require approval from Finance. Document role definitions and maintain a role library so that new roles are created against standards rather than ad-hoc accumulating permissions.
Prepare a formal optimisation results report and request a contractual adjustment to SAP reflecting the optimised user count. This is the lever point for realising savings.
Five actions can reduce licence costs within 30 days without requiring complex analysis or business process changes. These are the "quick wins" that deliver immediate value while the broader optimisation programme runs in parallel.
Run a user-by-last-login-date report (transaction SUIM > Listing > Users > Users by Last Logon Date). Identify all users with no login activity in the past 90 days. Cross-check with HR to confirm these are genuinely leavers or on extended leave. Lock these accounts immediately via SU01. Schedule permanent deletion after a 30-day grace period to catch any data integrity issues. Each inactive account locked reduces the named user count by one and eliminates a licence seat cost.
Audit all users currently classified as Developer. Run a query to find Developer role assignments and cross-check each one with the user's job function. Many system administrators, technical support staff, and project managers have Developer licences for convenience despite not actually performing development work. Reclassify these users to a more appropriate type — often Limited Professional or Employee User, depending on their actual activities. Even reducing Developer assignments by 10% typically yields €40,000+ in annual savings for a mid-sized organisation.
Professional users are expensive. Run SM20 audit log analysis filtering for your Professional-classified users and identify those whose actual transaction access consists entirely of HR self-service transactions (leave requests, payslips, personal information). These users should be reclassified to Employee User. A single Professional user costing €3,000–5,000 per year can be downgraded to Employee User for €500–800 annually — a saving of €2,200–4,500 per user.
Review your SAP landscape measurement consolidation. Users accessing BW, Solution Manager, CRM, SuccessFactors, or other satellite systems should be counted once at the highest licence tier required. Extract user lists from each system and identify users appearing in multiple systems. Ensure the LAW (Licence Audit Workbench) consolidation rules are correctly configured so these users are not double-counted. Fixing consolidation errors can reduce apparent user counts by 5–10% without any actual user changes.
Before your next official measurement transmission, request your SAP account team to walk through the LAW (Licence Audit Workbench) report with you. The LAW application processes your USMM output and applies SAP's consolidation logic. Discrepancies in consolidation, engine licence classifications, or contract term interpretation often surface during LAW review. SAP account teams frequently spot opportunities for legitimate reclassification that reduce your measurement result before it becomes official.
Optimisation efforts only deliver savings if they are reflected in your SAP contract. A 30% reduction in your user count is meaningless if your contract still specifies the original user commitment — SAP will simply not invoice you for the unused seats, but you won't formally reduce your contractual position.
Named user count reduction is the primary path to contractual savings. If you have reduced your active user count materially — say, from 5,000 to 4,200 users — you can request a formal amendment to your SAP contract at the next renewal to reflect the new lower user count. SAP rarely offers mid-contract user count reductions (they prefer to keep committed numbers high), but renewal negotiation is the leverage point. If your last measurement showed 4,200 users but your contract specifies 5,000, you are contractually over-committed and have leverage for a reduction at renewal.
Licence type mix renegotiation is another savings path. If you have historically contracted for 60% Professional, 25% Limited Professional, and 15% Employee User, but your optimised measurement shows 40% Professional, 35% Limited Professional, and 25% Employee User, you can request a contract amendment reflecting the new mix. SAP pricing is significantly more favourable for Employee User and Limited Professional than for Professional, so shifting the mix has direct cost impact.
True-up avoidance is critical. SAP contracts typically include a true-up provision: if your actual measurement exceeds your contracted entitlement, you pay the difference. Every Professional licence above your contracted count triggers additional payment, often at a premium rate. Completing your optimisation before the contractual measurement date avoids a true-up uplift. SAP sales teams often request accelerated measurement when they suspect a licence shortfall — getting ahead of this puts you in a stronger negotiating position.
ELA restructure consideration: If your optimisation shows you are consistently over on Professional users and under on Employee, consider negotiating an ELA (Enterprise Licence Agreement) restructure at your next renewal. An ELA with a "per-named-user" pricing model (rather than licence-type-specific pricing) may be more economical if your user base is highly variable or if cost-per-user is your primary concern. This is a strategic negotiation that benefits from specialist advisory support.
Ready to launch a SAP user licence optimisation programme?
Optimisation without governance reverts within 12 months. Unless you implement systematic controls to prevent role creep, prevent stale accounts, and enforce licence type discipline, your optimisation savings will disappear as the estate naturally drifts back toward misclassification. Building governance into your IT operations is essential.
Monthly user review by Finance and IT jointly assesses new user creations, significant role assignments, and notable account changes. The conversation is simple: "This new hire is being assigned the CFIN role; that triggers Professional classification and costs €4,000/year. Is that appropriate for this role, or should we provision Limited Professional access instead?" Monthly discipline prevents the accumulation that leads to over-licensing.
Integrated HR/SAP provisioning connects HR system events to SAP access. When an employee is terminated in the HR system, a workflow automatically locks the SAP account on the termination date, with permanent deletion scheduled for 30 days later. When a role change occurs in HR, a notification is sent to IT requesting SAP access updates. This automation prevents manual delays and ensures stale accounts don't linger.
Quarterly dashboard monitoring tracks active user count, licence type distribution, average users per system, and inactive user percentage. A simple one-page dashboard showing these metrics reviewed quarterly by the CFO and CIO keeps licence cost on the agenda and prevents slow drift back to misclassification.
Role library maintenance keeps your role definitions clean and documented. Undocumented roles accumulate t-codes over time as developers and admins add permissions on an ad-hoc basis. Formally documented role definitions prevent this. New role creation should be approved against a role template, and periodic audits should remove orphaned t-codes from existing roles.
Specialist SAP licence consultants bring tooling and expertise that internal teams often lack. While many organisations can execute phases one through three of optimisation internally, specialist advisory adds value in several ways.
Independent measurement tooling is often more comprehensive than USMM alone. Platforms like Snow Software, Flexera, or dedicated SAP licence tools analyse the landscape, flag classification edge cases, and provide alternative recommendations that USMM does not surface. These tools often identify opportunities that manual USMM analysis misses.
Contractual interpretation is specialised work. SAP's licence definitions vary by contract. What qualifies as "Limited Professional" is defined in your specific agreement, not in a standard document. Specialists spend time interpreting your contract terms and identifying reclassification strategies that are defensible against SAP audit. This interpretation work reduces the risk of an SAP audit challenging your classifications.
Negotiation support is another value area. Presenting a well-evidenced optimisation case to SAP — "We have reclassified 200 Professional users to Limited Professional based on SM20 activity analysis; here is the supporting documentation" — requires understanding SAP's measurement methodology and the contractual language that governs it. Specialists know how to present optimisation results in a way that SAP's licensing team will accept without challenge.
For organisations launching a user licence optimisation programme, the best SAP negotiation consulting firms include specialists with deep expertise in user measurement and reclassification strategy.
Our panel includes specialists who have recovered millions in SAP licence overpayments for enterprises globally. Structure a programme, execute it with confidence, and negotiate the savings back into your contract.