Specific user reclassification, ghost elimination, and contract simplification tactics that deliver the largest cost reductions for enterprise buyers.
Your SAP licence cost structure is deliberately opaque. SAP's architecture embeds cost multipliers that remain invisible until you run the numbers yourself. The problem is that most enterprises never do the math in isolation — they bundle licence costs with implementation, support, and cloud services, making it impossible to isolate where actual value breaks down.
The hidden costs cascade through six distinct mechanisms. First, your user portfolio is almost certainly wrong. Most enterprises classify Professional users as if they were truly executing complex business processes, when in reality they're consuming a narrow subset of SAP functionality. Second, your system landscape is inflated. Consolidation from 8–12 systems to 3–5 rarely happens on schedule, so you're funding duplicative licences that serve migration timelines, not active business. Third, your engine and analytical products (BW, PI/PO, Analytics Cloud) are vastly over-purchased because SAP sells them as platform prerequisites without forcing usage justification. Fourth, your Enterprise Support contract locks you into a 22% annual maintenance rate regardless of how efficiently you operate. Fifth, your ancillary products (Ariba, Concur, SuccessFactors) run under metrics that ignore actual transaction volume. Sixth, your contract terms don't align with modern work patterns — you're paying for full named users when shared accounts and ESS would suffice.
SAP never volunteers this analysis. In fact, their sales and audit teams actively obscure it. They will show you "cost per user" metrics when what matters is cost per actual business transaction. They will cite your contract language when the language itself was negotiated under information asymmetry. And they will point to your own transaction logs as evidence that you need more licences, not fewer, because they measure activity, not entitlement.
The largest cost reductions in consolidation come from attacking these six mechanisms methodically. Each has a different risk profile, ROI timeline, and contractual defense. The strategies below are sequenced by ROI first, then by risk, so you can prioritize where your effort yields the highest return.
Professional users represent the highest-cost user type in SAP's licensing model. A single Professional user licence costs 2.5 to 3.5 times more than a Limited Professional licence, and the maintenance fee differential is direct: if you reclassify one Professional to Limited Professional, your annual maintenance payment drops by approximately 22% of that user's licence value immediately. For an enterprise with 300 Professional users, even a conservative reclassification of 80 users yields €450,000 to €600,000 in annual savings.
The contractual basis for reclassification lies in the SAP General Terms and Conditions, which tie user type to "actual use and functionality access." Your Order Form's Schedule of Licences specifies which business functions define each type. The standard definitions are:
What SAP doesn't volunteer is that the functional access definition is enforced by SAP authorization code (Pflich fields in the SUIM_USER_ROLE_ASSIGN report), not by what the user is "permitted" to do. This is the leverage point. If a user's authorization matrix doesn't include transaction codes for MMBE (inventory), COSP (cost analysis), or VL10B (delivery), then they are not a Professional user by contract, regardless of what your Order Form claims.
Not all Professional users have equal reclassification probability. SAP will challenge some reclassifications during audit. The lowest-risk targets are user populations with clear, auditable functional boundaries. These fall into three categories:
CRM and Sales Users. Salesforce.com and SAP CRM users accessing C4C or CRM Cloud are frequently licensed as Professional users but execute only a handful of transaction codes: transaction VH01 (account management), H04 (opportunity), H05 (activity), and a few reporting transactions. These users have zero need for manufacturing (MM), materials planning (PP), or financial closing (FM). Authorization analysis via SUIM_ROLES report will show fewer than 20 active transaction codes. Reclassification to Limited Professional is contractually defensible and rarely disputed.
HR and Payroll Users. HR department staff and business partners using SuccessFactors Employee Central or SAP SuccessFactors are often Licensed as Professional but access only PA (personnel administration), PY (payroll), and TR (travel). Manufacturing, procurement, and finance access are zero. The USMM (User Management Maintenance) audit report will confirm transaction scoping, and the evidence is airtight. SAP auditors understand this category well; they will contest fewer reclassifications in HR because the functional segregation is standard practice.
Portal and ESS Users. Employee Self-Service (ESS) portal users — those accessing time entry, expense submission, benefits enrollment — are almost universally mis-licensed as Professional or Limited Professional when they should be Employee or Productivity users. Portal access is governed by portal roles, not SAP transaction codes. A user with portal-only authorization typically accesses five or fewer SAP transactions: PA0001 (personal data), PA0014 (address), PA0008 (bank details). They have no need for transactional modules. Reclassification to Employee user is immediate and nearly uncontestable if you have role assignment records and portal access logs.
The financial impact of user reclassification is amplified by SAP's maintenance fee structure. SAP's Annual Maintenance Fee (typically 17–22% of net licence value per year, though contracts vary) is applied per user type. Here's how the multiplier works:
Over a five-year period, one Professional-to-Limited Professional reclassification eliminates €2,310 in maintenance costs alone, not counting the initial licence value write-back you can negotiate at contract renewal. Across 80 reclassifications (a realistic number for a mid-sized multinational), the five-year impact exceeds €184,000 in maintenance alone.
SAP's response to large reclassification claims is typically to audit the underlying authorization roles and challenge which transactions are "required" for business use. This is where your evidence collection (SUIM_ROLES, SUIM_USER_ROLE_ASSIGN, SU01 user master records) becomes contractual protection. If you can demonstrate that 75% of the target user population executes fewer than 30 unique transaction codes and 85% of those codes are in a single module (Sales, HR, Finance), you have a defensible position.
Quantify your reclassification potential: Your USMM or SAP Licence Audit Workbench (LAW) report contains the transaction activity data you need. If you don't have a clean USMM output from the last 12 months, we can help you extract and analyse it. Schedule a free 30-minute consolidation assessment and we'll give you a reclassification target range.
Ghost users are SAP user accounts that exist in your SU01 master but have not executed any transaction for 12 months or longer. They are dormant, abandoned, or forgotten. Most enterprises carry 15–25% ghost users as a proportion of total named users. For a 1,000-user estate, this means 150–250 licences paying maintenance on accounts that generate zero business value.
The contractual position is unambiguous. SAP's standard Order Form language requires licences for "users who access the system." Accounts with zero transaction activity in 12 months do not meet the access criterion. Eliminating ghost users is the lowest-risk consolidation strategy because SAP has never successfully defended a position that dormant accounts require paid licences.
Ghost user identification requires three data sources: SM20 (user transaction logs), SM37 (background job logs), and SU01 (user master). You must confirm that a user account has not executed any interactive transaction (SM20) and has not been the owner or executor of any batch job (SM37) in the past 12 months. Accounts locked by HR for more than 90 days (SU01 status field) are candidates for immediate removal, though you should verify no batch jobs run under those accounts.
Ghost user prevalence varies by organization maturity and system governance, but the pattern is consistent across industries. Financial services companies (where regulatory compliance demands formal user access controls) typically have ghost user rates of 12–18%. Manufacturing and discrete industries average 18–22%. Retail and consumer goods, with higher user churn and looser deprovisioning governance, reach 22–30%.
The financial impact is direct. Assume an average user licence cost of €1,800 and maintenance at 20% annually:
Ghost user elimination also strengthens your audit defence. SAP auditors will always inquire about dormant accounts. If your consolidation submission includes documented evidence of ghost user deprovisioning, you're demonstrating active governance and challenging SAP's ability to claim that the accounts were "in use" at any point. This shifts the burden of proof to SAP, and they will often concede the point rather than defend it.
The implementation is straightforward: extract SM20 (no activity in 12 months), cross-reference SU01 for accounts locked >90 days, confirm no SM37 batch jobs, and deactivate the accounts in SU01. Document the activity logs for each deactivated account. During contract negotiation, present a consolidated report showing ghost user reduction and claim immediate credit against your licence fees.
Analytical and integration engines are the second-largest source of over-licensing in enterprise SAP estates. SAP sells SAP PI/PO (Process Integration/Process Orchestration), BW (Business Warehouse), HANA, Analytics Cloud, and Data Intelligence as platform necessities, often bundling them with core licence agreements at fixed metric levels that bear no relationship to actual usage.
The standard SAP package structure assigns static metrics for engine products: SAP BW is sold by "data volume" or "concurrent users"; SAP PI/PO is sold by "message volume" or "batch processing units"; SAP Analytics Cloud is sold by "users" or "rows queried." These metrics are rarely enforced uniformly, and SAP's own usage measurement (via the USMM or SAP Licence Audit Workbench) is notoriously imprecise for these products.
The contractual vulnerability lies in the gap between metric definition and enforcement. If your Order Form specifies "unlimited SAP BW concurrent users," SAP cannot later claim you owe additional fees based on an increase from 50 to 75 concurrent users — the entitlement is unlimited. Conversely, if your contract specifies "5GB BW data volume," SAP can argue you've exceeded entitlements if usage grows to 8GB. The key is understanding which metrics are enforced and which are aspirational.
SAP PI/PO is sold using one of three metrics: named users, message volume, or integrated system connections. Most enterprises over-purchase on all three dimensions. They license PI/PO for 100,000 daily messages when actual peak volume is 35,000. They license connections for 15 integrated systems when the current integration map shows 8. They license named users (PI/PO administrative users) as if every integration team member needs full access when, in reality, one or two architects and developers manage 90% of integrations.
BW over-purchasing follows a similar pattern. Most enterprises license BW for significantly higher data volumes than they load. They contract for 100GB of BW storage when actual load is 35GB. They license concurrent BW users for a peak that occurs once quarterly during quarter-close reporting, not as a daily norm. The contractual opportunity is to revisit the BW metrics based on a 12-month usage analysis. Extract data from transaction DBACOCKPIT or the SAP BW technical tables (RSTATS table) to quantify actual usage peaks and propose a metric reduction that reflects the 85th percentile of observed activity, not the theoretical maximum.
Analytics Cloud and the newer SAP Analytics products (Business Technology Platform analytics) are the fastest-growing over-licensed category because customers rarely understand the transition from BW to Analytics Cloud licensing. SAP frequently sells both products concurrently during migration, claiming they're needed for "parallel operation." In reality, parallel operation rarely requires full licensing of both. Post-migration, many enterprises find their Analytics Cloud licence is vastly over-provisioned.
SAP's cloud and suite products — Ariba (procurement), Concur (expense), SuccessFactors (HR and talent) — use user-based licensing that is often inflated to accommodate future growth or organizational restructuring. Enterprises license Ariba for 500 procurement users when actual active users are 180. They license Concur for all 10,000 employees when only 3,500 expense regularly. They license SuccessFactors Employee Central for the full population when not all business units have deployed the product.
These metrics are measurable and auditable. Ariba usage is tracked in the Ariba Spot Buy transaction logs; Concur tracks expense submissions by user; SuccessFactors tracks logged-in users by module. A 12-month analysis of these logs will almost always show significant whitespace between licensed user counts and actual active user counts. The contractual position is that you should pay only for users who execute transactions. When active usage is 60% of licensed seats, you have a strong negotiation position to reduce the licence count and recapture the overpayment.
The challenge is that SAP will claim "active growth planning" or "surge capacity" justifies higher metrics. Counter this by demonstrating that the 12-month analysis spans seasonal peaks (quarter-end close for Concur, hiring cycles for SuccessFactors, procurement events for Ariba). If usage never reached 80% of licensed capacity, the extra capacity is not justifiable.
SAP's own licensing best practice documentation (SAP Note 0000011112) recommends metric reviews at every contract renewal. Most enterprises never perform these reviews, leaving millions in unused entitlements unpurged from their Order Forms.
SAP Enterprise Support represents a 22% annual tax on your licence base. For a €10 million licence estate, you're paying €2.2 million per year for support, regardless of whether you use SAP's support channels or not. This is the second-largest controllable cost centre in your SAP spend, after licences themselves.
Conventionally, enterprises have accepted this as non-negotiable. SAP's licensing model doesn't allow you to "opt out" of support — it's contractually mandatory and included as a percentage of net licence value. However, the support cost reduction opportunity is embedded in three mechanisms: (1) third-party maintenance providers, (2) support level downgrades, and (3) focused support scope reduction.
Your Enterprise Support contract almost certainly specifies support at either 22% or 24% of net licence value annually. This percentage compounds year-over-year if your licence base grows (through new user additions or SAP version upgrades). A €500,000 annual support bill grows to €610,000 in Year 5 if your licence base grows at 5% annually, even if your user count remains static.
The contractual language usually reads: "SAP will provide software support (including patches, updates, and technical assistance) during the term of the licence and continuing thereafter subject to annual maintenance renewal." The "thereafter" clause is key — your support obligation is perpetual unless you formally terminate it. This is where cost leverage exists. If you consolidate users (Strategy 1) or eliminate ghost users (Strategy 2), your licence base shrinks, and your support cost shrinks proportionally. A 10% reduction in named users = 10% reduction in Enterprise Support fees, calculated on your new, lower licence base.
Additionally, most enterprise support contracts include optional SLAs (service-level agreements) that specify response times. If you're paying premium SLA support (4-hour response, 24/7 availability), you can reduce costs by 15–20% by shifting to standard SLA (8-hour business hours). This is particularly feasible if your operations are regional, not truly 24/7 global.
Third-party maintenance providers (Rimini Street, Micro Focus, HCL, and others) now provide SAP support services at 40–50% lower cost than SAP Enterprise Support while maintaining contractual compliance with your SLA obligations. SAP has historically challenged third-party maintenance during audits, claiming that non-SAP support violates the licence terms. This position has weakened considerably as third-party providers have demonstrated compliance with standard support SLAs and as legal precedent has established that customers have the right to source support independently.
The key contractual point is that your Order Form specifies maintenance for "support services to keep licences current and secure." It does not mandate that SAP be the sole support provider. If a third-party provider meets your SLA requirements (incident response time, security patches, regulatory compliance), you can transition from SAP Enterprise Support to third-party support and claim a cost reduction equal to the difference between SAP's 22% rate and the third-party's negotiated rate (typically 10–12% of net licence value).
SAP's pushback is that you lose access to SAP's technical resources and knowledge base. This is partially true, but third-party providers have built extensive SAP knowledge bases and can resolve most non-critical issues independently. For truly complex issues requiring SAP's development team, you can maintain an emergency support contract with SAP (at a lower tier) while using third-party support for day-to-day operations.
During consolidation negotiations, third-party maintenance is a powerful lever. Present SAP with a quote from a recognized third-party provider and ask for SAP's best-effort pricing. SAP will frequently reduce Enterprise Support rates by 8–15% to prevent you from switching. Over a five-year period, even a 10% support cost reduction on a €2 million annual support bill yields €1 million in cumulative savings.
Most large enterprise SAP contracts accumulate metric complexity through acquisitions, divestitures, and incremental upgrades. You may have five different user type definitions (Professional, Limited Professional, Functional, Employee, Productivity) across various modules, plus three different engine metrics (BW concurrent users, PI/PO messages, Analytics Cloud rows), plus cloud product licences (Ariba users, Concur users, SuccessFactors users). This complexity serves SAP's interest (more metrics = more enforcement opportunities) and works against yours (more metrics = more audit disputes).
Contract metric simplification is the process of consolidating these disparate metrics into a smaller, clearer set that reduces SAP's audit enforcement leverage while maintaining your operational flexibility. The typical consolidation model moves from 8–12 distinct metrics to 3–5 core metrics, aligned to actual business needs.
Named User Equivalent (NUE), Functional User Equivalent (FUE), and Concurrent User licensing are SAP's three primary user-counting methodologies. Most enterprises license on a Named User basis because it's the simplest to understand and enforce. However, for certain user populations, FUE conversion yields significant savings.
FUE licensing is based on concurrent usage, not on the total number of named accounts. If you have 500 customer service representatives but only 150 are logged in simultaneously at peak hours, you can licence 150 FUEs rather than 500 named users. FUE conversion is appropriate for environments with significant time-zone dispersion (where different regions work different hours) or shift-based operations (where the same workstation is used by multiple sequential users).
The contractual risk is that SAP will audit concurrent usage and challenge whether your peak numbers are representative of typical days or anomalies. Counter this by establishing a 90-day usage baseline: measure concurrent user count during the busiest quarter (quarter-end close, peak season for retail, etc.) and use the 85th percentile of observed peaks as your FUE baseline. This is conservative and defensible.
For a call centre with 500 named agents and measured peak concurrency of 160, FUE conversion delivers savings of approximately 68% (from 500 named users to 160 FUEs). On a per-user licence cost of €1,800 and maintenance of 20%, the annual saving is: (500 - 160) × €1,800 × 1.20 = €748,800.
Acquisitions and mergers frequently result in licence portfolios with redundant or legacy metrics. You may inherit a subsidiary's SAP system that was licensed under "SAP R/2" user categories (an outdated licensing model) or a predecessor licence agreement that defined custom user types no longer used in your primary SAP system. These legacy metrics remain in your consolidated Order Form, creating ambiguity during audits.
Consolidation is the opportunity to clean up this legacy. In your contract renewal negotiation, propose a Schedule of Licences that eliminates all obsolete metrics from acquired entities and restates your entire licence position using your primary system's current definitions. This simplification reduces audit contention because there's no ambiguity about which user type definitions apply to which user populations.
Typically, this metric consolidation comes with a small cost: you may not recapture 100% of the licence value from the legacy products, as SAP will negotiate a transition adjustment. However, the compliance benefit (clearer terms, fewer audit disputes) and operational benefit (single set of user type rules across all systems) often justify the compromise.
If your enterprise is planning to migrate to RISE with SAP (SAP's cloud ERP subscription model), you must consolidate your on-premise licence estate before the migration. The reason is technical and contractual: RISE with SAP subscription fees are calculated based on your "baseline consumption" — a snapshot of your user count, transaction volume, and system metrics at the time you transition to RISE. If you consolidate after the migration, you cannot retroactively reduce your RISE fees.
The financial impact is substantial. RISE with SAP typically costs 15–25% more than equivalent on-premise Enterprise Support, with the premium justified by cloud infrastructure, automated upgrades, and reduced operational overhead. If your on-premise estate is carrying 15% ghost users or 30% over-licensed engine metrics, that over-provisioning becomes baked into your RISE baseline for the duration of the contract (typically 3–5 years).
Example: An enterprise with 1,000 named users and 18% ghost users (180 accounts) consolidates on-premise before RISE migration. They eliminate the 180 ghost users and right-size engine metrics. When they sign the RISE contract, their baseline is 820 active users, not 1,000. If RISE costs €1,800 per user annually, the five-year pre-RISE consolidation effort yields €900,000 in direct subscription cost savings (180 users × €1,800 × 5 years), plus the indirect benefit of carrying cleaner user data into the cloud environment.
The timing is critical. SAP will calculate RISE baseline fees within 60–90 days of your cloud go-live date. Any consolidation, user reclassification, or ghost elimination after that date has no impact on your RISE pricing. Therefore, if your migration is planned for Q2 2026, you must complete all consolidation activities by Q4 2025 at the latest. This creates a hard deadline for your consolidation project, which actually helps project governance — you cannot delay the effort indefinitely.
Once your RISE baseline is finalized at cloud go-live, you cannot reduce your subscription tier or user count without a contract amendment. Amendments typically require 90-day notice and incur renegotiation penalties. Pre-migration consolidation is your only opportunity to establish a lower baseline cost.
Consolidation requires cross-functional sponsorship: your CFO needs to see the cost reduction, your CIO needs to understand the technical work, and your SAP Operations and Compliance teams need to execute the plan. A clear business case translates the strategies above into your organization's specific cost structure and timeline.
Your business case should quantify the following by strategy: (1) current state user count and composition by type; (2) transaction activity baseline (SM20, USMM data) to support reclassification targets; (3) ghost user count and maintenance cost; (4) engine and cloud product metric review against contractual entitlements; (5) current Enterprise Support rate and third-party alternatives; (6) contract renewal timeline and RISE migration timeline if applicable.
A typical mid-market enterprise (€5–10 million annual SAP licence and support spend) can expect consolidation savings of 12–18% of total SAP spend, realized over 18 months to 3 years. That translates to €600,000 to €1.8 million in cumulative savings. The costs of consolidation (advisory services, internal project management, legal review) typically run €80,000 to €150,000, yielding a payback period of 2–5 months.
Present the business case to your SAP partner and procurement team 4–6 months before contract renewal. Early visibility creates negotiating leverage. SAP is far more willing to offer discounts and metric concessions if they know consolidation is underway and you're prepared to defend reclassifications with evidence.
We've helped 40+ enterprises navigate consolidation: If your consolidation analysis is incomplete or your negotiations with SAP are stalled, our licensing team can provide independent verification of your reclassification targets, ghost user analysis, and engine metric usage. Explore our License Optimisation service or contact us for a consolidation strategy session.
A typical consolidation project spans 4–8 months from analysis to final SAP agreement: 1 month for data extraction and analysis, 2–3 months for reclassification evidence compilation, 1 month for internal legal and compliance review, and 1–2 months for negotiation with SAP. You should begin 6 months before your contract renewal date. If RISE migration is planned, you must complete consolidation before your cloud go-live date to lock in the lower baseline.
SAP will challenge some reclassifications, particularly if they reduce your Professional user count by more than 20%. However, if your evidence is based on transaction activity logs (SM20, SUIM_ROLES) and authorization role assignments (SU01), your position is defensible. Industry best practice is to prepare for SAP to dispute 30–40% of your reclassifications and to be willing to compromise on the most marginal cases (users with activity in adjacent modules). Your non-marginal cases (portal users, single-module specialists) should be uncontestable.
Ghost user elimination is a unilateral action. You own the SU01 user master, and deactivating dormant accounts is an operational decision, not a licensing decision. However, you must document the evidence (SM20 logs, SM37 batch logs, SU01 lock dates) and include this documentation in your consolidation submission to SAP. Presenting evidence-backed ghost user elimination during contract negotiation demonstrates governance and shifts the burden of proof to SAP if they challenge the elimination.
The risk is low if your evidence is solid, but it's non-zero. SAP's worst-case response is to audit your environment post-consolidation and demand that you re-license users they believe should be reclassified upward (Professional, not Limited Professional). However, this is rare in practice because SAP faces contractual risk: if they demand reclassifications based on claimed "business need," they must justify why that need didn't exist before your consolidation. Most disputes resolve through compromise: you retain 80% of your reclassifications and adjust the remaining 20% to a middle ground. If SAP escalates to litigation, the burden is on them to prove that users require Professional-level access based on your contract terms, which is difficult without evidence of actual use.
Consolidation is strongest as a renewal negotiating position. If you approach renewal having already reclassified users and eliminated ghost accounts, SAP knows the consolidation is operational fact, not speculation. They will then negotiate from a weaker position, knowing you've reduced your actual user base and they cannot claim the old user counts still apply. If consolidation is still in progress at renewal, SAP will try to negotiate based on your current (unconsolidated) state and will resist accepting your projected consolidation targets. Timing matters: complete consolidation 2–3 months before renewal, document everything, and then present SAP with evidence and demand revised terms based on your new, lower baseline.
Get expert insights on licence consolidation, contract negotiation, and audit defence delivered to your inbox monthly.