SAP Named Users to FOE Licenses

RISE with SAP introduces a fundamentally different licensing model, shifting from traditional Named User licenses to a Full User Equivalent (FUE) metric. Under the FUE model consolidates all user access levels into a single measurable unit.

This unified metric is designed to simplify how enterprises purchase and manage SAP S/4HANA Cloud licenses.

One FUE represents a standard “full” user, with ratios defined for lighter or heavier usage profiles (for example, multiple low-level users count as a fraction of an FUE, and high-level developers count as more than one).

This change promises greater flexibility. Companies can allocate and reallocate FUEs among different types of users without requiring rigid license type counts.

It also means a single subscription covers the digital core, replacing the myriad of SAP named-user types with one contractual line item.

However, this simplification has important implications for CIOs, IT leaders, and sourcing professionals. In this new paradigm, organizations must adapt how they track usage and ensure license compliance.

License monitoring shifts to focusing on total FUE consumption, requiring new tools and processes to classify user roles by their FUE weight.

Cost transparency is improved at a high level (one consistent metric), but understanding the composition of that cost (advanced vs. casual users) becomes an internal exercise.

Enterprises will need to pay close attention to forecasting and contract terms. Committing to the right number of FUEs is critical, as under- or overestimating usage can have significant financial consequences in a subscription model with less flexibility for downscaling. In summary, SAP’s FUE model streamlines licensing on paper but demands proactive management to realize its benefits and avoid pitfalls.

Key Takeaways for IT and Sourcing Leaders:

• Unified Licensing Metric: The FUE model replaces dozens of named-user license types with one pooled metric, simplifying contracts but requiring careful internal mapping of user roles to FUE consumption.
• Flexibility and Reallocation: FUEs allow companies to flexibly redistribute license capacity among user categories (advanced, core, self-service, etc.) as needs change, potentially reducing shelfware.
• Monitoring and Compliance: Because FUE counts are based on user authorizations (not actual login activity), organizations must implement robust monitoring of roles and authorizations to stay compliant and avoid over-licensing.
• Cost and Forecasting Impact: FUE subscriptions shift costs to an OpEx model with clearer upfront pricing, but forecasting the correct FUE volume for multi-year terms is crucial. Overcommitting means paying for unused capacity, while undercommitting can lead to unbudgeted true-ups.
• Action Required: CIOs and sourcing professionals should treat the FUE transition as an opportunity to clean up user access, optimize license usage, renegotiate terms wisely, and establish ongoing governance for SAP license management under RISE.

Problem and Context

SAP’s traditional licensing model for ERP software has long been based on Named User licenses, where each user is assigned a specific license type according to their role and activities.

Under the classic model (especially in SAP ECC and early SAP S/4HANA on-premises), companies purchased different categories of named users, such as Professional, Limited Professional, Employee Self-Service, Developer, etc., each with its rights and price point.

This approach often led to complexity in tracking who had which license, ensuring the correct license type for each role, and avoiding license non-compliance or shelfware. Many organizations struggled with ambiguity in definitions (what exactly qualifies a “Professional” vs. a “Limited” user) and had to rely on periodic audits and manual assignment to stay compliant.

License management was further complicated by the need to estimate counts for each user type in contracts, and any growth or change in usage often required contract adjustments or additional purchases.

RISE with SAP (introduced in 2021) is SAP’s strategic cloud offering that bundles SAP S/4HANA (cloud edition) with other services under a single subscription contract.

A key aspect of RISE is overhauling the licensing approach for S/4HANA. Instead of dealing with a dozen user license SKUs, SAP introduced the Full User Equivalents (FUE) concept for S/4HANA Cloud.

FUE is a new metric consolidating various user types into one standard unit. SAP positions this as a simplification: rather than buying 100 Professional, 50 Limited, and 300 Employee Self-Service licenses separately, a company could, for example, contract for a pool of (say) 50 FUEs that covers all types of users under that unified count.

Under the FUE model, each user’s access level is translated into a fraction or multiple of an FUE:

• Advanced Users (akin to the old “Professional” users with broad access to modules and configuration) are weighted as 1 FUE each. These are users with full functional access – typically power users or key roles like accountants, controllers, or system configurators who use extensive features of S/4HANA.
• Core Users (comparable to “Functional” or limited users who perform operational tasks in a specific area) are counted at five users per 1 FUE. In other words, each Core user consumes 0.2 of an FUE. These might be roles like procurement clerks, shop floor schedulers, or sales processors – users who use the system regularly but only within a narrower scope of functionality.
• Self-Service Users (analogous to very limited “Employee Self-Service” or occasional users) are counted at 30 users per 1 FUE (approximately 0.03 of an FUE each). These include casual users who might only view reports, enter timesheets, or create simple requisitions and approvals.
• Developer/Technical Users (users with development or support-only access) also count in the FUE model, typically at a higher weight. For example, a developer user is often treated as 2 FUEs per person (0.5 users per 1 FUE). SAP classifies these separately because developers have deep system access (though not functional transaction usage) and they have advanced privileges. It’s worth noting that developer licenses under RISE may be handled via separate “developer access” terms, but when counted as part of FUE, the standard conversion used is 1 developer = 2 FUEs.

This unified scheme means that all direct human access to the S/4HANA digital core is quantified against a single metric.

SAP’s motivation for this change is to provide simplicity in licensing and flexibility in usage: customers get one contractual line item (e.g., “SAP S/4HANA Cloud Enterprise Management – X Full User Equivalents”) rather than juggling multiple user license types and counts.

The FUE approach also aligns with cloud economics by allowing customers to subscribe to a total capacity of usage (like a pool of resources) rather than fixed counts of each type of user.

Context of the Change:

For CIOs and IT leaders, this transition occurs in the broader push towards cloud and subscription models. SAP encourages customers to move off perpetual on-premise licenses and into cloud subscriptions (like RISE) by offering this simplified model and bundling infrastructure, support, and software in one package.

In practical terms, when an existing SAP customer transitions to RISE with SAP:

• Their old named-user licenses for SAP S/4HANA (or ECC) are converted/retired in favor of the FUE subscription. SAP typically provides a conversion program (such as the Cloud Extension Policy) where unused on-premises licenses can be terminated or credited as the cloud subscription kicks in, to protect the investment made in perpetual licenses. (The negotiation of this conversion – often referencing an internal “rule of 7” or other formulas – determines how much of the customer’s existing investment is offset against the new RISE subscription cost.)
• The contract will specify a certain number of FUEs that the customer is entitled to use. This number is often based on an initial assessment of the customer’s current usage. SAP might perform a license audit or measurement (e.g., a STAR report) on the customer’s systems to estimate how many FUEs their current users equate to. STAR (SAP’s “System Trust Audit” or “Secure Test for Audit Review”) uses actual user authorizations in the system to map each user to one of the FUE categories, thereby calculating a total FUE requirement for the landscape.
• Once under RISE, the customer pays a recurring subscription fee for those FUEs (and any additional cloud services in the bundle). Typically, FUE pricing is tiered: for instance, a larger commitment of FUEs might reduce the per-unit monthly price. Public information suggests that a mid-size tier might price an FUE around $150–$180 per month (actual pricing varies by region, edition (public vs private cloud), and negotiated discounts).

In summary, SAP’s restructured licensing approach with RISE moves from many license types to one metric, intending to streamline the experience. But understanding how a diverse user base translates into FUEs is a critical piece of context.

This model requires enterprises to consider overall capacity (like total “user consumption units”) rather than individual named licenses. For global organizations, the appeal lies in simplification—one contract, one bill, one metric—but the challenge lies in the details of conversion and ongoing management, which we explore next.

Key Challenges for Enterprises

Adopting the FUE model under RISE brings new challenges that IT and sourcing teams must address to ensure effective license management and cost control. Below are the key challenges enterprises are facing in this transition:

1. Mapping Users to FUE Categories:

Organizations must accurately assign each user to the appropriate usage category (Advanced, Core, Self-Service, etc.). This is not always straightforward—users’ roles can be complex, and there is a risk of misclassification without clear definitions.

A user given slightly too broad an authorization could be classified as a higher category (e.g., Advanced) when they only needed Core-level access.

The lack of clarity and automation in this mapping process means enterprises must invest time analyzing authorizations and possibly use SAP’s tools or third-party solutions to categorize users. Many companies realize they lack visibility into what each user does in the system, making it challenging to assign the right FUE category.

2. License Compliance and Monitoring:

Under FUE, compliance is measured against the total FUE count, which is derived from user authorizations. This means compliance is now tightly linked to how you manage user access rights. Enterprises face the challenge of tracking FUE consumption on an ongoing basis.

Today, SAP’s metering for FUE is still evolving. It may require running measurement reports (similar to the old USMM/SLAW for on-prem) and interpreting results. Automated, real-time consumption dashboards (via the SAP “For Me” portal or other tools) are in development but may not be fully deployed.

This creates a monitoring gap: companies must proactively run audits or use license management tools to know if they are within their contracted FUE limits. It’s a challenge to ensure that, as new users are onboarded or roles change, the total FUE usage doesn’t silently creep over the entitlement.

3. Role Design and Authorization Management:

Historically, many SAP customers followed a principle of role-based access, where a role might include a broad set of permissions for convenience (often to minimize the number of roles or ensure users had all the access they might need). Under FUE, this practice can backfire—“role bloat” can lead to users being classified in higher FUE categories than necessary. Excessive authorization assignment directly drives up the FUE count.

The challenge is to balance security and convenience against cost optimization. Enterprises might need to redesign roles more granularly, creating more fine-tuned profiles that give just enough access for a user’s job.

This is a change management challenge for SAP security/GRC teams: they must now consider license impact (FUE category) as part of role provisioning. Tightening authorizations without disrupting business processes requires careful analysis and often cultural change in how IT grants access.

4. Forecasting and Capacity Planning:

In a subscription model like RISE, customers are typically locked into a certain number of FUEs for the contract term (commonly 3 or 5 years). While it’s possible to increase the count (with additional cost) if usage grows, reducing it (if you overestimated) is usually not easy until renewal. This makes accurate forecasting critical and challenging. Enterprises must project not only headcount growth but also changes in usage patterns – for example, if new modules are deployed, will they create more advanced users?

If processes are automated, will some users move from core to self-service usage? The FUE model is new, so historical data for forecasting may be limited. Sourcing professionals find it challenging to predict the “mix” of user types in the future.

Over-forecasting results in paying for unused FUEs (shelf-ware in the cloud, which still wastes budget), while under-forecasting could mean mid-term expansions at less favorable rates.

Additionally, SAP’s tiered pricing means forecasting more users could lower the unit price but commit the organization to a higher base spend, finding that balance is non-trivial.

5. Cost Transparency and Management:

While one might assume a single metric brings transparency, enterprises are finding that internally allocating and managing costs can be challenging. In the old model, a department knew if it had 10 Professional and 20 Limited licenses assigned. In the FUE model, the entire pool is shared.

Companies need a way to internally charge or budget the subscription across business units or regions. This means they must translate FUE usage back into departmental usage (e.g., Department A used X advanced users and Y core users = Z FUEs).

Without proper internal reporting, IT leaders may be asked by finance about how the subscription cost correlates with business unit consumption.

Moreover, SAP’s FUE pricing is fixed per unit in the contract, which is transparent at a high level, but the value of each user can vary. For example, one advanced user (1 FUE) might be seen as “costing” the same as 30 self-service users (also 1 FUE in total). This can complicate discussions on productivity and ROI unless communicated.

6. Managing Contractual Terms and Audits:

Enterprises also face challenges in negotiating and managing FUE-based licensing. Many CIOs are navigating contracts where SAP bundles not just S/4HANA but other cloud services; understanding which services are measured by FUE and which are separate (e.g., some add-on products or digital access documents are still licensed separately) is vital.

Audit provisions under an RISE contract may allow SAP to check FUE usage periodically. A challenge here is that the methodology (based on user authorizations) can yield results that vary depending on how clean your user-role assignments are.

Customers have noted that initial SAP-run assessments can overstate FUE requirements if their roles are overly broad or outdated (e.g., test or inactive users with high privileges could count against you).

Companies must be prepared to discuss and potentially dispute audit findings by demonstrating optimizations or changes.

The traditional tension of SAP audits—ensuring compliance without paying for unnecessary licenses—persists, but now with a new metric that both parties are still getting familiar with.

7. Transition of Existing Licenses:

Another challenge for established SAP customers moving into RISE is the transition itself—converting from a capital expenditure model (with sunk costs in perpetual licenses and annual maintenance) to a subscription model.

While not directly a technical license management issue, it’s a financial and contractual hurdle. Sourcing professionals need to negotiate how existing investments are recognized. SAP’s Cloud Extension Policy offers some relief by allowing customers to surrender on-prem licenses in exchange for cloud subscriptions with certain credits or maintenance waivers.

However, the “give and take” can be complex: companies worry about not losing the value of hefty initial license investments. They also must plan for what happens to any remaining on-prem environments (e.g., non-production systems or other SAP software not in RISE)—those might still require some perpetual licenses, meaning they deal with both models for a period.

In summary, while the FUE model simplifies the contract structure, it introduces challenges in operations and planning. Enterprises must develop new competencies in license measurement, tighten their governance on user access, and negotiate/plan strategically to ensure the promise of simplification doesn’t become a cost trap.

In the next section, we’ll analyze these challenges and illustrate them with examples of how organizations cope under the new model.

How the FUE Model License To User

Under the hood, SAP’s Full User Equivalent model translates all user roles into a single metric, using predefined ratios.

The consolidation works by defining “use packages” that group capabilities. Each use package has a conversion rate to FUE.

Table 1 below provides an overview of how traditional SAP named user types correspond to RISE FUE categories and their weights:

Traditional User License Type	RISE “Use Package” (Access Level)	FUE Consumption per User	Typical Roles/Capabilities
Professional User (e.g. SAP Professional)	Advanced Use	1.0 FUE per user (1:1)	Full enterprise usage – broad access including configuration, high-level transactions (e.g. finance manager, plant manager)
Limited Professional / Functional User	Core Use	0.2 FUE per user (5:1)	Moderate scope – specific module or function (e.g. sales clerk, production planner, HR specialist)
Employee Self-Service / Occasional User	Self-Service Use	~0.033 FUE per user (30:1)	Very limited usage – primarily self-service, data entry, or read-only (e.g. employee entering time/expenses, casual approver)
Developer User / Support User	Developer (Technical) Access	2.0 FUE per user (0.5:1) *	Technical access for development or support (e.g. ABAP developer, basis support user with broad system rights)

Table 1: Consolidating classic SAP user types into FUE categories and their relative weighting.
(Note: In the FUE model, a Developer or Support user is typically counted as 2 FUEs due to their extensive system privileges. These technical users are usually a small subset of total users.)

With this consolidation, a customer no longer buys, for example, “500 Professional + 100 Limited + 1000 ESS licenses,” but rather a single quantity of FUEs. The customer can allocate those FUEs in any mix across the categories.

The power of this model is that if your user base’s needs change, you don’t have to purchase a different type of license—you can repurpose the FUE capacity you already have.

For instance, you might assume 100 users will be “Advanced” and 500 “Self-Service.” If 20 of those advanced users later change roles to only use self-service functions, you could reallocate that freed capacity to other needs. You are covered if the total weighted usage stays within your purchased FUEs.

Consider an example: A company has 30 FUEs in its contract, demonstrating how FUEs consolidate different usage levels.

There are many ways those 30 FUEs could be utilized, a few of which are shown in Table 2:

Scenario (30 FUE capacity)	Advanced Users	Core Users	Self-Service Users	Total FUE Used
All heavy users	30	0	0	30 FUE (30 × 1.0)
Mixed usage example	10	95	30	30 FUE (10×1.0 + 95×0.2 + 30×0.033)
Mostly light users	0	0	900	30 FUE (900 × 0.033)

Table 2: Different ways to allocate 30 FUEs across user types (illustrative example).

In the mixed usage example above, the company uses 10 advanced users (10 FUE), 95 core users (95 × 0.2 = 19 FUE), and 30 self-service users (30 × ~0.0331 FUE), totaling exactly 30 FUE.

This demonstrates the flexibility: the same 30 FUE allowance can support very different workforce profiles—either 30 power users, hundreds of lighter users, or a blend of both. The consolidation has effectively turned licensing into a math exercise of ensuring the weighted sum of users stays within the purchased FUE pool.

SAP also simplifies the sale by packaging the S/4HANA functional scope with the FUE metric. In a RISE contract, typically, the “SAP S/4HANA Cloud Enterprise Management” license (for a given edition) covers the core digital ERP platform usage via FUE. LoB modules (like Treasury, Extended Warehouse, etc.) might be additive, but many are now included or can be attached via the FUE metric as well, rather than separate named user licenses.

It means fewer line items on the contract – much of the needed functionality is bundled into that one FUE-driven subscription.

Real-life Observation:

Early adopters of RISE have reported that this bundling and metric made their purchasing process easier.

For example, a manufacturing firm’s CIO noted that instead of haggling over how many “warehouse user” vs “shop floor user” licenses they need, they just negotiated for the total FUE based on an agreed-upon user count and then internally determined how to allocate those across their operations.

It gave them one predictable bill and removed the need to continually adjust licenses when people’s roles changed – a significant administrative relief.

Implications for Tracking Usage and License Compliance

The move to FUE changes how organizations must track SAP usage internally. Under named user licensing, compliance was checked by counting users of each type and comparing them to entitlements.

Now, compliance is about the total FUE consumption. But since FUE is not something you directly assign to a user (you don’t label users as “0.2 FUE” in the system; you assign them roles, and the roles imply a category), tracking usage means tracking how each user’s authorizations map to the FUE categories and summarizing the results.

Tracking Usage:

In the RISE environment, SAP provides a license measurement toolset similar to the one used in the on-premise world. Typically, an admin will run a report (often using SAP’s License Audit Workbench or an Object Analyzer specifically adapted for S/4HANA Cloud) that evaluates each user’s authorization profile.

This tool will output the number of users who fall into Advanced, Core, Self-Service, etc., and then calculate the FUE total. SAP’s “SAP for Me” portal will eventually show continuous metered usage for cloud subscriptions, including FUE consumption.

As of the last year or so, SAP has begun rolling out automated FUE metering, meaning that over time, customers can log in and see their current consumption against their allowance. Until that is fully mature, companies often have to perform their checks. This might involve running the measurement quarterly or before true-up cycles.

One implication is that tracking moves from occasional true-up audits to potentially continuous monitoring. In a cloud model, SAP could have the capability to monitor usage more actively (even if it is not enforcing it in real time yet). CIOs should expect that transparency is increasing, both for them to track usage and for SAP to detect over-consumption.

License Compliance:

Compliance in an FUE model means ensuring that your total assigned FUEs do not exceed the purchased amount at all times (or at least at audit points). One advantage is that short-term fluctuations in one area can be offset by reductions in another without non-compliance, as long as the total stays under the cap.

For example, if you temporarily assign a user higher permissions (making them an Advanced user), that will raise the FUE count for that period. However, you could reduce another user’s permissions (or remove an inactive user) concurrently to stay within limits.

This was harder in the old model, where if you ran out of a particular license type, you were out of compliance even if you had excess in another category. In that sense, compliance management is more flexible with a pooled metric.

Conversely, because FUE compliance is based on user authorizations (essentially what users could do, not necessarily what they did), companies must be vigilant in controlling authorizations.

An idle user with a powerful role effectively ” consumes” an FUE even if they never log in. This emphasizes good IAM (Identity and Access Management) practices: timely de-provisioning of users who leave or change jobs, regular reviews of role assignments, and avoiding role drift.

Under a pure usage-based licensing model, an unused account might not cost anything; under an authorization-based model like FUE, an unused account with assigned access does count against you.

Industry observers have noted that authorization-based metrics can drive license counts 50% or more higher than if you only counted active usage, precisely because many organizations tend to over-provision access “just in case.” Paying for what you aren’t using is a key compliance risk.

Example – Managing FUE Compliance:

A global retail company that moved to RISE found that in the first year, their initial FUE allotment was being quickly approached. This was not because they added more employees than expected but because their internal project team had left many users with higher access levels than needed after go-live. Many end users were temporarily given Advanced rights during hypercar (the post-go-live support period) and never downgraded.

When they ran SAP’s measurement report, they exceeded their contracted FUE by about 15%. Fortunately, because of the unified metric, they didn’t have to purchase a new license type; instead, they launched a cleanup effort: tightening roles, removing extra privileges from hundreds of users, and even deleting accounts no longer in use.

After these housekeeping tasks, their FUE count fell below the licensed amount without impacting operations. They learned that continuous governance is needed, so they implemented quarterly internal audits of user access to ensure they remain compliant and don’t pay for “ghost users” or over-authorized users.

Another company in the services sector reported that SAP’s audit (STAR report) initially suggested they needed 500 FUEs based on their ECC system usage. This number was a shock, implying a much higher cost than their current maintenance.

With careful analysis, they realized the tool classified many users as Advanced because of broad role assignments, even though they didn’t use most of those transactions.

Restructuring roles and re-running the analysis brought the requirement down to 350 FUEs. This real-life scenario underlines that compliance and cost control under FUE require understanding how SAP’s tools classify your users. Companies shouldn’t blindly accept the first number; they should dig into why and how it is derived.

Cost Transparency and Forecasting under RISE

In financial terms, moving to FUE in a RISE model turns the previously one-time license purchase plus annual support into an all-in subscription fee.

For many CIOs and CFOs, this provides a clearer picture of ERP costs as an annual operating expense. There is a single line item for “ERP software usage” covering users, and it often includes infrastructure and basic support as part of RISE.

This can improve transparency at the budgeting level – you know what you pay per FUE, and thus can calculate the cost of adding (or the savings from removing) one unit of usage. The metric is also easier to communicate to executives: “We have 100 FUEs, which roughly corresponds to supporting 500 total users of various types.”

However, as mentioned earlier, internal cost transparency can diminish because you don’t see individual license types. For internal chargeback models, IT may have to create a formula to allocate the subscription cost to departments, perhaps based on a weighted user count per department.

Some organizations have developed internal “FUE calculators” to continuously translate the master FUE metric into business-consumable metrics (like cost per heavy user, cost per light user, etc.) for departmental billing purposes.

Forecasting Implications:

Forecasting under the FUE model requires thinking about both headcount and usage intensity. In the past, if a company planned to add 100 new employees who would use SAP, they might estimate that 20 would need professional licenses and 80 would need employee self-service.

They need to estimate how many FUE those 100 users will consume, depending on their roles. If all 100 are light users, that could be as little as ~3.3 FUE; if many turn out to be core users, it could be 20 FUE; if they include some advanced users, more.

So, scenario planning is needed. Typically, enterprises will forecast the mix of new users and use the conversion factors to project FUE growth.

SAP’s sales approach often helps here: they might propose a tiered growth plan in the contract. For example, a contract might start at 300 FUE in year 1 and ramp to 400 FUE by year 3 as the business expands or more legacy systems are migrated into SAP. This can lock in pricing for the additional FUEs needed later.

The challenge is ensuring these assumptions are realistic. If the usage ramp-up doesn’t happen as fast (e.g., project delays or slower user onboarding), the customer could be paying for unused FUEs in later years.

There have been cases where SAP included an aggressive increase in FUE (even doubling by the final year of the term) to give a better average price per FUE over the term and provision for future growth.

Sourcing professionals should be cautious about such terms—if the growth doesn’t materialize, the organization might be stuck with a bill for capacity it doesn’t use.

Example – Forecasting Pitfall:

A multinational firm signed a 5-year RISE contract that started at 200 FUE and, by contract end, was set to reach 400 FUE. This was based on a roadmap of adding new divisions to SAP. Midway, they realized the rollout was slower; by year 3 ,they had only reached 250 FUE of actual usage.

Yet, the contract committed them to 350 FUE in year 4, meaning they would pay for an extra 100 FUEs regardless of immediate need. In effect, they faced a significant cost increase with no corresponding business value for a period of time. The contract did not allow reductions (downscaling), only potentially deferring if SAP agreed.

They had to renegotiate to push out the ramp-up timeline, which was difficult and required concessions in other areas. The lesson was clear: build flexibility in forecasting or at least avoid aggressive commitments unless you’re certain of the timeline.

On the other hand, companies that accurately predicted their needs have found the model very straightforward. One mid-size enterprise new to SAP opted for RISE and counted all their employees who would use the system somehow.

They came up with several FUE that comfortably covered that, and added a 15% buffer for growth.

Over the contract, they consumed that buffer as they expanded, and the predictable cost per FUE meant each new project or acquisition’s ERP cost could be estimated easily (e.g., “adding this new subsidiary will bring 50 new SAP users, which equates to ~10 FUE, at $X each per month”).

In this sense, forecasting can be made easier when growth is linear and usage profiles are stable – the unified metric removes the need to guess different license types; you just track the aggregate.

Challenges and Opportunities: What Enterprises Are Experiencing

It’s worth noting that enterprises are reporting both positive and negative experiences with the new model, highlighting it as a double-edged sword:

• Simplified Negotiations and License Housekeeping: Some organizations appreciate that the FUE model forced them to thoroughly clean up their SAP users and roles. In preparation for RISE, they conducted internal license audits, often discovering that 20-30% of their named users were inactive or over-provisioned. By cleaning these up, they entered the RISE contract with a leaner, more accurate user count, sometimes negotiating a lower FUE count than their initial SAP quote. For example, a company with 1,000 named users found that after eliminating duplicates and retirees and adjusting roles, they effectively only needed ~800 users’ worth of FUE capacity to cover the same population, yielding significant cost savings. This rationalization might not have happened without the impetus of moving to the new model.
• Potential Cost Increases: Conversely, companies that have been very efficient with their old licensing or have had many occasional users may see a cost increase. If you previously didn’t license every light user (perhaps using a concurrency model or just not giving them access), under RISE, you might end up licensing more users because the FUE model assumes a more comprehensive approach (everyone accessing needs to be counted). Also, the shift to subscription means you’re continuously paying; over a typical 5-7 year period, the subscription fees can add up to more than what an initial license + maintenance would have in that same time. Analysts have observed that authorization-based cloud licenses can be 50% to 100% more expensive than pure usage-based models if an organization isn’t actively managing its usage. This means there is a real risk of higher TCO if you “set and forget” your FUE count and roles.
• Compliance Confidence vs. Audit Surprises: Under the old scheme, many SAP customers lived with a bit of anxiety around audits, because SAP could interpret license classification in their favor (for example, arguing that certain Limited users were using enough functions to require a full Professional license). Now, with clearly defined FUE categories tied to specific authorization scopes, there is more transparency. Companies can self-audit and know where they stand. One CIO mentioned that it’s easier to explain to auditors or SAP account reps that “User X only has core-level permissions, so they count as 0.2 FUE” rather than debating job titles. Because the tools are new, some have found initial SAP audit reports to “overstate” FUE usage. The burden is on the customer to analyze the output in these cases. For example, Turnkey Consulting (an SAP licensing advisor) noted that the first run of a STAR audit often counts too many users in Advanced, and customers need to optimize roles and perhaps rerun the measurement to get a true picture. The opportunity here is that if you do your homework, you can go into a contract negotiation or audit armed with data to push back on an inflated number. The FUE model gives a formula to argue with – something you can empirically adjust by changing authorizations, rather than subjective definitions.
• Internal License Governance: Enterprises are learning to integrate license considerations into their governance processes. For instance, change advisory boards and ITIL processes now include a check for license impact: if a new role is introduced or an existing role is modified, how does that affect FUE classification? Some have created an approval step that,if a user’s role change would bump them from Core to Advanced, it requires a business justification because it effectively uses more of the finite FUE pool. This level of governance was often absent in the past (where a license was procured upfront and then not thought about until true-up). Because each authorization potentially “draws” from the pool, it’s akin to having a continuous meter, and companies are instilling an ongoing discipline. This is challenging initially – it requires education of administrators and possibly new tooling – but in the long run, it leads to more efficient license use and fewer surprises.

Real-Life Example – License Optimization:

A concrete example of active management’s benefits comes from a European manufacturer’s case study. They had roughly 1,000 users on SAP and were evaluating RISE. An initial license assessment (mapping their users to FUE) showed they would need about 487 FUEs for full coverage.

Before signing, their IT and GRC teams undertook an optimization project: they reviewed each role and user, removed unnecessary transaction codes, and downgraded access where appropriate (without hampering actual work).

They also identified some users who could use a self-service interface instead of the full SAP GUI for their tasks. After this optimization, they recalculated the requirement: it came out to around 260 FUEs. In other words, by rightsizing roles, they cut their needed FUE by almost half, while still supporting 1,000 users.

This translated to enormous cost avoidance – in their case, an analyst estimated over $30,000 monthly savings in subscription fees compared to the unoptimized scenario. This example underscores a crucial point: the FUE model rewards those who proactively manage and optimize their SAP usage.

Organizations that take the time to align roles with actual needs can see significant efficiency gains (and cost savings), whereas those that don’t may end up overpaying.

Contract Management and Audit Scenarios under FUE

In terms of contracts, the shift to FUE requires careful attention to a few specifics:

• Entitlement Definition: The contract should clearly define an FUE, the user types (Advanced, Core, Self-Service, etc.), and their ratios. Most RISE contracts reference the official Service Description, where these definitions live. IT leaders should ensure they have a solid understanding of these documents. It’s wise to double-check that, for example, analytics or specific embedded functions don’t secretly bump a user to a higher category. SAP’s documentation typically spells out which activities fall under each use type (for instance, it may list that anyone who can post a journal entry or run a configuration transaction is an Advanced user). Knowing these details will help in compliance and discussions with SAP if disagreements arise.
• Audit Rights and Process: SAP will maintain the right to audit usage in a RISE contract. The process often involves the customer running the measurement tools and sharing results (or SAP having telemetry). What’s important is negotiating how often this can happen and the remediation process. Given that this is a subscription, if you are found over the licensed FUE count, the remedy is to procure additional FUEs (and possibly pay back fees if it was for some time). Customers should negotiate reasonable true-up mechanisms – for example, the ability to true-up at next renewal or add FUEs moving forward, rather than an immediate penalty. It’s also worth clarifying if bursting is allowed: say, one month you exceed FUE by a small amount but come back down – is that non-compliance, or is there tolerance? Usually, any sustained overage is addressed by an increase to your subscription.
• Flexibility Clauses: Some contracts include the ability to adjust the FUE count mid-term (usually only upward). If you anticipate a need for more, it can be good to lock in a price for additional FUEs, or a right-of-first-refusal to buy more at the same discount. Downward flexibility (reducing FUEs) is rarely granted. Still, in some cases of divestitures or significant business change, companies have been able to negotiate a reduction or swap (often by extending the term or adding other SAP products in exchange). A clause that discusses what happens if your business shrinks can be valuable, though not all customers can obtain that.
• Related Licenses: Remember that RISE’s FUE covers direct human users of S/4HANA. It does not cover things like indirect/digital access (e.g., if non-SAP systems create documents in S/4HANA – those are typically covered by a separate “digital access” document count license or are included in some packages up to a point) or certain add-on cloud services (SuccessFactors, Ariba, etc., which have their metrics). In contract management, it’s important to identify the scope of FUE. For example, if you also have SAP BTP (Business Technology Platform) in your RISE bundle, that might be measured in credits, not FUE. So, a challenge is managing a contract that, while simplified, still has multiple components. To avoid compliance issues in those other areas, CIOs should ensure their teams understand which usage is measured by FUE and which is not. For instance, a user might be licensed via FUE for S/4HANA. Still, if they also access SAP Ariba, they might need an Ariba license – RISE doesn’t magically cover all SAP products unless explicitly included.

Audit Scenario Example:

In one audit under the new model, SAP’s auditors identified that a customer had several service accounts (system/service users) with broad privileges. These were counted as “Support” users at 0.5:1 (2 FUE each). The customer had not counted these in their internal tally, focusing only on human users. This led to a discrepancy – they used an extra ~10 FUE for these service accounts.

The resolution was that the customer either had to reduce those accounts’ access or buy additional FUEs. They deleted some obsolete service accounts and narrowed the rest (transferring some tasks to technical job users who were licensed differently).

This highlights that everything with a user ID in the system counts in an authorization-based model, even those generic accounts that people sometimes overlook.

Opportunity – Leverage SAP’s Eagerness:

On the positive side of contract management, SAP is very motivated to make RISE deals attractive.

Many organizations have reported being able to negotiate considerable discounts or incentives, especially if they were early adopters, considering competitors, or staying on-premises. For example, some have received free additional FUEs for the first year or bundling of pilot subscriptions for other SAP cloud products.

SAP aims to move customers to the cloud so CIOs and sourcing managers can use this as leverage to address some concerns.

If you identify a particular challenge – the need for flexibility due to an upcoming reorganization – bringing that up during negotiation could lead SAP to craft a custom clause or give a pricing cushion.

It’s not purely a technical point, but a strategic one: the FUE model itself is fixed in how it works, but its commercial terms are negotiable.

In conclusion of this detailed analysis, the transition to FUE licensing under RISE with SAP is much more than a metric change; it touches processes, governance, and financial planning.

Real-world experiences show that with preparation and active management, companies can reduce their SAP costs and complexity (e.g., through optimized roles and eliminating idle licenses).

But without that diligence, the new model could lead to compliance issues or higher costs, either through paying for unnecessary capacity or facing true-up bills. The next section provides concrete recommendations to ensure CIOs and IT leaders get the most value from SAP’s new licensing approach while minimizing risk.

Clear Recommendations for CIOs, IT Leaders, and Sourcing Professionals

Organizations should take a proactive and strategic approach to successfully navigate SAP’s FUE licensing model under RISE.

Below is a Gartner-style playbook of clear recommendations and best practices:

1. Perform a Comprehensive License Baseline Assessment Before Moving to RISE:
Before signing a RISE contract or migrating to S/4HANA Cloud, conduct a thorough internal audit of your current SAP user licenses and usage. Leverage SAP’s measurement tools (USMM/SLAW or the S/4HANA Object Analyzer/STAR report) in a controlled manner to see how many FUEs your current environment would translate to. Identify discrepancies – for example, if SAP’s estimate seems high, investigate which users or roles are driving it. Goal: Arrive at a verified FUE count requirement that reflects actual business usage, not over-provisioning. Use this as the basis for negotiation with SAP, rather than accepting their first quote.

2. Optimize User Roles and Authorizations to Reduce License Demand:
Treat the transition to FUE as an opportunity to clean house in your SAP security design. Review all roles and trim unnecessary authorizations. Ensure each user has access that is appropriate to their job – no more, no less. This may involve removing powerful roles from users who don’t truly need them, splitting them into more granular ones, and eliminating outdated ones. Pay special attention to users that SAP’s tools classify as Advanced; verify if they genuinely need that level of access. Also, look at developer or system accounts and minimize their usage/permissions where possible. Goal: Minimize the FUE consumption by aligning it with actual usage needs, thereby avoiding paying for artificially inflated license requirements.

3. Right-Size Your FUE Subscription and Negotiate Flexibility:
When contracting for RISE, resist the urge to pad the FUE count “just in case.” Instead, right-size the subscription to your optimized usage plus a reasonable buffer (for growth or contingency). If SAP proposes a multi-year ramp-up of FUEs, scrutinize it against your project roadmap – don’t agree to large increases unless you have high confidence in the need. Negotiate flexibility into the contract: for example, tiered pricing (lock in unit prices for additional FUEs if needed later), and seek provisions to adjust timelines if deployments are delayed. While reducing FUE counts mid-term is difficult, you can negotiate elements like carrying over unused FUE capacity or swapping with other cloud services of equivalent value if your plans change. Also, negotiate how incremental FUE additions will be priced (to avoid paying full list price for a small overage later). Goal: Secure a contract that meets your needs without excessive commitment, and preserve your ability to adapt as your business evolves.

4. Strengthen Ongoing License Governance Processes:
Embed FUE license management into your regular IT governance. For example, license impact checks can be incorporated into user provisioning and role change workflows. When a new user is created or a role is modified, assess if it changes the FUE count (e.g., moving someone from Self-Service to Core use). Maintain a record of current FUE consumption by department or role category to have internal transparency. Establish a cadence (monthly or quarterly) to review user lists: remove users who have left, and downgrade or retire accounts that are not actively in use. Essentially, treat FUE like a consumable resource that needs monitoring – assign an owner (license manager or SAM manager) to watch this metric just as you would cloud compute costs. Goal: Prevent creeping non-compliance and cost leakage by catching issues early and keeping the user base tidy.

5. Utilize Tools and Expertise for License Management:
Consider investing in SAP license management or Software Asset Management (SAM) tools that are FUE-aware. Many third-party tools can analyze SAP authorization data and simulate FUE consumption continuously, giving you an early warning if you’re nearing your limits or if a certain change will spike usage. These tools can also suggest optimization (for example, identifying a user who could be downgraded from Advanced to Core based on actual usage patterns). In addition, don’t hesitate to engage external expertise – specialized SAP licensing consultants or partners (including SAP’s advisory services) can provide insights, especially if you have a complex environment. They can assist with interpreting the nuances of FUE (such as which transaction codes trigger an Advanced classification). Goal: Augment your team’s capabilities with analytics so that managing FUE becomes more automated and less guesswork.

6. Plan for and Educate on the Audit Process:
Prepare your team for how audits under RISE will work. Ensure that your basis/technical team knows how to run the latest SAP measurement reports for FUE. Conduct internal “mock audits” annually – run the tools, see the results, and reconcile them with your contract entitlement. If you find any discrepancies, address them proactively. Train your software asset managers and IT finance folks on the FUE concept so they understand that a single user’s permissions can impact licensing. This knowledge will also help them communicate with business users. For instance, if a manager requests elevated access for an employee, IT can explain the cost/licensing implications in business terms. Goal: Be audit-ready at all times, with no scrambling. When SAP or an external auditor comes knocking, you should know your status and have evidence of compliance (or a plan to remediate if usage grows).

7. Maintain Cost Transparency and Communicate Value:
Internally, translate the benefits of the FUE model to stakeholders. Work with finance to possibly create an internal chargeback model for the SAP subscription that is perceived as fair. For example, you might allocate costs by counting Advanced users as 1 unit, Core as 0.2, etc., so each department pays for what they use. By mirroring SAP’s model, you encourage departments to optimize their usage (nobody wants to pay for an Advanced user license for someone who doesn’t need it). Additionally, track KPIs such as “Cost per active user” or “FUE per 100 employees” over time – this can show that IT is getting more efficient if those numbers drop, or help justify investments if they rise because of new projects. Goal: Ensure that the single metric doesn’t obscure who is using what; keep the organization informed so there are no surprises about IT costs, and showcase improvements when you successfully manage licenses.

8. Keep Abreast of SAP’s Licensing Updates and RISE Scope:
SAP’s cloud offerings and licensing policies continue to evolve. Stay updated on any changes SAP makes to the FUE definitions or RISE packages. For instance, SAP might introduce new use types or adjust what’s included in each category (though ratios like 1:5:30 have held steady so far). Also, watch for any shift toward true usage-based pricing (SAP has hinted at more cloud metering in the future). Being informed will allow you to adjust your strategy. Attend SAP user group sessions or licensing webinars, and network with peers to learn how they optimize under the FUE model. Goal: Avoid being caught off-guard by changes and continuously refine your license management strategy in line with the latest best practices and SAP offerings.

By following these recommendations, CIOs and sourcing professionals can turn what might seem like a licensing constraint into an advantage.

The Full User Equivalent model, with its flexibility and simplicity, can indeed benefit enterprises that manage it actively. It can reduce administrative overhead and potentially lower costs through better alignment of licenses to actual use.

The key is to treat license management as an ongoing discipline in the cloud era, just as one manages other cloud resources. Those who do so will find RISE with SAP’s licensing far more predictable and conducive to supporting business growth.