On-Premise-Lizenzanrechnung auf Cloud ERP: Credit-Typen und Mechanik

Wer von einer On-Premise-SAP-Landschaft zu RISE wechselt, hat über Jahre in Maintenance investiert. Diese Investition muss beim Übergang nicht vollständig abgeschrieben werden. SAP stellt über das Cloud Extension Program drei Credit-Typen zur Verfügung, die gegen den neuen RISE-Vertrag verrechnet werden können.

Die Herausforderung liegt nicht im Grundsatz, sondern in der Mechanik: Welcher Credit-Typ deckt welche Vertragsposition ab? Wie werden Credits gegen den Annual Contract Value verrechnet? Und warum beeinflusst der Zeitpunkt der Anmeldung die verhandelbare Höhe erheblich? Diese Fragen strukturieren diesen Artikel.

Drei Credit-Typen: Unterschiedliche Herkunft, unterschiedliche Verwendung

SAP unterscheidet im Cloud Extension Program drei Credit-Typen. Sie unterscheiden sich nicht nur in ihrer Herkunft, sondern auch in ihrer Verwendungsrichtung.

Maintenance Credits entstehen aus der laufenden On-Premise-Wartungsgebühr. Wer jährlich Maintenance auf SAP ERP, On-Prem-S/4HANA oder zugehörige Add-ons zahlt, hat eine Basis für Maintenance Credits aufgebaut. Diese Credits werden typischerweise gegen künftige On-Premise-Wartungsrechnungen verrechnet, solange der Parallelbetrieb läuft.

Service Credits sind für SAP-Services-SKUs vorgesehen. Kunden, die SAP Consulting-Leistungen, SAP Activate-Pakete oder Migration Advisory beziehen, können einen Teil der zuvor gezahlten Service-Beträge als Guthaben einsetzen. Das ist besonders relevant für Kunden, die in den Jahren vor der Entscheidung bereits SAP-seitige Migrationsvorbereitung beauftragt haben.

Cloud Credits sind die direkteste Form der Anrechnung: Sie werden gegen Cloud-Vertragsrechnungen, also den RISE-ACV, verrechnet. Damit reduzieren sie den tatsächlichen Zahlungsbetrag in der Startphase des neuen Vertrags.

Der Steuerungsmoment bei den Credit-Typen liegt in der richtigen Zuordnung. Maintenance Credits gegen Cloud-Rechnungen einzusetzen ist nicht vorgesehen, Cloud Credits gegen Service-SKUs ebenso wenig. Wer die Grenzen der Typen kennt, kann die Anrechnung gezielt planen, statt sie erst in der Vertragsverhandlung zu klären.

Eligibility: Wer anrechnen kann und über welches Programm

Anrechenberechtigt sind SAP-Bestandskunden mit aktiven On-Premise-Lizenzen auf SAP ERP (BS7) oder On-Prem-S/4HANA. Der Einstiegsweg ist das Cloud Extension Program, das SAP für den Übergang zu RISE und GROW bereitstellt.

Zwei Bedingungen sind dabei relevant: Erstens muss eine aktive Kundenbeziehung mit SAP bestehen, also ein gültiger Wartungsvertrag. Zweitens muss der Wechselweg über RISE oder GROW führen, nicht über einen reinen On-Prem-S/4HANA-Vertrag ohne Cloud-Komponente.

Kunden, die bereits vor Ende 2025 eine Transition Option oder einen frühen RISE-Vertrag subskribiert haben, können eine günstigere Ausgangslage haben, weil der Transition-Option-Aufschlag für diese Gruppe entfällt. Das ist allerdings eine separate Vertragsebene und kein Bestandteil der Credit-Anrechnung selbst.

Entscheidend ist: Eligibility ist keine Selbstverständlichkeit, die automatisch im RISE-Angebot erscheint. Sie muss aktiv beim SAP Account Executive angemeldet werden. Das ist der erste Steuerungsmoment in diesem Prozess.

Wie Credits gegen den ACV verrechnet werden: Die Mechanik

Cloud Credits werden nicht als pauschale Gutschrift auf den Vertragsbetrag angewendet. Die Verrechnung erfolgt gegen spezifische Positionen im RISE-Vertrag, typischerweise gegen den Annual Contract Value in der Ramp-up-Phase.

Der ACV ist die jährliche Vertragssumme, die sich aus FUE-Lizenzierung, BTP-Entitlements, Hyperscaler-Betrieb und weiteren im Paket enthaltenen Leistungen zusammensetzt. Credits können diesen Betrag in den ersten Vertragsperioden reduzieren, nicht jedoch eliminieren. SAP setzt typischerweise eine Untergrenze, ab der der ACV nicht weiter unterschritten werden darf.

Die Höhe der anrechenbaren Credits ist nicht festgesetzt. Sie ist Verhandlungsergebnis zwischen Kunden und SAP Account Executive, beeinflusst durch mehrere Faktoren: Wie lange besteht die Kundenbeziehung? Wie hoch ist die historische Maintenance Base? Wann wurde der Wechsel angekündigt? Welche Vertragslaufzeit wird für RISE angeboten?

Ein konkretes Rechenbeispiel in abstrakter Form: Wenn die jährliche Maintenance Base bislang bei 500.000 Euro lag und der angebotene RISE-ACV bei 600.000 Euro liegt, können Maintenance Credits einen Teil der Differenz schließen. Die genaue Quote ist nicht publiziert, sie variiert je nach Kundenprofil und Verhandlungsstand.

Der Steuerungsmoment "Kosten" aus dem FinOptory-Framework greift hier direkt: ACV-Tracking, Credit-Verrechnung und Ramp-up-Profil gehören in dieselbe Vertragssteuerungslogik. Wer Credits in der Startphase nicht aktiv abbildet, verliert sie nicht sofort, aber der Spielraum für spätere Korrekturen wird enger.

Warum der Zeitpunkt die Verhandlungsposition beeinflusst

Die Credit-Höhe ist nicht nur von der historischen Maintenance Base abhängig, sondern auch davon, wann der Wechsel beim SAP Account Executive angemeldet wird.

SAP hat ein Interesse daran, Migrationsvorhaben frühzeitig zu planen. Kunden, die ihren Wechsel früh signalisieren, geben SAP die Planungssicherheit, die für eine attraktivere Credit-Ausgestaltung sprechen kann. Wer dagegen erst kurz vor dem Maintenance-Ende 2027 wechselt, verhandelt unter Zeitdruck, was die eigene Position erfahrungsgemäß schwächt.

Darüber hinaus gibt es ein Zeitfenster für das Cloud Extension Program selbst. Es ist nicht unbegrenzt offen. Wer die RISE-Migration für 2026 oder 2027 plant, sollte die Credit-Anmeldung nicht auf das letzte Quartal vor Vertragsabschluss verschieben. Frühzeitige Anmeldung bedeutet mehr Gestaltungsraum.

Ein weiterer Faktor: SAP kann in der Verhandlung Vorleistungen belohnen. Kunden, die sich zur längeren RISE-Laufzeit verpflichten (etwa fünf statt drei Jahre), haben typischerweise mehr Spielraum bei der Credit-Anerkennung.

Das alles sind keine Garantien, sondern Verhandlungsdynamiken. Der Punkt ist: Die Verhandlungsposition beim RISE-Einstieg ist kein fester Wert, sondern wird durch Timing und Vorbereitung beeinflusst.

Was nicht automatisch angerechnet wird

Es gibt Positionen, bei denen eine Anrechnung naheliegend erscheint, die aber nicht automatisch im Cloud Extension Program enthalten sind.

Add-on-Wartungskosten: Kunden zahlen Maintenance nicht nur auf das SAP ERP-Kernsystem, sondern auch auf Add-ons. Ob Add-on-Maintenance Credits erzeugt, hängt vom jeweiligen Add-on-Vertrag und dessen Stellung im Wartungsverbund ab. Nicht alle Add-ons sind über das Cloud Extension Program eligible. Das ist eine der Positionen, die bei der Vorbereitung explizit geprüft werden muss.

Application Management Services (AMS): Wer externe AMS-Leistungen bezieht, zahlt an einen Implementierungspartner, nicht an SAP direkt. Diese Zahlungen erzeugen keine Credits im SAP-Programm. AMS bleibt ein separater Vertragskreis.

Third-Party-Wartungsverträge: Manche Kunden nutzen unabhängige Wartungsanbieter neben oder statt SAP Enterprise Support. Zahlungen an Drittanbieter erzeugen keine SAP-seitigen Credits.

Laufende Consulting-Mandate: Service Credits beziehen sich auf SAP-eigene Services-SKUs, nicht auf Beratungsmandate bei Systemintegratoren.

Die Identifikation dieser Grenzen ist deshalb wichtig, weil sie direkt in die Kalkulation des Business Case für den RISE-Wechsel einfließt. Wer die Credit-Basis überschätzt, hat im späteren Vertragscheck eine unerwartete Lücke. Wer sie kennt, kann Alternativen frühzeitig einplanen.

Shelfware als ergänzender Faktor bei der Verrechnung

Neben den Credit-Typen des Cloud Extension Program gibt es eine weitere Verhandlungsressource: ungenutzte On-Premise-Lizenzen, die bezahlt, aber nicht produktiv eingesetzt werden.

Diese Shelfware kann auf zwei Wegen in die Verrechnung eingebracht werden. Erstens durch gezielte Lizenzaufgabe: Wer nicht benötigte Nutzungsrechte vor dem RISE-Wechsel formell zurückgibt, reduziert die Maintenance Base und damit den Aufschlag bei Extended Maintenance. Zweitens durch Verhandlung: Shelfware ist ein Argument, das die eigene Verhandlungsposition stärkt, weil es zeigt, dass die bezahlte Basis über dem tatsächlichen Nutzungsumfang liegt.

Shelfware-Verwertung ist ein eigenes Thema, das Cluster 6 dieses Pillars ausführlich behandelt. Für die Credit-Verrechnung gilt: Shelfware und Credits sind separate Mechanismen, aber sie wirken in dieselbe Richtung. Wer beide strukturiert einbringt, hat eine breitere Verhandlungsbasis.

Was der Vertragstext über Credits aussagen muss

Credits, die in der Verhandlung besprochen werden, gelten nur dann als gesichert, wenn sie im Vertragstext verankert sind. Das klingt selbstverständlich, ist es in der Praxis aber nicht immer.

Der Vertragstext sollte mindestens folgende Positionen zu Credits explizit regeln:

Den Credit-Typ (Maintenance, Service oder Cloud) mit der jeweiligen Bezugsgröße
Den Anrechnungszeitraum: In welchen Vertragsperioden wird der Credit in Abzug gebracht?
Die Verfallsregel: Welche Credits verfallen, wenn sie nicht bis zu einem bestimmten Zeitpunkt genutzt werden?
Die Verknüpfung mit dem Ramp-up-Profil: Wie passt die Credit-Inanspruchnahme zur vereinbarten FUE-Ramp-up-Kurve?

Die Vertragssprache rund um Credits ist nicht standardisiert. SAP nutzt verschiedene Bezeichnungen, und die tatsächliche Wirkung hängt von der exakten Formulierung im Vertragsanhang ab. Ein verhandeltes, aber nicht klar formuliertes Credit-Arrangement kann sich in der Billing-Phase anders verhalten als erwartet.

Das ist kein Einzelfall, sondern ein Muster, das sich in der Praxis regelmäßig zeigt: Die Investition in Vertragsklarheit vor der Unterschrift ist die effektivste Form der Kostensteuerung nach der Unterschrift.

Die vier Steuerungsmomente bei der Credit-Verrechnung

Das FinOptory-Framework unterscheidet vier Steuerungsmomente: Nutzung, Berechtigungen, Infrastruktur und Kosten. Bei der Lizenzanrechnung liegt das Gewicht klar auf dem Steuerungsmoment Kosten, aber alle vier Bereiche sind indirekt betroffen.

Nutzung: Die FUE-Ausgangsgröße beeinflusst den ACV und damit die Basis, auf die Credits angerechnet werden. Wer vor dem RISE-Wechsel eine belastbare FUE-Analyse durchgeführt hat, verhandelt auf Basis nachvollziehbarer Zahlen.

Berechtigungen: Die Rollenstruktur bestimmt den FUE-Mix. Zu breite Rollen erhöhen den FUE-Bedarf und damit den ACV. Wer das Rollendesign vor dem Vertragsabschluss bereinigt, reduziert die Credit-Basis, die nötig ist, um den ACV auf ein verträgliches Niveau zu senken.

Infrastruktur: Die Hyperscaler-Wahl beeinflusst den Infrastrukturanteil am ACV. Dieser Teil ist nicht durch Credits reduzierbar. Credits wirken typischerweise nur auf den Lizenz- und Service-Anteil.

Kosten: Hier liegt der Kern. ACV-Tracking, Credit-Zuordnung, Ramp-up-Profil und Maintenance-Abgrenzung während der Dual-Use-Periode sind Aufgaben, die nach der Vertragsunterschrift fortlaufen. Sie erfordern eine Datenstruktur, die diese Positionen laufend sichtbar macht, nicht nur zum Abschlusszeitpunkt.

Fazit: Credit-Anrechnung ist kein Automatismus

Bestehende Maintenance-Investitionen sind beim RISE-Wechsel nicht verloren. Drei Credit-Typen stehen zur Verfügung, die gegen unterschiedliche Vertragsbestandteile verrechnet werden können. Die Höhe ist nicht festgesetzt, sie entsteht in der Verhandlung.

Was systematische Steuerung ermöglicht: Die Credit-Basis vor der Verhandlung vollständig zu erfassen, den Zeitpunkt der Anmeldung bewusst zu wählen, die Grenzen der Anrechenbarkeit zu kennen und das Ergebnis im Vertragstext zu verankern.

Wer SAP-Verträge nach der Unterschrift strukturiert steuert, erkennt den Steuerungsmoment "Kosten" nicht als einmalige Verhandlungsaufgabe, sondern als laufende Disziplin. Die Credit-Verrechnung ist ihr Ausgangspunkt, die laufende ACV-Überwachung die Fortsetzung.

Weiterführende Artikel in diesem Pillar:

Autor: Bernhard Mändle, Managing Consultant bei FinOptory
LinkedIn: linkedin.com/in/bernhardmaendle

FinOptory steuert SAP-Verträge nach der Unterschrift. Über die gesamte Laufzeit. Erstgespräch vereinbaren.