SAP FUE by Design: how to actively manage license classification in an SAP S/4HANA project

An SAP S/4HANA implementation generates dozens, often hundreds of design decisions: new Fiori applications, process extensions, role changes, new authorization objects, additional activities or access to further organizational units. Each of these changes can potentially affect user classification in the FUE model.

The natural reflex is therefore to try to evaluate every Change Request from a licensing perspective. Such an approach is possible, but at larger project scale it quickly becomes expensive, inconsistent and hard to maintain. On the other hand, measuring FUE only after go-live means we are not managing risk - we are only measuring its outcome.

The right goal is therefore not "count FUE as early as possible", but manage FUE iteratively, as the solution matures.

1. The problem: FUE appears in the project much earlier than at audit time

In a typical project the question of FUE impact appears with successive CRs. For example, the team wants to deploy a new mass order creation application, or to extend the Purchaser role with functions related to RFQs, vendor offers or contracts. On the business level the change may look innocent, but technically it can mean a new Fiori catalog, new authorization objects and additional activities.

The problem is that at the concept stage the final roles and complete authorizations often do not yet exist. It is therefore impossible to perform a full technical classification of users. This does not mean, however, that the FUE topic should be postponed to the end of the project.

1a. Why this challenge is structural, not personal

It is worth pausing for a moment to understand why this challenge is so hard to solve in the classic working model. It is not a question of goodwill - it is a structural information problem, in which both sides operate with limited knowledge.

The client perspective

SAP's licensing policy for RISE with SAP and S/4HANA environments is complex and evolving. The FUE model replaced classic Named User Licenses - instead of counting users by nominal license types, it measures the effective scope of authorizations. The same user can be classified as Core Use or Advanced Use depending on a single activity in one authorization object.

During the project the client is only just learning the functionality - what a specific Fiori application does, how a new process works, what variations extensions have and what authorizations will be required. At the same time they are aware that every decision about an extension has licensing consequences. The responsible behaviour is to ask about the impact before deciding. But to ask sensibly, you need a tool - and the client does not yet have one.

The consultant perspective

The functional consultant's goal is system configuration and delivery of a business solution. Knowledge of the FUE metric, the 7 license classes, the combinatorics of Auth Object + Field + Value is a specific technical-licensing competency that only a relatively narrow group of specialists holds. Not every functional consultant carries it in their natural competency pack - and rightly so, because their primary job is to deliver a working business process, not a license calculator.

Without a tool that immediately shows the impact of a change on user classification, the consultant would have to: learn the FUE ruleset (v1.69, 3,100+ rules), run a user population analysis, perform a combinatorial calculation - all for every single CR. This is additional specialization and additional work that does not fit in the classic implementation scope.

The information paradox

The client knows they should know the FUE impact before deciding - but they don't yet have a tool that would show it. The consultant knows how to implement the functionality, but has no natural knowledge of how it will translate into license classification. Result: both sides do their best, but the bill only appears at the end of the project.

In the SAP FUE context, that means a tool that:

• Has current data on roles and authorizations across all the client's SAP instances,
• Has the current FUE ruleset loaded (currently v1.69) and a mechanism to update to future versions,
• Knows what is in the roles today and what users actually use,
• Can simulate how it will change when we add new functionality - with a concrete effect on the user population,
• Presents the result in a format that client and consultant can jointly discuss before the Project Committee decision.

Only with such a tool can the client decide responsibly, and the consultant can provide complete information without the need for manual per-CR analysis. The market challenge described at the beginning becomes doable - not through team heroism, but by giving the team the right tool.

2. Three maturity levels of FUE analysis

FUE by Design - concept stage

At the start we analyze not roles, but planned business functions. The goal is not yet a final user classification, but identifying scenarios that may be drivers of a higher FUE.

• Scenario A: the user only creates a purchase requisition.
• Scenario B: the user runs RFQs and compares offers.
• Scenario C: the user additionally selects an offer and creates a contract or purchase order.

At this stage what makes sense are scenario analyses and "what if" questions: what will happen to the classification if we extend the process scope with an additional business function?

FUE by Authorization - build stage

Once roles, catalogs, applications and authorization objects start being configured, the analysis can be made more granular. Instead of assessing a general process description, we can point to specific elements that affect classification.

For example, the object M_BEST_EKO defines the scope of purchasing organizations, but the number of values assigned to a user does not by itself change FUE. What matters is the combination of object, activity, business function and the entire effective authorization scope.

At this stage the what-if analysis can answer a much more practical question: "what will happen to user classification if we add this application, catalog, object or activity to the role?"

FUE by Usage - post go-live

After go-live another data layer appears: actual system usage. We can then compare what the user has assigned with what they actually use. This creates the opportunity to optimize roles and identify individual authorizations that unnecessarily raise the classification.

FUE measurement after go-live is therefore necessary, but by itself is not management. Management starts when the effects of decisions can be assessed before they are deployed.

3. Why manual per-CR analysis does not scale

In theory the GRC team can review each CR separately: analyze the function, roles, objects, activities and potential FUE impact. In practice this model works only with a small number of changes.

• CRs appear faster than they can be manually analyzed.
• Roles change after the initial opinion and the conclusion quickly becomes outdated.
• At the concept stage technical data is often missing.
• The same function can be implemented by different applications and roles.
• Manual assessment depends on the knowledge of a few people and is hard to reproduce consistently.
• Excel, meetings and point-in-time analyses create a control process, but not a continuous management mechanism.

3a. What FUE impact analysis actually looks like - SAP guidelines

To grasp the scale of the problem, it helps to see what the official mapping of authorizations to license classification looks like. SAP provides a FUE ruleset for RISE with SAP Private Cloud Edition (current version: 1.69), which maps combinations of authorization objects to 7 main license classes.

Each rule is a combination: Auth Object + Auth Field + Auth Value. Example - a rule that classifies a user as Advanced Use (GB):

Rule Description: GB Advanced Use
Auth Object:      F_ACES_PER
Auth Field:       ACTVT
Auth Value:       02, 30, 39, F1, UL

If a user has authorization object F_ACES_PER with activity 30 in their roles, they are classified as Advanced Use.

A classic hidden trap - transaction BP (Business Partner):

• ACTVT=03 (Display) → user classified as Self-Service Use (lowest cost)
• ACTVT=01/02 (Create/Change) → automatically Core or Advanced Use (tens of times more expensive)

An apparent "small difference" between Display and Change in a single transaction can move hundreds of users from Self-Service (0.033 FUE) to Advanced Use (5-10× more FUE). At an average rate of ~€2,000 per FUE per year, such a change in an innocent-looking CR is concretely tens, even hundreds of thousands of euros in extra license cost.

SAP provides the SLIM_USER_CLF_HELP report (Note 3113382) which performs initial FUE classification - but SAP itself notes in the documentation that the result requires expert validation (the STAR Review service) and does not account for custom authorization objects or actual system usage.

Why this is hard in practice

• Rule volume - 3,100+ entries to analyze. A functional consultant does not know this ruleset by heart and does not even know all the authorization objects.
• Combinatorics - the user gets the MAX of their authorizations, not the SUM. If user X already has Advanced Use from FI, adding Core Use from MM changes nothing. But if user Y is in Self-Service Use, the same Core Use "upgrades" them. Without a population analysis you cannot predict this per CR.
• The ruleset evolves - v1.69 is another SAP update. A consultant analyzing a CR on v1.65 may misclassify under v1.69.
• Custom Z-authorizations - SAP does not cover them in the official ruleset. The client must map them themselves and maintain that mapping.
• Industry-specific rulesets - Retail (73 rules), IS-H Healthcare (74), Real Estate (83), GTS (31), HR (35), Utilities (48) - each industry has additional rules that can overlap.
• Dynamic changes - CRs update roles several times a week, new users join, new functions appear. A snapshot analysis from last month is already outdated.
• Environment scale - a typical enterprise implementation is several SAP instances (ECC + S/4HANA + BW + dev/test/prod landscape) and many thousands of users. Every added CR must be analyzed in the context of the entire population across all systems simultaneously. Doing this manually in Excel at that scale is hundreds of analyst hours per Project Committee.

Coming back to the challenge described at the start - both perspectives make sense. Classic per-CR manual analysis really does not scale at this complexity, but leaving it to the end of Explore is also too late for management. The answer is not choosing between "manually per CR" and "in bulk at the end", but building an automatic analytical layer fed by current SAP data and the official ruleset.

4. Where smartGRC can add value

In such a model smartGRC should not be treated purely as a FUE calculator. The greatest value appears when the tool becomes an analytical layer between role design and the license model.

As a result the question is no longer "is this role Core or Advanced?", but: "which specific permission or function causes the classification change and how many users does it affect?"

4a. Four FUE-aware processes in the access lifecycle

Active FUE management is not only what-if analysis per CR at the concept stage. It means embedding license awareness in four key operational processes that already exist in an organization with SAP GRC:

1. Role design with an FUE constraint (design time)

Classic role design mainly looks at two axes: functionality (does the role let you do the required tasks) and SoD (does it create a segregation of duties conflict). A third axis that should be equally visible: FUE classification.

A concrete scenario: a "Display Only" role for the finance team should grant Self-Service Use. But for apparent convenience the object M_RECH_BUK with the Create activity was added - and suddenly the role classifies all its users as Advanced Use. Without FUE awareness at design time such situations are normal - and expensive. The role designer should see the license classification at build time, not months later during an audit.

2. Tagging "expensive" roles in BRM / smartArchitect

Roles that carry a high FUE classification (Advanced, Developer) should be labelled in the role management tool - in SAP GRC Access Control BRM, in smartArchitect, or in any other system that handles role metadata. A label like "License: Advanced (+3.5 FUE / user)" visible on each such role changes downstream dynamics.

A line manager requesting access for a new employee immediately sees that role A is more than ten times more expensive than role B - and asks functionally: "Do they really need everything from A, or is the leaner B enough?". That is a conversation that did not happen before, because nobody saw the price.

3. FUE-aware provisioning (workflow)

Next step: embedding FUE cost visibility directly into the access request workflow. When a manager approves subordinate access, they see not only whether it carries SoD risk, but also:

• what FUE classification will be assigned to the user,
• whether it changes from the current one (e.g. Core → Advanced),
• how much it costs per year within the department budget.

The effect: the manager stops being merely an "SoD approver" and becomes a "cost-and-risk approver". Accountability for license cost is distributed to those who make access decisions - not only to finance, who see the SAP bill at year-end.

4. Periodic access reviews from a FUE perspective

Traditional User Access Review (UAR) checks "should this user still have this access from a functional perspective". It is worth extending this with a cost question: "does this user use the access intensively enough to justify Advanced / Developer classification?".

Practical result from real projects: reviews based on actual usage (usage data from the last 6-12 months) can identify 15-30% of users who are assigned a higher FUE class than their actual work in the system would justify. Downgrading these users to a lower license class delivers immediate savings without losing business functionality.

5. The critical condition: up-to-date data

The what-if function alone does not solve the problem if the analysis data is updated manually. Exporting from SAP, preparing the file, importing into the tool and repeating the whole process for every major CR does not scale in an intensive project.

Active FUE management therefore requires not only an analytical model, but also a smooth and preferably automatic feed of current data from the project and the SAP environment.

Only then can a practical cycle be built:

project change → role update → what-if analysis → impact assessment on users → decision → re-verification after deployment.

6. Target model: FUE as a design constraint

The most mature approach treats FUE like SoD or security architecture: not as a control performed after project completion, but as one of the constraints taken into account during design.

This does not mean that at the first stage we must know the final license for every user. Analysis accuracy grows with project maturity:

• concept → scenario assessment and potential FUE drivers,
• build → analysis of final roles and authorizations,
• test/go-live → simulation of impact on the user population,
• run → comparison of permissions with actual usage and optimization.

6a. FUE remediation vs FUE by Design - two very different approaches

Across the industry, most conversations about SAP FUE licensing today happen after the fact - the term commonly used is FUE remediation. Someone runs the SAP-provided classification program, sees that too many users are landing in the Advanced Use class, and then triggers a cleanup exercise: strip broad roles, remove inherited authorizations, revoke unused Fiori catalogs. This is useful work. It is also permanently reactive - you are fixing licence exposure that a design decision already created, often months or years earlier, and the redesigned roles need to be tested against the user population one more time.

FUE by Design flips the order. Instead of measuring after the roles are built and users assigned, you make FUE class a first-class design constraint at the moment the role is drafted, requested, or modified. Every change request is scored against its licence delta before it is approved. Every access review campaign includes a licence lens, not only an audit/SoD lens. Every access request through your IAG platform (Omada, SailPoint, Saviynt) gets a what-if FUE simulation returned via REST API before provisioning.

Both approaches have their place. If you have never run classification and your PCE landscape is already several years old, you almost certainly need a remediation pass first - a one-time recalibration. But if you stop there, the same drift will repeat. Roles will grow again as new projects, joiners and temporary access accumulate, and in 18-24 months you will run the same exercise again. FUE by Design is the operating model that keeps the remediation savings from evaporating.

Three role categories that make FUE by Design tractable

One practical pattern that helps operationalize FUE by Design at the role-catalog level is a strict three-category split, based on licence impact rather than functional area:

The mistake most organizations make is bundling category 2 and category 3 into a single "Finance Power User" role, then assigning it broadly because it is convenient. Everyone assigned to that role inherits the Advanced Use classification - even the users who only ever run displays. A single role change to split the bundle can move dozens or hundreds of users down one licence class in a single deployment.

The FUE by Design version of this pattern: your role catalog is designed to keep the three categories separate, your access request workflow validates the split on every change, and your quarterly access review campaigns test whether users assigned to category 3 roles have actually used the advanced functionality in the last 90 days.

Case: master data centralization as an FUE lever

A less obvious FUE by Design pattern is at the process level, not the role level. Consider decentralized master data maintenance - a common pattern where finance teams create GL accounts, sales teams maintain customer master, procurement maintains vendor master, and operations maintains material master. Each of these responsibilities requires create/modify authorizations that push users into Advanced Use classification, and the total user population with expensive licensing can easily reach several hundred people in a large SAP estate.

The FUE by Design intervention here is not to strip authorizations from existing users - it is to redesign the process. A dedicated master data function of 10-20 people, with a lightweight intake workflow for the business, can absorb the create/modify responsibility and let the wider user population drop back to Functional Use or Self-Service Use. The licence savings are typically 5-10x larger than any role-level cleanup, and the side benefits include better data quality, clearer accountability, and easier audit evidence.

This is where FUE by Design stops being a licensing exercise and becomes a governance exercise. The tools stay the same - IAG for lifecycle, SoD engine for risk, licence analysis service for FUE class simulation - but the target changes from "less exposure per user" to "fewer users needing high-cost access at all".

7. Conclusion

The point is not to count FUE precisely as early as possible. The point is to understand the consequences of design decisions more accurately as the project matures.

Manual per-CR analysis can be a good control mechanism, but does not scale as a management model. Measurement done only at the end shows the outcome, but no longer allows effective influence on the project.

A tool like smartGRC can fill this gap when used not only for final FUE measurement, but for scenario and what-if analysis during the project and later comparison of permissions with actual usage. The condition, however, is regular access to current data - without it even good analytics quickly turns into another manual process.

The most important question is not: "what license does this role have?", but "which design decision changes user classification, and is it really needed?"