Governance in ESG/Sustainability — Kennzahlen, Bezugs- und Detailebene und Nachweis

Was diese Landschaft besonders macht

ESG-Daten verbinden Messwerte, Schätzungen und Informationen externer Lieferanten. Die gleiche Aktivität kann je nach Systemgrenze, Faktorversion und Berichtsperiode anders bewertet werden. Ein plausibles Diagramm erklärt noch nicht, welche Werte gemessen und welche abgeleitet wurden.

• Organisatorische Grenze, Einheit und Faktorversion explizit halten.
• Geschätzte Daten von gemessenen Werten unterscheidbar machen.
• Korrektur und erneute Veröffentlichung einer Periode nachvollziehen.

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:

• ESG-Metric-Definition-Contracts — Scope, Faktoren, Versionen
• ESG Source Evidence und Assurance — Gemessen vs. geschätzt
• ESG Vendor- und Supply-Chain-Daten — Contracts und Quality Gates
• ESG Reporting-Kontrollen für Berichtsperioden — Close, Restatement, Gates

Einstieg

ESG-Governance beginnt nicht mit einem Reporting-Tool. Sie beginnt mit der Frage, welche Kennzahl für welche Grenze, Aktivität, Faktorversion und Nachweisqualität berichtet werden darf.

Wenn du nur fünf Minuten hast

1. Starte mit einer Kennzahl, einem Scope, einer Aktivität oder einem Lieferantennachweis.
2. Kläre fachliche Einheit: Entity, Site, Periode, Aktivität und Grenze.
3. Führe Ermittlungsmethode (gemessen, geschätzt oder berechnet) und Korrekturstatus getrennt. Auch ein berechneter Wert kann später restated sein; dies sind keine gegenseitig ausschließenden Kategorien.
4. Versioniere Faktoren, Quellen, Annahmen und geschlossene Perioden.
5. Binde Scope-3- und Lieferantendaten an Procurement-Identifier und Evidence-Status.

Begriffe vor dem Lesen

• Umfang 1 / 2 / 3 — direkte Emissionen, Energiebezug und Wertschöpfungskette. Still gemischte Scopes ohne Flag sind kein Produkt.
• Faktorversion — referenzierter Emissions- oder Umrechnungsfaktor mit Quellen-ID und Stichtag — nicht „der aktuelle Faktor“ in einer überschreibbaren Zelle.
• Activity-fachliche Zählebene — Entity, Site, Periode und Aktivitätseinheit, bevor eine Intensität berechnet wird.
• Gemessen vs. geschätzt — Pflichtflag am Wert. Mischung ohne Kennzeichnung zerstört Assurance.
• Dienstleister-Nachweis — Lieferantennachweis (Methode, Periode, Status, Review) für Umfang-3- und vorgelagerte Daten — kein Posteingangs-PDF.
• Restatement — versionierte Korrektur einer geschlossenen Periode. Überschreiben der aktuellen Zeile ist kein Restatement.
• Operational Kontrollregel vs. Equity Partnerfreigabe — Grenze-Regel, welche Entity und welches Site in die Kennzahl fallen. Mapping zur Finance-Entity wo nötig.

Die Beispiele sind Lehrfälle (keine Kundendaten). Ersetzt Entity-, Site-, Faktor- und Toolnamen durch eure Catalog-, ERP-, IoT- und Prozessquellen.

Fachlicher Zusammenhang: Verantwortung klärt, wer die Aussage entscheidet; Kennzahlen-Governance beschreibt ihre Bedeutung; Datenqualität prüft die benötigte Datengrundlage. Das Governance-Konzept verbindet diese Aufgaben zu einem gemeinsamen Arbeitsweg.

Orientierung — ESG-Kennzahl ohne das Reporting-Tool zu übernehmen

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

Produkte und Entscheidungen

ESG braucht nicht „eine Nachhaltigkeitsdatenbank“, sondern geschnittene Produkte.

Produkt für Kennzahlendefinitionen

Dieses Produkt beschreibt:

• Kennzahl-ID; Zweck und Nutzer; Einheit; Activity-fachliche Zählebene (Entity, Site, Periode, Aktivität); Umfang- und Grenze-Vereinbarung (inkl. Operational Kontrollregel vs. Equity Partnerfreigabe); Faktor- oder Umrechnungsreferenz mit Quellen-ID und Version; Breaking-Change-Regel.

Entscheidungen:

• Welche Grenze gilt für diese Kennzahl?; Wer darf Umfang, Einheit oder Faktorversion schließen?; Wann ist ein Faktorwechsel eine neue Metric-Version statt einer stillen Zelle?

Source-Evidence- und Assurance-Produkt

Evidence ist kein Screenshot-Ordner. Assurance braucht Quelle, Methode und Retention.

Es benötigt:

• Quellen-ID; gemessen vs. geschätzt; Erhebungszeitpunkt; zuständige Stelle; Aufbewahrungsfrist; Lieferstatus gegenüber dem Assurance-Pack.

Entscheidungen:

• Welche Quelle ist für Umfang 1/2 führend (Zähler, ERP, IoT)?; Wann darf geschätzt werden — und mit welchem Ablauf?; Wer nimmt ein Nachweis-Pack als vollständig an?

Lieferkette-Produkt

Scope 3 und vorgelagerte Daten sind kein optionaler Anhang. Sie brauchen denselben Identifier wie Procurement.

Entscheidungen:

• Welche Lieferanten-ID und welche Periode gelten?; Welches Nachweis-Minimum (Methode, Status, Review) blockiert den Close?; Wer eskaliert Lücken — Sustainability oder Category Manager?

Kontrollen für Berichtsperioden-Produkt

Der Period Close ist kein Export der aktuellen Mappe. Er ist ein versionierter Entscheidungsstand.

Entscheidungen:

• Wann ist die Periode geschlossen?; Welche verspätete Dienstleister-Datei darf noch rein?; Wer genehmigt ein Restatement — und welche Vorversion bleibt lesbar?

Wo Governance hängt

Zwischen Wiki-Formel und Metric-Version

Eine Formel im Intranet ohne Bezugs- und Detailebene, Scope und Faktorversion ist nicht berichtsfähig. Der Name der Kennzahl bleibt gleich, der Inhalt nicht.

Zwischen Faktorzelle und Stichtag

Überschreiben von „dem aktuellen Faktor“ zerstört YoY und Assurance. Der Stichtag braucht eine referenzierte Faktorversion.

Zwischen gemessen und geschätzt

Ohne Flag sieht der Report eine Messung. Assurance findet eine Hochrechnung. Beide Werte dürfen existieren — nicht unter einem Label.

Zwischen Vendor-Spreadsheet und Procurement-Identifier

Scope-3-Zahlen ohne Lieferanten-ID, Klauselperiode und Evidence-Status sind Schattenwahrheit. Finance und Einkauf können sie nicht prüfen.

Zwischen ESG-Close und Finance-Close

Energie im Ledger und Intensität im ESG-Tool können verschiedene Entity-Mappings und Periodenenden nutzen. Ohne Handoff entstehen zwei Abschlüsse.

Zwischen ERP/IoT-Admin und fachlicher Auslegung

Wer den Feed schalten kann, darf nicht entscheiden, was in Scope 3 dieser Periode liegt.

Rollen-Mapping

Data Owner (Sustainability / ESG Controller)

Der Sustainability- oder ESG-Controller ist accountable für Zweck der Kennzahl, Scope-Grenze, akzeptable Schätzungen und Freigabe des Assurance-Packs. Der Owner entscheidet nicht die ERP-Modellierung.

Finance-Close-Owner

Accountable für Periodenende, Entity-Mapping zur Finance-Wahrheit und dafür, welche ESG-Zahl den Close berührt. ESG-Semantik bleibt beim Sustainability-Owner; die Periode darf nicht still von einem Tool-Admin verschoben werden.

Data Steward

ESG Operations oder ein benannter Domain-Steward triagiert Faktor- und Evidence-Lücken, überwacht gemessen/geschätzt-Flags, führt die Vendor-Nachforderung und eskaliert Restatement-Konflikte.

Data Product Owner

Priorisiert Metric-Releases, Evidence-Index, Vendor-Gates und Perioden-Snapshots. Nutzen und Lieferbarkeit — nicht die Scope-Auslegung.

Data Architect

Schützt Entity-/Site-Bezugs- und Detailebene, Lineage Aktivität → Faktor → Intensität, Historie von Faktorversion und Restatement, Mapping zur Finance-Entity und Breaking Changes an Disclosure-Schnittstellen.

Data Custodian

ERP-, IoT- und Vendor-Portal-Betrieb setzen Feeds, Rechte, Retention und Close-Gates um. Konfigurationsmacht ist keine Kennzahlenhoheit.

Data Nutzer

Disclosure, Internal Audit / Assurance, Finance, Procurement, Leadership, Rating-Koordination. Abweichungen laufen über denselben Intake — keine stillen Intensitäts-Spreadsheets.

Procurement für Lieferantennachweis

Category Manager oder Vendor-Risk liefert und fordert Lieferantennachweise ein. Sie ersetzen nicht den ESG-Owner für Scope und Methode.

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.

Mini-Fall

Alltagssituation: Der Vorstandsbericht zeigt eine Kennzahl für eingekaufte Energie. Später fragt die Prüfung nach dem Stand aus Q2, aber die alte Version ist nicht mehr verfügbar. In der aktuellen Datei wurde ein Emissionsfaktor überschrieben, und Lieferantenzahlen mischen gemessene mit geschätzten Werten.

Was schiefläuft: Niemand kann sauber erklären, ob die Zahl je Standort, Monat, Produkt oder Aktivität gilt. Ein neues ESG-Tool hilft erst, wenn Kennzahl, Faktorversion, Datenquelle und Korrekturpfad fachlich vereinbart sind.

Vereinbarung: Jede ESG-Kennzahl bekommt ID, Standort, Zeitraum, Aktivität, Berichtsgrenze und Faktorversion zum Stichtag. Quellen zeigen, ob Werte gemessen oder geschätzt sind. Alte Perioden bleiben lesbar, und Korrekturen werden als genehmigte Neubewertung dokumentiert.

Kritische Übergaben

Anti-Patterns

• Catalog-Tags als Audit-Nachweis
• Intensität ohne Activity-fachliche Zählebene veröffentlichen
• Technischen Betrieb und fachliche Verantwortung in einer unklaren Rolle vermischen
• Geschätzte und gemessene Werte ohne Flag mischen
• Restatement still in der aktuellen Version überschreiben
• Umfang 1/2/3 unter einem Score ohne Namespace
• Dienstleister-PDFs im Posteingang ohne Lieferanten-ID und Review-Datum

Erster Umsetzungsschnitt

Wähle einen begrenzten betrieblichen Fall, an dem sich die beschriebene Entscheidung und ihre Umsetzung gemeinsam prüfen lassen.

• Arbeitsplan — Extended Domain Landscapes
• Lernpfad — Extended Domain Landscapes
• Functions Hub — ESG & Sustainability

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

Schritt 1: Rahmen und Entscheidung klären

Drei externe oder board-relevante Kennzahlen wählen. Bezugs- und Detailebene, Scope-Grenze, Methode, Faktorversion und Owner dokumentieren. Gemessen vs. geschätzt für eine Scope-2-Metrik kennzeichnen. ERP/IoT-Admin nur als Custodian mappen.

Schritt 2: Control und Nachweis umsetzen

Einen Kennzahlenvereinbarung und ein Source-Nachweispaket produktiv führen. Faktorversion zum Stichtag referenzieren — kein Überschreiben der aktuellen Zelle. Eine Lieferantennachweis-Lücke mit Procurement priorisieren.

Schritt 3: Testen und Ausnahmen sichtbar machen

Period-Close-Gate und einen Restatement-Pfad mit Finance-Close-Owner durchspielen. Negativtest: Report ohne Metric-Version oder ohne gemessen/geschätzt-Flag muss fehlschlagen. Assurance-Anforderungen schriftlich.

Schritt 4: Messen und begrenzt ausrollen

Aufwand und Lücken messen. Nur bestandene Muster (Bezugs- und Detailebene, Faktorversion, Evidence-Flag, Close-Gate) auf eine zweite Entity oder eine Scope-3-Warengruppe übertragen.

Exit-Kriterien

• Jede materielle Kennzahl hat fachliche Zählebene, Umfang, Faktorversion und verantwortliche Person.
• Source-Nachweis unterscheidet gemessen und geschätzt und hat Retention.
• Dienstleister-Chain-Zahlen hängen an einer Lieferanten-ID und einem Nachweis-Status.
• Period Close und Restatement sind getrennte, versionierte Entscheidungen.
• technischer Betreiber liefert Feed- und Prüfpunkt-Nachweis ohne mündliche Brücke.

Weiterlesen

• Governance in der Finance-Landschaft
• Governance im Procurement
• KPI-Definition, Verantwortung und Versionierung
• Audit Nachweis Operating
• Governance über Funktionen hinweg
• Rollen-Hub

In der Serie weiterlesen

• ESG-Metric-Definition-Contracts — Scope, Faktoren, Versionen