Why System Preparation Is the Highest-ROI Activity in SAP Audit Defence

When an enterprise learns that SAP is planning a licensing audit — or when an audit is already scheduled — the first instinct is often defensive: hire advisors, build arguments, prepare documentation. All of these are necessary. But the single highest-impact activity happens before any of that: cleaning up and rationalising your SAP systems so the measurement data itself is defensible.

Most SAP audit findings are not the result of SAP discovering complex contractual violations. They result from measurement data that, when presented to an enterprise, appears to justify significant licence upgrades. That measurement data comes from your system configuration, your user accounts, your role assignments, and your activity history. If those elements are messy, bloated, or misconfigured, the measurement will be aggressive. If they are clean, rationalised, and well-documented, the measurement will be much more defendable.

System preparation before measurement is not about hiding usage or sanitising data. It is about removing the garbage that inflates measurements: orphaned accounts, duplicate user IDs, test activity in production systems, roles that were assigned but never used, service accounts classified as named users, and systems included in measurement scope that should not be. A single week of intensive system preparation can reduce SAP's audit claim by 20-40% before measurement even runs.

The Preparation Window and Timeline

The moment you learn an audit is coming — whether from explicit notice by SAP, from a pre-audit communication, or from your account team hinting that a measurement is being scheduled — you enter the preparation window. This window typically closes when SAP schedules the actual measurement run or when the auditors arrive on-site to collect data.

In most cases, the preparation window is 4-12 weeks. Some enterprises receive more advance notice; others face compressed timelines. Regardless of duration, the priority is to move fast on the highest-impact items. A single week of focused activity — decommissioning 50 inactive accounts, cleaning up 30 duplicate user IDs, revoking access to obsolete roles — can have more impact on audit outcomes than six months of documentation-gathering after measurement runs.

Your first action after learning an audit is coming is to stop the clock internally. Schedule a rapid assessment with your SAP Basis and HR teams to map: How many active vs inactive user accounts exist? How many duplicate IDs are there? What systems are in scope? What roles are bloated with unnecessary transactions? This assessment typically takes one week and surfaces 2-3 high-impact areas for immediate remediation.

Step 1: User Account Audit and Decommissioning

The easiest, fastest, highest-impact preparation activity is decommissioning inactive users before measurement. If a user account has not logged in for 90 days (or your organisation's inactivity threshold), that account should not be licensed. Yet in most enterprises, inactive accounts persist in the system, consuming licence seats and inflating measurement counts.

Start by running a user listing report from your SAP security module. Request from your Basis team a list of all active user accounts, sorted by last-login date. Cross-reference this list with your HR system to identify users who have departed the company or gone on extended leave. Flag accounts with no login activity in the past 90 days, 6 months, or 1 year (depending on your company's idle threshold).

For inactive accounts you identify, your options are delete (permanent removal) or lock (disable login, preserve audit trail). Most enterprises prefer to lock accounts rather than delete them, to preserve audit history. SAP's measurement tools will exclude locked accounts from licence counts, so locking is sufficient to reduce measurement exposure.

Budget one week for this exercise in a mid-to-large organisation. A typical enterprise might identify 100-300 inactive accounts. Decommissioning them in bulk (working with your Basis team to disable accounts in batch operations) takes a day. The impact on measurement: each decommissioned account removes one named-user seat from the measurement count.

Key metrics to track: How many total user accounts exist today? How many have never logged in? How many have not logged in for 6+ months? How many are duplicates (same person with multiple IDs)? These metrics become your baseline for measuring improvement.

Step 2: Role Rationalisation and Transaction Audit

The second high-impact area is reviewing role assignments. Many enterprises build their role structures during implementation, then layer on customisations, patches, and ad-hoc role changes over years. The result: roles that include unnecessary transactions, roles assigned to users who never use them, and transaction access that persists long after business needs end.

SAP's measurement logic — particularly under STAR, which is activity-based — classifies users based on the highest-value transaction they are assigned (or have executed). A Functional user assigned to a single Professional transaction becomes a Professional user in measurement. A Professional user who executes one Productivity-tier transaction still gets classified as Professional. Your role structure directly drives your audit exposure.

Request from your SAP Basis and security teams a complete role inventory: For each role currently assigned in production, list the transactions it includes. Cross-reference each role against your organisation's actual job functions. Ask: Does this role still exist? Does it still represent a legitimate job function? Which transactions in this role are actually used?

For roles that include both Professional and Functional transactions, consider splitting them: create a Functional-tier role that includes only lower-cost transactions, and assign users to the Functional role if they do not genuinely need Professional tier. Many enterprises find they can downclassify 20-30% of Professional users by removing unnecessary transaction access.

Key targets for this exercise: roles with broad transaction access, roles created during implementations that are no longer actively maintained, roles assigned to users with no recorded activity, and roles that include manual corrections or Z-transactions created during implementations.

Step 3: Transaction Code Audit and Unnecessary Access Removal

Related to role rationalisation is a focused transaction code audit. Identify the highest-value Professional-tier transactions in your system. For each, audit: How many users are assigned this transaction? How many of those users have actually executed it? How many roles include this transaction despite it being irrelevant to most assigned users?

In most enterprises, a small set of high-cost transactions drives most of the Professional user classification. By identifying and restricting these transactions to only truly necessary users, you can dramatically reduce Professional user counts. Common examples: Master Data Management (MDM) transactions, system configuration transactions, financial posting transactions, and process control transactions.

Many of these transactions are assigned to users who need them rarely or never. A finance user might be assigned a cost allocation transaction as part of a broad Finance role, but only the corporate cost accounting team uses it. Removing this transaction from the broader role, while assigning it only to the 3-4 cost accountants who need it, reclassifies dozens of finance users from Professional to Functional tier.

Step 4: Service Account Review and User Type Classification

Service accounts — technical user IDs created to support automated processes, system integrations, batch jobs, or middleware — should not be licensed as named users. Yet in many organisations, service accounts are classified and counted as named users, inflating licence requirements significantly.

Work with your Basis and integration teams to map all service accounts: system-to-system middleware accounts, batch processing accounts, scheduled job accounts, reporting accounts, third-party integration accounts. For each, classify as either: (a) a service/technical user (not licensed), (b) a shared functional account used by multiple people (should be a Functional user pool, not named users), or (c) a genuine named user account that happens to be used by an automation process (edge case, but legitimate).

Re-classifying 20-50 service accounts from named users to service/technical users is typically straightforward and removes a proportional number of licence seats from measurement scope. This is pure cost-reduction opportunity with no business impact.

Step 5: System Scope Confirmation and LAW Consolidation Scope

SAP's measurement tools run LAW (Licence Agreement Workbench) consolidation, which brings together user data from all systems in defined "scope". If non-production systems, legacy systems, or test environments are accidentally included in scope, their users get counted in enterprise licence requirements.

Before measurement, confirm with SAP which systems are included in LAW scope. Typical scope includes: production ECC systems, production S/4HANA systems, and regional or business-unit instances that represent live business processes. Typical out-of-scope systems include: development, test, training, sandbox, legacy systems being decommissioned, and archived systems.

If test or training systems are included in scope by mistake, their removal can eliminate hundreds of user accounts from measurement. If legacy systems that are actively being decommissioned are in scope, negotiate removal or a sunset date. Getting this wrong can inflate measurements by 10-20%.

Step 6: Running Your Own USMM Pre-Measurement

Before SAP runs official USMM measurement, run an independent pre-measurement yourself. SAP provides the USMM tool within S/4HANA environments. A Basis team familiar with the tool can run a pre-measurement on a copy of your production data without affecting the live system or creating audit visibility to SAP.

This pre-measurement gives you a baseline. You see exactly what SAP will see: how many users are classified at each tier, which roles drive classification, which transactions are high-value, which users are outliers. Armed with this data, you can target your remediation efforts. If the pre-measurement shows 300 Professional users and 200 Functional users, but your expected population should be 150 Professional and 350 Functional, you know where the gap is and can close it before official measurement.

The pre-measurement also allows you to validate assumptions. Does SAP's transaction tier mapping match your understanding? Are there users classified unusually high due to one-off activities? Are there data quality issues — orphaned accounts, duplicate consolidations, etc. — that should be fixed before official measurement?

Step 7: Building Your LAW Consolidation

SAP's LAW consolidation logic (which systems contribute to measurement, how users are consolidated across systems, which user records take precedence) directly affects your licence count. Before SAP runs consolidation, confirm the consolidation rules with your account team and test them independently.

A common problem: users have accounts in multiple systems (e.g., one in ECC, one in S/4HANA; one for legacy business unit, one for new product line). When consolidated, these accounts may merge into a single user, classified at the highest tier across all accounts. If you can document that these accounts should not be consolidated (they represent different roles, different geographic entities, or business-unit separations), you can prevent the consolidation and reduce the overall classification.

LAW consolidation typically happens before USMM or STAR measurement. Understanding and influencing this consolidation rules is a critical pre-measurement step that many enterprises overlook.

Step 8: STAR Exposure Analysis and 12-Month Activity Review

If your systems run S/4HANA or cloud-based RISE, STAR measurement will occur. STAR is activity-based and looks at 12 months of transaction history. Identifying activities that may inflate classification — one-off project access, temporary implementations, test activities — allows you to either document their context (for later disputation) or remediate them before measurement.

Work with your Basis team to pull 12-month transaction activity logs. Focus on high-value Professional transactions. For each, identify: Is this activity routine and ongoing, or one-time/project-based? Is it driven by actual business users, or by system administrators troubleshooting issues? If activities are non-routine, document the business reason and timeline. If 12 months of history includes temporary project access that has since ended, that becomes ammunition for post-measurement disputation.

STAR measurement often captures development, testing, or troubleshooting activity that does not represent production business work. Building an audit trail of when those activities occurred and whether they have ended is critical defence preparation.

What to Do If SAP Has Already Scheduled Measurement

If you are reading this after SAP has already scheduled measurement and timelines are compressed, your priorities shift. Focus on the fastest-ROI items: decommission inactive accounts (1-2 days work, immediate impact), lock duplicate user IDs (1 day), remove service accounts from named-user classification (1-2 days), and remove obviously out-of-scope systems from LAW consolidation (1-2 days). This 5-7 days of work can reduce measurement by 15-25%.

If measurement has already run and SAP has presented initial findings, see our guide on how to challenge SAP's initial audit claim.

Building the Documentation Trail

As you prepare your systems, maintain detailed documentation: What accounts were decommissioned and when? Why were they decommissioned? What roles were changed and what was the business justification? What transactions were removed from roles? What systems were included or excluded from scope and why?

This documentation trail is critical. When SAP presents audit findings based on measurement data, you need evidence that your system baseline was clean, rationalised, and appropriate for your business. Documentation of pre-measurement remediation work demonstrates that high licence classifications are not the result of legitimate business need, but rather of system debris and configuration errors that you systematically cleaned up.

Many enterprises underestimate the audit impact of a clean, well-documented change trail. Documentation alone will not defeat an audit claim, but combined with clean systems and activity analysis, it creates a compelling narrative: "This is what we found wrong, this is what we fixed, this is why the measurement should be lower than SAP's initial claim."

Our Services

Independent SAP Licensing Advisory

Audit defence, contract negotiation, licence optimisation — all buyer-side, no SAP affiliation.

Explore All Services → Case Studies

Real Results for Enterprise Buyers

See how we've helped enterprises reduce SAP spend by 30-60% and win audit disputes.

Read Case Studies →

Conclusion: Preparation Is the Highest-ROI Defence Activity

Most enterprises spend most of their audit defence budget on disputation, documentation, and legal negotiation. These activities are necessary, but the single highest-ROI spending occurs before measurement even runs. A focused week of system preparation — user cleanup, role rationalisation, account decommissioning, and scope validation — often reduces audit claims by more than months of post-measurement fighting.

The moment you learn an audit is coming, your priority is to work with your Basis and HR teams to clean up your system baseline. Decommission inactive accounts. Rationalise roles. Remove unnecessary transaction access. Validate system scope. Run pre-measurements to surface hidden issues. Document everything.

By the time SAP runs official measurement, you will have a clean, defensible system baseline. The measurement data, when it arrives, will be dramatically lower than it would have been in a messy, bloated system. And when SAP inevitably argues for licence upgrades, you will have documentation and evidence that shows you have already removed the obvious inefficiencies and that further claims are unjustified.

For help planning and executing pre-measurement preparation activities, see our SAP Audit Defence service and our comprehensive SAP Audit Defence Guide.

Part of SAP USMM & LAW Tools Series