The SAP General Terms and Conditions have contained a single sentence since at least the 2009 master agreement that determines the entire commercial logic of named user licensing: each named user license is for a single individually identified user and may not be shared, rotated, or reassigned except in the case of permanent departure. Every audit finding that begins with "concurrent login," "generic account," or "shared service ID" traces back to that sentence, and the back-priced exposure on a shared-user finding is consistently among the three largest categories we see in active SAP audit matters.
This guide explains the contractual rule, the patterns SAP's auditors look for, the four common operational habits that produce a shared-user finding, and how to remediate the population before the next USMM submission turns the exposure into a settlement number.
The one-human-one-licence rule, as the contract states it
The contractual obligation is unambiguous. A named user licence is allocated to a specific individual, identified by name, and that individual is the only person authorised to use the licence. The contract permits reassignment when an employee permanently departs the organisation, but does not permit rotation, sharing, or pooling among multiple humans. The rule applies whether the access is interactive, indirect, technical, or batch — if a human ultimately drives the activity, that human needs their own licence.
SAP's interpretation has hardened over the last three contract generations. Older contracts could be read to permit pooled named users in narrow operational contexts; the 2018 master agreement closed those readings, and the 2024 RISE contract templates restate the prohibition explicitly. Customers operating on legacy contract paper need to read the actual definition in force, not the current public-facing language.
What the auditor actually looks for
The auditor's evidence base for a shared-user finding is straightforward and reproducible. They run three extracts and triangulate.
1. Concurrent-session evidence
The SU3 and ST03N transactions surface session and dialog logs. Two sessions opened against the same user ID, from different terminal IPs, in overlapping time windows, are prima facie evidence of sharing. We routinely see auditors filter for sessions opened from more than one workstation in any rolling thirty-day window — a low bar that catches almost every shared service account in a typical estate.
2. Login frequency anomalies
Accounts that log in more than fifty times per business day, or that log in continuously across multiple working shifts, are flagged as candidates for sharing. The auditor cross-references against the contractual definition of an individual user and asks the customer to explain how a single human is plausibly responsible for the activity.
3. Generic-name patterns
Account naming conventions are the lowest-effort find. IDs containing "service," "shared," "team," "ops," "support," "training," or any pattern that does not correspond to a recognised employee directory entry are flagged for review. Many estates retain "TRAINING01" through "TRAINING50" type accounts from go-live periods that were never decommissioned.
The four operational habits that produce shared-user findings
Habit one — the generic service account that gradually became human-driven
A technical account created for batch processing or RFC integration is given to an operations team to use interactively when the batch fails. Over time the manual fallback becomes routine, and the account is used by anyone in the operations rota. The auditor treats every human who has used the account as a separate named user requiring a Professional licence, retroactive to the first interactive login.
Habit two — the on-call account
The pattern most common in industries with twenty-four-hour operational coverage — manufacturing, utilities, logistics, healthcare. A single account is used by whoever holds the pager. The contract treats each on-call engineer as a separate named user requiring their own licence; the auditor will normally request the on-call rota and price the exposure against the number of distinct individuals who held the rota across the contract term.
Habit three — the contractor pool
Project teams of contractors are issued a smaller pool of accounts that they rotate among themselves to keep named user counts down. The audit treatment is the most expensive in the catalogue: every contractor who has logged in at any time during the measurement period is treated as a Professional user, plus a back-priced finding for the full contract term during which the contractor pool was in operation. See the related analysis on contractor classification for the correct treatment.
Habit four — the training environment that became a production extension
A training estate is provisioned with twenty pooled accounts intended for classroom use. Over time, the boundary between training and the production sandbox blurs, and the pooled accounts are used to validate production fixes by operations staff. The auditor consolidates the training accounts into the main USMM count.
What the contract does and does not permit
Three exceptions to the no-sharing rule are widely misunderstood and worth stating precisely.
The first exception is permanent reassignment. When an employee permanently leaves the organisation, their named user licence can be reassigned to a new individual. The audit defence is documentation: an HR-confirmed termination date, a deactivation timestamp on the old user, and a creation timestamp on the new user that follows the deactivation. Reassignment within the same calendar year is permitted; reassignment that overlaps with the original user remaining active is not.
The second exception is internal substitution during defined absence. SAP has historically permitted a single short-term substitution where an employee is on a multi-week absence and a colleague needs to cover their workload. The customer must document the substitution, the duration must be bounded, and the substitute must not retain access after the original employee returns. This exception is narrow and is increasingly absent from new contract paper.
The third exception is technical accounts that have no human user behind them — pure system-to-system RFC, batch processors, integration accounts. These are not named users in the contractual sense and follow a different licensing path under the indirect access framework. See the deeper treatment in our SAP indirect access topic page and the indirect access economics white paper.
Remediation before the next USMM run
A defensible position requires three preparation steps in the ninety days before the next measurement submission. These steps are routine licence hygiene; customers who treat them as such avoid almost every shared-user finding we see.
The first step is account inventory and naming-pattern audit. Run an extract of all user IDs in production, sort by naming convention, and flag every account whose name does not correspond to a current employee directory entry. Each flagged account is investigated, classified as either technical, dormant, or human-attached, and either reassigned to a named individual or decommissioned. The exercise typically reduces the active-user population by ten to twenty per cent before USMM runs.
The second step is concurrent-session reconciliation. Extract the ST03N session history for the prior six months and identify any account with overlapping concurrent sessions. Each pattern is either remediated with additional named user licences for the individuals who shared the account, or the sharing is stopped and the account is restricted to a single human going forward.
The third step is service-account documentation. Every technical account that performs RFC, batch, or interface processing should have a documented purpose, an owning team, and a contractual classification under the indirect access framework. The documentation is the audit defence for the technical-account population.
Negotiating the finding once it is raised
Even where SAP has a defensible shared-user finding, the price is negotiable. The opening position uses current list price for each additional individual, multiplied by the back-charge window, multiplied by the maintenance factor. We typically negotiate the unit price down to the customer's weighted-average discount, the back-charge window down to the current contract year, and the maintenance multiplier to the prospective basis. On a five-hundred-thousand-dollar opening claim the cumulative reduction is normally between fifty and seventy per cent. See the scope-pushback letter template for the language used to frame the negotiation in writing.
For procurement teams approaching a renewal with a known shared-user population, the negotiation lever is to fold the remediation into the renewal scope rather than absorbing it as an audit finding. A renewal-time uplift to the named user count, sized to the actual head-count behind shared accounts, carries no back-charge component and lands at the negotiated unit price rather than list. The difference on a typical mid-market estate is six to seven figures.
The independent advisory question is whether the customer's internal team can carry the position into the negotiation without external context on how similar findings have been settled. For most teams the answer is no, and the engagement of an independent advisor pays for itself in the first hour of negotiated reduction. See our manufacturer shared-account remediation case file for a worked example of the trajectory from opening finding to closed settlement.