The License Administration Workbench (LAW) is SAP’s consolidation transaction that aggregates USMM outputs across multiple SAP systems into a single landscape-level licence position. The mechanism is necessary because most enterprises run multiple SAP systems and the licence entitlement is at the landscape level rather than at the system level. The LAW de-duplicates users across systems, applies the highest licence band per consolidated user, and produces the consolidated licence requirement that becomes the submission to SAP. The consolidation is mechanically straightforward in concept and introduces a category of measurement error that buyers rarely validate. This article sets out the LAW mechanics, the two recurring pitfalls in the consolidation logic, and the validation routine that produces a defensible consolidated position. It is one of the engagement patterns underneath our USMM and LAW advisory service.
What the LAW actually does
The LAW collects USMM output files from each SAP system in the landscape, parses them, applies a user-matching algorithm to identify users that appear in multiple systems, consolidates the user records into single landscape entries, applies the highest classification across the consolidated record, and produces an aggregated licence requirement report. The output is the document submitted to SAP for the landscape-level licence reconciliation. The user-matching algorithm is the technical core of the consolidation and the principal source of the consolidation-specific measurement error.
The matching is based on user identifier and email address, with several optional matching criteria that can be configured. The matching is deterministic given a configuration, but the configuration is buyer-controlled and the matching outcome can vary materially with configuration changes. See the USMM topic page for the underlying mechanics.
Pitfall one — mismatched identifiers
The first and most common pitfall is mismatched user identifiers across systems. A user with identifier JSMITH in the ECC production system, JOHNSMITH in the BW system, and SMITHJ in the SuccessFactors integration. The matching algorithm with default configuration may treat the three as separate users and produce a landscape count of three users where the actual landscape population is one user. The inflated count flows into the consolidated licence requirement and becomes the audit position.
The mitigation is the user-matching configuration review applied before the LAW run. The review compares the identifier patterns across systems, identifies the variant pattern (single user with multiple identifiers, multiple users with one identifier), and configures the matching rules to handle the variant pattern correctly. The configuration is system-specific and depends on the user-provisioning history; the right configuration is established by analysis of the actual identifier patterns rather than by a default rule.
Pitfall two — aliasing and dormancy
The second pitfall is the inverse: a single landscape identifier shared across multiple actual users (typically a service account or a shared functional account) that is treated as one user when the underlying record represents many. The consolidation under-counts the actual user population, which is initially favourable to the buyer but creates an audit risk if the misalignment is discovered during the SAP review and reversed adversely.
The mitigation is the dormancy and alias review applied to the consolidated user list. The review identifies records with abnormal activity patterns (very high transaction volume suggesting multi-user use, very low transaction volume suggesting dormant assignment, off-hours patterns suggesting batch use), classifies each as service-account, shared-account, dormant, or active, and applies the appropriate classification under the contract definitions. Service accounts are typically excluded from the named-user count; shared accounts are typically classified at the highest band applicable to any of the users; dormant accounts are typically removed from the user-master before the LAW run.
The validation sequence
The LAW validation has four steps that complement the underlying USMM validation. First, the user-matching configuration review (described above) applied before the LAW run. Second, the LAW dry-run, with the consolidated output extracted in a non-submission mode. Third, the user-matching report review, comparing the consolidated user list against the source USMM populations to identify suspicious matching outcomes. Fourth, the configuration adjustment and re-run, repeated until the consolidated position is defensible.
The sequence takes two weeks for a typical landscape of five to ten SAP systems. The output is a consolidated submission that is supported by a documented matching configuration and a defensible per-user matching rationale. The validation discipline parallels the USMM validation discipline; the same evidence standard applies. See the USMM and LAW pillar for the integrated frame.
How matching rules differ
The default LAW matching configuration is conservative: match on exact user identifier with email as a secondary criterion. The conservative default is defensible but tends towards over-counting (treating variant identifiers of the same user as separate landscape entries). The aggressive matching configuration is the opposite: match more liberally on any of several criteria, producing fewer landscape entries but with higher risk of incorrect aggregations.
The right configuration is between the two extremes and is estate-specific. The configuration should be chosen on the basis of the actual identifier patterns observed across the buyer’s systems, and the choice should be documented so that the matching outcome is reproducible and defensible. The USMM validation playbook covers the configuration-choice framework.
The S/4HANA overlay
The LAW in the S/4HANA era operates similarly to the classical LAW, with adjustments for FUE-based reporting. The consolidated user list is converted to FUE values via the contract’s ratio table, and the FUE total becomes the consolidated licence requirement. The matching error categories described above persist; the FUE conversion amplifies the impact of matching errors because the FUE weighting magnifies user-count changes in the consolidated total.
The implication is that the LAW validation work becomes more economically consequential under the S/4HANA contract structure. The same pre-submission validation effort delivers larger savings because the FUE conversion magnifies the effect. The S/4HANA migration compliance pillar covers the FUE conversion mechanics.
The cross-system classification review
The LAW applies the highest classification across the consolidated record. A user classified as Professional in any source system is consolidated as Professional in the landscape record, regardless of the classification in other source systems. This is a conservative rule, defensible from SAP’s perspective, but it amplifies the impact of over-classification in any single source system. An over-classified record in a low-activity system propagates the over-classification to the consolidated record even if the user’s actual activity in the production system is correctly classified at a lower band.
The mitigation is the cross-system classification review applied as part of the LAW validation. The review compares classifications across systems for each consolidated user, identifies inconsistencies, and resolves to the actually-correct classification based on the user’s aggregate activity across all systems. The output is a consolidated record where the classification reflects the user’s landscape-level usage rather than the most-pessimistic per-system classification.
The LAW is conceptually a simple consolidation. In practice, it is the second-largest source of measurement error after the underlying USMM classification. A two-week validation pass typically corrects between three and eight per cent of the consolidated user count and a corresponding share of the landscape licence requirement.
The operating routine
A clean LAW consolidation, like a clean USMM submission, is the output of a year-round operating routine rather than a single annual project. The routine has three components. A consistent user-identifier strategy across SAP systems, ideally with single sign-on or directory-integrated provisioning that eliminates the variant-identifier pattern. A documented user-matching configuration that is reviewed annually and adjusted as the identifier patterns evolve. And a service-account and shared-account register maintained as a parallel document to the LAW output.
With the routine in place the annual LAW submission becomes a procedural exercise. Without it, the annual submission requires a fresh validation pass under measurement-window time pressure. The manufacturer case file documents the LAW validation methodology applied during audit defence.
What good looks like
A well-validated LAW submission reduces the consolidated licence requirement by between three and eight per cent against the unvalidated submission, with the reduction concentrated in the identifier-mismatch and dormancy-and-alias categories. The cross-system classification review adds a further reduction concentrated in the multi-system classification inconsistencies. The combined reduction is typically five to twelve per cent on the consolidated position, with corresponding cost reduction at the landscape level. The validation effort is calendar-bounded (two weeks), the methodology is well-established, and the dependency is on buyer-side analysis discipline rather than on negotiation skill.
— 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.
Where to start
Run the LAW consolidation in a dry-run mode and pull the user-matching report before the formal submission. The dry-run output reveals the matching pattern and lets the validation pass occur before the position is committed. The USMM and LAW advisory service brief covers the full validation sequence.