Transition from SAP FUE to PUPM — Revolution or Evolution?

SAP is replacing the FUE (Full Use Equivalent) model with PUPM (Per User Per Month). The multipliers are gone. The license names are clearer. On paper, it looks like a simplification. In practice, the core problem — paying for access, not usage — remains. And a new rule, "highest type wins," creates a pricing trap that's even easier to fall into than FUE.

Why FUE Was Painful

In the FUE model, customers had to convert users into "equivalents" before calculating licensing costs. A company with 100 employees might estimate: 50 Self-Service users (×0.1 FUE), 20 Operational (×0.5 FUE), 10 Finance (×1 FUE), and 5 Developers (×1.5 FUE) — totaling 45 FUEs.

The problem was not just the math. A purchasing clerk creating purchase orders was Operational. But if they also approved invoices, they needed Finance. A sales manager was Operational, but controlling access pushed them into a higher category. Companies without FUE experience consistently overestimated expensive user types. Instead of simplifying licensing, FUE forced organizations to run workshops, create role maps, and engage consultants just to avoid overpaying.

What PUPM Changes

In the PUPM model, SAP removed the multipliers. Customers now buy clearly named licenses: Self-Service, Operational, Finance Base, Finance Premium, SCM Base, SCM Premium, Combo Base, Developer. Each is a fixed monthly price per user. The math is simpler.

What determines a user's license type? Their Business Catalogs. Each catalog is tied to a license category, and a user inherits the highest type among all catalogs assigned to their role.

New PUPM License Types (SKUs)

The "Highest Type Wins" Rule — And Why It's Dangerous

A user inherits the highest license type among all catalogs assigned to their role. One Concur catalog added to a Self-Service role promotes the user to Finance Premium — even if they use Concur only for quarterly expense reports.

This is not a theoretical risk. It's how the model is designed to work. And it creates a pricing trap that's easy to miss: 90% of a user's permissions fit a lower tier, but a single catalog forces them into Premium. The user often doesn't realize that one checkbox in a role multiplied their license cost. Had they known, they might have opted out.

Minimum User Counts Add More Complexity

SAP also enforces commercial minimums. Finance Base or Premium requires at least 25 users as an entry point. Buying any other Base SKU (e.g., SCM Base) requires at least 1 Finance Base alongside it. Finance Premium removes the Base minimum, but Premium pricing still applies to every Premium user.

Example: a company that wants to start with only the purchasing module must still purchase at least 1 Finance Base + 25 Base/Premium users — even if fewer staff actually need them. Plan against minimums, not headcount.

Built-In Entitlements: Free Doesn't Mean Cost-Neutral

PUPM bundles previously separate licenses into the Base/Premium tiers. Base includes Multi-Bank Connectivity, Market Rates, Digital Access, Build Base. Premium includes Ariba, Concur, Sales Cloud, Project Management, Sustainability.

This looks like a benefit — and it is, for organizations that actually use these products. But it creates a trap: bundled features look "free," so organizations hand them out via roles without thinking about cost. Every Premium-only feature you assign elevates user types under highest-type-wins. Bundled does not mean cost-neutral.

The Inflexibility Problem: No Mid-Contract Reductions

This is why the transition period before 2026 is the critical window. FUE and PUPM coexist until the first half of 2026. Technical migrations open only after that date. Use this time to map actual usage per user and per Business Catalog — before signing a contract that locks in the wrong numbers for years.

Why the Problem Hasn't Gone Away

In FUE, fees were calculated based on assigned authorizations, not actual usage. In PUPM, fees are calculated based on assigned Business Catalogs, not actual usage. The form changed. The substance didn't.

Companies that take the shortcut of "just assigning roles" will quickly discover they are paying for Premium users while their staff only uses Self-Service or Operational features. Regular access reviews and usage monitoring are still critical — the tools just need to match the new model.

What to Do Before 2026

• Map catalog-level usage now — understand which Business Catalogs are actually used vs. merely assigned.
• Audit roles for unnecessary Premium catalogs — a single catalog removal can reduce costs for an entire team.
• Run workshops before go-live — conscious access design is cheaper than post-contract cleanup.
• Establish continuous monitoring — one-time cleanup is not enough. Usage changes. Role assignments drift.
• Walk into PUPM renewal with data — not with a guess about how many Premium users you "probably" need.

PUPM is a revolution in communication — pricing is clearer and easier to understand. But in practice, it remains an evolution: careful role mapping and continuous optimization are still essential. The best strategy is to treat the transition period until 2026 as a time for testing, workshops, and preparation, so that after migration organizations pay for what they truly use — and nothing more.