What Happens to Unused AI Units at Month-End?

PUPM packages in SAP Business AI work differently from classical licenses. Unused requests expire at month-end, not at year-end. What pooling makes possible, how continuous observation prevents waste, and which monthly governance moments Director SAP Platform and the four roles should derive.

How Month-End Expiration Works Mechanically

SAP Business AI operates with two distinct expiration logics that are frequently confused in practice.

The first is the classical AI unit quota: prepaid volume that an organisation purchases per contract year. This quota expires at year-end unless a rollover clause was negotiated in the Order Form. (The fact that SAP does not include such a rollover by default is a separate topic, addressed in the context of annual governance planning.)

The second is the PUPM mechanics. PUPM stands for Per-User-Per-Month: rather than drawing from a central pay-per-use pool, an organisation purchases a monthly package with a fixed request quota for defined user groups. These packages are structured by line of business: Finance, Spend Management, Customer Experience, and Human Capital Management.

The decisive mechanism: requests within a PUPM package expire on the last day of the month. There is no carryover to the following month. What was not consumed in February no longer exists in March.

That may sound like a minor detail of SAP license architecture. It is not. An organisation with 200 licensed users in the Finance PUPM package that draws only 60% of requests in March has permanently forfeited 40% of that month's package volume. Scaled across a full year and multiple packages, this creates a structural budget gap that remains invisible in the annual accounts because it generates no cost event. It represents unused investment, nothing more.

This asymmetry is the starting point for all governance moments around PUPM packages.

Source: SAP Help Portal, Metering and Pricing for SAP AI Core; SAP Learning, Analyzing the SAP Per-User-Per-Month Pricing Model.

What Pooling Permits Within a PUPM Package

Within a PUPM package, there is a balancing mechanism: pooling at the customer level.

This means that individual users do not each hold a rigid monthly quota that belongs exclusively to them. When user A draws significantly fewer requests than their package share in a given month, those unused requests become available to other users within the same package. The pool is drawn at the package level, not per person.

This meaningfully limits the loss scenario described above. An organisation with a well-sized package and a sufficiently large user group can absorb natural usage fluctuations. In a department with 50 Finance users, the heavy user during quarterly close compensates for the occasional user during quieter periods.

There is, however, a firm boundary: pooling applies exclusively within a single package. Cross-package pooling is not provided for. An organisation holding three PUPM packages (Finance, Spend Management, and HCM) cannot cover overuse in one package with remaining volume from another. Overuse draws additional AI units from the central annual quota instead, provided sufficient volume remains there.

Conversely, monthly pooling volume that no user within a package has drawn still expires at month-end. The pooling logic distributes available requests efficiently within a package. It does not suspend the fundamental expiration rule.

This mechanism defines the first practical governance moment: the relevant question is not simply whether enough package volume exists, but whether the package is sized to the genuinely active user group. A package sized too small generates overage costs. A package sized too large generates monthly losses.

Where Investment Typically Goes Unrealised

Three consumption patterns appear consistently in practice and lead to structurally unused PUPM volume.

Too many users in the package, too little actual usage. The gap often originates in initial sizing. During negotiations, PUPM packages are frequently ordered based on headcount projections or license roles rather than measured usage behaviour. Licensing all potential users by system role produces a different activation profile than actual usage data would indicate. Particularly in the first twelve to eighteen months after deployment, activation rates often fall short of projections. The PUPM volume runs off monthly regardless.

Seasonal usage patterns without adjustment. Quarterly close, year-end, audit periods, and project phases generate noticeable usage spikes. Demand for AI-supported workflows is correspondingly lower during quieter periods. A static PUPM configuration sized for peak load forfeits volume monthly during intermediate phases. The model does not allow in-month adjustment, but continuous observation at least enables planning for the next renewal period.

Parallel packages for overlapping user groups. When a user is assigned to multiple PUPM packages, each package is billed separately without cross-package pooling to offset those costs. In practice, this arises when user roles are defined across departmental boundaries, or when a contract amendment leaves legacy package assignments uncleaned. The result: duplicate package volume for one user, with only one of the pools being meaningfully utilised.

How Continuous Observation Addresses Expiration

Continuous observation of PUPM consumption is not a one-time exercise. It is a monthly governance moment that must be actively triggered. The following steps form a practical rhythm.

Step 1: Monthly consumption review per package. SAP for Me displays aggregated AI unit consumption. For PUPM packages, the relevant figure is how much of the monthly request quota per package was actually drawn. This figure should be documented monthly, not only at year-end. Only a time series across several months makes patterns visible.

Step 2: Define utilisation rate as a governance variable. A utilisation rate below 60% over three consecutive months indicates that the package is either oversized or that user adoption has room to grow. Both causes have different implications for the next contract period and should be evaluated separately.

Step 3: Review user assignments quarterly. Every user assigned to a PUPM package should be validated quarterly: is this person currently active? Has the role changed? Have restructurings shifted departmental affiliation? This governance moment is closely connected to the onboarding and offboarding process, addressed in the next section.

Step 4: Evaluate overage events. When a package exceeds its monthly quota in individual months and draws additional AI units from the annual quota, this signals that the package is sized too tightly for that user group. Repeated overage events over two to three months support a case for expanding the package before the next renewal period.

Step 5: Prepare a sizing recommendation for the next contract period. Governance moments during live operations only deliver value if they flow into the next negotiation. The observation data from the current period forms the foundation for a substantiated negotiating position: neither accepting oversizing nor paying unnecessary overage costs due to undersizing.

All five steps draw on data that SAP standard reporting delivers in part and does not deliver in other parts. Granularity at the user level within a package is not available in the standard. Understanding which users genuinely drive a package and which structurally underuse it requires an additional observation layer.

What Happens During Staff Turnover

Staff turnover is an underappreciated governance moment in PUPM management.

When an employee leaves the organisation, their PUPM package assignment in SAP Identity Authentication Service (IAS) persists until someone actively removes it. This has two consequences: package volume continues to run for a user who is no longer generating requests, and when successors or new employees are onboarded, new assignments may be created that coexist with outdated ones.

In organisations with regular restructurings or elevated turnover in certain areas, this effect accumulates. A package with 20 assigned users, five of whom have left the organisation and three of whom have moved to different departments since the last quarter, uses its pooling volume inefficiently.

The practical recommendation: cleaning up PUPM assignments should be connected to the HR offboarding process rather than treated as a manual IT task. The earlier a departed employee is removed from the package, the earlier that slot can be allocated to an active user without expanding the package scope.

The same applies to internal transfers: a user who moves from the Finance area to Spend Management should be removed from the Finance package and assigned to the Spend Management package. Without that step, duplicate assignments accumulate with corresponding duplicate costs.

FAQ

Do all unused AI units expire at month-end?

No. The expiration rule applies specifically to the monthly request quota within PUPM packages. The central annual AI unit quota (the prepaid volume from the contract) expires at year-end, not monthly. Both pools follow their own rules and should be observed separately. Source: SAP Help Portal, Metering and Pricing for SAP AI Core.

Can unused PUPM requests be carried over to the next month?

No. A rollover of PUPM requests across month boundaries is not provided for in the standard. Within the current month, pooling is possible within a package, meaning active users can draw requests allocated to other package members that have not yet been used. At month-end, unused volume expires permanently.

Which governance moments are relevant for Director SAP Platform on a monthly basis?

The first governance moment is the consumption review: how much of the PUPM package volume was utilised per package? The second governance moment is user assignment: are all assigned users still active and correctly mapped to the right packages? The third governance moment is the overage review: has any package exceeded its monthly quota and drawn additional AI units from the annual quota? These three checkpoints can be consolidated into a monthly routine and form the basis for a substantiated sizing decision in the next contract period. Source: SAP Learning, Analyzing the SAP Per-User-Per-Month Pricing Model.

Which of the four roles owns which governance moment?

The Contract Manager tracks package assignments and validates that PUPM structures reflect the current contract scope. Procurement uses consumption data to prepare the sizing recommendation for the next renewal. Controlling maps monthly PUPM costs to departmental cost centres and flags budget deviations early. The Executive reviews the consolidated picture at renewal: is the current package portfolio aligned with planned AI deployment across lines of business?