SAP Renewal Negotiation Framework: Renewal-Vorbereitung ueber 12 bis 18 Monate

SAP-Vertragserneuerungen entstehen nicht in den letzten Wochen vor Laufzeitende, sondern im 12-bis-18-Monats-Fenster davor. Wer in dieser Phase Verbrauchsdaten konsolidiert, kritische Klauseln prüft und Stakeholder ausrichtet, betritt das Renewal mit strukturierter Verhandlungsposition. Wer wartet, verhandelt unter Zeitdruck, mit lückenhafter Datenbasis und bei aktivem Auto-Renewal-Risiko.

Inhaltsverzeichnis

1. Warum Renewal-Vorbereitung 12 bis 18 Monate beginnt
2. Vier Phasen: Der Renewal-Zeitplan
3. Datenbasis aufbauen: Was zählt und was nicht
4. BTP-Verbrauchsdaten als Verhandlungs-Input
5. Kritische Klauseln: Was im nächsten Vertrag stehen muss
6. CPI-Klauseln und Preisanpassungsmechanismen
7. Self-Report-Pflicht und Overage-Governance vor Renewal
8. Stakeholder-Modell: Wer muss wann eingebunden sein
9. Auto-Renewal: Fristen, Risiken, Handlungsoptionen
10. Exit-Rechte: Was verhandelt werden sollte
11. HowTo: Renewal-Readiness in 10 Schritten
12. FAQ
13. Nächste Schritte

---

Warum Renewal-Vorbereitung 12 bis 18 Monate beginnt {#warum-renewal-vorbereitung-12-bis-18-monate-beginnt}

Renewal ist kein Termin, der am Laufzeitende entsteht. Es ist ein strukturierter Steuerungsmoment, der 12 bis 18 Monate vor diesem Termin beginnt und über alle vier Steuerungsbereiche hinweg gesteuert werden muss: Nutzung, Berechtigungen, Infrastruktur und Kosten. Wer diesen Steuerungsmoment systematisch nutzt, betritt das Verhandlungsgespräch mit vollständiger Datenbasis. Wer ihn verpasst, gibt den Steuerungsmoment ab.

Die Mechanik des RISE Enterprise Agreements setzt strukturelle Fristen, die keine Ausnahme kennen. Wer diese Fristen verpasst, kann nicht mehr aktiv gestalten, sondern nur noch auf die Bedingungen des Gegenübers reagieren.

Auto-Renewal als strukturelle Ausgangslage

Das RISE Enterprise Agreement verlängert sich ohne aktive Kündigung automatisch. Die Verlängerungslaufzeit entspricht in der Regel der ursprünglichen Vertragslaufzeit, sofern nichts anderes vereinbart wurde. Dieser Mechanismus ist kein Sonderfall, sondern der vertraglich vorgesehene Standard.

Was diese Ausgangslage für die Planung bedeutet: Ohne eine aktive Entscheidung läuft der Vertrag weiter, zu Konditionen, die SAP nach vertraglichen Regeln anpassen darf. Das 45-Tage-Ankündigungsfenster für Preiserhöhungen (Schedule 5, öffentlich) ist dabei die relevante Bezugsgröße, nicht das Laufzeitende selbst. Wer erst reagiert, wenn die Ankündigung eingeht, hat den Steuerungsmoment bereits verpasst.

Für die Governance-Praxis bedeutet das: Der Renewal-Kalender beginnt nicht mit dem Ablaufdatum, sondern mit dem Rückrechnungsdatum. Wenn ein RISE-Vertrag beispielsweise am 31. März 2028 endet und SAP eine dreimonatige Kündigungsfrist vorsieht, ist der späteste Steuerungsmoment für eine aktive Entscheidung der 31. Dezember 2027. Strukturierte Vorbereitung beginnt deshalb spätestens ab dem 30. September 2026, also 18 Monate vor Vertragsende.

Guthaben-Verfall am Vertragsende

Ein Steuerungsmoment, der im letzten Vertragsjahr seine volle Wirkung entfaltet: Der degressive Roll-Over-Mechanismus im RISE Enterprise Agreement reduziert den übertragbaren Guthabenanteil je Vertragsjahr. Im letzten Jahr verfällt restliches Guthaben vollständig ohne Möglichkeit zum Übertrag.

In der Praxis bedeutet das: Der Steuerungsdruck entsteht nicht am Laufzeitende, sondern im vorletzten Vertragsjahr. Wer erkennt, dass das eigene Guthaben das geplante Verbrauchsprofil übersteigt, hat im Vorjahr noch Möglichkeiten: Nutzung ausweiten, Guthaben in CAS-Pakete umschichten oder die Diskussion über ein Volumenanpassung aufnehmen. Im letzten Jahr sind diese Steuerungsoptionen eingeschränkt, weil Sperrfristen für neue Subskriptionen greifen. Die letzten sechs Monate vor Vertragsende lassen keine neuen Managed-Service- oder Software-Subskriptionen mehr zu, die letzten zwölf Monate keine neuen CAS-Einheiten.

Wer diese Friststruktur kennt, plant Guthaben-Nutzung und Renewal-Vorbereitung als verbundene Aufgabe.

SAP beginnt früher als der Kunde

Ein struktureller Aspekt, der in der Renewal-Vorbereitung regelmäßig unterschätzt wird: SAP startet den Renewal-Dialog auf Kundenseite typischerweise 12 bis 18 Monate vor Laufzeitende. Das SAP-Renewal-Team arbeitet mit strukturierten Vertriebsprozessen, vollständiger Verbrauchshistorie aus SAP-eigenen Systemen und einer klaren Zielsetzung für den nächsten Vertragsabschluss.

Dieser zeitliche Vorsprung erzeugt eine Informationsasymmetrie: SAP kennt die Verbrauchsdaten aus eigenen Systemen. Kunden, die ihre eigene Verbrauchssituation nicht systematisch aufbereitet haben, treten einem strukturierten Counterpart gegenüber, ohne gleichwertige Datenbasis. Diese Situation ist nicht unvermeidlich, sie entsteht dort, wo Verbrauchsdaten nicht kontinuierlich konsolidiert werden.

Der Steuerungsmoment Renewal ist damit auch ein Steuerungsmoment für Informations-Parität: Wer im Vorfeld in den gleichen Steuerungsbereichen Nutzung, Berechtigungen, Infrastruktur und Kosten belastbare Daten hat, tritt das Gespräch auf gleicher Informationsgrundlage an.

Der Steuerungsmoment Renewal

Renewal ist kein administrativer Vorgang. Es ist der zentrale kommerzielle Steuerungsmoment im SAP-Vertragszyklus. Die Qualität des nächsten Vertrags, Volumen, Preise, Klauseln, Flexibilitätsoptionen, hängt von der Vorbereitung ab, die in den 12 bis 18 Monaten zuvor geleistet wurde.

Alle vier Steuerungsbereiche sind beim Renewal gleichzeitig relevant. Nutzungsdaten zeigen, welche Komponenten ausgelastet sind und wo Potenzial zur Volumenanpassung besteht. Berechtigungsdaten belegen die korrekte FUE-Allokation und identifizieren Optimierungspotenzial bei Lizenzklassen. Infrastrukturdaten liefern die Grundlage für ein sachgerechtes Sizing der nächsten Laufzeit. Kostendaten ermöglichen eine fundierte Bewertung von Preisänderungen und Renewal-Szenarien. Wer nur einen dieser Bereiche berücksichtigt, verhandelt mit unvollständiger Grundlage.

Nach Unterzeichnung des neuen Vertrags sind Konditionen für die nächste Laufzeit fixiert. Der nächste Steuerungsmoment dieser Größenordnung kommt erst wieder in drei bis sieben Jahren.

---

Vier Phasen: Der Renewal-Zeitplan {#vier-phasen-der-renewal-zeitplan}

Ein strukturierter Renewal-Prozess lässt sich in vier Phasen gliedern. Jede Phase hat klare Aufgaben, Verantwortliche und ein definiertes Ergebnis. Das Phasen-Modell beginnt 18 Monate vor Vertragsende (M-18) und endet mit der Unterzeichnung und der Transition-Governance für die neue Laufzeit (M-0).

Phase 1 (M-18 bis M-12): Bestandsaufnahme und Datenbasis

Phase 1 legt die Grundlage für alles Folgende. Das Ziel ist eine vollständige und aktuelle Datenbasis über die eigene Vertragsposition: Was ist vertraglich vereinbart? Was wird tatsächlich genutzt? Wo gibt es Abweichungen?

Verbrauchsdaten konsolidieren. FUE-Auslastung je User-Typ (Advanced Use, Core Use, Self-Service Use, Developer Access) für die letzten 12 bis 18 Monate aufbereiten. BTP-Credit-Verlauf je Subaccount und Projektbereich dokumentieren. Cloud-Managed-Services-Nutzung gegen eingekauftes Volumen stellen. CAS-Paket-Nutzung: bezahltes Volumen gegen tatsächlich in Anspruch genommene Leistung.

Vertragsdokumentation aktualisieren. Order Form, alle Schedules, Amendments und Sondervereinbarungen auf Aktualität prüfen. Schedule 5 als Preislistenreferenz validieren: Stückpreise, Staffelstufen, Mindestmengen. Guthaben-Entwicklung je Vertragsjahr aus den Balance Statements nachvollziehen. Subskriptions-Mindestlaufzeiten und aktuelle Sperrfristen dokumentieren.

Unternutzung identifizieren. Komponenten, für die Guthaben aufgewendet wird, ohne dass der vereinbarte Nutzungsumfang ausgeschöpft wird, sind in dieser Phase zu identifizieren. Diese Feststellung ist keine Kritik am bisherigen Betrieb, sondern die Grundlage für eine sachgerechte Volumenplanung der nächsten Laufzeit.

Qualitätsdaten aufbereiten. SLA-Compliance der letzten 12 bis 18 Monate auswerten. Ticket-Volumen und Service-Request-Durchlaufzeiten dokumentieren. Ungelöste Eskalationen als dokumentierten Sachstand festhalten.

Das Ergebnis von Phase 1 ist eine vollständige Übersicht über die eigene Vertragsposition: Was steht vereinbart, was wurde tatsächlich genutzt, und was ist der Delta.

Phase 2 (M-12 bis M-9): Interne Ausrichtung und Szenario-Analyse

Phase 2 bereitet die Entscheidungsgrundlage vor. Das Ziel ist ein intern abgestimmtes Bild der eigenen Anforderungen für die nächste Laufzeit.

Stakeholder konstituieren. Die vier Rollen, die für das Renewal relevant sind, werden in Phase 2 aktiv eingebunden: Contract Manager, Procurement, Controlling und Executive. Jede Rolle bringt eine spezifische Perspektive, deren Fehlen in späteren Phasen Entscheidungslücken erzeugt. Wer das Stakeholder-Team erst in Phase 3 oder 4 zusammenstellt, verliert Vorlaufzeit.

Drei Szenarien definieren. Nicht jedes Renewal erfordert eine vollständige Neuverhandlung. Ein klarer Blick auf drei Grundszenarien schärft die interne Diskussion: Status-quo-Renewal ohne Anpassungen, Volumen- oder Komponentenanpassung auf Basis der Nutzungsdaten, oder vollständige Neuverhandlung mit geänderten Vertragsparametern. Jedes Szenario hat unterschiedliche Konsequenzen für Zeitplan, Budget und Ressourceneinsatz.

Projektionsbedarf bestimmen. Welche Nutzungsmengen für die nächste Laufzeit geplant sind, ergibt sich aus dem Abgleich von Ist-Verbrauch und geplanten Veränderungen: neue Module, veränderte Nutzerpopulation, geplante BTP-Erweiterungen, AI-Unit-Bedarf. Dieser Projektionsbedarf ist Basis für alle folgenden Budget-Szenarien.

Externe Einschätzung einholen. Wo interne Datenlage oder Marktkenntnis unvollständig sind, ist Phase 2 der richtige Zeitpunkt für eine unabhängige Bewertung der eigenen Vertragsposition.

Das Ergebnis von Phase 2 ist ein intern abgestimmter Entscheidungsrahmen: Welches Szenario wird angestrebt, welche Parameter sind verhandelbar, und welches Budget-Spektrum ist freigegeben.

Phase 3 (M-9 bis M-6): Klausel-Review und Verhandlungsvorbereitung

Phase 3 übersetzt Datenlage und Szenarien in eine konkrete Verhandlungsposition. Das Ziel ist eine vollständige Bewertung der kritischen Klauseln im aktuellen Vertrag und eine dokumentierte Ausgangslage für das Gespräch mit SAP.

Kritische Klauseln identifizieren. Preisanpassungsklausel, Auto-Renewal-Klausel, SLA-Struktur, Exit-Rechte, Divestiture-Klausel und Subskriptions-Flexibilität werden im aktuellen Vertrag bewertet. Diese sechs Klausel-Bereiche entscheiden über die Steuerbarkeit des nächsten Vertrags. Sektion 5 dieses Frameworks beschreibt sie im Detail.

BTP-Verbrauchsdaten strukturieren. Die in Phase 1 aufbereiteten BTP-Daten werden als strukturierter Input für die Renewal-Verhandlung aufbereitet: Zeitreihe über 12 bis 18 Monate, Projektzuordnung, Kostenstellenstruktur, Credit-Volumen-Kalibrierung für die neue Laufzeit.

Erste Gespräche mit SAP aufnehmen. Proaktiver Kontakt mit dem SAP-Renewal-Team, bevor SAP seinerseits die Initiative ergreift, setzt ein anderes Signal als reaktives Warten. Wer den Gesprächszeitpunkt selbst bestimmt, gestaltet den Rahmen des Renewal-Dialogs.

Das Ergebnis von Phase 3 ist eine vollständige Verhandlungsposition: Klausel-Delta zwischen aktuellem und gewünschtem Vertrag, strukturierte Datenbasis, und ein initialer Gesprächsstand mit SAP.

Phase 4 (M-6 bis M-0): Verhandlung, Abschluss, Transition

Phase 4 ist die Umsetzungsphase. Die Grundlage wurde in den vorherigen Phasen gelegt. Jetzt wird verhandelt, entschieden und abgeschlossen.

Verhandlung mit vorbereiteter Datenbasis. Verhandlungsführung auf Basis der Datenlage aus Phase 1 bis 3: Nutzungsauswertung, Klausel-Delta, Budget-Szenarien. Der Executive gibt in dieser Phase den Verhandlungsrahmen frei.

Auto-Renewal-Kündigung als taktische Option. Die ordentliche Kündigung als Reaktion auf eine Preiserhöhungs-Ankündigung ist ein vertraglich vorgesehenes Recht (SAP-Standard, Schedule 5). Sie kann als Signal im Verhandlungsprozess eingesetzt werden, ohne dass eine tatsächliche Absicht zur Beendigung des Vertragsverhältnisses dahinterstehen muss.

Sperrfristen beachten. In den letzten sechs Monaten vor Vertragsende lassen sich keine neuen Managed-Service- oder Software-Subskriptionen einbuchen. In den letzten zwölf Monaten sind keine neuen CAS-Einheiten mehr möglich. Notwendige Komponentenanpassungen müssen vor diesen Fristen abgeschlossen sein.

Transition-Governance einrichten. Was läuft unter dem alten Vertrag bis Laufzeitende, was startet unter dem neuen Vertrag? Diese Frage ist vor der Unterzeichnung zu klären, nicht danach.

Das Ergebnis von Phase 4 ist der unterzeichnete neue Vertrag mit dokumentierter Transition-Governance für die erste Phase der neuen Laufzeit.

---

Datenbasis aufbauen: Was zählt und was nicht {#datenbasis-aufbauen-was-zaehlt-und-was-nicht}

Verhandlungsposition ist keine Verhandlungstechnik, sondern eine Frage der Datenlage. Vier Datenkategorien bestimmen, wie belastbar die eigene Position in einem Renewal-Gespräch ist. Wer sie vollständig hat, kann jede Frage zu Volumen, Preis und Klausel sachlich beantworten. Wer sie unvollständig hat, verliert Steuerungsmomente, weil er auf SAP-Aussagen reagieren muss, anstatt eigene Fakten einzubringen.

Verbrauchsdaten: Tatsächliche Nutzung

FUE-Auslastung je User-Typ ist die wichtigste Verbrauchskennzahl. Advanced-Use-User (1 FUE je User), Core-Use-User (1 FUE für 5 User) und Self-Service-Use-User (1 FUE für 30 User) haben unterschiedliche Wertbeiträge pro eingesetztem Guthaben. Wer die tatsächliche Auslastung je User-Typ kennt, kann die FUE-Allokation für die nächste Laufzeit sachgerecht planen.

BTP-Credit-Verbrauch je Subaccount und Projekt liefert das granulare Bild der Cloud-Plattform-Nutzung. Welche BTP-Services werden produktiv eingesetzt, welche sind Test- und Entwicklungsumgebungen, und wie hat sich das Verbrauchsvolumen über die letzten 12 bis 18 Monate entwickelt?

Cloud-Managed-Services-Nutzung gegen eingekauftes Volumen zeigt, ob die Infrastrukturkomponenten des RISE-Pakets dem tatsächlichen Betriebsbedarf entsprechen. Infrastruktur-Überkapazitäten sind kein seltener Befund, insbesondere wenn das Sizing auf einem Ausgangszustand vor der vollständigen Nutzerbasis basiert.

CAS-Paket-Nutzung: Der Abgleich von bezahltem CAS-Volumen gegen tatsächlich abgerufene Beratungs- und Betriebsleistungen ist eine häufig vernachlässigte Steuerungskennzahl. CAS-Pakete haben eine Mindestlaufzeit von zwölf Monaten und können in den letzten zwölf Monaten vor Vertragsende nicht mehr neu gebucht werden.

Vertragsdaten: Was vereinbart ist

Schedule 5 als Preislistenreferenz: Die bei Vertragsabschluss fixierten Stückpreise, Staffelstufen und Mindestmengen für alle Komponenten. Diese Preisfixierung gilt für die gesamte Laufzeit, bei Cloud-Managed-Services jedoch nur für die initiale Subskription. Bei einer Re-Subskription nach Dekommissionierung gelten neue Preise.

Guthaben-Entwicklung je Vertragsjahr aus den monatlichen Balance Statements. Wer die monatlichen Balance Statements der letzten 12 bis 18 Monate vollständig vorliegen hat, kann die Guthaben-Entwicklung nachvollziehen und das Restguthaben zum Vertragsende projizieren.

Subskriptions-Mindestlaufzeiten und Sperrfristen. Welche Komponenten haben noch laufende Mindestlaufzeiten? Welche Sperrfristen greifen in den letzten Monaten vor Vertragsende? Diese Information ist für die Planung von Komponentenanpassungen unerlässlich.

Sondervereinbarungen in der Order Form. Amendments, Transformation-Incentive-Vereinbarungen, spezifische Sonderkonditionen. Diese Dokumente stehen über den Standard-Schedules und sind häufig der Ort, an dem im ursprünglichen Verhandlungsprozess relevante Zugeständnisse verankert wurden.

Marktdaten: Was öffentlich verfügbar ist

Öffentlich verfügbare Marktdaten aus DSAG-Berichten, Analystenanmerkungen von Gartner und Forrester sowie spezialisierten Quellen wie saprisenegotiations.com und redresscompliance.com ergänzen die eigene Verbrauchsdatenlage. Sie sind keine Geheimwaffe, aber sie liefern Einordnung: Wie verhält sich die eigene Situation im Branchenvergleich?

Produkttyp-übergreifend: Für Unternehmen mit SAP-Produktportfolio über RISE hinaus, etwa SuccessFactors, Ariba oder IBP, liefern die öffentlich verfügbaren Informationen zu diesen Produkten ergänzende Orientierung.

Transition-Option und Timeline als Vergleichsmaßstab: Die Transition Option für On-Premise-Kunden nach 2030 ist öffentlich mit einem 20-prozentigen Aufschlag gegenüber vergleichbarer SAP ERP Private Edition kommuniziert, mit einem Service-Start-Fenster zwischen 2028 und 2030 (Quelle: SAP Help Portal). Diese Information ist ein sachlicher Bezugspunkt für Gespräche über Vertragskontinuität.

Qualitätsdaten: Was SAP geliefert hat

SLA-Compliance der letzten 12 bis 18 Monate: Wie oft wurde die vereinbarte Verfügbarkeit eingehalten? Gab es Abweichungen, und wurden SLA-Credits geltend gemacht? Schedule B definiert P1-Reaktionszeit und Korrekturzeit, Schedule D die SLA-Credit-Mechanik (maximal 0,25 Prozent pro Quartal, maximal fünf Prozent kumuliert, nur als Gutschrift).

Ticket-Volumen und Service-Request-Durchlaufzeiten: SAP garantiert für Service-Requests keine SLA, das ist ein bekannter Bestandteil des RISE-Betriebsmodells. Wer seine eigene Beobachtung dokumentiert, hat eine sachliche Grundlage für Gespräche über Service-Qualität.

Ungelöste Eskalationen: Als dokumentierter Sachstand, nicht als Liste von Beschwerden. Die sachliche Aufbereitung offener Fragen aus der laufenden Vertragslaufzeit ist ein legitimer Input in die Renewal-Verhandlung.

---

BTP-Verbrauchsdaten als Verhandlungs-Input {#btp-verbrauchsdaten-als-verhandlungs-input}

BTP-Credits stehen in jedem RISE-Vertrag. Sie werden jedoch selten systematisch als Verhandlungs-Input aufbereitet. Dabei sind sie der direkteste Beleg für tatsächliche Cloud-Nutzung unterhalb der FUE-Ebene: granularer, zeitlicher und projektzuordenbar.

Was BTP-Credit-Daten zeigen und was nicht

Der BTP-Credit-Verbrauch unterscheidet sich nach Service-Familien. Depreciation Group 1 (BTP-Kerndienste) und Depreciation Group 2 (kostspieligere Spezialdienste) haben unterschiedliche Credit-Gewichtungen. Diese Unterscheidung ist relevant für die Hochrechnung des Verbrauchsprofils auf die nächste Laufzeit.

AI-Unit-Verbrauch ist ein eigenständiger Datenstrang: PUPM-basierte Nutzung (Per-User-per-Month) und AI-Unit-Kontingente aus dem RISE-Bundle sind separate Verbrauchstöpfe, die nicht gegeneinander verrechnet werden können. Wer AI-Units innerhalb des RISE-Vertrags nutzt, muss den Verbrauch aus dem eigenen BTP-Reporting entnehmen.

Ungenutzte Credits sind kein Problem. Sie sind ein Belegstück für eine Überallokation, die bei der nächsten Laufzeitplanung korrigiert werden kann. Diese Feststellung ist sachlich, nicht wertend.

Was BTP-Credit-Daten nicht zeigen: Sie liefern keine direkte Aussage über den Euro-Gegenwert der Nutzung, weil der individuelle Preis pro Credit im Order Form vereinbart ist. Für Budgetierungszwecke ist der Abgleich mit dem vertraglich fixierten Credit-Preis notwendig.

Wie BTP-Daten in die Renewal-Datenbasis fließen

Eine Zeitreihe über 12 bis 18 Monate ist die Mindestvoraussetzung für eine belastbare Renewal-Datenbasis auf BTP-Ebene. Kürzere Zeitreihen erfassen keine saisonalen Schwankungen und führen zu unreliablen Hochrechnungen.

Projektzuordnung: Welche BTP-Nutzung ist produktiver Betrieb, welche ist Test- und Entwicklungsumgebung? Diese Unterscheidung ist wichtig, weil Entwicklungsaktivitäten nicht als Beleg für produktiven Skalierungsbedarf herangezogen werden können.

Kostenstellenzuordnung als Basis für internes Reporting: Wer BTP-Nutzung Kostenstellen zuordnen kann, ist in der Lage, das interne Reporting der letzten Laufzeit abzuschließen und die Projektionsgrundlage für die neue Laufzeit zu fundieren.

Was aus BTP-Daten für den nächsten Vertrag folgt

Credit-Volumen-Kalibrierung: Aus der 12-bis-18-Monats-Zeitreihe lässt sich ein realistisches Jahresvolumen für die nächste Laufzeit ableiten. Dabei sind geplante Ausbauprojekte, neue Integrationen und eine etwaige AI-Unit-Erweiterung als Aufschlag einzurechnen.

AI-Unit-Bedarfsplanung: Falls eine Erweiterung der Business-AI-Nutzung geplant ist, der Sprung von eingebetteten Copilot-Features zu agentischen Deployments zum Beispiel, ist dieser Bedarf frühzeitig zu quantifizieren. Agentische Deployments können das Drei- bis Zwanzigfache an AI Units gegenüber reinen Copilot-Projektionen verbrauchen. Eine Unterschätzung dieses Faktors führt zu unerwarteten Overages.

Overage-Risiko quantifizieren: Welches Volumen an BTP-Credits wird voraussichtlich in der nächsten Laufzeit benötigt? Wer dieses Volumen belastbar einschätzt, kann die Vertragsverhandlung mit konkreten Mengenangaben führen, anstatt pauschalen SAP-Sizing-Vorschlägen zuzustimmen.

Governance der BTP-Daten vor Renewal

Monatliches Balance-Statement-Review ist Pflichtunterlage: Das Balance Statement ist die einzige verlässliche Quelle für den aktuellen Guthabenstand und die einzige Grundlage für eine konsistente Zeitreihe.

Subaccount-Struktur als Reporting-Grundlage: Wer BTP-Nutzung in einer strukturierten Subaccount-Hierarchie betreibt, kann Verbrauch nach Projekt, Geschäftsbereich oder Umgebung auswerten. Diese Granularität ist mit einer flachen Subaccount-Struktur nicht herstellbar.

Wer im Unternehmen die BTP-Daten belastbar liefern kann: Die Beantwortung dieser Frage vor Beginn der Renewal-Vorbereitung spart Zeit. In vielen Unternehmen liegen BTP-Betriebsdaten beim Architektur- oder Plattform-Team, nicht beim Contract Manager. Der Renewal-Prozess erfordert eine koordinierte Datenlieferung über mehrere Funktionen hinweg.

Weiterführend: [SP-2 BTP-Verbrauchsdaten als Verhandlungs-Input] bietet Detailtiefe zu diesem Thema.

---

Kritische Klauseln: Was im nächsten Vertrag stehen muss {#kritische-klauseln-was-im-naechsten-vertrag-stehen-muss}

Nicht alle Klauseln in einem RISE-Vertrag haben gleiches Gewicht für die laufende Steuerung. Sechs Klausel-Bereiche entscheiden, ob der nächste Vertrag steuerbar ist oder ob Handlungsspielräume erst im Nachhinein sichtbar werden. Diese sechs Bereiche sollten in jedem Klausel-Review vor Renewal vollständig bewertet sein.

Preisanpassungsklausel (CPI-Mechanismus)

Wie SAP Preiserhöhungen bei Renewal ankündigen darf, ist in Schedule 5 des RISE Enterprise Agreements geregelt. Der öffentlich kommunizierte Rahmen sieht eine maximale Erhöhung von 3,3 Prozent pro Verlängerungszeitraum vor, mit einer 45-Tage-Ankündigungspflicht vor Verlängerungsbeginn (Quelle: Schedule 5, SAP-Vertragswerk). Bei verspäteter Ankündigung gilt die Erhöhung erst für die übernächste Periode.

Der Kunde hat bei einer angekündigten Preiserhöhung das Recht zur ordentlichen Kündigung. Dieses Recht ist im SAP-Standard vorgesehen und unabhängig davon, ob eine Erhöhung tatsächlich stattfindet oder nicht.

Was in diesem Klausel-Bereich verhandelt werden kann, betrifft die Formulierung und Begrenzung des Anpassungsmechanismus: absolute oder prozentuale Begrenzung, Referenzindex und Anpassungszeitraum. Eine Wechselwirkung existiert mit dem Guthaben-Mechanismus: Bei Guthabenreduktion darf SAP nach Standardbedingungen den Rabatt anpassen.

Auto-Renewal-Klausel

Die Auto-Renewal-Klausel regelt, unter welchen Bedingungen sich der Vertrag verlängert und welche Fristen gelten. Die relevanten Elemente: Verlängerungszeitraum, Kündigungsfrist, Preisbindung bei Verlängerung. Die genaue Ausgestaltung ist vertragsspezifisch und im Order Form beziehungsweise in den Schedule-Verweisen zu finden.

Was diese Klausel für die Governance bedeutet: Ohne aktive Entscheidung tritt die Verlängerung ein. Das erfordert einen aktiv gesteuerten Fristenkalender mit mindestens drei Monaten Vorlauf vor dem kritischen Entscheidungszeitpunkt.

SLA-Struktur und Geltungsbereich

Die SLA im RISE-Vertrag (Schedule B) definiert die Verfügbarkeit der Systeme, typischerweise 99,7 Prozent im Standard. Enhanced Operations (Schedule 3) für große Unternehmen sieht 99,95 Prozent vor. Was die SLA misst, ist die Logon-Fähigkeit des Systems, nicht Antwortzeiten, Batch-Fenster oder Service-Request-Qualität.

Wesentliche Einschränkungen des Geltungsbereichs: Cloud Features laufen auf separater Infrastruktur und fallen nicht unter das SLA des Hauptsystems. Service-Requests haben keine vertraglich garantierten Reaktionszeiten. Übernutzungsphasen (Overage) sind explizit vom SLA ausgeschlossen.

SLA-Credits sind im Ergebnis symbolisch: maximal 0,25 Prozent des Jahresbetrags pro Quartal, kumuliert maximal fünf Prozent, ausschließlich als Gutschrift, geltend zu machen innerhalb eines Monats nach Quartalsende, schriftlich (Schedule D). Die Performance-Governance muss deshalb operativ stattfinden, nicht über SLA-Credits.

Exit-Klauseln und Datenportabilität

Was bei Vertragsende mit den Daten passiert, ist in Schedule C (DPA) geregelt. Die DPA legt Datenschutzregelungen für die Zeit nach Vertragsende fest, enthält aber keine automatischen Portabilitäts-Garantien in kundengewählten Formaten.

Was aktiv verhandelt werden sollte: Datenportabilität in standardisierten Formaten, Zugriffsfristen nach Vertragsende und die Kostentragung bei SAP-seitigen Exportleistungen. Diese Fragen sollten nicht erst entstehen, wenn das Vertragsende unmittelbar bevorsteht.

Divestiture-Klausel

Die Standard-Divestiture-Regelung im RISE-Vertrag sieht eine Übergangsnutzung von maximal zwölf Monaten vor, mit zwei Wochen Voranmeldung. Third-Party-Cloud-Services sind von dieser Regelung ausgenommen.

Für Unternehmen mit aktiven M&A-Aktivitäten oder Konzernumstrukturierungen ist die genaue Ausgestaltung dieser Klausel relevant. Was bei Carve-out, Spin-off oder Verkauf eines Geschäftsbereichs gilt, der RISE nutzt, ist im Detail vertragsspezifisch.

Subskriptions-Flexibilität

Mindestlaufzeiten je Komponente bestimmen, wann Dekommissionierungen möglich sind: Cloud-Managed-Services sechs Monate, Cloud-Software sechs Monate, CAS-Pakete zwölf Monate. Third-Party-Software ist generell nicht dekommissionierbar, ein in der initialen Vertragsgestaltung häufig unterschätzter Mechanismus.

Sperrfristen für neue Subskriptionen in den letzten Monaten vor Vertragsende begrenzen die Gestaltungsmöglichkeiten: keine neuen Managed-Service- oder Software-Subskriptionen in den letzten sechs Monaten, keine neuen CAS-Einheiten in den letzten zwölf Monaten.

---

CPI-Klauseln und Preisanpassungsmechanismen {#cpi-klauseln-und-preisanpassungsmechanismen}

CPI-Klauseln (Consumer Price Index) in SAP-Verträgen regeln, wie und in welchem Umfang Preisanpassungen bei Renewal zulässig sind. Wie der Mechanismus formuliert ist, beeinflusst den Handlungsspielraum im Renewal-Gespräch und beim nächsten Vertragszyklus.

Was CPI-Klauseln in SAP-Verträgen regeln

Im RISE Enterprise Agreement ist zu unterscheiden zwischen der vertraglichen CPI-Bindung im engeren Sinne und SAPs Möglichkeit, Preiserhöhungen bei Renewal anzukündigen. Beides berührt dieselbe Frage, gehorcht aber unterschiedlichen Logiken.

Die Ankündigungspflicht nach Schedule 5 ist ein klar definiertes Verfahren: SAP muss eine beabsichtigte Erhöhung mindestens 45 Tage vor Verlängerungsbeginn ankündigen. Erfolgt die Ankündigung nicht fristgerecht, gilt sie erst für die übernächste Verlängerungsperiode. Diese Fristenlogik ist für den Fristenkalender relevant.

Was öffentlich bekannt ist (Schedule 5)

Schedule 5 des RISE Enterprise Agreements ist das öffentlich zugängliche Vertragswerk, das die Preisanpassungsregeln dokumentiert. Die maximale Erhöhung pro Verlängerungszeitraum beträgt 3,3 Prozent. Die 45-Tage-Ankündigungspflicht ist darin ebenfalls festgehalten. Das Kündigungsrecht des Kunden bei einer angekündigten Erhöhung ist SAP-Standard.

Was bei der Vertragsgestaltung zu klären ist

Die Formulierung des Anpassungsmechanismus im individuellen Vertrag bestimmt den Handlungsspielraum. Relevante Aspekte sind: Ist die Begrenzung absolut oder prozentual? Welcher CPI-Index gilt als Referenz, über welchen Zeitraum wird er gemessen, und was ist die Berechnungsbasis? Eine Klausel, die auf einem bestimmten Index basiert, kann in einem Hochinflationsumfeld anders wirken als in einem stabilen Umfeld.

Eine Wechselwirkung existiert mit dem Guthaben-Reduktions-Mechanismus: SAP-Standardbedingungen sehen vor, dass bei Guthabenreduktion eine Anpassung des Rabattes möglich ist. Wer das Volumen in der nächsten Laufzeit reduzieren möchte, sollte diese Wechselwirkung im Blick behalten.

Wechselwirkung mit anderen Mechanismen

Der Kombinations-Effekt aus CPI-Erhöhung und Preiserhöhung bei Guthabenreduktion ist ein strukturelles Risiko, das bei der Szenario-Analyse in Phase 2 adressiert werden sollte. Beide Mechanismen können gleichzeitig eintreten, ihre additive Wirkung sollte quantifiziert sein, bevor das Renewal-Gespräch beginnt.

Staffelpreise (Schedule 5) spielen eine Rolle, wenn Volumina über Staffelgrenzen hinweg angepasst werden: Ein Mengenrückgang auf eine niedrigere Staffelstufe kann den Stückpreis erhöhen, auch ohne CPI-Anpassung. Wer Volumina reduzieren möchte, sollte die Staffelpreisstruktur vorab auswerten.

Bei Verlängerung eines bestehenden Vertrags gelten andere Preisstabilitätsbedingungen als bei einem Neuvertrag. Diese Unterscheidung ist relevant, wenn der Renewal-Prozess zu einem grundlegenden Neuverhandlungsszenario führen soll.

---

Self-Report-Pflicht und Overage-Governance vor Renewal {#self-report-pflicht-und-overage-governance-vor-renewal}

Im RISE Enterprise Agreement liegt die Pflicht zur Meldung von Übernutzung beim Kunden. Diese Pflicht besteht unabhängig davon, ob SAP die Übernutzung kennt oder nicht. Wer sie nicht systematisch steuert, riskiert ungeklärte Sachstände in einem Zeitfenster, das für die Renewal-Vorbereitung genutzt werden sollte.

Was die Self-Report-Pflicht bedeutet

Der Kunde ist verpflichtet, Übernutzung an SAP zu melden, bevor sie eintritt, nicht nachdem sie festgestellt wird. SAP hat keine automatische Meldepflicht gegenüber dem Kunden, wenn die Nutzung das vereinbarte Guthaben übersteigt.

Die Konsequenzen bei Übernutzung sind vertraglich definiert: Verbrauch über das Guthaben hinaus wird mit einem 15-prozentigen Aufschlag auf die reguläre Verbrauchsgebühr fakturiert. Für die Übernutzungsphase gilt außerdem keine SLA-Garantie. Fakturiert wird monatlich im Nachhinein, was bedeutet, dass Overages erst auf der nächsten Rechnung sichtbar werden.

Wie Overage-Governance vor Renewal aussehen sollte

Monatliches Balance-Statement-Review als Pflichtprozess: Das Balance Statement ist die primäre Steuerungsgrundlage für den Guthabenstand. Wer es monatlich auswertet, erkennt Abweichungen vom Verbrauchsplan frühzeitig.

Threshold-Definition: Bei welchem Guthabenstand wird intern eskaliert? Ein klarer Threshold, zum Beispiel 20 Prozent Restguthaben bezogen auf den Jahresplan, schafft einen strukturierten Eskalationspfad.

Eskalationspfad intern: Wer entscheidet über eine Zusatz-Subskription versus Akzeptanz von Overage? Diese Entscheidung gehört nicht in ad-hoc-Gespräche, sondern in einen definierten Prozess mit klaren Zuständigkeiten.

Warum Overage-Governance besonders vor Renewal wichtig ist

Ungeklärte Overage-Sachstände in den letzten 12 Monaten vor Vertragsende schwächen die eigene Position im Renewal-Gespräch. Wer offene Nachforderungen oder ungelöste Abrechnungsfragen mitbringt, muss diese parallel zur Renewal-Verhandlung lösen, was Ressourcen und Aufmerksamkeit bindet.

Saubere Buchführung über die gesamte Vertragslaufzeit, mit vollständigen Balance-Statements, dokumentierten Overage-Entscheidungen und nachvollziehbarem Verbrauchspfad, ist eine Stärke, keine Selbstverständlichkeit.

Self-Report und FUE-Vermessung im Zusammenhang

SAP hat seit 2025 mit PCE-Metering (Private Cloud Edition Metering) eine zunehmend automatisierte eigene Messung der FUE-Nutzung eingeführt. Diese Messung läuft parallel zur Kunden-eigenen Vermessung.

Eigene Vermessung als Kontrollinstrument: Wer die eigene FUE-Auslastung regelmäßig ermittelt, ist in der Lage, SAP-seitige Messergebnisse zu validieren. Bei Abweichungen zwischen SAP-Messung und Eigenermittlung ist ein strukturierter Klärungsprozess gefragt, der auf dokumentierten Daten aufbaut.

---

Stakeholder-Modell: Wer muss wann eingebunden sein {#stakeholder-modell-wer-muss-wann-eingebunden-sein}

Renewal-Vorbereitung ist eine Querschnittsaufgabe. Die vier Rollen, die ein SAP-Vertrags-Steuerungsmodell braucht, sind beim Renewal gleichzeitig gefragt und haben unterschiedliche Zeithorizonte. Wird eine Rolle zu spät eingebunden, entstehen Entscheidungslücken, die im Renewal-Gespräch sichtbar werden.

Contract Manager

Der Contract Manager verantwortet die Fristenübersicht, den Klausel-Review und die Vertragsdokumentation. Er ist die Rolle, die am frühesten in den Renewal-Prozess eintritt.

Ab M-18: Vertragsdokumentation auffrischen. Order Form, alle Schedules und Amendments auf Aktualität prüfen. Fristen für den Renewal-Kalender bestimmen und dokumentieren. Schedule 5 als Preislistenreferenz validieren.

Kernaufgabe M-9: Klausel-Delta zwischen aktuellem und gewünschtem Vertrag definieren. Welche Klauseln entsprechen dem Bedarf der nächsten Laufzeit, welche sollten angepasst werden? Diese Aufgabe ist das zentrale Ergebnis des Klausel-Reviews in Phase 3.

Der Contract Manager ist auch die Rolle, die sicherstellt, dass alle Fristen im Renewal-Kalender aktiv gesteuert werden: Auto-Renewal-Entscheidung, Kündigungsfristen, Sperrfristen für neue Subskriptionen.

Procurement

Procurement verantwortet die Verhandlungsführung und das Budget-Mandat für die neue Laufzeit. Diese Rolle tritt nicht am Anfang ein, braucht aber ausreichend Vorlaufzeit, um eine belastbare Verhandlungsposition aufzubauen.

Ab M-12: Szenario-Analyse und Budget-Planung. Auf Basis der Verbrauchsdaten aus Phase 1 und der Szenarien aus Phase 2 baut Procurement die Budgetrahmen für die drei Renewal-Szenarien.

Kernaufgabe M-6: Verhandlung mit SAP führen. Procurement führt das Renewal-Gespräch mit vollständiger Datenbasis, definiertem Verhandlungsrahmen und Executive-Freigabe.

Controlling

Controlling verantwortet die Kostenallokation, Budgetplanung und Forecast für die neue Laufzeit. Die Verbindung zur Datenbasis ist bei Controlling besonders eng: Ohne die Verbrauchsauswertung aus Phase 1 kann Controlling keine belastbaren Budget-Szenarien entwickeln.

Ab M-12: Verbrauchsauswertung und interne Verrechnung der letzten Periode. Welche Geschäftsbereiche haben welche SAP-Leistungen in welchem Umfang genutzt? Diese Frage ist sowohl für die Abrechnung der laufenden Periode relevant als auch für die Hochrechnung auf die nächste.

Kernaufgabe M-9: Budget-Szenarien für neue Laufzeit aufbauen. Die drei Renewal-Szenarien müssen in Budgetgrößen übersetzt werden, bevor der Executive eine fundierte Entscheidung treffen kann.

Executive

Executive trifft die strategische Entscheidung: Verlängerung, Volumenanpassung oder Neuausrichtung? Und gibt den Verhandlungsrahmen frei.

Ab M-12: Szenarien prüfen und Entscheidungsrahmen setzen. Der Executive braucht zu diesem Zeitpunkt keine Detailtiefe, aber einen klaren Überblick über die drei Szenarien und ihre Budget-Implikationen.

Kernaufgabe M-6: Freigabe des Verhandlungsrahmens und finale Vertragsunterzeichnung. Die Entscheidung, welchen Handlungsspielraum Procurement in der Verhandlung hat, muss vor dem ersten formalen Renewal-Gespräch mit SAP abgezeichnet sein.

Was fehlt, wenn Rollen fehlen

Ohne Contract Manager: Klausel-Risiken und Fristversäumnisse werden spät sichtbar, oft erst wenn das Handlungsfenster bereits geschlossen ist.

Ohne Procurement: Die Verhandlung findet ohne ausreichendes Budget-Mandat statt, was die Handlungsoptionen einschränkt.

Ohne Controlling: Verbrauchsdaten sind nicht aufbereitet, und Budget-Szenarien basieren auf Schätzungen statt auf validierten Zahlen.

Ohne Executive: Entscheidungen über den Verhandlungsrahmen werden verzögert, was Zeitdruck in die Verhandlungsphase bringt.

---

Auto-Renewal: Fristen, Risiken, Handlungsoptionen {#auto-renewal-fristen-risiken-handlungsoptionen}

Das Auto-Renewal im RISE Enterprise Agreement ist eine strukturelle Frist, keine Formalität. Was bei Nicht-Einhalten passiert, ist vertraglich eindeutig. Was die taktischen Optionen sind, hängt davon ab, wie früh der Steuerungsmoment genutzt wird.

Wie Auto-Renewal im RISE-Vertrag funktioniert

Der RISE-Vertrag verlängert sich ohne aktive Kündigung automatisch. Der Verlängerungszeitraum entspricht in der Regel der ursprünglichen Vertragslaufzeit, sofern im Order Form keine abweichende Regelung vereinbart wurde.

Preis bei Verlängerung: SAP darf den Preis für die neue Periode erhöhen, muss die Erhöhung aber mindestens 45 Tage vor dem Verlängerungsbeginn ankündigen. Bei verspäteter Ankündigung gilt die Erhöhung erst für die übernächste Periode.

Die kritischen Fristen

Das 45-Tage-Ankündigungsfenster für Preiserhöhungen ist in Schedule 5 dokumentiert. Es ist der früheste Zeitpunkt, an dem Kunden erfahren, ob SAP eine Erhöhung beabsichtigt.

Die Kündigungsfrist ist vertragsspezifisch und typischerweise bei drei Monaten. Sie ist im Order Form oder in den Schedule-Verweisen zu finden, nicht generisch bestimmbar. Die Prüfung des eigenen Order Forms ist unerlässlich.

Die Kombination aus Kündigungsfrist und 45-Tage-Fenster bestimmt den frühesten und spätesten Steuerungsmoment: Wer die Kündigungsoption offen halten möchte, muss spätestens zum Ablauf der Kündigungsfrist entschieden haben. Wer auf eine Preiserhöhungs-Ankündigung reagieren will, hat ab der Ankündigung 45 Tage Zeit.

Was passiert, wenn die Frist verpasst wird

Der Vertrag verlängert sich zu den angekündigten oder aktuellen Konditionen. Eine Nachverhandlung ist ohne eine neue Öffnung des Verhandlungsrahmens nicht möglich. Der gebundene Zeitraum erstreckt sich mindestens über die Verlängerungslaufzeit. Diese Situation ist revidierbar, aber mit erheblichem Aufwand verbunden.

Auto-Renewal als taktische Option

Aktive Nicht-Kündigung als bewusstes Signal: Wer auf eine Kündigung verzichtet, obwohl er theoretisch das Recht dazu hätte, sendet ein Signal der Kontinuität. Dieser Verzicht sollte eine bewusste Entscheidung sein, keine Unterlassung.

Ordentliche Kündigung bei angekündigter Preiserhöhung als Handlungsoption: Das Kündigungsrecht des Kunden bei einer Preiserhöhungs-Ankündigung ist im SAP-Standard vorgesehen. Dieses Recht kann ausgeübt werden, ohne dass eine Absicht zur Vertragsbeendigung besteht, wenn es als taktisches Signal im Rahmen eines gleichzeitig laufenden Neuverhandlungsprozesses eingesetzt wird.

Parallelführung: Kündigung ausgesprochen und gleichzeitig Neuverhandlung aufgenommen. Dieses Vorgehen erfordert vollständige Transparenz über das eigene Risiko, falls die Neuverhandlung scheitert.

Wie Fristensteuerung organisiert werden sollte

Ein Fristen-Kalender mit mindestens drei Monaten Vorlauf vor jedem kritischen Entscheidungszeitpunkt ist das Mindestsystem. Verantwortung für Pflege und Eskalation sind klar zuzuordnen, typischerweise beim Contract Manager.

Das Erinnerungssystem braucht mindestens zwei Eskalationsebenen: eine operative Erinnerung drei Monate vor der Frist und eine strategische Eskalation an den Executive vier bis fünf Monate vor der Frist.

Dokumentation der Kündigung, falls ausgesprochen: Schriftform, Zugangsnachweis, Empfangsbestätigung. Diese Dokumentation ist für den Fall relevant, dass Fristen oder Zustellzeitpunkte nachträglich in Frage gestellt werden.

Weiterführend: Pillar 1 SP-1 (Auto-Renewal-Fristen-Übersicht) vertieft dieses Thema.

---

Exit-Rechte: Was verhandelt werden sollte {#exit-rechte-was-verhandelt-werden-sollte}

Exit-Klauseln fehlen in SAP-Verträgen nicht, weil sie grundsätzlich nicht vorgesehen wären, sondern weil sie in der Verhandlungsphase nicht systematisch adressiert wurden. Beim Renewal ist der beste Zeitpunkt, diese Lücke zu schließen. Nachträglich, also außerhalb eines Renewals oder Amendments, sind Ergänzungen strukturell schwieriger.

Was Exit-Rechte in einem SAP-RISE-Vertrag regeln

Ordentliche Kündigung: Fristen, Voraussetzungen und Konsequenzen. Was passiert mit Guthaben, mit aktiven Subskriptionen, mit laufenden CAS-Paketen?

Außerordentliche Kündigung: Welche Sachverhalte berechtigen zu einer außerordentlichen Beendigung? Material Breach des Vertragspartners ist in den meisten SAP-Verträgen adressiert, aber die genaue Definition und das Verfahren sind vertragsspezifisch.

Datenmitnahme bei Vertragsende: In welchem Format können Daten exportiert werden, welche Frist gilt nach Vertragsende für den Zugriff, und wer trägt die Kosten für SAP-seitige Exportleistungen?

Was standardmäßig im RISE-Vertrag steht

Schedule C (DPA) regelt Datenschutzaspekte für die Zeit nach Vertragsende, nicht aber Portabilitätsdetails im gewünschten Format oder kostenlose Exportfristen. Die DPA ist notwendige Grundlage, aber nicht hinreichend für eine vollständige Exit-Governance.

Die Divestiture-Klausel sieht zwölf Monate Übergangsnutzung bei Unternehmensveräußerungen vor, mit zwei Wochen Voranmeldung. Third-Party-Cloud-Services sind ausdrücklich ausgenommen.

Kein automatisches Recht auf verlängerte Datenhaltung nach Vertragsende: Was nach Vertragsende mit den Daten geschieht, ist im Standard geregelt, aber nicht notwendigerweise in dem Format, das für eine Migration oder einen Anbietermigrations-Prozess benötigt wird.

Was aktiv zu verhandeln ist

Datenportabilität in standardisierten Formaten: SAP bietet Exportfunktionen an. Welche Formate, welche Granularität und welche Kosten, sollte vertraglich definiert sein, bevor ein Bedarfsfall eintritt.

Übergangsfristen nach Vertragsende: Wie lange bleibt Lesezugriff auf die Produktivdaten nach Beendigung des Vertragsverhältnisses möglich? Für Migrationsprojekte ist ein ausreichendes Übergangsfenster existenziell.

Definition von Kundeneigentum für Migrationszwecke: Welche Daten und Konfigurationen gelten eindeutig als Eigentum des Kunden, und was ist SAP-eigener Service-Inhalt?

Kostentragung: Wer zahlt für SAP-seitige Exportleistungen? Ohne vertragliche Regelung gilt die SAP-Standardpreisliste, die Exportleistungen als kostenpflichtigen Service führt.

Vendor-Lock-in und Exit-Strategie im Zusammenhang

Was auf der HANA-Runtime läuft, ist an die SAP-Infrastruktur gebunden. Was auf BTP als Eigenentwicklung betrieben wird, kann je nach Technologie-Stack auch außerhalb der SAP-Infrastruktur lauffähig sein. Diese Unterscheidung ist für eine Exit-Strategie relevant.

Das S/4HANA Compatibility Pack ist zeitlich begrenzt: Nutzungsrecht bis 31. Dezember 2030 (und früheres Subscription-Ende falls früher). Für Unternehmen, die noch ERP-Code im Compatibility-Pack-Modus betreiben, ist diese Frist ein harter Planungsrahmen.

Exit-Rechte und Renewal-Verhandlung

Wer Exit-Optionen im Renewal verhandelt, stärkt damit die Position für alle nachfolgenden Renewals. Ein klares Bild der eigenen Ausstiegsmöglichkeiten erhöht die Verhandlungsposition unabhängig davon, ob diese Optionen jemals in Anspruch genommen werden.

Exit-Bereitschaft als sachliches Signal im Verhandlungsprozess: Wer dokumentiert hat, welche Exit-Optionen existieren und wie eine Migration technisch und kommerziell aussehen würde, zeigt, dass die eigene Entscheidung für Kontinuität eine informierte Entscheidung ist, keine erzwungene.

Weiterführend: SP-3 (Exit-Rechte in SAP-Verträgen verhandeln) bietet Detailtiefe zu diesem Thema. Weiterführend auch: Pillar 8 (SAP als strategischen Vendor managen).

---

HowTo: Renewal-Readiness in 10 Schritten {#howto-renewal-readiness-in-10-schritten}

Die folgenden zehn Schritte sind chronologisch geordnet und jeweils einem Zeitpunkt vor Vertragsende zugeordnet. Sie spiegeln die vier Phasen des Renewal-Zeitplans in operativer Form wider.

Schritt 1 (M-18): Renewal-Datum und Auto-Renewal-Frist im Unternehmenskalender verankern. Der Startpunkt ist nicht die Vertragsunterzeichnung, sondern ein strukturierter Kalender-Eintrag. Renewal-Datum, Kündigungsfrist, 45-Tage-Fenster und Sperrfristen werden als separate Einträge dokumentiert, mit klar benannten Verantwortlichen für jede Frist.

Schritt 2 (M-18): Alle Vertragsunterlagen aktualisieren. Order Form, alle Schedules, alle Amendments. Der vollständige Vertragsbestand wird gesichtet und auf Aktualität geprüft. Fehlende Dokumente werden bei SAP angefordert. Der aktuelle Balance-Statement-Bestand wird für die letzten 18 Monate zusammengestellt.

Schritt 3 (M-15): Verbrauchsdaten der letzten 12 Monate aufbereiten. FUE-Auslastung je User-Typ, BTP-Credit-Verbrauch je Subaccount, CAS-Nutzung gegen gebuchtes Volumen, Balance-Statement-Zeitreihe. Diese Aufbereitung ist die Grundlage für alle weiteren Schritte. Sie kann nicht in vier Wochen nachgeholt werden, wenn sie 18 Monate lang nicht gepflegt wurde.

Schritt 4 (M-12): Nutzungslücken und Unternutzung identifizieren. Auf Basis der Verbrauchsdaten: Wo liegt das tatsächliche Nutzungsvolumen unter dem eingekauften Volumen? Welche Komponenten werden nicht in dem Umfang genutzt, der bei Vertragsabschluss geplant war? Diese Feststellung ist Grundlage für die Szenario-Analyse.

Schritt 5 (M-12): Stakeholder-Team konstituieren. Contract Manager, Procurement, Controlling und Executive werden formell in den Renewal-Prozess eingebunden. Verantwortlichkeiten je Rolle werden schriftlich dokumentiert. Ein Kommunikationsrhythmus für die Renewal-Vorbereitung wird etabliert.

Schritt 6 (M-9): Kritische Klauseln im aktuellen Vertrag bewerten. Preisanpassungsklausel, Auto-Renewal-Klausel, SLA-Struktur und Geltungsbereich, Exit-Klauseln und Datenportabilität, Divestiture-Klausel, Subskriptions-Flexibilität. Für jeden der sechs Bereiche wird dokumentiert, was im aktuellen Vertrag steht und was für die nächste Laufzeit anders sein sollte.

Schritt 7 (M-9): Drei Szenarien definieren. Szenario 1: Status-quo-Renewal, Verlängerung zu im Wesentlichen unveränderten Bedingungen. Szenario 2: Volumen- oder Komponentenanpassung auf Basis der Nutzungsauswertung. Szenario 3: Vollständige Neuverhandlung mit geänderten Vertragsparametern. Jedes Szenario wird mit Budget-Implikationen und Zeitaufwand bewertet.

Schritt 8 (M-6): Verhandlungsgespräch mit SAP proaktiv aufnehmen. Kein reaktives Warten auf eine SAP-Kontaktaufnahme. Wer das Gespräch initiiert, bestimmt den ersten Framing-Rahmen. Der Gesprächseinstieg erfolgt auf Basis der Datenbasis aus Schritt 3 und 4 und der Klausel-Bewertung aus Schritt 6.

Schritt 9 (M-3): Auto-Renewal-Entscheidung treffen. Kündigung aussprechen oder bewusst laufen lassen. Diese Entscheidung ist jetzt mit allen relevanten Informationen zu treffen: Verhandlungsstand mit SAP, Budget-Freigabe durch Executive, Fristen-Kalender. Sie sollte nicht unter Zeitdruck fallen, weil die Vorbereitungsschritte nicht rechtzeitig abgeschlossen wurden.

Schritt 10 (M-2): Vertragsunterzeichnung und Transition-Governance einrichten. Der neue Vertrag wird unterzeichnet. Die Transition-Governance für die neue Laufzeit wird dokumentiert: Was läuft bis wann unter dem alten Vertrag, was startet unter dem neuen? Guthaben-Übergangsplanung, neue Subskriptions-Startdaten, aktualisierter Fristen-Kalender für die neue Laufzeit.

---

FAQ {#faq}

1. Wann sollte ich mit der Renewal-Vorbereitung beginnen und warum 12 bis 18 Monate?

Strukturierte Vorbereitung beginnt spätestens 18 Monate vor Vertragsende. Grund: Die Datenbasis, die für eine fundierte Verhandlungsposition benötigt wird, lässt sich nicht kurzfristig aufbauen. Verbrauchszeitreihen über 12 bis 18 Monate, vollständige Vertragsdokumentation, Stakeholder-Ausrichtung und Klausel-Review erfordern Vorlaufzeit. Darüber hinaus beginnt SAP den Renewal-Dialog auf seiner Seite typischerweise 12 bis 18 Monate vor Laufzeitende. Wer später beginnt, trifft auf einen bereits strukturierten Counterpart.

2. Was passiert, wenn ich das Auto-Renewal bei RISE nicht rechtzeitig kündige?

Der Vertrag verlängert sich automatisch zum Ende der Laufzeit, typischerweise um die ursprüngliche Vertragsdauer. SAP darf den Preis für die neue Periode erhöhen, sofern die Erhöhung mindestens 45 Tage vor Verlängerungsbeginn angekündigt wurde. Eine Nachverhandlung ohne Neu-Opening ist nicht möglich. Das Kündigungsrecht des Kunden bleibt auch bei Verlängerung bestehen, sofern SAP eine Preiserhöhung ankündigt.

3. Welche Daten brauche ich für eine fundierte Verhandlungsposition?

Vier Datenkategorien: Verbrauchsdaten (FUE-Auslastung je User-Typ, BTP-Credit-Verlauf, CAS-Nutzung), Vertragsdaten (Schedule 5, Balance Statements, Sondervereinbarungen), Marktdaten (öffentliche DSAG-Berichte, spezialisierte Quellen) und Qualitätsdaten (SLA-Compliance, Ticket-Volumen, ungelöste Eskalationen). Wer alle vier Kategorien vollständig hat, kann jede Frage zu Volumen, Preis und Klausel sachlich beantworten.

4. Was ist die 45-Tage-Ankündigungsfrist bei Preiserhöhungen und was folgt daraus?

SAP muss eine beabsichtigte Preiserhöhung für die Renewal-Periode mindestens 45 Tage vor dem Verlängerungsbeginn ankündigen (Schedule 5). Bei verspäteter Ankündigung gilt die Erhöhung erst für die übernächste Verlängerungsperiode. Der Kunde hat nach Eingang der Ankündigung das Recht zur ordentlichen Kündigung. Dieses Fenster ist ein strukturierter Steuerungsmoment: Wer es kennt, kann proaktiv positionieren.

5. Kann ich beim Renewal den Vertragsumfang reduzieren oder Komponenten abbestellen?

Ja, mit den vertraglich definierten Einschränkungen. Cloud-Managed-Services und Cloud-Software haben eine Mindestlaufzeit von sechs Monaten, CAS-Pakete zwölf Monate. In den letzten sechs Monaten vor Vertragsende lassen sich keine neuen Managed-Service- oder Software-Subskriptionen mehr einbuchen, in den letzten zwölf Monaten keine neuen CAS-Einheiten. Third-Party-Software ist generell nicht dekommissionierbar. Volumenanpassungen müssen vor den jeweiligen Sperrfristen abgeschlossen sein.

6. Was sind CPI-Klauseln in SAP-Verträgen und wie wirken sie sich auf die Renewal-Kosten aus?

CPI-Klauseln regeln, in welchem Umfang Preisanpassungen bei Renewal zulässig sind. Der öffentlich kommunizierte Rahmen in Schedule 5 sieht eine maximale Erhöhung von 3,3 Prozent pro Verlängerungszeitraum vor. Die genaue Klauselformulierung im individuellen Vertrag, Referenzindex, Berechnungszeitraum, Cap-Formulierung, bestimmt den tatsächlichen Anpassungsspielraum. Eine Wechselwirkung besteht mit dem Guthaben-Reduktions-Mechanismus: Bei Volumenreduktion darf SAP nach Standardbedingungen den Rabatt anpassen.

7. Was passiert mit ungenutztem Guthaben am Ende der Vertragslaufzeit?

Restguthaben am Ende der Vertragslaufzeit verfällt vollständig. Der degressive Roll-Over-Mechanismus erlaubt in den Vorjahren einen Teil des Guthabens zu übertragen (30 Prozent im ersten Jahr, 20 Prozent im zweiten, 10 Prozent ab dem dritten Jahr), im letzten Jahr ist der Roll-Over ausgeschlossen. Diese Mechanik ist ein struktureller Grund, warum die Guthaben-Planung im vorletzten Vertragsjahr beginnen muss, nicht im letzten.

8. Welche Stakeholder müssen in die Renewal-Vorbereitung eingebunden sein?

Die vier Rollen des SAP-Vertrags-Steuerungsmodells: Contract Manager (ab M-18, Fristenhüter und Klausel-Review), Procurement (ab M-12, Verhandlungsführung und Budget-Mandat), Controlling (ab M-12, Verbrauchsauswertung und Budget-Szenarien) und Executive (ab M-12, strategische Entscheidung und Freigabe des Verhandlungsrahmens). Das Stakeholder-Team sollte spätestens in Phase 2 formell konstituiert sein.

9. Was sind Exit-Rechte in einem SAP-Vertrag und wie verhandelt man sie?

Exit-Rechte regeln die Bedingungen für eine Vertragsbeendigung, einschließlich Fristen, Datenmitnahme und Kosten. Der beste Zeitpunkt zur Verhandlung ist das Renewal: Wer Exit-Optionen im Renewal adressiert, muss sie nicht nachträglich über ein Amendment einbringen. Aktiv zu verhandeln sind insbesondere Datenportabilität in standardisierten Formaten, Übergangsfristen nach Vertragsende und die Kostentragung bei Exportleistungen.

10. Wie nutze ich BTP-Verbrauchsdaten als Basis für die Renewal-Verhandlung?

BTP-Credit-Daten liefern das granulare Bild der Cloud-Plattform-Nutzung unterhalb der FUE-Ebene. Eine Zeitreihe über 12 bis 18 Monate mit Projektzuordnung und Kostenstellenstruktur ist die Mindestanforderung. Aus dieser Zeitreihe lässt sich das Credit-Volumen für die nächste Laufzeit kalibrieren, das Overage-Risiko quantifizieren und der AI-Unit-Bedarf hochrechnen, falls eine Erweiterung der Business-AI-Nutzung geplant ist. BTP-Daten sind damit direkt verwertbarer Verhandlungs-Input, nicht nur internes Reporting.

---

Nächste Schritte {#naechste-schritte}

Renewal-Vorbereitung strukturiert starten. Der Vertragscheck von FinOptory liefert in vier Wochen eine vollständige Bestandsaufnahme der eigenen SAP-Vertragsposition: Verbrauchsdaten, Klausel-Bewertung, Datenbasis für das Renewal-Gespräch. Festpreis 7.900 EUR. Der Vertragscheck ist der definierte Einstieg: Nach vier Wochen wissen Sie, wo Sie stehen und welche der drei Renewal-Szenarien für Ihre Situation in Frage kommt.

FinOptory AI nutzen. Die eigene Renewal-Situation lässt sich über den FinOptory-AI-Chat auf finoptory.ai schnell einordnen. Ein erster Überblick über Ihre Vertragsstruktur und die relevanten Steuerungsmomente ist ohne Vorlaufzeit möglich.

Weiterführende Lektüre. Pillar 1 (SAP Contract Governance über das gesamte Portfolio) legt das Grundlagen-Framework für alle SAP-Vertragstypen dar. Pillar 8 (SAP als strategischen Vendor managen) vertieft die Perspektive über das einzelne Renewal hinaus. Beide Pillars sind über die FinOptory-Ressourcen-Seite verfügbar.

---

Erstellt 2026-05-21. Version v1, Status: draft, freigegeben für Bernhard-Review. Quellen-Grundlage: SAP_RISE/02_vertragsstruktur_enterprise_agreement.md, SAP_RISE/04_rise_betrieb_und_governance.md, SAP_RISE/07_service_description_guide.md (alle partner-sichtbar). SAP_RISE/08_rise_negotiation_playbook.md wurde nicht verwendet.