Theory is useful. Implementation wins contracts. This guide takes you step-by-step through a real reclassification project. You'll learn the exact process we've executed dozens of times across Fortune 500 enterprises—how to audit your current state, identify cost reduction opportunities, build defensible evidence, and implement changes without triggering alarm bells in SAP's commercial organization.
In This Guide
Step 1: Collect Your Baseline Data
Before you touch anything, you need a complete picture of your current state. This takes two weeks. Don't skip it.
Pull these documents and spreadsheets: (1) Your current SAP license inventory—every license, user ID, current classification, purchased date. (2) Your most recent Order Form and SOWs showing the licensed scope for each user type. (3) Your internal org chart and job title hierarchy—we need to understand your actual roles. (4) Last 12 months of HR adds/removes—who joined, who left. (5) Security role assignments from SAP—use SUIM (System User Information and Maintenance) to export a full list of user IDs and their security role assignments.
Create a master spreadsheet: User ID, Current License Type, Job Title, Department, Security Roles Assigned, Date Hired, Manager Name. This is your audit trail. Everything else branches from here.
Need Help Structuring Your Baseline?
Our license optimization team has built data collection frameworks that extract all necessary baseline information in 1-2 weeks. We handle the data hygiene and create the audit framework.
Step 2: Extract and Analyze USMM Reports
USMM data is your evidentiary gold mine. You need 12 months of it. USMM shows every transaction executed by every user. Use it to profile actual usage patterns.
Request from SAP BASIS or a systems integrator: (1) 12-month USMM export (monthly snapshots, not just the latest). (2) Effective License Position (ELP) report showing SAP's determination of required license type by user. (3) Transaction detail logs showing which modules/transactions each user actually touches.
Create analysis buckets: For each user, count the modules they accessed. Did they touch 2 modules or 8? For each user, count unique transaction types. Did they execute 20 distinct transactions or 200? For each user, identify the modules where they spent 80% of activity. Those are the "core" modules that define their actual scope.
Use this analysis to identify candidates for reclassification. Anyone accessing 2–3 modules repeatedly should be considered for Limited Professional (assuming your Order Form permits it). Anyone only viewing reports should move to Functional. Anyone touching only one module should be Functional or, better, a role-specific license.
Step 3: Build Your Reclassification Cases
For each user you want to reclassify, create a one-page case file documenting:
- User ID and Name
- Current License Type – What they're licensed as today
- Proposed License Type – What they should be licensed as
- Actual Job Function – Their real role based on job title and manager confirmation
- USMM Evidence – 12-month transaction summary: modules accessed, core transactions, frequency
- Scope Definition – Which modules and transaction families should their new license cover
- Financial Impact – Annual cost difference between current and proposed
- Risk Level – Low, Medium, or High, based on how tight the fit is
Prioritize by impact and risk. Start with high-impact, low-risk cases (e.g., users with clear single-module scope). Avoid high-risk cases until you've built credibility with auditors.
Step 4: Document Scope Definitions
This is where auditors will attack you hardest. You need ironclad scope definitions. Use your Order Form as the template. If your Order Form says "Limited Professional – FI/CO, read-only HR, no SD access," use that exact language.
For each proposed license classification, write or update a scope definition showing:
- Which SAP modules are accessible
- Which transactions are permitted (list the key ones)
- Any transaction restrictions (e.g., "May not create journal entries," "May only view, not modify")
- Any time-based restrictions if applicable
Have the user's manager sign off on this scope. Get it in writing. This manager sign-off is your strongest defense in an audit. It proves the scope was intentional, not accidental.
Critical Evidence Checklist
- 12+ months of USMM transaction logs (monthly snapshots)
- Security role master data showing access assignment date
- Order Form and SOW documents defining each license type scope
- Manager sign-off on proposed user scopes
- Job title and function documentation
- System access request forms (SAP access request tickets)
Step 5: Get Stakeholder Buy-In
Don't surprise anyone. This fails when IT, the user's manager, or finance get blindsided. Lock in approval first.
Meet with: (1) The SAP CoE or systems team—they must be confident reclassifications won't break system access. (2) Finance—they want to know cost savings impact. (3) Each user's manager—they must confirm scope and accept the new classification. (4) Compliance/Legal, if you have a strong audit compliance function.
The conversations are simple: "User X is currently licensed as Professional but only accesses FI and CO modules. We're proposing Limited Professional for FI/CO scope, which saves €1,800/year. You retain full access to all needed transactions. Your manager has approved. Any concerns?"
Build momentum by starting with finance. Finance loves cost reduction. Once finance is onboard, other teams follow.
Step 6: Implement and Monitor
Once stakeholders approve, update your SAP user master: (1) Change the license classification in the system. (2) Update security roles to match the new scope. (3) Record the change date and reason in your master audit log. (4) Notify the user they've been reclassified and what their new scope is.
Over the following 60 days, monitor actively. Set SAP alerts to notify you if a reclassified user hits a blocked transaction. Check weekly. If someone blocked a transaction, either (a) their scope was mis-defined and needs adjustment, or (b) there's a legitimate business need to expand their access. Adjust accordingly.
After 60 days with no blocked transactions or escalations, mark that reclassification as successful. Document it as a "proven reclassification" for audit defense.
Step 7: Contract Amendment Strategy
If you're reducing your total Named User count, you should negotiate a contract credit. Here's how:
Scenario 1: You reclassified 50 users from Professional to Limited Professional. You've eliminated 50 "Professional" seat requirements. You could request a contract credit for 50 Professional licenses (€150K–250K potential savings). SAP will negotiate. They may not give you a full credit, but you've opened a conversation.
Scenario 2: You found 100 users misclassified as Limited Professional who should be Functional. Same approach—request a credit for 100 downgraded seats.
Time the amendment conversation strategically. Don't ask for a credit immediately after reclassification. Wait 90 days, collect proof that the reclassified users are operating normally, then approach SAP with evidence: "We've reclassified 50 users to Limited Professional scope. They've been stable for 90 days with zero exceptions. We'd like to amend our contract to reflect these optimizations and discuss a credit."
SAP will say no. Then say: "We understand. What if we formalized these reclassifications in an amendment—no credit required, just legal documentation?" SAP often agrees. Why? Because documented reclassifications are easier to defend in an audit than undocumented ones. You're offering SAP audit cover.