Der Ausgangspunkt

Die Gruppe: Industriedienstleistungen, 14 Rechtseinheiten in sieben Ländern, ~420 Mio. € Umsatz, seit 2022 auf einer Tier-1-ERP-Plattform. Die CFO hatte das System Mitte 2025 übernommen. Als wir hinzugezogen wurden, waren die Symptome aus dem Lehrbuch:

  • Monatsabschluss: 22 Arbeitstage, Konsolidierung rutschte regelmäßig in den nächsten Reporting-Zyklus.
  • Vier Reconciliation-Tools außerhalb des ERP — darunter ein Excel-VBA-Modell, das die vorherige Controllerin gebaut und nie dokumentiert hatte.
  • Intercompany-Differenzen von 2–4 Mio. € zum Monatsende, vor der Konsolidierung manuell ausgesteuert.
  • Audit-Findings zu Multibook-Abschreibung und Steuerrückstellungen — teils auf Konzern-, teils auf Gesellschaftsebene gebucht, ohne konsistentes Regelwerk.
  • Zwei offene Vendor-Angebote: „Neuimplementierung auf Plattform A" und „Migration auf Plattform B". Kombiniertes Budget: über 6 Mio. €, 14-Monats-Laufzeit.

Der Reflex des Vorstands: ersetzen. Die CFO vermutete, das System sei nicht das eigentliche Problem. Sie hat uns gebeten, diesen Verdacht zu prüfen, bevor sich das Unternehmen auf eines der beiden Vendor-Angebote festlegt.

Was wir in zwei Wochen gefunden haben

Das ERP war zweckgeeignet. Die Architektur darüber war es nicht. Die Plattform wurde gezwungen, ein Finance-Design zu kompensieren, das nie wirklich gemacht worden war.

Die Diagnose

Das zweiwöchige Assessment hat fünf Ebenen geprüft — Operating Model, Finance-Architektur, Stammdaten, Systemlandschaft, Governance — und auf einer Seite die Zielarchitektur und einen tragfähigen Plan formuliert. Die Kernbefunde:

1. Der Kontenrahmen war kopiert, nicht entworfen.

14 Gesellschaften, 14 unterschiedliche operative Lesarten derselben Konten, kein gruppenweites Konten-Wörterbuch. Das Mapping zur Konsolidierung lief jeden Monat manuell in Spreadsheets.

2. Multibook war nie aktiviert worden.

Local-GAAP- und IFRS-Anpassungen wurden im selben Ledger über „Tagging"-Konventionen gebucht, die von Land zu Land abweichend waren. Das ERP unterstützte Multibook ab Tag eins. Niemand hatte es konfiguriert.

3. Intercompany war ein Prozess, keine Architektur.

Jede IC-Buchung war eine zweiseitige manuelle Erfassung. Keine automatisierten Gegenbuchungen, keine zentrale IC-Clearing-Einheit, keine Policy darüber, welche Gesellschaft welche Transaktion führt. Die 2–4 Mio. € Differenz waren das Residuum davon.

4. Die „vier Reconciliation-Tools" waren Symptome.

Sie existierten, weil der Abschluss stromaufwärts kaputt war. Sie hatten sich etabliert, weil die Personen, die sie betrieben, die einzigen waren, die verstanden, was mit den Zahlen passierte.

5. Governance hatte keinen Eigentümer.

Kein Release-Kalender, kein Change Advisory, keine dokumentierte Finance-Verantwortung am ERP. Jede Anpassung war ein Einzelgespräch zwischen Controlling und IT.

Der Vorstand sollte eine 6-Mio.-€-Systemerneuerung freigeben, um Probleme zu lösen, die architektonisch waren, nicht technisch. Die Plattform trug die Schuld für Entscheidungen, die schlicht nie getroffen worden waren.

Was wir verändert haben

Wir haben — vom Vorstand freigegeben — ein Finance-Architekturprogramm auf der bestehenden Plattform vorgeschlagen. Drei Workstreams, sechs Monate, Festpreis-Assessment plus phasierte Lieferung.

Workstream A — Finance-Design

  • Konzern-Konten-Wörterbuch, 380 Konten, 1:1 zur Konsolidierung gemappt.
  • Multibook aktiviert: Local GAAP + IFRS als parallele Ledger, eine Quelle.
  • Steuerarchitektur je Jurisdiktion neu entworfen, klare Local-vs-Group-Regeln.
  • Konsolidierungslogik vom Spreadsheet in die native ERP-Konsolidierung verlagert.

Workstream B — Intercompany

  • Zentrale IC-Clearing-Einheit eingeführt.
  • Automatisierte Gegenbuchungen für AR/AP, IC-Rechnungen, Recharges.
  • Dokumentierte IC-Policy: Wer führt, wer folgt, wie Streitigkeiten geklärt werden.

Workstream C — Governance und Operations

  • Finance-eigener Release-Kalender, monatliche Kadenz, Change Advisory Board.
  • Drei der vier Reconciliation-Tools abgeschaltet. Das vierte — für Treasury — wurde behalten und sauber integriert.
  • BPO-Support für zwei kleinere Gesellschaften aufgesetzt — entlastet lokale Controller für höherwertige Arbeit.

Das Ergebnis nach sechs Monaten

  • Monatsabschluss: 22 Tage → 8 Tage. Konzernkonsolidierung wieder im Reporting-Zyklus.
  • IC-Differenz zum Monatsende: 2–4 Mio. € → unter 100 k €, fast vollständig timing-getrieben.
  • Audit-Findings zu Multibook und Steuerrückstellungen geschlossen.
  • Drei Reconciliation-Tools außer Betrieb genommen; das verbleibende sauber integriert.
  • Programmkosten insgesamt: deutlich unterhalb der 6-Mio.-€-Neuimplementierung — und die Plattform ist geblieben.

Engagement-Prinzip

Wenn ein Finance-Close kaputt ist, ist die Plattform selten das Richtige zum Ersetzen. Ersetzen Sie die Architektur darüber. Die Plattform — fast immer — überlebt.

Warum das über dieses Engagement hinaus relevant ist

Das Muster wiederholt sich. Eine mehrgesellschaftliche Gruppe, vier bis sechs Jahre nach ERP-Go-Live, mit zunehmend kaputtem Close, umgeben von Vendor-Angeboten zur Neuimplementierung. In einem nennenswerten Anteil dieser Situationen ist das ERP in Ordnung. Die Finance-Architektur wurde nie zu Ende gebaut. Eine Neuimplementierung produziert dasselbe Problem auf einem anderen System — zwei Jahre später.

In der Gruppe ist das die Art von Arbeit, die OPCON und BPO tragen — Execution und Finance-Operations, eingesteckt in das jeweilige ERP des Kunden. Die plattformspezifische Tiefe liegt in den Business Units (NetSuite, Microsoft, SAP, Zoho, Xentral). Die Diagnose bleibt auf jeder Plattform dieselbe: Architektur zuerst.