Technical Cleanup Before Audit: Ensuring Your SAP Systems Are Audit-Ready

Introduction – Why Technical Cleanup Defines Audit Outcomes

“If SAP’s audit tools see dirty data, you’ll pay for dirty data.” This adage captures the high stakes of SAP license audits. Technical cleanup is the single most effective cost-prevention measure before an SAP audit.

When SAP’s audit tools (like USMM for system measurement and LAW for consolidation) Scan your systems, they will count everything – every user ID, every package usage, every configuration quirk. If that data is “dirty” (obsolete users, misclassified roles, duplicated accounts, etc.), you risk inflated license counts and unwarranted fees.

By contrast, if your data is clean and accurate, you maintain control over what SAP “sees” in the audit. For more SAP audit checklists, read our overview SAP Audit Preparation Checklists: Ready Your Team, Systems, and Contracts.

Technical cleanup should be part of standard SAP governance, not a last-minute scramble.

Many organizations get caught off guard by small configuration issues or idle accounts that balloon their license compliance gap. Regular housekeeping ensures that when audit season arrives, there are no surprises.

In fact, a sudden mass cleanup right before an audit can raise red flags – SAP’s reports can reveal recent deletions or changes, potentially inviting scrutiny. It’s far better to treat cleanup as an ongoing practice so your system is always audit-ready.

The following sections provide a step-by-step technical checklist for SAP Basis and ITAM/SAM teams to execute before any SAP audit, focusing on eliminating the common technical pitfalls that lead to over-licensing or compliance disputes.

Pre-Audit System Validation Overview

Before diving into individual cleanup tasks, it helps to know the key focus areas of technical cleanup. Pre-audit validation spans multiple aspects of your SAP landscape, each with a specific objective and an ideal timing.

The table below summarizes what to cover:

These focus areas form the foundation of audit-ready systems. User Data cleanup keeps your named user counts honest. Role Alignment ensures each user is categorized to the right license type. Engine Data validation prevents over-counting of modular metrics (like documents or employees).

Keeping up with SAP Notes means your measurement tools aren’t using outdated logic. Lastly, setting correct System Roles (Prod vs. Test) avoids counting non-productive systems in license totals.

Before an audit, perform a holistic review across all these areas. Consider this your pre-audit system health check. Below is a quick validation checklist to ensure nothing is missed:

• All systems updated with the latest SAP license measurement notes and patches.
• System roles (Production, Quality, Development, Sandbox) are correctly designated in each system’s settings.
• Master SAP user list reviewed, cleansed, and approved by the business (no surprise users).

Each of the following steps dives into one of these focus areas with practical actions and checkpoints.

Step 1 – Cleaning Obsolete and Inactive User IDs

Inactive users are a top cause of inflated license counts. SAP’s named-user licensing counts every active user ID, even if the person hasn’t logged in for months.

Old accounts for former employees, contractors, or test users can needlessly push your license count over entitlements. Removing or locking these accounts ahead of an audit immediately reduces risk and cost.

For example, if 10–15% of accounts haven’t been used in a year, deactivating them can significantly drop your license usage. This cleanup should be routine (quarterly) and part of HR offboarding, so you’re not scrambling to do it all at audit time.

Action Steps:

1. Run transaction SUIM (User Information System) and use the Users by Last Login Date report. Identify all user accounts that have been inactive for more than 90 days (or your policy-defined threshold).
2. Review the list of inactive users and cross-check with HR or department managers to confirm these accounts are truly obsolete (e.g., the employee left or no longer needs access).
3. Deactivate or delete the confirmed obsolete user IDs. (Deactivation is safer if you want to retain history; deletion can be used for clearly duplicate or test accounts after proper backups.)
4. Document the changes and obtain necessary approvals. Verify with HR/user managers that each deactivated account has no business justification to remain active. This ensures alignment between IT and business before removal.
5. Before the next license measurement (USMM), double-check that these users are indeed locked or deleted in the system so they won’t appear as active in the audit data.

Pitfall Examples & Fixes:

• Pitfall: Old project accounts kept “just in case.” Fix: Archive their data if needed with HR approval, then remove or lock them so they are out of the active measurement scope.
• Pitfall: Shared or temporary training accounts left active. Fix: If truly needed for training, convert them to type “Training/System” users not counted in license audits, or preferably delete them entirely after use.

Checklist:

• Run SUIM login analysis and list all users with no logins in the last 3+ months.
• Review exceptions with HR or managers (ensure no recently transferred users or special cases are mistakenly removed).
• Deactivate or lock all obsolete IDs across all clients/systems.
• Confirm the cleanup results before executing USMM, ensuring these users no longer count toward license totals.

By cleaning up inactive users, you eliminate “shelfware” licenses and make sure you’re not paying maintenance on accounts nobody uses.

Pre-audit checklist, Pre-Audit Internal Review Checklist: How to Prepare 6–12 Months Before an SAP Audit.

Step 2 – Validating User Roles and License Types

Misaligned user roles and license classifications can cause over-licensing. SAP audit tools assume each user should be counted at the highest license level unless you prove otherwise.

For instance, if a user is performing only self-service tasks but is classified (or defaulting) as a Professional user, you’re unnecessarily allocating a premium license.

The goal is to ensure each user’s assigned license type matches their actual usage before the audit.

Action Steps:

1. Review your current role-to-license mapping. Identify what license type (Professional, Limited Professional, Employee Self-Service, etc.) each business role or job function in your organization should correspond to. If you haven’t documented this, create a mapping matrix now.
2. Using transaction ST03N (Workload Analysis) or SUIM’s user statistics, analyze what transactions and activities users actually perform. Compare actual usage against their assigned roles and license types. This helps spot mismatches (e.g., a user with limited display activity classified as Professional).
3. Reclassify or downgrade users who are performing limited functions. For example, if a user only runs reports or uses ESS/MSS, consider assigning a Limited or Employee license instead of a full Professional license. Likewise, upgrade any users who are clearly doing more (to avoid under-licensing).
4. Ensure every user in SAP has a license type set in their user master record (SU01). No user should be “unclassified” or left with the default classification. If a user has no license type, SAP will count them as a Professional by default – an expensive mistake. Assign the correct license type for all users now.
5. Document all classification decisions and maintain the mapping rules. This documentation will serve as evidence in an audit to show how you determined license assignments based on roles and usage. It provides traceability and helps defend your position if SAP challenges a user’s license category.

Insight: SAP’s audit assumes all your users are premium until proven otherwise – your job is to provide that proof through proper classification and usage data.

Checklist:

• Verify that users labeled “Professional” truly require that level based on their job duties (e.g., they perform broad create/change transactions).
• Reclassify low-usage or read-only users to cheaper license categories and adjust their roles if necessary to align with those licenses.
• Maintain a license mapping matrix (roles → license type) and an audit trail of any changes. Ensure this is up-to-date and approved by management for audit transparency.

By validating roles and license types now, you prevent SAP from automatically counting all users at the highest license cost. You take back control by right-sizing each user’s license before the auditors do it for you.

Read our SAP Audit communication plan, Audit Communication Plan: Managing Internal Alignment and SAP Auditor Engagement.

Step 3 – Consolidating Duplicate User Accounts

Many SAP customers have multiple systems (ERP, BI, CRM, etc.), and often the same person has user accounts in each. If not handled, those duplicate accounts can lead to double-counting in an audit. SAP’s License Administration Workbench (LAW) is designed to merge such duplicates, but it relies on consistent data.

A little effort in consolidating and cleaning up duplicate users ensures that each person is counted as one license in the audit report, not several.

Action Steps:

1. Identify potential duplicate users across your SAP landscape. Use unique personal identifiers such as Personnel Number, corporate email address, or HR ID to find users who likely represent the same individual in different systems. For example, if Jane Doe has user IDs JDOE in ECC and JOHN.DOE in CRM, those need linking.
2. Normalize and consolidate these accounts wherever possible. This could involve aligning the usernames (using a standard naming convention) and ensuring each user’s Personnel Number or global user ID is maintained consistently in all systems. In some cases, you might use SAP’s Central User Administration (CUA) or Identity Management tools to unify accounts.
3. Coordinate with HR or your identity management team to reconcile records. Make sure the SAP user accounts correspond 1:1 with actual people in your HR system. Each employee or contractor should have a single SAP identity used across environments, to the extent possible.
4. Configure and test consolidation rules in LAW. Before the official audit, run an internal LAW consolidation using the USMM results from all systems. Check that LAW is correctly merging the duplicates you identified. If the same person still shows up twice in the LAW output, adjust the criteria (for example, ensure the Personnel Number is entered in all systems for that user).
5. Fix any remaining duplicate issues by either deleting redundant accounts (if no longer needed) or by marking them as reference users/non-license-required (if they must exist for technical reasons but shouldn’t count for licensing).

Pitfall Examples & Fixes:

• Pitfall: The same person exists with slight variations (user JDOE vs. JOHN.DOE) in multiple systems, causing multiple counts. Fix: Implement a standard naming convention and fill a common field (like Personnel Number) on all accounts so LAW can recognize them as one user.
• Pitfall: Contractors or consultants given separate logins for each client or project. Fix: Assign a single global user ID per person or leverage external user IDs that persist, and use that consistently. Alternatively, deactivate extra accounts between projects and only keep one active at a time.

Checklist:

• Merge or eliminate duplicate accounts in SAP and ensure each active user corresponds to a unique person in the organization.
• Perform a trial LAW run internally to confirm that duplicate users are consolidated into one entry (resolving any anomalies before SAP’s audit LAW run).
• Document your deduplication approach and results. Keep a record of how many duplicates were found and resolved – this evidences your proactive compliance effort and can be shared if auditors ask about discrepancies.

Through duplicate consolidation, you prevent license inflation caused by one user consuming multiple licenses. It ensures the audit data reflects reality, not account proliferation.

Step 4 – Validating Engine (Package) Measurement Data

SAP “engines” or package licenses are measured by specific usage metrics (transactions, records, users, etc.), and these metrics can often be overcounted due to misconfiguration or lack of exclusions. For example, a Sales & Distribution (SD) documents engine might be counting test orders, or a Payroll engine might include terminated employees.

Small overcounts here can translate to huge costs, since engines are typically priced per volume. Every extra 10% in an engine metric can multiply into six figures of audit exposure. It’s critical to verify that all measured engine data is accurate and within scope.

Action Steps:

1. Review the list of engines/packages that your SAP systems report in USMM. Identify which licensed engines (e.g., SAP Payroll, SAP CRM, SAP Database, etc.) are being measured and what metric each uses (employees, documents, CPU cores, etc.).
2. For each engine, validate the measurement logic with the relevant business or technical owner. Ensure that the counting is aligned with your contract definition. For instance, if “SAP Payroll” should count only active employees, confirm that the number USMM reports matches your active HR employee count (and not including retirees or contractors if they shouldn’t count).
3. Exclude or adjust for any non-productive or irrelevant data. Often, test clients or historical data can sneak into engine counts. If an engine count includes development clients or year-old documents that aren’t in scope, apply notes or settings to exclude them. Work with Basis to configure measurement user exits or exceptions if available (or simply cleanse outdated data that’s unnecessarily counted).
4. Compare current engine usage metrics to previous periods or expected values. If you see a sudden spike in a metric, investigate it before the audit. It could be a genuine business growth (which might requirea true-up) or it could be an error (e.g., a duplicated data load). Understanding the cause of any jump lets you either correct it or prepare an explanation/defense for SAP.
5. Engage the business owners to cross-verify the numbers. For example, have HR verify the employee count, have sales operations verify the number of sales documents in the period, etc. This cross-check ensures the technical measurement aligns with real-world usage.

Checklist:

• Confirm each active engine’s metric counts are within the bounds of your contract entitlements (no hidden overage).
• Verify the accuracy of queries and inclusion/exclusion logic for engine measurements (no test or duplicate data being counted as production).
• Document the validation results for each engine. Note any adjustments made or any assumptions (e.g., “excluded client 400 test data from SD documents count on mm/dd”). This documentation can be vital during an audit review.

By validating engine metrics, you catch costly discrepancies in advance. You don’t want to discover during the audit that a trivial configuration issue caused an inflated count of documents or users in an engine – by then, it’s a costly conversation. Proactive verification ensures you only pay for true business usage.

Step 5 – Applying SAP Notes for Measurement Accuracy

SAP periodically updates its license measurement tools (USMM and LAW) via SAP Notes. These notes correct bugs or adjust how users and engines are counted.

Running license measurement on outdated software can produce incorrect results – for example, counting a user multiple times due to a known bug, or not recognizing a new license type properly.

To ensure accuracy, always apply the latest relevant SAP Notes for measurement before conducting an audit.

Action Steps:

1. Check SAP support for the latest measurement correction notes applicable to your SAP release. Look for notes related to USMM, LAW 2.0, and specific engine measurements. (For example, SAP Note 1796415 and 2738426 are known notes that addressed user classification and LAW consolidation issues in certain versions – your landscape may have analogous notes.)
2. Have your Basis team apply these SAP Notes or the corresponding support packages promptly, ideally well before the audit period. Treat these like critical patches; schedule them in a maintenance window and ensure they are transported to all relevant systems.
3. After applying the notes, re-run USMM in a test mode or on a subset of systems to confirm that the measurement output looks correct and that known issues are resolved. For instance, if there was a note fixing how a particular engine is counted, verify that the engine count changed as expected.
4. Keep track of which notes were applied (note numbers and descriptions) and when. This can be mentioned to auditors if there are questions about discrepancies between previous measurements and current results – you can explain that SAP’s update corrected a known issue.

Pitfall: Running USMM/LAW on old logic or without fixes. Fix: Always synchronize your measurement tools with SAP’s latest recommendations. If you skip these notes, you might count things the old (wrong) way and end up negotiating based on inflated figures.

A common example is not having a note that excludes locked users from counting or one that updates license category definitions. Missing these can directly increase your audit exposure.

Checklist:

• Basis team has applied all relevant SAP license measurement correction notes for your system version.
• A test measurement run was executed after the note application to validate that counts and classifications align with expectations.
• All changes are documented (including notes, date applied, and effect on measurement). Keep this record in your audit readiness file.

Staying up-to-date on SAP’s measurement logic is an easy win – it ensures you’re on a level playing field with SAP’s auditors, running the same version of the tools they will use.

Step 6 – System Role Validation (Productive vs. Non-Productive)

Not all systems are equal in an audit. Only productive systems (where real business operations occur) should count toward license usage, whereas development, test, or sandbox systems often do not require licenses for their users.

However, this only holds if those systems are properly flagged as Non-Production. If a QA system is mistakenly classified as “Production” in the measurement configuration, its users might be counted as if they all need licenses, skewing the results. Ensuring each system’s role is correctly set is a simple but crucial step.

Action Steps:

1. Inventory your entire SAP landscape and verify the designated system type/role for each instance. In each SAP system, check the system measurement settings (in USMM or system properties) to see what role it’s marked as: Production, Test, Development, Training, etc.
2. For every non-productive system (e.g. DEV, QA, Sandbox, Training clients), update the settings to clearly mark it as Test/Non-Production. SAP usually allows a flag or selection for system role which then reflects in the measurement logs. This ensures when you run USMM, it knows these systems are non-productive and their data can be treated accordingly.
3. Adjust your LAW consolidation input so that only productive system results are included in the final consolidated report. LAW has options to exclude or separately categorize non-prod systems. Utilize these so that even if you measure all systems (which is good practice internally), the numbers you report or focus on for compliance are only from production systems.
4. Double-check user counts in non-productive systems for reasonableness. Non-prod systems often have generic users or copied users from production for testing. If those appear in measurement, ensure they won’t be counted. (For example, a developer with 10 test accounts shouldn’t count 10 times. Proper system role marking and LAW settings prevent that.)
5. Maintain a system landscape document that lists every system, its system ID, client, and role (Prod or Non-Prod), and keep it handy. This can be shared with auditors to clarify your scope. It also helps new team members quickly understand which systems contribute to license counts.

Checklist:

• Updated the role/classification of each SAP system in USMM or configuration (no system incorrectly left as “Production” if it’s not).
• Verified that non-production systems are either excluded from LAW or set not to contribute to license totals.
• In each USMM measurement XML or log, confirm that the system is labeled correctly (e.g., “Test system – results not added to total”). This serves as proof that your settings are correct.

By validating system roles, you avoid a scenario where test or development users artificially inflate your license count. It draws a clear line for auditors: “These are our production usage numbers, and those other systems are for non-productive use.” Clarity here means fewer arguments later.

Step 7 – Pre-Audit Validation Run

After performing all the cleanups and configurations above, it’s time for a dry run – essentially, a full internal audit simulation. This final step is about verifying that all your cleanup actions achieved the desired result: an accurate license count.

Think of it as a dress rehearsal where you control the narrative, rather than SAP. A shadow measurement now can save you from months of damage control later.

Action Steps:

1. Execute USMM on all productive systems once more. This is your internal measurement run, ideally a few weeks or months before any expected official audit. Make sure to run it in a steady state (no unusual activities happening).
2. Collect the USMM results (the measurement logs) from each system and consolidate them using LAW. Follow the same procedure you would if you were submitting to SAP: import all system measurement files into LAW and let it produce a combined license audit report.
3. Analyze the consolidated LAW output carefully. Look for any anomalies or spikes: Are the total named user counts in line with expectations after your cleanup? Do all users have the correct license type in the LAW report? Are all engines showing reasonable numbers? If anything looks off (e.g., a higher user count than anticipated or an engine count that doesn’t match what you validated), investigate immediately.
4. Cross-verify the LAW results with your internal records. For example, if LAW says you have 1,000 Professional users, ensure you can account for who they are (via your cleaned user list and classification data). If LAW shows any “Unclassified” users or “Default” license users, it means some user wasn’t classified properly – fix that and re-run if needed.
5. Hold an internal review of the final figures. Bring together your SAM team, SAP Basis team, and relevant stakeholders (even procurement or legal if necessary) to go over the results. This serves two purposes: it ensures everyone is aware of the license position, and it provides an opportunity to formulate any explanations or justifications for the auditors. If the numbers are higher than your entitlement in any area, you can strategize how to handle it (e.g., purchase additional licenses proactively or be prepared to negotiate).
6. Securely store the final LAW reports and all supporting evidence (user lists, engine validations, note application logs, etc.). Treat this as your audit dossier. In the event of an audit, you’ll be well-prepared to hand over data that you’ve already vetted, and you have backup documentation to support every figure.

Checklist:

• All systems’ measurement data have been run and validated internally (no unchecked errors or weird results).
• No inactive users or duplicates appear in the LAW report (confirmation that earlier cleanup steps were successful).
• The final LAW consolidation output is saved and reviewed, with sign-off from SAM/compliance leads confirming that it accurately reflects your usage.
• Any gaps between entitlements and usage are identified and addressed before SAP’s auditors do.

With this rehearsal done, you can approach the official SAP audit with confidence. You’ll essentially be handing SAP the same numbers you’ve already seen, cleaned, and controlled, turning the audit from a potential scramble into a routine confirmation.

5 Technical Cleanup Actions to Secure Audit Readiness

To summarize, here are five critical technical cleanup actions that will fortify your SAP systems before an audit:

• Delete or deactivate inactive and duplicate users. (Eliminate unused accounts and ensure one person = one user ID to avoid overcounting.)
• Validate all user-role mappings and license classifications. (Make sure each user is correctly licensed according to what they actually do.)
• Review and correct all engine metric measurements. (Check package license usage for accuracy and exclude any non-relevant data.)
• Apply the latest SAP Notes and retest USMM/LAW. (Keep measurement tools up-to-date so you’re counting with SAP’s most accurate logic.)
• Confirm system roles and LAW consolidation accuracy. (Only count production systems and verify that LAW is merging and reporting users correctly.)

By executing these technical cleanup actions methodically, you put your organization in the driver’s seat for the upcoming audit. You’ll eliminate the easy errors that auditors love to exploit and ensure that what SAP sees is what you intend for them to see – no more, no less.

Audit readiness isn’t a one-time project, but with these steps, it becomes a sustainable part of your SAP operations, dramatically reducing compliance risk and unnecessary license costs.

Read about our SAP Advisory 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