What is it — and why PUPM drives cost control in SAP Public Cloud programs

If you’re planning SAP Public Cloud (for example SAP S/4HANA Cloud, Public Edition), you’ll quickly run into a term that sounds like billing — but actually shapes your entire operating model: PUPM.

PUPM stands for Per User Per Month. Sounds simple: you pay per user, per month. In real projects, PUPM is more than a price metric. It’s a steering model that directly impacts how you define personas, assign roles, control authorizations, and forecast cost.

That’s why many Public Cloud programs don’t fail on technology first — they struggle on PUPM governance: if your user model isn’t clean, you get role creep, too many high-tier users, and costs nobody can defend at renewal time.

Contact us now!

PUPM means Per User Per Month — a billing model where Public Cloud usage rights are planned and purchased as a monthly fee per user.

The important part: in Public Cloud, the monthly amount usually depends on user types / access depth (e.g., “Standard”, “Advanced”, “Self-Service/Light” — depending on the product and contract structure). PUPM is the billing unit, but control comes from:

• User type / access depth

• Role packages

• Governance for changes (upgrades, exceptions)

Snippet-ready definition:
PUPM (Per User Per Month) is a user-based billing model in SAP Public Cloud where cost is charged per user and month, typically driven by user types, role packages, and upgrade governance.

A common misconception: “We have 1,000 users, so we pay 1,000 × PUPM.” In reality:

• User count = number of people with access

• PUPM cost = number of users by user type × monthly price × term

Your main lever is not just “how many users”, but:

• which users get which user type

• how stable your role model stays over time

Memorable line:
PUPM doesn’t just count people. PUPM prices access depth — and access depth tends to grow unless you control it.

Because PUPM is the Public Cloud equivalent of “permission + cost control.”

If you don’t separate PUPM, FUE, and Named User, two things happen: forecasts become unreliable, and permissions grow without cost steering.

“Give everyone the higher user type.” Convenient now, expensive forever.

“Key user = high tier.” Key user is a project role; without post–go-live downgrade, you overpay.

“We define 50 personas.” Too many exceptions kills control. Aim for 10–15.

“No one reviews the user mix.” You discover the drift at renewal — too late.

A setup that works fast and scales:

1. Define 10–15 personas
   Focus on process reality, not org charts.

2. Create one approved role set per persona
   Standard packages, minimal variations.

3. Assign a target user type per persona
   This is your default—not your maximum.

4. Rule: “new role → PUPM check”
   Every exception triggers a quick question: does the user type change? Who approves?

5. Forecast 12–36 months
   Rollout waves, growth scenario, seasonal peaks.

6. Review cadence
   Monthly (dynamic) or quarterly (stable):

   • user mix

   • outliers

   • actions (downgrade, cleanup, training)

A company starts SAP S/4HANA Cloud, Public Edition for Finance & Procurement in Germany, later expanding to AT/CH (or similarly: initial US region, then more states). Total: 600 planned users.

To scale without cost creep:

• Persona catalog: approved personas + target user type

• Approved role sets: standard role packages per persona

• Change control: upgrades only with quick approval (owner + reason + timebox)

• Cost attribution: persona/team → cost center (light showback)

• Review cadence: user mix, outliers, actions

This turns PUPM from “licensing stress” into a controllable model.

PUPM (Per User Per Month) sounds like simple billing, but in SAP Public Cloud it’s a core steering model. If you define personas cleanly, standardize role packages, and treat upgrades as approved exceptions, your user mix stays stable—and PUPM stays predictable. And if you clearly distinguish PUPM from FUE (private cloud weighting model) and Named User (classic on-prem principle), you get forecasts Finance trusts and governance IT can actually live with.