The License Administration Workbench, known universally by its acronym LAW, is the SAP tool that consolidates user data across a multi-system landscape into a single licence measurement. For customers operating ECC, S/4HANA, BW, Solution Manager, and any number of regional or business-unit instances, LAW is what turns a federated set of user master records into one defensible audit number. The configuration choices that drive the consolidation are technical, defensible, and routinely overlooked. Customers consistently submit LAW results that overstate their licence position by twenty to forty per cent because the consolidation has been configured against them rather than for them.
This guide walks through how LAW consolidates users, the four configuration choices that determine the consolidated number, the common errors that inflate the count, and the reconciliation steps that produce a defensible submission.
What LAW actually does
LAW is a transaction that runs on a chosen central system and pulls user master data from each connected satellite system in the landscape. For each user ID it can identify across the landscape, LAW applies a set of rules to determine whether the user records represent a single human or multiple humans, and assigns a single consolidated licence type to that human.
The rules are configurable. The default configuration applies basic matching — username, full name, email address — and consolidates records that match across systems into a single licence consumer. The configuration choices determine how aggressive the matching is, how the licence type is selected when the satellite records disagree, and how unmatched records are treated.
The output is a consolidated user list with one row per human, each carrying a single contractual licence type. That list is what gets submitted to SAP as part of the annual measurement, and it is what the auditor benchmarks against the licensed entitlement. See the broader USMM context in our USMM topic page.
Configuration choice one — the matching algorithm
The first and most consequential configuration choice is the matching algorithm. LAW supports matching on several fields, in several combinations, and the choice determines how many cross-system duplicates are correctly consolidated.
The default matching is normally username plus full name. The combination works for customers whose user provisioning is centralised and consistent, but it fails badly where local naming conventions vary by system. A user whose ECC username is "john.smith" and whose S/4HANA username is "JSMITH" will not be consolidated under default matching, even where the underlying human is the same. The auditor sees two separate licence consumers, each requiring its own licence.
The defensive matching configuration is to include email address as a matching field. Email addresses are normally centralised in active directory and are consistent across systems even where local username conventions vary. Adding email to the matching set typically improves consolidation by ten to twenty per cent on a heterogeneous landscape.
Configuration choice two — the licence-type selection rule
When the satellite records for a single consolidated user disagree on licence type — for example, the user is classified as Professional in ECC, Limited Professional in BW, and Functional in S/4HANA — LAW needs a rule to pick a single licence type for the consolidated record. The default rule is to take the highest tier present across the satellites.
The default is defensible against an audit but maximally expensive against the customer's interest. A user who is correctly Limited Professional in operational reality, but mislabelled as Professional in a single system due to a copied composite role, will consolidate as Professional under the default rule. The fix is to remediate the underlying classification in the satellite system, not to override the rule, but customers routinely allow the misclassification to propagate through the consolidation because they have never reviewed the rule.
The case for the highest-tier default
The default rule reflects SAP's contractual position. A user whose authorisations in any production system entitle them to perform Professional-level activity has the contractual licence type Professional, regardless of whether they actually used that authorisation in the period. The audit defence is to remediate the satellite that carries the high tier, not to argue against the consolidation rule.
Configuration choice three — the sandbox and training exclusion
LAW connects to the systems it is told to connect to. Customers running sandboxes, training environments, and other non-production instances need to ensure those systems are excluded from the consolidation, or the user records from those systems will inflate the consolidated count.
The most common error is to include the training environment in the LAW configuration because it is technically a "production" system from an availability perspective. The contractual position is that training environments are not production for licence purposes, but the LAW configuration does not know that distinction unless the customer applies it.
The remediation is to maintain a single LAW configuration document that lists the productive systems in scope and the non-productive systems out of scope. The document sits in the licence file and is the audit defence against any auditor challenge that the consolidation is incomplete.
Configuration choice four — the dormant-record threshold
LAW can be configured to exclude records that have not had recent login activity from the consolidation. The threshold is configurable — thirty days, sixty days, one hundred eighty days, or longer. Customers who do not set the threshold include all records, dormant or active, and consolidate them into the licence count.
The defensive setting is one hundred eighty days. Records inactive for that period are flagged for review, either reactivated and counted, or deactivated and excluded. The exercise typically removes ten to twenty per cent of the headline user count. See the related treatment in our analysis of dormant named user cleanup.
The reconciliation workflow before LAW submission
A defensible LAW submission is built in four stages.
Stage one is the satellite-system extract review. For each system in the landscape, run the user master and authorisation extracts, classify each user, and remediate misclassifications at source. The exercise needs to complete before LAW runs, because LAW consolidates the satellite classifications and does not interrogate them.
Stage two is the configuration review. Confirm the matching algorithm, the licence-type selection rule, the system inclusion list, and the dormant threshold. The configuration should be documented and version-controlled, with explicit rationale for any non-default setting.
Stage three is the test run. Execute LAW in test mode against the configured landscape and review the consolidated output. Look for users whose consolidated licence type is higher than their operational reality, dormant users still included in the count, and cross-system duplicates that have not consolidated. Each anomaly is investigated and either remediated at source or documented as a known exception.
Stage four is the production run and submission. Execute LAW in production mode, lock the output, and submit to SAP with documented footnotes covering any non-default configuration. The footnotes are the audit defence and signal to the auditor that the customer has run the consolidation deliberately rather than accepting the defaults.
Where LAW intersects with the S/4HANA conversion
Customers mid-conversion from ECC to S/4HANA face a specific LAW complication. The conversion year normally has the user population split across the two systems, with some users transferred wholesale, some users running parallel in both, and a small population that exists only in the system that has not yet been converted. The LAW configuration needs to consolidate the population correctly without double-counting the parallel-running users.
The treatment is governed by the conversion paperwork. Most conversion contracts include a transitional provision permitting parallel running for a defined period, during which a user counted in ECC is not also counted in S/4HANA. The LAW configuration needs to apply the transitional provision, which is normally a customer-side configuration step rather than an automatic SAP-side adjustment. See the deeper treatment in our S/4HANA engine conversion analysis and our S/4HANA migration compliance service.
Three configuration questions to ask before the next LAW run
First, is the matching algorithm tuned for the customer's actual user provisioning conventions, or running on defaults? If on defaults, run a test consolidation with email-based matching and measure the delta.
Second, is the licence-type selection rule producing a defensible output, or propagating misclassifications? If the latter, the remediation is at source rather than at the consolidation rule.
Third, is the system inclusion list current? Sandboxes, training environments, and decommissioned satellites should not be in the consolidation. Customers who have not reviewed the list in two or more years routinely find one or more legacy systems still contributing to the count.
For the broader USMM and LAW measurement methodology see the SAP Audit Defence Playbook and our USMM and LAW measurement advisory service. For the documented case file see the global retailer LAW consolidation case.