Can unused PUPM requests be accumulated?

No. PUPM requests expire permanently at month-end. Neither carryover to the following month nor crediting against the annual quota is provided for.

What is the difference between PUPM and the classical AI Unit quota?

The classical AI Unit quota is a central annual prepaid pool. PUPM is a monthly per-user quota per line of business. PUPM expires monthly; the annual quota at year-end.

PUPM in SAP Business AI: How the Per-User-Per-Month Model Really Works

Per-User-per-Month sounds like a classical license, but in SAP Business AI it is a consumption model with monthly expiration. Unused requests expire at month-end, not at year-end. What this means for budget planning, forecasting, and employee turnover, and which governance moments emerge.

How PUPM Works Mechanically in SAP Business AI

PUPM stands for Per-User-per-Month. In the context of SAP Business AI, it describes a consumption model in which each user is allocated a fixed quota of AI requests per month. The starting point is a technical assignment: every user receives a package assignment in the SAP Identity Authentication Service (IAS). That package defines which AI capabilities the user may access and how many requests are available each month.

Packages are not cross-product pools. They are scoped by solution area: Finance, Spend Management, Customer Experience, Human Capital Management. A user who wants to use Joule in Finance and in Procurement requires two separate packages, because cross-package pooling is not part of the model. Each package is purchased separately and billed separately.

Within a package, a limited balancing mechanism applies: requests that one user has not consumed in a given month can be used by other users in the same package during that month. This allows some flexibility when usage is uneven across a group (Source: SAP Learning, Analyzing the PUPM Pricing Model). The balancing is strictly intra-package. Package A never offsets Package B.

When Requests Expire and How Much

The central governance moment in the PUPM model is monthly expiry. Every package resets after 30 days. What has not been consumed is forfeited. There is no carry-forward to the following month, not even on a pro-rata basis.

This expiry cycle differs structurally from the annual expiry of classic AI Unit entitlements: while AI Unit pools expire at year-end, PUPM expires every month. For investment planning, this means that underestimating adoption or delaying a rollout results in budget loss not once a year but twelve times.

In practice, these losses tend to appear in two situations. The first is the ramp-up phase of a rollout: packages are assigned to users before training is complete or before workflows are stable. The package is paid for, the request pool expires. The second is uneven seasonal usage: business units that operate on an annual cycle, with a heavy month-end close and quieter periods in between, pay for months in which utilization is low.

Monthly expiry is not a flaw in the model but a deliberate design choice. As a governance moment it means: PUPM packages cannot be assessed only once at the point of purchase. They require continuous review. Without monthly observation of package utilization rates, organizations structurally pay more than necessary. Controlling and Contract Managers need a regular view of package fill rates that is not fully derivable from standard SAP reporting alone (Source: SAP Help Portal, Metering and Pricing for SAP AI Core).

Pooling Within the Package

The pooling mechanism in PUPM is precisely bounded. Requests are poolable within a package: if User A does not fully consume their allocation in a given month, the remaining requests can be used by User B in the same package. This allows balancing within a usage group.

Three pooling boundaries are relevant for governance. First, pooling does not work across packages: Finance packages and Procurement packages remain separate pools, even within the same organization. Second, pooling is limited to the current month. There is no carry-forward between months, neither within a package nor across packages. Third, external visibility into pooling is limited: SAP reports consumption at the package level, not at the user level within a package. Any organization wanting to know which user consumed what share of the pool will not find that information in standard reporting (Source: SAP Learning, Analyzing the PUPM Pricing Model).

This reporting gap is a structural obstacle for continuous steering. Controlling can observe at the package level whether the entitlement is being used. However, verifying whether the right users hold the right packages requires an observation layer that goes beyond native SAP reporting. That gap is the starting point for an independent governance function. This is precisely where a second governance moment arises: the assignment and regular review of PUPM package allocations is not a one-time onboarding task. It is a recurring steering task.

What Happens During Employee Turnover

Employee turnover is a frequently underestimated cost factor in PUPM models. The model itself has no automatic cleanup mechanism. When a user leaves the organization, their assigned PUPM package remains active until it is manually deactivated. The slot continues to be paid for, and the request entitlement continues to expire each month.

In practice, this creates a structural gap between HR offboarding and SAP license management. The period between a user's last working day and the actual package deactivation can range from weeks to months, depending on process maturity.

The reverse direction is equally relevant. When a new employee joins, the PUPM package must be actively assigned. This happens manually or via Excel batch upload, not automatically from the HR system. Until the assignment is in place, the slot remains vacant, and the package entitlement flows into the pool without the intended user being able to apply it productively.

For Contract Managers and Procurement, this represents a governance moment with direct operational impact: plannable steering of PUPM costs requires close coordination between HR offboarding, IT access management, and SAP license assignment. When these three processes are not aligned, organizations pay for slots that no one is actively using. And when new joiners are not integrated into productive packages promptly, adoption potential is left unrealized during the months when onboarding is most intensive.

Practical Forecasting Boundaries

Classic license forecasting follows simple logic: user count multiplied by license price. In PUPM, that calculation is only the starting point. Organizations seeking to steer their investment with precision need three additional variables: adoption rate, rollout plan, and consumption profile per usage type.

The adoption rate determines how much of the paid request pool is actually utilized each month. If a package with 100 users is utilized at only 40 percent capacity, 60 percent of the package potential expires each month. For Controlling, this is a budget variance that remains invisible without monthly observation. Recognizing and addressing it early is a governance moment that requires regular analysis.

The rollout plan influences when packages should be activated. A common pattern: licenses are centrally procured at contract start, but actual activation is staged over several months. Activating packages before productive use means paying for the lead time. Activating them too late means losing adoption speed. This trade-off is a governance moment that calls for an executive decision: when does the rollout begin, and in what sequence?

Consumption profiles vary significantly by usage type. Users who use Joule primarily for straightforward conversational queries generate a different consumption pattern than users operating Joule in agentic workflows. Agentic deployments can consume substantially more tokens and AI Units than simple skill calls, depending on plan complexity. Organizations planning the transition from copilot to agent deployments should account for this explicitly in their forecasting (Source: SAP Licensing Experts, Negotiating SAP AI Contracts).

Reliable PUPM forecasting therefore requires use-case-specific analysis that goes beyond SAP's own sizing assumptions. SAP sizing estimates for copilot usage tend to underrepresent agentic workloads, because multi-step plans consume considerably more than standard projection models assume. Procurement and Controlling should address this gap together with the relevant business unit before the next renewal cycle.

What to Monitor Continuously

PUPM is not a set-and-forget model. The following governance moments require regular attention:

Monthly package utilization rate: Is utilization systematically below the paid entitlement? If so, a package adjustment or a delayed rollout start may be appropriate.
Active users per package: Are packages formally assigned but not actively used? Gaps between assignment and usage are an early indicator of adoption challenges.
Offboarding lag: How long do departed employees remain in active PUPM packages? A clear offboarding process with direct package deactivation is an operational governance moment.
Cross-package analysis: Are users assigned multiple packages when their usage profile does not justify it? Redundant package assignments are a frequent source of avoidable cost.
Sizing assumptions ahead of the next renewal: Do the original SAP sizing assumptions match the actual consumption profile? Deviations should be the basis for the next renewal discussion.

This observation layer cannot be fully established with native SAP tools alone. SAP for Me and the BTP cockpit provide aggregate values, but not user-granular analysis within a PUPM package. An independent governance function that closes this gap is, for any organization seeking to deploy its investment with precision, not an optional add-on but a structural requirement (Source: NextLytics, DSAG Technology Days 2026).

FAQ

What is the difference between PUPM expiry and annual expiry of AI Units?

AI Unit entitlements purchased in the classic prepaid model expire at the end of the contract year. PUPM request entitlements expire monthly. That is a shorter cycle with more frequent expiry events. Organizations purchasing PUPM packages while ramping up adoption gradually lose budget not once a year but every month.

Can I use requests from a Finance package for Spend Management use cases?

No. Packages are solution-area-specific. Finance packages cover Finance capabilities, Spend Management packages cover Procurement capabilities. Cross-package pooling is not part of the model. A user who requires both areas needs two separate packages.

What happens when a user exceeds their PUPM entitlement?

Consumption beyond the package entitlement is drawn from the organization's central AI Unit pool. If sufficient entitlement is not available there, overage charges apply. This is an additional reason to monitor package utilization and the central AI Unit pool together. A governance moment that affects Contract Managers and Controlling alike.

How many users can be assigned to a single PUPM package?

The assignment is technically unlimited. The commercial boundary lies in the request pool: the more users share a package, the lower the average share available per user. Package dimensioning should therefore be based on expected usage volume, not solely on the number of potential users.

Further reading: SAP Pricing Page | SAP Help Portal: Metering and Pricing for SAP AI Core | SAP Learning: Analyzing the PUPM Pricing Model | SAP Licensing Experts: SAP AI Units Explained | NextLytics: DSAG Technology Days 2026

Back to the Pillar 2 Hub: SAP Business AI: Licensing, Consumption, and Governance