SAP License Management and Maturity Model: From Reactive to Strategically Embedded Governance

SAP license management consists of three interlocking disciplines: correct license type classification (Named User and FUE), ongoing measurement using USMM, LAW, and SAM4U, and organizational governance maturity, which determines how systematically these disciplines are embedded in day-to-day operations. Bringing all three together lets you manage the permissions governance moment and the usage governance moment in a planned, audit-independent way.

Why License Management Is More Than Compliance
Named User License Types: ECC, S/4HANA On-Premise, Distinctions
The FUE Model: Mechanics, Conversion Weights, Calculation Formula
Authorization-Based Classification in S/4HANA and FUE Implications
Measurement Tools: USMM, LAW, SAM4U, SAP for Me
PCE Metering: A Paradigm Shift and Current Quality Boundaries
Audit Types, Triggers, and the Structured Audit Process
Common Compliance Gaps and Their Financial Exposure
SAP License Maturity Model: Four Levels, Concrete Self-Assessment
Cross-Product License Governance: SuccessFactors, Ariba, BTP in Your Portfolio
Organizing License Management: Roles, Cadence, Tools
How-To: Building License Governance in Six Steps
FAQ
Next Steps

1. Why License Management Is More Than Compliance {#1-why-license-management-is-more-than-compliance}

In practice, "SAP license management" is often reduced to a single use case: preparing for an upcoming SAP audit. That framing is too narrow. Organizations that think about license management only in audit contexts are addressing the symptom, not the cause.

Two Dimensions: Compliance and Ongoing Governance

Compliance is the baseline requirement: Named User types and FUE volumes must align with actual usage. Failing to meet this requirement risks back payments, back-maintenance charges, and a weakened negotiating position at your next renewal.

Ongoing governance is the more advanced discipline: systematically recognizing, acting on, and documenting governance moments in the license domain. The usage governance moment asks whether FUE types match the actual access needs of your users. The permissions governance moment asks whether roles are correctly scoped and whether PCE metering evaluates those roles accurately. Both governance moments arise not during an audit, but in day-to-day operations, month after month.

Four Governance Moment Areas and Their License Relevance

SAP license management touches all four governance moment areas that FinOptory distinguishes for ongoing contract governance:

Usage is the most direct dimension: How many users of each type are active? Which FUE types are actually needed? Inactive accounts, incorrect FUE types, and underestimated growth rates all surface in the usage governance moment.

Permissions are the decisive factor in S/4HANA Cloud, because classification is authorization-based: what a user is allowed to do, not what they actually do, determines their FUE type. Role design is therefore a direct lever for license costs.

Infrastructure covers the question of which systems are licensed at all and which system environments are included in measurement. DR systems, sandbox systems, and training environments can trigger license obligations that were not accounted for in the initial plan.

Cost, finally, connects FUE consumption, invoice reconciliation, internal chargebacks, and renewal planning. If you do not continuously track cost trends in the cost governance moment, you will not notice variances until the next invoice arrives.

Why Reactive License Management Makes Predictable Budgets Harder

License management that only reacts to the next audit arrives too late, after the contract has been signed. Anyone who wants to make planned use of the usage and permissions governance moments needs an ongoing governance discipline. In practice, organizations without a structured license cadence tend to accumulate classification errors over multiple years. Resolving them in an audit context is more time-consuming and more expensive than continuous governance would have been.

Scope Versus SAM Tools

This pillar covers SAP license management in its full breadth: license types and FUE mechanics, measurement tools, audit processes, and organizational governance maturity. Generic Software Asset Management (SAM) tools fall outside the scope of this pillar. Where SAP-native tools such as SAM4U, USMM, and LAW are relevant, they are covered in detail.

2. Named User License Types: ECC, S/4HANA On-Premise, Distinctions {#2-named-user-license-types-ecc-s4hana-on-premise-distinctions}

Named User is the classic SAP license metric: every person who accesses SAP requires an individually assigned license. SAP does not offer concurrent-user models. License types differ significantly in access scope and price. Misclassification is one of the most common findings in Enhanced Audits and generates substantial retroactive claims.

ECC License Types at a Glance

In classic SAP ECC landscapes (also known as SAP R/3), five primary license types apply:

Professional User is the most comprehensive type, granting full, unrestricted access to all modules and transactions. Power users, controllers, module consultants, and administrators typically fall into this category. List price is in the range of USD 3,000 one-time, with approximately 22 percent annual maintenance (sources: Redress Compliance, SAP Product and Pricing Definitions).

Limited Professional User grants restricted access to defined modules or functions. Read and write access within a functional area is typical. Warehouse staff, purchasing clerks, or accountants with a limited transaction scope fit this type. List price is approximately USD 1,500 one-time.

Employee Self-Service (ESS) covers simple self-service tasks: time recording, travel expense reporting, and viewing HR master data. This type is designed for all employees with minimal SAP access and is often purchased in bulk packages.

Developer User enables access to the ABAP Workbench, development tools, and customizing. The type is intended for ABAP developers and technical consultants. Importantly, Developer Users may only be used for development purposes, not for productive business processes.

Test User is governed by contract-specific terms and is used for QA teams and test automation in test and QA systems. Exact conditions vary considerably by contract.

For every license type, the audit checks whether the transactions actually executed match the assigned license type. A user with a Limited type who runs Professional transactions is underlicensed.

S/4HANA On-Premise Categories

With the introduction of S/4HANA, SAP updated the Named User type nomenclature. The five categories for S/4HANA On-Premise are:

Professional User is equivalent to the ECC Professional and grants full access to all modules and end-to-end processes. List price ranges from USD 3,000 to USD 6,000 one-time depending on region and negotiating position.

Functional User (also Limited Functional User) corresponds to the Limited Professional and allows access to defined functional areas. An employee who only runs logistics transactions typically falls into this type.

Productivity User is an evolution of the ESS type and permits narrow access: viewing data, approving requests, and simple data entry. This type is purchased at bulk rates.

Self-Service User corresponds to ECC ESS and covers simple self-service functions via Fiori or the portal: time recording, payslip retrieval, simple requests.

Developer User serves the same purpose as in the ECC context: ABAP development, customizing, and no use for productive business processes.

What Changes When Moving from ECC to S/4HANA

The nomenclature change from ECC to S/4HANA is more than cosmetic. SAP made adjustments to role-to-user-type assignments in 2025. Certain transactions that qualified as "Limited" in ECC may require "Professional" in S/4HANA. This can increase license demand even with an unchanged user base. For every upgrade or contract review, it is worth comparing the current role-to-user-type mapping against the previous version.

For organizations planning or executing an ECC-to-S/4HANA migration, a reclassification analysis before go-live makes sense. The permissions governance moment for the migration phase is a concrete planning item that should be embedded in the governance cadence.

Named User vs. FUE: Which Metric Applies When?

On-premise systems (ECC, S/4HANA On-Premise) and Private Cloud Edition (PCE) contracts with older structures are licensed by Named User type, with each type requiring individual compliance.

RISE with SAP (S/4HANA Cloud Private Edition) and GROW with SAP (S/4HANA Cloud Public Edition) use the FUE model: the weighted sum of all user types determines the total FUE requirement, which is compared against the purchased FUE pool.

In hybrid landscapes where on-premise and cloud systems run in parallel, both metrics operate simultaneously. That requires separate governance for the Named User dimension and the FUE dimension, with separate measurement tools and separate review cadences.

3. The FUE Model: Mechanics, Conversion Weights, Calculation Formula {#3-the-fue-model-mechanics-conversion-weights-calculation-formula}

The FUE model (Full Use Equivalent) replaces Named Users in RISE and S/4HANA Cloud contracts with a weighted aggregation. Customers purchase a FUE pool and allocate it internally across user types. The model provides flexibility, but it makes classification quality the decisive cost driver.

FUE Definition and Core Principle

A FUE is a standardized unit that converts different user types into a single licensing measure. The compliance condition is straightforward: as long as the weighted sum of all active users stays within the purchased FUE pool, the organization is compliant. Internal role shifts, for example from Advanced to Core, require no renegotiation with SAP, provided FUE headroom exists.

This pooling principle distinguishes the FUE model fundamentally from the Named User model: with Named Users, each type must be individually compliant. With the FUE model, a surplus in one type (for example, Self-Service) can offset an overage in another type (for example, Core), as long as the overall pool is not exceeded (source: SAP Community, RISE with SAP FUE Concept).

Conversion Weights

The four FUE types carry the following weights (source: SAP documentation, SAP Community):

User Type	FUE Weight	Users per FUE
Advanced	1.0	1
Core	0.2	5
Self-Service	0.033	approx. 30
Developer	contract-specific	contract-specific

The cost ratio between types is the critical planning parameter: one Advanced User equals 5 Core Users or approximately 30 Self-Service Users in FUE weighting. That means one Advanced User costs 30 times more in license terms than one Self-Service User and 5 times more than one Core User (source: redresscompliance.com, FUE Licensing Explained).

The Developer type warrants particular caution: in practice, different weighting values appear across contract versions. Some contract formulations count 0.5 FUE per Developer (two Developers per FUE), while others count 2.0 FUE per Developer (one Developer equals two FUE). With 20 Developers, the difference can reach up to 30 FUEs, which can be a six-figure sum. The specific contract must be reviewed before any calculation is based on this figure.

Calculation Formula and Worked Example

The basic formula for FUE demand is:

Total FUEs = (Advanced x 1.0) + (Core x 0.2) + (Self-Service x 0.033)

The result is rounded up.

A concrete example: an organization with 50 Advanced Users, 100 Core Users, and 300 Self-Service Users yields:

50 Advanced x 1.0 = 50.0 FUE
100 Core x 0.2 = 20.0 FUE
300 Self-Service x 0.033 = 10.0 FUE
Total: 80 FUE

If that same organization licensed all 450 users as Advanced, 450 FUE would be required. Correct classification reduces demand in this example by more than 80 percent (sources: SAP Community Blog by SAP: RISE with SAP FUE concept, RISE SDG v11-2024).

Savings Potential Through Role-Access Alignment

The greatest optimization potential lies in correctly matching user types to actual access needs. When a user is licensed as Advanced but only uses Core functionality, 0.8 FUE per user are wasted. Downgrading from Advanced to Self-Service frees up 0.967 FUE per user.

Correct classification according to actual functional scope is mandatory under the SAP Service Description Guide. Organizations that classify all users as Advanced by default are structurally overpaying. Optimization starts with an analysis of which transactions each user actually runs, not which permissions they theoretically hold.

Mid-Term Reductions Are Not Possible

One structurally important contract aspect: most RISE contracts prohibit reducing the FUE count during the term. If you buy too many FUEs, you pay for unused capacity until renewal. The initial FUE calculation is therefore not correctable until the renewal comes around.

This makes the starting calculation one of the most important governance moments in the FUE domain: it determines the cost baseline for the entire contract term. A True-Up/True-Down clause allowing an adjustment after 18 to 24 months is negotiable and should be actively addressed during contract negotiations.

Developer FUE: Always Check the Contract

As noted above, Developer FUE weighting varies by contract version. With 20 Developers, the difference between 0.5 and 2.0 FUE per Developer can be substantial. This point is unknown or undocumented in many organizations. The usage governance moment for Developer Users therefore explicitly includes verifying which weight applies in the current contract.

4. Authorization-Based Classification in S/4HANA and FUE Implications {#4-authorization-based-classification-in-s4hana-and-fue-implications}

In S/4HANA Cloud, user classification is authorization-based: anyone assigned a role with Advanced authorization is counted as Advanced, regardless of whether they actually use that authorization. Role design is therefore not purely a security matter; it is a license cost matter with a direct impact on FUE demand.

How Authorization-Based Classification Works

The underlying logic of authorization-based classification follows the Role-Based Access Control (RBAC) principle: each user is assigned roles, and each role is mapped to a FUE type. The highest authorization a user holds across their roles determines their FUE type. If a role contains Advanced authorizations, the user is an Advanced User, even if they never use the Advanced functions in their daily work.

This distinction from usage-based classification is fundamental: usage-based classification would measure what a user actually does. Authorization-based classification measures what they could do. In S/4HANA Cloud, the authorization-based model applies.

PCE Metering and Its Connection to Roles

In the context of the Private Cloud Edition (PCE), SAP runs automated monthly metering. It measures assigned roles, not actual usage. Metering results feed into the LAW consolidation and surface as consumption data in SAP for Me.

The permissions governance moment must therefore be addressed monthly in a PCE context, not annually. If a role review happens once a year, there are eleven months in which misclassifications are captured by metering without the organization being aware of it.

Role Creep as a Classification Risk

A pattern frequently observed in practice is role creep: the gradual expansion of authorizations beyond the licensed scope. A typical case is a Self-Service User who is assigned additional roles that effectively contain Core-level authorizations. The result: the user is classified as Self-Service in the system, but metering counts them as Core because the combined role breadth exceeds that threshold.

The consequence is not only a compliance risk, but a silent governance moment loss: FUE volume is consumed without any deliberate decision having been made. Technical restrictions, meaning the consistent limitation of roles to the authorization level actually required, are the most reliable protection against role creep.

STAR Analysis: Capabilities and Limits

SAP's STAR analysis (S/4HANA Trusted Authorization Review) is a tool for analyzing the authorization structure in the system. It shows which authorizations are assigned and thereby provides the data foundation for a FUE optimization analysis.

One important caveat: STAR results show assigned authorizations, not actual usage. Raw STAR data without a prior reconciliation against usage logs can produce inflated FUE counts and may give SAP grounds for compliance action. The recommended approach is therefore: run STAR internally, reconcile results against actual usage logs, optimize authorizations, and only then use the optimized data as the basis for negotiations or submissions.

Role Optimization Before the PCE Metering Cycle

The permissions governance moment has a clear time dimension in the PCE context: role optimizations completed before the monthly metering cycle improve the metering result for that month. Optimizations completed afterward only take effect the following month.

A quarterly role review as an operating standard therefore makes sense: it ensures that misclassifications are not layered across multiple metering cycles before being addressed.

5. Measurement Tools: USMM, LAW, SAM4U, SAP for Me {#5-measurement-tools-usmm-law-sam4u-sap-for-me}

SAP provides several standard tools for license measurement. Understanding which tool is suited to which purpose, and how they work together, is the foundation of any structured license governance. Running these tools continuously is better than using them only in preparation for an audit.

USMM (User and System Measurement Management)

USMM is the classic single-system measurement tool. The USMM transaction is available in every SAP system and is typically run by the SAP Basis administrator. It measures Named User counts by license type as well as engine metrics for the respective system.

One important characteristic of USMM: it counts every Named User regardless of activity. Inactive accounts and duplicates inflate the measured count. This makes regular cleanup of inactive accounts a prerequisite for a reliable USMM measurement. The recommended threshold is 90 days without login, after which an account should be flagged for removal.

In the on-premise context, USMM is used at least annually for the Annual Measurement. In the PCE context, monthly automated metering largely replaces manual USMM execution for consumption measurement, but USMM remains relevant for internal self-audits and plausibility checks (source: SAP Help, License Administration Workbench).

LAW (License Administration Workbench)

LAW (transaction code SLAW2) is the multi-system consolidation tool. Its core capability is deduplication: when the same person has user accounts in multiple systems, LAW counts them only once in the consolidated report. This is critical in multi-system landscapes, because USMM measures per system and performs no cross-system deduplication.

The LAW consolidation process involves exporting USMM measurement files from all systems, importing them into LAW, automatically and manually matching user accounts across systems, and generating the consolidated report that is submitted to SAP.

A challenge is user matching: when the same person has different user IDs in different systems (for example, "bmaendle" in ECC and "bernhard.maendle" in BW), the mapping must be maintained manually. Poor data hygiene around user IDs leads to artificially inflated license counts in the LAW report.

In PCE metering, LAW is a central consolidation element: automated metering data from the customer system is consolidated via LAW, transmitted to SAP using a secured and anonymized transfer protocol (with hashed user IDs), and made visible to the customer in the SAP for Me dashboard.

SAM4U (SAP Software Asset Manager)

SAM4U is a free tool installed in the customer system via SAP Note 3646933. A key advantage: data remains within the customer network. It is not a cloud service where data is transmitted to SAP or a third party.

SAM4U provides an interactive dashboard with several functional areas:

Enhanced SAP Usage Tracking delivers more precise and more frequent usage data than classic USMM, providing a solid foundation for well-informed classification decisions.

Optimized Opportunities identifies concrete reclassification possibilities: users who could be downgraded from a higher to a lower FUE type because their actual usage justifies the lower tier.

The Authorization Simulation (new as of Q4/2025) lets you simulate authorization changes and assess their impact on total FUE demand before the changes are actually implemented.

Starting Q1/2026, a Data API is available for integrating SAM4U data into external reporting platforms (source: SAP Note 3646933, DSAG AK Lizenzen 11/2025). This enables integration into broader governance tools without moving data out of the customer network.

SAP for Me

The cloud portal SAP for Me (available at me.sap.com/consumption) provides a dashboard for entitlements and consumption over time. The relevant access right is "License Utilization for Private Cloud." SAP for Me allows you to visualize entitlement status and consumption trends across time periods.

In the PCE context, SAP for Me is the primary dashboard instrument: it receives the LAW-consolidated and SAP-enriched metering data and makes it accessible to the customer. Granularity at the individual user level is limited in the standard configuration; SAP for Me reports aggregated data, not at the individual user level.

How the Tools Work Together

The four tools have complementary functions:

USMM delivers single-system data at the Named User level. LAW consolidates and deduplicates across all systems. SAM4U optimizes and analyzes, with a simulation function for authorization changes. SAP for Me visualizes entitlements and consumption at the portal level.

A complete license governance setup uses the combination: USMM and LAW for baseline measurement, SAM4U for ongoing analysis and optimization, SAP for Me for the consumption overview and reconciliation against the contractual framework.

6. PCE Metering: A Paradigm Shift and Current Quality Boundaries {#6-pce-metering-a-paradigm-shift-and-current-quality-boundaries}

With the Private Cloud Edition (PCE), SAP moved from annual self-measurement to monthly automated metering. This fundamentally changes the division of responsibilities between customer and SAP and raises the bar for ongoing governance.

The Paradigm Shift in Brief

In the on-premise model, customers ran the measurement themselves once a year and submitted the result to SAP. Errors or optimization needs typically became visible once a year.

In the PCE model, SAP triggers metering monthly and automatically. The frequency difference is significant: compliance errors can surface up to 12 times faster. At the same time, the responsibility for data quality remains with the customer, because the foundation of automated metering is the authorizations and roles stored in the customer system.

This shift has a direct consequence for governance moments: the permissions governance moment, which was previously relevant once a year, becomes a monthly governance moment in the PCE context.

Technical Prerequisites

PCE metering requires minimum technical prerequisites: SAP BASIS 740 minimum, including all relevant support packages. Systems must be reachable for metering; systems in maintenance windows are temporarily unreachable. These interruptions should be documented, as missing metering data for certain periods can prompt follow-up questions.

Architecture of the PCE Metering Flow

The technical process follows a defined path: the customer system provides metering data. LAW consolidates engine results and user data, with user IDs hashed for transmission. SAP processes the data and enriches it with contractual entitlement information. The result is made available to the customer in SAP for Me as a consumption dashboard.

The transfer is secured and anonymized. Hashed user IDs allow SAP to perform correct deduplication without transmitting personal data in plain text.

Current Quality Boundaries (as of Q4/2025)

In practice, PCE metering shows known quality boundaries that SAP continues to address. Discrepancies between automated metering and STAR reports are documented: what the STAR tool shows as the authorization structure diverges in some cases from what automated metering captures. The causes lie partly in the still-incomplete quality of engine results and partly in implementation differences across customer environments.

The recommendation: document discrepancies, do not silently accept them. If you notice a gap between your own understanding of the authorization structure and the metering result, record that gap in writing. An undocumented discrepancy can work against you in a renewal context.

What PCE Metering Means for Governance

The monthly metering cadence demands a monthly governance cadence. The PCE metering dashboard in SAP for Me should be reviewed monthly: is consumption within the expected range? Are there outliers pointing to role creep or misclassifications? Do metering results match internal calculations?

Role optimizations should be completed before the metering cycle, not after. If you are planning a cleanup, you need to know the metering date and schedule the optimization to take effect in the relevant month.

7. Audit Types, Triggers, and the Structured Audit Process {#7-audit-types-triggers-and-the-structured-audit-process}

SAP has the contractual right to audit license usage. Knowing the mechanics lets you manage audits in a structured way rather than reacting ad hoc. The foundation for that is the four governance moment areas, which in an audit context are not viewed in isolation but as a unit.

Basic Audit vs. Enhanced Audit

The Basic Audit is the annual standard measurement. SAP sends a measurement request by email, the customer runs USMM/LAW measurements independently and submits the results. Review depth is limited: SAP largely relies on self-reported data. Obvious gaps between licensed and measured user counts are detected, but deep role analyses typically do not occur.

The Enhanced Audit is a deep-dive review that SAP initiates every two to three years or on a trigger basis. SAP Global License Auditing (GLA) is involved. The scope is considerably broader: role analysis, transaction usage, indirect access, and system landscape. Duration is typically three to six months for more complex environments. Financial exposure in an Enhanced Audit is significantly greater, because deeper findings can surface.

Typical Audit Triggers

Audits do not happen at random. In practice, Enhanced Audits frequently coincide with commercial events:

Before renewals and RISE migrations, SAP has an interest in understanding actual license usage before new contract terms are negotiated. M&A activity (mergers, acquisitions, divestitures) changes the system landscape and requires a fresh determination of the license base. Past non-compliance findings increase audit frequency for the affected organization. Anomalies in a Basic Audit, such as significant deviations between reported and expected values, can trigger an Enhanced Audit.

These patterns make one thing clear: organizations that maintain stable license governance on an ongoing basis create better conditions for the audit situations that will inevitably arise.

Four-Phase Process

A SAP audit typically runs in four phases:

Phase 1: Notification (Week 1). SAP sends the formal audit notification by email, including scope, timeline, and contact persons. The immediate action is to activate the internal audit response team. This team should cover at least four functions: IT/Basis, Procurement, Legal, and a CFO/CIO sponsor. The faster the team is operational, the stronger the position for subsequent phases.

Phase 2: Measurement and Data Collection (Weeks 2 to 4). USMM is run in all relevant systems and LAW consolidation is performed. Before submitting data to SAP, an internal review and cleanup is advisable: remove inactive accounts, correct duplicates, address misclassifications. These steps are not data manipulation; they are legitimate data hygiene that should have happened before the measurement.

Phase 3: Data Submission and SAP Analysis (Weeks 4 to 8). The consolidated LAW report is submitted via the SAP Support Portal. Recommendation: submit only the data contractually owed, nothing more. SAP may ask follow-up questions and request additional data; every request should be checked against the contractual scope.

Phase 4: Findings and Negotiation (Weeks 8 to 16 and beyond). SAP presents the identified gaps. Each finding should be reviewed individually: is the basis correct? Is the classification accurate? Is the period of claimed underlicensing traceable? Negotiation over the scope and terms of the true-up is possible and common in this phase.

Recommendation for Audit Preparation

Cooperative but controlled is the approach that works best in practice. That means: meet deadlines and communicate openly, but submit only what is contractually owed.

The audit response team should not be improvised; it should be defined in advance. The four roles responsible in an audit context mirror the four roles in the general governance model: Contract Manager for contract structure and compliance assessment, Procurement for commercial negotiation, Controlling for the cost assessment of findings, and Executive for approvals and strategic decisions.

8. Common Compliance Gaps and Their Financial Exposure {#8-common-compliance-gaps-and-their-financial-exposure}

Most compliance gaps in SAP landscapes arise not from deliberate underlicensing, but from inadequate data hygiene, missing lifecycle processes, and classification errors that accumulate over years. The challenge lies in the structure, not with the people involved.

Misclassified Users (Most Common Finding)

Users with a Limited license who are running Professional transactions are, by consistent assessments from SAP compliance practitioners, the most common audit finding. Financial exposure is calculated from the price difference between license types, multiplied by the years of underlicensing, plus back-maintenance.

A worked example: 100 users with a Limited license who are actually running Professional transactions, at a price difference of approximately USD 1,500 per user, results in USD 150,000 in required additional purchases. Adding three years of back-maintenance (22 percent per annum on USD 150,000) brings total exposure to approximately USD 249,000 (source: Redress Compliance, SAP License Audit: A Survival Guide).

Industry estimates from SAP compliance consulting suggest that 15 to 25 percent of Named User licenses in an average organization are misclassified or surplus. This range illustrates that misclassification is not a rare exception but a structurally common pattern in organizations without an ongoing review cadence (source: Reveal Compliance, SAP User License Categories Explained).

Inactive Accounts and Duplicates

USMM counts every Named User regardless of activity. A user who left the organization 18 months ago but was never deleted from the system inflates the measured license count. In organizations without a structured offboarding process, this category can be significant.

Duplicates arise in multi-system landscapes when the same person has different user IDs in different systems and LAW does not automatically recognize them as identical. Poor data hygiene around user IDs is the most common cause. The 90-day threshold without login is an established best practice for removing inactive accounts.

Engine and Package Overages

In addition to Named User classifications, SAP examines engine metrics in Enhanced Audits: payroll runs, order management volumes, and other system-specific usage figures. Overages beyond the licensed volume result in retroactive license costs plus two to three years of back-maintenance.

Exposure here is particularly relevant because engine overages frequently go unnoticed until SAP identifies them in an audit. A monthly alert at 90 percent of licensed engine capacity is a practical preventive measure.

Indirect/Digital Access as an Underestimated Gap

When external systems, meaning non-SAP applications such as CRM systems, e-commerce platforms, or IoT sensors, create documents in SAP, those transactions fall under Digital Access licensing. Nine document types are defined, from Sales Orders and Purchase Orders to Financial Documents and Material Documents (source: SAP Digital Access Documentation).

The challenge lies in visibility: third-party integrations that have been running for years often have no clear documentation of how many SAP documents they create and of which type. An annual inventory of the integration landscape and the document volumes generated is therefore part of a complete license governance. Digital Access is covered in depth in Pillar 4 of this content series.

Unlicensed Systems

Sandbox, training, and disaster recovery systems can trigger license obligations that were not accounted for in the initial plan. The exact conditions under which these system types are considered license-bearing are contract-specific. An annual system inventory that also captures non-production systems is therefore part of the governance cadence.

9. SAP License Maturity Model: Four Levels, Concrete Self-Assessment {#9-sap-license-maturity-model-four-levels-concrete-self-assessment}

The license maturity model describes four stages of development in SAP license management: from reactive classification to strategically embedded license governance. Each level is defined by concrete, observable characteristics and provides orientation on what the next level actually requires.

For clarity: the general SAP Contract Governance maturity model (described in Pillar 1) covers all four governance moment areas. The license maturity model in this section goes deeper specifically into the license dimension: Named User, FUE, authorizations, measurement tools, and audit readiness.

Level 1: Reactive

At Level 1, classification happens at the outset but is not reviewed on an ongoing basis. USMM is only run when SAP requests it, not as an independent governance measure. There is no systematic connection between role design and FUE implications. Inactive accounts are not cleaned up regularly.

The permissions governance moment and the usage governance moment are not actively used at this level. They arise regardless, but remain untapped. The typical result is an accumulated backlog of remediation needs that only becomes visible in an audit.

Level 2: Documented

At Level 2, the license baseline is documented: license types, FUE quantities purchased, termination notice periods, and renewal dates are recorded. USMM is run internally at least annually. LAW consolidation exists. Misclassifications are known but not yet systematically addressed.

The transition from Level 1 to Level 2 is the step from no documentation to reliable documentation. The contract review is a structured entry point into Level 2: it captures the current state of the license baseline and makes classification variances visible for the first time.

Level 3: Actively Managed

At Level 3, quarterly self-audits are established as an operating standard. SAM4U is installed and actively used. Role optimization takes place before the PCE metering cycle. Inactive accounts are systematically cleaned up after the 90-day threshold. FUE consumption is reconciled against the contractual FUE pool monthly. Classification changes triggered by SAP upgrades are proactively reviewed.

This level means that the usage and permissions governance moment areas are managed in a planned way. The PCE metering dashboard is not just a reporting instrument; it is a governance instrument reviewed monthly.

Level 4: Strategically Embedded

At Level 4, license governance is part of IT strategy and budget planning. FUE optimization is built systematically before renewal as a negotiating foundation. Scenario models for usage growth and classification changes are available. Cross-product license coordination, meaning alignment across RISE, SuccessFactors, BTP, and other product types, is an operating standard. The SAM4U Data API is integrated into a central reporting platform.

At this level, governance moments are not merely reactively visible; they are actively planned. The renewal process does not begin 90 days before the contract date; it begins 12 months out, with a cleanly built FUE optimization analysis as the negotiating foundation.

Self-Check: 8 Questions to Assess Your License Governance Maturity

The following eight questions allow an initial assessment of your license governance maturity:

Is it documented which Named User types or FUE types are licensed in the current contract and at what price?
Is USMM run internally at least once a year, independent of SAP requests?
Is a LAW-consolidated report produced for all systems in the landscape?
Are inactive accounts cleaned up according to a defined process and threshold (90 days)?
Is SAM4U installed and actively used for classification optimization?
Is FUE consumption reconciled against the contractual FUE pool monthly?
Are role optimizations scheduled before the PCE metering cycle?
Is the license situation addressed as part of IT budget planning and the renewal preparation process?

1 to 2 "yes" answers correspond to Level 1. 3 to 4 "yes" answers correspond to Level 2. 5 to 6 "yes" answers correspond to Level 3. 7 to 8 "yes" answers correspond to Level 4.

10. Cross-Product License Governance: SuccessFactors, Ariba, BTP in Your Portfolio {#10-cross-product-license-governance-successfactors-ariba-btp-in-your-portfolio}

License management does not end with S/4HANA. If you operate a SAP portfolio with multiple product types, you are managing different license models simultaneously, with different metrics, different measurement timings, and different compliance requirements.

SuccessFactors: Per-Employee Model

SuccessFactors is licensed per active employee. Every change in headcount, whether through hiring, attrition, or restructuring, has a direct impact on the monthly invoice. Unlike the FUE model, there is no "consuming a pool"; there is a direct metric that can change every month.

For governance, this means the usage governance moment in the SuccessFactors context is relevant monthly. During major reorganizations or workforce reduction programs, adjustments to the license count can be time-sensitive. Starting August 2026, EU AI Act requirements apply to SuccessFactors features that support HR processes such as candidate screening. These features may be classified as high-risk AI systems and require their own documentation and governance measures.

Ariba: Transaction Fees Alongside Subscription

Ariba combines a subscription component with transaction fees on the Ariba Network. Network transaction fees accrue per document exchanged over the network. At higher procurement volumes, these fees can be significant.

The cost governance moment in the Ariba context requires ongoing monitoring of transaction volumes: are volumes within the budgeted range? Are there periods with unexpected volume spikes? Are the contractually agreed volume tier boundaries known?

BTP: Credit-Based Licensing

BTP (SAP Business Technology Platform) is licensed via credit entitlements (CPEA: Cloud Platform Enterprise Agreement, BTPEA: BTP Enterprise Agreement). These credits can be applied to a wide range of BTP services but expire at year-end if unused.

AI Units for SAP Business AI functions are a separate consumption pool and are not charged against BTP credits. Details on AI licensing and AI Units are covered extensively in Pillar 2 of this content series; details on BTP FinOps governance are in Pillar 3.

Portfolio Coordination as a License Governance Task

Simultaneously managing S/4HANA FUE, SuccessFactors per-employee, Ariba transaction volumes, and BTP credits requires a coordinated perspective. Different renewal cycles, different metrics, and different measurement contexts increase complexity.

Co-termination, meaning aligning the renewal dates of different product types, is a simplification option that can be actively raised in contract negotiations. It reduces the number of separate renewal processes and creates opportunities for portfolio-wide negotiating positions.

All four roles in the governance model must be active in cross-product coordination: Contract Manager for the cross-product contract structure, Procurement for renewal coordination and price negotiation, Controlling for cost allocation and internal chargebacks by product type, Executive for strategic prioritization and approvals.

11. Organizing License Management: Roles, Cadence, Tools {#11-organizing-license-management-roles-cadence-tools}

License governance does not work as a one-person task. Four roles share responsibility, and a defined cadence ensures that governance moments are not missed.

Four Roles and Their License Responsibilities

Contract Manager is the primary role for license governance: maintaining the license baseline, calculating FUE demand, monitoring clauses (especially mid-term reduction prohibitions and True-Up/True-Down options), and serving as the first point of contact when an audit notification arrives. The Contract Manager is the sponsor for SAM4U analyses and the recipient of consolidated LAW reports.

Procurement owns the commercial dimension: preparing for renewals using the FUE optimization analysis delivered by the Contract Manager, negotiating True-Up/True-Down clauses and Digital Access entitlements, and coordinating across product types in cross-product renewals. In an audit context, Procurement leads the commercial negotiation over the scope and terms of the true-up.

Controlling connects license costs with financial planning: FUE cost allocation to cost centers and departments, budget forecasting for the next fiscal year based on current FUE consumption, and internal chargebacks in multi-unit organizations. Controlling also escalates variances between the license budget and the actual invoice.

Executive decides and prioritizes: approving role optimizations with organizational consequences, making strategic FUE planning decisions before renewal, and escalating audit findings with significant financial exposure. The Executive sponsors the contract review and is the first escalation point when the cost governance moment reveals budget variances outside the operating team's decision authority.

Governance Cadence for License Management

A structured governance cadence ensures that governance moments in the license domain are not missed.

Monthly: The PCE metering dashboard in SAP for Me is reviewed. Is consumption within expected ranges? Are there outliers? Inactive accounts identified in the past month are flagged for cleanup.

Quarterly: A self-audit using USMM and SAM4U is conducted. Role optimization takes place before the next metering cycle begins. FUE consumption is reconciled against budget and the contractual FUE pool. Classification variances are compared against the current SAP role definition.

Annually: LAW consolidation across all systems is performed. A full classification review takes place. The system inventory is validated, including non-production systems. The license maturity model is used as a self-assessment instrument.

12 months before renewal: A FUE optimization analysis is built as the negotiating foundation. SAM4U data is used to document the optimized FUE baseline. True-Up/True-Down clauses are evaluated. Portfolio coordination with other SAP product types is initiated.

Tools at a Glance

SAM4U is the central tool for ongoing measurement and optimization. It is free, runs within the customer system, and with the Authorization Simulation (available since Q4/2025) offers a function that simulates the FUE impact of role changes before they are implemented.

LAW is the consolidation tool for multi-system landscapes. It deduplicates user accounts across systems and is the central consolidation element between customer systems and SAP in the PCE metering flow.

A comprehensive governance platform that consumes the SAM4U Data API and embeds license governance in the broader context of contract governance is the next step beyond Level 3 of the maturity model. FinOptory is designed as a consumer of the SAM4U Data API: license measurement stays within the customer system, while FinOptory provides the governance layer that connects license data with contract parameters, renewal planning, and all four governance moment areas.

12. How-To: Building License Governance in Six Steps {#12-how-to-building-license-governance-in-six-steps}

Building structured license governance follows a clear sequence. The six steps move from current-state assessment through optimization to embedding governance in the operating cadence.

Step 1: Assess the Current State (USMM and LAW)

USMM is run in all systems and measurement files are exported. LAW consolidation is performed. The result is a complete overview of current license counts and classifications by product type and license type.

This assessment creates the foundation that all subsequent steps build on. Without reliable baseline data, any optimization measure is speculative. The contract review that FinOptory offers as a structured entry point goes beyond a pure USMM/LAW assessment and places the license baseline in the context of the contractual agreements.

Step 2: Reconcile Classification Against Actual Usage

SAM4U is installed and Enhanced Usage Tracking is activated. The STAR analysis is run internally and results are reconciled against actual usage logs. The result is a list of misclassifications and their FUE impact: how many users could be downgraded from a higher to a lower FUE type, and how many FUEs would that free up?

This step requires collaboration between the Contract Manager (who assesses the FUE impact), IT/Basis (who provides the technical usage data), and Controlling (who calculates the cost impact).

Step 3: Clean Up Roles and Optimize Authorizations

Role creep is identified and technically restricted. Inactive accounts are cleaned up after the 90-day threshold. The result is an optimized FUE baseline that serves as the foundation for negotiations and ongoing planning.

This step directly addresses the permissions governance moment: completing the role cleanup before the next PCE metering cycle ensures that the next metering result reflects the optimized situation.

Step 4: Define the License Governance Cadence

Responsibility for individual governance tasks is assigned to the four roles. Monthly, quarterly, and annual checkpoints are established and integrated into the existing IT governance cadence. The PCE metering dashboard in SAP for Me is included in monthly reporting.

This step makes license governance independent of individual initiatives. A governance structure that only functions when a specific person takes care of it is fragile. The cadence must be institutionalized.

Step 5: Build Audit-Readiness Documentation

Structured documentation is created: which users run which transactions and why? Technical roles are mapped to license types. The integration landscape for Digital Access is documented: which third-party systems create SAP documents, and in what volume? The audit response team is named.

This documentation is the foundation for the four-phase audit process. An organization that can draw on prepared documentation in an audit situation is significantly better positioned than one that creates documentation only after receiving an audit notification.

Step 6: Anchor License Maturity in the Governance Review

The license maturity model is used as a self-assessment instrument in the quarterly governance review. All four roles participate. Cross-product coordination (S/4HANA, SuccessFactors, Ariba, BTP) is a standing agenda item. Progress from level to level is documented and established as a strategic goal.

This final step closes the loop between operational license governance and strategic contract governance. Organizations that systematically manage their license maturity build the data foundation that generates concrete negotiating leverage in the cost governance moment and during the renewal process.

13. FAQ {#13-faq}

What is the difference between Named User and FUE?

Named User is the license metric for on-premise systems (ECC, S/4HANA On-Premise): each person requires an individually assigned license of a specific type. FUE (Full Use Equivalent) is the license metric for S/4HANA Cloud systems (RISE, GROW): different user types are converted into a single unit using different weights, and customers purchase a FUE pool that they can allocate internally.

How do I calculate my organization's FUE demand?

The basic formula: Total FUEs = (Advanced x 1.0) + (Core x 0.2) + (Self-Service x 0.033). The result is rounded up. The Developer type is weighted contract-specifically (0.5 or 2.0 FUE per Developer) and must be verified separately. SAM4U offers a simulation that calculates current FUE demand based on the actual authorization structure and highlights optimization potential.

Why is the conversion rate for Developer Users contract-specific?

SAP has not established a uniform standard weighting for Developer Users across all contract versions. In practice, different weightings appear: 0.5 FUE per Developer in some contract versions, 2.0 FUE per Developer in others. The difference with 20 Developers can reach up to 30 FUEs, which can be a six-figure sum. The specific contract must always be reviewed.

What is authorization-based classification and how does it differ from usage-based classification?

Authorization-based classification measures what a user could do (assigned authorizations). Usage-based classification would measure what a user actually does. In S/4HANA Cloud, the authorization-based model applies: the highest authorization across assigned roles determines the FUE type, regardless of actual usage.

What is the difference between USMM and SAM4U?

USMM is the classic single-system measurement tool: it counts Named Users by license type and measures engine metrics. SAM4U is a modern optimization tool with a dashboard, Enhanced Usage Tracking, optimization recommendations, and a simulation function for authorization changes. SAM4U is free, runs within the customer system, and offers considerably more analytical depth than USMM alone.

What does LAW do and when do I need it?

LAW (License Administration Workbench) consolidates USMM results from multiple systems into a single report and deduplicates user accounts that exist in more than one system. LAW is necessary as soon as more than one SAP system is present in the landscape. In the PCE metering context, LAW is the consolidation element between customer systems and SAP.

What is PCE metering and what does it mean for my governance?

PCE metering is SAP's automated monthly license measurement system for the Private Cloud Edition. Unlike the annual on-premise audit cycle, SAP triggers metering monthly. That requires a monthly governance cadence: review the PCE metering dashboard, complete role optimizations before the next metering cycle, document discrepancies.

What audit types exist and how do they differ?

Basic Audit is the annual standard measurement: self-conducted, limited review depth, moderate risk. Enhanced Audit is a deep-dive review: SAP GLA involved, in-depth role analysis, transaction usage and indirect access examined, duration three to six months, significant financial exposure. Enhanced Audits frequently coincide with commercial events (renewals, migrations, M&A).

What are the most common SAP compliance gaps in practice?

The most common categories are: misclassified Named Users (15 to 25 percent in an average organization, per industry estimates), inactive accounts and cross-system duplicates, engine and package overages (often unnoticed), and missing or inadequate Digital Access licensing for third-party integrations.

What is the financial exposure from misclassification?

With 100 misclassified users (Limited license, actually running Professional transactions) and a price difference of approximately USD 1,500 per user, the required additional purchase is USD 150,000. Adding three years of back-maintenance (22 percent per annum) of approximately USD 99,000 brings total exposure to approximately USD 249,000. For engine overages or indirect access gaps, exposure can be considerably higher.

Can I reduce FUEs during the contract term?

In most RISE contracts, a mid-term reduction of the FUE count is not possible. If you buy too many FUEs, you pay for them until renewal. A True-Up/True-Down clause that allows an adjustment after 18 to 24 months is a negotiable contract element that should be actively addressed during contract negotiations.

What is a True-Up/True-Down clause in RISE?

A True-Up/True-Down clause allows the FUE count to be adjusted after a defined period (typically 18 to 24 months after contract start). True-Up means additional FUEs are purchased when actual demand exceeds the original calculation. True-Down means FUEs can be reduced when actual demand is lower. This protects against paying for unused FUE capacity until the end of the contract term.

What does license maturity mean and where do most organizations stand today?

License maturity describes how systematically an organization manages its Named User and FUE governance: from reactive classification (Level 1) to documented baseline (Level 2), an actively managed operating cadence (Level 3), and strategic embedding in IT planning (Level 4). In practice, many organizations are at Level 1 or transitioning to Level 2. Moving from Level 2 to Level 3 requires establishing a regular self-audit cadence and deploying SAM4U as an ongoing optimization tool.

How does FinOptory differ from SAM4U?

SAM4U is a free, SAP-native tool for license measurement and compliance: it measures, identifies optimization potential, and since Q4/2025 offers a simulation function. SAM4U is focused on license measurement and provides no BTP/AI credit governance, no contract management, no internal chargebacks, and no forecasting. FinOptory is designed as a consumer of the SAM4U Data API: license measurement stays within the customer system via SAM4U, while FinOptory provides the overarching governance layer that connects license data with contract parameters, renewal planning, and all four governance moment areas.

14. Next Steps {#14-next-steps}

License governance is an ongoing management task, not a one-time project. The governance moments in the license domain, the usage governance moment and the permissions governance moment, arise monthly. Organizations that engage with them systematically manage in a planned way. Those that do not address them pay more than necessary and lose negotiating leverage at renewal.

Book a Contract Review: The structured entry point into Level 2. In four weeks, the current state of the license baseline is assessed, classification variances are identified, and the FUE baseline is documented. You get clarity on where you stand and a solid foundation for your next governance decision. Fixed price, four weeks, independent of SAP. EUR 7,900. Schedule an introductory call

Further Reading:

SAP Contract Governance: Governance Moments and Governance Foundations (Pillar 1)
BTP and SAP Business AI: Licensing and Governance (Pillar 2)
BTP FinOps: Managing Costs and Avoiding Credit Expiry (Pillar 3)
Digital Access and Indirect Access: Governance and Compliance (Pillar 4)

Author: Bernhard Mändle. Last updated: May 21, 2026. Questions and feedback: bernhard@green-dopamine.at

Table of Contents