Can I use unused Capacity Units for AI services?

No. AI Units and Capacity Units are not interchangeable. An existing BTPEA balance cannot be used for Joule conversations or AI Core calls.

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

The AI Unit quota is a prepaid annual balance. PUPM packages are monthly request quotas per user structured by line of business. PUPM requests expire monthly; AI Units expire annually.

Three Consumption Pools in SAP Business AI: What Distinguishes AI Units, Capacity Units, and BDC Credits

SAP Business AI bills through three separate consumption pools: AI Units for generative AI functions, Capacity Units for classical SAP AI services, and BDC Credits for Business Data Cloud. What connects, what stays apart, where pooling is possible, and where investments expire.

Why Three Pools and Not One

Anyone trying to steer SAP Business AI within a single contract encounters something that most initial negotiations leave unaddressed: what SAP markets under the umbrella term "Business AI" divides into three separate consumption models that can neither be aggregated nor offset against each other.

This separation is not an oversight. It is the result of a grown product architecture. BTP platform services were historically billed via Capacity Units long before generative AI capabilities existed. SAP Business AI as a service category received its own AI Units because the pricing logic differs: not platform capacity, but AI service consumption. The Business Data Cloud emerged as a separate data layer and brings its own billing logic.

For contract governance, this has a direct consequence. An organization with a BTP Enterprise Agreement and a remaining Capacity Unit balance cannot apply that balance to Joule conversations or AI Core calls. An organization that has purchased AI Units cannot use them to operate Integration Suite services. Each pool stays closed in itself. Forecasting, budget allocation, and monitoring must be built separately per pool. This is the first governance moment at which insufficient pool knowledge leads to misallocated investment.

The DSAG Licenses Working Group named this pool separation in 2026 as a structural complexity that makes entry into SAP Business AI more demanding and requires dedicated governance capabilities (source: NextLytics, DSAG Technology Days 2026).

Pool 1: AI Units

AI Units are the central consumption unit for SAP Business AI services. SAP defines them as "a consumption-based virtual currency used to consume SAP Business AI services across the portfolio" (source: SAP Pricing Page). Customers purchase a prepaid annual allowance. Each AI service call draws a contractually defined number of AI Units, depending on the service used.

AI Units are consumed via SAP S/4HANA Cloud (embedded AI features), SuccessFactors, Ariba, SAP Build with Joule capabilities, and BTP services such as AI Core and the Generative AI Hub. The conversion factor varies substantially by service: Joule Messaging consumes 7 AI Units per 10,000 messages, Document Grounding consumes 0.005 AI Units per record. For calls via the Generative AI Hub, token consumption is the base metric, which is then converted into AI Units; the range is model-dependent (source: SAP Help Portal, Metering and Pricing for SAP AI Core).

The pricing logic behind AI Units follows a prepaid model that generates two governance moments. First: unused AI Units expire at the end of the contract year unless an explicit rollover clause has been agreed in the Order Form. DSAG data indicate that a significant share of RISE customers in their second contract year carry unused AI credits, because actual AI adoption typically lags behind original usage projections. Second: an organization that exceeds its allowance moves into the overage logic of the Order Form, which, depending on wording, can cost two to four times the contract rate.

Alongside the standard allowance model, SAP offers a second billing model for AI Units: PUPM packages (Per-User-per-Month). Each user is assigned a package slot via SAP Identity Service that contains a fixed monthly request allowance. Within a package, unused allowances from one user can be drawn by other users in the same package. That is the permitted pooling. Cross-package pooling is not available. All unused allowances expire at month-end.

PUPM packages are structured by solution area: Finance, Spend Management, Customer Experience, Human Capital Management. An organization that wants to use Joule capabilities across multiple areas needs a separate package for each area. A user assigned to two packages pays for both separately. There is no offset between packages.

For contract governance, AI Units therefore represent the most pronounced governance moment in the SAP Business AI contract portfolio, because their mechanics, expiry behavior, and pooling logic have the greatest influence on budget planability.

Pool 2: Capacity Units

BTP Capacity Units are the consumption unit for BTP platform services. They fund infrastructure, not AI functionality. They are obtained via the BTP Enterprise Agreement (BTPEA) or the Cloud Platform Enterprise Agreement (CPEA).

The boundary with AI Units is precise: Capacity Units cover Integration Suite, application development, database services, analytics, and comparable platform services. AI Units cover the AI capability layer on top of that platform. Both pools run simultaneously and separately (source: SAP Help Portal, Metering and Pricing for SAP AI Core).

For contract governance, this is a frequent source of miscalculation. An organization with an active BTPEA and growing AI requirements cannot simply draw on existing Capacity Unit balances to fund AI capabilities. It must conclude a separate AI Unit contract or acquire AI Units as an add-on. The governance moments for consumption and cost converge here: an organization that does not monitor and forecast Capacity Units and AI Units separately builds a budget picture that does not reflect the actual consumption structure.

Capacity Units are in practice the more stable pool, because their consumption profile is more tightly linked to plannable platform workloads. However, AI-intensive agent workflows change this profile, because they consume both platform infrastructure and AI services and thus draw on both pools simultaneously.

Pool 3: BDC Credits

The Business Data Cloud (BDC) is SAP's data layer. It connects SAP and non-SAP data via a delta-sharing protocol and provides the foundation for the SAP Knowledge Graph, for Company Memory, and for the organization's own process and policy knowledge that Joule and agents use as context.

The BDC is licensed via its own BDC subscription. Billing runs via dedicated credits whose measurement depends on data volume, delta sharing, and the data products used. These credits are not interchangeable with AI Units or BTP Capacity Units.

The governance moment for BDC Credits frequently lies in a blind spot. Many organizations that want to use Joule with custom model grounding or with proprietary context activate the BDC pool automatically, without that pool having been explicitly considered in initial contract planning. BDC is often treated in negotiations as a separate line item that becomes visible only when a concrete AI use case needs to draw on the organization's own knowledge.

For the governance level, the BDC is the data building block without which organization-specific AI governance becomes structurally more difficult. An organization that wants to operate AI agents with reliable, proprietary context should include the BDC pool in procurement planning from the outset, not add it retrospectively (source: SAP Help Portal, Business Data Cloud Metering).

Where the Pools Intersect

In practice, AI use cases frequently draw from more than one pool. This is the situation that is hardest to steer in governance.

A Joule agent that retrieves business data from the Business Data Cloud, executes on BTP runtime, and calls a foundation model in the Generative AI Hub simultaneously generates AI Unit consumption, Capacity Unit consumption, and BDC Credit consumption. These three consumption streams are reported in different SAP tools, with different reporting rhythms and different thresholds. A consolidated view of total AI consumption is not achievable with native SAP tooling, because the tools report per pool, not per use case (source: NextLytics, DSAG Technology Days 2026).

This leads to what practitioners call the aggregation trap. SAP counts AI consumption across all system environments of a customer against the monthly allowance, meaning development, test, and production environments together. An organization running AI features in non-production environments generates consumption against the same allowance as the production system. Combined with a multi-pool use case, this can produce unexpectedly high consumption figures that native reporting tools cannot easily reconstruct.

Several governance moments stack here: in the consumption area (which system environments consume what), in the cost area (which pool generates overage), and in the infrastructure area (how is the system landscape structured and how is it measured against the contract framework). An organization monitoring these moments without a dedicated governance function relies on aggregated data that arrives too late.

The structural recommendation for any organization scaling AI use cases beyond an initial pilot: before rollout, each active use case should have a pool assignment on record. Which AI Units, which Capacity Units, which BDC Credits will be consumed per month? Answering this question early makes budget allocation more robust and the governance moment at renewal more calculable.

Pooling, Rollover, Expiry Compared

The following table summarizes the key parameters of the three pools.

Parameter	AI Units	Capacity Units	BDC Credits
Billing model	Prepaid allowance per year	Prepaid allowance, rolling	Subscription-based, consumption-dependent
Pooling	Within a PUPM package; cross-package not available	Flat per Global Account; no use-case pooling	No pooling across subscriptions
Monthly expiry	PUPM request allowances expire monthly	No	No
Annual expiry	Yes (standard); rollover negotiable	Term-bound; adjustable at renewal	Subscription-periodic
Rollover	Not standard; 10-20% achievable in many negotiations	Not applicable in same form	Not available
Cross-pool consumption	Not possible	Not possible	Not possible
Overage logic	Yes, 1.5-4x contract rate depending on clause	Yes, contract-specific	Yes, per BDC subscription terms
Native monitoring depth	Aggregated (SAP for Me); no user granularity	Subaccount level (BTP Cockpit)	BDC Cockpit; use-case granularity limited

(Sources: SAP Help Portal Metering and Pricing, SAP Licensing Experts AI Units Explained 2026, SAP Learning PUPM Pricing Model)

The table makes the central challenge visible: in none of the three pools does SAP today offer a use-case-level consumption view that allows a direct comparison with the contract framework. This is not a technical oversight; it is a structural limit of native tooling that the DSAG Licenses Working Group has framed as an open demand toward SAP: "When will a FinOps tool for billing, metering, and forecasting at the AI level be available?" As of May 2026, this question remains open (source: NextLytics, DSAG Technology Days 2026).

For governance, this means: an organization scaling SAP Business AI beyond a simple pilot will reach the limits of planability with native tooling. Budget allocation, rollover negotiations, and overage control all require an independent observation layer that consolidates the three pools and reflects them against the contract framework. This is exactly the governance moment where a dedicated contract governance function provides the planning basis.

Frequently Asked Questions

Can AI Units be carried over across fiscal years?

Not by default. Unused AI Units expire at the end of the contract year. A rollover right of 10 to 20 percent of unused AI Units can be introduced in many contract negotiations, but it is not a standard condition and must be explicitly anchored in the Order Form (source: SAP Licensing Experts, AI Units Explained 2026).

What happens if a user is registered in multiple PUPM packages?

The user pays for each package separately. Unused allowances from one package cannot be credited against another package. Cross-package pooling is not part of the PUPM logic (source: SAP Learning, Analyzing the PUPM Pricing Model).

When does BDC become relevant in contract planning?

Whenever Joule capabilities or AI agents are to be grounded on proprietary context, whether via custom model grounding, Company Memory, or the SAP Knowledge Graph. At that point, BDC becomes an active consumption pool that must be procured and governed separately.

Which tool provides a consolidated view across all three pools?

There is currently no native SAP tool that aggregates all three pools and reflects them against the contract framework. SAP for Me shows aggregated AI Unit consumption, the BTP Cockpit shows Capacity Unit consumption at subaccount level, the BDC Cockpit reports BDC Credits. Consolidation rests with the customer and requires a dedicated governance capability.

Further articles in this series:

SAP Business AI 2026: What It Is and What Has Changed (Cluster 1)
Understanding PUPM in SAP Business AI (Cluster 3)
Business AI in the RISE Contract (Cluster 5)
Full Overview: SAP Business AI Licensing and Governance (Hub Pillar 2)

Sources: SAP Help Portal (Metering and Pricing for SAP AI Core, Metering and Pricing for Generative AI, Business Data Cloud), SAP Pricing Page (Software Packages and Pricing: SAP Business AI), SAP Learning (Analyzing the PUPM Pricing Model), SAP Licensing Experts (SAP AI Units Explained 2026, SAP AI in RISE Contracts 2026), NextLytics (DSAG Technology Days 2026: SAP's AI Strategy Reality Check)

Author: Bernhard Mändle | LinkedIn | Last updated: May 2026