SAP License Measurement Tools
Introduction – Why Measurement Discipline Matters
SAP license audits start with your own usage data. If your internal measurements are sloppy or incomplete, you hand SAP the upper hand in an audit. Small errors in counting users or engines can snowball into huge compliance gaps and unplanned costs. The key is discipline: measure your SAP environment as rigorously as SAP’s auditors would – before SAP asks. By maintaining tight control over license measurements, you preserve negotiation leverage and avoid overpaying for licenses you don’t truly need.
Keeping measurement data clean and accurate is a strategic defense. Misclassified users, duplicate accounts, or under-reported engines will all work against you in an audit. Adopting a proactive, skeptical stance toward SAP’s defaults ensures you’re not blindly accepting counts that inflate your compliance exposure.
In the guide below, we outline how to correctly run SAP’s native measurement tools (USMM and LAW), validate the results against your contracts, and use third-party Software Asset Management (SAM) tools for double-checking. The goal: preempt audit issues and always present SAP with data that is accurate, defensible, and contract-aligned.
USMM and LAW in Plain English
USMM (User Measurement) is SAP’s built-in tool for measuring license usage in a single system. When you run transaction USMM, it gathers two key data sets from that system: the count of named users by license type, and the usage of any modular SAP engines (packages) by their specific metrics. Essentially, USMM tells you how many users of each type exist in one system (e.g., ERP, CRM, BW) and how much of each licensed component that system is consuming.
LAW (License Administration Workbench), accessed via transaction SLAW or SLAW2, is the consolidation tool. In a multi-system SAP landscape, the same person might have user accounts in several systems. LAW aggregates the USMM results from all systems/clients and deduplicates users so that each human is counted only once at the highest license type they need.
LAW also sums up engine usage across systems. The end product is a single combined compliance report for your entire SAP landscape.
Think of USMM as your per-system “raw data” collection and LAW as the “merge and refine” step. SAP expects customers to perform an official measurement periodically (often annually) by running USMM in each production system, consolidating with LAW, and submitting the results. Internally, you should also run these tools in shadow mode (for your eyes only) to catch issues early.
The difference is that in an official run, you transmit the LAW results to SAP, whereas in internal runs, you do not – you use them to fix any misclassification or licensing shortfall beforehand.
Prepare the Ground – Contract & Landscape Baseline
Accurate measurement starts long before you execute any transactions. Preparation is about knowing your contract and your system landscape inside-out:
- Gather Your Contracts: Pull together your SAP contract documents, including the price list, specific user types you purchased, engine licenses, and definitions for each. You need clarity on exactly what a “Professional User” or a given engine metric means in your contract.
- Inventory Your Landscape: Document all SAP systems (SIDs) and clients in scope. Mark which are production, development, test, sandbox, training, or legacy systems. Note any Central User Administration (CUA) or Identity Management (IdM) in place that links users across systems.
- Map License Types: Align the user license categories in your contract to those in each SAP system. Sometimes system user types don’t exactly match contract names – make a mapping so you know, for example, that “Employee” in the system corresponds to “Employee Self-Service” in the contract.
- Engine Metrics Owners: For each licensed engine or package (like SAP Payroll, CRM, Business Warehouse, etc.), identify who in the business or IT is responsible for the data that will be measured. Document where and how that metric is tracked (e.g., HR module for employee count, Finance for sales orders count).
- User Policy and Naming Conventions: Review your policies on user accounts. Ensure you have clear definitions for dialog users vs. technical users, reference users, and how contractors or external users are labeled. Consistent naming or attributes (like Personnel Number, Email, or Global ID fields) will help later when deduplicating in LAW.
Preparation Checklist: Ensure the following are ready before any measurement run:
- ✅ Contract Documents: All license entitlements (user types, engine quantities) and definitions are on hand.
- ✅ System List: Every SAP production and non-production system is identified, with clients noted and usage (prod/non-prod) labeled.
- ✅ User Classification Rules: A current policy mapping job roles to the minimum license type, including rules for technical and reference users.
- ✅ Engine Data Sources: For each engine metric (users, documents, records, etc.), the source report or table is identified and accessible for measurement.
- ✅ CUA/IdM Links: If you have centralized user management, you have a mapping of user IDs across systems (e.g. the same HR employee ID or email is populated on all their accounts).
Preparing these elements creates a baseline. It’s your reference to validate the USMM/LAW results later against what should be counted per the contract. Now you’re ready to run the tools with confidence.
Running USMM Correctly — Step by Step
Executing USMM is not just pushing a button – it requires thoughtful setup and post-run review. Follow these steps to run USMM in each system properly:
- Select the Correct Price List: In USMM’s settings, choose the price list that matches your SAP contract. This ensures the tool uses the correct license category definitions. Pitfall: If you select the wrong price list (e.g., using an outdated default), the user classifications may map incorrectly to your contract. Always double-check that the price list matches your contract version or SAP product (ECC, S/4HANA, industry-specific lists, etc.) before running the measurement.
- Clean Up User Classifications: Before running the measurement, go to the User Classification screen in USMM (or via SU01 user maintenance) and ensure each user is assigned the appropriate license type. Apply these hygiene checks:
- Technical/Communication Users: Ensure that system, communication, and background users are marked correctly so they aren’t counted as dialog (named) users. Remove any logon privileges (GUI access) from these accounts.
- Reference Users: Verify that reference user accounts (used for role assignment templates) cannot log on. They should be classified typically as type “Reference” or equivalent and not counted as a named user.
- Test and Training IDs: Exclude or properly tag any training accounts or test users. If your contract allows, these might not need a paid license. At minimum, ensure they’re identified so you can explain them or exclude them in LAW consolidation.
- Duplicate Users in Same System: If one person has multiple user IDs in a single client (which is uncommon but possible), consolidate roles under one ID if feasible or at least classify both identically. This prevents an active user being double-counted due to a duplicate account.
- Measure Engines in USMM: When configuring USMM, ensure all relevant engines/packages are set to be measured. This might involve:
- Checking the component measurement selection in USMM for each product (e.g., SD documents, HR records, etc.).
- Running any ancillary reports for engines that require manual steps. For example, if an engine’s metric is “number of certain documents”, you might need to run a specific report to get that count.
- Coordinating with engine owners (identified in prep) to verify the data. For instance, have the HR team confirm the employee count or have the BI team provide the number of reports run if that’s a metric.
- Capturing evidence: take screenshots or export lists of the data that back up USMM’s engine counts. During internal runs, this evidence will help validate the numbers and is invaluable if questions arise later.
- Review and Freeze Results: After running USMM, you’ll get a summary of measurement results (users by type, engines by usage). Save or export these results for internal review. Do not transmit anything to SAP at this stage if this is a shadow (internal) run. Treat these results as preliminary:
- Export Data: Use the export functions (to a spreadsheet or PDF) to preserve the user counts and any unclassified users list.
- Analyze Anomalies: Look for anything unexpected – e.g., a user category count that jumped dramatically since last run, or an engine usage that seems off. Investigate before moving on.
- Lock It Down: Once satisfied, consider the results “frozen” for that period. You might even take screenshots ofthe USMM result screens for your records. This way, if changes happen in the system afterward, you still know what was measured.
USMM Common Pitfalls → Fixes:
- Pitfall: Using the wrong price list in USMM, leading to mis-mapped user types.
Fix: Always confirm the price list selection against your contract’s exact naming/version before each run. - Pitfall: Generic or technical IDs counted as full users (dialog).
Fix: Reclassify these accounts as System or Communication users and remove any dialog logon rights so they don’t require a named-user license. - Pitfall: Misuse of reference users (counted when they shouldn’t be).
Fix: Never allow direct login for reference users. If a reference user was used improperly, replace those logins with individual named users with appropriate roles/licenses. - Pitfall: Missing engine metrics in the measurement because nobody gathered the data.
Fix: Assign each engine to an owner before the run. Have them execute the necessary reports or checks, and input that data into USMM or record it as part of the measurement evidence.
By methodically addressing these pitfalls, you ensure the USMM output is clean. Now you have per-system data that you trust – the foundation for the next step, consolidation.
LAW Consolidation — Getting Deduplication Right
Once each system’s USMM results are ready, LAW (License Administration Workbench) combines them. The core challenge in LAW is deduplicating users across multiple systems so that one person = one license.
Here’s how to use LAW effectively:
- Collect USMM Files: From each system/client measured, download the USMM measurement file. In SLAW/SLAW2, import all these files into the LAW consolidation system.
- Define Matching Rules: LAW can automatically match user accounts it thinks belong to the same person. Set the matching criteria to something reliable across your landscape. Common dedupe keys include Personnel Number (if consistently maintained for user IDs), email address, or a unique Global User ID field. You can also match on username if your naming convention is standardized (though beware of differences in common names like “JOHNDOE” vs “JDoe”).
- Merge Duplicate Users: LAW will list suspected identical users across systems. Manually confirm these matches. For example, if
jdoein ECC andjohn.doeIn CRM, if the same personnel number or email exists, merge them. The tool then treats them as one user for license counting. Always roll them up to the highest license type that person has in any system. (If John is a Professional in one system and an Employee in another, the consolidated user should be counted as a Professional, one time.) - Handle Unique Exceptions: Sometimes the same person might have two accounts that don’t auto-match (e.g., different spellings, or a contractor with no personnel number). Prepare a pre-merge mapping if possible—a simple list of “User A in system X = User B in system Y”—and feed that into LAW or manually adjust. This standardizes identities so LAW can deduplicate correctly.
- Exclude Non-Productive Systems: If your contract allows excluding certain users (like those only in development or training systems), use LAW’s features to mark those systems/clients appropriately (such as flagging them as test systems). LAW can then exclude or separate those counts as needed. Ensure you only exclude what your contract explicitly permits – usually, all production users must be counted, while pure non-prod or duplicate test users might be ignored for licensing.
After merging users, LAW will produce a Consolidated User License Count (how many unique users of each license type across the whole landscape) and a Consolidated Engine Usage report (adding up all engines from each system). Review these carefully before considering them final.
LAW Pitfalls → Fixes:
- Pitfall: The same person isn’t recognized as one user because they have different user IDs in each system (e.g.
jdoevsjohn.d).
Fix: Define standard deduplication keys (such as personnel number or email) and do a pre-run cleanup. Populate missing fields or prepare a manual mapping to feed into LAW so it knows those accounts belong together. - Pitfall: Counting users from non-production or multiple client copies when it’s not necessary.
Fix: Mark test/training clients in LAW and exclude those from the consolidated count if allowed. Double-check LAW’s scope includes only the relevant clients (usually production and any client that has unique users doing productive work). - Pitfall: Over-counting a user’s license by assigning them the highest type in every system.
Fix: Use LAW properly to assign each person a single highest license across the whole landscape, not per system. One person = one license (the highest needed) no matter how many systems they access.
LAW Consolidation Checklist:
- ✅ All Systems Included: Confirm you imported measurement files from every in-scope system/client.
- ✅ Deduplication Rules Set: Document which fields you used for matching (username standard, personnel no., email, etc.) and ensure those are consistently maintained in user records.
- ✅ Manual Merges Done: Review LAW’s matching suggestions and manually merge or correct any it missed. No duplicate person should slip through.
- ✅ Non-Prod Identified: Systems or clients that are non-productive are flagged appropriately so their users are handled according to contract allowances.
- ✅ Peer Review: Have a colleague (Basis or SAM team member) review the consolidated results. A fresh pair of eyes might catch an odd user or a count that was overlooked.
Engines & Metrics — Don’t Wing It
Specific usage metrics measure SAP “engines” or package licenses, and you cannot afford to guess on these. Common examples include SAP Payroll (measured by the number of employees on payroll), SAP SD (measured by the number of order documents), or SAP BW (measured by data volume or reports).
To handle engines correctly:
- Know the Metric Definition: For each engine, read the contract’s exact wording. Does it count active employees, named users, business objects, transactions, or something else? The unit of measurement must be crystal clear.
- Pull the Actual Data: Identify where that metric lives. If it’s employees, maybe in the HR module or a table of active employees. If it’s orders, run a query for nthe umber of sales orders created in the year. Do this at the same period or snapshot that SAP would consider (often the current usage as of measurement date, unless the contract specifies an average or peak period).
- Deduplicate or Filter: Apply the contract rules to the raw count. For example, if counting documents, should you exclude test records or those in a holding status? If counting named objects, remove duplicates. Always align the data extraction with the contract’s scope (e.g., “productive employees only” or “orders excluding voided orders”).
- Document Evidence: For each engine metric, keep a record of how you got the number. Save the query, a screenshot of the result, or an exported list. This evidence backs up your self-declaration and can be provided if SAP challenges your figures.
- Cross-Verify: If the engine has an internal SAP measurement (some engines might automatically appear in USMM results), compare it to your manual count. Do they match? If not, figure out why (maybe USMM wasn’t updated or the engine not active).
Engine Measurement Pitfalls → Fixes:
- Pitfall: Assuming engine usage is covered by user counts (it’s not).
Fix: Treat engines as separate compliance items. Check each licensed engine’s consumption via its own metric source, independent of user licenses. - Pitfall: Counting everything without exclusions (“gross” count).
Fix: Deduplicate and exclude according to the contract. For instance, count active employees, not all historical employees; count completed documents, not those in test or demo clients. - Pitfall: Using the wrong time frame for usage.
Fix: Match the contract’s measurement period. If it says “concurrent users at peak” or “annual documents”, ensure you measure accordingly (e.g., peak concurrency or total for the year) rather than a random snapshot.
Every engine count should be as defensible as your user count. When in doubt, get clarification on metric definitions from SAP or through an expert, but never leave an engine unmeasured or assumed – that’s exactly where surprise audit fees can bite.
Shadow Measurement SOP — Internal Runs Before Audits
Don’t wait for SAP to announce an audit. Implement a shadow measurement routine to catch issues early and often.
Treat it like an internal license audit rehearsal:
- Regular Cadence: Schedule internal USMM/LAW runs every quarter. Additionally, do a special run 2–3 months before any known SAP true-up, renewal, or anticipated audit. This timing gives you a buffer to fix problems.
- Complete the Cycle: Run USMM in all systems, consolidate in LAW, and produce the full set of results without sending to SAP. Compare this against your last official submission or baseline. Where did things change? Are user counts creeping up in a certain category? Did an engine’s usage spike?
- Variance Analysis: For each internal measurement, have a brief internal meeting to review variances. For example, “We have 50 more Professional users than last quarter – why? Did a project go live, or did we classify more users correctly?” Understanding changes helps ensure they are legitimate and backed by license purchases or require action (like reassigning licenses).
- Remediation Plan: If the shadow run shows you’re over your entitlement in any area, immediately formulate a mitigation plan. This could mean archiving inactive users, purchasing additional licenses proactively, or optimizing classifications. The idea is to resolve it before SAP’s official audit.
- Internal Measurement Pack: After each run, compile a small report for leadership and record-keeping. This pack should include:
- An Executive Summary highlighting any compliance risks, major changes in counts, and potential cost impact if it were an official audit.
- User Classification Deltas: What changed in user counts per category since the last measure? Identify additions, removals, or reclassifications of note.
- Engine Metrics Evidence: The numbers for each engine alongside the screenshots or query extracts that support them.
- Deduplication & Exceptions: Note any special merges done in LAW or users excluded (e.g., test IDs) to ensure this logic is transparent.
- Action Items: A remediation or optimization plan for any issues found, such as cleaning up licenses, deactivating unused accounts, or requesting a contract extension for an engine metric.
This internal pack not only proves due diligence, but it also serves as audit defense material. If SAP challenges something later, you can show a history of measurement and fixes. Essentially, you’re continuously building an audit readiness dossier, not scrambling when the audit hits.
User Classification Playbook — Rightsize Before You Count
One of the most powerful ways to control license usage is through rigorous user classification. Don’t accept a user’s role at face value – challenge it and downgrade where possible before measuring:
- Role-to-License Mapping: Review what each user actually does in SAP and map their roles to the minimum necessary license type. If a user only runs reports or views data, perhaps they can be an ESS (Employee Self-Service) or a Limited Professional instead of a full Professional license.
- Downgrade Where Possible: Many companies find they’ve assigned everyone a Professional license by default. This is often overkill. Identify users who could be downgraded (with management approval) to a lower-tier license based on their usage patterns. This should happen in the user master data (license type field) before running USMM.
- Cull Inactive Users: Before measurement, identify any users who haven’t logged in for, say, 90 days or more. If they’re truly inactive, lock or remove them. They should not consume a license. Integrate with HR termination lists to ensure anyone who has left the company or changed roles is addressed promptly.
- Reclaim and Reassign: Implement a process with HR or managers to reclaim licenses from people who leave or no longer need access. This might involve an integration where HR’s leaving action triggers the SAP account lock. It ensures licenses can be recycled to new users rather than always buying more.
- Contractor and Partner Accounts: Separate external users (contractors, partners) into proper license categories. Often, these might require a special license type (or at least not be using a higher internal user license). Ensure these accounts are tagged so they can be reported on separately if needed.
Below is a quick reference mapping of user scenarios to appropriate license types. Use it to guide reclassification efforts:
| Usage Scenario | Suggested License Type |
|---|---|
| Training User (if contract allows) or temporarily assigned a minimal license | Professional User (or SAP Functional User) |
| Shop-floor data entry or confirmations only | Worker User / Employee Self-Service (low-tier license) |
| Read-only reporting and inquiries | Limited Professional or ESS (per contract definition) |
| Interface accounts, background jobs (no interactive login) | Technical/Communication User (no named user license needed for purely non-dialog use) |
| Training accounts (for internal training systems) | Training User (if contract allows) or temporarily assigned minimal license |
Always cross-verify any suggested downgrades with your contract definitions, as license terminology can vary. The principle is to give each user the cheapest license that still covers their activities – nothing more.
Non-Prod, Training, and Reference Users — Control the Gray Areas
Certain user accounts fall into gray areas of licensing. It’s crucial to manage these carefully and document how they are handled:
- Non-Production Systems: Users that exist only in development, test, or sandbox systems often do not require a license if they’re not performing productive work. However, if a user is in both prod and non-prod, they count. Enforce policies that non-prod systems are for configuration and testing only (no real business transactions). Use SAP’s system measurement settings to flag these systems appropriately, and keep evidence (like a brief report) that shows no productive data is processed in them, in case SAP inquires.
- Training Users: If you create special training accounts for classes or practice, ensure they are time-bound and restricted. For example, you might create 20 training users that are valid for a two-week course, then lock or delete them. These should have minimal roles and never be used in production. Document their use and ensure they are excluded from measurement when permitted. If not allowed to exclude, treat them as a separate category, you can explain to SAP with dates and purpose.
- Reference Users: These are template accounts used to assign roles to other users. A reference user should never log in on its own. Ensure all reference users in your system have no password or are locked for the dialog. Monitor user logs to confirm no one used them interactively. Also, be mindful: roles assigned via a reference user still count toward the license of the person who inherits them. And from an audit perspective, SAP might want to know that reference users aren’t a loophole to pool licenses – so keep the usage clean and well-documented.
Gray Areas Checklist:
- ✅ Non-Prod Documentation: Maintain a list of all non-production clients and a note on their usage (e.g. DEV, QA, Sandbox) with a statement that no business operations occur there. Use this if needing to justify excluding those user counts.
- ✅ Training User Controls: Have procedures to create training users with expiration dates, and to remove or lock them immediately after training. Keep a log of when they were active and for what purpose.
- ✅ Reference User Policy: Write down the policy that reference accounts cannot be used to log in, and periodically audit that they haven’t. Keep logs or reports showing zero dialog logins for these accounts. If a reference user accidentally got used, document the incident and resolution (e.g., create proper user accounts instead).
Tightly managing these special cases closes off common audit loopholes. SAP auditors know to look at these areas, so you should be one step ahead with clear controls and evidence.
When (and How) to Send to SAP
At some point, you’ll perform an official measurement for SAP. This might be an annual requirement or a triggered audit.
Approach this submission with formality and caution:
- Timing: Only execute the official LAW consolidation and submission when you’ve internally vetted the data. Ideally, this is after a recent shadow run that looked good. Avoid running right after major changes or go-lives; stabilize first.
- Team Review: Before sending, conduct a two-person (or more) review. For example, the SAP Basis administrator who ran the measurement, along with a SAM or IT asset manager, should cross-verify the numbers. It’s wise to also have someone from procurement or legal involved, especially to ensure the results align with contract expectations.
- Preserve Evidence: Take screenshots of the USMM results in each system, the LAW consolidated summary, and any engine measurement details. Save the measurement logs and export files. Essentially, create an archive of exactly what you are about to submit. This “evidence pack” is part of your audit defense if, later, there’s a dispute about what was reported.
- Transmittal Log: Record the details of the submission – who transmitted it, on what date, via which method (LAW upload, email to SAP, etc.). Keep copies of any files sent. If SAP provides an upload portal, ensure you get confirmation of receipt.
- Add a Cover Note: It’s often helpful (and within your rights) to include an interpretation letter or notes along with the raw data. For example, explain any anomalies: “We have excluded X training users in client 900 per agreement with SAP in past true-up,” or “Engine Y usage was measured manually due to known tool limitation; see attached document.” This sets the narrative and shows SAP you are on top of the details.
Do’s and Don’ts at Submission:
- Do ensure all stakeholders (IT, SAM, finance, legal) agree on the numbers before sending. Once submitted, it’s hard to walk back data.
- Accompany the submission with your notes or a summary that highlights you followed the contract definitions closely. This flags to SAP that you are an informed customer.
- Don’t simply accept if SAP comes back with different interpretations of the data. For instance, if they try to count a user twice or reclassify your users into higher categories, push back by referencing the contract and the evidence you saved.
- Don’t ever send raw measurement data without reviewing it thoroughly. A rushed submission is almost guaranteed to contain something SAP can question.
When done properly, the official submission becomes a non-event – essentially a repeat of what you’ve already practiced internally. And because you have kept meticulous records, you can answer any questions SAP might raise.
Third-Party SAM — Cross-Checking Your Numbers
Leverage third-party Software Asset Management (SAM) tools as a second line of defense for your SAP license compliance. Tools like Flexera, Snow License Manager, USU, or ServiceNow SAM can greatly enhance your oversight:
- These SAM tools can import SAP USMM/LAW data directly, automating what might otherwise be a manual analysis. For example, after you run LAW, you can load the results file into the SAM tool to crunch the numbers.
- SAM solutions maintain a repository of your entitlements – you input your contract quantities for each license type and engine. The tool then compares measured consumption vs. entitlements, highlighting any overuse or underuse.
- Many tools offer role-based license optimization suggestions. They can analyze user roles and actually recommend a more appropriate license type (similar to our playbook above, but automated). This cross-check can validate your own classification decisions or spot ones you missed.
- What-if modeling is another benefit: you can simulate changes, such as “What if we convert 100 Professional users to Limited Professional?” and see the compliance outcome. This is great for planning remediation before an audit or preparing for contract renewals.
- SAM reports can also provide audit trails and trend charts. Use these to show, for instance, how your license usage is trending down due to proactive management – a story that can be useful in negotiations.
To integrate SAM tools into your process, ensure the following:
SAM Integration Checklist:
- ✅ Data Connector: Set up the connector or process to pull USMM and LAW results into the SAM tool regularly (e.g., quarterly after each shadow run). Verify that this data transfer is working and accurate.
- ✅ Entitlement Entry: Enter your purchase records into the tool – how many of each user type, how many engine units you own. Keep this up to date with any new purchases or swaps.
- ✅ License Rule Alignment: Configure the SAM tool’s classification rules to match your contract. For example, if your contract defines a certain user type differently, ensure the tool knows that for accurate suggestions.
- ✅ Exception Handling: Have a process for any discrepancies the tool finds. If the SAM tool flags a user classification that doesn’t make sense, investigate and resolve it (either adjust in SAP or mark as exception with justification).
- ✅ Reports & Sign-offs: Regularly review the SAM-generated compliance reports with your team. Treat it as a validation step. If the tool’s results differ from your manual analysis, reconcile the differences until you trust the output. Then use those reports as additional evidence of diligence.
While SAP’s own tools are the official source of truth in an audit, third-party SAM tools give you an independent perspective. Think of them as your watchdog – they might catch what you overlooked, and they provide a structured way to manage licenses continuously.
Governance — Make Measurement a Habit, Not an Event
The final piece of audit readiness is governance – embedding these practices into regular IT operations and corporate policy.
This shifts license compliance from a once-a-year fire drill to a routine business process:
- Policy and Schedule: Establish a formal policy for conducting SAP license measurement internally every quarter, and implement an official submission process with due diligence whenever required. Put these on the IT compliance calendar. For instance, “Q1, Q2, Q3 internal checks; Q4 official measurement submission” could be a standard cycle.
- Clear RACI: Define who is responsible, accountable, consulted, and informed for each part of the measurement. Who classifies new users when they are created? Who runs USMM in each system? Who consolidates in LAW? Who reviews the results and approves them? By assigning these roles (Basis team, SAM manager, etc.), you avoid gaps and finger-pointing later.
- Align with Business Changes: Integrate license measurement tasks with business events. For example, whenever a large project goes live or a new module is deployed, run a quick license impact check. Tie regular measurements to HR updates (so new hires or leavers are reflected) and to just before contract renewals (so you negotiate from current data).
- Controls and Audits: Incorporate a “four-eyes” principle – at least two people must review any data before it’s considered final. Maintain an evidence archive (your measurement packs, screenshots, SAM reports) in what some call the “contract bible” – a repository of all key licensing documents and proofs. Periodically, do an internal audit of the process itself: ensure that last quarter’s measurement was done on time, that all checklists were followed, and that any issues found were tracked to resolution.
By normalizing these practices, you create an organizational muscle for license compliance. It won’t feel extraordinary or rushed when SAP knocks on the door; it will just be another well-rehearsed routine.
Audit-Ready Governance Checklist:
- ✅ Recent Internal Audit Completed: The latest shadow measurement run was performed and approved by the responsible parties.
- ✅ Documented Remediations: Any compliance issues identified (extra users, engine overages) have action plans, and those plans are being actively managed.
- ✅ Evidence Archive Updated: All measurement results, decisions, and communications are saved in a central repository for quick retrieval.
- ✅ Continuous Improvement: Lessons learned from each cycle (e.g., a user type that was hard to classify, or a tool glitch) are noted and the process adjusted. The process today should be better than it was last year.
With strong governance, you shift from reactive scramble to proactive control. SAP compliance becomes a managed process like any other, reducing risk and avoiding nasty surprises.
Related articles
- SAP LAW & USMM Overview: How SAP’s License Measurement Tools Work Together
- Running SAP USMM for Self-Audit: How to Gather Accurate License Data
- Using SAM Tools with SAP: Managing Licenses Beyond USMM and LAW
- Avoiding Measurement Errors: How to Prevent Costly Mistakes in SAP License Audits
- Interpreting LAW Reports: How to Read SAP License Measurement Results Correctly
5 Measurement Tactics to Stay Audit-Safe
- Align USMM to Your Contract: Always set USMM to the correct price list and license definitions according to your SAP contract – never rely on SAP’s default settings alone. This ensures your user counts are measured on your terms, not SAP’s assumptions.
- Deduplicate with Precision: In LAW, use stable global identifiers (personnel numbers, emails, etc.) to match accounts and count each person once. Meticulously merge duplicates so one person = one license across the landscape.
- Validate Engines Quarterly: Don’t skip engines in your measurements. Every quarter, have owners verify each engine’s usage with real data and evidence. Cross-check these metrics against contract definitions so you’re confident in every number reported.
- Run Internal Audits Before SAP: Treat every internal measurement as a rehearsal. Identify and fix misclassified users, inactive accounts, and overuse before SAP ever sees the data. By the time you submit to SAP, it should contain no surprises for you.
- Never Send Data Without Context: Accompany your official LAW report to SAP with a management-approved narrative or cover letter. Explain how you measured and interpreted the contract. Don’t allow SAP to redefine your results without referring back to the contract and the evidence you’ve prepared.
Read about our SAP Audit Services
