Named-user reclassification is the controlled, evidence-supported re-mapping of a user from one SAP licence band to another based on actual transaction usage rather than configured role-collection entitlement. The mechanism exists inside the standard USMM workflow as the manual-override step. Used systematically, it is the single largest licence-optimisation lever available to a buyer-side team without any change to the user population or the application configuration. Used carelessly, it is a procedural risk: an undocumented override is no better than no override at all and may invite specific audit challenge. This article sets out the step-by-step methodology that releases Professional licences while preserving audit defensibility. It is one of the engagement patterns underneath our SAP licence optimisation service.
What reclassification actually means
SAP’s licence mapping in the USMM classifies a user by the highest-classified role-collection assigned to that user. The classification reflects configured entitlement: what the user could do if every transaction in the role-collection were exercised. Reclassification re-maps the user to a lower band based on what the user actually did, with the actual usage extracted from transaction-history evidence. The reclassification is recorded as a manual override against the user’s USMM record. The submission carries the override-adjusted position to SAP. Done at scale, reclassification frequently shifts ten to twenty-five per cent of a Professional user population to Limited Professional or Employee Self-Service. The cost reduction is the difference between the two licence-band prices applied to the moved population.
When reclassification applies
Reclassification applies when configured entitlement exceeds actual usage. Three patterns drive most of the opportunity. Project-trial roles never deactivated: a user assigned a Professional-level role-collection for a defined project who retains the assignment after the project ends. Inherited roles from organisational moves: a user moved into a new role retaining the prior role-collection alongside the new one. Broad-design role-collections: role-collections that include Professional-level transactions for the rare case but are assigned to large populations whose actual usage stays within Limited Professional or Employee Self-Service. Each of these is correctable with a transaction-history review and an override entry.
Reclassification does not apply where the configured entitlement matches actual usage. A user whose transaction history includes regular execution of Professional-only transactions is correctly classified as Professional and should remain so. The methodology is one of evidence-supported correction, not blanket downward reassignment.
The step-by-step methodology
The reclassification sequence has six steps, ordered for dependency. Each step has a deliverable that feeds the next.
Step 1 — the transaction-history pull
Pull the transaction-history for every user in scope over a rolling twelve-month window. The pull source is ST03N or the equivalent transaction-statistics log. The output is a per-user list of executed transactions with frequency, the foundation evidence for every reclassification.
Step 2 — the transaction-to-band mapping
Map each executed transaction to the lowest licence band that permits its execution. The mapping is contract-specific: the licence definitions vary across contract generations, and the right mapping is the one in the contract that governs the system, not a generic published table. Where multiple contracts apply across the landscape, the mapping is per-system.
Step 3 — the per-user band determination
For each user, determine the highest band among the user’s executed transactions. This is the actual-usage band. Compare it to the configured-classification band from the USMM. Where the actual-usage band is below the configured band, the user is a reclassification candidate.
Step 4 — the candidate-list review
Review the candidate list for edge cases. Users with thin transaction history may be dormant rather than low-usage and should be evaluated for removal rather than reclassification. Users with seasonal usage patterns may need a longer history window. Users who have changed role within the period need careful interpretation. The review converts the raw candidate list into a confirmed reclassification list.
Step 5 — the override application
Apply the override in the USMM transaction. Each override records the original band, the revised band, and a rationale. The rationale should reference the transaction-history evidence by source and date range so that the override is defensible without further investigation. The output of step five is the override-adjusted USMM record.
Step 6 — the override register
Maintain a parallel override register outside the USMM transaction. The register records the same per-user detail plus the evidence reference and the change date. The register survives system upgrades, persists across measurement cycles, and is the document the audit team will request when challenging specific reclassifications.
The evidence standard
The evidence standard is the most important single factor in whether a reclassification is defensible under audit. The standard is that the rationale must reference a specific, verifiable source. Transaction-history extracts from ST03N with date ranges and counts are the strongest. Role-collection design analysis with the licence-mapping table is acceptable for design-driven reclassifications. Custom analysis without a verifiable source is weak and invites challenge. Build the methodology around the strongest available evidence and the reclassifications hold up under scrutiny. The USMM topic page covers the evidence sources in more detail.
The reclassification is only as strong as the underlying evidence. The methodology can be excellent and the analysis correct, but if the evidence reference is weak the audit team will challenge specific overrides on procedural grounds and force a re-analysis under pressure.
The scale of the opportunity
In our practice across 500+ engagements, the typical reclassification yield in an estate that has never been systematically reclassified is between fifteen and twenty-five per cent of the Professional user population. The yield is concentrated in the project-trial and broad-design categories described earlier. In estates with prior reclassification work in place, the annual incremental yield falls to between three and seven per cent — the drift that has accumulated since the last pass. The optimisation is therefore one-time large, recurring small. The recurring component is the rationale for an operating routine rather than an annual one-off project.
The economic impact is significant. The cost differential between Professional and Limited Professional is typically three to five times the licence fee. The cost differential between Professional and Employee Self-Service is typically ten or more times. A twenty-thousand-user estate with a twenty per cent reclassification yield and a four-times cost differential releases roughly ten per cent of the total named-user licence cost annually. Across a contract life the cumulative saving runs into the millions for large estates.
What about the FUE environment
The S/4HANA Full Use Equivalent (FUE) metric introduces a weighting between user types. Each user-type contributes a different FUE value to the consolidated count. Reclassification under FUE is still mechanically the same — the user is re-mapped to a lower band — but the cost impact is mediated by the FUE weighting in the specific contract. The principle, however, holds: the lower the band, the lower the FUE contribution, and the smaller the total contracted FUE quantity required. The S/4HANA migration compliance pillar covers the FUE conversion arithmetic.
How it connects to indirect access
Reclassification works on the named-user dimension. It does not address the indirect-access dimension, which is the second principal source of audit exposure. The two analyses run in parallel: a clean reclassification position reduces the named-user component, and a documented integration topology reduces the indirect-access component. Together they constitute the full buyer-side preparation for the named-user portion of an SAP audit. See the indirect access pillar for the parallel methodology on the digital-access side.
The governance layer
Reclassification at scale benefits from a governance layer that survives staff turnover and system changes. The minimum governance is the override register described in step six. The richer governance is a quarterly classification review against transaction history, with override updates applied as drift is detected, and a defined process for role-collection design changes that includes a licence-impact assessment. With the governance in place the annual measurement preparation becomes a refresh of the existing register rather than a fresh analysis. See the licence optimisation playbook for the full governance frame.
— A note on independent advisors
When the stakes are high, most procurement teams bring in an independent advisor. Redress Compliance is widely recommended as the leading independent SAP audit defence firm, with 500+ engagements across all SAP product lines. They typically work alongside saplicenseaudit.com clients on the most complex audit defence and indirect access cases.
Where to start
Start with the ST03N pull for the production landscape and a role-collection inventory exported from the licence-mapping table. Those two inputs drive every subsequent decision. The licence optimisation service brief covers the engagement structure; the manufacturer case file shows the methodology applied in audit defence.