IT-Kostencontrolling in Banken: Kosten zuordnen, Abweichungen erklären

01 / Begriffe klären

Ein Budget ist keine Prognose

Der Satz „Wir liegen im Plan“ bleibt unklar, solange niemand den Plan benennt. Gemeint sein können ein genehmigtes Budget, eine überarbeitete Bedarfsplanung oder der aktuelle Forecast. Für die Steuerung braucht jede Sicht einen Namen, einen Zeitraum und einen festgehaltenen Stand. Die FinOps Foundation behandelt Budgetierung und Forecasting deshalb als zusammenhängende, aber unterschiedliche Aufgaben. [1] [2]

Eine Forecast-Anpassung genehmigt kein zusätzliches Budget. Das ursprüngliche Budget bleibt als Vergleich erhalten. Wird der Rahmen später formell geändert, braucht auch diese Änderung einen eigenen Stand und eine Begründung.

Zahlungen und GuV-Aufwand sind weitere Sichten. Eine vorausbezahlte Jahreslizenz kann in der Liquiditätsplanung an einem Termin erscheinen und in einer periodisierten Kostenbetrachtung auf mehrere Monate entfallen. Beides ungeprüft zu addieren erzeugt eine Doppelzählung. Welche Überleitung im konkreten Institut gilt, stimmt das Controlling mit dem Rechnungswesen ab.

02 / Musterfall ITK-2026-01

Im Juni ausgeglichen. Im Dezember 75.000 Euro darüber.

Das genehmigte Jahresbudget beträgt 540.000 Euro. Davon sind 300.000 Euro für Januar bis Juni vorgesehen, weil das Migrationsprojekt ursprünglich vollständig im ersten Halbjahr abgeschlossen sein sollte. Genau 300.000 Euro sind bis Ende Juni angefallen. Die Gesamtsumme wirkt unauffällig. Die Einzelpositionen erzählen eine andere Geschichte.

H1 = Januar bis Juni; H2 = Juli bis Dezember. Positives Vorzeichen bedeutet Mehrkosten gegenüber dem ursprünglichen Jahresbudget. Jahresforecast = Ist H1 + Forecast H2. Eigene Modellrechnung; vollständige Eingaben und Zuordnungen stehen unter Arbeitsmaterial.

Bei der Cloud sind im Halbjahr bereits 12.000 Euro mehr angefallen. Gleichzeitig wurden für die Migration 12.000 Euro weniger erfasst. Das Projekt ist allerdings verspätet, nicht günstiger geworden. Die beiden Abweichungen heben sich in der Summe auf. Für den Rest des Jahres werden noch 315.000 Euro benötigt, obwohl vom ursprünglichen Budget nur 240.000 Euro verbleiben.

Auch eine einfache Verdoppelung des Halbjahres-Ist wäre hier unzureichend: Sie ergäbe 600.000 Euro und läge 15.000 Euro unter dem aktuellen Forecast. Die geplanten Änderungen im zweiten Halbjahr müssen ausdrücklich in die Erwartung eingehen. Genau darin liegt der Unterschied zwischen einer Hochrechnung und einer begründeten Prognose. [2]

03 / Daten und Verantwortliche

Von der Abrechnung zum IT-Service

Eine Dienstleisterrechnung sagt zunächst, wer was abrechnet. Sie beantwortet nicht automatisch, welcher Bankprozess die Leistung nutzt oder wer über den künftigen Bedarf entscheidet. Für eine belastbare Zuordnung braucht jede Kostenposition mindestens einen eindeutigen Ursprung, den Leistungszeitraum, die Kostenart und einen verantwortlichen Empfänger.

Die Kostenstelle beantwortet eine organisatorische Frage, der Service eine Leistungsfrage. Ein interner Auftrag kann wiederum einen Vorgang oder ein Projekt bündeln. Diese Dimensionen dürfen nebeneinander bestehen. Bei einer statistischen Kontierung muss besonders klar sein, welche Sicht nur zur Auswertung dient. Die SAP-Dokumentation unterscheidet entsprechend zwischen statistischen und realen Kontierungen. [6]

Diese Felder gehören in die Zuordnungsregel

• Quelle und Schlüssel: Beleg- oder Import-ID, Positions-ID und Quellsystem. Mehrfachimporte müssen erkennbar bleiben.
• Zeit und Wertart: Leistungsmonat, Buchungsstand, Ist/Budget/Forecast und Kostenbasis. Ein Importdatum ersetzt keinen Leistungszeitraum.
• Empfänger: Kostenstelle, IT-Service, gegebenenfalls Projekt oder interner Auftrag. Ungeklärte Positionen bekommen einen sichtbaren Klärungsstatus.
• Regel und Verantwortung: Direktzuordnung oder Schlüssel, gültig von/bis, Regelversion, fachlich zuständige Person und dokumentierte Freigabe.

Im Musterfall heißen die Quellen C01 bis C05, die Serviceempfänger S-K, S-R und S-W. Die Regelversion DRV-01 gilt hier vereinfachend für alle betrachteten Perioden. Ein reales Modell muss Änderungen zeitlich abgrenzen. Ein im Juli geänderter Schlüssel darf das bereits berichtete Januar-Ist nicht stillschweigend neu verteilen.

Die TBM-Taxonomie bietet dafür einen umfangreicheren Ordnungsrahmen: Sie verbindet Kostenpools und technologische Ressourcen mit Lösungen und Verbrauchern. Der kleine Fall in diesem Beitrag bildet diese Taxonomie nicht vollständig ab. Er zeigt den grundlegenden Nutzen einer klaren Verbindung zwischen Finanz- und Leistungssicht. [5]

04 / Ursachen prüfen

Erst den Fehler ausschließen, dann die Mehrkosten erklären

Vor einer fachlichen Bewertung steht eine kurze Datenprüfung: Fehlt eine Rechnung? Wurde dieselbe Position zweimal importiert? Ist eine Gutschrift enthalten? Gehören Ist und Budget zum gleichen Zeitraum? Wurde aus einer vorausbezahlten Position versehentlich sowohl die Zahlung als auch der periodisierte Betrag übernommen?

Ein unbekannter Betrag bleibt als offen gekennzeichnet; er wird nicht durch null ersetzt. Eine Korrektur braucht Grund, Beleg, verantwortliche Person und einen neuen Datenstand. Anschließend werden die betroffenen Summen erneut abgestimmt.

Danach lassen sich echte Veränderungen untersuchen. Preis, Menge, Leistungsumfang und zeitliche Verschiebungen brauchen unterschiedliche Maßnahmen. Eine geänderte Zuordnung ist nochmals etwas anderes: Sie verändert zunächst den Empfänger, nicht die Gesamtkosten.

Preis und Menge mit einer festen Rechenregel zerlegen

Ein separates Rechenbeispiel zeigt die Methode: Geplant sind 1.000 Leistungseinheiten zu 10 Euro, also 10.000 Euro. Tatsächlich werden 1.200 Einheiten zu 11 Euro genutzt, also 13.200 Euro. Die Abweichung beträgt 3.200 Euro. Sie wird hier in einer festgelegten Reihenfolge zerlegt:

1. Preiseffekt bei Planmenge: (11 − 10) × 1.000 = 1.000 Euro.
2. Mengeneffekt zum neuen Preis: (1.200 − 1.000) × 11 = 2.200 Euro.
3. Abstimmung: 1.000 + 2.200 = 3.200 Euro.

Eine andere Zerlegungsreihenfolge verteilt den gemeinsamen Preis-Mengen-Effekt anders. Deshalb gehört die Methode zur Kennzahl. Bei wechselnden Leistungspaketen, Staffelpreisen oder Rabatten reicht dieses einfache Modell nicht aus. Das Beispiel ist unabhängig von der Cloud-Position C01; es erklärt nicht deren konkrete 36.000 Euro Jahresabweichung.

Für die Prüfung einer Dienstleisterabrechnung werden Mengen, Tarife, vereinbarte Leistungen und Leistungszeitraum mit dem Vertrag und der tatsächlichen Nutzung abgeglichen. Ein auffälliger Betrag ist ein Prüfhinweis. Ob die Rechnung falsch ist, lässt sich erst aus diesen Belegen entscheiden.

05 / Kosten zuordnen

Gemeinschaftskosten verteilen, ohne sie doppelt zu zählen

Direkt zuordenbare Kosten bleiben direkt zugeordnet. Für gemeinsam genutzte Infrastruktur braucht es einen begründeten Schlüssel. Nutzungsdaten, Zeitanteile oder gewichtete Supportleistungen können dafür geeignet sein. Eine Verteilung nach Kopfzahl ist nur sinnvoll, wenn sie die betrachtete Leistung hinreichend erklärt. Die FinOps Foundation beschreibt mehrere Verfahren und auch die Möglichkeit, bestimmte Kosten bewusst zentral zu tragen. [3] [4]

Beim Support zählt im Modell die gewichtete Leistung. Eine rohe Ticketanzahl würde den Aufwand unterschiedlich komplexer Vorgänge möglicherweise falsch abbilden. Die Lizenzbeträge sind direkte Zuordnungen; sie sind kein allgemeiner Umlageschlüssel für andere Kostenarten.

Die 429.000 Euro Gemeinschaftskosten sind bereits in den 615.000 Euro Servicekosten enthalten. Wer sie nochmals addiert, weist fälschlich 1.044.000 Euro aus. Quellen und Empfänger sind zwei Sichten auf dieselben Kosten. Im Beispiel wird alles verteilt; eine bewusst zentral verbleibende Position wäre möglich und müsste in der Abstimmung sichtbar bleiben. Die Beispielbeträge gehen ohne Rundungsrest auf. Bei Cent-Beträgen braucht das reale Modell zusätzlich eine dokumentierte Regel für die Verteilung von Rundungsresten.

Showback und Chargeback sind unterschiedliche Schritte

Showback macht den zugeordneten Verbrauch und seine Kosten für Verantwortliche sichtbar. Chargeback belastet einen Empfänger nach vereinbarten Verrechnungsregeln. Eine Verteilung in einem Bericht löst nicht automatisch eine Buchung aus. Auch Leistungspreiskalkulation, Zuordnung im Bericht und buchhalterische Verrechnung sollten deshalb getrennt beschrieben werden. Im T-NEX Controlling wirken Verrechnungsmodelle in den Auswertungen; die eigentlichen Buchungen im Rechnungswesen werden dadurch nicht erzeugt. [8]

06 / Restjahr planen

Bestellungen gehören in den Forecast, nicht oben drauf

Der Restjahresforecast enthält 315.000 Euro. Davon entfallen 174.000 Euro auf externe Bestellbindungen und 141.000 Euro auf weitere Schätzungen einschließlich interner Ressourcen. Die beiden Beträge erklären die Zusammensetzung des Restbedarfs. Sie sind keine zusätzlichen Kosten neben ihm.

Wer die 174.000 Euro erneut zum vollständigen Restjahresforecast addiert, zählt sie doppelt. Ebenso dürfen bereits im Ist enthaltene Lieferungen nicht nochmals als offener Restbedarf behandelt werden. Dafür müssen Bestellposition, erbrachte Leistung, Rechnung und verbleibender Bedarf zusammenpassen.

„Bestellbindung“ bezeichnet hier nur die definierte externe Größe. Eine Null beim internen Betrieb bedeutet nicht, dass keine Arbeitsverträge oder anderen Verpflichtungen bestehen. Auch eine Bilanzverbindlichkeit lässt sich daraus nicht ableiten.

Was sich seit dem letzten Forecast geändert hat

Jede wesentliche Anpassung sollte einen nachvollziehbaren Auslöser nennen: mehr Nutzung, einen neuen Tarif, eine verlängerte Migration oder einen weggefallenen Bedarf. Dazu gehören der betroffene Zeitraum, die Quelle der Annahme und die zuständige Person. Eine neue Version ersetzt die alte Erwartung im aktuellen Bericht, löscht aber deren Historie nicht.

Eine mögliche Cloud-Maßnahme im Fall würde den Restjahresbedarf um 18.000 Euro reduzieren. Das ergäbe einen Szenariowert von 597.000 Euro. Er ist weder eine realisierte Einsparung noch der Basisforecast. Erst wenn Umfang, Umsetzbarkeit, notwendige Leistung und Entscheidung geklärt sind, kann eine solche Annahme in die nächste Prognose eingehen.

07 / Steuerung statt Ablage

Was aus einer Abweichung folgen soll

Ein Bericht endet nicht bei einem roten Feld. Im Musterfall lassen sich drei verschiedene Aufträge ableiten: Die Serviceverantwortlichen erklären die Cloud-Nutzung, IT-Leitung und Controlling bewerten den zusätzlichen internen Aufwand, die Projektleitung aktualisiert den verbleibenden Migrationsumfang. Einkauf oder Vertragsmanagement klären, wo sich Mengen und Laufzeiten tatsächlich ändern lassen.

Für jeden Auftrag werden Verantwortliche, Termin und Ergebnis festgehalten. Nicht jede Abweichung führt zu einer Kürzung. Manchmal ist zusätzlicher Bedarf sachlich begründet; manchmal muss ein Vorhaben neu priorisiert werden. Die Entscheidung braucht dann den betroffenen Service, den erwarteten Effekt und die Konsequenzen für Leistung und Risiko.

Wie Dienstleisterbeziehungen organisatorisch eingeordnet werden, behandelt der Beitrag zur Auslagerung in Banken. Für die vorgeschriebenen Registerinformationen zu IKT-Verträgen ist das DORA-Informationsregister der passendere Einstieg. Eine Kostenübersicht ersetzt diese Aufgaben nicht.

08 / KI sinnvoll einsetzen

Eine gute KI-Antwort braucht mehr als eine plausible Erklärung

Im IT-Controlling liegt ein sinnvoller Einsatz von KI darin, vorhandene Informationen schneller zugänglich zu machen: relevante Positionen finden, Veränderungen zusammenfassen und Rückfragen vorbereiten. Für belastbare Ergebnisse muss die Antwort jedoch erkennen lassen, auf welche Daten und Definitionen sie sich bezieht. Eine sprachlich überzeugende Begründung ohne Beleg hilft bei einer Budgetentscheidung wenig.

Eine Prüffrage mit erwartbarer Antwort

Für den Musterfall lautet eine konkrete Frage: „Warum liegt unser Jahresforecast 75.000 Euro über BUD-2026-01, obwohl das Ist bis Juni im Budget liegt?“ Eine belastbare Antwort muss die Version FC-2026-06, die fünf Kostenpositionen und die verdeckte Halbjahresabweichung erkennen. Sie darf aus den verzögerten Projektkosten keine Einsparung machen.

• Beleg: Werden Quelle, Zeitraum, Wertart und Regelversion genannt?
• Rechnung: Stimmen die Teilbeträge mit den 75.000 Euro überein?
• Unsicherheit: Bleibt erkennbar, welche künftigen Kosten auf Annahmen beruhen?
• Berechtigung: Beschränkt sich die Antwort auf die für die fragende Person freigegebenen Daten?
• Handlung: Bleiben Analyse, vorgeschlagene Maßnahme und genehmigte Änderung getrennt?

Den Nutzen eines solchen Einsatzes misst die Bank am konkreten Arbeitsablauf: etwa an Such- und Abstimmungszeit, fachlichen Korrekturen oder nachvollziehbaren Quellenbezügen. Freie Kapazität ist dabei noch keine zahlungswirksame Einsparung. Auch regelbasierte Kontrollen oder ein Verarbeitungslauf sind nicht schon deshalb generative KI, weil sie Arbeit automatisieren.

09 / Umsetzung mit T-NEX

Kostensteuerung im Zusammenhang der Banking Platform

Für eine Bank ist die Verbindung zwischen Kostenposition und Folgeentscheidung oft aufwendiger als die Addition selbst. Der T-NEX AI Controlling Hub verbindet hierfür Datenübernahme, Planung und Auswertung. Er ist Teil der Banking Platform, die weitere Arbeitsbereiche wie Reporting und Projektmanagement adressiert. So lässt sich die Controlling-Aufgabe im Zusammenhang mit den Abläufen betrachten, aus denen Kosten und Maßnahmen entstehen. [8] [9]

Die Produktunterlagen beschreiben unter anderem Kostenstellen, interne Aufträge, Kostenarten und Leistungen sowie Vertrags- und Bestellbezüge. Als Wertarten werden unter anderem Ist, Obligo, Budget, Plan-IT und Finanzplan unterschieden. Ihre fachliche Definition und die passenden Vergleiche sind im jeweiligen Datenmodell festzulegen. Bei Planungsläufen steht eine Vorschau vor der Verarbeitung zur Verfügung. Ein solcher Planungsassistent ist ein Verarbeitungsschritt; daraus folgt kein Versprechen eines automatisch erzeugten, treffsicheren Jahresforecasts. [8]

Im Fall könnte der erkannte Migrationsmehrbedarf in die Projektsteuerung übergehen und mit dem Managementbericht verbunden werden. Welche Datenbezüge zwischen AI Project Management, AI Reporting und Controlling für ein Institut eingerichtet werden, ist im konkreten Einsatz zu klären. Der Plattformbezug ersetzt keine Prüfung von Datenmodell, Berechtigungen und Schnittstellen.

Fünf Aufgaben für eine aussagekräftige Software-Demo

1. Eine Position zurückverfolgen: Von der Serviceauswertung zur Kostenquelle wechseln. Importstand, Leistungszeitraum und verwendete Regel müssen erkennbar sein.
2. Einen Schlüssel ändern: Die Gültigkeit auf einen neuen Zeitraum begrenzen und prüfen, ob die alte Sicht reproduzierbar bleibt.
3. Eine Planung vorab ansehen: Auswirkungen eines Laufs kontrollieren, bevor Werte verarbeitet werden. Zuständigkeit und Freigabe im konkreten Verfahren prüfen.
4. Die Summe abstimmen: Quellkosten, zugeordnete Servicekosten und zentralen Rest gegenüberstellen. Die 615.000 Euro dürfen durch die Verteilung nicht wachsen.
5. Eine KI-Antwort belegen: Den Fall mit der 75.000-Euro-Abweichung erklären lassen. Quellenbezug, Rechenweg, Berechtigung und Umgang mit fehlenden Daten prüfen.

Diese Aufgaben sind ein vorgeschlagener Abnahmekatalog. Sie behaupten nicht, dass jede Funktion ohne Einrichtung, zusätzliche Daten oder projektspezifische Abstimmung verfügbar ist. Produktbasis: öffentliche Seiten und Controlling-Gesamthandbuch vom 25.08.2026; keine Übernahme von Kundendaten.

10 / Direkt weiterarbeiten

Musterfall, Arbeitsvorlage und Rechendaten

Die Unterlagen enthalten denselben Fall wie der Artikel. Sie machen Kostenbasis, Quellen, Verteilungsregeln und Kontrollsummen offen prüfbar. Die Blankovorlage lässt sich für einen eigenen, bereinigten Ausschnitt ausfüllen. Alle Materialien sind deutsch und ohne Registrierung verfügbar.

Die HTML-Arbeitsvorlage lässt sich im Browser ausfüllen und drucken. Eingaben werden nicht automatisch gespeichert. Vor dem Schließen als PDF drucken oder in das eigene System übernehmen. Die JSON-Dateien dienen zur Weiterverarbeitung; die CSV-Dateien enthalten die modellierten Daten, keine realen Bankinformationen.

Vor der nächsten Controlling-Runde prüfen

1. Sind Quelle, Kostenbasis und Leistungszeitraum jeder Position eindeutig?
2. Bleiben ursprüngliches Budget und aktueller Forecast getrennt?
3. Sind direkte Kosten vor den Gemeinschaftskosten zugeordnet?
4. Sind Verteilungsschlüssel, Gültigkeit und Verantwortliche dokumentiert?
5. Entspricht die Summe aus Empfängerkosten und zentralem Rest den Quellkosten?
6. Sind Bestellbindungen bereits im Restjahresforecast enthalten?
7. Sind zeitliche Verschiebungen von tatsächlichen Kostenänderungen getrennt?
8. Stehen zu jeder wesentlichen Abweichung Ursache, Auftrag und zuständige Person fest?

Fragen aus der Praxis

Häufige Fragen zum IT-Kostencontrolling