Governance in Finance — Abschluss, Kennzahlen und Kontrollen belastbar verbinden

Begriffe vor dem Lesen

• Governance — Gemeinsame Regeln, Rollen und Nachweise, damit Daten verantwortbar genutzt werden.
• verantwortliche Person — Fachlich verantwortliche Person oder Rolle, die Zweck, Bedeutung und Freigabe klärt.
• technischer Betreiber — Technische Rolle, die Plattform, Zugriff, Betrieb oder Umsetzung betreut.
• Nachweis — Prüfbarer Nachweis, der für Audit, Kontrolle, Aufsicht oder interne Freigabe verständlich bleibt.

Sizing: KMU — Close nah am Ledger, wenige kritische KPIs, klarer Monatsabschluss und prüfbare Korrekturen. Mid-Market — getrennte Steward-Kapazität für Ledger, Management Accounting, Forecast und BI-Kennzahlen. Enterprise — mehrere Legal Entities, Group-Mappings, IKS/SOX-nahe Kontrollen, Segregation of Duties, Audit-fähige Close Evidence und strengere Zugriffs- und Änderungsprozesse.

Finance besitzt bereits Regeln, Kontrollen und Freigaben. Trotzdem ist Data Governance dort nicht automatisch gelöst. Der Monatsabschluss kann kontrolliert sein, während Management-KPIs außerhalb des Ledgers entstehen. Cost-Center-Hierarchien können in ERP, Planung und BI auseinanderlaufen. Forecasts können für Steuerung sinnvoll sein, dürfen aber nicht still zur gebuchten Wahrheit werden. Reports können genehmigt sein, ohne dass ihre Datenherkunft reproduzierbar ist.

Die Anforderungen sind höher als in vielen anderen Fachbereichen, weil Finance-Zahlen Entscheidungen, externe Berichte, Budgetverantwortung, Bonuslogik, Audit und teilweise regulatorische Pflichten beeinflussen. Deshalb müssen Definition, Periode, Quelle, Berechtigung, Änderung, Korrektur und Nachweis zusammenpassen.

Governance muss deshalb drei Wahrheiten verbinden:

• die gebuchte Wahrheit; die steuerungsrelevante Management-Sicht; die technische Reproduzierbarkeit.

Finance Governance schützt nicht nur Zahlen. Sie schützt die Entscheidungen, Nachweise und Übergaben, durch die Zahlen verbindlich werden.

Die Serie Governance in der Finance-Landschaft gibt dir den Einstieg und den roten Faden für die folgenden Teile.

Ausgangslage

Zwei Controller schließen dieselbe Periode. Im Ledger ist der Umsatz gebucht; die Management-Sicht zählt Accruals, Umbuchungen und Sales Commit mit. Ein Dashboard zeigt beides als „Revenue“, ohne Periodenstatus, Legal Entity, Währung, Korrekturpfad und Sign-off sichtbar zu machen.

Das Problem ist nicht „Finance hat zu viele Zahlen“. Das Problem ist, dass gebuchte Wahrheit, Management-Sicht, Forecast und BI-KPI unterschiedliche Zwecke haben. Wenn diese Zwecke nicht getrennt und verbunden werden, kann eine Zahl fachlich plausibel und trotzdem für Abschluss, Audit oder Steuerung falsch sein.

Was diese Serie klärt

• Orientierung: Governance in Finance — Abschluss, Kennzahlen und Kontrollen belastbar verbinden
• Vertiefung: Close- und Perioden-Vereinbarungen — Gebuchte Wahrheit betreibbar machen
• Vertiefung: Management Accounting und Ledger sauber verbinden
• Vertiefung: Forecast und Budget als Handoff führen, nicht als stille Ledger-Erweiterung
• Abschluss mit betreibbaren Next Steps über Close-Nachweis und Korrekturpfade — Nachweis statt Status ohne Belege

Begriffe und Kürzel vor dem Lesen

• Close — verbindlicher Periodenabschluss mit Status, Abgleich und Nachweis — kein Dashboard-„grün“.
• Ledger — gebuchte Wahrheit je Entity und Periode — nicht die steuerungsrelevante Management-Sicht.
• Management-Sicht — steuernde Hierarchie und KPI mit Mapping aufs Ledger — kein Ersatz für den legalen Close.
• Periode — Buchungszeitraum mit Open/Soft-Close/Hard-Close — kein Kalendermonat allein.
• Close-Nachweis — nachweisbare Abgleich, Snapshot und Korrekturpfad — kein Statushäkchen.
• IKS / Internal Kontrollregeln — Kontrollen über Erstellung, Änderung, Freigabe und Nachweis von Finance-Daten; kein reines Audit-Dokument nach dem Abschluss.
• Segregation of Duties — Trennung kritischer Tätigkeiten, zum Beispiel Anlegen, Ändern, Freigeben und Buchen. Ein Admin-Recht ist keine fachliche Finance-Freigabe.

Lesepfad

1. Governance in Finance — Abschluss, Kennzahlen und Kontrollen belastbar verbinden
2. Close- und Perioden-Contracts — Gebuchte Wahrheit betreibbar machen
3. Management-Accounting vs. Ledger — Zwei Wahrheiten, ein Contract
4. Forecast- und Budget-Handoff — Sales-Wahrheit trifft Finance-Close
5. Close-Evidence und Korrekturpfade — Nachweis statt Status ohne Belege

Konzept halten — Last-Säulen: KPI und Verantwortung tragen diese Kette; Access ist Nachbar (Influence, kein Parallel-Rollout). These: Konzept · Haltung: gemeinsamer Standard · Tiefe: 8 Säulen.

Orientierung — Abschluss und Kennzahlen verbinden, ohne den ganzen Stack umzubauen

Download: PDF dieser Seite · Vertriebshub: Governance als Dienstleistung · Wen rufen: Delegation

Produkte und Entscheidungen

General-Ledger-Produkt

Das Ledger-Produkt repräsentiert gebuchte Sachverhalte.

Sein Contract umfasst:

• Company Code oder Legal Entity; Konto; Buchungsbeleg; Buchungsdatum; Periode; Währung; Betrag; Gegenkonto; Status; Herkunftssystem; Korrekturbeziehung.

Entscheidungen:

• Welche Buchung ist wirksam?; Welche Periode ist offen?; Wer darf korrigieren?; Welche Quelle ist für den Abschluss autoritativ?; Wie bleiben Storno und Neubuchung verbunden?

Management-Accounting-Produkt

Dieses Produkt verbindet:

• Cost Center; Profit Center; Projekt; Produkt; Kanal; Region; Allokationen; Plan und Forecast.

Entscheidungen:

• Welche Hierarchie gilt für welche Periode?; Welche Allokationslogik ist freigegeben?; Wie werden Reorganisationen historisiert?; Welche Management-Sicht darf vom Legal Reporting abweichen?

Revenue-Produkt

Finance Revenue beginnt nicht bei Closed Won.

Es braucht einen Vertrag für:

• Leistungsverpflichtung; Vertragswert; Billing; Recognition; Rabatte; Gutschriften; Währung; Periodisierung; Korrekturen.

Sales liefert kommerziellen Kontext. Finance entscheidet über die buchhalterische Behandlung.

Close- und Reconciliation-Produkt

Ein Close-Produkt macht den Prozess selbst messbar.

Es enthält:

• Close Task; verantwortliche Einheit; Fälligkeit; Evidenz; Freigabe; Ausnahme; Abgleich Status; Korrektur; Abschlusszeitpunkt.

Entscheidungen:

• Ist die Abstimmung ausreichend?; Darf ein Task geschlossen werden?; Welche Abweichung ist wesentlich?; Wer akzeptiert das Restrisiko?

Finance-KPI-Produkt

KPIs wie Marge, EBITDA, Working Capital oder Cash Conversion benötigen:

• Zweck; Formel; Komponenten; fachliche Ebene; Umfang; Währung; Kalender; Ausschlüsse; Version; verantwortliche Person; Change-Prozess.

Eine Formel allein reicht nicht.

Wo Governance hängt

Zwischen Subledger und General Ledger

Die Summen können stimmen, obwohl Zuordnungen falsch sind.

Ein Reconciliation Contract braucht:

• verglichene Grundgesamtheit; Schlüssel; Bewertungslogik; Toleranz; Zeitpunkt; Ausnahmebehandlung; Freigabe; Evidenz.

An Hierarchien

Cost Center und Profit Center verändern sich. Wenn nur der aktuelle Baum gespeichert wird, werden historische Reports umgeschrieben. Governance muss Effective Dates und Versionen verlangen.

An manuellen Journals

Manuelle Buchungen sind nicht grundsätzlich schlecht.

Sie benötigen stärkere Evidenz:

• Geschäftszweck; Ersteller; Prüfer; Betrag; Periode; Beleg; Bezug zur Korrektur;
• Freigabestatus.

Zwischen Excel und Plattform

Excel ist oft ein legitimes Arbeitsmittel. Das Risiko entsteht durch unkontrollierte Logik, lokale Referenzdaten und fehlende Versionierung. Nicht jede Datei gehört in den Katalog. Entscheidungsrelevante Modelle brauchen jedoch Owner, Version, Input-Contract und Review.

Zwischen Finance und Data Team

Finance versteht Bilanzierungs- und Steuerungslogik. Das Data Team versteht Transformation, Lineage und Betrieb. Governance hängt, wenn technische Ableitungen als fachliche Definition gelten. SQL dokumentiert Implementierung. Es ersetzt keine Finance-Entscheidung.

Zwischen lokaler und Gruppenwahrheit

Lokale Kontenpläne, Kalender und Währungen benötigen Mapping. Ein Gruppenreport darf lokale Unterschiede nicht verstecken.

Mapping-Regeln brauchen:

• Gültigkeitszeitraum;
• fachlichen verantwortliche Person;
• Freigabe;
• Version;
• Ausnahme;
• Rückverfolgbarkeit.

Rollen-Mapping

Data Owner

Der Finance Data Owner kann je Produkt variieren.

Beispiele:

• Controller für Management Accounting;
• Chief Accounting Officer für Ledger und Close;
• Treasury Lead für Cash;
• Tax Lead für Steuerdaten.

Der Owner entscheidet über:

• fachliche Bedeutung;
• autoritative Quelle;
• Materialität;
• Zugriff;
• Ausnahmen;
• Freigabe.

Data Steward

Finance Stewards können aus Controlling, Accounting Operations oder Finance Transformation kommen.

Sie:

• pflegen Konten- und KPI-Definitionen;
• koordinieren Hierarchieänderungen;
• triagieren Quality-Issues;
• sammeln Close-Evidenz;
• verfolgen Mapping-Ausnahmen;
• bereiten Entscheidung der verantwortlichen Personen vor.

Data Product Owner

Der Product Owner führt:

• Finance Data Auswertungstabelle;
• Close Analytics;
• Management Reporting;
• Planning-Produkt;
• Revenue- oder Cost-Produkte.

Er priorisiert Delivery und Lifecycle. Er entscheidet nicht allein über Bilanzierung oder Materialität.

Data Architect

Der Architect schützt:

• Journal- und Balance-fachliche Ebene;
• historisierte Hierarchien;
• Ledger-zu-Auswertungstabelle-Vereinbarungen;
• Währungs- und Kalendermodelle;
• Lineage;
• kontrollierte Änderungen.

Data Custodian

ERP-, EPM-, Warehouse- und BI-Teams tragen Custodianship.

Sie betreiben:

• Jobs;
• Berechtigungen;
• SoD-nahe technische Kontrollregeln;
• Backups;
• Perioden-Snapshots;
• Audit Logs;
• Recovery.

Custodian ist nicht fachlicher Owner eines Kontos.

Data Consumer

Consumer umfassen:

• Accounting;
• Controlling;
• Management;
• Treasury;
• Tax;
• Audit;
• Investor Relations;
• Operations.

Sie müssen Report-Gaps und Schattenlogik melden.

Hilfskarte — wen zuerst fragen

Das Rollen-Mapping sagt, wer entscheidet. Die Hilfskarte sagt, wen man zuerst fragt, damit die Entscheidung nicht leer ist. Hüte: Wer hilft wem an der Quelle.

Zum Owner nur bei Definitions- oder Risiko-Streit. Schema- und Join-Fragen bleiben bei Expert oder Custodian. Achtundvierzig Stunden Antwort — nicht stilles Slack.

SMB versus Enterprise

SMB

Ein SMB sollte Finance Governance nah am Close aufbauen.

Praktische Besetzung:

• CFO oder Head of Finance als verantwortliche Person;
• Controller als Steward und Nutzer Representative;
• Analytics Lead als Product Owner und Architect;
• ERP Admin oder IT Partner als technischer Betreiber.

Das Minimum:

• autoritatives Ledger benennen;
• Konten- und Cost-Center-Hierarchie versionieren;
• zehn kritische KPIs definieren;
• manuelle Journals kontrollieren;
• Abgleich-Evidenz ablegen;
• Zugriffe quartalsweise prüfen;
• einen Issue-Kanal betreiben.

Ein SMB braucht kein Finance Data Council für jede Änderung. Ein 30-minütiger monatlicher Entscheidungs-Slot kann genügen.

Enterprise

Ein Enterprise benötigt föderierte Finance Governance.

Typische Struktur:

• Group Finance-verantwortliche Person für Konzernprodukte;
• lokale Finance-verantwortliche Person für gesetzliche Sichten;
• Lead Stewards nach Accounting, Controlling und Treasury;
• Product Owner für zentrale Finance-Produkte;
• Group und Domain Architects;
• Custodians je ERP-, EPM- und Data-Service;
• Audit und Risk als konsultierte Kontrollfunktionen.

Zentrale Standards umfassen:

• Group Chart of Accounts;
• gemeinsame KPI-Verträge;
• Währungslogik;
• Kalender;
• Mapping-Prinzipien;
• Materialität;
• Evidenzanforderungen;
• Intercompany-Vereinbarungen.

Lokale Abweichungen brauchen explizite Gültigkeit.

Kritische Übergaben

Mini-Fall

Symptom: Drei Umsatzzahlen im Close-Meeting: Opportunity Amount, fakturierter Betrag, gebuchter Umsatz — unter einem Label.

Typischer Fehlstart: Ein weiteres Dashboard und eine Kennzahlenmodell-Lizenz, ohne Perioden-Vereinbarung.

Vereinbarung: Ein Close-Produkt mit verantwortliche Person, Stichtag, Korrekturpfad und Semantikgrenze zu Sales-Bookings.

Anti-Patterns

Abgestimmt bedeutet verstanden

Eine Reconciliation beweist Summengleichheit. Sie beweist nicht automatisch korrekte Klassifikation oder Bedeutung.

Aktuelle Hierarchie für historische Perioden

Damit verändert eine Reorganisation rückwirkend frühere Reports.

CFO als Owner jeder Finance-Tabelle

Der Titel ist zu weit vom operativen Entscheidungsobjekt entfernt. Delegierte Owner brauchen klare Grenzen.

Data Team definiert Finance-KPIs

Technische Umsetzung kann präzise und fachlich falsch sein.

Jede Excel-Datei verbieten

Das treibt Arbeit in Schattenprozesse. Kontrolliere kritische Modelle nach Risiko.

Audit als Owner einsetzen

Audit prüft unabhängig. Es sollte operative Accountability nicht übernehmen.

Controls ohne Ausnahmeweg

Ein Block ohne begründete Ausnahme erzeugt Umgehung.

Journal-Text als strukturierte Evidenz behandeln

Freitext ist hilfreich, aber nicht ausreichend für systematische Kontrolle.

Close-Schnelligkeit allein optimieren

Ein schneller Close ohne Reproduzierbarkeit verschiebt Arbeit in Korrekturen.

Kontroll-Design

Ein guter Control beantwortet:

• Welches Risiko wird reduziert?
• Auf welcher Grundgesamtheit arbeitet er?
• Wann läuft er?
• Wer bearbeitet Treffer?
• Wer akzeptiert Ausnahmen?
• Welche Evidenz bleibt?
• Wann wird seine Wirksamkeit geprüft?

Präventive Controls

• gültige Konten-Kombination;
• erlaubte Periode;
• Pflichtbeleg bei manuellem Journal;
• Vier-Augen-Freigabe;
• gültiges Hierarchie-Mapping;
• Zugriff nach Funktion.

Detektive Controls

• Subledger-GL-Abweichung;
• ungewöhnliche manuelle Buchung;
• verspätete Buchung;
• nicht gemappte Konten;
• sprunghafte KPI-Abweichung;
• verwaiste Cost Center;
• nachträgliche Report-Änderung.

Korrektive Controls

• dokumentierte Reclassification;
• Mapping-Korrektur;
• Restatement;
• Report-Neuveröffentlichung;
• Nutzer-Benachrichtigung;
• Ursachenanalyse.

Controls werden nach Risiko priorisiert. Mehr Controls sind nicht automatisch bessere Governance.

Mini-Scorecard

Bewerte jede Aussage mit 0, 1 oder 2 Punkten.

Produkte

• Ledger, Management Accounting und KPI-Produkte sind getrennt.
• fachliche Ebene, Perioden und Währung sind explizit.
• Hierarchien und Mappings sind versioniert.

Entscheidungen

• Materialität und Ausnahmen haben verantwortliche Person.
• Revenue-Übergaben sind vertraglich beschrieben.
• KPI-Änderungen besitzen Freigabe.

Rollen

• Finance und Technik teilen klare Grenzen.
• Stewardship hat geschützte Zeit.
• Audit bleibt unabhängig.

Nachweise

• Reconciliations sind reproduzierbar.
• manuelle Journals besitzen Evidenz.
• Report-Versionen bleiben nachvollziehbar.

0–7 Punkte: kontrollierte Einzelschritte ohne Daten-Operating-Model.

8–16 Punkte: belastbare Close-Basis mit Produktlücken.

17–24 Punkte: durchgängige Finance Data Governance.

Erster Umsetzungsschnitt

Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Finance Landscape
• Lernpfad — Finance Landscape
• Functions Hub — Finance

Lege Woche 1 als ersten Slice in den Plan. Spätere Wochen bleiben in derselben Instanz. Erster Kontakt für Hüte: Wer hilft wem an der Quelle.

Woche-1-Schnitt

Nicht drei Finance-Entscheidungen. Period-Grain und eine Close-Zahl.

Erste Entscheidung im Fachbereich · Tool

Woche 1

• drei kritische Finance-Entscheidungen wählen;
• zugehörige Produkte und Reports inventarisieren;
• Definition, fachliche Ebene, Periode und Quelle vergleichen.

Woche 2

• Owner und Steward je Produkt benennen;
• Product-, Architecture- und technischer Betreiber-Hüte mappen;
• fünf kritische Übergaben dokumentieren.

Woche 3

• KPI- und Abgleich-Vereinbarungen testen;
• Hierarchieversionen prüfen;
• manuelle Korrekturen auf Evidenz untersuchen.

Woche 4

• einen Close-Ausschnitt end-to-end verfolgen;
• Wartezeiten und manuelle Brücken messen;
• zwei unnötige Kontrollregeln entfernen;
• drei wirksame Kontrollregeln automatisieren oder stärken.

Weiterlesen

• KPI- und Metric-Governance
• KPI-Definition, Verantwortung und Versionierung
• RACI für Data Governance
• Functions Hub — Finance
• Rollen-Hub