Was ist die Voraussetzung fuer verursachergerechte BTP-Kostenverrechnung?

Eine Subaccount-Struktur, die organisatorische Einheiten, Projekte oder Kostenstellen widerspiegelt. SAP liefert monatliche Balance Statements auf Subaccount-Ebene.

Interne Verrechnung von BTP-Kosten: Chargeback-Modelle fuer hybride Portfolios

Q: Was ist der Unterschied zwischen Showback und Chargeback?

Showback zeigt Kostenstellen ihre BTP-Kosten, ohne eine interne Buchung vorzunehmen. Chargeback verrechnet Kosten tatsaechlich auf Kostenstellen und schafft echte Kostenverantwortung.

Verursachergerechte Zuordnung von BTP-Kosten auf Geschäftsbereiche und Kostenstellen ist in der Praxis häufig ungelöst. Ohne eine passende Subaccount-Struktur fehlt die technische Grundlage für jede belastbare Allokation. Dieser Artikel beschreibt, welche organisatorischen und technischen Voraussetzungen notwendig sind, wie Showback und Chargeback sich in der Praxis unterscheiden, und wo SAP-eigene Werkzeuge an ihre Grenzen stoßen.

Warum interne Verrechnung eine Controlling-Anforderung ist, keine Option

BTP-Kosten entstehen nicht gleichmäßig über eine Organisation. Ein Integrationsvorhaben in der Logistik, ein HANA-Cloud-Datenbankbetrieb für die Finanzplanung und ein AI-Pilotprojekt im HR-Bereich erzeugen unterschiedliche Credit-Verbräuche, die einem einheitlichen Jahresbudget gegenüberstehen.

Solange diese Verbräuche nicht differenziert auf die verursachenden Einheiten zurückgeführt werden, entsteht ein klassisches Steuerungsproblem: Das zentrale IT-Budget trägt Kosten, deren Treiber in den Fachbereichen liegen. Fachbereiche planen ohne Kenntnis ihrer tatsächlichen BTP-Aufwände. Und bei der Renewal-Vorbereitung fehlen die Daten, um das kommende Commitment auf einer belastbaren Verbrauchshistorie aufzubauen.

Für Directors SAP Plattform ist dieser Steuerungsmoment im Bereich Kosten keine interne Kostenrechnung im engeren Sinne, sondern eine Governance-Voraussetzung: Wer intern nicht verrechnet, kann gegenüber CFO und Management nicht belegen, welcher Geschäftsbereich welchen Anteil am SAP-Budget beansprucht und warum.

Subaccount-Struktur als Zurechnungseinheit: Die Design-Entscheidung mit Kostenfolgen

Die technische Grundlage für jede interne BTP-Kostenverrechnung ist die Subaccount-Struktur des Global Accounts. SAP liefert monatliche Balance Statements auf Subaccount-Ebene. Was auf Subaccount-Ebene nicht getrennt wurde, lässt sich auf Berichtsebene nicht mehr trennen.

Diese Entscheidung ist keine rein technische Architekturaufgabe, sondern ein Steuerungsmoment mit direkter Kostenfolge: Wie der Global Account und seine Subaccounts organisiert sind, bestimmt, für welche Granularität eine verursachergerechte Verrechnung überhaupt möglich ist.

Vier Organisationsprinzipien haben sich in der Praxis etabliert:

Nach Geschäftsbereichen: Ein Subaccount pro Business Unit. Einfach in der Verwaltung, aber zu grob, wenn mehrere Projekte innerhalb einer BU unterschiedliche Credit-Profile haben.

Nach Projekten: Ein Subaccount pro BTP-Projekt oder Vorhaben. Präzise Zuordnung, aber höherer Verwaltungsaufwand bei häufig wechselnden Projekten. Geeignet für Organisationen mit klar abgegrenzten, mehrjährigen BTP-Projekten.

Nach Umgebungen mit Projekttrennung: Je ein Subaccount für Produktion, Test und Entwicklung pro Projekt. Ermöglicht zusätzlich die Unterscheidung zwischen produktivem Verbrauch und Dev/Test-Kosten, was für Non-Production-Shutdown-Strategien und interne Verrechnung relevant ist.

Nach Kostenstellen: Die Subaccount-Struktur bildet die interne Kostenstellenstruktur ab. Direkte Verbindung zur buchhalterischen Steuerung, setzt aber eine stabile Kostenstellenstruktur voraus, die sich nicht häufig ändert.

Die Herausforderung bei granularen Strukturen: Viele Subaccounts erhöhen den Verwaltungsaufwand für Entitlement-Zuweisung und Monitoring. Die richtige Balance hängt von der Organisationsgröße, der BTP-Nutzungstiefe und den Controlling-Anforderungen ab. Entscheidend ist, dass diese Entscheidung bewusst getroffen und dokumentiert wird, bevor BTP-Workloads produktiv gehen, nicht danach.

Credit-Rate als Verrechnungsgrundlage: Was der Kostenstellen-Owner wissen muss

BTP-Kosten entstehen in Capacity Units (CU), nicht direkt in Euro. Die Credit-Rate, also der vertraglich fixierte Preis pro Capacity Unit aus dem Order Form, ist die Umrechnungsgrundlage für die interne Verrechnung.

Dieser Unterschied zum Listenpreis ist für den internen Verrechnungsprozess wesentlich. Ein Enterprise Agreement mit 25 bis 35 Prozent Rabatt auf den Listenpreis bedeutet: Die interne Verrechnung sollte den verhandelten Vertrags-Credit-Preis widerspiegeln, nicht den Listenpreis. Kostenstellen-Owner, die den Listenpreis als Referenz nehmen, überschätzen systematisch die Kosten ihres BTP-Verbrauchs.

Der praktische Prozess für eine monatliche Verrechnung auf Kostenstellen folgt drei Schritten:

Balance Statement auswerten: Für jeden relevanten Subaccount den Credit-Verbrauch des Monats aus dem monatlichen Balance Statement entnehmen.
In Euro umrechnen: Credit-Verbrauch multipliziert mit dem vertraglich fixierten Credit-Preis (aus Order Form) ergibt den Euro-Betrag pro Subaccount.
Auf Kostenstellen buchen: Den Euro-Betrag auf die der Subaccount-Struktur zugeordnete Kostenstelle oder den internen Budget-Owner übertragen.

Dieser Prozess setzt voraus, dass das Mapping zwischen Subaccounts und internen Kostenstellen gepflegt und aktuell ist. Eine Änderung der Organisationsstruktur erfordert eine entsprechende Anpassung der Subaccount-Zuordnung, damit die Verrechnung weiterhin korrekt funktioniert.

Showback versus Chargeback: Zwei Reifegrade interner Transparenz

In der Praxis haben sich zwei Modelle für die interne BTP-Kostenverteilung etabliert, die sich in ihrer Bindungswirkung und ihrem Implementierungsaufwand unterscheiden.

Showback stellt Kostenstellen und Projekten ihre BTP-Kosten monatlich sichtbar zur Verfügung, ohne eine tatsächliche interne Buchung vorzunehmen. Das Controlling-System bleibt unverändert. Die Wirkung entsteht durch Sichtbarkeit: Wer seinen BTP-Verbrauch regelmäßig als Zahl sieht, entwickelt ein anderes Kostenbewusstsein als bei einer unsichtbaren Sammelrechnung.

Showback ist der einfachere Einstieg. Es erfordert keine Anpassung interner Buchungsprozesse und ist auch dann umsetzbar, wenn die Subaccount-Struktur noch nicht vollständig nach Verrechungseinheiten getrennt ist. Es schafft den ersten Steuerungsmoment im Bereich Kosten auf der Ebene der Fachbereiche.

Chargeback verrechnet BTP-Kosten tatsächlich auf Kostenstellen oder Projekte durch interne Buchungen oder eine entsprechende Budgetzuweisung. Chargeback schafft echte Kostenverantwortung: Wer mehr BTP-Ressourcen beansprucht, spürt das im eigenen Budget. Dieser direkte Steuerungsimpuls ist nachhaltiger als reine Sichtbarkeit, weil er Verhalten beeinflusst.

Chargeback erfordert eine reifere Infrastruktur: eine funktionierende Subaccount-Architektur als Datengrundlage, ein definiertes Allokationsmodell, das buchhalterisch valide ist, und die Bereitschaft der Fachbereiche, für ihre BTP-Nutzung intern zu zahlen. Die FinOps Foundation beschreibt Showback als typischen Reifeschritt auf dem Weg zu Chargeback: Viele Organisationen beginnen mit sechs bis zwölf Monaten Showback, um intern Akzeptanz und Verständnis für die Kostenstruktur aufzubauen, bevor der Chargeback-Prozess eingeführt wird (Quelle: FinOps Foundation, FinOps Framework 2025).

Was SAP-eigene Tools leisten und wo ihre Grenzen liegen

Das BTP Cockpit und die monatlichen Balance Statements liefern die Rohdaten für interne Verrechnung. Sie zeigen den Credit-Verbrauch je Service und je Subaccount in einer strukturierten Form. Für das Monitoring und die Basis-Auswertung auf Vertragsebene sind diese Werkzeuge ausreichend.

Die Grenzen werden sichtbar, sobald die Verrechnung die Subaccount-Ebene übersteigt oder mehrere Vertragsstrukturen zusammengeführt werden sollen.

Das BTP Cockpit bietet keine direkte Integration in interne ERP- oder Controlling-Systeme. Die Verbindung zwischen Balance-Statement-Daten und internen Kostenstellen muss außerhalb des Cockpits hergestellt werden, typischerweise über manuelle oder halbautomatische Datentransfers.

Es bietet keine konsolidierte Sicht über mehrere Vertragsstrukturen. Wer parallel ein CPEA-Agreement und mehrere Subscription-Verträge betreibt, sieht diese in separaten Ansichten, nicht als zusammengeführtes Budget-Bild.

Es liefert keine automatisierte Buchungslogik. Die Übernahme von Subaccount-Verbrauchsdaten in das interne Rechnungswesen ist ein manueller oder prozessual zu lösender Schritt. In der Praxis führt das häufig zu Excel-basierten Allokationsmodellen, die bei jeder Vertragsänderung oder Organisationsanpassung überarbeitet werden müssen.

Dieser letzte Punkt ist der am häufigsten unterschätzte Aspekt: Excel-Allokationsmodelle sind keine dauerhaft tragfähige Lösung für ein wachsendes SAP-Portfolio. Sie skalieren nicht mit der Komplexität des Portfolios, ihre Qualität hängt von einzelnen Personen ab, und sie erfordern bei jeder Vertragsänderung manuelle Nacharbeit.

Drei typische Allokationsmuster in der Praxis

In der Praxis zeigen sich drei Allokationsansätze, die je nach Organisationsstruktur unterschiedliche Stärken und Schwächen haben.

Verbrauchsbasierte Allokation (direkt): BTP-Verbrauch wird auf Basis der Subaccount-Daten direkt auf die zugeordneten Kostenstellen übertragen. Diese Methode ist die präziseste und schafft echte Kostenverantwortung. Sie setzt voraus, dass die Subaccount-Struktur konsequent nach Zurechnungseinheiten organisiert ist, und ist der Zielpfad für jede reife BTP-Governance.

Nutzungsbasierte Schlüsselung: Wo Subaccounts nicht nach Kostenstellen getrennt sind, wird der Gesamtverbrauch eines Subaccounts nach einem Nutzungsschlüssel aufgeteilt. Dieser Schlüssel kann auf dem Anteil der aktiven Nutzer pro Geschäftsbereich, dem Anteil der Transaktionsvolumina oder einer vorab vereinbarten Gewichtung basieren. Diese Methode ist weniger präzise, aber operativ einfacher umzusetzen, solange keine vollständige Subaccount-Trennung vorhanden ist.

Flat-Rate-Chargeback: Ein fixer interner Preis pro definierter BTP-Nutzungseinheit wird vorab festgelegt und periodisch aktualisiert. Vorteil: Planbarkeit für die Fachbereiche, weil der interne Preis stabil ist und nicht monatlich schwankt. Nachteil: Die tatsächlichen Vertragskosten weichen ab, wenn der reale Verbrauch vom Plan abweicht. Flat-Rate-Modelle eignen sich besonders für stabile, vorhersagbare Workloads wie HANA-Cloud-Produktionsbetrieb oder Integration-Suite-Grundbetrieb. Für variable Workloads, insbesondere AI-Nutzung, sind sie weniger geeignet.

Allen drei Mustern gemeinsam ist: Je mehr die interne Allokation die tatsächliche Vertragslogik widerspiegelt, desto belastbarer ist die Grundlage für Renewal-Verhandlungen, Budget-Forecasting und die strategische Priorisierung neuer BTP-Vorhaben.

Wie der Steuerungsmoment "Kosten" BTP-Governance und interne Verrechnung verbindet

Der Steuerungsmoment im Bereich Kosten im FinOptory-Governance-Modell umfasst vier Dimensionen: ACV-Tracking, Derived Charges, Rechnungsabgleich und interne Verrechnung. Diese vier Dimensionen sind nicht unabhängig.

Wer ACV-Tracking betreibt, weiß, ob der Jahresverbrauch auf Kurs liegt. Wer Derived Charges verfolgt, erkennt Overage-Risiken, bevor sie eintreten. Wer die SAP-Rechnung gegen die eigenen Balance-Statement-Daten abgleicht, stellt Plausibilität sicher. Und wer intern verrechnet, schließt den Kreis: Die Kosten, die auf Vertragsebene sichtbar sind, landen bei den Einheiten, die sie erzeugen.

Ohne interne Verrechnung bleiben die ersten drei Dimensionen Aufgaben des zentralen IT-Budgets, ohne dass die Treiber in den Fachbereichen sichtbar werden. Mit interner Verrechnung entsteht ein vollständiger Steuerungsmoment: Von der Vertragsstruktur über den monatlichen Verbrauch bis zur organisatorischen Verantwortung.

Dieser Zusammenhang ist der Grund, warum die Entscheidung über Subaccount-Struktur und Verrechnungsmodell nicht als technische Nacharbeit behandelt werden sollte, sondern als Teil der BTP-Governance-Konzeption von Beginn an.

Häufige Fragen

Wie verteile ich BTP-Kosten auf interne Kostenstellen, wenn ich keine saubere Subaccount-Struktur habe?

Ohne Subaccount-Trennung ist eine direkt verbrauchsbasierte Allokation nicht möglich. Als Übergangslösung ist eine nutzungsbasierte Schlüsselung auf Basis von Transaktionsvolumina oder Nutzeranteilen je Geschäftsbereich ein praktischer Ansatz. Parallel sollte die Subaccount-Struktur für neue Projekte konsequent nach Zurechnungseinheiten aufgebaut werden. Eine nachträgliche Umstrukturierung bestehender Subaccounts ist technisch möglich, erfordert aber Sorgfalt bei der Entitlement-Neuzuweisung (Quelle: SAP Help Portal, Monitoring Usage and Consumption Costs).

Was ist der Unterschied zwischen Showback und Chargeback bei BTP?

Showback macht BTP-Kosten für Kostenstellen und Projekte transparent, ohne interne Buchungen vorzunehmen. Chargeback verrechnet diese Kosten tatsächlich auf die Budgets der Fachbereiche. Showback schafft Kostenbewusstsein, Chargeback schafft Kostenverantwortung. Viele Organisationen beginnen mit Showback und führen Chargeback ein, nachdem intern Akzeptanz für die Kostenstruktur entstanden ist (Quelle: FinOps Foundation, FinOps Framework 2025).

Wie oft sollte die interne Verrechnung aktualisiert werden?

Monatlich, weil die BTP-Balance Statements monatlich geliefert werden und relevante Verbrauchskomponenten auf Monatsbasis abgerechnet werden. Eine quartalsweise Aggregation reicht für Budget-Reviews, erfasst aber keine unterjährigen Verschiebungen, die für Renewal-Vorbereitung oder Overage-Steuerung relevant sind.

Welche Daten brauche ich, um einen ersten Chargeback-Prozess aufzubauen?

Vier Bestandteile sind notwendig: erstens die monatlichen Balance Statements je Subaccount aus dem BTP Cockpit, zweitens der vertraglich fixierte Credit-Preis aus dem Order Form, drittens das Mapping zwischen Subaccounts und internen Kostenstellen oder Projekten, und viertens ein definiertes Freigabe- und Buchungsverfahren für die monatliche Verrechnung. Der aufwändigste Teil ist in der Regel das Mapping, weil es die interne Organisationsstruktur mit der BTP-Architekturentscheidung verbindet (Quelle: SAP Help Portal, Monitoring Usage and Consumption Costs).

Nächste Schritte

BTP-Kostenallokation als Teil des Vertragscheck: Wenn Sie eine Grundlage für die verursachergerechte Verrechnung Ihrer BTP-Kosten aufbauen wollen, beginnt das mit einer vollständigen Analyse Ihrer aktuellen Subaccount-Struktur, Vertragsmodelle und Verbrauchsdaten. Der FinOptory Vertragscheck liefert diese Grundlage in vier Wochen, mit einer konkreten Handlungsempfehlung als Ergebnis.

Weiterführende Artikel: FinOps Inform-Optimize-Operate für SAP BTP | SAP-Kosten intern verrechnen: Wo SAP-eigene Werkzeuge an Grenzen stoßen | BTP FinOps: Übersicht