BTP FinOps und Credit-Steuerung: SAP-Cloud-Budgets verursachergerecht steuern

SAP BTP wird über vier Vertragsmodelle konsumiert, aber nur eines davon (BTPEA) ist für Neukunden das strategische Standardmodell. Darunter liegt eine Credit-Mechanik, bei der ungenutzte Budgets am Jahresende verfallen und Overages zum vollen Listenpreis abgerechnet werden. Wer BTP-Kosten transparent steuern, verursachergerecht zuordnen und in einen FinOps-Zyklus einbetten will, benötigt drei Dinge: ein passendes Vertragsmodell, laufendes Monitoring und klare interne Verantwortlichkeiten.

Inhaltsverzeichnis

1. Was BTP ist und warum die Vertragsmodell-Wahl entscheidet
2. Die vier Vertragsmodelle: CPEA, BTPEA, PAYG, Subscription
3. CPEA vs. BTPEA: Was sich unterscheidet und wer migrieren sollte
4. Capacity Units: Das Abrechnungsmaß verstehen
5. Depreciation Groups: Stabilität und Innovationsrisiko im Service-Katalog
6. Credit-Verfall und Use-It-or-Lose-It-Logik
7. Overage: Wie Überverbrauch entsteht und was er kostet
8. BTP-Monitoring: Was man sehen muss, um steuern zu können
9. FinOps Inform-Phase: Transparenz über den BTP-Verbrauch herstellen
10. FinOps Optimize-Phase: Verbrauch und Commitment gezielt ausrichten
11. FinOps Operate-Phase: Laufende Steuerung als Governance-Prozess
12. Interne Verrechnung: BTP-Kosten auf Projekte und Kostenstellen allokieren
13. FAQ
14. Nächste Schritte

---

1. Was BTP ist und warum die Vertragsmodell-Wahl entscheidet {#was-btp-ist}

BTP als technische Plattform in fünf Säulen

SAP Business Technology Platform (BTP) ist die zentrale Technologieschicht im SAP-Ökosystem. Sie verbindet Anwendungsentwicklung, Automatisierung, Integration, Datenmanagement und künstliche Intelligenz in einer gemeinsamen Plattform. Für Unternehmen mit komplexen SAP-Landschaften ist BTP der Ort, an dem Erweiterungen gebaut, Integrationen betrieben und Daten zusammengeführt werden.

Die fünf Säulen der Plattform lassen sich klar abgrenzen: Application Development umfasst Low-Code- und Pro-Code-Entwicklungsumgebungen wie SAP Build Apps, SAP Build Code und das Business Application Studio. Automation schließt Workflow-Management, robotische Prozessautomatisierung und Dokumentenverarbeitung ein. Integration bündelt die SAP Integration Suite mit über 3.400 vorkonfigurierten Integrationspaketen, API-Management und Event-Mesh-Architektur. Data & Analytics umfasst SAP Datasphere, SAP Analytics Cloud und SAP HANA Cloud als In-Memory-Datenbankplattform. Die fünfte Säule, AI, stellt SAP AI Core, den Generative AI Hub und AI-Services bereit.

Diese Fünf-Säulen-Architektur bedeutet für die Vertragssteuerung: BTP ist kein einzelnes Produkt, das man an- oder abschaltet. Es ist eine Plattform mit dutzenden aktiven Services, die gleichzeitig laufen, unterschiedliche Verbrauchsmuster haben und in ihrer Summe das monatliche Credit-Budget belasten.

Warum die Vertragsmodell-Wahl mehr als eine Einkaufsentscheidung ist

Die Wahl zwischen CPEA, BTPEA, PAYG und Subscription-Modellen bestimmt nicht nur den Preis pro Capacity Unit. Sie bestimmt auch, welche Services überhaupt zugänglich sind, wie Overages abgerechnet werden, welche Verfallsregeln für ungenutzte Credits gelten und welche Governance-Anforderungen sich ergeben.

Ein CPEA-Vertrag gibt Zugang zu einem historisch gewachsenen Katalog von rund 85 Services, bietet aber keine Zukunftssicherheit für neue Services. Ein BTPEA-Vertrag enthält neuere Services exklusiv, führt aber das Zwei-Gruppen-Modell für Service-Deprecation ein, das eigene Monitoring-Anforderungen stellt. PAYG bietet maximale Flexibilität zum Listenpreis, eignet sich aber nicht für den Produktivbetrieb. Subscriptions schaffen Kostenpräzision für einzelne, stabile Services, erzeugen aber schnell Shelfware bei variablen Workloads.

Die Vertragsmodell-Wahl ist damit ein Steuerungsmoment, der die gesamte BTP-Governance über die Vertragslaufzeit prägt. Wer das Modell falsch wählt oder nach Vertragsabschluss nicht aktiv steuert, läuft in eine von zwei Fallen: Credits verfallen ungenutzt, oder Overages entstehen zum vollen Listenpreis, ohne dass der Verbrauch rechtzeitig erkannt wurde.

BTP im RISE-Kontext: inkludiertes Credit-Budget versus eigenständiger BTP-Vertrag

Für Kunden mit RISE-Vertrag besteht ein wichtiger Unterschied, der in der Praxis häufig zu Fehleinschätzungen führt. Im RISE-Paket ist ein BTP-Credit-Budget enthalten, dessen Höhe von der Lizenzstufe abhängt. Dieses Budget ist nicht unbegrenzt und deckt nicht alle BTP-Nutzungsszenarien ab.

Wer BTP-Services über das inkludierte Budget hinaus nutzt, erzeugt entweder ungeplante Overages im Rahmen des RISE-Vertrags oder muss einen eigenständigen BTP-Vertrag (CPEA oder BTPEA) abschließen. In der Praxis sehen wir regelmäßig, dass Unternehmen im zweiten oder dritten Vertragsjahr feststellen, dass ihr BTP-Bedarf das ursprünglich eingeplante Budget übersteigt, weil Integrationsvolumina unterschätzt wurden oder neue Use Cases hinzugekommen sind, die bei Vertragsabschluss noch nicht geplant waren.

Was eine falsche Modellwahl über die Vertragslaufzeit bedeutet

Die finanziellen Konsequenzen einer nicht angepassten Vertragsstruktur werden mit der Zeit sichtbar, nicht sofort. Ein zu hoch dimensionierter Credit-Pool, der nicht vollständig verbraucht wird, kostet am Jahresende das gesamte ungenutzte Budget. Ein zu niedrig dimensionierter Pool erzeugt Overages, bei denen alle Volumenrabatte entfallen und zum vollen Listenpreis abgerechnet wird.

Dieser Steuerungsmoment zwischen Überdimensionierung und Unterdimensionierung lässt sich nur durch aktives, laufendes Monitoring und einen strukturierten Governance-Prozess verwalten. Einmalige Planungsentscheidungen bei Vertragsabschluss reichen über eine typische Drei-Jahres-Laufzeit nicht aus.

---

2. Die vier Vertragsmodelle: CPEA, BTPEA, PAYG, Subscription {#vier-vertragsmodelle}

Vier Modelle, vier unterschiedliche Steuerungslogiken. Was sie gemein haben, was sie trennt, und welches wann passt.

CPEA: Grundprinzip und Kernmerkmale

Das Cloud Platform Enterprise Agreement (CPEA) ist das traditionelle Enterprise-Modell für BTP. Es funktioniert nach dem Commit-to-Consume-Prinzip: Der Kunde kauft vorab ein jährliches Credit-Budget und verbraucht dieses flexibel über die rund 85 verfügbaren BTP-Services. Die Logik entspricht einer Prepaid-Karte: Credits werden vorab geladen, Services verbrauchen sie nach definierten Rates.

Kernmerkmale im Überblick: Jährliches Mindestcommitment mit Volumenrabatten, flexibler Verbrauch über den gesamten Servicekatalog, Self-Provisioning ohne SAP-Freigabeprozess, monatliche Balance Statements mit Aufschlüsselung nach Service und Subaccount. Der Credit-Preis sinkt mit steigendem Commitment, typische Bandbreiten liegen bei 10 bis 25 Prozent Rabatt auf den Listenpreis bei mittleren Volumina (Community Knowledge: Redress Compliance, Rizing).

Ein strukturelles Merkmal von CPEA: Der Service-Katalog wird nicht mehr um neue Services erweitert. Wer neue SAP-Services nutzen möchte, die nach CPEA-Einführung entwickelt wurden, findet diese ausschließlich im BTPEA-Katalog (Quelle: ASUG, SAP Experts Detail New SAP BTP Enterprise Agreement).

BTPEA: Grundprinzip und strategische Positionierung

Das BTP Enterprise Agreement (BTPEA) wurde 2024 als strategisches Nachfolgemodell eingeführt und ist für Neukunden heute das empfohlene Standard-Vertragsmodell. Die Grundlogik ist identisch zu CPEA: Vorab-Kauf von Credits, flexible Nutzung über einen definierten Servicekatalog, Volumenrabatte, monatliche Abrechnung.

Der entscheidende Unterschied liegt nicht in der Abrechnungslogik, sondern im Service-Scope und der Zukunftssicherheit. BTPEA enthält alle neuen Services exklusiv, darunter SAP Analytics Cloud, neuere AI-Services und künftige Additions. Gleichzeitig sind einige Low-Adoption-Services aus dem Katalog herausgenommen worden. Die Minimum Price Guarantee stellt sicher, dass der Kunde bei sinkenden SAP-Listenpreisen während der Laufzeit automatisch davon profitiert (Quelle: ASUG).

PAYG: Wann und warum

Pay-As-You-Go ist das Zero-Commitment-Modell. Kein Mindestverbrauch, keine Vorabzahlung, monatliche Abrechnung nach tatsächlichem Verbrauch. Dafür gilt der volle Listenpreis ohne Volumenrabatte.

PAYG ist sinnvoll für Proof-of-Concept-Projekte, Developer-Sandboxes, die Evaluierung von Services vor einem Enterprise-Agreement-Commitment und als Einstieg, um Verbrauchsmuster zu verstehen. Für den Produktivbetrieb mit relevantem Nutzungsvolumen ist PAYG strukturell ungeeignet, weil die Stückkosten erheblich höher liegen als in einem Enterprise Agreement.

Subscription: Stabilität versus Starrheit

Das Subscription-Modell bietet feste Preise für einzelne Services mit definierten Kapazitätsgrenzen. Für stabile, vorhersagbare Workloads bietet es die höchste Kostenpräzision. SAP HANA Cloud in der Produktionsumgebung, die Integration Suite mit festem Nachrichtenvolumen oder SAP Build für definierte Entwicklungsteams sind typische Subscription-Szenarien.

Die Kehrseite: Subscriptions sind unflexibel. Wer mehr Kapazität benötigt als gebucht, zahlt Overage. Wer weniger verbraucht, zahlt trotzdem den vollen Betrag. Shelfware entsteht häufig bei Subscriptions, weil der geplante Bedarf sich nach Vertragsabschluss nicht in der erwarteten Nutzung materialisiert.

Hybrid-Modelle in der Praxis

Die meisten Enterprise-Kunden nutzen keine einheitliche Strategie, sondern kombinieren Modelle. Typisch ist eine Kombination aus Subscription für Kernservices mit konstantem Bedarf (z.B. Integration Suite Produktion) und CPEA oder BTPEA Credits für flexible Nutzung (z.B. AI-Workloads, neue Entwicklungsprojekte, Dev/Test-Umgebungen). Dieses Hybrid-Modell bietet Kostenpräzision für die Basis und Flexibilität für variable Teile der BTP-Nutzung.

Governance-Anforderung bei Hybrid-Modellen: Zwei Vertragsstrukturen erfordern zwei Monitoring-Streams. Der Steuerungsmoment, an dem Subscription-Overage und Credit-Verbrauch gleichzeitig beobachtet werden müssen, erhöht die Komplexität der internen Steuerung.

---

3. CPEA vs. BTPEA: Was sich unterscheidet und wer migrieren sollte {#cpea-vs-btpea}

Service-Scope-Unterschied: Legacy-Breite versus Zukunftssicherheit

CPEA wurde mit einem Katalog von rund 85 bis 90 Services gestartet, der historisch gewachsen ist. Dieser Katalog ist stabil, aber abgeschlossen. Neue Services, die SAP seit der BTPEA-Einführung entwickelt hat, stehen in CPEA nicht zur Verfügung.

BTPEA hat einen schmaleren Legacy-Scope, weil Low-Adoption-Services entfernt wurden, enthält aber alle neuen Services exklusiv. SAP Analytics Cloud ist das prominenteste Beispiel: Sie wurde erst mit BTPEA in das Enterprise-Agreement-Modell aufgenommen und steht CPEA-Kunden über diesen Weg nicht zur Verfügung. Gleiches gilt für KI-Services der neuesten Generation und weitere strategische Additions (Quelle: ASUG, SAP Experts Detail New BTPEA).

Für die Modellwahl ergibt sich: Wer ausschließlich Services nutzt, die in CPEA enthalten sind, und keine neuen Services benötigt, kann auf CPEA bleiben. Wer SAP Analytics Cloud über das Enterprise Agreement nutzen oder neue SAP-AI-Services einsetzen möchte, benötigt BTPEA.

Deprecation Policy: Das Zwei-Gruppen-Modell in BTPEA

BTPEA führt eine strukturierte Deprecation Policy ein, die CPEA nicht kennt. Services werden in zwei Gruppen eingeteilt.

Gruppe 1 (Core Services) sind Services, die bis zum Ende der aktuellen Vertragslaufzeit unterstützt werden. Kunden können diese Services ohne Migrationsdruck über die gesamte Laufzeit ihres Vertrags nutzen. Dieser Schutz entspricht der Zusage, die CPEA-Kunden grundsätzlich haben.

Gruppe 2 (Innovation Services) sind neuere oder selten genutzte Services, die SAP nach einer Vorankündigungsfrist von mindestens 6 Monaten entfernen oder in Gruppe 1 überführen kann. Das bedeutet: Produktive Workloads auf Gruppe-2-Services haben ein strukturelles Risiko, das aktiv überwacht werden muss (Quelle: ASUG, SAP Experts Detail New BTPEA).

Für die Praxis bedeutet das Zwei-Gruppen-Modell: Jedes Deployment auf einem BTPEA-Service sollte zu Beginn geprüft werden, in welche Gruppe der Service fällt. Dieser Steuerungsmoment im Bereich Infrastruktur ist keine einmalige Aufgabe, sondern eine kontinuierliche Monitoring-Anforderung.

Was in BTPEA hinzugekommen ist

Neben SAP Analytics Cloud (Public System, BI und Planning) enthält BTPEA neue AI-Services aus dem SAP AI Portfolio und weitere neuere Additions, die SAP kontinuierlich ergänzt. Der Discovery Center Service Catalog zeigt tagesaktuell, welche Services in welchem Modell verfügbar sind (https://discovery-center.cloud.sap/).

Wann Migration sinnvoll ist und wann nicht

Eine Migration von CPEA zu BTPEA ist sinnvoll, wenn mindestens eine der folgenden Bedingungen zutrifft: Das Unternehmen möchte SAP Analytics Cloud über das Enterprise Agreement nutzen. Neue AI-Services sollen in die Plattformstrategie einbezogen werden. Die Zukunftssicherheit des Vertragsvehikels ist strategisch wichtig und neue SAP-Innovations-Services sollen flexibel erprobbar sein.

Eine Migration ist weniger dringend, wenn alle aktiv genutzten Services im bestehenden CPEA-Katalog enthalten sind, keine neuen Services aus dem BTPEA-exklusiven Bereich benötigt werden und der bestehende Vertrag noch eine relevante Restlaufzeit hat.

Migrationsprozess: Was sich technisch ändert und was sich kommerziell ändert

Die gute Nachricht: Eine Migration von CPEA zu BTPEA erfordert keine technischen Änderungen an der bestehenden BTP-Landschaft. Der Global Account, die Subaccounts, die laufenden Services und alle Konfigurationen bleiben unverändert. Es werden lediglich die neuen kommerziellen Konditionen auf dem bestehenden Global Account aktiviert (Quelle: ASUG, SAP Experts Detail New BTPEA).

Die kommerzielle Seite der Migration ist relevanter: Der neue Vertrag bildet eine neue Preisgrundlage, die von den alten CPEA-Konditionen abweichen kann. Services, die nicht in BTPEA enthalten sind, müssen als separate Subscriptions weitergeführt werden, wenn sie noch benötigt werden. Eine sorgfältige Analyse der genutzten Services vor der Migration ist deshalb ein Pflicht-Schritt.

---

4. Capacity Units: Das Abrechnungsmaß verstehen {#capacity-units}

Was eine Capacity Unit ist und wie die Umrechnung funktioniert

Capacity Units (CU) sind das universelle Abrechnungsmaß über alle BTP-Services hinweg. Jeder Service definiert eigene technische Verbrauchsmetriken, zum Beispiel GB RAM pro Stunde bei Runtime-Umgebungen, Nachrichtenvolumen bei der Integration Suite oder Speicher- und Compute-Einheiten bei SAP HANA Cloud. Diese service-spezifischen Metriken werden über Credit-Rates in Capacity Units umgerechnet.

Die Faustregel: Ein Credit entspricht grob einem Dollar Verbrauch zum Listenpreis (die genaue Konversion ist vertragsabhängig und im Order Form festgelegt). Der monatliche Abrechnungsprozess funktioniert konsistent: SAP misst den technischen Verbrauch je Service, multipliziert ihn mit der service-spezifischen Rate, summiert die Capacity Units aller Services auf und zieht sie vom Credit Pool ab. Das Ergebnis wird in monatlichen Balance Statements dokumentiert (Quelle: SAP Help Portal, Monitoring Usage and Consumption Costs).

Service-spezifische Metriken im Vergleich

Die Bandbreite der Verbrauchsmetriken ist erheblich, und gerade dieser Unterschied macht BTP-Forecasting ohne fundiertes CU-Verständnis anspruchsvoll.

Cloud Foundry Runtime wird nach GB RAM pro Stunde gemessen. Als Orientierungswert gilt etwa 0,1 CU pro GB RAM und Stunde, was bei 24/7-Betrieb rund 72 Credits pro Gigabyte und Monat ergibt (Community Knowledge: Redress Compliance). Kyma Runtime, die Kubernetes-native Laufzeitumgebung, liegt bei etwa 0,24 CU pro Node-Stunde, ein Drei-Node-Cluster kommt damit auf rund 518 Credits im Monatsdauerbetrieb.

Die Integration Suite verwendet Nachrichtenzählungen als Metrik. Das Volumenmodell ist progressiv: Bei niedrigen Volumina (200.000 Nachrichten pro Monat) liegen die Kosten bei etwa 6 Credits pro 10.000 Nachrichten, bei hohen Volumina (5 Millionen Nachrichten pro Monat) sinken sie auf 2 bis 3 Credits je 10.000 Nachrichten. SAP HANA Cloud ist in aller Regel der größte Einzelposten im BTP-Budget: eine Produktionsinstanz mit signifikantem Arbeitsspeicher kann mehrere tausend Credits pro Monat verbrauchen (Community Knowledge: Redress Compliance, SAP HANA Cloud CU Estimator).

Alle genannten Werte sind Richtwerte aus der Community-Praxis. Die aktuellen, verbindlichen Rates finden sich im SAP Discovery Center und den service-spezifischen Estimatoren, da SAP diese Werte periodisch aktualisiert.

Monatlicher Abrechnungsprozess und Balance Statements

SAP liefert monatliche Balance Statements, die den Verbrauch nach Service und Subaccount aufschlüsseln. Diese Statements sind die primäre Datenquelle für jedes BTP-Monitoring. Sie zeigen, welche Services wie viele Credits verbraucht haben, was die Credit-Balance am Ende des Monats war und welcher Verbrauch welchem Subaccount zuzuordnen ist.

Wichtig für den Steuerungsmoment im Bereich Kosten: Balance Statements sind rückwirkende Berichte, keine Echtzeit-Daten. Wer proaktiv steuern will, braucht zusätzlich laufende Monitoring-Einstellungen im BTP Cockpit, die Schwellenwerte überwachen und bei Annäherung an das Budget signalisieren.

Wo man aktuelle Rates findet

Die autoritativen Quellen für aktuelle Capacity-Unit-Rates sind der SAP Discovery Center Service Catalog (https://discovery-center.cloud.sap/) mit vollständiger Liste aller Services und Pricing je Commercial Model, der SAP Discovery Center Estimator (https://discovery-center.cloud.sap/estimator) für interaktive Kostenabschätzung, sowie service-spezifische Estimatoren für HANA Cloud, Datasphere und AI Core. Rates ändern sich, weshalb Forecasts mit dem Stand bei Erstellung gekennzeichnet werden sollten.

Warum Forecasting ohne CU-Verständnis systematisch ungenau bleibt

Ein Forecast, der nur in Euro rechnet und nicht die Credit-Rate-Struktur der genutzten Services berücksichtigt, lässt zwei strukturelle Fehler entstehen. Erstens bleibt die Verbrauchsdynamik unsichtbar: Ein Integrations-Use-Case mit wachsendem Nachrichtenvolumen kann den Credit-Pool innerhalb weniger Monate erschöpfen, wenn er nicht mit der progressiven Rate-Struktur der Integration Suite modelliert wird. Zweitens werden Service-Kombinationen unterschätzt: Wenn AI-Workloads sowohl BTP Capacity Units als auch separate AI Units verbrauchen, muss der Forecast beide Töpfe getrennt betrachten.

---

5. Depreciation Groups: Stabilität und Innovationsrisiko im Service-Katalog {#depreciation-groups}

Gruppe 1 (Core Services): Schutz bis Vertragsende

Gruppe-1-Services sind diejenigen BTP-Services, die SAP bis zum Ende der aktuellen Vertragslaufzeit unterstützt. Der Kunde kann diese Services produktiv einsetzen, ohne während der Laufzeit eine unerwartete Migration befürchten zu müssen. Dieser Schutz entspricht dem Versprechen, das CPEA-Kunden grundsätzlich genießen: Der Service-Scope ist für die Laufzeit gesichert.

Gruppe-1-Services bilden damit die verlässliche Basis für produktive, geschäftskritische Workloads. Integration Suite-Kern, HANA Cloud, Cloud Foundry Runtime und ABAP Environment gelten als stabile Gruppe-1-Services.

Gruppe 2 (Innovation Services): 6 Monate Vorlauf bei Abkündigung

Gruppe-2-Services können von SAP mit einer Vorankündigungsfrist von mindestens 6 Monaten aus dem BTPEA-Katalog entfernt oder in Gruppe 1 überführt werden. Die 6 Monate sind kein Puffer, der sicheres Warten erlaubt, sondern ein Zeitfenster, in dem eine Migrationsplanung eingeleitet werden muss.

Für den Einsatz von Gruppe-2-Services in produktiven Prozessen bedeutet das: Alle Abhängigkeiten auf solche Services müssen dokumentiert sein, und das Deprecation-Monitoring muss so eingestellt werden, dass eine Abkündigung nicht erst nach Ablauf der Ankündigungsfrist bemerkt wird.

Wie man prüft, welche genutzten Services in welche Gruppe fallen

Der SAP Discovery Center Service Catalog weist für jeden Service die Gruppe aus. Es empfiehlt sich, bei der Einführung eines neuen BTPEA-Deployments die Gruppen-Zugehörigkeit der genutzten Services zu dokumentieren. Diese Dokumentation ist Teil des Steuerungsmoments im Bereich Infrastruktur.

Aktuell betroffene Services: Datasphere und SAP Analytics Cloud

Zwei Services, die für viele BTP-Kunden relevant sind, standen unter Deprecation-Druck: SAP Datasphere und SAP Analytics Cloud zeigten in BTP Cockpit-Instanzen Deprecation-Warnungen mit Bezugsdatum 31. Dezember 2025 (SAP KBA 3630656, SAP KBA 3632353). Der Migrationspfad führt von Datasphere in Richtung SAP Business Data Cloud. Kunden, die Datasphere produktiv nutzen, sollten ihren Migrationsstatus und den aktuellen Stand dieser Ankündigungen prüfen, da sich SAP-Migrationspläne weiterentwickeln.

Für CPEA-Kunden gilt: Der Service-Scope ist für die Laufzeit gesichert, aber neue Weiterentwicklungen dieser Services finden in der Nachfolgelösung statt. Eine vorausschauende Planung für die nächste Vertragsverlängerung sollte diese Entwicklung berücksichtigen.

Governance-Konsequenz: Deprecation-Monitoring als laufende Aufgabe

Deprecation-Monitoring ist keine einmalige Einrichtungsaufgabe, sondern ein struktureller Bestandteil der BTP-Governance. SAP veröffentlicht Neuigkeiten über Service-Änderungen im BTP Release Navigator (https://help.sap.com/whats-new/cf0cb2cb149647329b5d02aa96303f56). Die regelmäßige, quartalsweise Prüfung dieses Kanals ist eine praktische Maßnahme, um frühzeitig auf Änderungen im genutzten Servicekatalog reagieren zu können.

---

6. Credit-Verfall und Use-It-or-Lose-It-Logik {#credit-verfall}

Standardregel: Ungenutzte Credits verfallen am Ende der Vertragsperiode

Die Credit-Verfall-Regel ist eine der folgenreichsten Mechaniken im BTP-Vertragsmodell. Ungenutzte Credits verfallen am Ende der Vertragsperiode, in der Regel zum Ende des Vertragsjahres. Es gibt keinen automatischen Rollover auf das nächste Vertragsjahr. Diese Regel gilt für CPEA und BTPEA gleichermaßen (Quelle: SAP FAQ, Consumption-based Commercial Model CPEA).

In der Praxis bedeutet das: Ein Unternehmen, das zu Jahresbeginn ein Credit-Budget von 100.000 Credits kauft, davon aber bis Jahresende nur 65.000 Credits verbraucht, verliert die übrigen 35.000 Credits. Diese Situation entsteht häufig bei zu optimistischer Planung von BTP-Use-Cases, die sich in der Realisierung verzögern, oder wenn Services aktiviert, aber nicht in der erwarteten Intensität genutzt werden.

Kein automatischer Rollover in Standardverträgen

Die Abwesenheit eines Standard-Rollovers ist der Steuerungsmoment, der quartalsweise Verbrauchsreviews erzwingt. Wer erst am Jahresende feststellt, dass ein erheblicher Anteil der Credits unverbraucht bleiben wird, hat in der Regel keinen Handlungsspielraum mehr.

Die strukturelle Empfehlung lautet: Credit-Commitment konservativ dimensionieren. Lieber einen etwas zu kleinen Pool wählen und bei Bedarf nachkaufen, als einen zu großen Pool verfallen zu lassen. Das Nachkaufrecht zu initialen Konditionen sollte vertraglich gesichert sein, damit ein Top-Up nicht zum Listenpreis erfolgen muss (Quelle: SAP BTP Licensing Models, Community Knowledge).

Wann Over-Commitment entsteht und wie er sich materialisiert

Over-Commitment entsteht, wenn die tatsächliche BTP-Nutzung hinter der Planung zurückbleibt. Drei typische Ursachen: Erstens werden BTP-Projekte verzögert oder anders priorisiert, so dass geplante Services in der Vertragsperiode nicht produktiv gehen. Zweitens werden Services aktiviert, aber nicht in der geplanten Intensität genutzt, weil Nutzerakzeptanz oder Prozessintegration länger dauern als geplant. Drittens werden bei Vertragsabschluss optimistische Sizing-Annahmen getroffen, die das realistischere Nutzungsszenario überschätzen.

Verhandlungsraum: Begrenzter Credit-Rollover

In Vertragsverhandlungen ist ein begrenzter Credit-Rollover aushandelbar, wenn auch kein Standardbestandteil. Als Orientierungswert aus der Praxis gilt ein Rollover von 10 bis 20 Prozent der ungenutzten Credits als erzielt worden (Community Knowledge: Rizing, Redress Compliance). Dieser Wert ist keine offizielle SAP-Angabe und kein garantiertes Verhandlungsergebnis, sondern ein Erfahrungswert.

Alternativ kann eine kurze Grace Period oder die Umwidmung ungenutzter Credits auf andere SAP-Softwarekäufe verhandelt werden, was jedoch ebenfalls kein Standardfall ist.

Quartalsweise Reviews als strukturelle Maßnahme gegen Verfall

Die praktisch wirksamste Maßnahme gegen unerwarteten Credit-Verfall ist der quartalsweise Verbrauchsreview. In diesem Review wird der kumulierte Verbrauch mit dem geplanten Verbrauchspfad verglichen. Ist der tatsächliche Verbrauch erheblich niedriger als geplant, gibt es noch Zeit, Gegenmaßnahmen einzuleiten: Aktivierung zusätzlicher Services für Dev/Test-Workloads, Anpassung laufender Service-Konfigurationen oder proaktives Gespräch mit SAP über eine Vertragsanpassung.

Der Steuerungsmoment eines quartalsweisen BTP-Reviews schafft die Grundlage dafür, dass ungenutzte Budgets erkannt und adressiert werden, bevor sie am Jahresende unwiederbringlich verfallen.

---

7. Overage: Wie Überverbrauch entsteht und was er kostet {#overage}

Was passiert, wenn der Credit Pool erschöpft ist

Wenn der vertraglich fixierte Credit Pool vor Ablauf der Vertragsperiode aufgebraucht ist, laufen die BTP-Services in der Regel weiter. SAP stellt den Betrieb nicht automatisch ein. Stattdessen greift die Overage-Mechanik: Der Verbrauch über das Kontingent hinaus wird zum vollen Listenpreis abgerechnet, ohne die Volumenrabatte, die im Enterprise Agreement verhandelt wurden (Quelle: SAP FAQ, Consumption-based Commercial Model CPEA; SAP Help Portal).

Das ist der entscheidende finanzielle Unterschied: Während ein Enterprise-Agreement-Kunde etwa 25 Prozent Rabatt auf den Listenpreis hat, werden Overage-Credits ohne diesen Rabatt abgerechnet. Bei einem erheblichen Überverbrauch kann die effektive Kostensteigerung signifikant sein.

Overage-Mechanik: Alle Volumenrabatte entfallen

Die Formel ist einfach: Innerhalb des Kontingents gilt der verhandelte Credit-Preis. Außerhalb des Kontingents gilt der Listenpreis. Diese Asymmetrie ist der finanzielle Kern der Overage-Mechanik. Sie macht Overages nicht nur teurer, sondern strukturell schwerer planbar, weil der Listenpreis nicht die Verhandlungsgrundlage war, auf der die ursprüngliche Budgetplanung basierte.

Für den Steuerungsmoment im Bereich Kosten bedeutet das: Overage-Risiko ist ein Budget-Risiko, das in keiner SAP-internen Kostenplanung unterschätzt werden sollte.

Typische Overage-Treiber

In der Praxis zeigen sich drei besonders häufige Overage-Ursachen.

Integration Suite Volumenunterschätzung: Integrations-Workloads haben eine Eigenschaft, die bei initialer Planung leicht übersehen wird. Was als 100.000 Nachrichten pro Monat geplant ist, kann durch File-Splits (ein Batch-File erzeugt hunderte Einzelnachrichten), Retry-Logik bei Fehlern und größere Payloads schnell ein Vielfaches davon werden. Integrations-Volumen-Monitoring gehört deshalb zu den kritischsten BTP-Steuerungsaufgaben.

HANA Cloud: SAP HANA Cloud ist in vielen BTP-Setups der größte Credit-Verbraucher. Eine 24/7-Produktionsinstanz mit signifikantem Arbeitsspeicher kann den gesamten Jahres-Credit-Pool stärker belasten als ursprünglich geplant, besonders wenn im Projektverlauf zusätzliche Kapazitäten aktiviert werden.

AI-Nutzung: AI Core und Generative AI Hub-Workloads haben oft schwer vorhersagbare Verbrauchsmuster, weil Token-Verbrauch stark von Use Case, Modellauswahl und Nutzungsintensität abhängt. Erste AI-Piloten überschätzen selten, aber bei produktivem Scale-up kann der Verbrauch schnell wachsen.

Self-Reporting-Pflicht: Übernutzungsmeldung liegt beim Kunden

Ein in der Praxis häufig unterschätzter Aspekt: In vielen BTP-Verträgen liegt die Pflicht zur Meldung von Übernutzung beim Kunden, nicht automatisch bei SAP (Quelle: SAP FAQ CPEA). Das bedeutet: Wer Overage erzeugt und nicht aktiv trackt und meldet, kann am Jahresende mit einer Nachbelastung konfrontiert werden, die sich über mehrere Monate aufgebaut hat.

Proaktives Upselling versus ungeplanter Overage

Es gibt einen strukturellen Unterschied zwischen einem geplanten Top-Up und einem ungeplanten Overage. Wer bei 70 bis 80 Prozent Credit-Verbrauch das Gespräch mit SAP sucht und einen Top-Up zu den ursprünglichen Vertragskonditionen vereinbart, vermeidet den Listenpreis-Aufschlag. Wer das Kontingent überschreitet, ohne vorher gehandelt zu haben, zahlt den Listenpreis (Quelle: SAP BTP Licensing Models KB, Community Knowledge: Rizing).

Das Nachkaufrecht zu initialen Konditionen sollte deshalb vertraglich gesichert sein. Bei 70 bis 80 Prozent Verbrauchsstand zu handeln, ist die praktische Alert-Schwelle für proaktive Steuerung.

Overage Cap als Verhandlungsziel

In Vertragsverhandlungen ist ein Overage Cap vereinbar: Ein Deckungsbetrag, der festlegt, bis zu welchem Vielfachen des Vertragspreises Overage maximal abgerechnet werden darf. Ein Cap bei 110 Prozent des Listenpreises bedeutet, dass Overage-Credits nicht teurer werden als 10 Prozent über dem Listenpreis. Diese Klausel schützt vor extremen Budgetüberschreitungen in Szenarien mit unerwartetem Verbrauchsanstieg.

---

8. BTP-Monitoring: Was man sehen muss, um steuern zu können {#btp-monitoring}

BTP Cockpit und monatliche Balance Statements

Das BTP Cockpit ist die primäre Benutzeroberfläche für die Verwaltung von BTP-Services, Subaccounts und Entitlements. Es bietet einen Überblick über aktive Services und Nutzung. Monatliche Balance Statements sind die strukturierte Verbrauchsübersicht: Sie zeigen den Credit-Verbrauch je Service und je Subaccount, die verbleibende Credit-Balance und die Entwicklung über den Vertragszeitraum.

Subaccount-basierte Aufschlüsselung nach Service und Projekt

Monatliche Balance Statements sind nur dann verursachergerecht lesbar, wenn die Subaccount-Struktur des Global Accounts sinnvoll organisiert ist. Ein Subaccount, der alle Projektumgebungen vermischt, liefert aggregierte Zahlen, aber keine Zuordnung zu Projekten oder Kostenstellen.

Der Steuerungsmoment im Bereich Nutzung setzt eine Subaccount-Struktur voraus, die organisatorische Einheiten, Projekte oder Kostenstellen widerspiegelt. Nur so lassen sich Balance Statements verursachergerecht interpretieren und für interne Verrechnung nutzen.

Alert-Schwellen: Wann gehandelt werden muss

Eine praktisch bewährte Alert-Strategie verwendet zwei Schwellenwerte: Eine erste Benachrichtigung bei 70 bis 80 Prozent Credit-Verbrauch leitet proaktive Steuerungsmaßnahmen ein. Eine zweite Benachrichtigung bei 90 Prozent ist der späteste Moment, um ein Top-Up-Gespräch mit SAP zu initiieren und ungeplante Overages zu vermeiden.

Das BTP Cockpit ermöglicht die Konfiguration von Benachrichtigungen für Subaccount-Nutzung. Diese Alerts sollten als Standard-Konfiguration in jedem produktiven BTP-Setup eingerichtet sein.

SAP BTP Discovery Center Estimator für laufende Forecasts

Der Discovery Center Estimator (https://discovery-center.cloud.sap/estimator) ist nicht nur ein Einmalwerkzeug bei Vertragsabschluss, sondern ein laufendes Forecast-Instrument. Wenn sich die Service-Nutzung verändert, zum Beispiel durch neue Projekte, wachsendes Integrationsvolumen oder den Einstieg in AI-Workloads, erlaubt der Estimator eine aktualisierte Abschätzung des Credit-Bedarfs für die restliche Vertragsperiode.

Grenzen des SAP-eigenen Monitorings

Das BTP Cockpit hat strukturelle Grenzen, die für eine vollständige Steuerung relevant sind. Es berichtet Verbrauch pro Subaccount und pro Service, bietet aber keine konsolidierte Sicht über mehrere Vertragsstrukturen (z.B. CPEA und Subscription gleichzeitig). Es zeigt keine historischen Verbrauchstrends über mehrere Vertragsjahre in vergleichbarer Form. Es liefert keine automatische Verbindung zu internen Kostenstellen oder Budgetstrukturen.

Wer BTP-Kosten vollständig mit SAP-nativen Werkzeugen steuern möchte, stößt damit an Grenzen, sobald die Vertragsstruktur komplex wird oder eine verursachergerechte interne Verrechnung erforderlich ist. Diese Lücke ist der Ausgangspunkt für den Aufbau einer eigenständigen BTP-Governance-Funktion.

Verknüpfung mit internen Kostenstellen

Eine vollständige BTP-Kostensteuerung verbindet die Subaccount-Verbrauchsdaten aus den monatlichen Balance Statements mit den internen Kostenstellenstrukturen des Unternehmens. Diese Verbindung herzustellen erfordert zwei Schritte: Die Subaccount-Struktur muss die organisatorischen Zurechnungseinheiten widerspiegeln, und ein Prozess muss existieren, der die monatlichen BTP-Daten in die interne Kostenrechnung überführt.

---

9. FinOps Inform-Phase: Transparenz über den BTP-Verbrauch herstellen {#finops-inform}

Das FinOps Framework als Rahmen

Das FinOps Framework ist ein offener Standard, der von der FinOps Foundation entwickelt und gepflegt wird. Die FinOps Foundation ist eine Non-Profit-Organisation unter dem Dach der Linux Foundation, gegründet 2019, mit inzwischen über 10.000 Mitgliedern weltweit. Das Framework strukturiert Technology Cost Management in drei Phasen: Inform, Optimize, Operate (Quelle: FinOps Foundation, FinOps Framework 2025).

Ursprünglich für Public Cloud (AWS, Azure, GCP) entwickelt, hat die FinOps Foundation seit 2024 und 2025 den Scope des Frameworks explizit erweitert. Licensing ist heute ein eigenständiger Scope, und SAP BTP ist ein konkretes Anwendungsbeispiel: Die spezifischen Mechaniken von Commit-to-Consume-Modellen, Credit-Verfall und Overage-Logik machen BTP zu einem Lehrbuch-Fall für FinOps-Prinzipien außerhalb der Public Cloud (Quelle: FinOps Foundation, Licensing & SaaS Capability).

Inform heißt: Vollständige Sichtbarkeit, bevor man optimiert

Der erste Schritt im FinOps-Zyklus ist nicht Optimierung, sondern Transparenz. Inform-Phase bedeutet, dass alle relevanten Daten über BTP-Entitlements, Service-Nutzung und Kosten vollständig erfasst und für die relevanten Rollen zugänglich sind. Ohne vollständige Sichtbarkeit ist Optimierung nicht fundiert, sondern zufällig.

Der Steuerungsmoment der Inform-Phase für BTP umfasst vier Dimensionen: Was ist vertraglich entitelt (alle Services und Limits im Vertrag)? Was ist tatsächlich aktiviert (alle aktiven Service-Plans pro Subaccount)? Was wird tatsächlich genutzt (monatliche Verbrauchsdaten aus Balance Statements)? Und welche Kosten entstehen dadurch (Umrechnung in Credits und schließlich in Euro)?

Inventarisierung: Alle BTP-Entitlements, Subaccounts, aktive Service-Plans

Der konkrete erste Schritt in der Inform-Phase ist eine vollständige Inventarisierung. Für BTP umfasst das: alle Verträge und Amendments (CPEA, BTPEA, Subscriptions), alle Global Accounts und deren Subaccount-Struktur, alle aktivierten Entitlements je Subaccount, und alle aktiven Service-Plans mit ihrem aktuellen Nutzungsstatus.

Diese Inventarisierung ist kein einmaliges Projekt, sondern eine Baseline, die bei jeder Vertragsänderung, jedem neuen Projekt-Setup und jedem Renewal aktualisiert werden muss.

Cost Allocation in der Inform-Phase: Erste Zuordnung von Credits auf Projekte

Sobald die Inventarisierung vorliegt, beginnt die erste Kostenzuordnung. In der Inform-Phase geht es noch nicht um optimierte Verrechnung, sondern um die grundsätzliche Fähigkeit, Credits Projekten oder Organisationseinheiten zuzuordnen. Diese erste Zuordnung ist der Ausgangspunkt für alle weiteren Steuerungsentscheidungen.

Shelfware im BTP-Kontext erkennen

Shelfware, also aktivierte Services, die nicht oder kaum genutzt werden, ist im BTP-Umfeld ein strukturelles Phänomen. Services werden im Rahmen von Projekten aktiviert und bleiben nach Projektende laufen. Testinstanzen werden aufgebaut und nicht wieder abgeschaltet. Service-Plans werden für zukünftige Use Cases aktiviert, die nie realisiert werden.

In der Inform-Phase wird Shelfware sichtbar, weil aktive Service-Plans mit tatsächlichem Nutzungsvolumen abgeglichen werden. Ein aktivierter Service-Plan mit nahezu null Verbrauch über mehrere Monate ist ein Kandidat für Deaktivierung oder Downsizing.

---

10. FinOps Optimize-Phase: Verbrauch und Commitment gezielt ausrichten {#finops-optimize}

Optimize heißt: Aktive Eingriffe, nicht nur Beobachten

Die Optimize-Phase setzt auf den Daten der Inform-Phase auf und zielt auf aktive Maßnahmen zur Verbesserung der Credit-Effizienz. Optimize ist kein einmaliges Kostensenkungsprojekt, sondern ein laufender Prozess, der immer dann eingeleitet wird, wenn Inform-Daten Potenzial für Verbesserungen zeigen.

Rightsizing: Überdimensionierte Service-Plans und Runtime-Konfigurationen

Der erste Optimierungsansatz betrifft die Dimensionierung aktiver Services. Runtime-Umgebungen (Cloud Foundry, Kyma) laufen häufig mit mehr Ressourcen als tatsächlich benötigt, weil die initiale Konfiguration auf Spitzenlast ausgelegt war, die im Normalbetrieb nicht erreicht wird. SAP HANA Cloud-Instanzen können Arbeitsspeicher haben, der dauerhaft nur zu einem Bruchteil ausgenutzt wird.

Rightsizing bedeutet, Service-Konfigurationen an den tatsächlichen Nutzungsbedarf anzupassen. Für den Steuerungsmoment im Bereich Nutzung: jede Ressource, die über den tatsächlichen Bedarf hinaus läuft, verbraucht Credits ohne entsprechenden Business-Wert.

Hyperscaler-Overlap prüfen: Wo wird doppelt gezahlt?

Für Kunden auf Hyperscalern (AWS, Azure, GCP) besteht ein strukturelles Doppelzahlungsrisiko. BTP bietet Integration, Analytics und AI-Funktionen, aber die jeweiligen Hyperscaler bieten vergleichbare oder ergänzende Services an. Wenn ein Unternehmen sowohl BTP-Analytics-Services als auch Hyperscaler-Analytics-Dienste zahlt, ohne eine klare Abgrenzung zu haben, entstehen Kosten für überlappende Capabilities.

Die Optimize-Maßnahme besteht in einer systematischen Gegenüberstellung: Welche BTP-Services haben direkte Hyperscaler-Entsprechungen? Wo ist der BTP-Service besser geeignet (z.B. SAP-Integration Suite für SAP-spezifische Integrationen), wo ist der Hyperscaler-Service gleichwertig oder günstiger? Die Konsolidierung auf eine Capability-Quelle vermeidet Redundanzkosten.

Non-Production-Shutdown-Strategien

Development- und Test-Instanzen von HANA Cloud, Kyma-Clustern und Cloud-Foundry-Laufzeitumgebungen müssen nicht rund um die Uhr laufen. Automatische Shutdown-Strategien für Nacht- und Wochenendzeiten reduzieren den Credit-Verbrauch dieser Umgebungen erheblich, ohne den Development-Betrieb zu beeinträchtigen.

Für HANA Cloud gibt es Scheduling-Funktionen, die automatische Starts und Stopps ermöglichen. Kyma-Cluster können auf null Nodes herunterskaliert werden, wenn sie nicht benötigt werden. Cloud-Foundry-Applikationen können auf null Instanzen gestellt werden. Diese Maßnahmen haben typischerweise eine direkte und messbare Auswirkung auf den monatlichen Credit-Verbrauch.

Credit-Commitment-Kalibrierung

Die Optimize-Phase umfasst auch die Kalibrierung des Credit-Commitments für die nächste Vertragsperiode. Auf Basis der Inform-Daten der laufenden Periode lässt sich ein fundierter Forecast erstellen, der realistischer ist als die initiale Planung bei Vertragsabschluss. Dieser Forecast ist die Grundlage für das Commitment der nächsten Periode: genug, um Volumenrabatte zu sichern, aber nicht mehr, als tatsächlich verbraucht werden kann.

Die Empfehlung für eine konservative Erstdimensionierung und ein vertraglich gesichertes Nachkaufrecht kombiniert das Risiko von Verfall (zu viel) und das Risiko von Listenpreis-Overage (zu wenig) in ein handhabbareres Bild.

---

11. FinOps Operate-Phase: Laufende Steuerung als Governance-Prozess {#finops-operate}

Operate heißt: Kontinuierliche Steuerung, nicht einmaliges Projekt

Die Operate-Phase schließt den FinOps-Zyklus, der danach von vorne beginnt. Operate bedeutet, dass die Governance-Prozesse aus Inform und Optimize in den regulären Betriebsrhythmus des Unternehmens eingebettet sind. BTP-FinOps ist kein Projekt mit Abschlussdatum, sondern eine laufende Funktion.

Monatlicher Steuerungsrhythmus

Der monatliche Steuerungsrhythmus umfasst drei Kernaktivitäten: Erstens die Auswertung der monatlichen Balance Statements und den Abgleich mit dem Verbrauchspfad (Budget Tracking). Zweitens die Prüfung auf Anomalien: Dienste, die unerwartet viel verbrauchen, neue Service-Aktivierungen ohne dokumentierten Geschäftsbedarf, oder Verbrauchsspitzen, die auf Konfigurationsfehler oder unerwartete Workloads hinweisen. Drittens ein aktualisierter Forecast für die restliche Vertragsperiode auf Basis des tatsächlichen Verbrauchsstands.

Vier Rollen im BTP-FinOps-Prozess

Laufende BTP-Steuerung erfordert die strukturierte Zusammenarbeit von vier Rollen, die im FinOptory-Governance-Modell klar definiert sind.

Der Contract Manager trägt die Verantwortung für die Vertragsstruktur: Welche Modelle und Services sind kontraktiert? Welche Laufzeiten und Renewal-Termine stehen an? Welche Klauseln (Overage Cap, Rollover, Nachkaufrecht) sind im Vertrag gesichert? Der Contract Manager ist der Steuerungsmoment-Verantwortliche für die Schnittstelle zwischen Vertrag und tatsächlichem Verbrauch.

Procurement verantwortet die Einkaufsentscheidungen: Ist das aktuelle Modell noch das richtige? Wann ist der optimale Verhandlungszeitpunkt (SAPs Q4-Ende, Renewal-Fenster)? Wie werden Top-Up-Konditionen im Verhandlungsgespräch mit SAP gesichert?

Controlling übernimmt die Brücke zwischen BTP-Verbrauch und interner Budgetsteuerung: Werden BTP-Kosten verursachergerecht auf Projekte und Kostenstellen verrechnet? Stimmt das BTP-Budget mit den tatsächlichen Kosten überein? Welche Abweichungen werden im Management-Reporting sichtbar?

Der Executive trägt die Entscheidungsverantwortung bei Schwellenfragen: Wird das Renewal-Commitment erhöht oder reduziert? Welche neuen BTP-Use-Cases werden strategisch priorisiert? Wie wird das BTP-Budget in der Gesamtplanung positioniert?

Vier Steuerungsmomente-Bereiche im BTP-Kontext

Die laufende BTP-Steuerung berührt alle vier Steuerungsmomente-Bereiche des FinOptory-Governance-Modells.

Nutzung: Welche Services werden wie intensiv genutzt? Welche Service-Plans sind aktiv, aber ungenutzt? Wo gibt es Shelfware? Wo wächst der Verbrauch unerwartet?

Berechtigungen: Welche Subaccounts haben Zugriff auf welche Services? Sind die Entitlement-Strukturen im Global Account konsistent mit den organisatorischen Zuständigkeiten? Werden Services von nicht autorisierten Subaccounts aktiviert?

Infrastruktur: Welche Runtimes laufen produktiv, welche nur für Dev/Test? Laufen Non-Production-Umgebungen außerhalb der Betriebszeiten? Welche Services fallen in Deprecation Group 2 und erfordern ein aktives Migrationsvorbereitung?

Kosten: Wie entwickelt sich der Credit-Verbrauch relativ zum Budget? Gibt es Overages oder drohen sie? Werden BTP-Kosten verursachergerecht auf Kostenstellen verrechnet? Stimmt das Commitment für die nächste Periode mit der Verbrauchsprognose überein?

Quarterly Business Review für BTP

Ein Quarterly Business Review (QBR) für BTP ist das strukturelle Steuerungsinstrument auf Management-Ebene. Es verdichtet die monatlichen Tracking-Daten zu einem strategischen Lagebild und adressiert Entscheidungen, die über den Tagesrhythmus hinausgehen: Vertragsmodell-Überprüfung, Renewal-Vorbereitung, strategische Priorisierung neuer BTP-Use-Cases und interne Budget-Planung für die Folgeperiode.

Der QBR-Inhalt sollte Verbrauchstabstand versus Jahresziel, Overage-Risikobewertung, Shelfware-Identifikation, Service-Deprecation-Status für genutzte Gruppe-2-Services und eine Empfehlung zur Commitment-Kalibrierung für das nächste Jahr umfassen.

Audit-Readiness und jährliches Compliance-Review

BTP-Verträge unterliegen wie alle SAP-Verträge dem Audit-Recht von SAP. Audit-Readiness bedeutet, dass die Balance Statements der vergangenen Perioden vollständig dokumentiert sind, alle Service-Aktivierungen nachvollzogen werden können und die Subaccount-Struktur konsistent mit den vertraglichen Entitlements ist. Ein jährliches Compliance-Review prüft diese Punkte systematisch und identifiziert etwaige Inkonsistenzen, bevor sie in einem SAP-Audit sichtbar werden.

---

12. Interne Verrechnung: BTP-Kosten auf Projekte und Kostenstellen allokieren {#interne-verrechnung}

Warum verursachergerechte Verrechnung ohne Subaccount-Struktur kaum möglich ist

Die Forderung nach verursachergerechter interner Verrechnung von BTP-Kosten ist in den meisten größeren Unternehmen ein Controlling-Standard. In der Praxis lässt sie sich ohne eine entsprechend strukturierte Subaccount-Architektur nicht erfüllen.

SAP liefert monatliche Balance Statements auf Subaccount-Ebene. Wer BTP-Kosten intern auf Projekte oder Kostenstellen verrechnen will, braucht Subaccounts, die diesen Projekten oder Kostenstellen entsprechen. Wenn alle BTP-Workloads im gleichen Subaccount laufen, gibt es keine technische Basis für eine differenzierte interne Verrechnung.

Subaccount als Zurechnungseinheit: Organisatorisches Design als Voraussetzung

Die Entscheidung, wie Global Accounts und Subaccounts organisiert werden, ist eine Governance-Entscheidung, keine rein technische. Sie bestimmt, für welche Granularität eine verursachergerechte BTP-Kostenverrechnung möglich ist.

Typische Organisationsprinzipien für Subaccounts sind: nach Geschäftsbereichen (ein Subaccount pro Business Unit), nach Projekten (ein Subaccount pro BTP-Projekt), nach Umgebungen mit Projekt-Trennung (je ein Subaccount für Produktion, Test und Entwicklung pro Projekt) oder nach Kostenstellen. Je granularer die Subaccount-Struktur, desto präziser ist die verursachergerechte Verrechnung.

Die Herausforderung: Eine zu granulare Struktur erzeugt Verwaltungsaufwand und kann die Entitlement-Zuweisung komplizieren. Die richtige Balance hängt von der Organisationsstruktur und den Controlling-Anforderungen des Unternehmens ab.

Credit-Rate als interne Verrechnungsgrundlage

Was der Kostenstellen-Owner wissen muss: BTP-Kosten entstehen nicht in Euro, sondern in Credits, die anschließend in Euro umgerechnet werden. Die Credit-Rate, also der vertraglich fixierte Preis pro Capacity Unit, ist die Grundlage der internen Verrechnung.

Für die Kostenstelle bedeutet das: Sie zahlt intern nicht den Listenpreis, sondern den verhandelten Vertrags-Credit-Preis. Dieser Unterschied ist erheblich, wenn das Enterprise Agreement 25 bis 35 Prozent Rabatt auf den Listenpreis enthält. Die interne Verrechnung sollte die tatsächlich anfallenden Vertragskosten widerspiegeln und nicht den Listenpreis.

Showback versus Chargeback: Zwei Modelle für interne Transparenz

Zwei Modelle der internen BTP-Kostenverteilung haben sich etabliert, die sich in ihrer Bindungswirkung unterscheiden.

Showback zeigt Kostenstellen und Projekten ihre BTP-Kosten, ohne eine tatsächliche interne Buchung vorzunehmen. Das Ziel ist Transparenz und Bewusstsein für den eigenen Verbrauch. Showback ist der einfachere Einstieg, weil es keine Anpassung interner Buchungsprozesse erfordert. Es schafft Steuerungsimpulse durch Sichtbarkeit, aber keine harte Budget-Verantwortung bei den Verbrauchern.

Chargeback verrechnet BTP-Kosten tatsächlich auf Kostenstellen oder Projekte, entweder durch interne Buchungen oder durch entsprechende Budgetzuweisung. Chargeback schafft echte Kostenverantwortung bei den Verbrauchern und gibt ihnen einen direkten Steuerungsimpuls: Wer mehr BTP-Ressourcen nutzt, sieht das in seinem Budget. Chargeback erfordert eine reifere interne Finanzstruktur und eine funktionierende Subaccount-Architektur als Voraussetzung.

Die FinOps Foundation beschreibt Showback als Reifeschritt auf dem Weg zu Chargeback. Viele Organisationen beginnen mit Showback, um zunächst Transparenz zu schaffen, bevor sie den komplexeren Chargeback-Prozess einführen.

Was SAP-eigene Tools leisten und wo die Grenzen liegen

Das BTP Cockpit und die monatlichen Balance Statements liefern die Rohdaten für interne Verrechnung. Sie zeigen Verbrauch pro Subaccount und pro Service. Sie liefern jedoch keine direkte Integration in interne ERP-Systeme, keine Kostenstellenzuordnung jenseits der Subaccount-Ebene und keine automatisierte Buchungslogik.

Wer eine vollautomatisierte Chargeback-Lösung anstrebt, muss die Balance-Statement-Daten in das interne Controlling-System übernehmen und dort verarbeiten. Das ist lösbar, erfordert aber einen eigenen Prozess und möglicherweise eine technische Integration.

Wie der Steuerungsmoment "Kosten" mit BTP zusammenhängt

Der Steuerungsmoment im Bereich Kosten umfasst für BTP vier miteinander verbundene Dimensionen: ACV-Tracking (Stimmt das kontraktierte Jahresvolumen mit dem tatsächlichen Verbrauch überein?), Derived Charges (Entstehen unerwartete Overage-Kosten, die im ursprünglichen Budget nicht geplant waren?), Rechnungsabgleich (Stimmt die SAP-Rechnung mit den erwarteten Balance-Statement-Daten überein?) und interne Verrechnung (Werden BTP-Kosten verursachergerecht auf die organisatorischen Einheiten verteilt, die sie erzeugen?).

Alle vier Dimensionen sind nur mit einem strukturierten Governance-Prozess adressierbar. Wer BTP-Kosten vollständig steuern will, braucht nicht nur Cockpit-Zugriff, sondern ein systematisches Steuerungsmodell, das Vertragsstruktur, Monitoring, Forecast und interne Verrechnung verbindet.

---

13. FAQ {#faq}

Was ist der Unterschied zwischen CPEA und BTPEA und welches Modell passt wann?

CPEA und BTPEA teilen die gleiche Grundlogik: Vorab-Kauf von Credits, flexible Nutzung über einen Servicekatalog, Volumenrabatte. Der Unterschied liegt im Service-Scope. CPEA hat einen historisch breiten Katalog, der keine neuen Services mehr aufnimmt. BTPEA enthält alle neuen und strategischen Services exklusiv, darunter SAP Analytics Cloud und neuere AI-Services. Für Neukunden ist BTPEA das empfohlene Modell. Bestandskunden auf CPEA sollten bei der nächsten Renewal prüfen, ob benötigte Services den Wechsel erfordern (Quelle: ASUG, SAP Experts Detail New BTPEA).

Was passiert mit ungenutzten BTP Credits am Jahresende?

Ungenutzte Credits verfallen am Ende der Vertragsperiode. Es gibt keinen automatischen Rollover. Ein begrenzter Rollover von 10 bis 20 Prozent der ungenutzten Credits ist in Vertragsverhandlungen als Ergebnis erzielt worden (Community Knowledge: Rizing, Redress Compliance), gehört aber nicht zur Standardvereinbarung. Die beste Strategie gegen Verfall ist eine konservative Dimensionierung mit vertraglich gesichertem Nachkaufrecht zu Ausgangsbedingungen (Quelle: SAP FAQ CPEA).

Wie wird Overage bei CPEA/BTPEA abgerechnet und was kostet das im Vergleich zum Vertragspreis?

Wenn der Credit Pool vor Ablauf der Vertragsperiode erschöpft ist, laufen Services weiter, werden aber zum vollen Listenpreis abgerechnet. Alle Volumenrabatte des Enterprise Agreements entfallen. Ein Unternehmen mit 25 Prozent Rabatt im Vertrag zahlt im Overage-Fall 100 Prozent des Listenpreises statt 75 Prozent. Ein Overage Cap, der den maximalen Aufschlag begrenzt, ist verhandelbar (Quelle: SAP FAQ CPEA; Community Knowledge: Rizing).

Was sind Capacity Units und wie rechnet man sie in Euro um?

Capacity Units (CU) sind das universelle Abrechnungsmaß über alle BTP-Services. Die Faustregel: 1 Credit entspricht grob einem Dollar Verbrauch zum Listenpreis (vertragsabhängig). Die tatsächliche Euro-Entsprechung ergibt sich aus dem im Order Form fixierten Credit-Preis multipliziert mit dem CU-Verbrauch. Der SAP Discovery Center Estimator zeigt Volumina in Credits, nicht in Euro. Die Euro-Beträge ergeben sich aus individuell verhandelten Preisen, die im Order Form festgehalten sind (Quelle: SAP Discovery Center; SAP Help Portal, Monitoring Usage and Consumption Costs).

Was ist der Unterschied zwischen Depreciation Group 1 und Group 2 bei BTP-Services?

Gruppe-1-Services in BTPEA werden bis zum Ende der aktuellen Vertragslaufzeit unterstützt, analog zur CPEA-Schutzregel. Gruppe-2-Services (Innovation Services) können nach einer Vorankündigungsfrist von mindestens 6 Monaten aus dem Katalog entfernt oder in Gruppe 1 überführt werden. Das Deprecation-Risiko von Gruppe-2-Services erfordert aktives Monitoring und eine Dokumentation aller Abhängigkeiten auf solche Services (Quelle: ASUG, SAP Experts Detail New BTPEA).

Wie viele BTP Credits sind typischerweise in einem RISE-Vertrag enthalten?

Das im RISE-Vertrag enthaltene BTP-Credit-Budget hängt von der Lizenzstufe ab. SAP gibt keine öffentlichen Standardwerte für diese Budgets an. In der Praxis ist das inkludierte Budget häufig ein Ausgangspunkt, der für umfangreichere BTP-Nutzungsszenarien im zweiten oder dritten Vertragsjahr ergänzt werden muss. Wer seinen konkreten BTP-Credit-Anteil im RISE-Vertrag kennen möchte, findet diesen im Order Form oder in der Anlage zum RISE-Vertrag.

Wie richte ich Credit-Alerts im BTP Cockpit ein?

Im BTP Cockpit können Benachrichtigungen für Subaccount-Nutzung konfiguriert werden. Die praktisch bewährte Alert-Konfiguration setzt eine erste Benachrichtigung bei 70 bis 80 Prozent Verbrauchsstand und eine zweite bei 90 Prozent. Diese Schwellenwerte geben ausreichend Zeit, proaktive Maßnahmen einzuleiten, bevor ungeplante Overages entstehen. Die genauen Konfigurationsschritte finden sich im SAP Help Portal unter Monitoring Usage and Consumption Costs (Quelle: SAP Help Portal).

Was ist das FinOps Inform-Optimize-Operate-Modell und wie gilt es für BTP?

Das Inform-Optimize-Operate-Modell der FinOps Foundation ist ein iterativer Zyklus für Technology Cost Management. Auf BTP angewendet: Inform schafft vollständige Sichtbarkeit über Entitlements, aktive Services und tatsächlichen Verbrauch. Optimize setzt aktive Maßnahmen um, zum Beispiel Rightsizing, Non-Production-Shutdown und Hyperscaler-Overlap-Bereinigung. Operate bettet die Steuerung in den regulären Betriebsrhythmus ein, mit monatlichem Tracking, quartalsweisen Reviews und jährlicher Compliance-Prüfung (Quelle: FinOps Foundation, Framework 2025; Licensing & SaaS Capability).

Wie verteile ich BTP-Kosten auf interne Kostenstellen oder Projekte?

Die Grundvoraussetzung ist eine Subaccount-Struktur, die organisatorische Einheiten, Projekte oder Kostenstellen widerspiegelt. SAP liefert monatliche Balance Statements auf Subaccount-Ebene. Diese Daten bilden die Basis für Showback (Transparenz ohne Buchung) oder Chargeback (tatsächliche interne Verrechnung). Ohne passende Subaccount-Struktur gibt es keine belastbare technische Basis für verursachergerechte Verrechnung (Quelle: SAP Help Portal, Monitoring Usage and Consumption Costs).

Was ist ein Hyperscaler-Overlap und wie erkenne ich, ob ich doppelt zahle?

Ein Hyperscaler-Overlap entsteht, wenn ein Unternehmen sowohl BTP-Services als auch vergleichbare Hyperscaler-Services (AWS, Azure, GCP) für die gleiche oder ähnliche Funktion zahlt. Typische Überschneidungsbereiche: Analytics, Datenbankservices, Integrations-Middleware, AI-Plattformdienste. Eine systematische Gegenüberstellung der genutzten BTP-Services und der Hyperscaler-Services identifiziert Redundanzen. Die Optimierungsentscheidung sollte auf dem jeweiligen Mehrwert basieren: SAP-spezifische Integrationen und SAP-Datenstrukturen rechtfertigen BTP-Services; generische Cloud-Workloads können günstiger auf dem Hyperscaler laufen.

Wann ist eine Migration von CPEA zu BTPEA sinnvoll?

Eine Migration ist sinnvoll, wenn das Unternehmen Services benötigt, die ausschließlich in BTPEA verfügbar sind (SAP Analytics Cloud, neuere AI-Services), oder wenn die Zukunftssicherheit des Vertragsvehikels strategisch wichtig ist. Die Migration erfordert keine technischen Änderungen an der bestehenden BTP-Landschaft. Vor der Migration sollte eine vollständige Analyse der genutzten Services zeigen, ob alle diese Services im BTPEA-Katalog enthalten sind oder ob separate Subscriptions erforderlich werden (Quelle: ASUG, SAP Experts Detail New BTPEA).

Wie bereite ich BTP-Credit-Daten für ein Renewal-Gespräch mit SAP vor?

Ein gut vorbereitetes Renewal-Gespräch basiert auf drei Datenpunkten: Erstens der tatsächliche Jahresverbrauch der ablaufenden Periode aus den monatlichen Balance Statements, aufgeschlüsselt nach den wichtigsten Services. Zweitens ein Forecast für das nächste Vertragsjahr, der neue Use Cases, Wachstum bestehender Workloads und geplante Optimierungsmaßnahmen berücksichtigt. Drittens eine Übersicht der aktuell genutzten Services und deren Deprecation-Status im BTPEA-Katalog. Mit diesen Daten lässt sich das Renewal-Commitment fundiert begründen und die Verhandlung über Conditional Clauses wie Nachkaufrecht, Overage Cap und Rollover auf eine belegte Basis stellen.

---

14. Nächste Schritte {#naechste-schritte}

Vertragscheck buchen: Wenn Sie Ihren BTP-Vertragsanteil analysieren, das richtige Modell für die nächste Periode bewerten oder eine Grundlage für das nächste Renewal-Gespräch schaffen wollen, ist der FinOptory Vertragscheck der strukturierte Einstieg. Vier Wochen, Festpreis, mit klarer Handlungsempfehlung als Ergebnis.

FinOptory AI Chat: Für eine erste Einschätzung Ihres BTP-Vertragsanteils steht der FinOptory AI Chat zur Verfügung, ohne Vorbereitungsaufwand und ohne Upload-Pflicht.

Weiterführende Artikel: Pillar 1: SAP Contract Governance über das gesamte Portfolio | Pillar 2: SAP Business AI Units als separater Credit-Topf