SAP Licence Consolidation: Practical Enterprise Guide

SAP licence consolidation is the systematic process of reducing your named user count, reclassifying expensive users to lower-cost categories, and retiring unused accounts. For a €15M SAP shop, successful consolidation typically recovers €2-5M in licence costs. But the word "typically" hides the gap between theory and execution. The enterprises that capture these savings are the ones that follow a specific sequence of steps, each with documentation requirements that SAP will challenge if you're not prepared.

This guide is practical. Not theoretical. It covers the exact methodology we use for enterprises ranging from €3M to €75M in annual SAP spending, the specific tools you'll need (USMM, LAW, STAR, transaction logs), and the documentation requirements that separate successful consolidations from false starts.

The biggest mistake we see: enterprises propose consolidation to SAP before they've completed their own baseline analysis. SAP's account team responds with their own measurement — which invariably counts more users than your analysis, and becomes the "reference number" for negotiations. By that point, you've lost leverage. This guide shows you how to avoid it.

What "Practical" SAP Licence Consolidation Means (vs Theoretical)

Theory says: measure your users, reclassify the ones who don't need expensive licences, submit the new count to SAP, receive credit. In practice, you'll encounter resistance at every step — because SAP's entire licensing enforcement strategy depends on user overcounting, and consolidation directly threatens that revenue.

Practical consolidation means building a case that SAP cannot credibly dispute. This requires:

• Independent baseline analysis using transaction logs, access control records, and role-based evidence — not SAP's own measurement tools, which are biased toward higher counts.
• Documented justification for every user reclassification, with specific transaction evidence that proves the user's actual scope is lower than their current licence tier.
• Proof of account hygiene. Active removal and documentation of users who are inactive, locked, or no longer employed.
• Technical evidence that shows SAP your measurement approach is more rigorous than their standard methodology.

The enterprises that succeed in consolidation are the ones that treat it as a compliance project: build evidence first, negotiate second, submit third. The sequence matters. If you submit first and negotiate second, SAP controls the baseline and you're negotiating down from their inflated count.

Step 1 — Build Your Baseline ELP Independently (Before SAP Sees Anything)

ELP is SAP's term for "Enterprise Licence Portfolio" — the current count of all your named users. The first rule of consolidation is this: never ask SAP to run the baseline measurement for you. SAP's measurement tools (USMM, LAW, STAR) are designed to support SAP's enforcement strategy, not to help you optimise your costs. They will consistently overcount.

Your independent baseline must answer three questions: (1) How many active named users do we actually have? (2) Which users should be Professional vs Limited Professional? (3) How many accounts are inactive or should be removed?

Extracting Transaction Logs from SM20 and SM70

SM20 and SM70 are the SAP standard transaction logs that capture all user access to the SAP system. SM20 is the System Log tool; SM70 is the Workload Activity Monitor. Together, they provide the forensic record of who actually accessed SAP, when, and what they did.

Extract a minimum of 6 months of transaction data from both logs. The standard approach is a 12-month extraction, but if you're under time pressure, 6 months is defensible. Export the logs to CSV format and sort by user ID. This gives you a definitive list of users who have actually logged into SAP within your measurement period. This is your ground truth.

Any user who does not appear in SM20/SM70 logs for 90+ consecutive days is a candidate for deactivation or reclassification. Users who appear only once or twice in a 12-month period should be flagged for removal or Employee/Productivity tier demotion.

Common finding: In a typical 5,000-user installation, 15-25% of named users generate zero transaction activity in a 12-month period. These accounts exist in the system but are not actively used. They're still licensed, still counting toward your spend, and represent immediate consolidation opportunity.

Running Your Own User Classification Analysis

After you have the activity logs, run a user classification analysis. This is a role-based assessment that maps each user's actual transactions to the user type definitions in your SAP contract.

SAP's standard user types are: Professional (full unrestricted access, highest cost), Limited Professional (specific transaction/module access, typically 40-60% less expensive), Developer (development environment access), Employee (self-service only), Functional (narrow functional area access), and Productivity (lowest cost, read-only or very restricted). There are also ESS (Employee Self Service) and Manager Self Service licenses.

For each user in your extraction, run a transaction analysis to determine which user type fits their actual usage pattern. A user classified as Professional who only executes MM (Materials Management) transactions with no FI (Finance) access should be reclassified as Limited Professional. A user with only ESS transactions should not be a named user at all.

Tool reference: This analysis can be done manually in Excel or with SAP's own role-based access control reporting. The key is that you're not just looking at the user's assigned role in SAP — you're looking at what transactions they actually executed. Role assignment and actual usage frequently diverge. This divergence is your consolidation opportunity.

Building the Named User Matrix

Once you've completed the activity analysis and user classification, build a matrix. Columns should include: User ID, Full Name, Department, Current Licence Type, Actual Usage Pattern, Recommended Licence Type, Evidence Source, Annual Savings If Reclassified. Keep this internal — this is your working document, not for sharing with SAP yet.

The matrix serves two purposes. First, it forces you to be specific about why each reclassification is justified. Second, it's the document you'll use to build your case to SAP. Every entry in the matrix needs supporting evidence, typically in the form of the STAR data (which you'll collect in Step 3) or the transaction logs themselves.

A typical matrix for a 5,000-user SAP install might show: 3,200 Professional users current, 1,800 candidates for Limited Professional reclassification, 800 candidates for Employee or Productivity tier, and 200 candidates for deactivation. If Named User Professional costs €3,500 annually and Limited Professional costs €1,200, those 1,800 reclassifications represent €4.14M in annual savings. This is your value proposition.

Step 2 — Execute Ghost User Purge and Account Hygiene

Before you do any reclassification, remove the accounts that shouldn't exist. These are the low-hanging fruit: leavers (employees who left the company but still have active SAP accounts), service accounts that are locked or inactive, test accounts that were never properly removed, and contractor accounts whose engagements ended.

Identifying Leavers, Service Accounts, and Locked Users

Cross-reference your SAP user master data with your HR system. Any user in SAP whose ID does not match an active employee in HR should be flagged. Export the HR database of active employees and do a left-outer join against your SAP user list. The non-matching records are candidates for deactivation.

Service accounts — accounts created for background jobs, middleware integrations, batch processes, or system-to-system connections — are usually locked or have password change restrictions. In your SM20 extraction, these accounts will show either zero transaction activity or very regular automated activity at specific times. Flag them as potential deactivation candidates if they're not actively supporting a current integration.

Check the SAP user master data (table USR02) for accounts with status indicators: locked, no logon, password expired, or validity date exceeded. Any user in locked status who has not been accessed for 12+ months should be deactivated immediately.

Typical finding: In a 5,000-user population, 200-400 accounts meet the criteria for immediate deactivation: they're in locked status, inactive for 12+ months, or no longer employed. Removing these first demonstrates rigor to SAP and immediately improves your cost position.

Documentation Requirements to Survive Audit Challenge

Document the deactivation. For each account removed, create a record containing: User ID, Last Name, Termination Date, Last SAP Access Date, Confirmation from HR that employee is no longer active, Date of Deactivation, and SAP transaction used to deactivate (typically SU01).

Store these records with a timestamp. If SAP audits you and questions whether you had the right to remove user XYZ, you'll have documented evidence of the removal, the date, and the business justification. This is not overcautious — 52% of SAP customers have been audited more than twice in 18 months, and audit defence always comes down to documentation.

For accounts you're reclassifying rather than removing, the documentation bar is similar: provide evidence that the user's actual usage justifies the new licence tier, retain the transaction logs that support the analysis, and keep HR records confirming the user is still employed in their current role.

Step 3 — User Reclassification — Which Users to Target First

Not all reclassifications have equal risk. Some users are clear candidates — their transaction records show restricted usage, the role definition supports a lower-cost tier, and the risk of challenge is minimal. Others are borderline and require more evidence.

Start with the clear candidates. They generate immediate savings and build momentum. Then move to the more complex cases.

Professional to Limited Professional: The Biggest Opportunity

The largest single consolidation opportunity in most enterprises is the Professional-to-Limited-Professional reclassification. Named User Professional is SAP's catch-all licence for any user with unrestricted access. Limited Professional is for users with defined, restricted access — specific modules or transaction groups.

In practice, many users are licensed as Professional when their actual role requires only Limited Professional access. The reasons are usually legacy — they were licensed at Professional as a precaution when they joined, or their role has narrowed since their original licence assignment. Because Professional is the default, no one re-evaluates it unless forced to.

Your transaction analysis reveals this. A user assigned Professional but whose SM20/SM70 logs show execution of only MM transactions (all materials management) with no FI, SD (Sales & Distribution), or any other modules is a clear Limited Professional candidate. You have evidence. The user's actual scope is not "full unrestricted access" — it's "materials management transactions only."

SAP will resist this reclassification if you frame it as a cost reduction. SAP will accept it if you frame it as a compliance matter: "We've completed a usage analysis and determined that user [X]'s actual access requirements are [Y]. We're aligning the licence tier to the documented requirement." This is true, it's defensible, and it shifts the conversation from "you're trying to save money" to "you're improving compliance."

How to Use STAR Data as Your Evidence

STAR is SAP's System and Technology Analytics Repository — it's a data warehouse that captures usage metrics across your SAP environment. It includes transaction frequency, user activity patterns, role-based access, and module usage.

Most enterprises don't access STAR data regularly. This is a mistake. STAR provides the technical evidence layer that supports user reclassifications. If you're proposing to reclassify user X from Professional to Limited Professional, pull their STAR report. It will show, by module, transaction frequency, and access pattern. If STAR shows that user X has zero FI transactions in the past 12 months but 3,000+ MM transactions, that's forensic evidence that supports the reclassification.

SAP's own measurement tools use STAR data. When you present STAR evidence to justify reclassification, you're using SAP's own data against SAP's resistance. This is very effective. It's hard to argue that your reclassification is unfounded when SAP's own STAR system confirms the usage pattern you're citing.

Practical approach: Extract STAR reports for your top 500 users by cost (Professional users only). Sort by actual module usage. Identify clusters of users with narrow usage patterns — all MM, all FI, all HR. These users are reclassification candidates. Build your initial target list from these clusters. These are your highest-confidence, lowest-risk reclassifications.

Step 4 — Engine and Package Metric Analysis

SAP's licensing model includes not just named users but also application component metrics. Some SAP products — like Analytics Cloud, Advanced Planning, or CRM — are sold on "Named Users per Product" or "Package" models, where the licensed product is separately counted and priced.

During consolidation, audit your application component inventory. Are you licensing modules you're not using? Do you have maintenance contracts on products that were deployed 5 years ago and are no longer in production? Are you paying for Analytics Cloud named user licensing when your actual active users are far lower than the quantity you're paying for?

This is not user reclassification — this is licence scope optimization. The savings can be substantial. We've seen enterprises discover, during consolidation, that they're paying support and licensing for SAP Advanced Planning (APO) or Plant Maintenance (PM) modules that are inactive. Removing inactive product scopes can reduce licence costs by 10-15% independently of user consolidation.

Step 5 — Prepare Your Consolidation Submission to SAP

By this point, you have completed your independent baseline analysis, removed ghost accounts, reclassified users with documented evidence, and audited your product scope. Now you're ready to submit to SAP. The sequence and timing are critical.

What to Include, What to Withhold

Your submission to SAP should include: your new baseline user count, broken down by user type, the number of accounts deactivated and the business justification, the reclassifications you're proposing with a summary of the evidence basis (you don't need to provide the full SM20/SM70 logs unless requested), and the estimated annual savings.

What you withhold: your internal user matrix, your complete transaction logs, your STAR reports. Don't volunteer these unless SAP specifically requests them. Your submission should be a summary with confidence that your analysis is sound. The detailed evidence stays internal until SAP asks for it — or until you're in an audit situation.

Frame the submission as a compliance matter, not a cost reduction. Write: "We have completed a comprehensive user access analysis and identified users whose current licence tier does not match their functional requirements. We're proposing reclassification to align licence assignment with actual role scope, which will improve our compliance posture." This is true and it's less confrontational than "we found 1,800 users you overcharged us for."

Timing Your Submission for Maximum Leverage

SAP's account teams operate on quarterly revenue targets and annual renewal cycles. The worst time to submit a consolidation request is 30 days before the quarter ends — SAP's sales team will be highly resistant because a consolidation claim reduces their quarterly revenue number. The best time is the first 30 days of a quarter, or ideally, during a contract renewal negotiation when SAP is motivated to find terms you'll accept.

Never submit a consolidation request in isolation. Pair it with another ask: perhaps a price protection clause negotiation, or a contract term extension, or a product scope addition. SAP will be much more willing to accept your consolidation claim if it's part of a negotiated trade-off where both parties get something.

If you're not in a renewal period, submit the consolidation request, expect SAP's account team to push back, and then have ready the detailed evidence to justify your position. But do this only after you've completed all the technical work. Don't negotiate with incomplete evidence.

Working with an Independent SAP Licensing Advisor on Consolidation

The question you should ask is not whether to use an independent advisor, but when — and the answer is: early. Ideally before you run your baseline measurement. The reason is that consolidation contains multiple technical decision points where an early mistake can cost more than the advisory fee.

For example: if you run your baseline measurement using USMM without first understanding which USMM version your system is running, and which mode it's configured in, you may get a count that SAP will legitimately challenge. An advisor helps you select the right measurement approach from the start. This is worth far more than the cost of the engagement.

Our SAP Licence Optimization service covers the full consolidation workflow: independent baseline analysis, user classification, evidence gathering, gap identification, and the submission and negotiation with SAP. The typical engagement timeline is 8-12 weeks for an enterprise with 3,000-10,000 users. For larger populations, 12-16 weeks.

The ROI is straightforward. If you recover €1.5M in licence costs, the advisory cost becomes 1-2% of the recovered amount. This is a 50-100× return. And the risk reduction is equally important — the alternative is a failed consolidation or an adverse audit finding because you didn't document your work.

Our SAP License Optimization service is independent, fixed-fee, and buyer-side only. We don't have SAP affiliation. Contact us for a scope conversation if you're planning consolidation.

Frequently Asked Questions

How much time does a complete consolidation cycle take?

For a 5,000-user SAP installation, a complete consolidation cycle — baseline analysis, ghost user purge, reclassification analysis, and SAP submission — typically takes 8-12 weeks if done independently, or 6-10 weeks with dedicated advisory support. The largest time component is evidence gathering (SM20/SM70 extraction and analysis). For larger populations (10,000+ users), extend the timeline to 12-16 weeks. Negotiation time with SAP is separate and typically adds 4-8 weeks.

Will SAP accept reclassifications without challenging them?

SAP will always push back on consolidation claims initially — it's a reduction in their revenue. But with documented evidence (transaction logs, STAR data, role-based access control documentation), most reclassifications are eventually accepted. The enterprises that win on consolidation are the ones with better evidence than SAP's measurement tools. If your evidence is stronger than SAP's USMM count, you have leverage. This is why the documentation phase is critical.

Can we do consolidation during an audit?

You can propose reclassifications during an audit, but you lose leverage. SAP's GLAC team is focused on finding under-licensing; they're not incentivized to accept your consolidation claims. The right approach is to complete consolidation before the audit, or to use the audit findings as the starting point for consolidation (i.e., if SAP claims you owe money for unlicensed users, negotiate a consolidation and licence true-up that partially offsets their claim). Never start consolidation for the first time during an audit.

What's the typical savings range for consolidation?

For a €15M SAP annual spend, successful consolidation typically recovers €2-5M in net annual licence costs, depending on the extent of user overcounting and inactive accounts. A €3M shop typically recovers €400K-€1M. The variance depends on three factors: the age of the current licence assignment (older assignments tend to have more legacy Professional users who should be downgraded), the complexity of your user integration landscape (more integrations = more indirect access exposure, which affects reclassification opportunity), and the quality of your current SAP account management (well-managed accounts have fewer ghost accounts). Conservative estimate: 12-25% of current spend. Aggressive: 25-40% if you have significant legacy overcounting.

Do we need SAP permission to deactivate accounts?

No. You can deactivate any account in your own system. The question is whether SAP will accept the deactivation as legitimate if audited. The answer is yes — if you have documentation. Any user who is no longer employed, who is in locked status, or who has generated zero activity for 12+ months is a defensible deactivation. You don't need SAP permission to remove ghost accounts. You need documentation to defend the removal if questioned.

📬 SAP Licence Consolidation Support

Get Expert Consolidation Analysis

Practical guidance on user analysis, reclassification strategy, and SAP negotiation. Independent, buyer-side only. No SAP affiliation.

Please use a corporate email.

Get Consolidation Insights →