SAP Licence Consolidation: Checklist and Action Plan

Key Takeaways

Consolidation flows through five sequential phases: technical prep, ELP analysis, execution, documentation, and SAP negotiation
Phase 1 (technical preparation) must complete before any user reclassification or account elimination — skipping steps creates compliance risk
Phase 2 (ELP analysis) converts raw system data into contractual evidence that survives audit challenge
Phase 3 (technical execution) operationalizes the changes; all modifications must be reversible until SAP agreement is finalized
Phase 4 (documentation) builds the legal and audit defense package that supports your submission
Phase 5 (SAP negotiation) applies evidence systematically to claim cost reduction; timing relative to contract renewal matters
Completion time: 4–8 months depending on estate size and data quality; RISE migration dates create hard deadlines

How to Use This SAP Licence Consolidation Checklist

This checklist is designed as an operational guide, not a theoretical framework. Each item has a specific deliverable, a role owner (your IT, Finance, SAP Operations, or Compliance team), and a dependency relationship with other items. Do not treat the phases as flexible — they are sequenced deliberately. Phase 1 must complete before Phase 2 starts; Phase 2 must inform Phase 3 decisions; and so on.

The checklist assumes you have access to your SAP system's administrative tools (SM20, SM37, SU01, USMM, LAW) and that your SAP instance is in a stable state without active major upgrades. If you're mid-S/4HANA migration or operating multiple parallel systems, consolidation becomes more complex, and the timeline extends by 2–4 months.

For each phase, we've included the business rationale, the specific technical steps, the evidence you need to collect, and the audit defense value of each item. Use this as a project management tool: assign owners, set completion dates aligned to your contract renewal timeline, and track blockers.

If your RISE with SAP migration is scheduled for 2026, you must complete this entire checklist by Q4 2025 at the latest. RISE baseline fees lock at cloud go-live and cannot be retroactively adjusted — this creates a hard deadline that should drive urgency through your organization.

Phase 1: Technical Preparation Checklist (items 1–10)

Phase 1 is about securing your data foundation. You cannot reliably reclassify users or claim ghost user elimination without clean baseline data. This phase locks your system state, extracts the authoritative transaction and user master records, and documents your starting position. All items in this phase are read-only operations — you are not making changes yet.

The purpose is to create an audit-defensible record of your pre-consolidation licence state. If SAP later challenges your reclassifications or disputes ghost user elimination, you will reference Phase 1 data to prove your starting point and justify the changes you made. This is why data extraction timing matters: do not extract SM20 logs from "whenever you remember" — extract them on a specific date, document that date, and use it as your official baseline.

1

Lock SAP system change freeze. Implement a controlled change freeze for 30 days during Phase 1. No new users added, no user deletions, no role assignments modified. This ensures your baseline data is stable and represents your true state. Document the freeze in writing and communicate it to your IT operations team.
2

Export SM20 user transaction logs (12 months). SM20 (User Information System) records every interactive transaction a user executes. Extract the complete 12-month transaction log to a CSV file using report SUIM_LOGINS or SAP Audit Log Analysis tool. Include timestamp, user ID, transaction code, and system activity indicator. This is your evidence for ghost user identification and transaction-based reclassification.
3

Export SM37 batch/background job logs. SM37 (Batch Job Overview) shows which users execute batch jobs and when. Extract 12 months of SM37 job history for all batch jobs in your system. Filter for user-initiated jobs (exclude SAP system jobs). This identifies batch processing activity and determines which users classified as "Functional" might actually be processing-heavy.
4

Pull SU01 user master data for all systems. Export SU01 (User Master) records for every active and inactive user in all systems (production, quality, development if in scope). Include fields: user ID, full name, user type, creation date, last logon date, lock status, validity period. This is the authoritative list of your named user accounts.
5

Identify all subsidiary and production systems in scope. Map every SAP system you're consolidating (production, quality, development, regional systems, legacy systems). Document which systems are in active business use and which are maintenance-only or slated for decommissioning. Create a system inventory with go-live date, module scope, and current user count. This prevents you from claiming consolidation on systems SAP argues are "non-material."
6

Map all third-party system integrations (indirect access risk). During consolidation, you may reduce user count in your primary SAP system. However, if those users access SAP through third-party integrations (indirect access), they still consume SAP functionality and may require licences. Document all integrations: file imports, API connections, third-party tools connecting to SAP. This prevents SAP from claiming you've eliminated named users who are still consuming functionality indirectly.
7

Extract LAW/USMM last-run date and output. SAP's Licence Administration Workbench (LAW) or User Master Maintenance Monitor (USMM) runs periodically to record your effective licence position. Extract the most recent USMM output file and verify the last execution date. If USMM hasn't run in 90+ days, schedule a fresh run. This output will be your reference data for showing which users are "active" vs. dormant by SAP's own definition.
8

Pull current Order Form and Schedule of Licences. Get a clean copy of your current SAP Order Form, including the Schedule of Licences (Exhibit A, B, or equivalent). This documents your contracted licence entitlements by type and metric. During Phase 5 negotiation, you'll use this as the baseline and propose changes based on your consolidation findings.
9

Identify all user accounts locked >90 days. Query SU01 for users with lock status = "locked" or validity end date older than 90 days ago. These are candidates for ghost user elimination. Cross-reference with SM20 logs to confirm no transaction activity. Document the lock date and reason (if available) in a separate list.
10

Map HR system leaver data against SAP user accounts. Your HR system (SuccessFactors, HCM, or on-premise HR module) records employee terminations. Pull the list of employees marked as "leaver" or "separated" in the past 12 months. Cross-reference their IDs against SU01 to identify users who should have been deprovisioned but are still in SAP. This is ghost user evidence and demonstrates control gaps SAP can exploit during audit.

Phase 1 Completion Criteria: You have clean, dated baseline exports of SM20, SM37, SU01, USMM, and your current Order Form. All data exports are timestamped and stored in a secure, version-controlled location. You have documented your system scope, integration dependencies, and identified candidate accounts for elimination. Phase 1 typically takes 2–3 weeks.

Phase 2: Effective Licence Position (ELP) Analysis Checklist (items 11–20)

Phase 2 converts raw system data into contractual evidence. You take your SM20 and SU01 exports and analyze them to classify each user by their actual licence type entitlement (Professional, Limited Professional, Functional, Employee) based on transaction evidence. This is where the real consolidation work happens.

The ELP analysis is labor-intensive because you must examine transaction activity for hundreds or thousands of users. However, this work is what makes your consolidation defensible. SAP will challenge your reclassifications during audit; your ELP analysis is your proof that the reclassifications are justified by actual usage patterns.

11

Classify each user by actual transaction activity (STAR/SM20). For every user in SU01, query SM20 to determine which transaction codes they executed in the past 12 months. Count unique transactions per user and map those transactions to modules (SD, MM, FI, CO, HR, etc.). Users executing more than 50 unique transactions across 4+ modules = Professional activity. Users with 15–50 transactions in 2–3 modules = Limited Professional. Users with <15 transactions in a single module = Functional or Employee.
12

Map activity to licence type definitions in Order Form. Pull the exact user type definitions from your Order Form's Schedule of Licences. Compare your transaction analysis (step 11) against the contractual definitions. If your contract defines Professional User as "unrestricted access to all modules" and SM20 shows a user accessing only three modules, that user does not meet the Professional definition by contract.
13

Identify all Professional users with no Professional-level transactions. Build a list of all users currently licensed as "Professional" who, per SM20 analysis, execute fewer than 30 unique transactions or are confined to a single module. These are your reclassification candidates. The larger this list, the higher your potential savings.
14

Build Limited Professional candidate list with evidence. Identify Professional users who should downgrade to Limited Professional. For each candidate, document: (a) their current licence type, (b) the 12 months of SM20 transaction activity, (c) which modules they accessed, (d) how many unique transactions, (e) the contractual reason they don't meet Professional definition. Build a spreadsheet with one row per candidate — this becomes your submission to SAP.
15

Build Employee/Functional candidate list with evidence. Identify users who should downgrade to Functional or Employee type. Functional users typically execute 5–20 specific transaction codes for a narrow process (e.g., invoice posting, goods receipt, time sheet approval). Employee users have read-only access or portal-based access with minimal transaction execution. Document transaction codes and frequency for each candidate.
16

Identify ESS/Productivity candidates (portal users only). Extract employee self-service (ESS) portal users from your SuccessFactors, SAP Portal, or UX/UI configuration. These users access time entry, expense, benefits, leave request, and other employee-facing processes through a portal interface, not through SAP transaction codes. They typically need no named SAP licence; instead, they're ESS/Productivity or Employee users. Identify and list all portal-only users.
17

Analyse Engine licence usage vs contracted entitlements. For SAP BW, PI/PO, Analytics Cloud, and other engine products, extract usage metrics from the past 12 months. For BW: actual data volume loaded (from DBACOCKPIT), concurrent user peaks (from BW workload log), and query execution frequency. For PI/PO: actual message volume, peak load, and active integration count. For Analytics Cloud: active user logins, row volume queried, and data refresh frequency. Compare actual usage against your contracted metrics.
18

Analyse Package metric usage vs contracted entitlements. For cloud products (Ariba, Concur, SuccessFactors, FieldGlass), extract active user counts for the past 12 months. For Ariba: number of active procurement users per month. For Concur: number of expense submitters. For SuccessFactors: number of logged-in HCM users by module. Compare against your licensed seats.
19

Identify subsidiary licences eligible for global consolidation. If you operate regional SAP systems or acquired subsidiaries with separate SAP instances, determine whether those systems can be consolidated (technically and contractually) into a global licence agreement. Document the technical dependencies (network latency, system autonomy) and contractual triggers (acquisition date, separate vs. consolidated Order Forms).
20

Quantify financial impact per user category. Calculate annual savings for each category: Professional-to-Limited Professional reclassification × user count × licence cost × (1 + maintenance %), plus similar calculations for other reclassifications. Aggregate total consolidation savings. If your enterprise has 1,000 users with 20% Professional overage, and each Professional licence is €3,500 with 20% maintenance, the annual savings from 200 reclassifications = 200 × €3,500 × 1.20 = €840,000.

Phase 2 Completion Criteria: You have a detailed spreadsheet listing every reclassification candidate with supporting transaction evidence. You have analysis of engine and cloud product usage showing which entitlements are over-provisioned. You have a consolidated estimate of total consolidation savings. Phase 2 typically takes 3–6 weeks depending on user count and data cleanliness.

Phase 3: Technical Execution Checklist (items 21–30)

Phase 3 operationalizes the consolidation. You deactivate ghost users, move users to their correct licence type in SU01, and update authorization roles to match the new user type. This phase is where the rubber meets the road — you're making irreversible system changes. However, you should structure Phase 3 so that changes can be rolled back if SAP disputes your consolidation heavily.

The key principle is: make changes in batches, document every change with before/after evidence, and wait for SAP feedback before committing to the next batch. If you reclassify all 500 candidates in a single week and SAP responds by demanding reclassification reversal across the board, you'll spend weeks undoing work.

21

Execute leaver account deactivation and lock. Using the HR leaver list from Phase 1, systematically deactivate and lock user accounts in SU01. Set the user's validity end date to their separation date (or current date, if overdue). Lock the account with reason code "Separated from company." This is an operational necessity and is defensible by HR records.
22

Purge test accounts older than 12 months. Query SU01 for test users (accounts with names like TEST_USER, DEV_USER, etc.) and development environment accounts not accessed in 12+ months. Deactivate these accounts. They carry no business value and consume licence entitlements unnecessarily.
23

Deactivate confirmed ghost user accounts. Deactivate accounts identified in Phase 1 as having zero SM20 activity in 12 months and zero SM37 batch job activity. Lock them with reason code "No activity" and record the deactivation date. Do not delete accounts permanently — lock them so they can be reactivated if needed.
24

Document all account changes with approval trail. Maintain a change log of every account deactivation and user type change. Include: user ID, change date, reason for change (leaver, ghost, reclassification, test), approver name, and supporting evidence reference. This approval trail becomes your audit defense.
25

Update user master records (SU01) to correct licence types. For reclassification candidates, update the user type field in SU01. Change user type from Professional to Limited Professional, Functional, or Employee. Do this in batches (e.g., 100 users per week) so you can assess impact and backtracks if needed. Use transaction SU01 or a batch upload if your admin tooling supports it.
26

Validate role assignments align with new licence type. After reclassification (step 25), verify that the user's authorization role (in transaction PFCG or SU01 role tab) matches the new licence type. If you downgrade a user from Professional to Limited Professional, that user should not have a role that grants access to all SAP modules. If the role is too broad for the new licence type, create a more restrictive role or remove the user from the overly permissive role.
27

Run post-cleansing USMM to confirm user count reduction. After completing account deactivations and reclassifications, run SAP's USMM (User Master Maintenance Monitor) or LAW report to capture your post-consolidation licence position. Compare to the Phase 1 baseline. You should see a reduction in named user count (from ghost elimination) and a shift in user type distribution (from reclassifications). This post-consolidation USMM output is your proof that the consolidation actually occurred.
28

Verify no indirect access was created by role restrictions. When you restrict user roles (step 26), ensure that indirect access loopholes don't exist. Check whether users can still access SAP through reports, function modules, or third-party tool integrations even though you've restricted their direct transaction access. Document that no indirect access was created.
29

Archive pre-cleansing screenshots and reports. Save PNG screenshots of the Phase 1 SU01 user list, SM20 transaction logs, and USMM output. These become your audit evidence. Store them in a secured, read-only archive (OneDrive, SharePoint, or external drive) so you can reference them during SAP's audit challenge.
30

Confirm no active batch jobs run under deactivated accounts. Query SM37 to verify that deactivated accounts don't have scheduled batch jobs set to run. If batch jobs are scheduled for a deactivated user, either reassign the job to an active administrative user or delete the job if it's no longer needed.

Phase 3 Completion Criteria: All ghost users are deactivated, all reclassifications are complete in SU01, all authorization roles are aligned with the new user types, and you have a post-consolidation USMM output confirming the reduction in named users and the change in user type distribution. Phase 3 typically takes 2–3 weeks, plus 1 week per 500 users for batched reclassifications if you're moving slowly to avoid operational disruption.

Phase 4: Documentation and Evidence Checklist (items 31–35)

Phase 4 builds the formal package you'll submit to SAP. This is where your work becomes legally defensible. The documentation phase is about creating a narrative that connects your Phase 2 analysis to your Phase 3 changes and demonstrates that the consolidation is contractually and operationally justified.

31

Compile reclassification evidence file per user/cohort. For each reclassification candidate, build a file folder containing: (a) the user's SU01 master record (current and pre-consolidation), (b) 12 months of SM20 transaction logs for that user, (c) a summary sheet mapping their executed transactions to modules and frequency, (d) a comparison of their activity against your Order Form's user type definitions, (e) the contractual justification for the reclassification. If you're reclassifying 200 users, you should have 200 evidence files prepared.
32

Document contractual basis for each licence type decision. Create a reference document that quotes the exact language from your Order Form's Schedule of Licences defining "Professional User," "Limited Professional User," "Functional User," and "Employee User." Cross-reference this against your ELP analysis. This document becomes your counter-argument when SAP disputes a reclassification by claiming "the user needs Professional access for their role." Your counter: "Your Order Form requires ___ for Professional status; this user shows ___, which doesn't meet the definition."
33

Prepare pre/post comparison report. Create a comprehensive consolidation summary report showing: (a) pre-consolidation user count by type (from Phase 1 USMM), (b) post-consolidation user count by type (from Phase 3 USMM), (c) number of ghost users eliminated, (d) number of users reclassified by category, (e) number of test/development accounts purged, (f) engine and cloud product metrics before/after, (g) estimated annual savings impact by category, (h) the business case for consolidation (e.g., "cost reduction ahead of RISE migration").
34

Legal review of reclassification methodology. Have your legal or compliance team review the consolidation package to ensure it's defensible in an audit. Specifically, review the transaction evidence against the contractual definitions. Legal should validate that you've applied the Order Form language consistently and haven't made arbitrary reclassifications. A legal sign-off becomes part of your submission to SAP and raises the bar for SAP's ability to contest your position.
35

Confirm documentation survives disclosure in an enhanced audit. SAP has the contractual right to conduct enhanced audits, where they request all documentation supporting your consolidation. Before submitting to SAP, assume they will request your evidence files (step 31) and ask you to defend each reclassification. Verify that your documentation is complete, clear, and withstands that scrutiny. If there are any gaps in evidence (e.g., a user with incomplete SM20 logs), resolve them or exclude that user from your reclassification claim.

Phase 4 Completion Criteria: You have a formal consolidation submission package ready to send to SAP. The package includes the pre/post comparison report, the contractual analysis document, evidence files for all reclassifications, ghost user documentation, engine metric analysis, and a legal attestation. Phase 4 typically takes 1–2 weeks for final compilation and review.

Phase 5: SAP Engagement and Negotiation Checklist (items 36–40)

Phase 5 is the contract negotiation phase. You present your consolidation findings to SAP and negotiate revised licence terms based on your new, lower licence baseline. The timing of this phase relative to your contract renewal is critical: do it too early, and SAP will ignore it; do it too late, and you've lost negotiating leverage.

36

Decide on standalone submission vs renewal linkage. Decide whether to submit consolidation findings as a standalone claim now (12 months before renewal) or to link the consolidation claim directly to contract renewal negotiation (60 days before renewal). Standalone submission gives SAP time to respond; renewal linkage creates urgency. For most enterprises, renewal linkage (60 days before) is stronger because SAP knows you'll need a new agreement and they have more pressure to negotiate.
37

Identify SAP contract owner and escalation path. Know who your SAP account executive and licensing manager are. Escalate the consolidation claim above them to SAP's regional licensing director if the initial response is dismissive. Prepare an escalation path in advance so you're not scrambling when SAP pushes back.
38

Prepare opening consolidation position document. Write a crisp 2–3 page cover letter to SAP outlining: (a) your consolidation analysis overview, (b) the categories of licences you're consolidating (ghosts, Professional downgradestoLimited Professional, etc.), (c) your proposed cost reduction, (d) a brief summary of evidence (without overwhelming SAP with all the documentation yet), (e) your openness to discussion and validation. This letter frames the negotiation positively — you're not accusing SAP of mislicensing; you're presenting evidence-based consolidation.
39

Define minimum acceptable outcome before negotiations begin. Before you send anything to SAP, decide internally: what is the minimum consolidation savings you need to make the effort worthwhile? Is it 10% cost reduction? 15%? €500,000 in annual savings? If you're targeting 20% reduction but SAP will only concede 8%, what's your fallback? Decide this in advance so you're not negotiating on emotion during the conversation.
40

Engage independent SAP licensing advisor if claim exceeds €500K. If your consolidation claim is more than €500,000 in annual savings (or €2.5 million over a 5-year renewal), consider engaging an independent licensing advisor to support your negotiation. SAP will hire their own licensing experts to counter your claims; having a third-party advisor levels the field and increases your negotiation credibility. Budget €50,000–€100,000 for advisory support if this applies.

Phase 5 Completion Criteria: You have sent the consolidation submission to SAP with supporting documentation. You have scheduled a call with SAP to discuss the consolidation findings. You have prepared for counter-arguments and have your evidence files ready to defend specific reclassifications. Phase 5 typically spans 3–6 months (from initial submission through final agreement).

After the Checklist: What Comes Next

Once you've completed all 40 items and reached agreement with SAP, the consolidation moves into contract amendment and true-up phase. SAP will issue an amended Order Form reflecting the reduced licence baseline. You'll receive a credit for overpaid licences (either as a cash refund, a service credit against future payments, or a discount on the renewal). Document this amendment and the credit in your financial systems.

If you're planning RISE with SAP migration, ensure that the new, consolidated licence baseline is the input used to calculate your RISE subscription fees. Do not let SAP lock your RISE baseline against your pre-consolidation numbers — the whole point of pre-migration consolidation is to reduce the RISE baseline and lower your cloud costs.

Finally, consolidation doesn't end at contract amendment. Maintain your consolidated state going forward. Treat user classification discipline as an ongoing operational practice, not a one-time project. Conduct mini-consolidations annually during your contract review meetings with SAP. The more disciplined you are about user type classification in real-time, the less room SAP has to claim over-licensing during future audits.

Need help executing this checklist? Managing 40 action items across five phases is complex, especially if you're doing this for the first time. Our licensing team has executed consolidations for 40+ enterprises and can guide you through each phase, manage evidence collection, and handle SAP negotiation. Explore our License Optimisation service or contact us for a scope discussion.

FAQ

Can we skip Phase 2 and go straight to Phase 3 (technical execution)?

No. Phase 2 analysis is what makes Phase 3 defensible. If you execute user reclassifications without the transaction evidence from Phase 2, SAP will audit your changes and ask "why did you reclassify this user?" If you can't show SM20 transaction logs and contractual analysis, you have no defense and will be forced to revert the reclassifications. Always complete Phase 2 analysis before making technical changes.

How many users can we reclassify in a single batch?

Batch size depends on your operational tolerance and SAP's response. Start with batches of 50–100 users per week. Monitor system performance and user impact. After each batch, wait 1–2 weeks for operational feedback before proceeding to the next batch. This approach takes longer but is lower-risk and allows you to pause if issues arise. If you're confident in your analysis and have internal buy-in, you can accelerate to 200–300 users per week.

What happens if SAP challenges our ghost user elimination?

SAP may claim that eliminated accounts were "inactive but available for surge capacity" and therefore still require licences. Counter this by presenting SM20 logs (zero transaction activity), SM37 logs (zero batch jobs), and SU01 lock dates showing the account was locked before your consolidation. If the account is locked, it's not "available" — it's dormant. The burden is on SAP to prove the account was accessible and in use; zero activity logs are your defense.

Should we consolidate before or after a major SAP upgrade (S/4HANA migration)?

Consolidate before migration if possible. Post-migration, your system is unstable (new data structures, new user interfaces, new role models). Consolidation during or immediately post-migration creates too much operational noise. However, if your S/4HANA migration is imminent (within 3–4 months), it's better to defer consolidation to 90 days post-go-live when the system is stable, rather than rush a consolidation during the migration itself.

What if we discover data quality issues during Phase 1 (incomplete SM20 logs, SU01 records with gaps)?

Data quality issues are common, especially in older SAP systems. If SM20 logs are incomplete, you'll need to rely on alternative evidence: role assignments (PFCG), user profile codes (authorization objects), or business owner attestation of user purpose. If SU01 records have gaps, work with your SAP Basis team to restore historical records if possible. In some cases, you may have to exclude problematic user records from your reclassification claim rather than submit weak evidence. It's better to consolidate 80% of candidates with strong evidence than 100% with weak evidence and risk audit rejection.

👤

SAP Licensing Experts

An independent advisory firm specializing in enterprise SAP licensing strategy, contract negotiation, and audit defense. 25+ years of expertise helping buyers protect their position against SAP's enforcement tactics.

Stay Updated on SAP Licensing Strategy

Get expert insights on licence consolidation, contract negotiation, and audit defence delivered to your inbox monthly.