SAP named user licensing assigns every human a license type, and the price gap between types is large: a Professional user lists near $3,800, a Limited Professional roughly half that, and an Employee user under $400. The same person can fall into any of these depending on what their role allows, and SAP measures by entitlement rather than activity. That makes classification the single largest controllable cost in an on-premise SAP estate, because moving users to the correct lower type removes real license demand without removing any work the business actually does.
The named user model predates the cloud FUE metric and still governs every ECC and on-premise S/4HANA agreement. Each named user license is consumed by a single, identified person, and that person must hold the appropriate type for everything they are authorized to do across the estate. The rules are precise, the defaults are expensive, and the field that records the type is the one SAP reads at audit. Getting that field right, for thousands of users, is the work.
The named user types and prices
SAP publishes several named user types, and three account for the bulk of any estate. The list prices below are representative reference figures; realized prices reflect discount, and the type ratio is what most affects the total.
| User type | Indicative list | Permitted activity |
|---|---|---|
| Professional User | ~$3,800 | Full operational and administrative use across modules |
| Limited Professional User | ~$1,900 | Operational use within a delimited role scope |
| Employee User | ~$380 | Self-service: time, leave, expenses, own data |
| Employee Self-Service (ESS) | Low, bundled | Read and submit own HR and travel data only |
| Developer User | ~$3,800 | ABAP development and system configuration |
The economics are stark. A 5,000-user estate licensed entirely as Professional lists near $19M; the same estate correctly split into a realistic mix of types can fall by half or more. The cloud equivalent of this exercise, where these types fold into a blended count, is covered in our SAP FUE counting guide, and the two share the same classification logic.
How SAP classifies a user
The governing rule is that a user must hold the highest type their authorizations permit, regardless of how often they exercise the higher capability. A warehouse operative who can also approve a purchase requisition is a Professional or Limited Professional user, not an Employee user, because the approval authorization exists in their role. This is why composite roles inflate cost so reliably.
| Real-world role | Naive type | Correct type after role review |
|---|---|---|
| Plant operator, occasional approver | Professional | Limited Professional |
| Manager approving leave and expenses only | Professional | Employee |
| AP clerk, single module | Professional | Limited Professional |
| Field worker, time entry only | Limited Professional | Employee Self-Service |
Each correction is defensible because it reflects what the role actually grants once over-broad authorizations are removed. The discipline of splitting composite roles so that occasional high-privilege actions do not permanently elevate a user is the heart of named user optimization. The audit that reads these classifications is described in our SAP license audit guide.
The default-Professional problem: Most SAP provisioning processes assign Professional by default because it never causes an authorization failure. The result is an estate where 60 to 80 percent of users are typed Professional while fewer than half need it. A one-time reclassification against actual authorization usage typically removes 20 to 40 percent of Professional license demand with no operational change.
Named users and indirect access
The named user model only covers people who log in directly. When a third-party system accesses SAP on behalf of users who never touch SAP themselves, those users may still create a licensing obligation, historically resolved through indirect named users and now more often through digital access document counting. A buyer who has cleanly classified their direct users can still face exposure from an external CRM or e-commerce platform writing into SAP. The boundary between the two models is the subject of our indirect versus digital access and SAP digital access guides.
The practical rule is to treat human classification and machine access as two separate projects that must both be controlled. Cleaning named users without addressing indirect access leaves a large exposure unmanaged, and a contested indirect claim is handled through SAP indirect access advisory.
Multi-system de-duplication
A single person frequently holds accounts in several SAP systems: an ECC production system, a BW analytics system, a Solution Manager instance, and perhaps a CRM. The licensing rule is that the person counts once, at their highest classification across all systems, but only if the measurement consolidates their identities correctly. When the consolidation fails, the same human is counted in every system, multiplying the named user total against a population that has not grown at all.
| System | Account for one person | Naive count | Correct count |
|---|---|---|---|
| ECC production | Professional | 1 | 1 Professional |
| BW analytics | Professional | 1 | |
| Solution Manager | Limited Professional | 1 |
The naive count charges three licenses for one person; the correct count charges one. On a large multi-system estate, identity consolidation alone can remove 10 to 20 percent of the apparent named user population. The tool that performs this de-duplication is LAW, and getting its identity mapping right is one of the highest-return tasks in the annual cycle, as described in our SAP license audit guide.
The classification errors that recur
Named user over-classification is not random; it follows predictable patterns that recur in almost every estate. Recognizing them turns a one-time clean-up into a repeatable governance process that holds the saving over time.
| Error | Root cause | Governance fix |
|---|---|---|
| Everyone provisioned Professional | Default avoids authorization failures | Provision to role-based minimum type |
| Leavers never deactivated | No joiner-leaver license trigger | Tie deactivation to HR offboarding |
| Role drift after job change | Old authorizations never removed | Re-certify roles on transfer |
| Test users typed as dialog | Service accounts mis-set | Use correct technical user type |
The common thread is that classification is treated as a one-time provisioning decision rather than an ongoing license control. An estate that re-certifies user roles on job change, and ties license deactivation to HR offboarding, keeps the named user count honest without a repeated clean-up project. This is the same discipline that protects FUE under cloud, covered in our SAP FUE counting guide.
The substitution test for Professional: Before accepting any user as Professional, ask whether their daily work could be performed by a Limited Professional license. If the answer is yes for more than a narrow slice of approvals, the user is over-classified. Applying this single test across an estate where 60 to 80 percent of users are typed Professional typically reclassifies a third of them downward, with the saving locked in once roles are redesigned to match.
Named users at S/4HANA conversion
The named user position is not just an ECC concern; it is the foundation of the FUE count a buyer carries into S/4HANA. Converting a clean, correctly classified named user estate produces a defensible FUE commitment, while converting an over-classified one inflates the cloud number through the conversion ratio. This is why named user optimization is the prerequisite to any RISE move, not a separate exercise. The translation rules and the credits that offset the new commitment are detailed in our S/4HANA conversion credits guide and the SAP RISE advisory page.
A buyer planning conversion in the next two to three years should run the named user clean-up now, well ahead of the conversion negotiation, so the cloud commitment is sized against the true population rather than the inflated default. The renewal-timing discipline that sequences this is in our SAP renewal strategy guide.
Indirect named users and technical accounts
Not every account in an SAP system is a human, and the treatment of technical and service accounts is a frequent source of both over-counting and audit risk. A background processing account, an interface user that moves data between systems, and a system administrator account are each typed differently from a dialog user, and mis-typing them either inflates the count or creates a compliance gap. Communication and system user types exist precisely for these non-human accounts and should be applied correctly.
The risk runs in both directions. Typing a genuine interface account as a Professional dialog user pays for a license that should be non-chargeable, while typing a human's account as a technical user to dodge a license is a compliance violation that an audit will find. The correct position classifies every account by what it actually is, which removes the over-count without creating exposure. The boundary between human licensing and machine access, where indirect use is priced by document rather than seat, is covered in our SAP digital access and indirect versus digital access guides.
Service accounts that drive third-party integrations deserve particular attention, because the same integration can create both a named user question and a digital access document question. Mapping each technical account to its correct type, and confirming whether its activity is also counted as digital access, prevents the same machine traffic from being charged twice. This reconciliation is a standing part of our SAP optimization practice.
Tooling for ongoing classification
A one-time reclassification project recovers the immediate over-spend, but holding the saving requires ongoing measurement, and the question of tooling arises. SAP's own measurement transactions report the current position, while third-party license management tools can model the optimal classification for each user against their actual authorization usage and flag drift before the annual measurement. The decision on whether to invest in dedicated tooling turns on the size and volatility of the estate.
For a large, dynamic estate with constant joiners, leavers, and role changes, a dedicated tool that continuously models classification pays for itself by preventing the slow creep back toward default Professional. For a smaller or more stable estate, a disciplined quarterly review using SAP's native transactions controls the same risk without the tooling cost. Either way, the governance is the point, not the tool, and the cloud equivalent of this ongoing measurement is covered in our SAP FUE counting guide. The wider estate context is in the complete SAP licensing guide.
Running a named user optimization
The payoff from named user discipline is both immediate and recurring. The immediate saving comes from reclassifying the existing over-typed population, often a third of the Professional licenses, while the recurring saving comes from the governance that holds the count down as the workforce turns over. A buyer who treats classification as a one-time project captures the first and loses the second; a buyer who builds the re-certification and offboarding triggers captures both, year after year.
A named user optimization follows a clear sequence: extract the real authorization profile of every user, model each against the type definitions, identify the lowest defensible type, and re-provision roles so the classification holds over time rather than drifting back to Professional. The saving is locked in only when role design changes, because a one-time reclassification without role discipline reverts within a year as new users are provisioned on the old defaults. For the full SAP context see the complete SAP licensing guide, the SAP advisory practice, and our software licensing advisory service for the classification project itself.