Role-based user reclassification is the most reliable single lever for reducing the SAP named-user bill. The premise is straightforward: most users in a typical SAP estate are licensed to a tier broader than their actual authorisation pattern requires. The cause is usually historical — the implementation team assigned tiers conservatively, the role catalogue evolved without a corresponding licensing review, the joiner workflow defaulted to the highest tier "to avoid friction." The cumulative effect is a Professional population that is twenty to forty per cent larger than the business need.
This article sets out the role-based reclassification workflow in operational detail: how to extract the authorisation footprint, how to map it back to the contract definitions, where the common reclassification opportunities sit, and how to defend the reclassification position when SAP challenges it.
Why role-based reclassification works
The SAP commercial framework prices named users by authorisation tier, not by role title or business function. The contractual definitions of each tier (Professional, Functional, Limited Professional, Employee Self-Service) reference the transactions and authorisation objects a user can execute, not the customer's HR taxonomy. That asymmetry is the source of the opportunity: the customer-side organisation thinks of users in HR terms, while the licensing exposure is in authorisation terms.
The reclassification exercise reconnects the two. The customer maps each role (and each composite role, and each commonly-used authorisation pattern) to the contractual user type that the authorisations actually require. The mapping reveals two populations: users whose tier is correctly aligned to their authorisation footprint, and users whose tier is broader than necessary. The second population is the reclassification opportunity.
The three reclassification opportunities most often missed
1. Professional users with Functional-grade authorisation footprints
The largest single category. Users whose authorisation footprint is constrained to a specific business function but who have been licensed as Professional, typically because the original role design did not consider the contractual boundary. The reclassification from Professional to Functional moves a single seat by $2,000 to $4,000 on the SAP price list. On a population of 200 misclassified seats, the recovery is $400k to $800k per year. See our deeper analysis in the Professional vs Functional vs Limited Professional tier comparison.
2. Functional users with Limited Professional-grade authorisation footprints
The second category. Users whose role is bounded entirely to read-only or self-service activities but who have been licensed as Functional. The reclassification moves a single seat by $1,400 to $2,000. The population is typically smaller than the Professional-to-Functional opportunity but still material in most estates.
3. Multiple-tier assignments for the same human
The hidden category. Users with multiple accounts across the landscape who are double-counted at the highest tier observed across all accounts. The reclassification opportunity is the consolidation of the multiple accounts to a single tier that matches the authorisation footprint, not the sum of all the assigned tiers. See our analysis of the eight named-user audit risk areas for the audit dimension of this category.
The reclassification workflow
Step 1 — Extract the authorisation footprint
Pull the SUIM USERS_BY_AUTHORIZATION extract or the equivalent from a role-mining tool. The extract should list every active user, every assigned role, and every authorisation object that the role contains. The extract is the evidence base for the reclassification.
Step 2 — Map authorisations to the contractual tier
For each authorisation object, identify whether it constitutes a Professional, Functional, Limited Professional, or Employee Self-Service action under the customer's contract. The mapping is non-trivial — the contractual definitions reference business functions rather than authorisation objects, and the mapping requires judgement — but the framework is repeatable once established.
Step 3 — Identify the over-tiered population
For each user, compare the assigned tier to the maximum tier required by their authorisation footprint. Users whose assigned tier exceeds the required tier are reclassification candidates. The output is a structured reclassification list with the proposed new tier, the supporting authorisation evidence, and the estimated annual saving.
Step 4 — Validate against transaction usage
Authorisation footprint is the necessary condition for reclassification; transaction usage is the sufficient condition. A user with the authorisation to execute a Professional transaction but no usage history is a defensible reclassification target. A user with active usage of the relevant transactions is not. The usage extract is the defence against any subsequent SAP challenge.
Step 5 — Execute the reclassification
The reclassification itself is a systems exercise — updating the user-type assignment in the SAP user master — combined with a procedural exercise on the customer side: documenting the change, updating the joiner-mover-leaver workflow to prevent regression, and capturing the saving against the licence baseline. Without the procedural exercise, the over-tiering returns within twelve months.
The defensibility question
The single most common SAP response to a customer-driven reclassification is to challenge the new tier on the grounds that the authorisation footprint is broader than the customer's mapping recognises. The defence has two components.
The first is the documented mapping itself. A written policy that explains how each authorisation object maps to each contractual tier, with worked examples, is a much stronger defence than an ad-hoc reclassification. The policy should reference the specific contractual definitions in use, not generic price-list descriptions.
The second is the transaction usage evidence. A user whose authorisations could in principle execute a Professional transaction but who has never done so over the measurement period is a much harder reclassification challenge than one whose actions trigger the role-content boundary. The usage extract is the customer's evidence; the auditor will produce their own version, and the defence is to produce yours first. The USMM and LAW advisory service covers the full mechanics.
The post-reclassification regression problem
Reclassification gains erode unless the joiner-mover-leaver workflow is updated to prevent regression. The most common regression pattern is the joiner workflow that defaults to Professional for any new role above a certain seniority threshold. New hires enter at the high tier, the population creeps back upward, and within twelve months a meaningful fraction of the original reclassification has been undone.
The prevention is procedural: update the joiner workflow to require an explicit authorisation review for every new user assignment, with the default set to the lowest tier that matches the role's authorisation footprint. The same logic applies to internal movers — the move workflow should re-evaluate the licensing tier, not carry the prior tier forward.
The interaction with USMM and the audit cycle
The reclassification exercise has two timing windows. The first is ahead of the next USMM submission; reclassification completed before the measurement window reduces the count that SAP sees. The second is in the early stages of an active audit; reclassification completed during the auditor's analysis window can change the finding before it is formalised.
The pre-USMM window is the preferable one. Reclassification under the pressure of an active audit is harder to execute cleanly, and the auditor's natural response is to challenge the reclassification timing as opportunistic. A reclassification that is part of a documented annual licence-hygiene cycle is a much stronger defence. See our analysis of the pre-USMM employee category cleanup for the broader timing framework, and the USMM and LAW topic page for the measurement mechanics.
The renewal-cycle conversation
Reclassification gains should be captured in the next contract renewal. Without an explicit baseline adjustment at renewal, the customer continues to pay the prior tier mix even after the active reclassification. The renewal conversation should propose a new user-mix baseline based on the post-reclassification position, with grandfathering language that protects the new mix for the contract term.
The leverage in the renewal conversation depends on the customer's preparation. A documented reclassification with usage evidence and a clean transition plan is a much stronger negotiating position than an undocumented assertion. The SAP contract negotiation service covers the full renewal framework, and the SAP Audit Defence Playbook includes a chapter on the reclassification methodology with sample policy language.
The three governance disciplines that hold reclassification gains
Annual authorisation review: a documented review of the authorisation footprint of every active user, at least once per year, with the licensing tier confirmed or adjusted based on the current footprint.
Quarterly joiner-mover audit: a sample-based audit of the joiner and internal-mover workflows, confirming that the default tier was set correctly and any deviations were approved.
Renewal-cycle baseline reset: at every contract renewal, the user-mix baseline should be reset to the current post-reclassification position, not the prior baseline. Customers who maintain these three disciplines typically hold their reclassification gains across multiple renewal cycles and see audit findings concentrated in the engine and indirect access dimensions rather than the named-user dimension. See the worked example in our global retailer reclassification case file.