Wie laufen SAP AI Units ab?

SAP Business AI Units (PUPM) verfallen in der Regel am Monatsende, nicht am Jahresende. Ungenutzte AI-Anfragen innerhalb eines Monats werden nicht in den Folgemonat übertragen.

Warum BTP Credits am Jahresende oft verfallen und was Sie dagegen tun können

Q: Was ist der Unterschied zwischen CPEA und BTPEA?

CPEA ist das ältere Vertragsmodell für BTP. BTPEA ist das aktuelle Nachfolgemodell. Beide arbeiten mit jährlichen Credit-Budgets, unterscheiden sich aber in Service-Katalog, Abrechnungslogik und der Behandlung von Restguthaben.

BTP-Credits verlieren ihren Wert, wenn sie nicht im Verbrauchszeitraum genutzt werden. Wer Verbrauch nicht laufend beobachtet, sieht den Verfall erst auf der Folgerechnung. Was technisch dahintersteckt, welche Konstellationen zu Verfall führen und wie laufende Beobachtung das Budget planbar hält.

Wie BTP-Credit-Verbrauch funktioniert

SAP Business Technology Platform wird über ein Credit-Modell konsumiert. Unternehmen, die BTP im Rahmen von RISE with SAP oder über ein eigenes BTP Enterprise Agreement (BTPEA) nutzen, erwerben ein jährliches Credit-Budget. Dieses Budget wird gegen den tatsächlichen Service-Verbrauch verrechnet: Jeder genutzte BTP-Service zieht Credits aus dem Jahresguthaben ab, wobei die Umrechnungsrate pro Service unterschiedlich hoch ist.

Das ältere Modell, das in vielen aktiven Verträgen noch relevant ist, heißt CPEA (Cloud Platform Enterprise Agreement). Bei CPEA gilt: Das Jahresguthaben ist für einen definierten Verbrauchszeitraum bestimmt. Was innerhalb dieses Zeitraums nicht verbraucht wird, verfällt. Ein Roll-over in das nächste Jahr ist im Standardmodell nicht vorgesehen, es sei denn, er wurde vertraglich vereinbart.

Die Burndown-Logik ist damit umgekehrt zu dem, was viele aus klassischem Lizenzmanagement kennen: Nicht die Über- oder Unternutzung von Nutzern wird gemessen, sondern der laufende Verbrauch von Services in Echtzeit. Je mehr Services aktiv genutzt werden, desto schneller sinkt das Credit-Guthaben.

Diese Logik erfordert eine andere Art der Beobachtung: Wer BTP-Verbrauch nur einmal jährlich prüft, hat keine ausreichende Grundlage, um auf Abweichungen zu reagieren.

Wo Credits typischerweise verfallen

Der häufigste Verfall-Zeitpunkt liegt am Ende des Vertragsjahres. Dort läuft das Guthaben aus, und nicht konsumierte Credits werden wertlos. In der Praxis sind dafür drei Konstellationen besonders häufig beobachtbar:

Ungeplante Service-Subscriptions. Unternehmen aktivieren BTP-Services für ein Projekt oder einen Pilot, der nicht vollständig umgesetzt wird. Die Service-Subscription läuft weiter, konsumiert Credits, erbringt aber keinen produktiven Gegenwert. Über ein Vertragsjahr summiert sich das.

Depreciation Groups und Service-Migration. SAP unterscheidet BTP-Services nach Deprecation Groups: Gruppe 1 umfasst stabile, langfristig unterstützte Services, Gruppe 2 enthält Services, die sich in Übergangs- oder Ablösephasen befinden. Services aus Gruppe 2 können während der Laufzeit abgekündigt werden. Wenn Nachfolge-Services andere Credit-Raten haben, entstehen Planungslücken, die erst beim nächsten Abrechnungsschnitt sichtbar werden.

Joule-Entitlements ohne aktive Nutzung. SAP Joule, der generative KI-Copilot, ist an die Premium Plus Lizenz gebunden. Die Entitlements laufen, sobald das Vertragswerk aktiv ist. Wer Joule noch nicht produktiv eingeführt hat, zahlt für Kapazitäten, die nicht genutzt werden.

Warum Verfall in der Praxis spät sichtbar wird

In den meisten SAP-Organisationen liegt die Verantwortung für Lizenzen und Vertragsmanagement in anderen Händen als die operative Verantwortung für BTP-Services. Die SAP-Basis-Abteilung oder die Cloud Center of Excellence-Einheit betreibt die Services, der SAP Contract Manager hält die Vertragsdetails, das Controlling sieht die Rechnungen. Diese drei Perspektiven arbeiten oft mit unterschiedlichen Rhythmen und Datenquellen.

Klassische Software-Asset-Management-Werkzeuge wurden für Lizenz-Metriken entwickelt, nicht für Credit-Verbräuche. Sie zeigen, wie viele Nutzer welche Berechtigungen haben, aber nicht, wie schnell ein BTP-Budget in welche Services fließt. Der Burndown-Verlauf, also die Kurve des Credit-Verbrauchs über die Zeit, ist in diesen Werkzeugen selten direkt ablesbar.

Hinzu kommt, dass SAP eigene Monitoring-Werkzeuge für BTP bereitstellt, deren Nutzung aktiv konfiguriert und gepflegt werden muss. Das SAP BTP Cockpit zeigt Verbrauchsdaten, allerdings auf Service-Ebene, ohne automatisch eine Burndown-Prognose für das Gesamtjahr zu errechnen. Wer diese Daten nicht regelmäßig aggregiert, sieht den Verfall-Trend erst dann, wenn der Handlungsspielraum im laufenden Jahr bereits eingeschränkt ist.

Ein weiterer Faktor: Die Meldepflicht bei Übernutzung liegt beim Kunden. Wer den Verbrauch nicht verfolgt, merkt Abweichungen nach oben wie nach unten erst mit Verzögerung. Bei Underuse bedeutet das verfallendes Budget; bei Overuse entstehen Verbrauchsgebühren, die im Standard mit einem Aufschlag belastet werden.

Wie laufende Beobachtung den Verfall verhindert

Laufende Beobachtung bedeutet in diesem Zusammenhang nicht permanente manuelle Prüfung, sondern ein strukturiertes Steuerungsmodell mit definierten Rhythmen und Schwellenwerten.

Schritt 1: Monatliches Burndown-Tracking etablieren. Ziehen Sie den BTP-Credit-Verbrauch einmal pro Monat als aggregierte Zahl heraus und vergleichen Sie ihn mit dem idealen Burndown: Jahresguthaben geteilt durch zwölf Monate ergibt den linearen Sollwert pro Monat. Liegt der tatsächliche Verbrauch dauerhaft unter diesem Sollwert, haben Sie einen Verfall-Indikator. Liegt er darüber, besteht das Risiko einer Overage.

Diese einfache Kennzahl, die Abweichung vom linearen Burndown, ist der wichtigste Frühindikator für beide Richtungen. Sie ersetzt keine detaillierte Service-Analyse, gibt aber das Signal, wann eine tiefere Analyse notwendig ist.

Schritt 2: Service-Mix regelmäßig prüfen. Mindestens einmal pro Quartal sollte der aktive Service-Katalog gegen den tatsächlichen Verbrauch gehalten werden. Services mit hohem Credit-Verbrauch und eingeschränkter produktiver Nutzung sind Kandidaten für Downsize oder Kündigung. Services aus Deprecation Group 2 sollten auf ihren Ablöseplan hin überprüft werden.

Schritt 3: Alerts und Schwellenwerte konfigurieren. Das SAP BTP Cockpit erlaubt die Konfiguration von Nutzungsbenachrichtigungen. Definieren Sie einen Warnschwellenwert für verbleibende Credits, zum Beispiel 30% Restguthaben, der ausreichend Zeit lässt, um entweder Verbrauch zu erhöhen oder mit SAP über Reallokation zu sprechen. Der Schwellenwert sollte so früh gesetzt werden, dass noch mindestens zwei Monate Steuerungsspielraum verbleiben.

Schritt 4: Reallokation vor Jahresende prüfen. Wenn im vierten Quartal absehbar ist, dass Credits nicht vollständig verbraucht werden, gibt es in der Regel einen Handlungsspielraum: Credits können auf nutzungsintensivere Services umgeschichtet werden, Pilotprojekte vorgezogen oder bestehende Services skaliert werden. Diese Optionen funktionieren aber nur, wenn der Verfall-Trend früh genug erkennbar ist. Im Dezember ist der Spielraum typischerweise bereits gering.

Verantwortlichkeit klären. Laufende BTP-Verbrauchssteuerung fällt in eine organisatorische Lücke: Sie ist zu operativ für das klassische Contract Management, zu strategisch für die IT-Basis, und zu SAP-spezifisch für ein generisches FinOps-Team. Sinnvoll ist eine explizite Zuordnung dieser Aufgabe, zum Beispiel an eine Cloud Center of Excellence-Funktion mit Reportingpflicht gegenüber dem Controlling.

Drei Indikatoren, dass Sie Verfall riskieren

Prüfen Sie die folgenden drei Punkte für Ihr laufendes BTP-Budget:

Burndown-Abweichung: Liegt Ihr kumulierter Credit-Verbrauch nach sechs Monaten unter 50% des Jahresguthabens? Wenn ja, besteht ein strukturelles Unterverbrauchsmuster.
Inaktive Service-Subscriptions: Haben Sie Services aktiv, die in den letzten drei Monaten keine messbaren Verbrauchsdaten erzeugt haben? Jede inaktive Subscription verbraucht Credits ohne produktiven Gegenwert.
Kein Burndown-Report vorhanden: Können Sie heute auf Anhieb zeigen, wie hoch Ihr verbleibendes Jahresguthaben ist und bis wann es aufgebraucht sein wird? Wenn nicht, fehlt die Steuerungsgrundlage.

Alle drei Indikatoren lassen sich mit vorhandenen BTP-Cockpit-Daten prüfen. Sie erfordern keine zusätzlichen Werkzeuge, aber eine klare Verantwortlichkeit für die Auswertung.

Weiterführende Informationen und nächste Schritte

Das Thema BTP-Credit-Steuerung ist Teil der breiteren SAP Contract Governance nach der Unterschrift. Wie CPEA, BTP Enterprise Agreement und RISE-Vertragslogik im Zusammenhang stehen, beschreibt der Pillar-Artikel SAP Contract Governance: Verträge nach der Unterschrift steuern.

Wenn Sie wissen möchten, wie Ihr aktuelles BTP-Budget aufgestellt ist, beantwortet FinOptory AI erste Fragen direkt: FinOptory AI. Für eine strukturierte Analyse Ihrer SAP-Verträge bietet FinOptory einen Vertragscheck als definierten Einstieg.

Häufig gestellte Fragen

Was passiert mit nicht genutzten BTP Credits am Jahresende? Bei CPEA-Verträgen verfallen nicht genutzte Credits am Ende des Verbrauchszeitraums. Ein automatischer Roll-over in das Folgejahr ist im Standard nicht vorgesehen. Ob eine Roll-over-Vereinbarung im Vertrag enthalten ist, lässt sich in den Contract Schedules prüfen. Quelle: SAP Help Portal, CPEA Vertragslogik; saplicensingexperts.com.

Was ist der Unterschied zwischen CPEA und BTPEA? CPEA (Cloud Platform Enterprise Agreement) ist das ältere Vertragsmodell für BTP, das in vielen laufenden Verträgen noch aktiv ist. BTPEA (BTP Enterprise Agreement) ist das aktuelle Nachfolgemodell. Beide arbeiten mit jährlichen Credit-Budgets, unterscheiden sich aber in Service-Katalog, Abrechnungslogik und der Art, wie Restguthaben behandelt werden. Bei einem bestehenden CPEA-Vertrag lohnt es sich, den Umstieg auf BTPEA im Rahmen des nächsten Renewals zu evaluieren. Quelle: SAP Community; saplicensingexperts.com.

Wie laufen SAP AI Units bei BTP ab, monatlich oder jährlich? SAP Business AI Units, die über den Generative AI Hub oder AI Services auf BTP konsumiert werden, folgen einer anderen Verbrauchslogik als das allgemeine CPEA-Guthaben. Per-User-Per-Month-Requests (PUPM) verfallen in der Regel am Monatsende, nicht am Jahresende. Das bedeutet, dass ungenutzte AI-Anfragen innerhalb eines Monats nicht in den Folgemonat übertragen werden. Wer AI-Services eingeführt hat, aber noch nicht im produktiven Betrieb ist, sollte die monatlichen Verbrauchsdaten gesondert beobachten. Quelle: SAP Community Blog; SAP Help Portal.

Wie verteile ich BTP-Kosten intern auf Projekte und Kostenstellen? BTP-Verbrauchsdaten lassen sich im SAP BTP Cockpit auf Subaccount-Ebene auswerten. Eine verursachergerechte Zuordnung zu Projekten oder Kostenstellen erfordert eine bewusste Subaccount-Struktur, in der BTP-Ressourcen je Geschäftsbereich oder Projekt in separaten Subaccounts betrieben werden. Diese Strukturentscheidung muss früh getroffen werden, da eine nachträgliche Reorganisation der Subaccount-Hierarchie aufwendig ist. Quelle: SAP Help Portal, BTP Account Model Documentation.