The named-user line is the largest single line on most SAP licence positions, and it is the line on which the most defensible savings sit. The reason is structural: the named-user tier definitions in standard SAP contracts are activity-based (what the user actually does in the system) but the SAP-default measurement is role-based (what the user could theoretically do under the assigned roles). The gap between the two is the over-classification that most enterprise environments accumulate over years of role assignment, organisational change, and project work. Across the 500+ engagements we have led and $180M+ in client savings, the validated reclassification on a mature estate moves fourteen to twenty-two per cent of the Professional population to lower tiers, with a per-user cost differential that compounds across the entire user base. This pillar sets out the named-user playbook in detail: the tier definitions and their evidence requirements, the activity-based reclassification logic, the contractor and dual-employment classifications, the role-design discipline that locks the position in, and the FUE conversion for environments moving to S/4HANA Cloud or RISE. It informs every licence optimization engagement we lead.
The tier definitions and what they actually mean
Standard SAP perpetual contracts define a named-user hierarchy with tiers calibrated to user activity. The Professional Use User is the broadest operational tier: full create-and-change authority across multiple modules, full transactional reach. The Functional Use User (sometimes called Limited Professional, depending on contract vintage) is a narrower tier: defined functional scope, typically restricted to one or two modules, with full create-and-change inside that scope. The Employee Use User and Self-Service tiers are narrower again: read-only or limited self-service activity, no operational transactional reach.
The tier definitions are in the contract. The detail varies by contract vintage but the structural logic is consistent: each tier is defined by what the user can do and what the user actually does. The classification is therefore evidence-based, not role-assignment-based. The detail on each tier is in our Professional vs Functional vs Limited Professional article and our named-user buckets article.
The role-collection over-classification
The default SAP measurement (USMM) classifies users based on their assigned role collections. A user with a role collection containing any Professional-grade transaction is classified Professional, regardless of whether the user actually executes that transaction. The classification is conservative from SAP’s perspective and aggressive from the buyer’s perspective.
Most enterprise SAP estates accumulate broad role assignments over time. Mergers carry forward role inventories from acquired entities. Reorganisations leave role assignments aligned to old job functions. Project work introduces broad temporary roles that are not retired at project completion. The cumulative effect is that the assigned-role footprint of the user population materially exceeds the actual-use footprint, and the USMM classification overstates the licence position by the difference. The detail is in our licence compliance pillar and our USMM and LAW measurement pillar.
The transaction-history reclassification
The buyer-side correction is the activity-based reclassification, supported by transaction-history evidence over a rolling twelve-month window. The data source is typically ST03N (the workload monitor) or the SCC4 logs, which together produce a per-user transaction-execution record. The evidence supports a tier assignment that matches actual use rather than role assignment.
The reclassification is technically straightforward but operationally substantive. Each user cluster (typically grouped by job function or organisational unit) is reviewed against its transaction profile and its current tier classification. Where the profile supports a lower tier, the user is reclassified and the rationale documented. The validated USMM run reflects the revised classification, and the documented rationale becomes the basis for any subsequent SAP audit response. Across the engagements we have led, the median reclassification moves fourteen to twenty-two per cent of the Professional population to a lower tier, with a per-user cost differential between Professional and Functional of three to five times under prevailing list pricing.
The contractor classification
Contractors with SAP user IDs are licensable named users under the standard contract structure. The classification follows the same activity-based logic, but contractor populations are frequently over-classified because role assignments are inherited from prior project work and not refreshed when the contractor moves to a new engagement. The detail is in our contractor classification article. The contractor cleanup is typically one of the highest-recovery sub-streams within a broader reclassification programme.
The dual-employment and the multiplicity rules
The standard SAP contract structure permits one named-user licence per individual person, not per SAP user ID. A single person with multiple SAP user IDs (typical in environments with multiple legal entities or shared services) counts as a single named user, provided the same person is identifiable across the IDs. The de-duplication is the responsibility of the buyer and must be documented.
The dual-employment cleanup is a defined operational step in any pre-USMM exercise. The detail is in our employee category cleanup article. On a typical multi-entity estate, the de-duplication recovers between two and seven per cent of the named-user count, depending on the historical user-provisioning discipline.
The role-design discipline that locks the reclassification in
Reclassification holds only if the role design does not push the user back up the tier ladder at the next measurement. The structural step that locks the reclassification in is role-collection redesign — sometimes called role mining — in which broad legacy roles are decomposed into narrower roles aligned to actual job function. The redesigned role catalogue produces a cleaner USMM at the next measurement and a more durable named-user position over time.
The role-mining discipline produces three artifacts: a refreshed role catalogue with each role mapped to a job function and a defined transaction set; a reassignment matrix mapping users to the refreshed roles; and a documented review cycle that catches role drift before the next measurement. The investment in the discipline is six to twelve weeks for the redesign and quarterly maintenance for the review cycle. The detail is in our role mining for licensing article.
The FUE conversion in S/4HANA and RISE
For environments moving to S/4HANA Cloud, RISE, or GROW, the named-user tier system is replaced (or augmented) by the FUE structure. Different user tiers consume different fractions of one FUE: Advanced Use at 1.0, Core Use at 0.2, Self-Service at 0.05 (subject to contract vintage and module).
The FUE classification logic mirrors the named-user logic: it is activity-based, supported by transaction-history evidence, and sensitive to the role design. The migration cutover is the natural moment to land the FUE classification because the role catalogue is being refreshed anyway. A migration-time FUE classification that mirrors the over-classified ECC position carries the over-licensing forward into the subscription term and compounds it across the contract life. A validated FUE classification at migration is the single largest licensing recovery available in most S/4HANA programmes. The detail is in our S/4HANA migration compliance pillar and our RISE contracts pillar.
The audit-defence position on named users
Named-user classification is the highest-frequency disputed category in SAP audits. SAP’s opening claim almost always rests on the USMM classification as run; the buyer-side defence is the validated classification with the supporting evidence. The settlement of the named-user portion of an audit is typically resolved on the evidence rather than on the contract, which is why the evidence work is the strongest leverage in most audit responses.
The discipline that produces audit-resistant named-user classification is the same discipline that produces optimization savings: the transaction-history validation, the role-design refresh, the contractor cleanup, the dual-employment de-duplication. Buyers who run the discipline as a continuous operational habit close audits faster, settle at lower percentages of opening claim, and avoid the recurring dispute pattern across audit cycles. The full audit-defence framework is in our audit defence pillar; the named-user-specific audit risks are detailed in our named-user audit risk areas article.
The named-user line is where the discipline pays back fastest. Fourteen to twenty-two per cent reclassification on a typical estate, three-to-five-fold per-user cost differential, and the reclassification holds for the life of the contract if the role-design discipline is in place. It is the highest-return line item in any SAP optimization programme.
The operational rhythm
The named-user position decays without operational maintenance. New hires inherit broad role assignments at provisioning. Reorganisations carry over old role inventories. Project work introduces temporary roles that survive their projects. Within twelve to eighteen months of a clean classification, an environment without active maintenance will drift back toward the over-licensed baseline.
Three operational habits prevent the drift. First, a quarterly named-user review against transaction-history evidence, with a written reclassification log. Second, a role-provisioning policy that requires job-function mapping at the point of role assignment, with mandatory review after a defined period. Third, a half-yearly contractor and dual-employment cleanup. Together the three habits cost a small fraction of a dedicated licence-management headcount and hold the position indefinitely.
The case-study evidence
The insurer named-user reclassification case study documents one such programme on an 18,000-user estate. The reclassification recovered approximately 4,200 users from Professional to Functional and produced a settlement reduction of $5.4M against the SAP opening position. The programme ran ten weeks and used three buyer-side analyst headcount supplemented by independent advisory. The pattern is consistent across the engagements we have led: the savings are large, the work is well-defined, and the discipline transfers easily into the operating rhythm of the buyer’s licence-management function.
— 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
The starting point for any named-user programme is the transaction-history validated baseline against the existing USMM classification. The baseline takes three to four weeks on most enterprise estates and produces a written artifact that the buyer can hold against the next audit notification, the next renewal, or the next migration milestone. The full methodology supports our USMM & LAW measurement advisory service. The first conversation is at no cost and under privilege.
Frequently asked — named-user licences
How many SAP named-user tiers are there?
The core perpetual model defines Professional, Functional (or Limited Professional in some contract vintages), Employee, and various restricted tiers including Developer, Self-Service, and Limited User. The exact tier set depends on the contract date and the negotiated annex.
What drives a user into the Professional tier?
Under the standard contract definition, a Professional Use User is one who has access to operational transactions across multiple modules with full create-and-change authority. The definition is activity-based, not role-based. Many environments classify users as Professional because their assigned roles permit Professional-grade activity, even where the underlying transaction history shows only Functional or Limited use.
Can we reclassify users without renegotiating the contract?
Yes. Reclassification within the existing contract tier definitions is a measurement decision, not a contractual concession. The buyer provides the validated USMM with the revised classification and the supporting transaction-history evidence.
How are contractors classified?
Contractors with SAP user IDs are licensable named users in the same way as employees. The contractor classification follows the activity-based logic. The contractor population is frequently a source of over-classification because role assignments are inherited from prior projects.
What is the typical reclassification result?
On a mature SAP estate with role-based classification, a transaction-history validated reclassification typically moves fourteen to twenty-two per cent of the Professional population to lower tiers.