BTP Credit-Verfall und Overage: Was am Jahresende mit nicht genutzten Credits passiert

Bei SAP BTP läuft das Vertragsjahr nach einer Logik, die in der Praxis regelmäßig unterschätzt wird. Ungenutzte Credits verfallen am Ende der Vertragsperiode. Wer den Credit Pool erschöpft, zahlt Overage zum vollen Listenpreis ohne Volumenrabatte. Beide Situationen sind durch strukturierte Steuerung vermeidbar. Was genau passiert, wie die Mechaniken funktionieren und wo die Steuerungsmomente liegen, erklärt dieser Artikel.

---

Use-It-or-Lose-It: Wie die Verfallsregel funktioniert

Der Ausgangspunkt ist die Grundregel im CPEA- und BTPEA-Modell: Das jährlich eingekaufte Credit-Budget ist an die Vertragsperiode gebunden. Was bis zum Ende dieser Periode nicht verbraucht ist, verfällt. Es gibt keinen automatischen Rollover in das nächste Vertragsjahr (Quelle: SAP FAQ, Consumption-based Commercial Model CPEA).

Diese Regel ist keine Ausnahme im Kleingedruckten, sondern strukturelles Merkmal des Commit-to-Consume-Modells. Wer zu Jahresbeginn ein Credit-Budget von 100.000 Credits kauft und bis Jahresende 68.000 davon verbraucht, verliert die verbleibenden 32.000 Credits. Der gezahlte Preis bleibt bestehen, der Gegenwert verfällt.

In der Praxis tritt dieser Steuerungsmoment im Bereich Nutzung regelmäßig dann auf, wenn BTP-Projekte sich verzögern, die tatsächliche Nutzungsintensität hinter der Planung zurückbleibt oder Services zwar aktiviert, aber nicht in der erwarteten Intensität eingesetzt werden. Das Jahresende als fixer Verfallstermin gibt keine Toleranz für Nachsteuerung, sobald es zu spät ist.

---

Typische Over-Commitment-Konstellationen

Over-Commitment, also ein zu hoch dimensionierter Credit Pool im Verhältnis zur tatsächlichen Nutzung, entsteht aus drei wiederkehrenden Konstellationen.

Verzögerte Projektrealisierung: BTP-Use-Cases, die bei Vertragsabschluss für das erste Vertragsjahr geplant sind, gehen erst im zweiten oder dritten Jahr produktiv. Das Credit-Budget der ersten Periode wurde auf Basis dieser Planung dimensioniert und ist nun zu hoch.

Unterschätzte Anlaufkurven: Services werden aktiviert, Prozesse gebaut, aber die tatsächliche Nutzung wächst langsamer als erwartet. Integrations-Pipelines, die mit vollem Nachrichtenvolumen geplant wurden, laufen zunächst mit einem Bruchteil davon. HANA Cloud-Instanzen stehen bereit, die Applikationsanbindung ist aber noch nicht abgeschlossen.

Optimistische Erstkalibrierung: Bei Vertragsabschluss wird häufig mit einem Sicherheitspuffer geplant, der realistisch nicht verbraucht werden kann. Dieser Puffer summiert sich über eine Drei-Jahres-Laufzeit zu erheblichen ungenutzten Beträgen.

Alle drei Konstellationen sind erkennbar, wenn der Credit-Verbrauch quartalsweise mit dem geplanten Verbrauchspfad verglichen wird. Wer diesen Abgleich nicht durchführt, stellt die Lücke erst fest, wenn der Handlungsspielraum gering ist.

---

Rollover: Was verhandelt werden kann

Ein automatischer Credit-Rollover ist kein Bestandteil des CPEA- oder BTPEA-Standardvertrags. Er ist jedoch in Vertragsverhandlungen als Ergebnis erreichbar. Als Orientierungswert aus der Praxis gilt, dass ein begrenzter Rollover von 10 bis 20 Prozent der ungenutzten Credits in Verhandlungen als Ergebnis erzielt worden ist (Community Knowledge: Rizing, Redress Compliance). Dieser Wert ist keine offizielle SAP-Vorgabe und kein garantiertes Verhandlungsergebnis.

Neben einem prozentualen Rollover gibt es weitere Verhandlungsoptionen: eine kurze Grace Period nach Ablauf der Vertragsperiode, in der ungenutztes Budget noch verbraucht werden kann, oder die Möglichkeit, ungenutzte Credits gegen andere SAP-Softwareleistungen zu verrechnen. Auch diese Optionen sind keine Standardfälle.

Die entscheidende Schlussfolgerung für die Steuerung lautet: Eine Rollover-Klausel ist kein Ersatz für ein aktives Verbrauchsmanagement. Sie ist eine Absicherung für Restvolumina, keine Lösung für systematisch zu hohe Commitments. Die strukturell bessere Maßnahme ist eine konservative Dimensionierung bei Vertragsabschluss, kombiniert mit einem vertraglich gesicherten Nachkaufrecht zu Ausgangsbedingungen.

---

Overage-Mechanik: Listenpreis und kein Rabatt

Die zweite kritische Situation ist das Gegenteil des Credit-Verfalls: der Überverbrauch. Wenn der vertraglich eingekaufte Credit Pool vor Ablauf der Vertragsperiode erschöpft ist, laufen die BTP-Services weiter. SAP stellt den Betrieb nicht automatisch ein. Stattdessen greift die Overage-Mechanik.

Overage-Credits werden zum vollen Listenpreis abgerechnet, ohne die Volumenrabatte des Enterprise Agreements (Quelle: SAP FAQ CPEA; SAP Help Portal). Die Konsequenz ist eine ausgeprägte Kostenasymmetrie: Ein Unternehmen mit 25 Prozent Rabatt im Vertrag zahlt für Overage-Credits den vollen Listenpreis, also in der Rechnung 33 Prozent mehr pro Credit als im vertraglich vereinbarten Rahmen.

Diese Asymmetrie ist der finanzielle Kern der Overage-Mechanik. Sie macht Overages nicht nur teurer als geplant, sondern strukturell schwerer steuerbar, weil der Listenpreis nicht die Verhandlungsgrundlage war, auf der die ursprüngliche Budgetplanung basierte. Overage-Kosten sind deshalb im Controlling häufig schwer zuzuordnen: Sie tauchen in der SAP-Rechnung auf, haben aber keine entsprechende interne Budgetposition.

---

Typische Overage-Treiber: Integration Suite, HANA Cloud, AI Core

Overage entsteht nicht zufällig. Drei Services sind erfahrungsgemäß die häufigsten Treiber.

Integration Suite Volumenunterschätzung: Die Integration Suite rechnet nach Nachrichtenvolumen ab. Was bei der Planung als 100.000 Nachrichten pro Monat erscheint, kann in der Produktion durch File-Splits, Retry-Logik bei Fehlern und größere Payload-Strukturen ein Vielfaches ergeben. Ein Batch-File, das als eine Nachricht geplant war, erzeugt nach dem Split hunderte Einzelnachrichten. Integrations-Volumen-Monitoring ist deshalb einer der kritischsten BTP-Steuerungsmomente überhaupt. Ohne laufendes Monitoring ist der Übergang von geplanter Nutzung zu Overage-Territorium schwer erkennbar.

SAP HANA Cloud: HANA Cloud ist in vielen BTP-Setups der größte einzelne Credit-Verbraucher. Eine Produktionsinstanz mit relevantem Arbeitsspeicher kann den jährlichen Credit Pool stärker belasten als alle anderen Services zusammen, besonders wenn im Projektverlauf Kapazitäten nachträglich erhöht werden. Kapazitätserweiterungen, die in der ursprünglichen Dimensionierung nicht vorgesehen waren, sind ein struktureller Overage-Auslöser, der häufig keine explizite Budgetfreigabe hat.

AI Core und Generative AI Hub: AI-Workloads haben ein besonderes Verbrauchsprofil. Der Token-Verbrauch von Sprachmodellen variiert erheblich mit Use Case, Modellauswahl und Nutzungsintensität. Was in einem kleinen Piloten vorhersagbar schien, kann bei produktivem Scale-up zu einem exponentiell wachsenden Credit-Verbrauch führen. AI-Workloads auf BTP sollten deshalb von Beginn an mit Monitoring-Alerts ausgestattet sein.

---

Self-Reporting-Pflicht: Was Kunden wissen müssen

Ein Aspekt der BTP-Vertragslogik, der in der Praxis häufig nicht ausreichend bekannt ist: In vielen BTP-Verträgen liegt die Pflicht zur Meldung von Übernutzung beim Kunden, nicht automatisch bei SAP (Quelle: SAP FAQ CPEA). Das bedeutet, dass Overages, die sich unbemerkt über mehrere Monate aufbauen, am Jahresende als Nachbelastung erscheinen können.

Diese Self-Reporting-Pflicht ist ein struktureller Steuerungsmoment im Bereich Kosten. Wer Overages nicht trackt und nicht meldet, übernimmt ein Risiko, das sich erst dann vollständig zeigt, wenn die Abrechnungsperiode geschlossen ist. Monatliches Credit-Monitoring ist keine optionale Optimierungsmaßnahme, sondern eine Voraussetzung für die Erfüllung vertraglicher Pflichten.

---

Alert-Strategie: Wann handeln, bevor es zu spät ist

Die praktisch wirksamste Maßnahme gegen ungeplante Overages ist eine klar definierte Alert-Strategie mit zwei Schwellenwerten.

Erste Stufe bei 70 bis 80 Prozent Credit-Verbrauch: Diese Schwelle signalisiert, dass der Credit Pool zu mehr als drei Vierteln ausgeschöpft ist. Bei diesem Stand ist noch ausreichend Zeit, um proaktiv zu handeln: Verbrauchsanalyse durchführen, laufende Non-Production-Umgebungen prüfen und bei Bedarf das Gespräch mit SAP über einen Top-Up zu Vertragsbedingungen aufnehmen.

Zweite Stufe bei 90 Prozent: Diese Schwelle ist der späteste Zeitpunkt, um ein Top-Up zu initiieren. Wer jetzt noch nicht handelt, riskiert ungeplante Overages. Der Unterschied zwischen einem geplanten Top-Up zu Vertragsbedingungen und einem ungeplanten Overage zum Listenpreis ist erheblich: Im ersten Fall gelten die verhandelten Konditionen des Enterprise Agreements, im zweiten Fall entfallen alle Rabatte.

Das BTP Cockpit ermöglicht die Konfiguration von Benachrichtigungen für Subaccount-Nutzung. Diese Alert-Konfiguration sollte als Standard-Setup in jeder produktiven BTP-Umgebung vorhanden sein, nicht als Reaktion auf einen ersten Overage-Fall.

Ein vertraglich gesichertes Nachkaufrecht zu Ausgangsbedingungen ist die Voraussetzung dafür, dass der Top-Up beim Erreichen der 70-bis-80-Prozent-Schwelle zu kalkulierbaren Kosten erfolgen kann. Ohne dieses Nachkaufrecht hängt der Preis des Top-Ups von der Verhandlungsposition zum Zeitpunkt des Bedarfs ab, nicht von den ursprünglichen Vertragskonditionen.

---

Wie Steuerungsmomente Credit-Verfall und Overage verbinden

Sowohl Credit-Verfall als auch Overage sind Symptome desselben strukturellen Problems: fehlende laufende Steuerung des BTP-Credit-Budgets. Beide Situationen sind am Ende des Vertragsjahres häufig nicht mehr vollständig korrigierbar. Sie sind aber beide früh erkennbar, wenn die richtigen Steuerungsmomente genutzt werden.

Der quartalsweise Verbrauchsreview ist der Steuerungsmoment, der Over-Commitment erkennt, bevor der Verfall eintritt. Er vergleicht den kumulierten Verbrauch mit dem geplanten Verbrauchspfad und identifiziert, ob Gegenmaßnahmen wie Aktivierung zusätzlicher Dev/Test-Workloads oder ein proaktives Gespräch mit SAP über eine Vertragsanpassung einzuleiten sind.

Das monatliche Credit-Monitoring mit Alert-Konfiguration ist der Steuerungsmoment, der Overages verhindert. Er signalisiert frühzeitig, wenn der Verbrauch schneller wächst als geplant, und gibt die Zeit, um einen Top-Up zu Vertragsbedingungen zu sichern, bevor der Listenpreis greift.

Beide Steuerungsmomente fallen in den Bereich Nutzung und Kosten des FinOptory-Governance-Modells. Sie erfordern keine aufwändige Infrastruktur, aber einen strukturierten Rhythmus: Wer BTP-Credits monatlich trackt und quartalsweise bewertet, hat die wesentlichen Hebel in der Hand.

---

Häufige Fragen

Was passiert, wenn ich am Jahresende noch viele ungenutzte Credits habe?

Ungenutzte Credits verfallen am Ende der Vertragsperiode. Es gibt keinen automatischen Rollover. Der bezahlte Preis bleibt, der Gegenwert ist verloren. Ein begrenzter Rollover ist in Vertragsverhandlungen als Ergebnis erreichbar, aber kein Standardbestandteil. Die wirksamere Steuerungsmaßnahme ist ein quartalsweiser Verbrauchsabgleich, der eine Unterauslastung frühzeitig sichtbar macht (Quelle: SAP FAQ CPEA).

Kann ich vor dem Jahresende noch zusätzliche Credits kaufen, um den Pool aufzufüllen?

Ja, wenn das vertraglich gesicherte Nachkaufrecht zu Ausgangsbedingungen vorhanden ist. Ohne diese Klausel hängt der Preis eines Top-Ups von der Verhandlungssituation zum Zeitpunkt des Bedarfs ab. Das Nachkaufrecht sollte deshalb bei Vertragsabschluss oder bei der nächsten Renewal explizit verankert werden (Community Knowledge: Rizing, SAP BTP Licensing Models).

Ab wann sollte ich das Gespräch über einen Top-Up mit SAP suchen?

Die praktisch bewährte Schwelle liegt bei 70 bis 80 Prozent Credit-Verbrauch. Bei diesem Stand ist noch ausreichend Zeit für eine strukturierte Abstimmung. Wer bis 90 Prozent wartet, hat deutlich weniger Handlungsspielraum. Wer das Kontingent überschreitet, zahlt den Listenpreis ohne Volumenrabatte.

Wie kann ein Overage Cap helfen?

Ein Overage Cap ist eine Vertragsklausel, die festlegt, bis zu welchem Vielfachen des Vertragspreises Overage maximal abgerechnet werden darf. Ein Cap bei 110 Prozent des Listenpreises bedeutet, dass keine Overage-Credits teurer werden als 10 Prozent über dem Listenpreis. Diese Klausel begrenzt das Budget-Risiko in Szenarien mit unerwartetem Verbrauchsanstieg. Sie ist in Vertragsverhandlungen erreichbar, aber kein Standardbestandteil.

---

Nächste Schritte

Vertragscheck buchen: Wenn Sie Ihren aktuellen BTP-Credit-Stand analysieren, das Overage-Risiko für die laufende Periode bewerten oder eine fundierte 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 Ihrer BTP-Credit-Situation steht der FinOptory AI Chat zur Verfügung, ohne Vorbereitungsaufwand.

Weiterführende Artikel: BTP FinOps: Hub-Artikel mit vollständiger Credit-Mechanik | Capacity Units und Depreciation Groups verstehen | BTP-Monitoring und Steuerbarkeit im Betrieb