SAP License Audits Contact Us
Home · Journal · USMM & LAW · Classification rules

How USMM decides your license type

Classification is not an opinion. It is a deterministic mapping from role-collection assignment to license band, executed against rules SAP has held more or less constant for fifteen years. Understanding the mapping is the prerequisite for every reclassification challenge.

Published 2026-05-23By The SAPLicenseAudits Editorial Desk9 min readUSMM & LAW cluster
Open ledger with classification rules and a magnifying glass

SAP user classification is the gateway through which every measurement-driven licence cost passes. The USMM transaction reads the role-collection assignment on each user master, applies a deterministic mapping table, and emits a per-user licence-type recommendation. The mapping is documented, the inputs are inspectable, and the output is reproducible. Yet the recommended classification accepted by most buyers without challenge contains, in our 500+ engagements, an over-classification rate of between twelve and twenty-eight per cent. This article sets out how the classification logic actually works, the seven role-collection patterns that drive systematic over-classification, and the evidence base that supports a downward reclassification at audit. The full reclassification methodology is covered in our license optimisation service.

The mapping table in plain terms

USMM does not measure what a user did. It measures what a user is allowed to do. The mapping table reads the role-collection authorisation profile, identifies the highest-banded authorisation in the profile, and assigns the corresponding licence type. A user with a role-collection that permits SAP_BC_BASIS_ADMIN is classified Professional regardless of whether the user has ever executed an administration transaction. A user with a role-collection that permits FI_AP_DISPLAY but no posting authority is classified Limited Professional. The classification follows the entitlement, not the behaviour.

The implication is the entire foundation of buyer-side reclassification work. If actual usage falls below the entitlement band, the entitlement band can be reduced, and the licence type follows the entitlement band down. The reclassification engine is the gap between configured entitlement and actual usage, evidenced from transaction history.

The seven over-classification patterns

Across our practice the same seven patterns produce the bulk of unsupportable classifications. They recur across industries, estate sizes, and SAP product generations.

Pattern one — legacy broad-design role-collections

Role-collections defined in the original implementation typically aggregate every authorisation the original business analyst could imagine the role might ever need. Ten years on, the role-collection retains the broad design, and every user assigned to it inherits the Professional-banded authorisation embedded in it. Reclassification requires a role-collection split, separating the rarely-used Professional-banded authorisations from the routine working set.

Pattern two — inheritance across organisational moves

A user who is promoted, transferred, or rotated typically receives the new role-collection without removal of the previous role-collection. Authorisations accumulate. The user ends with an authorisation profile that no business function actually requires but that classifies them Professional under USMM. Periodic role-collection cleanup is the corrective.

Pattern three — project trial assignments never deactivated

Project work, training exercises, and ad-hoc data investigations frequently produce temporary role-collection assignments that are never removed. The user’s nominal job is Limited Professional, the temporary assignment was Professional, and the residual entitlement determines the classification. The override register is the principal documentation route for this pattern.

Pattern four — service accounts assigned human classifications

Technical service accounts used by batch processes, interface jobs, or RFC connections are often assigned classifications intended for human users. USMM counts them. Reclassification to System User or RFC User is straightforward where the authorisation profile supports it, but each account requires individual evidence.

Pattern five — dormant Professional users

Users who have not logged in for ninety days, who have departed the organisation, or who have been replaced by an automated process frequently remain in the user master with their pre-departure classification. USMM counts them. Dormant-user cleanup is the single highest-yield reclassification activity in most estates. The license optimisation pillar covers the procedural detail.

Pattern six — double-counted users across systems

A user present in two systems is counted twice by USMM unless the LAW consolidation correctly identifies the user as the same person. LAW matching depends on the consistency of the user-master identifier across systems. Inconsistent identifiers produce duplicate counts. Reconciliation is the corrective.

Pattern seven — ESS users misclassified above the ESS band

Employee Self-Service users are intended to perform a narrow set of self-service transactions. Role-collection bloat regularly pushes these users into Limited Professional or Professional bands. The ESS band is the most under-utilised licence type in most estates and the most consequential reclassification target.

Across the seven patterns the recurring observation is that reclassification is largely cleanup. The audit defence work is the documentation of the cleanup, not the cleanup itself.

The evidence base for reclassification

Every downward reclassification must be supported by evidence. The audit team will challenge unsupported reclassifications on procedural grounds before they engage on substance. The acceptable evidence is transaction-history data extracted from ST03N or equivalent, covering a rolling twelve-month window, demonstrating that the user’s actual transaction usage falls within the band of the reclassified licence type. The evidence reference is recorded in the override register against the specific user identifier, and the audit conversation moves directly to the substance of the reclassification rather than to the methodology.

Estates without a transaction-history pull cannot defend a reclassification at audit. The pull is the gating activity for the entire reclassification programme. See the USMM run preparation playbook for the procedural sequence and the USMM topic page for the technical data sources.

What FUE changes

The S/4HANA Full Use Equivalent (FUE) model layers a weighting matrix on top of the classification. The same user classified Professional consumes one FUE, classified Functional consumes a fraction of an FUE, classified Productivity consumes a smaller fraction still. The reclassification therefore translates into FUE quantity directly, and the FUE quantity translates into renewal-period subscription cost. The reclassification arithmetic that matters in the S/4HANA contract is the FUE delta, not the user-count delta. See the S/4HANA migration compliance pillar for the FUE mechanics in detail.

The auditor rebuttal sequence

SAP audit teams have a consistent rebuttal sequence against reclassification claims. They first challenge the evidence base — whether the transaction-history pull is complete, whether the rolling window is representative, whether the data source is verifiable. They next challenge the methodology — whether the reclassification rules applied are consistent with the contractual licence definitions. They finally engage on specific users — whether each named reclassification is supported by the named evidence. A reclassification programme that anticipates each stage of the sequence and prepares the response is approximately seventy per cent more efficient through audit than one that responds reactively. See the manufacturing reclassification case file for the sequence in practice.

What we see in the field

The estates that hold the cleanest baseline are those that treat reclassification as a quarterly cadence rather than as an annual measurement-window activity. The quarterly cadence catches the seven patterns before they accumulate, holds the override register current, and reduces the formal measurement preparation to a refresh exercise. Estates without the cadence carry an inflated baseline into every measurement window and produce inflated submissions that drive audit claims that take months to dismantle. The USMM validation playbook sets out the cadence template.

— 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

If a USMM submission is approaching and the classification has not been reviewed against transaction-history evidence, the reclassification work is the highest-yield preparation activity available. Our USMM and LAW advisory service brief covers the typical timeline.

An audit notification is not an invoice.

It is the opening position of a negotiation. Speak with a specialist before responding. The first conversation is at no cost and under privilege.

Contact Us →
— Subscribe

SAP Audit Alerts · The weekly briefing

Every Wednesday. Field reports from active matters, decoded SAP communications, and what to look for in the next audit cycle. Work email only.