The SAP measurement architecture distinguishes between system-level metrics and client-level metrics, and the distinction shapes how a complex estate is consolidated through the LAW into a coherent licence position. System-level metrics apply to the entire technical system, are measured once per system regardless of the number of clients in the system, and typically capture engine consumption. Client-level metrics apply to each logical client within a system, are measured separately per client, and typically capture user counts. The two levels are reconciled through the LAW into the final submission. A measurement preparation that conflates the two levels produces a submission with structural defects that the audit team will exploit. This article sets out the distinction, the metrics that apply to each level, and the LAW consolidation that reconciles the two. The full measurement methodology is in our USMM and LAW advisory service.
The technical distinction
An SAP system is a technical installation of the SAP NetWeaver platform. A client is a logical sub-installation within the system, with its own user master, its own transactional data, and its own configuration. A single system can host many clients — typically a development client, a test client, an integration client, and a production client. Some estates host multiple production clients in the same system for organisational reasons. The measurement architecture acknowledges the structural difference between the system and the client by routing different metrics to each level.
The system-level metrics
The system-level metrics include the database engine consumption, the application-server processing capacity, and the workload metrics that capture the technical footprint of the system as a whole. The engine consumption is measured once per system, because the engine runs once per system regardless of the number of clients. The HANA engine, the SAP NetWeaver Application Server engine, the SAP Solution Manager engine, and the various technology engines are all measured at the system level. The measurement output is a per-system consumption figure that is independent of the client structure.
The system-level metrics are the most likely source of unanticipated audit findings because the metrics are not visible through the user-facing interfaces and require technical extraction. The recurring pattern in our 500+ engagements is a system-level engine finding that the buyer was unaware of until the audit submission was returned with a quantity flag. The mitigation is a system-level review as part of the measurement preparation, conducted alongside the client-level user review.
The client-level metrics
The client-level metrics include the named-user count by classification, the user-master inventory, the role-collection assignment record, and the workflow assignment record. The metrics are measured separately per client because the user master is client-specific. A user who exists in two clients is two users for client-level purposes, and the LAW consolidation is responsible for de-duplicating the count across clients in the final submission.
The client-level metrics are the most visible to the business and the most familiar to the procurement team. They are also the metrics most affected by the override register, because the user classification is the primary reclassification target and the user classification is client-level. The override register is structured per client, with each entry naming the user identifier, the client, and the original and revised classifications.
The LAW consolidation
The LAW consolidates the per-system and per-client measurements into a single estate-wide licence position. The consolidation has two principal functions. The first is the de-duplication of users across clients and systems — a user present in multiple clients or multiple systems is counted once in the final position, provided the user identifier is consistent across the appearances. The second is the aggregation of engine consumption across systems against the contractual licence position for each engine — some engines are licensed at the estate level and others at the system level, and the LAW reconciles each.
The user-identifier consistency requirement
The de-duplication function depends on the consistency of the user identifier across the appearances. If the same user appears as JSMITH in one client, as J.SMITH in a second, and as JOHN.SMITH in a third, the LAW cannot reliably de-duplicate the user and produces a triple count. The mitigation is a pre-measurement reconciliation that aligns the user identifier across the appearances or that constructs a mapping table the LAW can use. The reconciliation is one of the highest-yield cleanup activities in estates with inconsistent user-master practice. See the LAW consolidation pitfalls article for the typical reconciliation patterns.
The development and test clients
The development and test clients are typically excluded from the licence position on the basis that they are non-productive. The exclusion is contractually supported in most agreements but requires explicit documentation in the override register. A development or test client included in the count without intention — typically because the LAW configuration did not flag it as non-productive — produces a substantial inflation in the user count. The mitigation is a pre-measurement review of the LAW client-configuration setting and an explicit confirmation of the productive/non-productive flag for every client in scope.
The single most common LAW configuration error in our practice is a sandbox or development client flagged productive. The error inflates the user count by the development team population, frequently producing a submission five to nine per cent higher than it should be.
The engine-licence reconciliation
The engine-licence reconciliation is the system-level analogue of the user de-duplication. Engines are licensed in quantities that may be allocated across the estate (estate-level licensing), allocated to specific systems (system-level licensing), or allocated per-client in some legacy contracts. The LAW reads the engine consumption per system and reconciles against the contractual allocation pattern. A reconciliation that misclassifies the allocation level — treating an estate-level licence as if it were system-level, or vice versa — produces a submission with engine-quantity flags. The contractual review that establishes the allocation level for each engine is a prerequisite for the LAW consolidation. See the engine metrics topic page for the engine-level detail.
The multi-production-client case
Some estates host multiple production clients in the same system for organisational reasons — one client per business unit, one client per regional operating company, one client per acquired entity. The multi-production case interacts unusually with the measurement architecture. The user counts are client-level and require de-duplication across clients. The engine consumption is system-level and is shared across the clients. The contractual treatment is rarely uniform and requires individual review. The case is more common in older estates and in estates that have grown through acquisition. See the USMM and LAW pillar for the broader context.
The preparation sequence
The two-level measurement architecture requires a two-track preparation. The client-level track addresses the user master, the role-collection design, the override register, and the user-classification work. The system-level track addresses the engine inventory, the engine-consumption measurement, the engine-contract reconciliation, and the engine-specific override documentation. The two tracks reconcile in the final LAW consolidation. A preparation that runs only the client-level track produces a submission with unaddressed engine exposure, and a preparation that runs only the system-level track produces a submission with unaddressed user exposure. Both tracks are required for a defensible position. See the USMM run preparation article for the client-level sequence and the engine licensing decoded white paper for the system-level sequence.
The audit-team probe pattern
Audit teams probe the system/client distinction explicitly. The probe sequence is to request the LAW configuration export, to verify the productive/non-productive flag on each client, to verify the engine-allocation level for each engine, and to verify the de-duplication mapping for cross-client users. A preparation that has documented each of the probe areas in the override register removes the procedural attack surface and moves the audit conversation directly to substance. The oil and gas LAW consolidation case file documents the probe pattern in practice.
— 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
If your estate hosts multiple clients across multiple systems, the two-level measurement architecture is the framework that determines what your submission actually says. Our USMM and LAW advisory service brief covers the two-track preparation.