If your organization uses SAP, a license audit is not a question of if but when.
SAP license audits are routine (often annual) and contractually mandatory, yet poor preparation can lead to multi-million dollar compliance findings. SAP’s audit approach is notoriously rigorous and often revenue-driven so being well-prepared is your best defense.
This means treating SAP’s own measurement tools (like USMM and LAW) as continuous compliance checks, not one-time chores.
Proactively using these tools (and newer ones such as SLAW2 and LMBI) helps you spot and fix license issues before SAP’s auditors do. Read our guide, SAP License Compliance 101.
In this guide, we’ll break down the SAP license audit process step by step, explain how each tool works, and share strategies to survive an audit with minimal pain.
SAP Audit Lifecycle – Step by Step
An SAP audit typically follows a predictable lifecycle with several key stages. Knowing these steps helps you plan and avoid last-minute scrambles.
Here’s a checklist of the SAP audit lifecycle in five steps:
- Notification: SAP sends a formal audit notification to your organization (often annually or per contract). This marks the beginning of the audit timeline and outlines the systems and license metrics that will be inspected. You usually get a few weeks to prepare.
- Measurement: You run SAP’s measurement program (USMM) on each relevant system. USMM captures user license data and engine metrics in that system. This step is crucial – it’s essentially a self-audit of usage.
- Consolidation: Next, you aggregate all system results using the License Administration Workbench (LAW, or its updated version SLAW2). This consolidates multiple USMM outputs into one combined picture, eliminating duplicate users across systems.
- Submission: You submit the consolidated LAW report (often an output file) to SAP for review. Typically, this is uploaded via SAP’s support portal or sent to SAP’s license audit team as instructed.
- Review: SAP’s audit team analyzes your LAW submission. They may seek clarifications or run their own checks. If significant discrepancies or shortfalls are found, SAP may escalate to an “enhanced audit” – a deeper dive that can involve SAP auditors scrutinizing your systems or requesting additional data.
These five steps make up the core audit cycle. The process might span several weeks or months from notification to final review.
By understanding the sequence, you can allocate time for each stage – especially the internal measurement and consolidation work where you have the most control.
In the next sections, we’ll dive deeper into the tools and tactics to manage these stages effectively.
USMM – System Measurement Basics
USMM (User and System Measurement Management) is SAP’s built-in tool for measuring license usage within a single SAP system.
Think of USMM as the “audit within the audit” – it scans your system’s user list and activity to propose what license type each user needs and counts certain usage metrics (engines).
Key points about USMM:
- How to run it: USMM is executed as a transaction (
USMM) in each SAP system (ECC, S/4HANA, etc.). When you run a USMM audit on a system, it gathers data on all named user accounts and any license-relevant “engines” (non-user metrics like documents or records). It then produces a measurement log/report for that system. - User classification: USMM automatically proposes a license type for each user based on that user’s roles and activity. For example, it might flag a user as a “Professional” user if they have broad access, or as an “Employee” or “Limited Professional” user if their usage is lighter. These proposals are a starting point – it’s up to you to review and correct them as needed.
- Cleanup before running: Crucially, prepare your user master data before measurement. Delete or lock inactive users (those who left the company or haven’t logged in for months), and ensure each active user is assigned the appropriate license type in their user master record. USMM will count every active user, so failing to clean up can inflate your counts. A common mistake is leaving old test accounts or ex-employees active – USMM will report them, potentially costing you licenses.
- Engine measurements: In addition to users, USMM collects data on various engine metrics specific to certain SAP modules (for example, number of sales orders created, number of employees in the HR module, gigabytes of database used, etc.). These figures are used to check compliance with module or package licenses (more on this in “Engine Measurements – A Critical Risk” below).
After running USMM, you should analyze the results in-house. Pay attention to any users classified as higher license types than expected – are they correctly classified, or do you need to adjust their role or license assignment?
This is your opportunity to identify and correct misclassified users before consolidating the data.
It’s perfectly fine (and recommended) to rerun USMM after cleanup to get a clean measurement.
In short, USMM is the foundation of your audit data – garbage in, garbage out, so take the time to get it right.
SAP Audit Defense Strategies: How to prepare for audits, handle interactions with SAP’s auditors, and successfully negotiate outcomes.
LAW – License Administration Workbench
Once you have the USMM data from all your systems, the next step is consolidation using LAW (License Administration Workbench), often referred to simply as the SAP LAW tool. LAW’s job is to combine multiple USMM results into one coherent report for SAP.
Here’s how LAW works and why it’s critical:
- Central consolidation: Typically, you run LAW in a central system (for example, Solution Manager or your main SAP system designated for consolidation). Using LAW, you import the measurement results from each system (USMM generates files or can transfer data directly). LAW then aggregates all that data.
- Duplicate user identification: In a multi-system SAP landscape, the same person often has user accounts in multiple systems (e.g., a user might have an account in ERP and another in BW). Without consolidation, that person would be counted twice. LAW automatically identifies duplicate users across systems – usually by matching user IDs or personnel numbers/email. It then merges them, ensuring each individual is counted only once, under the highest license type they require. For example, suppose John Doe is a “Professional User” in the ERP system and only an “Employee” user in another system. In that case, LAW will count John as one Professional user (the higher of the two categories).
- Adjustments and checks: You have some ability to adjust matching criteria and manually reconcile in LAW. If the same person uses different usernames in two systems, LAW might not catch that automatically – you may need to help it by mapping those users as one (if you know, for instance, that jdoe in one system is the same as john.doe in another). A best practice is to standardize user IDs across systems or maintain a central user ID reference to aid this process.
- LAW report generation: After consolidation, LAW produces a combined license audit report (sometimes called the LAW audit file). This displays the total number of unique users by license type across all systems, as well as combined engine metric totals. This consolidated output is what you ultimately submit to SAP’s auditors.
Using LAW is mandatory for most SAP audits if you have more than one system in place. SAP expects a single consolidated report, not separate system results.
Before submitting, scrutinize the LAW results internally: do the numbers make sense? Did LAW properly eliminate duplicates?
Resolve any anomalies now; you do not want to explain them to SAP later.
It’s often advised to run LAW and review it internally multiple times a year, not just when an official audit notice arrives. Regular use of LAW as a monitoring tool helps you avoid nasty surprises.
New Tools – SLAW2 and LMBI
SAP has introduced newer tools and features to improve the license measurement process beyond the classic USMM and LAW.
Two notable ones are SLAW2 and LMBI:
- SLAW2 (LAW 2.0): SLAW2 is essentially an enhanced version of the License Administration Workbench. It offers improved consolidation features and a more modern interface. With SLAW2, the process of combining user data is more streamlined, and it provides better analytics on your license distribution. For instance, SLAW2 might give you built-in reports or graphics to visualize license counts per system or identify anomalies more easily than the old LAW. If your SAP system supports SLAW2, it’s worth using for the audit consolidation stage as it can simplify duplicate handling and give deeper insight into your data. (In many SAP releases, transaction
SLAWmight open the new version after an upgrade, otherwise known as LAW 2.0.) - LMBI (License Management by Indicator): LMBI is a tool that leverages SAP’s Business Intelligence capabilities for license measurement and analysis. Traditional LAW focuses mainly on user counts, but LMBI goes beyond standard user metrics. It collects and analyzes specialized indicators – think of metrics like database size, CPU usage, or other module-specific usage indicators that affect licensing. LMBI is often used to measure aspects such as SAP HANA database usage (since HANA licenses can depend on memory size) or other engine metrics that a simple USMM snapshot might not fully analyze. The power of LMBI lies in its ability to do deeper reporting and scenario analysis. For example, you can use LMBI to simulate changes: “What if we reclassified 100 users from Professional to Limited Professional – how would our compliance position change?” or to see trends over time in user counts or document counts. This makes LMBI a great tool for internal audit preparation and optimization – you can plan license needs proactively rather than just reacting to the audit at hand.
In summary, SLAW2 and LMBI are there to give you better cross-system visibility and planning capability.
While USMM and LAW are enough to fulfill SAP’s audit requirements, leveraging SLAW2’s improved consolidation and LMBI’s analytical power can put you one step ahead.
They help turn what is normally a backward-looking compliance exercise into a forward-looking license optimization exercise.
Engine Measurements – A Critical Risk
When people talk about SAP audits, they often focus on user licenses – but “engine” measurements can be the real landmines.
Engines (also referred to as package metrics or secondary metrics) refer to license metrics that are not per-user, but rather based on usage volumes or capacities.
Examples include: number of sales orders processed, number of employees in the HR system, the database size or memory usage for a HANA database, number of “SAPs” (processing power units), etc.
These are measured during the USMM run and consolidated in LAW, and they are compared against the specific entitlements in your SAP contracts.
Why are engine metrics a critical risk?
- Unnoticed growth: Engine usage often grows with your business operations. You might have licensed 1,000 employees for SAP HCM a few years ago, but if your company grew to 1,200 employees, the system will report 1,200 – leaving you 200 over your license. Unlike user counts (where you generally know when you add a user), engine metrics can quietly creep up until an audit reveals you’re over the limit.
- Data inaccuracies: The raw counts SAP tools collect might include things that shouldn’t count against you. For instance, the sales order count might include test orders or orders later deleted. The employee count may include retirees or contractors who are not considered “licensed employees” under the contract definition. If you blindly accept USMM’s numbers, you could be over-counting. It’s essential to validate these engine measurements manually. Involve the functional owners: have HR confirm how many active employees should be counted, have sales operations confirm actual order counts, etc. Cross-check the system’s figures against real operational data.
- High cost of non-compliance: Engine licenses are often expensive, and overages here can generate massive compliance bills. SAP will treat any usage exceeding your contract as unlicensed, and you will need to pay for it (usually at list price). For example, if your license covers 500 GB of HANA memory and USMM/LMBI shows 600 GB in use, SAP could bill that 100 GB overage at a very high price. The same goes for extra employees or orders beyond what you bought.
To mitigate this risk, pay close attention to engine metrics in your measurement results. Don’t just focus on user counts. If an engine count is higher than your entitlement, investigate why.
It could be legitimate business growth (time to buy more licenses, hopefully negotiated at a discount), or it could be a data issue or misunderstanding (in which case, document the discrepancy and prepare an explanation for SAP).
Many companies have avoided huge penalties by catching an odd engine metric and addressing it before submission – for instance, cleaning up obsolete data or clarifying contract terms (e.g., some contracts allow excluding certain records from counts).
The key is: treat engine measurements with healthy skepticism and double-check everything.
Audit Preparation Best Practices
The best way to survive an SAP audit is not to treat it as a one-off fire drill. Instead, bake license compliance checks into your regular IT governance.
Here are some audit preparation best practices that SAP license administrators and ITAM/SAM teams should follow:
- Run internal measurements regularly: Don’t wait for SAP’s official audit notice to run USMM and LAW. Make it a routine to run measurements, perhaps on a quarterly or biannual basis. Regular internal “self-audits” will let you catch trends – for example, if a particular system’s user count is spiking or if a certain engine metric is nearing your license limit, you’ll see it early.
- Clean up user licenses proactively: Implement a process to keep your SAP user master data tidy. When employees leave or change roles, have procedures in place to promptly lock or remove their SAP accounts and update license type assignments if their usage changes. Consider periodic license reviews to identify dormant users (those with no logon in 90 days, etc.) and remove them. Also, reconcile duplicate accounts; if one person has somehow ended up with two SAP IDs on the same system, decide which to keep.
- Align roles with license types: Ensure that each user’s assigned license type in SAP actually matches their usage. For instance, a user performing advanced configuration or heavy transactions should be a Professional user, not a Limited Professional. Misclassified users are a red flag in audits – SAP’s tools will catch if a “low-level” user ran high-level transactions. Avoid that by classifying correctly from the start. Document your classification rules (e.g., which roles require which license category) so you can justify them to SAP if needed.
- Monitor indirect usage: Indirect access (third-party systems or bots accessing SAP data) is a notorious audit issue. Regularly monitor for technical or communication users and external interfaces that query or update SAP data. Use SAP logs, such as SAP Passport records or UBM (Usage Behavior Monitoring), if available, to identify data being created or read by external systems. This helps you address unlicensed indirect usage proactively – either by licensing it under SAP’s Digital Access model or redesigning the integration. (See Indirect Access vs Digital Access for a detailed comparison of how SAP covers these scenarios.)
- Involve functional teams: License compliance isn’t just an IT/Basis responsibility. Pull in HR, finance, sales, etc., for areas that correspond to license metrics. They can help verify numbers (as mentioned for engine metrics) and provide context. For example, if HR knows that 50 of the “active” employees in SAP are contractors who shouldn’t count per contract, that’s critical info. Or if Sales ops can explain that a spike in orders was due to test data, note that. Having functional input makes your audit submission more accurate and defensible.
Following these practices throughout the year creates a state of continuous compliance. It’s far less stressful to maintain compliance than to scramble in the 11th hour of an audit.
Below is a quick-reference table of common audit findings, why they happen, and how to prevent them:
| Common Audit Finding | Why It Happens (Root Cause) | How to Prevent It (Solution) |
|---|---|---|
| Duplicate user accounts counted multiple times | Same person has separate user IDs in different systems, leading to over-counting in LAW. | Maintain a central user ID strategy; use LAW/SLAW2 to consolidate and eliminate duplicates. |
| Inactive users still consuming licenses | Users who left or no longer need access remain active, inflating license counts. | Regularly remove or lock unused accounts; run cleanup before each USMM measurement. |
| Misclassified user license types | Users perform activities beyond their assigned license (e.g. an “Employee” user executing Professional-only transactions). | Align license types with actual usage; review user roles and adjust license assignments accordingly. |
| Untracked indirect usage (third-party access) | External systems or bots pull/push data from SAP without proper licensing, often unnoticed by user-based tools. | Monitor system interfaces and logs for indirect access; consider SAP Digital Access licenses or limit such integrations. |
| Engine metric overrun (exceeding capacity) | Business growth or data accumulation causes metrics like employee count, orders, or database size to surpass licensed amounts. | Keep an eye on engine usage trends; involve business owners to forecast changes and true-up licenses before an audit. |
By addressing the issues in the “Prevent” column proactively, you’ll eliminate the most common pitfalls that lead to audit findings. In essence, an ounce of prevention is worth a pound of cure when it comes to SAP audits.
Handling Audit Data & Submissions
After you’ve run USMM, consolidated results in LAW, and double-checked everything internally, it’s time to submit your data to SAP.
However, how you handle this phase can make a big difference in the outcome:
- Always review internally before submission. This point cannot be overstated. Never send raw USMM or LAW data to SAP without a thorough internal review. Look for anomalies one last time. For example, if LAW shows you 50 more Professional users than you thought, investigate why. If an engine metric looks off, dig into it. It’s much easier to correct errors or explain oddities before SAP gets involved.
- Document and add context: If there are any unusual circumstances reflected in the data, document them and consider adding explanatory notes in your submission. Some companies include a cover letter or notes for SAP, highlighting, for instance, “X number of our users are contractors who are inactive for half the year,” or “the spike in document count was due to a one-time data migration.” While SAP will ultimately go by the numbers, providing context can sometimes preempt further questioning and show that you’ve done your homework.
- Don’t be afraid to rerun measurements: Found an error after consolidating? Perhaps you realized you missed cleaning some users, or a system setting was incorrect. As long as you’re within the audit timeline given by SAP, you can correct the issue and rerun USMM/LAW to get updated figures. It’s better to take an extra day to fix data (and even inform SAP you needed to correct something and will submit slightly later if necessary) than to submit known-bad data. The audit should reflect your real usage as accurately as possible.
- Proactive negotiation: If your final LAW report shows you’re under-licensed (a shortfall), consider reaching out to SAP before they finalize the audit. Often, if you initiate a conversation like “we noticed we’re a bit short on licenses for module X – can we discuss adding those licenses?”, you may have more control. You might be able to negotiate a better commercial term or bundle it with other needs. Once SAP formally concludes an audit and issues a compliance letter, you lose leverage – it becomes a finding that you must resolve, sometimes with back-maintenance or penalties. Early, proactive negotiation keeps it a normal sales discussion rather than a compliance breach scenario.
Finally, once you submit, be responsive and cooperative with SAP’s auditors. They may have follow-up questions or want to schedule a meeting to review the results.
Respond with your data and documentation ready.
The goal is to demonstrate that you are in control of your licensing position. If you’ve prepared diligently, you should be able to address SAP’s queries confidently and avoid any nasty surprises.
FAQs
- Q: Is using LAW mandatory for SAP audits?
A: If you have only one SAP system, SAP might accept just the USMM report from that system. However, for organizations with multiple systems, using LAW (or SLAW2) is effectively mandatory. SAP’s audit instructions typically require a consolidated license report. LAW is the official tool to produce that, so in practice, yes, you should use LAW for audits to ensure all your systems are accounted for and duplicate users are resolved. - Q: Can LAW or SLAW2 detect indirect use of SAP?
A: Not directly. LAW/SLAW2 consolidates user license data, but indirect usage (when third-party applications access SAP without a named user) is not explicitly identified in a LAW report. Indirect use is usually detected through other means – SAP might analyze technical users, interface accounts, or use specialized Digital Access estimation tools to gauge document creation via external systems. It’s on you to monitor and disclose indirect usage. Don’t rely on LAW to catch it – LAW’s focus is on named user licenses. - Q: Should development or test systems be included in the measurement?
A: Yes, you should run USMM on all systems as instructed (including dev/test), but how you treat the data requires care. Generally, user licenses are only required for productive use, but the LAW consolidation will include all users from all systems to identify duplicates. Many users in dev/test are the same as in production (and will be consolidated), but if you have users exclusive to non-production systems, you’ll need to consider them. Often, SAP will not charge separately for purely non-productive users (since licenses usually cover a person’s use of any system). It’s wise to mark or document which systems are non-production and which users are test accounts. Include them in LAW to avoid duplicate counting, but you can footnote any purely test user counts so SAP knows they’re not end users performing productive work. - Q: What happens if my LAW results show a license shortfall?
A: If LAW reveals you have more usage than licenses (a shortfall), SAP’s auditors will likely flag it. Typically, they will inform you of non-compliance and expect you to purchase additional licenses to cover the gap (often including back maintenance fees for the period you were over). Before it gets to that, verify the shortfall – is it real or a data mistake? If it’s real, you can either dispute it (if you interpret the contract differently) or negotiate a license purchase. As mentioned, negotiating proactively is better than waiting. In some cases, if the shortfall is large or complex, SAP may escalate the matter to an enhanced audit or send an audit team to investigate further before finalizing. So, a shortfall isn’t the end of the world, but it will likely cost you unless you can prove the data was wrong or persuade SAP to waive some costs. - Q: Can I rerun USMM/LAW if I discover errors or make fixes?
A: Absolutely. Until you formally submit the results to SAP (and even then, if something major is wrong, you can discuss a re-run), you are free to rerun the measurement. In fact, SAP provides a window for the audit. If you realize, say, some user accounts were wrongly classified or an engine count included test data, you should correct those issues in the system and run USMM again, then update the LAW consolidation. The final LAW file you send should be based on the most accurate, cleaned-up data you can manage. Rerunning the tools to get it right is not only allowed, but also recommended.
Indirect vs. Digital Access – Deep Dive: Detailed comparison and guidance on choosing and managing the right model for your scenario.
Five Expert Recommendations
To wrap up, here are five expert tips to help you manage the SAP license audit process like a pro:
- Treat USMM/LAW as continuous compliance tools, not just audit tasks. Use them year-round to monitor your license position.
- Always clean inactive and duplicate users before measurement. It’s easier to fix data upfront than to explain it in an audit.
- Validate engine metrics with functional teams. Don’t take system counts at face value if they seem off – double-check with the business.
- Use SLAW2/LMBI for scenario planning and optimization. Leverage these advanced tools to foresee issues and optimize license allocations before you’re audited.
- Don’t submit LAW results until you’ve run your own reconciliation. Review everything internally and make sure you’re comfortable with the numbers and explanations.
By following these recommendations, you’ll not only survive your next SAP audit – you’ll turn auditing into an ongoing practice that keeps your organization one step ahead of SAP’s auditors.
Read about our SAP Advisory Services