Central User Administration (CUA) was designed for operational convenience: one place to create, change, and disable users across an SAP landscape rather than maintaining each system’s user master independently. The convenience is real and most mature estates rely on it. The licence-position consequence, however, is the source of one of the most common measurement-cycle surprises: a user count from the USMM consolidation that is materially higher than the count the IT team carries internally. The gap is not an error in either count — both counts are correct — but the reconciliation requires understanding what CUA does and does not deduplicate.
What CUA actually consolidates
CUA is a user-administration mechanism. A central CUA system holds a master user record; the child systems hold synchronised copies. When the central administrator creates a user, the user is propagated to the configured set of child systems. When the central administrator changes a role assignment, the change is propagated. The mechanism reduces administrative work and improves the consistency of the user population across the landscape.
What CUA does not do is reduce the number of user records that USMM sees. Each child system continues to hold its own SU01 record per CUA-propagated user. USMM, executed on each system, sees that system’s SU01 records. The LAW consolidation, executed across systems, sees the aggregated SU01 records. CUA’s administrative consolidation does not change the licence-counting mechanism. Each user appears in each child system in which they are entitled to access, and the licence count reflects the entitlement footprint rather than the human-headcount.
The split-user pattern
The recurring pattern in our measurement engagements is the split-user case. A user has CUA-propagated SU01 records in (say) the central ERP, the BW analytics system, the SRM procurement system, and a regional ECC instance. Each propagation set is appropriate to the user’s role. USMM in each system sees a record. The LAW consolidation should deduplicate the user across the four systems and report a single user, with the highest applicable classification across the systems. In practice the consolidation frequently misses the deduplication, either because the user identifiers do not match exactly across systems or because the LAW configuration has not been maintained.
The consequence is that the consolidated user count overstates the actual user population by the duplication factor — typically 1.4x to 2.1x in mature landscapes. The licence position constructed from the inflated count is correspondingly overstated, with the contractual implication that the buyer carries a higher Named-User baseline than the actual population would justify.
The identifier question
LAW’s deduplication mechanism relies on the user identifier matching across systems. Where CUA propagates with identical user identifiers across all child systems, the deduplication works. Where the propagation produces system-suffixed or system-prefixed identifiers (a not-uncommon legacy pattern), the deduplication fails and the consolidated count counts the same human four times. The remediation is an identifier-rationalisation exercise: normalising the user identifier across systems so that LAW can deduplicate cleanly.
The remediation cost
Identifier rationalisation is operationally non-trivial. Changing a user identifier in SAP requires either a new user creation with role re-assignment (and the old user’s history orphaned in the audit log) or a more elaborate rename process that preserves history but requires careful sequencing across systems. The cost per affected user is moderate; the cost across a population of several thousand affected users is meaningful. The work is best done as a discrete project rather than as an embedded element of the measurement preparation. The licence optimization service brief covers the rationalisation methodology.
The LAW configuration question
LAW consolidation requires specific configuration on each participating system: the system must be registered with the central LAW system, the user-identifier mapping must be configured, and the consolidation profile must be maintained. Each configuration item is straightforward in isolation; the failure mode is missing or stale configuration after system additions, system retirements, or LAW version upgrades. A consolidation run against a partial configuration produces a partial result, with the missing systems either undercounted (if they are not registered) or double-counted (if they are registered but the identifier mapping is wrong). See the LAW consolidation pitfalls piece for the configuration discipline.
The consolidated number on the LAW report and the actual user population on the corporate directory should reconcile to within a few per cent. A gap of twenty per cent or more is a strong indicator of a configuration or identifier problem rather than a genuine user inflation. The remediation is configuration, not negotiation.
The audit-defence position
An audit team facing a buyer-side claim that the consolidated count overstates the actual user population is in the position of asking the buyer to demonstrate the duplication. The demonstration is the reconciliation: the consolidated user count, the corporate directory user count, the per-system user inventories, and the cross-system identifier match. If the buyer has the reconciliation in hand, the conversation is mechanical and the audit position is restated to the lower count. If the buyer does not have the reconciliation, the consolidated number stands and the licence position is constructed on the inflated baseline. The discipline is to maintain the reconciliation continuously rather than to construct it under audit pressure.
The USMM sequence
The USMM preparation routine described in the USMM run preparation playbook should include a LAW configuration review and an identifier-reconciliation pass as standing items. The review confirms that every in-scope system is registered, that the identifier mapping is current, and that the consolidation profile is appropriate. The reconciliation produces the per-user cross-system mapping that supports any subsequent challenge to the consolidated count. Both items add modest time to the preparation calendar and remove the consolidation surprise as a category.
Where S/4HANA changes the picture
The S/4HANA migration is the natural moment to address identifier rationalisation, because the migration project re-implements the user master in the new system and can adopt the rationalised identifier scheme from the start. The downstream LAW consolidation against the new S/4HANA system benefits from the rationalisation immediately. The Full Use Equivalent (FUE) consolidation in the S/4HANA contract is built on the deduplicated count, and the rationalisation is the gating prerequisite for an accurate FUE baseline. See the SAP S/4HANA topic page for the FUE mechanics and the retailer CUA rationalisation case file for the pattern in practice.
Where to start
Pull the LAW consolidation report from the most recent measurement. Compare the consolidated count to the corporate directory. If the gap is meaningful, the identifier rationalisation is the priority item. If the gap is modest, the LAW configuration review is sufficient. The USMM validation playbook sets out the reconciliation template and the USMM and LAW advisory service brief covers the methodology.
— 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.
The operating discipline
CUA produces administrative convenience and licence-position complexity in the same operational decision. The two cannot be separated. The discipline is to treat the CUA configuration, the LAW configuration, and the identifier scheme as a single integrated topic rather than as three independent ones. The integration is owned by the licence team in collaboration with the basis team; left to either alone it tends to drift. The drift is what produces the measurement surprise, and the integration is what prevents it.