In this article you will learn:

·       why SAP is moving away from the FUE model and introducing PUPM,

·       what the new user types are and how they differ from each other,

·       how the rule “highest type wins” works and why it can significantly increase costs,

·       what risks are associated with assigning roles and business catalogs,

·       why mapping matrices are difficult in practice and how to read them,

·       what the transition period means and when migration will actually be possible,

·       which tools and practices help control licensing costs in the new model

The need for a new licensing model

For the past years, SAP Cloud ERP used the FUE (Full Use Equivalent) model. Customers had to convert their users into “equivalents” before they could calculate licensing costs.

The problem was not only the math itself, but above all the challenge of assigning each user to the right category. A company new to SAP, unfamiliar with the licensing model, often started from a simple assumption: “we have 100 people who need to work in the system.” Instead of granting access and watching actual usage, the company had to decide upfront what each of those people would be doing and which user type they should be assigned. This was difficult and likely to error.

In such a scenario, the company might estimate 50 self-service users, 20 operational users, 10 finance users, and 5 developer users. In FUE each type had its own multiplier: Self-Service counted as 0.1 FUE, Operational as 0.5 FUE, Finance as 1 FUE, and Developer as 1.5 FUE. To calculate the total, the company had to perform the following math: 50 × 0.1 + 20 × 0.5 + 10 × 1 + 5 × 1.5 = 45 FUE. Only this sum became the basis for calculating license costs.

Complications didn’t stop there. A purchasing clerk primarily creating purchase orders could be classified as operational, but if they also approved invoices, they might need to be reclassified as finance. Similarly, a sales manager looked operational at first glance, but if they had access to controlling reports, they pushed costs into a higher category.

As a result, companies without prior FUE experience often overestimated the number of expensive user types. Instead of simplifying licensing, the model forced organizations to run workshops, create detailed role maps, and engage consultants just to avoid overpaying.

 

FUE replaced by PUPM – a new approach

In the PUPM (Per User Per Month) model, SAP removed the indictors (multipliers) that were most painful in FUE. At first sight, this seems like a solution: customers buy clearly named licenses such as Self-Service, Operational, or Finance Base, and pay a monthly fee per user.

In practice, however, the challenge did not disappear; it only changed the form. Now it is not multipliers but Business Catalogs that determine what license type a user receives. Each catalog is tied to a license category, and a user inherits the highest type among the catalogs assigned to their role.

For example, if an employee has both Self-Service and Operational catalogs, they are classified as Operational. If they also receive a Finance Base catalog, their type increases to Finance Base—even if they use those functions rarely or not at all.

This brings back a familiar problem: “we have 100 people who need to work in the system,” but before assigning roles, the company must understand which catalogs trigger a higher user type and licensing cost. The math is simpler than in FUE, but role classification is still complex and not error-free. One additional catalog can increase costs for an entire group of employees, and granting broad roles without analysis leads to overspending.

Therefore, in PUPM as in FUE, running workshops and conducting regular access reviews remain critical. Companies that take the shortcut of “just assigning roles” may quickly discover they are paying for Premium users while their staff only uses Self-Service or Operational features.

New user types (SKUs)

In the PUPM model, SAP introduced clearly defined user categories. Instead of abstract FUE multipliers, customers now choose from specific packages. Each package corresponds to a functional scope, and the price depends on the level.

Finance Base / Finance Premium

Finance Base is the basic package for finance staff – accountants, AP/AR specialists, reporting roles – including GL, AP, AR, and basic controlling processes.
Finance Premium is the advanced package, covering additional apps and integrations such as Ariba, Concur, Project Management, Sustainability, as well as advanced controlling scenarios. It also includes everything in Finance Base (nested model).

SCM Base / SCM Premium

SCM Base is for planners and logistics operators – supply chain, production planning, warehouse management, operational purchasing.

SCM Premium is for more advanced roles such as production engineers, strategic planners, and quality managers. It includes everything in SCM Base plus extended modules for complex processes.

Combo Base (Finance + SCM)

Combo Base merges Finance Base and SCM Base. It is intended for organizations where some users work across both finance and logistics, without needing two separate licenses.

Operational
Operational User licenses cover staff handling day-to-day transactions, e.g., purchasing clerks, sales representatives, customer service staff. They create orders, sales quotations, and delivery confirmations, but do not have full access to finance or planning.

Self-Service
Self-Service User is the simplest and cheapest license, for employees who only need self-service functions such as leave requests, timesheet entry, or viewing personal HR data.

Developer
Developer User is for programmers working in SAP environments, including ABAP Workbench and SAP Build tools (Build Apps, Build Process Automation).

Example of user type assignment

Imagine a manufacturing company with 100 employees. Sixty are operators who only need to submit timesheets and leave requests – they fit into Self-Service. Twenty-five people work in sales and procurement – they require Operational. Ten employees in accounting need Finance Base. Three staff involved in advanced controlling and integration with Ariba and Concur require Finance Premium. Finally, two developers working in ABAP and SAP Build require Developer.

At first glance, everything seems straightforward: each person gets the license they need. But let’s assume 50 employees must use Concur to submit travel expenses. In theory, Concur is part of Finance Premium, which raises the question: does this mean all 50 need Premium licenses, even though they only use it for travel expense reporting?

This highlights the real-world complications. Questions arise such as: do all Concur users automatically need Premium? Does SAP provide exceptions? Can companies mix Self-Service and Premium licenses for similar users? How should roles be mapped to avoid paying Premium for employees who only use the app occasionally?

 

Example

If the 50 employees are classified as Self-Service, the cost (hypothetical simplified pricing) would be: 50 × €5 per month = €250/month.

But if they are classified as Finance Premium, the cost jumps to: 50 × €60 per month = €3,000/month.

The difference is €2,750 per month – over €33,000 per year – just because access to one application (Concur) raised the license category.

Minimum user counts

SAP also enforces minimums: for example, 25 Finance Base or Premium users as an entry point, and at least 1 Finance Base when buying any other Base SKU. Finance Premium removes Base minimums.

Example: A company wants to start with only the purchasing module. It must still purchase at least 1 Finance Base and 25 Base/Premium users, even if fewer employees actually use it – generating additional costs.

Built-in commercial entitlements

A major change is that some solutions that previously required separate licenses are now included in PUPM.

• In Base: Multi-Bank Connectivity, Market Rates, Digital Access, Build Base.
• In Premium: Ariba, Concur, Sales Cloud, Project Management, Sustainability.

This is a simplification, but also a risk: companies must be careful not to overpay for features they don’t actually use.

 

 

How SAP assigns user types

The system works based on Business Catalogs.
Each catalog has a user type. A role is a set of catalogs. A user inherits the highest type among all their catalogs. Measurement is automatic in SAP IAM.

Example:

·       Warehouse Operator → Self-Service

·       Production Operator → SCM Base Accounts

·       Payable Accountant → Finance Base

·       Compliance Officer → SCM Premium

The effect: even if many users work mainly with simple functions, a few Premium roles can push up total licensing costs

Why it is still complicated

On slides, the model looks clean – a few user types, a clear “highest type wins” rule, and automated measurement in IAM. In reality, clients receive large mapping matrices resembling Excel sheets with dozens or hundreds of rows and columns. Each column is a business role, each row a task or object, and intersections are marked with “x” indicating a required catalog.

From a licensing perspective, the “highest type wins” rule is problematic. It is common for 90% of a user’s permissions to fit into a lower type, such as Operational or Finance Base, but a single catalog forces them into Premium. Users often don’t realize that this one catalog multiplies their license cost; had they known, they might have opted out.

Therefore, it is in the customer’s best interest to define access consciously, making sure there is a clear business need for higher license types, and more importantly, to monitor actual usage. Often during go-live, business users fight for broader access “just in case,” sometimes driven by ego or organizational status. As a result, someone ends up with Premium access they never use, while the company pays for months.

The optimal approach is to assign both a tool and a responsible person to monitor usage continuously. The goal is not to underpay for SAP, but to ensure the company pays for what is genuinely used – not for access won in negotiations and later forgotten.

Example: An Accounts Payable Accountant working mostly in Finance Base gets an additional Concur catalog for rare cases of expense reporting. The system immediately classifies them as Finance Premium, raising costs significantly. That single “x” in the matrix can increase license costs not only for one person, but for a whole group if the role is broadly assigned.

Important limitations

It is worth noting that properly defining the PUPM model is not only about user licenses, but also about the overall system offering. Depending on whether the Base or Premium version is selected, the customer may receive additional products and functionalities. However, the key limitation is that PUPM does not provide flexibility in both directions.

Adding licenses during the contract is possible – the customer can increase the number of users at any time. However, reducing the number of licenses is not possible on an ongoing basis. Such an adjustment can only be made at the time of contract renewal, depending on its duration (most often 3–5 years). During the contract period, SAP does not authorize license volume reductions.

This means that a company that overestimates its needs and purchases too many Premium licenses “just in case” will have to bear that cost until the end of the contract. That is why customer awareness, as well as the knowledge of partners selling SAP Cloud ERP, is absolutely crucial – it directly determines whether the organization will use its resources efficiently, or waste significant budgets on unused access for years. An effective way to mitigate this risk is to monitor actual system usage and assigned licenses.

 

Instead of immediately purchasing new licenses, it is worth considering whether the current level of usage is intensive enough to justify adding them. Very often, analysis shows that some users are not fully utilizing their access. In such cases, rather than increasing the number of licenses, it is possible to reassign them within the existing pool – withdrawing unused entitlements and allocating them to new employees.

Conclusion

In the new PUPM model, the key risk is that fees are calculated based on assigned authorizations, not actual usage. This means companies may pay for access never utilized. Without regular role optimization and usage analysis, costs can easily exceed what is necessary. Tools such as SAP GRC, SAP IAG, or SmartGRC remain essential to check who has which permissions, who actually uses them, and where savings are possible.

For now, FUE and PUPM will coexist until the first half of 2026, and migration is not mandatory. In fact, technical transitions will only be available after that date.

To summarize: PUPM is a revolution in communication, making pricing clearer and easier to understand. But in practice, it is still an evolution, requiring clients to carefully analyze role mappings and maintain continuous optimization. The best strategy is to treat the transition period until 2026 as a time for testing, workshops, and preparation, so that after migration companies pay for what they truly use – and nothing more.