Kann ich ungenutzte Capacity Units für AI-Services verwenden?

Nein. AI Units und Capacity Units sind nicht austauschbar. Ein bestehendes BTPEA-Guthaben kann nicht für Joule-Konversationen oder AI-Core-Aufrufe genutzt werden.

Was ist der Unterschied zwischen AI-Unit-Kontingent und PUPM-Paketen?

Das AI-Unit-Kontingent ist ein Prepaid-Jahreskontingent. PUPM-Pakete sind monatliche Request-Quoten pro Nutzer, nach Line-of-Business geschnitten. PUPM-Requests verfallen monatlich, AI Units jährlich.

Drei Verbrauchstöpfe bei SAP Business AI: Was AI Units, Capacity Units und BDC Credits unterscheidet

SAP Business AI rechnet über drei getrennte Verbrauchstöpfe ab: AI Units für generative AI-Funktionen, Capacity Units für klassische SAP-AI-Services und BDC Credits für die Business Data Cloud. Was zusammengeht, was nicht, wo Pooling möglich ist und wo Investments verfallen.

Warum drei Töpfe und nicht einer

Wer SAP Business AI heute in einem Vertrag steuern will, begegnet einem Sachverhalt, der in den meisten initialen Verhandlungen nicht explizit adressiert wird: Das, was SAP unter dem Dachbegriff "Business AI" vermarktet, teilt sich in drei separate Verbrauchsmodelle auf, die weder aggregiert noch gegenseitig angerechnet werden können.

Diese Trennung ist kein Versehen. Sie ist das Ergebnis einer gewachsenen Produktarchitektur. BTP-Plattformdienste wurden historisch über Capacity Units abgerechnet, lange bevor generative AI-Funktionen existierten. SAP Business AI als Servicekategorie wurde mit eigenen AI Units ausgestattet, weil die Pricing-Logik eine andere ist: nicht Plattformkapazität, sondern AI-Serviceverbrauch. Die Business Data Cloud wiederum ist als separate Datenebene entstanden und bringt ihre eigene Abrechnungslogik mit.

Das hat für die Vertragssteuerung eine direkte Konsequenz: Wer ein BTP Enterprise Agreement mit verbleibendem Guthaben an Capacity Units hat, kann damit keine Joule-Konversationen oder AI-Core-Aufrufe finanzieren. Wer AI Units gekauft hat, kann damit keine Integration-Suite-Services betreiben. Jeder Topf bleibt in sich geschlossen. Forecasting, Budgetallokation und Monitoring müssen pro Topf separat aufgebaut werden. Das ist der erste Steuerungsmoment, an dem eine unzureichende Topf-Kenntnis zu Fehlinvestitionen führt.

Der DSAG-Arbeitskreis Lizenzen hat diese Topf-Trennung 2026 als strukturelle Komplexität benannt, die den Einstieg in SAP Business AI erschwert und eigenständige Governance-Kapazitäten voraussetzt (Quelle: NextLytics, DSAG Technology Days 2026).

Topf 1: AI Units

AI Units sind die zentrale Verbrauchseinheit für SAP Business AI Services. SAP definiert sie als "konsumbasierte virtuelle Währung, mit der SAP Business AI Services übergreifend genutzt werden können" (Quelle: SAP Pricing Page). Kunden kaufen ein Prepaid-Jahres-Kontingent. Jeder AI-Serviceaufruf zieht eine vertraglich definierte Anzahl AI Units, abhängig vom genutzten Service.

Konsumiert werden AI Units über SAP S/4HANA Cloud (eingebettete AI-Features), SuccessFactors, Ariba, SAP Build mit Joule-Funktionen sowie BTP-Services wie AI Core und den Generative AI Hub. Der Konversionsfaktor variiert je nach Service erheblich: Joule Messaging verbraucht 7 AI Units pro 10.000 Nachrichten, Document Grounding 0,005 AI Units pro Record. Bei Aufrufen über den Generative AI Hub wird Token-Verbrauch als Basismetrik gemessen und anschließend in AI Units umgerechnet; die Spannweite ist modellabhängig (Quelle: SAP Help Portal, Metering and Pricing for SAP AI Core).

Die Pricing-Logik bei AI Units folgt einem Prepaid-Modell, das zwei Steuerungsmomente erzeugt. Erstens: Nicht verbrauchte AI Units verfallen am Ende des Vertragsjahres, sofern keine explizite Rollover-Klausel im Order Form vereinbart wurde. DSAG-Daten zeigen, dass 80 Prozent der RISE-Kunden im zweiten Vertragsjahr ungenutzte AI-Credits haben, weil die tatsächliche AI-Adoption typischerweise hinter den ursprünglichen Nutzungsprojektionen zurückbleibt. Zweitens: Wer das Kontingent überschreitet, greift in die Overage-Logik des Order Forms, die je nach Formulierung das Zwei- bis Vierfache der Vertragsrate kosten kann.

Neben dem klassischen Kontingentmodell bietet SAP ein zweites Abrechnungsmodell für AI Units an: PUPM-Pakete (Per-User-per-Month). Hierbei wird jedem Nutzer über den SAP Identity Service ein Paketslot zugeordnet, der ein fixes Request-Kontingent pro Monat enthält. Innerhalb eines Pakets können nicht genutzte Kontingente eines Nutzers von anderen Nutzern desselben Pakets genutzt werden. Das ist das erlaubte Pooling. Paketübergreifendes Pooling ist nicht vorgesehen. Alle nicht genutzten Kontingente verfallen am Monatsende.

Die PUPM-Pakete sind nach Lösungsbereichen strukturiert: Finance, Spend Management, Customer Experience, Human Capital Management. Wer Joule-Funktionen für mehrere Bereiche einsetzen möchte, benötigt für jeden Bereich ein eigenes Paket. Ein Nutzer in zwei Paketen zahlt zweimal. Es gibt keinen Querausgleich zwischen Paketen.

Für die Vertragssteuerung gilt damit: AI Units sind der ausgeprägteste Steuerungsmoment im SAP-Business-AI-Vertragsportfolio, weil ihre Mechanik, ihr Verfall und ihr Pooling-Verhalten den größten Einfluss auf die Budgetplanbarkeit haben.

Topf 2: Capacity Units

BTP Capacity Units (CU) sind die Verbrauchseinheit für BTP-Plattformdienste. Sie finanzieren Infrastruktur, nicht AI-Funktionalität. Bezogen werden sie über das BTP Enterprise Agreement (BTPEA) oder das Cloud Platform Enterprise Agreement (CPEA).

Die Abgrenzung zu AI Units ist präzise: Capacity Units decken Integration Suite, Application Development, Datenbankservices, Analytics und vergleichbare Plattformdienste ab. AI Units decken die AI-Funktionsebene auf dieser Plattform ab. Beide Töpfe laufen gleichzeitig und separat (Quelle: SAP Help Portal, Metering and Pricing for SAP AI Core).

Für die Vertragssteuerung bedeutet das eine häufige Quelle für Fehleinschätzungen: Ein Unternehmen mit aktivem BTPEA und wachsendem AI-Bedarf kann nicht einfach auf das vorhandene Capacity-Unit-Guthaben zurückgreifen, um AI-Funktionen zu finanzieren. Es muss einen separaten AI-Unit-Vertrag schließen oder AI Units als Add-On erwerben. Die Steuerungsmomente im Bereich Nutzung und Kosten treffen hier zusammen: Wer Capacity Units und AI Units nicht getrennt monitort und forecastet, baut ein Budgetbild auf, das die tatsächliche Verbrauchsstruktur nicht abbildet.

Die Capacity Units sind in der Praxis der stabilere Topf, weil ihr Verbrauchsprofil enger mit planbaren Plattformnutzungen verknüpft ist. KI-intensive Agenten-Workflows verändern dieses Profil jedoch, weil sie sowohl Plattforminfrastruktur als auch AI-Services konsumieren und damit beide Töpfe gleichzeitig beanspruchen.

Topf 3: BDC Credits

Die Business Data Cloud (BDC) ist SAPs Datenebene. Sie verbindet SAP- und Nicht-SAP-Daten über ein Delta-Sharing-Protokoll und stellt die Grundlage für den SAP Knowledge Graph, für Company Memory und für das unternehmenseigene Prozess- und Richtlinienwissen bereit, das Joule und Agenten als Kontext nutzen.

Die BDC wird über eine eigene BDC-Subscription lizenziert. Die Abrechnung erfolgt über separate Credits, deren Bemessung von Datenvolumen, Delta Sharing und eingesetzten Data Products abhängt. Diese Credits sind weder mit AI Units noch mit BTP Capacity Units verrechenbar.

Der Steuerungsmoment bei BDC Credits liegt häufig in einem blinden Fleck: Viele Organisationen, die Joule mit Custom Model Grounding oder unternehmenseigenem Kontext nutzen wollen, aktivieren damit automatisch den BDC-Topf, ohne dass dieser in der initialen Vertragsplanung explizit berücksichtigt wurde. BDC wird in Verhandlungen häufig als separates Line Item behandelt, das erst dann sichtbar wird, wenn ein konkreter AI-Use-Case auf firmeneigenes Wissen zugreifen soll.

Für die Governance-Ebene gilt: Die BDC ist der Datenbaustein, ohne den eine unternehmensindividuelle AI-Governance systematisch schwieriger wird. Wer AI-Agenten mit verlässlichem, unternehmenseigenem Kontext betreiben will, sollte den BDC-Topf von Anfang an in die Beschaffungsplanung einbeziehen, nicht nachträglich als Add-On (Quelle: SAP Help Portal, Business Data Cloud Metering).

Wo die Töpfe zusammentreffen

In der Praxis greifen AI-Use-Cases häufig auf mehr als einen Topf zu. Das ist der Sachverhalt, der in der Governance am schwersten zu steuern ist.

Ein Joule-Agent, der Geschäftsdaten aus der Business Data Cloud abruft, auf BTP-Laufzeit ausgeführt wird und dabei ein Foundation Model im Generative AI Hub aufruft, erzeugt gleichzeitig AI-Unit-Verbrauch, Capacity-Unit-Verbrauch und BDC-Credit-Verbrauch. Diese drei Verbrauchsströme werden in unterschiedlichen SAP-Tools angezeigt, mit unterschiedlichen Reporting-Rhythmen und unterschiedlichen Schwellenwerten. Eine konsolidierte Sicht auf den Gesamt-AI-Verbrauch ist mit nativen SAP-Werkzeugen derzeit nicht herstellbar, weil die Tools pro Topf, nicht pro Use Case berichten (Quelle: NextLytics, DSAG Technology Days 2026).

Das führt zur sogenannten Aggregations-Falle: SAP zählt den AI-Verbrauch über alle Systemumgebungen eines Kunden hinweg auf das monatliche Kontingent an, also über Entwicklungs-, Test- und Produktivsysteme gemeinsam. Wer AI-Features in Nicht-Produktivumgebungen betreibt, erzeugt Verbrauch gegen dasselbe Kontingent wie das Produktivsystem. Kombiniert mit einem Multi-Topf-Use-Case kann das zu unerwartet hohen Verbräuchen führen, die sich aus den nativen Reporting-Werkzeugen nicht ohne weiteres rekonstruieren lassen.

Hier liegen mehrere Steuerungsmomente übereinander: im Bereich Nutzung (welche Systemumgebungen konsumieren was), im Bereich Kosten (welcher Topf erzeugt Overage) und im Bereich Infrastruktur (wie ist die Systemlandschaft aufgebaut und wie wird sie gegen den Vertragsrahmen vermessen). Wer diese Momente ohne eigenständige Governance-Funktion überwacht, verlässt sich auf Aggregationsdaten, die zu spät kommen.

Die strukturelle Empfehlung für jede Organisation, die AI-Use-Cases über die erste Pilotphase hinaus skaliert: Pro aktivem Use-Case sollte vor dem Rollout eine Topf-Zuordnung vorliegen. Welche AI Units, welche Capacity Units, welche BDC Credits werden pro Monat verbraucht? Diese Frage frühzeitig zu beantworten, macht die Budgetallokation belastbarer und den Steuerungsmoment beim Renewal kalkulierbar.

Pooling, Rollover, Verfall im Vergleich

Die folgende Übersicht fasst die Kernparameter der drei Töpfe zusammen.

Parameter	AI Units	Capacity Units	BDC Credits
Abrechnungsmodell	Prepaid-Kontingent pro Jahr	Prepaid-Kontingent, rollierend	Subscription-basiert, nutzungsabhängig
Pooling	Innerhalb eines PUPM-Pakets möglich; paketübergreifend nicht	Pauschal pro Global Account; kein Use-Case-Pooling	Kein Pooling über Subscriptions hinweg
Monatsverfall	PUPM-Request-Kontingente verfallen monatlich	Nein	Nein
Jahresverfall	Ja (Standard); Rollover verhandelbar	Laufzeitgebunden; bei Vertragsverlängerung anpassbar	Subscription-periodisch
Rollover	Nicht Standard; 10-20% in vielen Verhandlungen erreichbar	Nicht anwendbar in gleicher Form	Nicht vorgesehen
Cross-Pool-Verbrauch	Nicht möglich	Nicht möglich	Nicht möglich
Overage-Logik	Ja, 1,5-4x Vertragsrate je nach Klausel	Ja, vertragsspezifisch	Ja, nach BDC-Subscription-Bedingungen
Native Monitoring-Tiefe	Aggregiert (SAP for Me); keine Nutzer-Granularität	Subaccount-Level (BTP Cockpit)	BDC-Cockpit; Use-Case-Granularität eingeschränkt

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

Die Tabelle macht die zentrale Herausforderung sichtbar: In keinem der drei Töpfe bietet SAP heute eine Use-Case-genaue Verbrauchssicht, die einen direkten Abgleich mit dem Vertragsrahmen erlaubt. Das ist kein technisches Versehen, es ist eine strukturelle Grenze der nativen Werkzeuge, die der DSAG-Arbeitskreis Lizenzen als offene Forderung gegenüber SAP formuliert hat: "Wann kommt ein FinOps-Tool für Verrechnung, Metering und Forecasting auf AI-Ebene?" Stand Mai 2026 ist diese Forderung offen (Quelle: NextLytics, DSAG Technology Days 2026).

Für die Governance bedeutet das: Wer SAP Business AI über einen einfachen Piloten hinaus skaliert, kommt mit nativen Werkzeugen an die Grenze der Planbarkeit. Budgetallokation, Rollover-Verhandlungen und Overage-Steuerung setzen eine eigenständige Beobachtungsschicht voraus, die die drei Töpfe zusammenführt und gegen den Vertragsrahmen spiegelt.

Häufige Fragen

Können AI Units über Geschäftsjahre hinweg angespart werden?

Nicht im Standard. Ungenutzte AI Units verfallen am Ende des Vertragsjahres. Ein Rollover-Recht von 10 bis 20 Prozent der nicht genutzten AI Units lässt sich in vielen Vertragsverhandlungen einbringen, es ist aber keine Standardbedingung und muss explizit im Order Form verankert sein (Quelle: SAP Licensing Experts, AI Units Explained 2026).

Was passiert, wenn ein Nutzer in mehreren PUPM-Paketen registriert ist?

Der Nutzer zahlt für jedes Paket separat. Ungenutzte Kontingente aus einem Paket können nicht auf ein anderes Paket angerechnet werden. Das Cross-Package-Pooling ist in der PUPM-Logik nicht vorgesehen (Quelle: SAP Learning, Analyzing the PUPM Pricing Model).

Wann ist BDC in der Vertragsplanung relevant?

Immer dann, wenn Joule-Funktionen oder AI-Agenten mit unternehmenseigenem Kontext geerdet werden sollen, sei es über Custom Model Grounding, Company Memory oder den SAP Knowledge Graph. In diesem Moment wird BDC zu einem aktiven Verbrauchstopf, der separat beschafft und gesteuert werden muss.

Welches Tool gibt die konsolidierte Sicht über alle drei Töpfe?

Es gibt heute kein natives SAP-Tool, das alle drei Töpfe aggregiert und gegen den Vertragsrahmen spiegelt. SAP for Me zeigt aggregierten AI-Unit-Verbrauch, das BTP Cockpit zeigt Capacity-Unit-Verbrauch auf Subaccount-Ebene, das BDC-Cockpit berichtet BDC-Credits. Die Konsolidierung liegt beim Kunden und erfordert eine eigenständige Governance-Funktion.