Warum Excel nach der ERP-Transformation zurückkehrt – und was Controller dagegen tun können

Die Excel-Datei, die nicht verschwinden wollte

Monatsabschluss. Im System laufen Millionen Buchungen korrekt durch, Dashboards zeigen Echtzeitstände, Prozesse sind integriert, Daten konsistent. Und trotzdem öffnet im Controlling jemand eine Datei mit dem Namen Forecast_final_v8.xlsx.

Eigentlich sollte diese Szene nach einer erfolgreichen Systemmodernisierung der Vergangenheit angehören. Doch nur wenige Monate nach dem Go-Live entstehen in vielen Unternehmen erneut Excel-Nebenwelten – zunächst als Ausnahme, später als alltägliche Praxis.

Die Erwartung vieler Transformationen lautet: Mit S/4HANA verschwinden Excel-Lösungen automatisch. Die Realität zeigt häufig das Gegenteil. Forecasts entstehen wieder außerhalb des Systems, Reports werden lokal konsolidiert, neue Nebenwelten wachsen – leise und pragmatisch.

Die entscheidende Frage, die sich dabei stellt: Wurde die Architektur der Unternehmenssteuerung mit derselben Konsequenz entwickelt wie die Architektur der Buchung? In den meisten Unternehmen lautet die Antwort: nein. Und genau hier beginnt das Steuerungsparadox.

Das Problem liegt selten bei den Anwendern – sondern in der Art, wie Transformationsprojekte priorisiert werden.

Wenn im Monatsreview plötzlich die falsche Frage gestellt wird

Drei Monate nach Go-Live stellte ein CFO im Monatsreview eine scheinbar einfache Frage:

Excel-Dateien enthalten dabei häufig geschätzte Werte oder manuelle Umlagen – Entscheidungen basieren damit auf Annahmen statt auf geprüften Daten.

Wo landet dieser Aufwand am Ende – und welche Kostenstelle trägt ihn tatsächlich?

Im System war alles korrekt gebucht. Doch die finale Kostenstellenzuordnung ließ sich nicht unmittelbar nachvollziehen. ERP-Systeme sind hervorragende Transaktionsmaschinen. Einkaufsprozesse, Wareneingänge, Rechnungen und Zahlungen laufen integriert, das Universal Journal liefert konsistente Daten.

Das Controlling beantwortet jedoch nicht die Frage, ob gebucht wurde – sondern wo ein Aufwand final in der Kostenrechnung landet. Das Management fragt nicht nach dem Buchungsweg, sondern nach der Zuordnung: Welche Kostenstelle trägt diesen Aufwand? Welches Produkt, welcher Kanal, welcher Markt? Erst dort entsteht Steuerungsrelevanz.

Für CFOs bedeutet das: Reportingarchitektur ist kein IT-Thema, sondern Bestandteil der Steuerungsarchitektur. Wer diese Ebene im ERP-Projekt nicht mitdenkt, unterschreibt stillschweigend die Rückkehr von Excel.

Aus der Praxis: Eine Rechnung über 120.000 EUR für externe Instandhaltungsleistungen wird korrekt erfasst – aber zunächst auf ein übergeordnetes Verwaltungskostenkonto gebucht, weil die finale Kostenstellen-Zuordnung noch offen ist. Im ERP ist die Buchung technisch sauber. Die Steuerungsfrage – belastet dieser Aufwand Werk A oder Werk B, laufender Betrieb oder Investitionsprojekt – bleibt unbeantwortet. Der Controller öffnet Excel.

Gerade Einkaufs- und Aufwandsprozesse erzeugen mehrstufige Buchungsketten. Standardberichte zeigen einzelne Schritte, aber nicht die wirtschaftliche Endwirkung. Fehlt diese Sicht, beginnt die manuelle Rekonstruktion. Excel springt dort ein, wo die Steuerungslogik im System nicht konsequent zu Ende gedacht wurde.

Das schwarze Loch zwischen Buchung und Steuerung

Beispiel: Ein produzierendes Unternehmen mit drei Werken und einem Jahresumsatz von rund 280 Mio. EUR. Der CFO will im Monatsreview wissen, welches Werk profitabel arbeitet – und welches nicht. Die Antwort kostet den Controller zwei Tage.

Werk Süd hat im laufenden Quartal externe Instandhaltungsleistungen im Umfang von 1,2 Mio. EUR beauftragt – Verpflichtungen, die im Kostenstellenbericht zunächst nicht sichtbar sind. Das ERP bildet den Beschaffungsprozess korrekt ab – und erzeugt dennoch ein klassisches Steuerungsproblem. Die Buchungskette zeigt, wo die Steuerungssicht verloren geht:

Schritt 1 – Bestellung (Obligo):

Die Bestellung erzeugt eine Mittelbindung auf der Kostenstelle Werk Süd / Instandhaltung. Im Kostenstellenbericht taucht dieses Obligo nicht auf – es liegt in einem separaten Verpflichtungsbericht, den die wenigsten Manager öffnen. Für die Deckungsbeitragsrechnung des Werks ist dieser Betrag in diesem Moment unsichtbar.

Schritt 2 – Leistungserfassung:

Die Instandhaltungsfirma erbringt die Leistung in drei Tranchen über zwei Monate. Mit jeder Leistungsbestätigung bucht das ERP automatisch auf ein technisches Verrechnungskonto – das sogenannte Waren-/Rechnungseingangskonto. Buchungssatz: Verrechnungskonto an Verbindlichkeiten. Die Kostenstelle Werk Süd ist zu diesem Zeitpunkt noch nicht belastet. Im Kostenstellenbericht: kein Eintrag.

Schritt 3 – Rechnungseingang:

Die erste Teilrechnung trifft vier Wochen nach Leistungserbringung ein. Erst jetzt erfolgt die endgültige Kontierung auf die Kostenstelle Werk Süd / Kostenart Fremdleistungen Instandhaltung. Buchung und wirtschaftliche Leistung liegen vier Wochen – und zwei Berichtsperioden – auseinander.

Schritt 4 – Gemeinkostenumlage:

Ende des Monats läuft eine automatische Umlage der Werksgemeinkosten. Basis: nur die bereits gebuchten Ist-Kosten — nicht das Obligo, nicht die noch offenen Leistungsbestätigungen. Die Umlage ist damit systematisch zu niedrig. Der ausgewiesene Deckungsbeitrag II von Werk Süd ist verzerrt.

Was der Controller im Monatsabschluss sieht – und was er nicht sieht:

Der Systembericht zeigt 500.000 EUR Kostenbelastung – der Plan lag bei 250.000 EUR. Schlechter als erwartet, aber noch beherrschbar. Die wirtschaftliche Realität: 2.000.000 EUR. Offene Bestellungen und Umlagen erscheinen in separaten Berichten – und bleiben im Monatsreview unsichtbar. Das Management entscheidet auf Basis eines Bruchteils der tatsächlichen Kosten.

Der Excel-Workaround – und sein Preis: Der Controller exportiert drei separate Listen: das Belegjournal für gebuchte Ist-Kosten, die Verpflichtungsliste für offene Bestellungen und den Umlage-Bericht aus der Kostenstellenrechnung. Er verbindet alle drei per SVERWEIS über die Bestellnummer, schätzt die fehlende Umlage auf Basis des Vormonats und baut daraus eine konsolidierte Kostenstellenansicht. Zeitaufwand: sechs Stunden. Dateiname: Werk_Sued_Kosten_Oktober_v4_final.xlsx.

Das Grundproblem: Das ERP hat keinen einzigen Fehler gemacht. Alle Buchungen sind korrekt, alle Prozesse laufen sauber. Die Lücke liegt zwischen den Berichtsebenen: Verpflichtungen, Ist-Kosten und Umlagen existieren als separate Sichten, die kein Standardbericht zusammenführt. Diese Verbindung herzustellen ist Aufgabe des Controllers – manuell, fehleranfällig, nicht revisionssicher.

Das System weiß alles. Aber es zeigt nicht, was das Management braucht.

Praxis-Tipp: Wenn Excel zum heimlichen Betriebssystem wird

Excel-Reports entstehen selten zufällig. Forecasts werden lokal versioniert, Investitionsübersichten manuell konsolidiert oder Managementberichte monatlich neu aufgebaut, weil Daten, Kommentierung und Freigaben nicht systemisch zusammenlaufen. Wer konkret Excel nutzt – und warum:

Das Muster ist in allen Fällen identisch: Das ERP liefert korrekte Daten – aber nicht in der Verdichtung und Verknüpfung, die die Steuerungsentscheidung erfordert. Excel schließt die Lücke. Schnell, flexibel – und für alle Beteiligten mit hohem persönlichem Risiko verbunden.

Echtzeit ist kein Ersatz für Erinnerung

Ein weiterer Trugschluss moderner Systemprojekte lautet: Echtzeit ersetzt Historie. Systeme zeigen zuverlässig den aktuellen Stand – Managemententscheidungen benötigen jedoch Vergleich und Entwicklung. Fragen wie: Wie sah der Forecast vor zwei Quartalen aus? Wann begannen Abweichungen? Welche Annahmen galten zu welchem Zeitpunkt? Diese Fragen lassen sich häufig nur über manuelle Versionen beantworten.

Fehlen systemische Snapshot- oder Versionsmechanismen, entstehen lokale Sicherungen. Dateien werden archiviert, Definitionen laufen auseinander. Was als Übergangslösung beginnt, bleibt oft dauerhaft bestehen.

Echtzeit ohne Historie ist wie ein Navigationssystem ohne Streckenverlauf: Man kennt den Standort, aber nicht den Weg dorthin.

In der heißen Projektphase einer ERP-Migration zählt vor allem Stabilität. Abschlüsse müssen funktionieren, Transaktionen korrekt laufen, Risiken minimiert werden. Reporting wird als Phase-2-Thema behandelt. Standardberichte werden übernommen, Erweiterungen verschoben, Historisierung nicht priorisiert. In vielen Projekten zeigt sich: Excel ist selten die Ursache, fast immer das Symptom dieser frühen Projektentscheidungen.

Wege aus dem Steuerungsparadox

Die notwendigen Konsequenzen sind vor allem organisatorischer Natur. Steuerungslogik muss als Bestandteil des Zielbilds definiert werden – nicht als spätere Optimierung. Drei Hebel sind entscheidend:

• End-to-End-Reporting designen: Die Prozesskette vom wirtschaftlichen Ereignis bis zur finalen Buchungswirkung muss durchgängig nachvollziehbar sein – Obligo, Ist-Kosten und Umlagen in einer systemischen Sicht.
• Historisierung systemisch verankern: Forecasts und Planstände müssen automatisiert versioniert werden, sodass frühere Erwartungshaltungen und Annahmen jederzeit nachvollziehbar bleiben.
• Die letzte Meile integrieren: Kommentierung, Abstimmung und Freigaben müssen systemisch abgebildet werden, damit Entscheidungslogik nachvollziehbar bleibt und für Analytics nutzbar wird.

Was S/4HANA nativ kann – und wo die Grenzen liegen

S/4HANA bietet mehr Steuerungstiefe als viele Unternehmen nach dem Go-Live tatsächlich nutzen. Das Universal Journal fasst alle relevanten Dimensionen in einem einzigen Datensatz zusammen: Kostenstelle, Profit Center, Segment, Projekt, Geschäftsbereich. Wer die Architektur konsequent aufbaut, kann Buchungswirkung end-to-end nachvollziehen – ohne Exporte, ohne Zwischendateien. Vier Steuerungshebel bietet S/4HANA nativ:

• Profit-Center-Rechnung: Jede Buchung trägt automatisch das Profit Center. Kostenbelastungen lassen sich ohne manuelle Aggregation nach Verantwortungsbereich verdichten – das ersetzt viele Konsolidierungs-Excel-Dateien.
• Ergebnissegmentrechnung (CO-PA): Erlös- und Aufwandssichten nach Produkt, Kanal oder Region – systemisch und in Echtzeit, ohne manuelle Konsolidierung aus verschiedenen Quellen.
• Integrierte Verpflichtungsrechnung: Offene Bestellungen werden im selben Kostenstellenbericht ausgewiesen wie Ist-Kosten – die manuelle Zusammenführung per SVERWEIS entfällt, wenn die Architektur stimmt.
• Eingebettete Analyse auf dem Buchungsdatensatz: Berichte können direkt auf den ERP-Bewegungsdaten aufgebaut werden – konsistent und ohne Versionsrisiko.

Nicht jede Steuerungsanforderung lässt sich im ERP abbilden – das ist strukturell so und kein Versagen des Systems. Drei Bereiche erfordern regelmäßig ergänzende Lösungen:

Integrierte Unternehmensplanung:

Wenn Planung, Forecast und Ist-Daten aus mehreren Quellen zusammengeführt und mit Kommentierung sowie Freigabe-Workflows versehen werden müssen, stoßen ERP-Systeme an ihre Grenzen. Spezialisierte Planungslösungen beherrschen Versionierung, Workflow und Freigabeprozesse systemisch. Die Steuerungslogik bleibt damit im System – nicht in Dateien.

Konzernkonsolidierung:

Abschlüsse mit mehreren Gesellschaften, unterschiedlichen Währungen und konzerninternen Eliminierungen sind Spezialaufgaben, die das Standard-ERP nur begrenzt abbilden kann. Spezialisierte Konsolidierungslösungen schließen diese Lücke – und ersetzen die Excel-Konsolidierungsdateien, die andernfalls entstehen.

Flexibles Management-Reporting:

Wenn Controller ad-hoc neue Dimensionen und Sichten benötigen – ohne jedes Mal Entwicklungsaufwand auszulösen – bieten moderne BI-Plattformen Self-Service-Analysen. Entscheidend: Self-Service funktioniert nur dann nachhaltig, wenn es auf einem sauberen, zentralen Datenmodell aufsetzt. Wer Self-Service auf einem schlechten Fundament baut, ersetzt Excel nicht – sondern tauscht es gegen lokale Power-BI-Dateien.

Ergänzende Tools sind keine Schwäche – aber sie müssen auf einem stabilen ERP-Fundament aufsetzen. Wer ein schlecht konfiguriertes ERP mit einer BI-Plattform verbindet, verschiebt das Problem nur eine Ebene weiter. Excel bleibt dann das kürzeste Verbindungsstück zwischen den Systemen – nur mit anderem Dateinamen.

Controller können durch eine konsequent aufgebaute Steuerungsarchitektur monatlich mehrere Stunden manueller Abstimmungsarbeit vermeiden. Erfahrungswerte aus der Praxis zeigen: Wer Obligo, Ist-Kosten und Umlagen in einem systemischen Report zusammenführt, spart pro Monatsabschluss typischerweise zwischen vier und acht Stunden – Zeit, die für Analyse und Entscheidungsunterstützung genutzt werden kann.

Fazit: Reporting entscheidet über den Erfolg der Transformation

Das S/4HANA-Paradox ist kein Technologieproblem, sondern Ausdruck einer unvollständigen Transformation. Unternehmen modernisieren ihre Transaktionssysteme – während entscheidungsrelevante Logik außerhalb entsteht. Solange Verpflichtungen, Ist-Kosten und Umlagen nur als separate Berichtsebenen existieren, liegt die operative Wahrheit der Unternehmensführung nicht im System, sondern in lokalen Excel-Dateien. Und Entscheidungen werden auf Basis von Dateien getroffen, die niemand außer dem Controller versteht, versioniert oder prüft.

ERP-Systeme modernisieren Transaktionen. Unternehmenssteuerung entsteht jedoch erst dort, wo Reportinglogik, Historisierung und Entscheidungsprozesse systemisch zusammengeführt werden. Solange diese Ebene fehlt, bleibt Excel das inoffizielle Betriebssystem des Controllings – unabhängig davon, wie modern das ERP-System im Hintergrund ist.

Das könnte Sie auch interessieren:

Warum Reporting-Anpassungen im Unternehmen so lange dauern - ... und was Controller konkret tun können

Migration auf S/4HANA: Es wird höchste Zeit!