Interpreting LAW Reports: How to Read SAP License Measurement Results Correctly

Interpreting LAW Reports

Imagine handing SAP a report that overstates your usage by thousands of dollars — misinterpreting SAP’s License Administration Workbench (LAW) results can lead to exactly that.

LAW is the final consolidation of SAP’s license measurement (from transaction USMM in each system) that SAP’s auditors rely on to assess your compliance. If duplicate users or misclassified licenses skew that view, it can inflate your apparent shortfall by millions. Read our ultimate guide to SAP License Measurement Tools.

Insight: “LAW’s numbers are not facts — they’re SAP’s interpretation of your data. Your job is to verify the story before it’s told to SAP.”

Overview of LAW Report Structure

Once you’ve run USMM on all productive SAP systems and imported the results into LAW, you get a consolidated report. This LAW report has three key sections that summarize your license usage:

Checklist: Before trusting the LAW output, do some basic sanity checks:

• Make sure all USMM measurement files from every productive system were imported (no system left behind).
• Verify that only productive systems are counted – development or test systems should be excluded or flagged so they don’t add to the totals.
• Confirm the measurement period aligns with your audit window (so the data isn’t from an outdated run).
• Check for any import errors or warnings in LAW and resolve them. A missing file or error could skew the results.

Understanding Duplicate User Consolidation

One of LAW’s most important jobs is to merge duplicate user accounts across systems. If the same person has a login in ECC, CRM, and BW, LAW should consolidate them into one user entry (with one license). This prevents double-counting the same human user multiple times. LAW uses deduplication keys (matching criteria) such as username, personnel ID, or email address to identify the same person across systems. However, LAW’s matching is literal – if the identifiers don’t match exactly, it won’t catch the duplicate.

How consolidation works: You choose a matching rule (for example, “email address” or “Personnel Number”) when importing USMM data. LAW then groups accounts that share the same identifier and treats them as one user.

The consolidated user is assigned the highest license type that person had in any system. For instance, if Jane Doe is a “Professional User” in one system but only “Employee Self-Service” in another, LAW will count Jane once as a Professional (the higher of the two).

Pitfall → Fix:

• Pitfall: A user has different usernames or IDs in each system (e.g., JDoe in one system vs. John.Doe in another). LAW might fail to link them as the same person.
  Fix: Create a mapping file or adjust the user data before import so that matching fields align (for example, ensure the email or personnel number is consistent across systems). This pre-work lets LAW correctly merge those accounts.
• Pitfall: LAW didn’t consolidate a user, and as a result, the person is counted twice – perhaps even assigned a high-level license in each system.
  Fix: Manually identify and consolidate those duplicates. You may need to rerun LAW using a different matching key or use LAW’s manual merge feature if you spot an unmerged duplicate. A user should end up with one license entry globally at their highest needed license level.

Insight: “LAW’s deduplication logic isn’t intelligent — it’s literal. If your naming is inconsistent, your costs will be too.”

In practice, this means you cannot rely blindly on LAW to figure out all duplicates. You should double-check the consolidation.

Checklist:

• Confirm which deduplication rule was used (username, personnel number, or email) and that it’s the best choice for your landscape.
• Spot-check a few users across systems to ensure they appear only once in the LAW user summary.
• Verify that each consolidated user’s license type makes sense. One person should have a single license category (the highest level they need), not multiple entries.

Read our guide to Avoiding Measurement Errors: How to Prevent Costly Mistakes in SAP License Audits.

Reviewing User Classification and License Counts

After consolidation, the LAW Named User Summary lists how many users you have in each license category. This is the foundation for SAP’s license compliance check on users. It’s critical to interpret these numbers correctly:

• Understand the counts: For example, LAW might show 120 Professional Users, 300 Limited Professional, 500 Employee Self-Service, etc., as consolidated totals across all systems. These numbers represent active unique users in each category after merging duplicates.
• Reconcile with expectations: Compare these totals to your internal data. Does 120 Professional Users sound reasonable given your company’s size and roles? If you only have 100 people who need a Professional license, seeing 120 suggests something’s off (perhaps inactive accounts or misclassified roles).
• Check against entitlements: Look at your SAP contract entitlements for each user type. If you purchased 100 Professional licenses but LAW shows 120 Professional users, SAP will consider that a 20-user shortfall.
• Exclude non-human accounts: Ensure that system users, background jobs, and reference users are not included in the named user count. SAP’s measurement should exclude “technical” accounts, but it’s worth verifying none slipped in, as they can unnecessarily inflate counts.

Action Tip: “If LAW shows more licensed users than you’ve purchased, it’s time to fix user mapping or classifications — not buy more licenses.”

Checklist:

• Compare the LAW user totals with your internal data (HR records, etc.) and with your purchased entitlements. Identify any license categories where the measured count exceeds what you actually have (either in people or in licenses owned).
• Verify that technical, system, or reference users are excluded from the count.
• Scan for inactive users (accounts with no recent login or users who have left) in the LAW list. Ideally, such accounts should have been deactivated before measurement, so their presence indicates a cleanup is needed.

Interpreting Engine Measurement Summaries

Beyond users, SAP licensing includes engines or package metrics – things like number of orders processed, number of payroll employees, database size, etc., depending on what SAP modules you use.

The LAW Engine Measurement Summary aggregates these metrics from all measured systems. Understanding this section is crucial because overusing engine licenses can be a huge cost factor.

What it shows: For each engine or package (usually identified by a name or metric in LAW), you’ll see a usage figure. For example, LAW might report “SAP Payroll – 8,000 personnel records” or “SAP SD – 50,000 sales documents.” This represents the total measured across the landscape for that metric.

How to interpret:

• Know your contract metric: Each engine has a specific unit of measurement defined in your contract (e.g., payroll is licensed by number of active employees, SD by sales documents per year, etc.). Make sure you understand what each LAW metric means in plain terms. If LAW says 8,000 personnel records, is that “8,000 employees” for your HR module? If it shows 50,000 SD documents, does that count all sales orders created?
• Compare to entitlements: Just like with users, compare the measured engine metrics against what you’re entitled to. If your contract allows 10,000 personnel records and LAW shows 8,000, you’re within limits. If LAW shows 12,000, you have a potential 2,000-unit overuse to address.
• Validate large variances: If an engine’s number surprises you (either very high or very low), investigate why. For instance, if “CRM Interactive Users” shows a count much larger than your number of sales employees, maybe a configuration counted something unintended. Or if “SAP BW Data Volume” spiked, was there a large data load or duplication? Check with the business or technical owners of that module to verify if the numbers make sense.
• Document the source: Note how each engine metric is calculated or where it comes from. Knowing the underlying measurement (e.g., which SAP transaction or table it’s based on) helps you repeat or explain the count. For example, be aware if “sales documents” includes quotes and orders, or only finalized orders. Understanding the scope ensures you and SAP are talking about the same thing.

Pitfall → Fix:

• Pitfall: Misinterpreting the metric definition. Perhaps you think “Number of Sales Documents” means only completed sales orders, but SAP counts all created documents (including quotes or canceled orders). This misunderstanding could lead you to believe you’re compliant when you’re not (or vice versa).
  Fix: Always confirm the metric definition from SAP’s official documentation or your contract. If something looks off, clarify which records are counted. You may discover that not all counted items should count toward licensing (e.g., test data or duplicates that can be excluded).
• Pitfall: Missing or incomplete engine data. Sometimes an engine doesn’t show up in LAW even though you use it (for example, a component wasn’t measured because it was inactive or not selected in USMM). This can lead to under-reporting usage that SAP might catch later by other means.
  Fix: Ensure your USMM configuration covers all relevant components. Double-check that no engine metrics were skipped due to a system role misclassification or an add-on not being included. If an engine should be measured but isn’t in the report, investigate and rerun the measurement if necessary – better to capture it now than have SAP find it later.

Checklist:

• List out each engine/package in the LAW report and cross-check it against your contract to confirm you haven’t missed any licensed components.
• For each metric, verify you understand what is being counted (documents, users, gigabytes, etc.) and that it matches how your contract defines that metric.
• Flag any metric that is over your entitlement or uncomfortably close to it. Those need attention – either plans to reduce usage or budget to true-up.
• If a metric result seems off, engage the relevant business owner or IT team for that module to verify the number. It’s better to resolve or explain an anomaly now than to have SAP question it later.

Understanding the License Shortfall Report

After you’ve consolidated everything in LAW and submitted the data to SAP (often through their online portal or by sending the LAW report file), SAP will generate a License Shortfall Report.

This compares what LAW reported versus what you’re contractually entitled to. Understanding this report is key to preparing your next moves.

What “shortfall” means: For each license type or engine, SAP’s report will list your entitlement (what you’ve paid for) alongside the measured usage from LAW:

• If measured usage exceeds entitlement, that’s a potential shortfall (under-licensing). For example, 120 Professional users measured versus 100 licensed, resulting in a 20-user shortfall. SAP will interpret that as you needing 20 more licenses (and they’ll be eager to charge for them).
• If usage is below entitlement, you have a surplus (over-licensing). For instance, 50,000 SD documents measured vs 60,000 licensed = 10,000 surplus. SAP typically won’t credit you for unused licenses, but a surplus is a sign you might optimize (you’re paying for more than you use).

Remember, the shortfall report is not a final bill. Think of it as SAP’s “opening move” in an audit. They’re saying, “According to our data, you’re short by X licenses.” It’s not set in stone – you have the chance to respond, explain, or correct the data before anything is final.

To navigate the shortfall report to your advantage, consider the following steps:

• Investigate each shortfall item: Don’t assume the shortfall is accurate; dig into why each gap appears. Often you’ll find the “extra” usage is inflated by data issues. Perhaps some “new” users are actually duplicate accounts or ex-employees that weren’t removed. Maybe an engine count spiked due to a one-time event or a misconfiguration, not ongoing business activity. Sometimes SAP’s default assumptions (like classifying every unclassified user as a Professional) overshoot reality. Identify these factors and address them (reclassify users, remove obsolete accounts, correct any measurement errors) to reduce the apparent usage.
• Provide context and push back: When discussing with SAP, be ready to explain anomalies. For example, “Yes, we show 20 Professional user shortfall, but 15 of those accounts belonged to temporary interns who are now removed — here’s the proof.” Or “The engine count exceeded because we migrated data to a new system during that period — it’s not typical ongoing usage.” This can lead SAP to reduce or waive certain findings if justified.

Insight: “SAP’s shortfall report is not a bill — it’s an opening move.”

Checklist:

• Cross-reference the shortfall report with your contract’s license inventory (what you’re entitled to). Ensure SAP isn’t comparing against outdated entitlement numbers.
• For each shortfall line, pinpoint the root cause of the discrepancy. Determine which users or transactions are driving the overage – this will form the basis of your explanation or remediation plan.
• Prepare a response document or notes addressing each shortfall. Include any mitigating facts (e.g., “those users have been removed” or “that spike was a one-time event during data migration”) to support your case.
• Engage your SAM or legal team to review the shortfall findings and your responses. They may spot additional angles (contractual nuances or data points) to help contest or clarify certain items.
• Be mindful of timing – SAP often expects a resolution (purchase or justification) within a set period after the audit. Use that time to your advantage by being thorough and strategic in your analysis.

Red Flags and Anomalies to Investigate

Even before you get a shortfall report, your LAW results might contain red flags that signal something is off. Keep an eye out for these common anomalies:

• Duplicate users not merged: If you notice the same or very similar usernames appearing twice (or an unusually high unique user count), it means deduplication might have missed some accounts. You’ll want to fix that by adjusting the matching criteria or merging those entries.
• Engine metrics that spike unreasonably: For example, if you normally process ~5,000 sales orders but LAW shows 15,000, find out why. Perhaps a test client’s data was inadvertently included, or a new interface generated a flood of documents. Big jumps without a business explanation are red flags worth investigating.
• Non-productive systems counted as productive: If a sandbox or test system’s data sneaked into LAW (for instance, if it was mistakenly flagged as productive in USMM), you could see phantom usage. E.g., too many users or documents that don’t align with real operations. Ensure each system’s role was set correctly.
• Over-classification of users: If almost everyone in LAW ended up classified as a Professional user when many of them probably have limited roles, something’s wrong. It could be that license classifications in some systems weren’t maintained (SAP defaults unclassified users to the highest license). This overestimation will inflate your compliance exposure needlessly.
• Technical/reference users counted as named users: A reference user (used for role templates) or background technical accounts usually shouldn’t count toward license totals. If they appear in LAW, your measurement configuration might be off – those accounts should be excluded or set to the correct license type that doesn’t count.

If you spot any of these anomalies, address them before submitting data to SAP. Often, it’s possible to correct the data (e.g., reclassify users, exclude a system, and rerun USMM) and regenerate the LAW report. Even if you can’t fully fix an anomaly by submission time, being aware of it means you can prepare an explanation for SAP.

Checklist:

• Review the LAW output line-by-line (especially the user listings) to catch duplicates or odd entries that a summary might hide.
• Use your internal SAM tools or reports to cross-verify totals. If your internal system says 800 active users but LAW shows 900, figure out where those extra 100 are coming from.
• Validate that all systems are correctly categorized (production vs. test) in USMM. A misclassified system can introduce data that shouldn’t be counted.
• If something doesn’t add up, escalate internally to your SAM manager or legal team before sending the report to SAP. It’s far easier to fix or clarify an issue upfront than to dispute it after SAP has the data.

Using LAW Results for Continuous Improvement

Interpreting LAW reports isn’t just a one-time audit task — it’s an opportunity to improve your SAP license management continuously. Here’s how you can leverage LAW insights beyond the audit:

• Track and trend usage: Keep each LAW report on file with notes about that period. By comparing results over time, you can spot trends (like certain license counts steadily rising). Early detection of license creep lets you correct course (for example, tightening user provisioning or cleaning up dormant accounts) before those trends become big compliance problems.
• Optimize and plan ahead: Use LAW insights to continually clean up and right-size your licenses. Regularly remove inactive users, downgrade users who have more access than they truly need, and address engines nearing their limits (archive old data, tune configurations). Also leverage these findings in contract negotiations – if you consistently underuse some licenses but exceed others, negotiate swaps or reallocations instead of buying new licenses.
• Align improvements with audits: Time your remediation actions so they show up in the next LAW cycle. For instance, if you plan to purge inactive accounts or fix user classifications, do it before the next USMM run. The subsequent LAW report will then reflect those improvements, demonstrating to SAP that you’ve proactively addressed the issues.

In short, treat the LAW report as a mirror of your SAP usage. Don’t just file it away after the audit — keep it handy to continually reflect on how you can improve license efficiency. Many savvy SAP customers even conduct internal “pre-audits” with LAW once or twice a year outside of official audits, just to stay on top of their license position.

5 Steps to Validate LAW Reports Before Submission

To wrap up, here’s a quick 5-step checklist to run through every time you prepare LAW results for SAP:

1. Verify user deduplication: Ensure no individual is double-counted across systems. Double-check LAW’s matching results so each person appears only once at the correct license level.
2. Cross-check classifications vs. HR data: Align LAW’s user counts with your internal records. Ensure the number of users in each license category aligns with your employee count and roles, and that high-cost licenses are only assigned where truly needed.
3. Confirm engine metrics definitions: Verify that each engine’s measured usage corresponds to the metric defined in your contract. Clarify any ambiguous metrics before submission (e.g., what exactly counts as a “document” or “user” for that engine).
4. Validate shortfall items internally: Don’t accept any apparent shortfall at face value. Analyze the underlying data for each overage. Correct any errors (like duplicate users or misclassified usage) and compile explanations for any legitimate overuse.
5. Get approval from SAM/legal: Have your Software Asset Management team or legal counsel review the LAW report and findings. A second set of eyes can catch issues you missed and will ensure you’re comfortable that the data is accurate. Only submit to SAP once you’re confident in the report and prepared to answer questions about it.

By following these steps and the guidance above, you’ll turn the LAW report from a daunting technical output into a strategic asset. It empowers you to go into SAP license discussions with confidence, armed with facts and a clear narrative of your usage. In the high-stakes world of SAP audits, a well-understood LAW report is your best defense — and even an opportunity to optimize your licensing for the future.

Read about our SAP Audit Services

fredrik.filipsson

Fredrik Filipsson is the co-founder of Redress Compliance, a leading independent advisory firm specializing in Oracle, Microsoft, SAP, IBM, and Salesforce licensing. With over 20 years of experience in software licensing and contract negotiations, Fredrik has helped hundreds of organizations—including numerous Fortune 500 companies—optimize costs, avoid compliance risks, and secure favorable terms with major software vendors. Fredrik built his expertise over two decades working directly for IBM, SAP, and Oracle, where he gained in-depth knowledge of their licensing programs and sales practices. For the past 11 years, he has worked as a consultant, advising global enterprises on complex licensing challenges and large-scale contract negotiations.

See Full Bio