An SAP named user licence is, in the contractual model, a licence assigned to a specific named individual within the customer organisation. The mechanics of how that assignment can be moved from one individual to another — when, with what notification, with what auditable trail — is one of the operational details that customers most consistently get wrong. The error is rarely deliberate; it is almost always a misunderstanding of where the contractual rule ends and the operational practice begins. But the consequence at audit is real, because reassignment errors translate directly into apparent over-deployment of licences and apparent under-deployment of others.
This article walks through what the SAP contractual rules on reassignment actually say, the operational patterns that produce non-compliance, and the controls that prevent reassignment errors from becoming audit findings.
The default contractual rule on reassignment
The default SAP enterprise contract permits reassignment of a named user licence from one individual to another, subject to two conditions. The first is that the reassignment is permanent — the licence is moved from the prior individual to the new individual, and the prior individual no longer has access to the system covered by that licence. The second is that the reassignment is not for the purpose of circumventing concurrent use — the customer cannot reassign a licence to enable two individuals to share the licence on a time-slicing basis.
Some older contracts and some industry-specific agreements impose additional conditions — a minimum tenure on the prior assignment, a notification requirement to SAP, or a limit on the frequency of reassignment. Customers should read their specific contract carefully before assuming the default rule applies.
The operational patterns that produce non-compliance
The first pattern is the dormant-account reassignment. The customer has a population of dormant SAP accounts — employees who have left, retired, or moved to roles that no longer require SAP access — and reassigns the licence from those accounts to new hires. The mechanics are straightforward: the dormant account is locked, the new account is created with the same authorisation profile, and the licence is treated as moved. The audit risk is that the dormant accounts have not been formally deactivated in the licence administration system, with the result that both the dormant account and the new account appear in the licence count.
The second pattern: the shared-licence pattern
The second pattern is the shared-licence pattern. A team of operators on a shift schedule, or a population of contractors on rotating engagements, is granted access through a single named user account that is logically passed from individual to individual. The customer's intent is to provision access efficiently; the contractual position is that the account is being shared, which is a clear non-compliance pattern. The defence in audit is essentially nonexistent; the controls before audit are operational.
For more on the shared-licence rules, see our shared named user article.
The third pattern: the role-based reassignment lag
The third pattern is the role-based reassignment lag. A customer's licence classification — Professional, Functional, Limited Professional — is tied to the user's role and authorisation profile. When a user's role changes, the licence classification should change with it, but in practice the classification lags the role change by months or quarters. Users with elevated authorisation profiles continue to be counted under the lower classification; users whose roles have been narrowed continue to be counted under the higher classification.
The audit exposure runs in both directions. Users under-classified relative to their authorisation are an under-licensing exposure. Users over-classified relative to their authorisation are a waste of licence value but not an audit exposure. The reassignment process needs to handle both directions, with regular reconciliation between the role administration system and the licence administration system.
The fourth pattern: the project-based contractor
The fourth pattern is the project-based contractor. The customer engages a contractor for a defined project, provisions a licensed SAP user, and at project end either retains the user for a follow-on project or releases the licence for reassignment. The reassignment is operationally clean, but the documentation is often weak, with the result that the auditor cannot trace the lineage of the licence assignment and treats every distinct user as a separate consumer. The customer's licence count is correct; the documentation is not.
For more on contractor classification, see our contractor classification article and the compliance assessment service.
The controls that prevent reassignment errors
Three controls, applied consistently, prevent the reassignment patterns above from producing audit findings. The first is a formal user lifecycle process — provisioning, role change, deprovisioning, licence release — with each step formally captured in the licence administration record. The second is a regular reconciliation between the operational user population, the SAP user accounts, and the licence administration record. The third is a documentary trail for every reassignment, with sufficient detail that an auditor could trace each licence from its original assignment to its current holder.
None of these controls is technically difficult; all of them require organisational discipline that customers frequently allow to slip in periods of high turnover or rapid organisational change. The discipline is most easily maintained when the licence administration is centralised in a single team with clear ownership rather than distributed across regional or business-unit administrators. For broader optimisation strategy, see our licence optimisation service.
The audit posture on reassignment
In an audit, the reassignment question typically surfaces in two ways. The first is the variance between the customer's reported licence count and the measurement output — if the LAW measurement shows more active users than the customer's reported count, the gap is often a reassignment-documentation gap. The second is the lineage question on specific licences — particularly where the auditor selects a sample of named user licences and asks for the assignment history.
The defence in both situations rests on the documentary trail. Customers with a clean trail can produce the lineage on request and resolve the variance; customers without a clean trail are exposed to a finding that the customer treats as routine reassignment but the auditor treats as evidence of shared use or under-licensing. The documentary discipline is therefore not only an operational good practice; it is a direct audit-defence asset. For an applied example, see the named user cleanup case file and our dormant cleanup article.
The cloud migration nuance
Customers migrating to RISE or to S/4HANA Cloud encounter an additional twist. The cloud subscription model meters active users differently from the on-premise named user model — typically through SAP's cloud usage telemetry rather than through USMM and LAW — and the reassignment rules differ accordingly. Customers who carry on-premise reassignment habits into a cloud subscription often find that their cloud licence position diverges from their actual user population in unexpected ways. The migration is a good moment to reset the reassignment discipline; customers who do not reset frequently find the cloud renewal more expensive than the modelled position.