Section I · The Brief
The headroom problem
The client, a regional utility group operating across Belgium, the Netherlands, and Luxembourg, ran a 12,000-user SAP ECC estate with an additional 6,000 user accounts in various technical, dormant, or service states. The contracted named-user entitlement was 12,000 Professional-tier and 4,000 Limited-Professional-tier licences, with an additional 1,500 Employee Self-Service licences for plant-floor and field-engineer self-service access.
Operational growth was projected to add 600 named users per year over the next contract term, driven by an ongoing acquisition programme and the rollout of a new field-service management module. The procurement forecast assumed an incremental SAP purchase of 1,200 named users over the contract term at a cost of approximately one point eight million dollars, on the basis that organic growth would consume the existing headroom buffer of 200 users within twelve months.
The brief was to test the existing entitlement against actual use across the 18,000 user accounts, identify the recoverable licences from the technical and dormant population, and present a redeployment plan that absorbed organic growth without incremental purchase.
Section II · The Opening Claim
The estate baseline
The opening position counted 12,000 named users against a 12,000-user entitlement, with no headroom buffer beyond the immediate 200 users for ongoing onboarding. The 6,000 additional user accounts were distributed across technical and dormant categories that had been excluded from the chargeable population in the LAW report but were consuming database storage and authorisation maintenance.
The additional account population broke down as follows.
- 2,400 service accounts (SAP-PUSER, SAP-CUSER, SAP-WFUSER) for cross-system integrations.
- 1,800 dormant accounts with no logon activity over the prior 12 months (former employees, expired contractors, completed projects).
- 900 test-and-training accounts inherited from prior implementation projects that had never been retired.
- 600 emergency-access and break-glass accounts for incident response and business-continuity scenarios.
- 300 vendor accounts associated with managed-services contracts that had expired without account-removal close-out.
Section III · The Defence
The recovery programme
We took the engagement on a continuous-optimisation footing with no SAP audit in flight. The evidence brief was a four-source extract: SU01 user table (account inventory), USR41 logon history (activity evidence), USR40 lockout state (deactivated accounts), and the basis team’s asset register (account-to-purpose mapping). The analysis horizon was the prior twelve months for activity evidence and the prior thirty-six months for retention-policy alignment.
The reclassification work split the named-user population into recoverable and non-recoverable subsets on a per-account basis. The recoverable subset was the population where a contracted named-user entitlement was assigned but the account had no productive use over the evidence window, with the entitlement therefore available for redeployment under the contracted retention rules.
The recovery recommendations broke down as follows: 600 retired-employee accounts had retained their named-user assignment in error (the SAP basis team had locked the accounts but not relinquished the entitlement); 380 expired-contractor accounts had retained their entitlement through the contractor lifecycle; 220 completed-project accounts had retained their entitlement after project closure; 100 accounts had been double-counted in the LAW run because of multi-system replication; 100 misclassified accounts had been at Professional tier where Limited Professional was the supportable assignment, releasing the Professional licence to the pool.
The output was 1,400 named-user licences released from the assigned population and returned to the entitlement pool, plus a process change in the basis team’s account-lifecycle methodology to ensure entitlement relinquishment at deactivation. The recovered pool absorbed projected organic growth for the next two years and provided a 200-user buffer for unplanned onboarding.
- Four-source extract (SU01, USR41, USR40, basis register) over a 12-month activity window
- 600 retired-employee accounts relinquished with retained entitlement returned to pool
- 380 expired-contractor accounts cleaned through the contractor lifecycle close-out
- 220 completed-project accounts retired with entitlement returned to pool
- 100 misclassified Professional-tier accounts re-banded to Limited Professional
Section IV · The Settlement
The redeployment outcome
The named-user entitlement was rebalanced from 12,000 assigned and 200 unassigned to 10,600 assigned and 1,400 unassigned. The 1,400-user buffer covered the next two years of projected organic growth with a 200-user residual, removing the incremental purchase requirement entirely from the renewal forecast.
The basis team’s account-lifecycle methodology was updated to incorporate entitlement relinquishment at account deactivation as a standard close-out step, with quarterly reconciliation against the contracted entitlement pool. The methodology was documented in an operational runbook deposited with the SAM function.
Total elapsed time from engagement to completed redeployment plan was ten weeks. The licence-pool reconciliation has run as a standing quarterly process since closure with no further leakage observed.
Section V · Lessons Applicable
What others can use
Five takeaways from the matter that apply to any organisation managing a steady-state SAP estate.
- Account deactivation is not entitlement relinquishment. The basis team can lock an account without releasing the named-user assignment back to the pool, and this is the single most common source of licence leakage.
- The contractor lifecycle close-out is a licensing checkpoint. Expired contractors should release their entitlement at contract close, not at the next quarterly reconciliation.
- Completed projects are a licensing release event. Project-team accounts should be reviewed at project closure rather than at annual reconciliation.
- Multi-system replication causes double-counting in LAW. Users replicated across ECC, BW, and CRM are counted once in the contracted pool but appear three times in the LAW extract.
- Quarterly reconciliation prevents leakage between annual cycles. Annual reconciliation catches the prior twelve months of leakage; quarterly catches it before it accumulates.
