SAP S/4HANA User Licensing Metrics – Named Users vs. Full User Equivalents

SAP S/4HANA User Licensing Metrics

Introduction – Why User Licensing Matters

SAP user licensing is often one of the largest components of ERP costs. How you measure and license users can dramatically affect your SAP S/4HANA budget.

Traditional SAP licensing uses named user categories, but S/4HANA has introduced a new approach called Full User Equivalents (FUE) for cloud subscriptions. Understanding both models is essential to avoid overspending.

The goal is to optimize licensing by matching users with the appropriate license type or FUE category, particularly during an S/4HANA migration or contract negotiation. Read our ultimate guide to S/4 Hana Licensing.

Legacy Named User Model (ECC)

Under SAP ECC (SAP’s earlier ERP), every individual user needed a specific license type. There were several categories of named users – common examples include Professional Users, Limited Professional Users, Employee Self-Service (ESS) users, Developer users, and many more specialized types.

Each category came with different levels of access and a different price point. In theory, you would assign each person the license type that matched their role.

In practice, the ECC model had some pitfalls. Companies often defaulted many users to the highest-level Professional User license out of caution or convenience.

This led to over-provisioning, where organizations paid for expensive licenses that many users didn’t fully utilize. The excess licenses (often called “shelfware”) sat unused while the company still paid maintenance on them.

Misclassifying a casual user as a Professional user meant paying a premium for functionality that wasn’t needed.

This legacy approach required careful tracking of who had which license to ensure compliance and cost efficiency—a task that was easy to get wrong.

S/4HANA Named User Types (On-Prem)

For on-premises S/4HANA (and private cloud deployments under RISE), SAP continues to use a named user model, but it has been simplified.

The user categories are consolidated into four main types: Professional, Functional (Limited), Productivity (Self-Service), and Developer.

A Professional Use license in S/4HANA covers broad, unrestricted access across modules (similar to the old Professional user).

A Functional Use (sometimes called Limited Professional) license restricts the user to specific modules or business areas (e.g,. an HR specialist or a procurement clerk).

A Productivity user is essentially an Employee Self-Service or light-use license for employees who only perform basic tasks (time entry, approvals, expense submissions, etc.).

Developer licenses are for technical users who work on system development and configuration but might not execute day-to-day business transactions.

These on-prem S/4HANA user types are hierarchical – a Professional user can do everything a Functional user can, and so on – so it’s important to allocate the minimum necessary license to each person.

Without oversight, many organizations still tend to skew toward assigning more Professional licenses than needed, just as in ECC. Role audits are crucial. Before a renewal or migration to S/4HANA, it’s wise to review all user roles and authorizations.

By mapping employees to the appropriate license type based on actual usage, companies can often identify users who could be downgraded to a lower-cost category.

This proactive audit prevents carrying over old shelfware and ensures the license mix is right-sized for the S/4HANA environment.

For strategies, read SAP S/4HANA Licensing Overview: Models, Metrics, and Migration Strategie.s

Full User Equivalents (Cloud FUE Model)

With the advent of S/4HANA Cloud (including the RISE with SAP offering), SAP introduced the Full User Equivalent (FUE) model.

This represents a fundamentally different approach to measuring user licensing. Instead of buying a fixed number of each license type, a company subscribes to a pool of FUEs – essentially a budget of user capacity.

Every user in S/4HANA Cloud falls into a usage category that consumes a certain fraction of an FUE.

SAP defines weightings for each user category in the cloud subscription model:

• Advanced User – counts as 1.0 FUE (the baseline, equivalent to a full “power user”). This is comparable to a Professional user with broad access across the system.
• Core User – counts as 0.2 FUE. These are more limited users (roughly like the Functional users); five Core users equal the consumption of one full user.
• Self-Service User – counts as 0.033 FUE. These are very light users (such as employees who only use ESS functionality); approximately 30 of these make up one full user.
• Developer User – counts as 2.0 FUE. Developers or technical users have a higher weight, reflecting their specialized deep access (one developer consumes the equivalent of two Advanced users in the FUE tally).

Typical FUE Weightings:

Under this FUE system, you might contract for, say, 100 FUEs in total. That entitlement can be split among any number of users and categories as long as the weighted sum doesn’t exceed 100.

For example, 100 FUEs could cover 100 Advanced users (100 × 1.0), or 500 Core users (500 × 0.2 = 100), or even 3,000 Self-Service users (3,000 × 0.033 ≈ 99).

More likely, it would cover a mix of user types – e.g., a company could support 50 Advanced users, 250 Core users, and 1,500 Self-Service users with roughly 100 FUEs in total.

The FUE model simplifies contracts (one metric instead of multiple SKUs) and adds flexibility. All your users are essentially part of one license pool, which reduces the likelihood of unused licenses in one category and shortages in another. However, it puts the onus on the customer to manage roles carefully.

Every user’s authorizations determine their FUE category, so if you accidentally grant too much access to a user, that person might count as an Advanced user (1.0 FUE) instead of a Core user (0.2 FUE).

In short, FUE makes licensing more dynamic; however, companies must pay close attention to how users are classified to ensure the total FUE consumption remains optimized.

For insights, read Navigating ECC to S/4HANA Transition: License Migration Strategies & Negotiation Playbook.

Optimizing FUE Usage

Getting the most value out of an FUE-based license means continuously tuning your user roles and authorizations:

• Assign the lowest appropriate role to each user. Always start with the least permissive access that allows them to do their job. If a user only needs to submit leave requests and view pay stubs, classify them as a Self-Service user (0.033 FUE) rather than a Core user. If someone just needs to run simple reports in one area, they might not require Advanced access.
• Beware of authorization creep. It only takes one extra authorization or role assignment to bump a user into a higher FUE bracket. For instance, an analyst might be fine as a Core user (0.2 FUE) until they are given a transaction that touches a broader scope – suddenly, they might qualify as Advanced (1.0 FUE). Regularly audit user permissions to ensure nobody has more access than necessary. This avoids accidental over-licensing where a handful of over-privileged accounts eat up your FUE capacity.
• Leverage self-service roles for light tasks. A big advantage of FUE is the extremely low weight of Self-Service users. Approximately 30 self-service employees collectively count as just 1 FUE. That means if you have a large population of occasional users (for example, employees who only log in to enter time or expenses), they add very little to your license count. Make sure those users are kept in true self-service roles and don’t needlessly receive higher-level access. Utilizing these low-cost user categories can significantly reduce your overall FUE consumption.
• Continuous monitoring. Treat FUE usage like a utility meter – keep an eye on it. SAP provides tools and reports to help track how many FUEs you’re consuming based on current user assignments. By monitoring this regularly (say, monthly), you can detect trends or spikes. If one department suddenly adds several Advanced users’ worth of roles, you can take action (perhaps they granted too broad access). Proactive management ensures you stay within the purchased FUE limits and can defer purchasing more until necessary.

Named vs FUE – Impact on Costs

Switching from the traditional named user model to FUE has a significant impact on cost structure and risk:

• Named User model: This approach is rigid. You purchase a specific number of each license type (e.g., 300 Professional users, 200 Limited users, etc.). The cost is upfront (for perpetual on-premises licenses) plus annual support. The risk is that you might buy more of a category than you end up needing (wasting money and paying maintenance on shelfware), or you might not buy enough of one type and then scramble if usage changes. Also, some named user licenses might go unused if people leave or roles change, but you’ve already paid for them. In ECC, companies often erred on the side of overbuying licenses for safety, which drove up costs.
• FUE model: This is more flexible since it’s essentially one aggregate license. You commit to a total capacity of usage. There’s less chance of one category being over-provisioned while another is under-provisioned, because all users draw from the same pool. Every active user will consume some portion of an FUE, so it’s more of a pay-for-what-you-use scenario (within your subscription allotment). However, all users count in an FUE model – there are no “free” users. Even system accounts or occasional users must be accounted for via one of the FUE categories. In the past, some very light-touch users might have been ignored or given a cheap license; now, even a light user consumes a bit of the pool (0.033 FUE at minimum). Similarly, technical or background users who might not have required a named user license still need to be accounted for in the FUE count (often as Core or Developer users). This means your total user count (human and technical) is fully visible in the licensing costs.

Impact on cost example:

Imagine under ECC, you had 500 named user licenses: 300 Professional and 200 Limited Professional. That fixed allocation might have been negotiated as a one-time cost plus a maintenance fee. Now consider moving to S/4HANA Cloud with FUE. Suppose you analyze those 500 users’ actual needs.

In that case, you might discover that not all 300 truly need full Professional (Advanced) access, and some of the Limited users could even be classified as Self-Service. Perhaps you identify 150 Advanced users, 320 Core users, and 30 Self-Service users in the new model.

The FUE calculation for that mix would be roughly: 150*(1.0) + 320*(0.2) + 30*(0.033) ≈ 150 + 64 + 1 = 215 FUE (plus any developer users if applicable).

In this scenario, about 215 FUEs cover the same workforce that previously required 500 named licenses – a dramatic reduction in counted units due to the efficiency of fractional users.

Of course, cost depends on how SAP prices those licenses vs. FUEs, but generally, a diverse user base yields savings under FUE.

Heavy users vs. light users: If your company is mostly heavy users (everyone needs Advanced access), then 500 users would equal 500 FUE – not much change in quantity (you’d basically be paying for 500 full users either way).

In fact, if you have a lot of developers or power users, you might pay a bit more under FUE because developers count as 2 FUE each (whereas in the old mode,l a developer license might have cost less than two professional licenses).

The flip side is if you have many light users, FUE can drastically lower costs since those users only consume a fraction of a license each.

In summary, the named user model can lead to overspend due to inflexibility and shelfware. In contrast, the FUE model offers potential savings and easier reallocation, particularly for organizations with a wide range of user activity levels.

However, FUE requires diligent management to ensure the theoretical savings are realized in practice.

Negotiation Considerations

Whether you are negotiating a traditional on-prem license deal or a new S/4HANA Cloud contract, there are strategies to achieve a better outcome.

Here are some considerations from a licensing negotiation perspective:

• On-Prem Named Users: If you’re buying or renewing S/4HANA on-prem licenses, leverage volume for discounts. SAP sells named users in bundles, so negotiate a better unit price for a large quantity. Also, be mindful of maintenance fees – try to cap maintenance on any software. For instance, if you have 100 unused licenses, see if SAP will allow reclassification of those to needed types or reduce support costs. Ensure your contract has flexibility to swap license types (e.g. ,converting a Professional to multiple lower-tier users) if your needs change, which can mitigate future costs.
• Cloud FUE Subscriptions: In a cloud subscription (RISE or public cloud S/4HANA), everything is based on FUEs. Negotiate tiered pricing: SAP often has pricing tiers (the more FUEs you commit to, the lower the price per FUE). Aim to get to a higher-tier discount if you’re near a threshold, as it can lower the average cost. Also consider asking for rollover or elasticity – for example, if you don’t use all your FUEs one year, can some carry over, or can you burst above your allotment temporarily without a huge penalty? SAP may not always allow unused capacity to be rolled over, but bringing it up could lead to concessions, such as a slight overage buffer or the right to true-down (reduce FUE count) at renewal if usage is lower than expected.
• License Conversions (ECC to Cloud): When migrating from ECC (with perpetual licenses) to S/4HANA Cloud (subscription), don’t let your previous investment go unrecognized. SAP offers programs to credit a portion of your on-premises license value when you migrate to the cloud. In negotiations, insist on credits or discounts reflecting the money you’ve already spent on licenses and maintenance. For example, if you’ve paid maintenance for years, you could negotiate a reduced subscription fee for the first term or an extra FUE capacity at no charge. The key is to tie the new deal to the old – ensure SAP provides a conversion offer so you’re not paying twice for the same users.
• Future-Proofing and Growth: Think about your company’s growth during the contract term. If you expect acquisitions or user count increases, negotiate those terms now. In an on-prem world, you might negotiate fixed pricing for additional named users for a few years. In an FUE contract, you might ask for a buffer of extra FUEs included (e.g., 10% more than your current need) or a locked-in price for adding more FUEs later. Some companies negotiate a clause that any additional FUEs purchased during the term will be at the same discounted rate as the initial batch, rather than a higher list price. This protects you from sudden cost spikes if user counts grow. It’s also wise to clarify how decreases are handled (for example, if you divest or reduce users, can you drop some FUEs at renewal? Often subscriptions are “use it or lose it”, but you might negotiate some flexibility in future contract cycles).

FAQs

• How do I calculate my FUE count? – SAP provides tools (like a user measurement report or conversion tool) to map your current users to FUE categories. Essentially, you assess how many Advanced, Core, Self-Service, and Developer users you have, then apply the weights. For example, 10 Advanced + 50 Core + 300 Self-Service would be 10*(1.0) + 50*(0.2) + 300*(0.033) FUEs. SAP or a licensing partner can help run this analysis so you know your FUE requirement.
• Can I still buy traditional named user licenses? – Yes, but only for on-premise deployments. S/4HANA on-prem (and private cloud) still uses named user licensing. If you move to S/4HANA Cloud or RISE with SAP, then the user licensing is based on FUEs instead. In other words, new cloud subscriptions don’t use the old named user SKUs; they use the FUE metric.
• What if my user count grows suddenly? – The best approach is to pre-negotiate terms for growth. If you expect potential spikes, negotiate some buffer FUEs or a capacity headroom. Alternatively, negotiate a clause for capped rates on additional users – for example, any extra FUEs you need can be purchased at the same discounted rate as your initial purchase. This way, a sudden expansion won’t blow your budget. Always communicate anticipated growth to SAP during negotiations; they may include a conditional quote for additional users, which you can invoke later if needed.
• Do technical users or system accounts count under FUE? – Yes. In the FUE model, essentially all users must be licensed. This includes background users, integration accounts, or any account that logs into or accesses the S/4HANA system. There is no free pass for technical users. Typically, those accounts would be categorized appropriately (some might be Core users if they perform limited functions, or Developer users if they exist only for development/support tasks). It’s important to account for these in your FUE calculation to stay compliant.
• Is the FUE model always cheaper than named users? – Not automatically; it depends on your usage mix. FUE can be very cost-effective if you have lots of occasional users, because you’re only paying a small fraction for each of those. For example, 100 light users might collectively equal just a handful of FUEs, whereas in the old model, you might need 100 separate licenses (which is far more expensive). However, if most of your users are heavy Advanced users (1 FUE each) or you have many double-counted Developer users (2 FUE each), the cost could end up similar to traditional licensing or even higher. The main advantage of FUE is flexibility and potential efficiency – it rewards right-sizing. Companies that diligently optimize roles will find FUE helps eliminate waste. Those who don’t might not see much savings.

Five Expert Recommendations

1. Audit user roles before migrating – Thoroughly analyze and document what each user actually does in the system. This helps you determine the correct license type (or FUE category) for each person, ensuring you’re not over-licensing when you move to S/4HANA.
2. Match users to the lowest-cost category – Always start a user in the lowest applicable license tier or FUE classification. Only upgrade a user’s license if their job can’t be done with the lower level. This principle prevents unnecessarily high allocations (e.g., avoiding default Professional or Advanced status for everyone).
3. Negotiate volume and rollover in contracts – If you’re committing to a large number of users or FUEs, leverage that for better pricing. Ask for tiered discounts and consider requesting the ability to carry over any unused FUE capacity or adjust down in the future. A well-negotiated contract can save money and provide flexibility over its term.
4. Leverage existing investments during migration – Don’t let your sunk cost in ECC licenses go unused. When switching to S/4HANA Cloud, push for conversion credits or migration discounts. SAP may not volunteer these, but if you bring it up, you can often reduce your net new cost by getting value for the licenses you’ve already paid for.
5. Implement continuous license governance – Treat SAP licensing as an ongoing program, not a one-time setup. After deployment, continue to monitor user access and FUE consumption. Regularly recertify that users still need the level of access they have. This helps catch “scope creep” where someone’s access grows over time, and it keeps your license position optimized before an official SAP audit or true-up catches you off guard.

By understanding both the named user and FUE models – and using smart optimization and negotiation strategies – you can significantly mitigate the risk of overspending on SAP S/4HANA licenses.

The key is to stay proactive: align licenses with actual usage and revisit the plan as your business evolves. With careful management, you’ll turn SAP’s complex licensing rules into an advantage rather than a liability.

Read about our SAP Advisory Services.

Do you want to know more about our SAP Services?

Please enable JavaScript in your browser to complete this form.

Name *

First

Last

Email *

Company

Message *

Submit