Governance in Finance — Abschluss, Kennzahlen und Kontrollen belastbar verbinden

Was diese Landschaft besonders macht

Finance unterscheidet gebuchte Vorgänge, Managementsicht und Planung. Periodenabschluss, Währungsbezug und spätere Korrekturen verändern den Vergleich. Eine CRM-Prognose und ein gebuchter Umsatz können beide richtig sein, ohne dieselbe Zahl darzustellen.

• Abschlussstände und spätere Korrekturen getrennt rekonstruieren.
• Konten-, Organisations- und Währungszuordnungen versionieren.
• Forecast und Ist über eine erklärte Überleitung vergleichen.

Welche Werkzeuge zu welcher Aufgabe passen

Ausgangspunkt sind die Aufgabe und die vorhandenen Systeme. Die Beispiele zeigen geeignete Einsatzgebiete; vor einer Auswahl müssen Datenzugriff, Funktionsumfang und laufender Betriebsaufwand im eigenen Bestand geprüft werden.

Die folgenden Kapitel vertiefen die einzelnen Grenzen und Problemfelder:

• Close- und Perioden-Contracts — Gebuchte Wahrheit betreibbar machen
• Management-Accounting vs. Ledger — Zwei Wahrheiten, ein Contract
• Forecast- und Budget-Übergabe — Sales-Wahrheit trifft Finance-Close
• Close-Evidence und Korrekturpfade — Nachweis statt Status ohne Belege

Einstieg

Finance hat bereits Regeln, Freigaben und Kontrollen. Trotzdem ist Data Governance dort nicht automatisch gelöst.

Der Monatsabschluss kann sauber geführt sein, während BI-Kennzahlen aus anderen Logiken entstehen. Ein Forecast kann für Steuerung wichtig sein, ist aber kein gebuchter Umsatz. Eine Management-Sicht kann dem Vorstand helfen, ist aber nicht automatisch die rechtliche Wahrheit. Ein Dashboard kann freigegeben sein, ohne dass Herkunft, Periode und Korrekturweg später prüfbar sind.

Finance-Governance verbindet deshalb Zahlen mit Verantwortung, Zeitraum, Quelle, Zweck, Zugriff, Änderung und Nachweis.

Wenn du nur fünf Minuten hast

1. Frage zuerst, welche Finance-Zahl für welche Entscheidung genutzt wird.
2. Trenne Ledger, Management-Sicht, Forecast und Budget sichtbar.
3. Mache Periode, Entity, Währung, Quelle und Version direkt an der Kennzahl sichtbar.
4. Benenne getrennte Owner für Buchungslogik, Steuerungslogik und technische Umsetzung.
5. Erzeuge Nachweis für Abstimmung, Freigabe und Korrekturpfad, nicht nur ein grünes Dashboard.

Begriffe vor dem Lesen

• Ledger — Hauptbuch oder gebuchte Wahrheit: hier stehen Buchungen nach Entity, Konto, Periode, Währung und Beleg.
• Close — Periodenabschluss, zum Beispiel Monats- oder Quartalsabschluss.
• Periode — Buchungszeitraum, der offen, vorläufig geschlossen oder endgültig geschlossen sein kann.
• Management Accounting — Steuerungssicht für Kostenstellen, Profit Center, Produkte, Regionen oder Projekte.
• Forecast — Erwartung für zukünftige Entwicklung, oft aus Sales, Controlling oder Planung.
• Budget — genehmigter Planstand für einen Zeitraum.
• Reconciliation / Abstimmung — Prüfung, ob zwei Datenstände kontrolliert zusammenpassen.
• IKS — internes Kontrollsystem; Regeln und Nachweise für kontrollierte Erstellung, Änderung und Freigabe.

Warum Finance besonders ist

Finance-Zahlen beeinflussen Entscheidungen, Budgets, Bonuslogik, externe Berichte, Audit und manchmal regulatorische Pflichten. Darum reicht es nicht, dass eine Zahl plausibel aussieht. Sie muss für ihren Zweck belastbar sein.

Eine Zahl kann fachlich sinnvoll und trotzdem für den falschen Zweck ungeeignet sein. Beispiel: Ein Forecast hilft bei Kapazitätsplanung. Er darf aber nicht als gebuchter Umsatz in einem Abschlussbericht erscheinen.

Das Grundmuster

Finance-Governance trennt drei Wahrheiten und verbindet sie kontrolliert.

Ein nachvollziehbarer Fall

Zwei Teams berichten „Revenue“. Accounting zeigt den gebuchten Umsatz der geschlossenen Periode. Controlling zeigt eine Management-Sicht mit Abgrenzungen, Umbuchungen und Forecast-Anteilen. Sales zeigt Pipeline und Commit.

Alle drei Sichten können wichtig sein. Aber sie dürfen nicht im selben Dashboard als eine Zahl erscheinen, ohne klar zu sagen: Welche Periode? Welche Entity? Welche Währung? Gebucht, geplant oder erwartet? Welche Korrekturen? Wer hat freigegeben?

Das Problem ist nicht, dass Finance mehrere Zahlen hat. Das Problem entsteht, wenn unterschiedliche Zwecke unter demselben Label verschwinden.

Was diese Serie klärt

Diese Serie ist der Einstieg in Finance-Governance. Sie zeigt, wie Abschluss, Ledger, Management-Sicht, Forecast, Budget, Kontrollen und Nachweise zusammenpassen.

Die fünf Teile bauen aufeinander auf:

• Dieser Teil erklärt die Finance-Landschaft.
• Teil 2 klärt Close- und Perioden-Contracts.
• Teil 3 trennt Management Accounting und Ledger.
• Teil 4 regelt Forecast- und Budget-Übergaben.
• Teil 5 erklärt Close Evidence und Korrekturpfade.

Produkte und Entscheidungen

Ledger-Produkt

Das Ledger-Produkt beschreibt gebuchte Sachverhalte. Dazu gehören Entity, Konto, Beleg, Buchungsdatum, Periode, Währung, Betrag, Status und Herkunft.

Wichtige Entscheidung: Welche Buchung ist wirksam und welche Periode ist geschlossen?

Management-Accounting-Produkt

Diese Sicht verbindet Kostenstellen, Profit Center, Projekte, Produkte, Regionen und Allokationen. Sie hilft bei Steuerung, muss aber mit dem Ledger verbunden bleiben.

Wichtige Entscheidung: Welche Hierarchie und Allokationslogik gilt für welche Periode?

Forecast- und Budget-Produkt

Forecasts und Budgets sind Versionen eines Plan- oder Erwartungsstands. Sie brauchen Snapshot, Währung, Organisation, Verantwortliche und Abgrenzung zu gebuchten Zahlen.

Wichtige Entscheidung: Wofür darf dieser Stand verwendet werden: Planung, Steuerung, Liquidität oder Close-Erklärung?

Close- und Evidence-Produkt

Der Close braucht Aufgaben, Status, Abstimmungen, Freigaben, Snapshots und Korrekturpfade. Ein grüner Status ohne Nachweis ist schwach.

Wichtige Entscheidung: Ist die Abstimmung ausreichend und wer akzeptiert offene Abweichungen?

Finance-KPI-Produkt

Kennzahlen wie Marge, EBITDA, Working Capital oder Cash Conversion brauchen Zweck, Formel, Komponenten, Periode, Währung, Ausschlüsse, Version und Owner.

Wichtige Entscheidung: Welche Zahl ist für welche Entscheidung freigegeben?

Rollen in einfachen Worten

Accounting verantwortet Ledger, Close und Buchungslogik. Controlling verantwortet Management-Sicht, Planung, Forecast und Steuerungskennzahlen. Treasury, Tax oder Revenue Accounting verantworten ihre jeweiligen Finance-Datenprodukte. Finance Stewards pflegen Definitionen, Hierarchien, Mappings, Korrekturen und Nachweise. Data Architects sichern historische Versionen, Schlüssel, Währungen und Lineage. ERP-, EPM-, Warehouse- und BI-Teams betreiben Systeme und Zugriffe.

Wichtig: Ein technischer Admin entscheidet nicht allein, welche Zahl buchhalterisch oder steuerungsrelevant gilt.

Mini-Fall

Ein Dashboard zeigt Umsatz je Produktbereich. Die Zahl enthält gebuchte Umsätze, erwartete Deals und manuelle Management-Anpassungen. Der Titel lautet nur „Revenue“.

Im Monatsabschluss entsteht Streit: Accounting erkennt nur gebuchte Umsätze an. Controlling braucht die Management-Sicht. Sales möchte den Forecast erklären.

Die saubere Lösung: Die Anzeige trennt Actual, Forecast und Management Adjustment. Die Periode hat Status und Snapshot. Die Management-Sicht hat eine eigene Version. Korrekturen verweisen auf den ursprünglichen Beleg oder die ursprüngliche Kennzahl.

Erster Umsetzungsschnitt

1. Eine kritische Finance-Kennzahl auswählen.
2. Klären, ob sie Ledger, Management-Sicht, Forecast oder Budget ist.
3. Periode, Entity, Währung und Quelle sichtbar machen.
4. Owner für Ledger-Logik und Management-Logik getrennt benennen.
5. Eine Abstimmung mit ID, Ergebnis und Nachweis anlegen.
6. Einen Korrekturpfad für Storno, Umbuchung oder KPI-Anpassung dokumentieren.
7. Das Dashboard-Label so ändern, dass der Zweck sichtbar ist.

Exit-Kriterien

• Ledger, Management-Sicht, Forecast und Budget sind getrennt benannt.
• Jede kritische Kennzahl hat Zweck, Formel, Periode, Währung, Owner und Version.
• Close-Status ist mit Abstimmung und Nachweis verbunden.
• Korrekturen verweisen auf Ursprung und Wirkung.
• Technische Systeme setzen Finance-Entscheidungen um, ersetzen sie aber nicht.

In der Serie weiterlesen

• Close- und Perioden-Contracts — Gebuchte Wahrheit betreibbar machen