BTP Credits und CPEA: Was in RISE-Verträgen wirklich passiert

Viele SAP-RISE-Kunden entdecken dasselbe Muster erst nach einigen Betriebsmonaten: Der BTP-Credit-Pool am Ende des Jahres zeigt noch einen erheblichen Restbestand. Gleichzeitig übersteigen die tatsächlich genutzten BTP-Services die ursprünglich eingeplanten Kosten. Beides passiert im selben Unternehmen, manchmal sogar im selben Quartal.

Das klingt nach einem Widerspruch. Es ist keiner. Es ist das direkte Ergebnis unzureichender Steuerung: Credits laufen ungenutzt durch, während einzelne Services unkontrolliert Verbrauch aufbauen. In der Praxis sehe ich diese Kombination regelmäßig, und sie hat immer dieselbe Ursache.

Dieser Artikel ist der erste Teil der RISE Contract Anatomy-Serie. Wir beginnen mit BTP und CPEA, weil hier die finanziellen Auswirkungen am schnellsten spürbar werden und gleichzeitig am wenigsten transparent sind.

Was BTP Credits sind und warum sie verfallen

Im Rahmen von SAP RISE erhalten Unternehmen Zugang zur SAP Business Technology Platform. Die Grundlage für die Nutzung ist das CPEA-Modell (Cloud Platform Enterprise Agreement): ein vorab gekaufter Pool an Cloud Credits, der über eine definierte Laufzeit, typischerweise ein Jahr, für rund 85 bis 90 BTP-Services eingesetzt werden kann. Integration Suite, Build-Werkzeuge, Daten- und Analysedienste, KI-Dienste, alle ziehen ihren Verbrauch aus demselben Pool.

Das Modell klingt flexibel. Der Haken liegt im Verfallsdatum. Ungenutzte Credits verfallen am Ende der Vertragsperiode. Es gibt keinen automatischen Übertrag. Was bis zum Stichtag nicht verbraucht wurde, ist verloren. SAP sprach auf der Sapphire 2024 offen darüber: Der geschätzte Wert ungenutzter BTP-Credits beläuft sich branchenweit auf rund 600 Millionen US-Dollar pro Jahr (SAPinsider, 2024). Das ist kein Ausreißer. Es ist das strukturelle Ergebnis von Credit-Pools, die zu Vertragsbeginn konservativ bemessen wurden, und dann ohne aktive Steuerung laufen.

Gleichzeitig läuft auf der anderen Seite derselbe Mechanismus in umgekehrter Richtung. Overage, also Verbrauch über das Credit-Budget hinaus, wird zum vollen SAP-Listenpreis abgerechnet. Ausgehandelte Volumenrabatte können dabei entfallen. SAP stellt den Betrieb nicht ein, wenn Credits erschöpft sind, aber die Folgerechnung kann den gesamten wirtschaftlichen Vorteil eines gut verhandelten Vertrags zunichtemachen.

Warum das ein strukturelles Problem ist

Der DSAG-Kongress 2024 hat gezeigt, dass Unsicherheiten über laufende Cloud-Kosten und Steuerungsmöglichkeiten zu den zentralen Themen bei SAP-RISE-Kunden gehören (IT-Onlinemagazin, 2024). Das ist kein Zufall. Die Vertragsstruktur schafft diese Unsicherheit aktiv, weil drei Dinge gleichzeitig zutreffen.

Erstens sind Credits und tatsächliche Service-Kosten entkoppelt. Im BTP Cockpit sehen Sie Ihren aktuellen Credit-Stand. Was Sie dort oft nicht direkt ablesen, ist, welcher Service in welchem Subaccount in welchem Tempo verbraucht. Integration Suite, Kyma, HANA Cloud und KI-Dienste haben alle unterschiedliche Verbrauchsraten, die sich über die Laufzeit verändern können.

Zweitens ist das CPEA-Modell ein Commit-to-Consume-Modell. Das bedeutet: Sie bezahlen den Credit-Pool, unabhängig davon, ob Sie ihn nutzen. Der finanzielle Verlust durch ungenutzte Credits ist nicht hypothetisch. Er entsteht zuverlässig, wenn aktives Monitoring ausbleibt.

Drittens reagiert Overage asymmetrisch. Wer zu viel eingekauft hat, verliert den Differenzbetrag. Wer zu wenig eingekauft hat, zahlt den vollen Listenpreis für den Mehrverbrauch, ohne die Möglichkeit, rückwirkend günstigere Konditionen zu aktivieren. Das Risiko liegt also auf beiden Seiten, und ohne Steuerung tritt erfahrungsgemäß beides ein: gleichzeitig in unterschiedlichen Services.

Was Sie konkret tun können

Die gute Nachricht ist, dass dieser Mechanismus steuerbar ist. Er erfordert keine Vertragsänderung, sondern operative Disziplin und die richtigen Beobachtungspunkte.

1. Verbrauch monatlich nachverfolgen, nicht jährlich überprüfen

Das BTP Cockpit stellt monatliche Balance Statements bereit: Verbrauch pro Service und Subaccount. Diese Daten werden häufig quartalsweise oder gar nicht systematisch ausgewertet. Ein monatlicher Review, auch wenn er kurz ist, gibt Ihnen die Zeit, bei erkennbaren Mustern einzugreifen, bevor daraus ein Problem wird. Die Faustregel: Bei 70 bis 80 Prozent des Credit-Budgets sollte das Gespräch mit SAP über Top-Up-Optionen beginnen, nicht bei 95 Prozent.

2. Subaccounts und Service-Nutzung gegenüberstellen

In der Praxis sehe ich häufig Situationen, in denen einzelne Subaccounts, etwa für Entwicklungs- oder Testumgebungen, hohen Verbrauch aufbauen, während produktive Services unterbelastet sind. Die Konsolidierung beginnt mit der Frage: Welche Services laufen in welchem Subaccount, wer ist verantwortlich, und entspricht der Verbrauch dem erwarteten Nutzen? Eine Bestandsaufnahme pro Service ist der erste Schritt.

3. Ungenutzte Service-Subscriptions identifizieren

Subscriptions, die im Rahmen des RISE-Pakets aktiviert wurden, aber nicht produktiv genutzt werden, verbrauchen trotzdem Credits. Das gilt insbesondere für Dienste, die im Onboarding aktiviert und dann nicht weiterentwickelt wurden. Ein jährlicher Scope-Review, welche Services tatsächlich in Betrieb sind und welche nur provisioniert, kann Credit-Verluste erheblich reduzieren.

4. Rollover-Klauseln und Top-Up-Rechte vertraglich sichern

Nicht alle Vertragskonditionen sind unveränderlich. In Vertragsverhandlungen und Renewals lassen sich gelegentlich Klauseln einbauen, die einen begrenzten Credit-Übertrag ermöglichen oder Nachkäufe zu den ursprünglichen Konditionen statt zum Listenpreis sichern. Das ist kein Standard bei SAP, aber es ist verhandelbar, wenn man früh genug agiert. Wer das Thema erst bei der Renewal-Vorbereitung aufgreift, hat wenig Spielraum.

5. CPEA- und BTPEA-Eignung beim nächsten Renewal prüfen

Seit 2024 bietet SAP das BTPEA-Modell (BTP Enterprise Agreement) als Weiterentwicklung von CPEA an. Es konzentriert sich auf BTP-Services, enthält neuere Dienste wie SAP Analytics Cloud und bringt eine differenziertere Deprecation Policy mit. Für Bestandskunden ist der Wechsel freiwillig und erfolgt im Rahmen der regulären Verlängerung. Die zentrale Frage beim nächsten Renewal lautet: Nutzen Sie Services, die nur in BTPEA verfügbar sind? Wenn ja, ist ein Wechsel sinnvoll. Wenn nein, kann CPEA mit seinem breiteren Legacy-Katalog günstiger bleiben. Diese Abwägung lässt sich nur auf Basis der tatsächlichen Nutzungsdaten treffen.

Fazit

BTP-Credits verfallen und BTP-Kosten wachsen unkontrolliert aus demselben Grund: unzureichende Beobachtung des laufenden Verbrauchs. Beides ist keine unvermeidliche Folge der Vertragsstruktur. Es ist das Ergebnis davon, dass Vertragssteuerung nach der Unterschrift als abgeschlossen gilt.

Ein RISE-Vertrag ist kein statisches Dokument. Er entwickelt sich mit der Nutzung, mit Service-Aktivierungen, mit Subaccount-Entscheidungen und mit Vertragsänderungen. Wer diese Entwicklung monatlich begleitet, kann gegensteuern, bevor Credits verfallen oder Overage entsteht.

Die nächsten Artikel der RISE Contract Anatomy-Serie vertiefen weitere Bausteine: ACV-Struktur, Order Form und SLA-Klauseln. Wenn Sie die Frage nach Ihrem eigenen BTP-Verbrauch jetzt konkret angehen möchten, bietet der FinOptory Vertragscheck einen strukturierten Einstieg.

Quellen:
SAPinsider (2024): Unleashing the Potential of SAP BTP Credits Makes Business Sense
IT-Onlinemagazin (2024): RISE with SAP und Cloud Innovation: DSAG-Kongress zwischen Hoffnung und Skepsis