SAP Business AI: Licensing, Consumption, and Governance

SAP Business AI consists of three separate consumption pools, three procurement paths, and a governance layer subject to the EU AI Act from August 2026. Understanding this structure helps avoid three typical traps: unused AI Units, double-paid capabilities, and compliance gaps in production use cases.

Table of Contents

1. What SAP Business AI Is Today
2. Three Consumption Pools: AI Units, Capacity Units, BDC
3. AI Units: Mechanics, Expiry, Pooling
4. PUPM Model and Token Pricing
5. Joule: Frontend, Skills, Agents
6. Foundation Models and Multi-Agent Logic
7. Three Procurement Paths: Standalone, Subscription, RISE
8. What Is and Is Not Included in RISE
9. Overage Mechanics and the Aggregation Trap
10. EU AI Act: Effect from August 2026
11. Data Sovereignty, IP Indemnification, Tenant Isolation
12. What to Review Before Negotiation
13. FAQ
14. Next Steps

---

What SAP Business AI Is Today {#what-sap-business-ai-is-today}

SAP Business AI has been the official umbrella brand for all AI capabilities in the SAP ecosystem since the Sapphire 2026 conference. It is also the most frequently misunderstood product category in current SAP contract portfolios. This section establishes the conceptual foundation for all subsequent sections.

Definition as a Three-Layer Architecture

SAP Business AI does not describe a single application but a platform architecture organized into three layers. SAP has officially referred to this since Sapphire 2026 as the SAP Business AI Platform.

The Context Layer forms the invisible base. It encompasses the Generative AI Hub with access to external foundation models from major providers, the SAP-proprietary models SAP-ABAP-1 and SAP-RPT-1, the SAP Knowledge Graph as a source for process domain knowledge, and the Business Data Cloud (BDC) as the data layer. Every higher-level service, whether a Joule conversation, an embedded AI feature, or a self-built agent, consumes this layer.

The Build Layer is Joule Studio 2.0, generally available since June 2026. It is the development environment for customer-built agents: a visual Agent Builder, a library of more than 2,500 pre-built SAP skills, a command-line interface for DevOps pipelines, a VS Code extension, and an integration of the open Model Context Protocol (MCP) for external AI toolchains.

The Governance Layer is the SAP AI Agent Hub, planned for general availability in Q3 2026. It is built on SAP LeanIX and provides discovery, verification, observability, and policy management for all agents in the tenant: SAP-delivered, customer-built, and third-party agents.

For contract steering, this three-layer logic is decisive because each layer has its own metering points. A Joule license does not automatically cover agent build and governance operations. Identifying which layers a planned use case will touch is the first governance moment in any SAP Business AI deployment.

Joule as the Shared Frontend

Joule is the unified copilot interface across all SAP solutions. As of 2026, Joule is active in 35 SAP solutions, from SAP Cloud ERP to SuccessFactors, Ariba, Fieldglass, and SAP Build. With Joule Work, the UX vision introduced at Sapphire 2026, SAP is positioning Joule as the primary interaction layer long term, gradually replacing traditional application navigation.

For licensing, this means Joule is not a single product with one license but a portfolio of consumption models. Per-user-per-month packages, AI Unit allowances, and token-based pricing coexist, depending on usage type and configuration.

Embedded AI Versus Custom Agents

SAP distinguishes two fundamental usage modes: embedded AI and custom agents.

Embedded AI comprises AI capabilities that SAP has integrated directly into its solutions, requiring no customer-side development. Examples include automated payment advice processing in Finance, the Catalog Optimization Agent in Procurement, and inventory analysis in Supply Chain. These capabilities are part of the solution subscription, but they still consume AI Units or fall under PUPM packages.

Custom agents are developed in Joule Studio 2.0 and operated via runtime on BTP. They enable customer-specific automation but require separate runtime licenses. The free design-time access valid through end of 2026 is an adoption strategy: organizations that build in 2026 will need runtime capacity in 2027.

The commercial difference is significant: embedded skills typically consume a defined AI Unit quantity per transaction, while autonomous agents can consume multiples of that in complex multi-step plans.

What Changed in 2025 and 2026

Three structural changes are relevant for contract steering.

First, RISE with SAP Premium Plus, the former top tier, was discontinued in June 2025. The AI capabilities that had been included were partly carried over into SAP Cloud ERP Private and partly repositioned as separate add-ons. Contracts that still reference the old tier name should be reviewed for what their current contractual scope actually is (sources: Redress Compliance, CIO Magazine).

Second, SAP introduced Joule Studio 2.0 and the AI Agent Hub as a development and governance infrastructure that played no role in earlier contract negotiations. For organizations intending to deploy AI in production, new licensing and compliance dimensions arise.

Third, the number of embedded capabilities is growing continuously: from 30 agents and 2,500 skills in Q1 2026 to 224 agents and 51 role-specific assistants at the Sapphire conference in Q2 2026 (source: SAP News, Sapphire 2026). Each new capability is a potential new consumption point. Organizations that do not continuously monitor consumption will notice shifts only when the next invoice arrives.

---

Three Consumption Pools: AI Units, Capacity Units, BDC {#three-consumption-pools}

Before contract and consumption details can be assessed, three conceptual worlds must be kept separate. In 2026, SAP operates three non-interchangeable consumption models in parallel. Conflating them leads to incorrect forecasts and procurement that misses actual requirements.

AI Units: Definition and Scope

AI Units are the consumption-based metering unit for SAP Business AI services. Customers purchase a prepaid allowance of AI Units per contract year. Each AI service call draws a defined number of AI Units, depending on the service used.

AI Units are consumed via 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. They are the central consumption currency for everything SAP markets as Business AI.

For contract governance, the key point is this: AI Units are not interchangeable with BTP Capacity Units. An organization with a BTP Enterprise Agreement and a remaining credit balance cannot apply that balance to AI capabilities. AI Units exist in their own, separate pool.

Capacity Units: Boundary

BTP Capacity Units (CU) are the consumption unit for BTP platform services: Integration Suite, application development, database services, analytics, and others. 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 fund the platform infrastructure. AI Units fund the AI capability layer on top of that platform. Both pools run simultaneously and separately.

In practice, this means an organization with an active BTPEA and emerging AI needs must conclude a separate AI Unit contract or acquire AI Units as an add-on to the existing subscription. Cross-pool consumption is not provided for (source: SAP Help Portal, Metering and Pricing for SAP AI Core).

Business Data Cloud Credits

The Business Data Cloud (BDC) is SAP's data layer, connecting SAP and non-SAP data via a delta-sharing protocol. It is licensed via its own BDC subscription and measured on a consumption basis with dedicated credits, depending on data volume, delta sharing, and data products.

The BDC is the source for the SAP Knowledge Graph and for Company Memory, meaning the organization's own process and policy knowledge that Joule and agents use as context. Organizations that want to ground AI agents in proprietary knowledge will automatically touch the BDC pool.

In contract negotiations, BDC is frequently treated as a separate line item. Organizations intending to deploy Joule with custom model grounding should verify whether their current contract already includes BDC or whether a separate procurement path is required.

What Happens When a Use Case Touches Multiple Pools

In practice, AI use cases frequently draw from more than one pool. A Joule agent that retrieves business data from the BDC, 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.

The challenge lies in visibility: the three pools 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 governance moment calls for a pre-deployment pool assignment for each production AI use case: which AI Units, which Capacity Units, which BDC credits will be consumed per month and per year? Answering these questions early makes forecasting more reliable and budget planning more controllable.

---

AI Units: Mechanics, Expiry, Pooling {#ai-units-mechanics-expiry-pooling}

AI Units are the central consumption currency for SAP Business AI. Organizations that understand their mechanics can steer the budget precisely. Those that do not will pay for allowances that expire or for overages that could have been avoided.

How an AI Unit Is Defined

SAP defines AI Units as "a consumption-based virtual currency used to consume SAP Business AI services across the portfolio" (source: SAP Pricing Page). Customers purchase a prepaid allowance per contract year. The actual consumption rate depends on the service used: each service has its own conversion factor.

Conversion factors that SAP has published include: Joule Messaging consumes 7 AI Units per 10,000 messages. Document Grounding consumes 0.005 AI Units per record. Cash Application rates vary by transaction volume, with higher volumes yielding a lower per-unit rate (source: SAP Help Portal, Metering and Pricing).

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 and can be substantial depending on conversation context.

Expiry Rules

AI Units expire at the end of the contract year if unused. This is the standard that applies in almost all contracts without an explicit counter-arrangement. A negotiated rollover is possible but is not part of the standard conditions (source: SAP Licensing Experts, AI Units Explained 2026).

For PUPM packages (Per-User-per-Month), an additional monthly expiry applies: request allowances assigned to a user within a given month expire at month-end. There is no carryover to the following month.

In practice, RISE customers in their second contract year frequently show that substantial portions of their AI Unit allowance go unused, because actual AI adoption lags behind the original usage projections. This situation is structural, not exceptional: SAP sizing assumptions for AI are based on projections that encounter a reality of gradual user acceptance and phased implementation readiness. Reviewing the utilization rate at mid-year and at Q3 is a governance moment that determines whether corrective action, such as accelerating deployment or negotiating a partial rollover, is still possible.

Pooling Within a PUPM Package

PUPM packages offer a limited pooling mechanism: unused request allowances from one user within a package can be drawn by other users in the same package. This provides a balancing function within a usage group.

This pooling operates only within a single package, not across packages. A user assigned to both a Finance package and a Procurement package pays separately for both. Unused allowances from Package A cannot be credited against Package B.

SWITCH Program for Existing Customers

SAP operates an internal migration program for existing customers still working with older AI Unit SKUs. This program transfers old entitlements into an updated structure with unified metering logic and updated capability entitlements.

For existing customers, the SWITCH is not a technical process without commercial relevance. The transfer can modify capability access and activate tiered pricing rules that did not apply under the old entitlement. The existing entitlement should be carefully documented before a SWITCH is executed (source: SAP Community Blog, The new TDD AI Unit SKU).

What Makes Continuous Monitoring Difficult

The most significant structural constraint in steering AI Units is the limited granularity of native SAP tooling. SAP for Me shows aggregated AI Unit consumption but provides no breakdown at the user level. The BTP Cockpit reports service calls per subaccount but no comparison against the contractual baseline. The SAP AI Pricing Estimator in the Discovery Centre estimates volumes but not euro amounts.

Organizations that want to know which business unit, which user, or which use case is consuming what share of the AI Unit budget will encounter structural limits with native tools (source: NextLytics, DSAG Technology Days 2026). This gap is the starting point for an independent AI governance capability.

---

PUPM Model and Token Pricing {#pupm-model-and-token-pricing}

Alongside the standard AI Unit allowance, SAP offers a second consumption model: Per-User-per-Month packages (PUPM). Both models coexist and serve different usage types.

PUPM Mechanics

PUPM packages follow a fixed package logic: each user is assigned a package via SAP Identity Service (IAS). The package contains a fixed monthly request allowance and a defined number of AI Units reserved for that user.

Packages are structured by solution area: Finance, Spend Management, Customer Experience, Human Capital Management. Organizations that want to use Joule across multiple areas need a separate package for each area. Assignment is done manually or via an Excel batch upload.

The pooling mechanism within a package was described in the previous section: unused allowances from one user can be drawn by other users in the same package. Cross-package pooling is not available.

A structural limitation of the PUPM model is the limited reporting granularity: SAP reports consumption at the package level and at the capability level, but not at the user level within a package. Organizations that want to know whether a specific user is actually using their package will not find this information in standard reporting (source: SAP Learning, Analyzing the PUPM Pricing Model).

Token-Based Pricing in the Generative AI Hub

For LLM calls via the Generative AI Hub, a separate pricing logic applies: token-based pricing. Each call to a foundation model is measured in tokens, which are then converted into AI Units.

The token rate varies substantially by model. SAP-proprietary models such as SAP-ABAP-1 and SAP-RPT-1 sit at the lower end of the pricing scale. Foundation models from major external providers vary, with more capable models typically generating higher token costs.

For a Joule conversation of 10 messages, between 5,000 and 20,000 tokens is realistic, depending on model selection, grounding effort, and conversation length (source: SAP Help Portal, Metering and Pricing for Generative AI). Across an active user population, this can produce substantial annual volumes that early sizing assumptions frequently underestimate.

SAP AI Pricing Estimator as a Reference Tool

SAP makes an AI Pricing Estimator available in the Discovery Centre. Inputs are service or capability, expected volume, and user count. The output is an estimated AI Unit quantity per year.

The Estimator has an important limitation: it shows volumes, not euro amounts. Actual costs emerge only from the individually negotiated price per AI Unit as fixed in the Order Form. The Estimator is therefore a sizing tool, not a budgeting tool. The governance moment lies in connecting the Estimator output to the per-unit price in the Order Form and translating the volume into an actual budget position.

Practical Forecasting Limits

The combination of PUPM packages, AI Unit allowances, and token-based pricing creates three parallel consumption streams that influence each other. PUPM overuse draws AI Units from the central pool. Token-intensive agent conversations consume AI Units faster than simple skill calls.

Reliable forecasting therefore requires a use-case-specific assessment: which usage type dominates in the organization, PUPM-based conversations or AI-Unit-intensive transactional processes? How does the planned agent deployment relate to the sizing assumptions SAP provided at contract signing?

SAP's own projection models for copilot usage structurally underestimate consumption in agentic deployments, because multi-step agent plans consume significantly more tokens and AI Units than simple skill-based copilot interactions (source: SAP Licensing Experts, Negotiating SAP AI Contracts). Organizations planning the shift from copilot to agent-based workflows should address this factor explicitly in contract negotiations.

---

Joule: Frontend, Skills, Agents {#joule-frontend-skills-agents}

Joule is not one product but a product family. For licensing and governance, the determining factor is which Joule component is being used, because the components differ substantially in consumption model, risk profile, and commercial logic.

Joule for Users, Developers, Consultants

SAP differentiates three Joule variants by user group.

Joule for Users addresses end users across the 35 SAP solutions. It is generally available and includes direct access to embedded AI features and conversational capabilities within the SAP workflow context.

Joule for Developers is the ABAP assistant in the ABAP Development Tools (ADT) environment and in Business Application Studio (BAS). It is built on SAP-ABAP-1, SAP's proprietary model trained on 250 million lines of ABAP code, and supports code generation, refactoring, and test generation. SAP cites a productivity improvement of 20 to 25 percent (source: SAP News, Our 2026 Roadmap for Joule for Developers). Licensing is via a separate Joule for Developers SKU or as part of BTP developer subscriptions.

Joule for Consultants is still in beta status, targeting implementation partners as a configuration assistant. The generally available version is planned in the course of 2026.

Skills Versus Agents: the Decisive Distinction

For budget planning and governance, the distinction between skills and agents is foundational.

A Joule Skill is a deterministic, predefined operation: it executes a single, clearly defined action, for example creating a purchase order with specified parameters. Skills are predictable in consumption, manageable in risk, and are typically already factored into sizing at contract signing.

A Joule Agent is an autonomous system that orchestrates multiple skills, plans, and acts. It pursues a higher-level objective, selects its own path toward that objective, and can take unexpected routes. The example "Optimize all open purchase orders by delivery time and cost" is an agent task, not a skill task.

The consumption difference is substantial: agentic deployments consume three to twenty times the AI Units compared to pure copilot projections, based on observations from practice (source: SAP Licensing Experts, Negotiating SAP AI Contracts). Organizations deploying agents in production without adjusting the sizing factor risk unexpected overage.

As of Sapphire 2026, the SAP Autonomous Suite offers 224 agents and 51 role-specific assistants across Finance, Spend Management, Supply Chain, HR, and Customer Experience.

Joule Studio as the Build Environment

Joule Studio 2.0 is the development environment for customer-built agents. It has been generally available since June 2026 and includes Agent Builder, Skill Library, Joule Studio CLI, VS Code Extension, and an MCP Server integration for external toolchains.

Through end of 2026, SAP provides free design-time access to Joule Studio under fair-use conditions. This free access covers the development environment, not production operations. Runtime licenses for running customer-built agents in production are separately required.

Three Construction Patterns

Joule Studio supports three construction patterns that differ in effort and risk.

The first pattern is Skill Assembly: existing SAP skills are combined into new workflow agents. Effort is low because no external integration is required, and risk is limited because only deterministic SAP skills are involved.

The second pattern is API Integration: external REST APIs are embedded as new skills. Effort is moderate; risk lies in ongoing API maintenance and interface stability.

The third pattern is Custom Model Grounding: agents are grounded on customer-specific documents, policies, and master data. Effort is high; risk lies in data quality. At the same time, this pattern is the foundation for the highest differentiation value over generic copilots.

---

Foundation Models and Multi-Agent Logic {#foundation-models-and-multi-agent-logic}

Joule does not have its own "Joule model." It is a frontend layer that consumes foundation models from the Generative AI Hub. Which model is chosen for which use case affects both the outcome and the consumption.

SAP-Proprietary Models and Vendor Lock-in Aspects

SAP develops two proprietary foundation models.

SAP-ABAP-1 was trained on 250 million lines of ABAP code and specializes in code generation, ABAP assistance in the development environment, and process inference in the SAP context. It forms the basis for Joule for Developers.

SAP-RPT-1 is trained on SAP business process data and enables predictions along SAP standard processes as well as process inference for embedded AI features.

The strategic relevance of these SAP-proprietary models lies in two opposing aspects: on one side, they offer a genuine advantage over generic language models because they have SAP-specific domain knowledge embedded. On the other side, they create a dependency: organizations that optimize their ABAP development around SAP-ABAP-1 will find it difficult to separate that practice from SAP (sources: SAP News Joule Studio, SAVIC Technologies AI Foundation Architecture 2026).

External Foundation Models in the Generative AI Hub

Alongside SAP-proprietary models, the Generative AI Hub provides access to foundation models from major providers. SAP abstracts the respective API so that customers can select a model per use case without establishing direct contractual relationships with model vendors.

The available models vary and are updated by SAP on a rolling basis. As of Q2 2026, models from several major providers are integrated (source: SAP documentation on the Generative AI Hub, help.sap.com). Which models are concretely available in a customer tenant depends on the region, contract version, and SAP release cycle.

A governance-relevant question: may SAP unilaterally replace foundation models with new versions or different models? This clause should be explicitly governed in the Order Form. The absence of a clause typically means SAP may adjust the model portfolio unilaterally. Each model substitution cycle is a governance moment: use cases that depend on a specific model's behavior need to be re-validated if the model changes.

Multi-Agent Protocol

SAP introduced a multi-agent protocol in Q1 2026 that enables agents to coordinate across systems. SAP agents can thereby communicate with other SAP agents, with customer-built agents from Joule Studio, and with third-party agents via the Model Context Protocol (MCP).

A practice example: a hire-to-onboard workflow can coordinate a SuccessFactors agent for candidate selection, an S/4HANA agent for master data creation, and a further agent for system access provisioning, without manual handoffs between systems.

For consumption governance, multi-agent coordination introduces a new dimension: every agent call within a multi-agent workflow generates its own consumption. Complex workflows can therefore rapidly consume substantial AI Unit quantities. At the same time, observability of these workflows with standard reporting tools is limited. The commissioning of a multi-agent workflow in production is therefore itself a governance moment: consumption projections must be updated before go-live, not after the first monthly report.

MCP Integration

SAP has supported the open Model Context Protocol (MCP) since Q1 2026. This allows external AI toolchains to access SAP Joule skills and SAP agents to consume external MCP servers.

For organizations operating their own AI architectures, MCP opens a bridge between SAP agents and external AI tools. At the same time: the SAP API Policy v4/2026 prohibits autonomous third-party AI agents at SAP APIs. Third-party components may provide skills but may not operate independently acting agents against SAP data (source: SAP API Policy, cross-referenced in SAP Help Portal). This tension should be considered in architecture decisions.

---

Three Procurement Paths: Standalone, Subscription, RISE {#three-procurement-paths}

SAP Business AI can be procured via three distinct commercial paths. The choice of procurement path affects not only price but also contract conditions, term commitment, and bundling options.

Standalone Contract

With the standalone path, the customer purchases AI Units directly via an independent BTP contract in the Global Account. This model offers the least commitment but typically the highest per-unit price.

The standalone path is relevant for organizations without an active SAP Cloud ERP Private or RISE contract that want to explore or scale individual AI use cases without entering a broader subscription. It also works for clearly defined pilot projects with a fixed time horizon.

The commercial constraint: standalone AI Units do not benefit from bundling. Organizations purchasing AI Units within a Cloud ERP Private bundle typically receive a better per-unit price than a standalone purchase (source: SAP Licensing Experts, SAP AI in RISE Contracts 2026). Evaluating the standalone-versus-bundle economics before the annual budget cycle is a governance moment that directly affects the effective cost per use case.

Subscription via SAP Cloud Platform Enterprise Agreement

The Business AI Subscription Bundle is a standalone subscription package that bundles AI Units, Joule access, and AI Foundation access. It offers a lower per-unit price than the standalone option, at higher overall commitment.

This path fits organizations procuring SAP Business AI as a standalone initiative, independent of their cloud ERP contract structure. It is also the relevant model for customers who want to combine BTP services and AI capabilities without taking the full RISE contract path.

Inclusion in the RISE Contract

The commercially most efficient option is the inclusion of AI Units in an existing SAP Cloud ERP Private contract, formerly referred to as RISE with SAP. In this model, AI Units are either included as part of the cloud ERP bundle or acquired as an add-on under existing RISE terms.

AI Unit allocation within the RISE bundle is typically more cost-effective than standalone purchase because SAP cross-subsidizes AI consumption as part of the overall package. For organizations with an active RISE contract, this is typically the most economically advantageous starting point.

Which Path to Choose and When

Three guiding questions help with the decision.

First: does an active SAP Cloud ERP Private or RISE contract already exist? If so, the add-on route within that contract should be evaluated before a standalone path is chosen.

Second: what is the organization's hyperscaler footprint? AI Units can be procured via hyperscaler marketplaces (AWS, Azure, GCP), which can yield additional pricing advantages depending on existing cloud commitments.

Third: which term commitment makes sense? A standalone contract offers more flexibility; a bundle contract offers lower per-unit costs. The choice depends on the stability of the planned AI adoption and the strategic confidence about future usage volumes (source: Advisory Report, Negotiating SAP RISE Add-Ons).

---

What Is and Is Not Included in RISE {#what-is-and-is-not-included-in-rise}

The most frequent misperception among RISE customers: the RISE contract already covers Business AI in full. It covers part of it. What exactly depends on the tier, negotiated conditions, and the timing of contract signing.

Embedded S/4HANA AI Features by Tier

Some AI features are included in every SAP Cloud ERP Private tier without an additional AI Unit license. These typically include capabilities such as Predictive Accounting, Intelligent AP Automation, and Demand Sensing: capabilities that SAP positions as a baseline component of the solution subscription.

Which features are concretely included in a given contract is not readable from marketing materials but from the Order Form and its associated schedules. SAP changes the capability scope of included features in quarterly updates and repackaging cycles, without automatically notifying customers (source: SAP Licensing Experts, SAP AI in RISE Contracts 2026). Each such change is a governance moment.

Fixed Transaction Quotas and Their Limits

RISE contracts typically include fixed AI transaction quotas: in practice these sit at 10,000 to 50,000 AI transactions per month, depending on tier (source: SAP Licensing Experts). These quotas are adequate for initial orientation, but structurally insufficient for production AI adoption across larger user populations.

The quota limits are deliberately narrow: they are the entry point, not the operating framework. Organizations that actually scale AI in production will regularly exceed these limits and require add-ons.

Joule View-Only Access as Default

The standard RISE contract includes Joule with a view-only access mode and limited daily conversation sessions: typically 10 to 20 sessions per user per month. This access is not adequate for production use that goes beyond occasional individual queries.

Production-grade Joule deployment requires Power User Seats as an add-on, with their own per-user-per-month price points (source: SAP Licensing Experts, SAP AI in RISE Contracts 2026). This connection is frequently not transparent in initial RISE contract negotiations, because marketing presents Joule as a RISE component without making the functional limits of the base scope explicit. Recognizing this as a governance moment before signing protects the budget.

Add-On Components

Beyond the base scope, the following components are among those available as add-ons: Joule Power User Seats, Joule API Consumption for embedding in custom applications, BTP AI Core and AI Launchpad as standalone BTP services, AI Foundation model access with token-based pricing, and additional AI Units at the contractual per-unit price.

Each of these add-ons has its own pricing parameters and its own term conditions. In negotiations, it is advisable to identify the required add-ons early and to clarify their conditions within the same negotiation cycle as the main contract.

Module Activation as a License Trigger

A mechanism frequently overlooked in practice: activating certain SAP modules within a RISE contract can trigger new AI licensing obligations. Modules such as SAP IBP (Integrated Business Planning) or Treasury contain AI capabilities that are not included in the standard subscription and must be separately licensed.

In concrete terms: an organization that activates new modules as part of its RISE migration can unintentionally trigger new licensing obligations if the AI components of those modules were not assessed in advance (source: SAP Licensing Experts, SAP AI in RISE Contracts 2026). This risk is particularly relevant for expansion projects that introduce new SAP modules into production operations. Module activation is therefore a governance moment that requires an AI license check, not just a technical change request.

---

Overage Mechanics and the Aggregation Trap {#overage-mechanics-and-the-aggregation-trap}

Overage is not an exceptional case in SAP Business AI contracts. It is a structurally embedded mechanism whose conditions are stated in the Order Form, but often become visible only at the next invoice.

What Happens at Overconsumption

Once the contractually fixed AI Unit allowance is exceeded, the overage clause of the Order Form applies. SAP typically provides for tiered factors: consumption up to 20 percent above the allowance is generally without surcharge. Between 21 and 50 percent above the allowance, 1.5 times the contract rate typically applies. Beyond 50 percent overconsumption, two to four times the contract rate or a service suspension are possible, depending on contract wording (source: SAP Licensing Experts, Negotiating SAP AI Contracts).

The wording in the Order Form is decisive: "soft overage" without a cap means consumption can continue without automatic notification or approval requirements. "Hard overage" with service suspension means productive AI services are interrupted when the allowance is exhausted. The formulation of the overage clause and an explicit cap agreement are therefore among the most important negotiation elements in an AI contract. These are governance moments that must be addressed at signing, not after the first invoice.

How SAP Consumption Projections Typically Work

SAP delivers sizing assumptions in contract negotiations that are based on copilot usage rates. These projections assume gradual user acceptance and typical copilot conversation lengths.

In practice, agentic deployments, meaning the use of Joule agents for autonomous process chains, can consume three to twenty times the AI Units compared to the original sizing assumptions (source: SAP Licensing Experts, Negotiating SAP AI Contracts). Organizations shifting from pure copilot usage to agent-based workflows should actively adjust their contractual baseline before the rollout begins. The decision to move an agent into production is a governance moment: it is the point at which the original sizing assumptions should be formally re-evaluated and, if necessary, renegotiated.

The Aggregation Trap in Multi-Pool Consumption

A standard clause present in many RISE contracts: SAP counts AI consumption across all system environments of a customer, meaning development, test, and production environments, against the monthly allowance.

For organizations with active S/4HANA system landscapes across multiple environments, this means development and test activities with AI features are counted against the same allowance as production. Organizations unfamiliar with this clause encounter unexpectedly high consumption figures without the production system being the sole cause (source: SAP Licensing Experts, SAP AI in RISE Contracts 2026).

The negotiation option: a dev/test exclusion from AI Unit counting is negotiable and should be reviewed at every new contract negotiation or renewal.

Embedding Licenses and Royalty Fees

A separate cost dimension arises when Joule capabilities are embedded in custom applications. Organizations integrating the Joule API in a customer-built frontend need, in addition to AI Units, a separate embedding license. This functions as a royalty fee on the use of the Joule API in non-SAP surfaces.

For architecture decisions, the alternative of a custom LLM architecture with direct model access versus embedded Joule API has a cost dimension that should be fully reflected in investment planning.

---

EU AI Act: Effect from August 2026 {#eu-ai-act-effect-from-august-2026}

The EU AI Act entered into force in August 2024. The decisive full-effect stage for high-risk AI systems takes effect on 2 August 2026. For organizations deploying SAP Business AI in production processes, concrete documentation and governance obligations arise from this date.

Timeline and Scope

The implementation of the EU AI Act proceeds in stages.

The law entered into force in August 2024. Prohibitions on unacceptable AI practices became effective in February 2025. Regulations for General Purpose AI Models (GPAI) became applicable in August 2025. Full effect for high-risk AI systems takes effect on 2 August 2026. A further stage follows in August 2027 for systems under certain Annex III categories (source: European Commission AI Act Regulatory Framework, SAP Trust Center EU AI Act Compliance).

The scope of the EU AI Act is broad: it applies to all AI systems deployed in the EU, regardless of where the provider is headquartered. US-based organizations with EU operations are equally affected (source: Holland and Knight, US Companies Face EU AI Act's August 2026 Compliance Deadline).

What Qualifies as High-Risk

For SAP customers, four categories of high-risk AI systems listed in Annex III of the EU AI Act are particularly relevant.

First, HR systems: AI features in SuccessFactors that support candidate screening or performance evaluation can be classified as high-risk.

Second, credit scoring and financial decisions: AI features in Finance modules of S/4HANA that feed into credit or risk assessments potentially fall under this category.

Third, critical infrastructure: AI capabilities in Procurement and Supply Chain solutions can be relevant for critical infrastructure contexts.

Fourth, worker management: AI capabilities that evaluate or steer the working time or performance of employees.

The decisive point: the customer is responsible as the deployer of these systems, not SAP as the provider. SAP's certifications cover the provider obligations. The deployer obligations rest with the customer (source: SAP Trust Center).

SAP Certifications

SAP has obtained relevant certifications for its AI services.

ISO/IEC 42001 is the international standard for AI Management Systems. SAP is, according to its own communication, among the first major companies globally to hold this certification. It covers governance, risk management, deployment, monitoring, and continuous improvement for SAP's own AI processes.

SOC 2 Type II audits cloud security of AI services on a 12-month audit cycle. Complementing this are ISO 27001 for Information Security Management and the EU-US Data Privacy Framework for transatlantic data transfers.

An important practical qualification: SAP's certifications cover SAP's provider obligations, not the customer's deployer obligations. Customers must separately document and demonstrate their own AI management processes.

AI Agent Hub as a Compliance Tool

The SAP AI Agent Hub (GA Q3 2026) is not only an operational tool but primarily a compliance instrument. Its capabilities directly address EU AI Act requirements.

Discovery creates the inventory of all agents in the tenant, required for the EU AI Act registration obligation. Verification ensures agents are authorized and operate under defined policies. Observability delivers logging and monitoring required for high-risk systems under Article 12 of the EU AI Act. Policy Definition defines human oversight mechanisms that are mandatory for high-risk systems (source: SAP Trust Center, SAP Insider Sapphire 2026 AI Agent Guardrails).

Each of these functions represents a governance moment for any organization approaching the August 2026 deadline.

What Customers Must Document Themselves

SAP's certifications and the AI Agent Hub are prerequisites but are not sufficient. As the deployer, customers must maintain for each production AI use case classified as high-risk: a complete conformity assessment prior to commissioning, technical documentation of the system, an established risk management system, defined human oversight mechanisms, active logging and monitoring, and retention periods for AI-relevant logs.

For organizations operating or planning multiple AI use cases in production, a structured inventory of all use cases with risk classification is the practically sound first step. Without this foundation, a compliance assessment is not possible (source: Secure Privacy, EU AI Act 2026 Compliance).

---

Data Sovereignty, IP Indemnification, Tenant Isolation {#data-sovereignty-ip-indemnification-tenant-isolation}

Beyond regulatory compliance, SAP Business AI touches three core contractual questions: who sees which data, what does SAP guarantee on IP infringement, and what applies for specific industries?

Who Sees Which Data

SAP Business AI processes customer data on the basis of the standard AI Terms included in every SAP cloud contract. The relevant statements:

Customer business data remains in the customer tenant. SAP does not access it except for agreed operational processes. Prompts that users send to foundation models via Joule are routed through the Generative AI Hub, which abstracts the model API. SAP's contract with the respective model provider governs data use on the provider side.

The point that matters for customers: SAP does not use customer data to train proprietary models. This commitment is anchored in the standard AI Terms as the basis on which customers can deploy sensitive business data in AI workflows. It applies to SAP-proprietary models, not unconditionally to all external models offered via the GenAI Hub. The contract terms of the respective model provider should be separately reviewed for sensitive data categories (source: SAP Trust Center).

IP Indemnification: What SAP Commits to and What It Does Not

IP indemnification is the contractual assurance that SAP accepts liability for potential intellectual property infringements by the AI systems or holds the customer harmless.

What SAP standardly commits to: indemnification for IP infringements by SAP-proprietary models (SAP-ABAP-1, SAP-RPT-1). For certain third-party models in the GenAI Hub, extended indemnification can be negotiated, but this is not standard.

What SAP does not commit to: IP indemnification for output produced by agents that the customer develops using Joule Studio. Indemnification for violations of sector-specific regulation such as the Medical Device Regulation.

The practical consequence: for use cases with high output risk, for example in pharmaceuticals, the legal sector, or financial services, explicit IP clauses should be anchored in the Order Form (source: SAP Governance KB).

Industry-Specific Requirements

Beyond the general EU AI Act requirements, additional compliance obligations exist in regulated industries.

In financial services, BaFin, EBA, and FINMA require an AI use case inventory, explainability for credit and risk assessments, and DORA compliance (Operational Resilience) for AI services.

In pharma and life sciences, GxP validation is required for AI components deployed in GxP-regulated processes. For medical software, the Medical Device Regulation (MDR) applies.

In defense and critical infrastructure, NIS-2 requirements apply to AI components, alongside sovereignty requirements that may mandate EU-based cloud processing.

In the public sector, BSI requirements apply and the C5 attestation for cloud services can be extended to AI services (source: SAP Governance KB).

SAP provides no generic industry certification for Business AI. Each customer must independently demonstrate sector-specific compliance based on SAP's Trust Center documentation and a proprietary AI governance framework. For organizations in regulated industries, the entry into production with each new AI use case is a governance moment that triggers a sector-specific compliance check before go-live.

---

What to Review Before Negotiation {#what-to-review-before-negotiation}

Organizations entering a negotiation on SAP Business AI without knowing their own starting position negotiate from a structurally weaker basis. The following five steps structure the preparation.

Step 1: Quantify Three-Pool Consumption in the Existing Portfolio

Before any negotiation begins, the current consumption position across all three pools should be known: how many AI Units were consumed in the last contract year, and how many expired? How does BTP Capacity Unit consumption compare to the annual allocation? Is there active BDC usage, and if so, at what volume?

This baseline is the foundation for every sizing discussion. Without it, the risk is significant of purchasing an allowance that is either too large (and therefore subject to expiry) or too small (and therefore subject to overage risk).

Step 2: Select the Contract Path

In the second step, the appropriate procurement vehicle is established. Is there an active SAP Cloud ERP Private or RISE contract? If so, the add-on path within that contract is typically more economically advantageous than a standalone purchase.

At the same time, the possibility of a hyperscaler marketplace path should be assessed. For organizations with existing cloud commitments on AWS, Azure, or GCP, this path can reduce the effective AI Unit rate substantially (source: Advisory Report, Negotiating SAP RISE Add-Ons).

Step 3: Identify the Relevant Order Form Sections

Not the master agreement document but the Order Form is the binding commercial foundation. For SAP Business AI, the following Order Form sections are particularly relevant.

The BTP Entitlements Exhibit shows which AI Unit allocation is included in the contract and under which tiers it applies. The AI Units Exhibit governs the per-unit price, whether it is fixed or left open via reference to "current pricing." The capability list names which capabilities are contractually guaranteed. The overage clause defines factors, cap, and escalation mechanism. Rollover provisions specify whether and how many AI Units can be carried over. The Aggregation Scope clause defines whether dev/test environments are included in allowance counting (source: SAP Licensing Experts, Negotiating SAP AI Contracts).

Step 4: Assess Governance Requirements per Use Case

For each planned production AI use case, a baseline classification should be in place before contract signing: does the use case fall under the EU AI Act as a high-risk system? Which data categories are processed? Is human oversight defined?

This classification determines whether the AI Agent Hub must be planned from the outset and what documentation obligations arise. It also shapes the contract language: IP indemnification clauses and logging requirements should be negotiated before contract signing, not after.

Step 5: Clarify Expiry and Forecasting Logic

In the final preparation step, the forecast basis is aligned with SAP. What sizing assumptions underlie the offer? Are these assumptions calculated on a copilot basis or an agent basis? How does the planned rollout timeline differ from the sizing assumption?

Organizations that clarify these questions before the negotiation have a well-founded basis for the discussion on allowance size, rollover clauses, and potential adjustment mechanisms in the contract. The 90-day window before SAP issues a renewal offer is itself a governance moment: this is when the organization's own data position must be complete. A rollover right of 10 to 20 percent of unused AI Units is achievable in many negotiations but is not standard and must be explicitly included in the Order Form.

---

FAQ {#faq}

What is an AI Unit and how is it consumed?

An AI Unit is SAP's consumption-based metering unit for Business AI services. Customers purchase a prepaid annual allowance. Every AI service call, whether a Joule conversation, an embedded Finance capability, or an agent execution, consumes a defined number of AI Units, published by SAP in conversion factors per service. Unused AI Units expire at the end of the contract year unless an explicit rollover clause is agreed in the Order Form (source: SAP Help Portal, Metering and Pricing).

How do PUPM requests work and can they be pooled?

PUPM packages (Per-User-per-Month) assign each user a fixed monthly request allowance via SAP Identity Service. Unused allowances can be redirected within a package to other users in the same package; this is the permitted pooling. Cross-package pooling is not available. All allowances in a PUPM package expire at month-end without carryover (source: SAP Learning, PUPM Pricing Model).

What Business AI is already included in a RISE contract?

A RISE or SAP Cloud ERP Private contract typically includes certain embedded AI features such as Predictive Accounting and Intelligent AP Automation, fixed transaction quotas, and a Joule view-only access with limited conversation sessions. This base scope is not adequate for production AI adoption across larger user populations. Joule Power User Seats, additional AI Units, and extended capability packages are add-ons (source: SAP Licensing Experts, SAP AI in RISE Contracts 2026).

How do AI Units, Capacity Units, and BDC differ?

AI Units are the consumption unit for Business AI services such as Joule and AI Core. Capacity Units (CU) are the consumption unit for BTP platform services such as Integration Suite, application development, and database services. BDC Credits measure data volume and data products in the Business Data Cloud. The three pools are not interchangeable, are measured separately, and are procured separately (source: SAP Help Portal).

What changed after the discontinuation of Premium Plus?

SAP discontinued RISE with SAP Premium Plus in June 2025. The former top tier RISE was renamed SAP Cloud ERP Private. AI capabilities previously included in Premium Plus were partly elevated into Cloud ERP Private and partly repositioned as separate add-ons. In particular, Embedded AI Units are no longer automatically included in Cloud ERP Private but must be separately acquired. Existing customers with old Premium Plus contracts should assess what changed in the repackaging (sources: Redress Compliance, CIO Magazine).

What is the aggregation trap and how should it be handled?

The aggregation trap refers to the SAP standard contract clause by which AI consumption across all system environments, meaning development, test, and production, is collectively counted against the monthly allowance. Organizations running active AI features in non-production environments can generate unexpectedly high consumption. A dev/test exclusion from AI Unit counting is negotiable and should be reviewed at the next contract negotiation or renewal (source: SAP Licensing Experts).

Which foundation models are available in the GenAI Hub?

The Generative AI Hub provides access to foundation models from multiple providers, including SAP-proprietary models for ABAP development and process contexts as well as models from major external providers. Available models vary by region, contract version, and SAP release cycle. SAP updates the model portfolio on a rolling basis. For governance purposes, the current model list should be drawn from SAP documentation, not from marketing material (source: SAP Help Portal, Generative AI Hub).

What is the difference between Skills and Agents in Joule?

A Joule Skill is a deterministic, predefined operation that executes a single action. A Joule Agent is an autonomous system that orchestrates multiple skills, develops a plan, and executes it independently. The consumption difference is substantial: agents consume significantly more AI Units in complex multi-step plans than individual skill calls. This distinction is central for budget planning and sizing (source: SAP Learning, Introducing Joule Agents).

What changes on 2 August 2026 with the EU AI Act?

On 2 August 2026, the full effect of the EU AI Act for high-risk AI systems takes effect. Organizations operating AI systems in high-risk categories in production must from this date be able to demonstrate a completed conformity assessment, full technical documentation, an established risk management system, defined human oversight mechanisms, and active logging and monitoring. As the deployer of these systems, the responsibility rests with the customer, not with SAP as the provider (source: European Commission, SAP Trust Center).

Will my data be used to train SAP-proprietary AI models?

According to SAP standard AI Terms, customer business data is not used to train SAP-proprietary models. This commitment is anchored in the AI Terms of the SAP cloud contract. For external foundation models offered via the Generative AI Hub, the contract between the model provider and SAP applies. For sensitive data categories, an explicit review of the data protection clauses of the respective model provider is advisable (source: SAP Trust Center, Data Sovereignty).

What does SAP Business AI cost in practice?

SAP does not publish a public AI Unit price list. The effective per-unit price depends on the chosen procurement path, contract size, and individually negotiated conditions. As an orientation: standalone BTP contracts typically carry the highest per-unit price. RISE or Cloud ERP bundle contracts typically offer more favorable conditions. The SAP AI Pricing Estimator in the Discovery Centre provides volume estimates, not euro amounts. Actual costs emerge only from the per-unit price fixed in the Order Form (source: SAP Pricing Page, SAP Licensing Experts).

Does SAP Business AI require its own governance capability?

For production AI use cases in regulated areas or with high-risk classification under the EU AI Act, a dedicated governance capability is required. Without structured inventory, classification, and observability of the AI systems deployed, neither compliance requirements can be met nor can consumption and cost development be steered in a plannable way. The SAP AI Agent Hub (GA Q3 2026) provides a technical foundation. The organizational anchoring of the governance capability rests with the customer.

---

Next Steps {#next-steps}

Organizations that want to assess their SAP Business AI contract structure systematically have three options.

The Contract Check delivers, within four weeks, a complete analysis of the current SAP contract portfolio, including AI Unit allocation, overage risks, and concrete recommendations for the next negotiation. Fixed price, independent.

The FinOptory AI Chat provides an initial assessment of the AI contract component based on a brief description of the current situation, without file upload. It is suited as a first orientation point when a full analysis is not yet planned.

For the broader context: Pillar 1 of this series covers SAP Contract Governance across the full SAP portfolio, across all nine product types, and across the full contract lifecycle.

---

Sources: SAP News (Sapphire 2026), SAP Help Portal (Metering and Pricing), SAP Pricing Page, SAP Learning (PUPM Model, Joule Studio), SAP Trust Center (EU AI Act, Data Sovereignty), European Commission (AI Act Regulatory Framework), SAP Licensing Experts (AI in RISE, AI Units, Negotiating AI Contracts), Advisory Report (Negotiating SAP RISE Add-Ons), Redress Compliance (RISE Premium Packaging Changes), CIO Magazine (SAP RISE rebrand), NextLytics (DSAG Technology Days 2026), Holland and Knight (EU AI Act August 2026), SAP Insider (Sapphire 2026), ERP Today (Sapphire 2026), SAVIC Technologies (AI Foundation Architecture, Joule Studio 2026), Secure Privacy (EU AI Act 2026 Compliance), SAP Community Blog (TDD AI Unit SKU)