Key Takeaways

  • Professional users you're charging full maintenance for ($3,000–6,000/user/year) that haven't logged in for years are invisible waste in your audit footprint
  • USMM and LAW count locked users but not properly deleted ones — locking alone leaves you exposed at measurement
  • A typical enterprise discovers 12–22% inactive users; at 1,000 users, that's 120–220 unneeded licences costing $360K–1.32M/year
  • SAP defines "inactive" as 90, 180, or 365 days no-logon — but you should use your own threshold for business continuity
  • A three-phase cleanup (identify → notify → delete) with proper audit trail defense and compliance documentation protects you legally
  • Running cleanup 3–6 months before system measurement ensures your count is clean before SAP's auditors arrive
  • Quarterly governance and automated detection prevent user creep and lock in savings at renewal

In This Article

Why SAP Inactive Users Are Costing You Millions

SAP's licensing model charges by named user, not by usage. That's the trap. A Professional license can cost you $3,000–$6,000 per user per year in maintenance alone — and that's on top of your initial capital cost. The moment someone is added to the system as a named user, you're paying for a full licence, whether they log in once a month or never touch the system again.

For most large enterprises, somewhere between 12 and 25 percent of your named user base is completely inactive. At a company with 1,000 SAP users, that's 120–250 people paying SAP $360,000 to $1.5 million every single year for access they don't use.

What makes this worse: SAP's system measurement tool — the USMM (SAP Usage Measurement Module) and its successor, LAW (License Assessment Workbench) — capture all named users in the system, including the inactive ones. Your count isn't based on who used the system; it's based on who exists in it. When SAP's auditors run their measurement before your renewal, they're looking at raw user counts, not activity. Inactive accounts inflate your baseline number, which then gets locked into your renewal terms for another one, two, or three years.

The financial impact compounds. Not only are you paying maintenance on users who aren't active — you're renewing at a higher baseline, which means your next maintenance bill is calculated on that inflated number. A single inactive user costs you money every year, forever, until someone manually removes them.

The Audit Risk

SAP doesn't penalize you for having inactive users. They profit from them. But if you delete users carelessly — without proper documentation, without notifying stakeholders, or without preserving audit trails — you expose yourself to compliance violations, legal liability, and audit disputes that are far more expensive than the users themselves.

How SAP Counts Users in System Measurement

Understanding how SAP's system measurement tools work is the foundation of an effective cleanup strategy. SAP measures named users using two primary mechanisms: the older USMM (User and System Measurement Module) and the newer LAW (License Assessment Workbench). Both tools are designed to capture the universe of all named users assigned licences in your SAP system.

The Critical Difference: Locked vs. Deleted vs. Archived

This is where most enterprises make their first mistake. Locking a user account in transaction SU01 (User Maintenance) is not the same as removing them from your licence count. SAP's measurement tools still count locked users. If you have a user who was terminated two years ago and you locked their account but never deleted it, USMM and LAW will still report them as a named user, and you're still paying licence fees for that person.

Here's the distinction:

  • Locked users: User record exists; account is disabled; still counted in system measurement and licence baseline
  • Deleted users: User record removed entirely from SAP; no longer counted in USMM/LAW; no longer incurs licence charges
  • Archived users: Some organizations retain a copy of deleted users in a separate archive table for compliance; not counted in live measurement

SAP's position is straightforward: a named user licence is assigned to a user ID. The moment you assign a user ID a licence (even if you later lock it), you've incurred a licensing obligation. Deletion is the only way to remove that obligation, provided you've documented the decision and met compliance requirements.

STAR Tool and Activity Reporting

SAP's STAR tool (SAP System Activity Repository) can measure actual activity — transactions executed, modules accessed, logons — but it's a separate reporting layer from the licence count. STAR data shows who is active, but SAP's renewal counting is based on who is licensed, not who is active. This disconnect is why you must run your own forensic analysis rather than relying on SAP's default reporting.

Identifying Inactive Users: The Forensic Approach

A proper inactive user cleanup requires multiple data sources and a clear definition of "inactive" that makes sense for your business. SAP doesn't have one universal definition — it varies by role, department, and organizational structure.

Transaction Codes and System-Level Tools

The primary SAP tools for user analysis are:

  • SUIM (User Information System): Query user master data, assignments, and logon history; built-in reporting on user activity by date range
  • SU01 (User Maintenance): Individual user record review; shows last logon date, role assignments, profile assignments
  • SU10 (Mass User Maintenance): Bulk user operations, mass locking, bulk updates to user attributes
  • SM20 (System Activity Logs): Audit trail of user transactions; can filter by user ID and date range to confirm activity level
  • USR02 (User Master Data) table: Direct database query showing UFLAG (user disabled), LASTLOGON timestamp, and other metadata

A proper audit uses all of these in combination. You're not just looking at logon dates; you're confirming role assignment, validating against your current HR records, and checking transaction history to confirm that the "last logon" date isn't just a system cleanup job run by an administrator.

Defining "Inactive" for Your Organization

SAP typically uses three inactivity thresholds: 90 days, 180 days, or 365 days (one year) without logon. But your threshold depends on your business:

  • 90 days: Appropriate for production environments with daily operational users; assumes any role requiring access should show activity at least quarterly
  • 180 days: Better for mixed environments where some roles are seasonal or part-time; aligns with typical mid-year review cycles
  • 365 days: Conservative; assumes any licensed user should touch the system at least once per year

We recommend starting with a 365-day threshold for your first cleanup. Users with no logon in a full year are unambiguously inactive — there's no legitimate operational reason for a named user to go a year without touching SAP. Once you've cleared those, you can tighten to 180 or 90 days based on your role definitions.

Automated Tools vs. Manual Analysis

For enterprises with 1,000+ users, manual analysis isn't practical. Tools like SAP's own LAW, or third-party ITAM platforms (Flexera, Snow, ServiceNow), can automate user activity detection, role assignment verification, and compliance reporting. However, automated tools are only as good as their data. You must manually validate the output against your HR records and organizational charts before acting on it.

Cross-Reference Against HR Records

The most reliable inactive user detection combines system logon data with your current employee directory. If someone hasn't logged in for 18 months and they're no longer on your payroll, that's unambiguous. If they're still employed but inactive, you need to verify with their manager before deletion.

The Cleanup Process: Step-by-Step

An effective inactive user cleanup is a five-phase process that balances speed with audit defensibility. This isn't a one-afternoon project — it's a structured governance activity.

Phase 1: Export and Forensic Analysis

Using SUIM or a direct database query on USR02, export all user records with these fields:

  • User ID
  • Last logon date
  • Primary role/profile assignments
  • Licence type (Professional, Standard, etc.)
  • User status (enabled/disabled)
  • User group or department (from user master text field)

This becomes your master inventory. Filter for users with no logon in your chosen threshold (365 days, 180 days, etc.). The export itself is your first audit trail — timestamp it and store it with version control.

Phase 2: Cross-Reference and Validation

You now have a list of candidate users for deactivation. Before proceeding, cross-reference against:

  • Current HR payroll records: Are they still employed? Confirm with HR directly
  • Organizational chart: Do they have an active manager or department assignment?
  • Transaction history (SM20/STAR): Even if their last logon was a year ago, did the system record any background processing on their behalf?
  • Role assignment: Is this role still in use? If the role is critical, confirm with the business owner that this person's assignment is redundant

Build a "hold" list — users that automated tools flagged but shouldn't be deleted due to business continuity, compliance, or management override. This is critical for audit defence. Document the reason for each exception.

Phase 3: Notification and Grace Period

Do not delete users without notice. Send a formal notification to each user's manager (and to the user, if possible) explaining that their account is scheduled for deactivation in 30 days if there is no activity.

Template language:

"Our audit of SAP usage shows that the account for [User Name] has not been accessed since [Date]. As part of our licence optimization programme, accounts inactive for more than 365 days will be deactivated on [Deactivation Date]. If this person is still in your department and should retain access, please notify [Licence Manager] by [Deadline]. No action is required if the person is no longer employed."

This serves three purposes: (1) catches legitimate reactivations, (2) creates a documented decision point for audit trail, and (3) gives management a chance to provide business context you might have missed.

Phase 4: Delete with Audit Trail

After the grace period, proceed with deletion using SU10 (bulk user maintenance) or direct system calls if your environment allows it. Before deletion:

  • Take a final snapshot of the user records (export the deletion candidate list with timestamps)
  • Document the deletion approval (manager sign-off, IT change control ticket, licence governance decision)
  • If required by compliance, archive the deleted user records to a separate table or export for long-term retention
  • Delete the user records
  • Immediately run a post-deletion SUIM query to confirm the records are gone

Store all of this documentation in a governance folder with clear versioning: deletion batch #1, deletion batch #2, etc. Each batch should have a cover memo explaining the scope, the approval, and the count of users affected.

Phase 5: Validate Against System Measurement

Within 48 hours of deletion, run your system measurement tool (USMM or LAW) to confirm that the deleted users are no longer counted in your licence baseline. If they still appear, investigate — it may indicate a replication delay, a backup process, or a secondary system that also needs cleanup.

This validation is your proof that the cleanup worked. Save the measurement output as part of the audit trail.

The Inline CTA

If your organization lacks the governance framework or expertise to manage this cleanup independently, our SAP licence optimisation service handles the forensic analysis, validation, and deletion workflow with full audit documentation. We've helped enterprises recover millions in unnecessary spending.

Compliance and Legal Considerations

User deletion isn't a technical operation — it's a legal one. Your jurisdiction, your industry, and your contract with SAP all govern what you can delete and what you must preserve.

GDPR and Data Retention Requirements

If you operate in the EU or handle EU residents' data, GDPR's "right to be forgotten" applies to personal data stored in user records. However, legitimate business purposes (audit trail, employment records, licence compliance) override the right to deletion. The safer approach is to delete the user record from SAP but retain an archive copy for the period required by your data retention policy (typically 7 years for employment and tax compliance).

Document your retention policy and follow it consistently. Random deletion of some users while retaining others can expose you to GDPR complaints.

Audit Trail Preservation

Before deleting any user, export their master record, role assignments, and transaction history. This isn't just for SAP — it's for your internal auditors, your tax advisors, and potentially for regulatory investigations.

If you're ever in an audit dispute with SAP and they claim you should have been licensed for users you deleted, the audit trail proves you had legitimate business reasons to remove them. Without documentation, you're defending a deletion years after the fact based on memory alone.

SAP's Contractual Position

SAP's standard contract (the Cloud Services Agreement or a traditional software agreement) grants you the right to manage users within your own system. You can add, modify, and delete users. SAP doesn't have the contractual right to prevent you from deleting inactive accounts.

However, SAP's position in audits has sometimes been that if a user was ever licensed, the licence fees were earned — even if you later delete the user. This is why documentation is critical. If you can prove the user was inactive and deleted for legitimate business reasons (head count reduction, role elimination, termination of employment), you're on much firmer ground.

Employment Law and HR Records

Deleting a user account for a terminated employee is straightforward — it's part of off-boarding. But deleting an account for a current employee requires manager approval and documentation. If someone later claims they should have retained access and suffered business damage because of the deletion, you need proof that they agreed to or understood the deletion was coming.

For this reason, always obtain manager sign-off before deleting any currently employed user. The 30-day grace period provides the opportunity for that sign-off to occur.

How Much Can You Save?

Let's work through the numbers with a realistic enterprise scenario.

Baseline Scenario

  • Total named users: 1,000
  • Licence mix: 70% Professional ($5,000/user/year), 30% Standard ($2,000/user/year)
  • Average annual maintenance cost per user: $4,100 (weighted average)
  • Current annual SAP spend: $4.1 million

Cleanup Scenario

Forensic analysis identifies 180 inactive users (15% of your base):

  • 100 Professional users (inactive, no 365-day logon)
  • 80 Standard users (inactive)
  • Year 1 savings from deletion: (100 × $5,000) + (80 × $2,000) = $660,000

Compound Savings at Renewal

When you renew your SAP contract (typically 1–3 years later), your new baseline is 820 users instead of 1,000. If your renewal pricing includes a 3% annual maintenance increase (common), your savings compound:

  • Year 2: 820 users × $4,227 (adjusted for inflation) = $3.466M (vs. 1,000 × $4,227 = $4.227M) = $761K saved
  • Year 3: 820 users × $4,354 = $3.570M (vs. 1,000 × $4,354 = $4.354M) = $784K saved

Total three-year savings: $2.205 million.

That's from identifying and removing 180 inactive users once. And that's before any further cleanup in subsequent years.

Industry Benchmarks

Based on audits we've conducted across 50+ enterprises:

  • Manufacturing and logistics: 18–22% inactive users (seasonal roles, temporary workers, contractor accounts)
  • Financial services: 12–18% inactive users (compliance and historical access retention)
  • Healthcare and pharmaceuticals: 14–20% inactive users (high turnover, departmental reorganizations)
  • Retail and consumer: 16–25% inactive users (high staff turnover, role elimination)

Even a conservative assumption of 12% inactive users (120 at 1,000 base) yields $500K+ in first-year savings and multi-million-dollar returns over a renewal cycle.

Inactive User Cleanup Best Practices for 2026

Timing and Measurement Windows

The best time to run an inactive user cleanup is 3–6 months before your next system measurement event. SAP typically measures before renewal negotiations. If you know your renewal is scheduled for Q3, run your cleanup in Q4 of the previous year — this gives you time to validate the results and ensure USMM/LAW reflects the cleaner baseline before SAP's auditors run their own measurement.

Governance and Organizational Structure

Designate a licence manager or licence governance committee with representatives from IT, HR, and the business. Their responsibilities:

  • Quarterly review of new user additions (who are we licensing, and why?)
  • Annual audit of inactive users using a standard inactivity threshold
  • Approval of deletion candidates before the grace period is triggered
  • Documentation of all decisions in a centralized governance log

This structure prevents user creep (the accumulation of unnecessary accounts over time) and ensures that future cleanups are faster and require fewer exceptions.

Automation and Third-Party Tools

For large deployments, consider SAP GRC (Governance, Risk, Compliance) or third-party ITAM tools to automate the detection phase. These tools can:

  • Auto-query user activity on a scheduled basis
  • Cross-reference user records with HR systems
  • Generate compliance reports for audit trails
  • Trigger notifications and workflows based on inactivity thresholds

Automation reduces the manual effort, but it doesn't reduce the need for human validation. A tool can flag inactive users, but a human must approve the deletion.

Documentation as Defense

Every cleanup activity should be documented with:

  • The inactivity threshold used (365 days, 180 days, etc.)
  • The rationale for the threshold
  • The list of users flagged, with their last-logon dates
  • The cross-reference results (HR validation, manager sign-off, exceptions noted)
  • The notification sent to managers and grace period offered
  • The final deletion list with execution timestamps
  • The post-deletion measurement report showing the reduction in user count

Store this in a central location with version control. If SAP ever questions your cleanup, you can produce a complete audit trail showing that every decision was documented, approved, and validated.

Frequently Asked Questions

Can we lock users instead of deleting them?
Technically, yes — locking (disabling) a user account prevents login. However, locked users are still counted by USMM and LAW in your licence baseline. If your goal is to reduce your licence count and fees, locked users don't help. Lock users as a temporary measure (30-day grace period), then delete if there's no reactivation request.
What if a deleted user needs to be reactivated?
If you've archived their user record, reactivation is straightforward — restore from archive and assign a new licence. If you've permanently deleted without archive, you can create a new user record. Either way, there's no penalty. SAP doesn't prevent you from re-adding users; the cost is the new licence fee going forward.
Do we need SAP's permission to delete users?
No. User management is your operational responsibility. You have the contractual right to add, modify, and delete users within your SAP system. SAP has no approval authority over your user maintenance decisions. However, SAP can audit your user count at renewal and question whether you should have been licensed for users you deleted. Documentation defends against this.
How do we handle service accounts and system users?
Service accounts (used by batch jobs, integrations, third-party tools) are often continuously active even if the business process they support is inactive. Don't apply the same inactivity threshold. Instead, validate service accounts annually: is the underlying integration or batch job still in use? If not, delete the service account. This requires coordination with your integration team.
Should we delete users immediately after termination or wait for the grace period?
For terminated employees, you can delete immediately — there's no business risk of reactivation. For current employees, the 30-day grace period is safer. It catches legitimate reactivations and provides documented manager approval. The extra 30 days is worth the audit defensibility.
What if our SAP system has a separate development or sandbox environment?
You must clean both. SAP typically measures production and non-production systems separately, but some audit approaches count all systems. Don't assume your sandbox users are "free." Apply the same inactivity rules to dev/test systems — a sandbox user is still a licence obligation unless it's explicitly classified as non-production (which requires specific contract language).

Related Articles in This Cluster