ESG-Reporting in SAP: Datenmodell, Governance und Audit

Regulatorischer Druck und technische Konsequenzen

ESG-Berichterstattung umfasst die Offenlegung von Kennzahlen und qualitativen Aussagen zu Umwelt, Sozialem und der Unternehmensführung. In der Praxis dominiert der Datenanteil, da Prüfbarkeit und Vergleichbarkeit nur über strukturierte Datenobjekte funktionieren.

Die Sammlung an Regelwerken, Frameworks und Vorgaben ist dabei ziemlich breit gefächert: CSRD fordert standardisierte digitale Daten im Lagebericht. ESRS spezifiziert Inhalte, Granularitäten und Zusammenhänge, die Unternehmen in konsistente Kennzahlenketten übersetzen müssen. Eine EU-Taxonomie ergänzt Anforderungen an Zuordnung, Klassifikation und Begründungslogik, die ohne ein formales Datenmodell nicht stabil bleibt.

Globale Rahmenwerke erhöhen die Komplexität. Das International Sustainability Standards Board (ISSB) fokussiert mit den beiden Nachhaltigkeitsstandards IFRS S1 und IFRS S2 investorenorientierte Offenlegung und Risikoexposition. Das Sustainability Accounting Standards Board (SASB) übersetzt branchenspezifische Prozesse in messbare Indikatoren. Die Global Reporting Initiative (GRI) deckt ein breites Spektrum gesellschaftlicher Auswirkungen ab. Die US-amerikanische Börsenaufsicht Securities and Exchange Commission (SEC) hat wiederum Regeln zu klimabezogenen Informationen, die in US-Kontexten zusätzliche Datenanforderungen mitbringen.

Diese Vielfalt an Rahmenwerken und Vorgaben erzwingt eine Architektur, die mehrere Berichtssichten aus identischen Grunddaten ableitet und die Semantik jeder Kennzahl dokumentiert.

Abgrenzung von Nachhaltigkeit und Corporate Social Responsibility (CSR)

Nachhaltigkeit fokussiert Umweltaspekte und Ressourceneinsatz. Corporate Social Responsibility (CSR), also die soziale Verantwortung, enthält Programme und Selbstverpflichtungen, die häufig als Text, Policies oder Initiativen auftreten. ESG-Reporting verlangt hingegen eine formale Mess- und Offenlegungsstruktur.

Das Datenmodell muss daher drei Ebenen unterscheiden: Eine Ebene enthält primäre Fakten aus operativen Prozessen und Messsystemen. Eine zweite Ebene führt diese Fakten über Regeln in Kennzahlen über. Eine dritte Ebene liefert veröffentlichungsreife Strukturen für Lagebericht und interne Steuerung. CSR-Inhalte können in diesem Modell ebenfalls auftauchen, aber erst die Modellierung als strukturierte Kennzahl oder als kontrolliertes Attribut macht den Inhalt prüffähig.

Fachliches Vorprojekt als Modellierungsgrundlage

Ein ESG-Programm beginnt mit einem fachlichen Vorprojekt, das Stakeholder, Berichtspflichten und Zielbilder zusammenführt. Die Wesentlichkeitsanalyse legt Themen, Grenzen und Prioritäten fest. Im EU-Kontext führt dieser Schritt in der Regel zu CSRD und ESRS als verbindlichem Kern. Viele Organisationen ergänzen interne Zielsysteme, integrieren ESG in Unternehmensplanung oder verlangen höhere Granularität für die Steuerung.

Das Vorprojekt liefert damit die Parameter für das technische Modell. Es definiert Berichtseinheiten, Konsolidierungskreise, Standortlogik, Datenverantwortlichkeiten und Freigabeprozesse. Es entscheidet außerdem, ob Kennzahlen aus Messwerten, aus operativen Belegen oder aus externen Datensätzen stammen. Ein ESG-Datenmodell ohne diese Entscheidungen zerfällt in inkonsistente Ableitungen, da jede Fachdomäne andere Grenzen und Definitionsräume setzt.

Warum eine direkte Umsetzung in SAP S/4HANA scheitert

SAP S/4HANA enthält viele relevante Belege, darunter Einkaufs- und Logistikdaten, Anlagenstammdaten, Kostenstelleninformationen, Buchungen im Controlling, Lieferanteninformationen und Prozessereignisse. ESG-Reporting benötigt jedoch regelmäßig zusätzliche Quellen. Energiedaten kommen oft aus Zählern, Gebäudeleittechnikanlagen oder Energiemanagementsystemen. Reisedaten kommen aus Concur oder Drittanwendungen. HR-Daten kommen aus SuccessFactors oder anderen HCM-Systemen. Lieferantennachweise kommen aus Plattformen, Zertifikatsdatenbanken oder Dokumentenmanagementsystemen. Emissionsfaktoren kommen aus externen Katalogen, Branchenmodellen oder nationalen Referenzdaten. Eine Rückintegration dieser Daten in das ERP-System widerspricht dem Prinzip Keep the core clean, weil es den operativen Kern mit Reporting-spezifischen Datenstrukturen und Historienlast belastet.

ESG benötigt zudem komplexe Modellierung und Berechnungen. CDS-Views in S/4HANA liefern ein virtuelles Modell, stoßen aber bei umfangreichen Berechnungen, Mehrdimensionalität und Massendaten an Laufzeit- und Wartungsgrenzen. ESG verlangt an vielen Stellen Persistenz, um Zeitstände zu fixieren und Prüfpfade zu sichern. Außerdem fehlt im operativen ERP eine auf lange Berichtszeiträume ausgelegte Historisierung, weil Archivierung und Betriebs-Performance andere Ziele verfolgen. Kapazitätsfragen verstärken das Problem. Teams, die SAP S/4HANA betreiben, priorisieren Betriebsstabilität, Release-Zyklen und Tagesgeschäft. Eine vollständige ESG-Plattform im ERP bindet diese Kapazitäten zusätzlich und verschiebt Risiko in den Kernbetrieb.

Strukturierte ESG-Datenmodelle als technische Pflicht

Ein ESG-Datenmodell beginnt mit einem semantischen Kern, der Fakten, Dimensionen und Regeln strikt trennt. Fakten sind messbare Ereignisse. Dazu zählen Energiemengen, Brennstoffverbräuche, Abfallmengen, Wasserentnahmen, Transportleistungen, Geschäftsreisen, Lieferantenattribute, Arbeitssicherheitsereignisse, Schulungsumfänge, Governance-Kennzahlen zu Gremien, Vergütung und Compliance-Vorfällen.

Jede Faktentabelle benötigt einen eindeutigen Zeitbezug. ESG kennt nicht nur ein Buchungsdatum, sondern auch Leistungszeitraum und Gültigkeitszeitpunkt der Berechnung. Ohne diese Trennung lassen sich Korrekturen, Nachmeldungen und Revisionsstände nicht nachvollziehen. Jede Faktentabelle benötigt außerdem einen Organisationsbezug. In SAP-Landschaften dominieren Rechtseinheit, Buchungskreis, Kostenstelle, Profitcenter, Werk, Standort und Projekt. ESG fordert zusätzlich Berichtsgrenzen, die nicht immer identisch zur Finanzkonsolidierung laufen. Das Modell braucht daher explizite Berichtsgrenzen, die eine rechtliche Sicht, eine operative Sicht und eine ESG-spezifische Konsolidierungssicht abbilden.

Dimensionsmodelle als Stabilitätsanker

Dimensionsmodelle sichern Konsistenz über Quellen hinweg. Organisationsdimensionen halten Hierarchien, Konsolidierungskreise und Zuordnungen, die sich im Zeitverlauf ändern. Produkt- und Materialdimensionen verbinden Einkaufs- und Produktionsbelege mit Klassifikationen, die für Taxonomie oder ESG-Themenzuordnung relevant sind.

Lieferantendimensionen führen Identitäten aus SAP und externen Registern zusammen und speichern Attribute zu Zertifikaten, Risikoindikatoren und Due-Diligence-Status. Standortdimensionen verbinden Werke, Gebäude, Regionen und Energieverbrauchsstellen. Zeitdimensionen bilden Kalender, Geschäftsjahre, Berichtsperioden und Stichtage ab. Eine Faktorendimension hält Emissionsfaktoren, Umrechnungsregeln und Quellenverweise mit Versionsführung.

Regelwerke und Berechnungsketten

ESG-Daten entstehen selten aus der einfachen Berechnung aller Kennzahlen, sondern umfassen Zuordnung, Umrechnung, Klassifikation und Aggregation:

• Zuordnung verbindet operative Belege mit Scope-Konzepten und Organisationshierarchien.
• Umrechnung wandelt Mengen in Energieeinheiten oder Emissionsäquivalente über Faktoren um, die eine Gültigkeit besitzen und im Zeitverlauf wechseln.
• Klassifikation ordnet Kennzahlen ESRS-Strukturen zu und verbindet sie mit Taxonomiekriterien oder internen Zielsystemen.
• Aggregation verdichtet Daten über Zeit und Organisation und bildet konsistente Summen über Hierarchien.

Diese Kette benötigt Versionierung. Jede Änderung an Faktoren, Grenzdefinitionen oder Zuordnungsregeln muss eine neue Regelversion erzeugen, damit ein bereits geprüfter Bericht reproduzierbar bleibt. Der technische Entwurf verlangt daher eine Regelverwaltung mit Freigabeprozess, Protokollierung und aktiver Version.

Datenherkunft und Auditpfade

Eine auditfähige ESG-Plattform dokumentiert Datenherkunft und Transformation. Data Lineage beginnt an der Quelle und endet in der veröffentlichten Kennzahl. Für SAP-Quellen müssen Extraktionswege nachvollziehbar bleiben. Für Nicht-SAP-Quellen müssen Schnittstellen, Importprozesse und Validierungen protokolliert sein. Auditpfade benötigen technische Protokolle, die Datenimporte, Regelanwendung, Berechnungsjobs und Berichtsfestschreibungen erfassen.

Zusätzlich braucht das System ein Rollenmodell. Rollen trennen Datenerfassung, Datenfreigabe, Regelpflege, Berichtsfestschreibung und Veröffentlichung. Ohne diese Trennung entsteht ein Prüfproblem, da dieselbe Person Daten ändern und freigeben kann. Eine ESG-Plattform muss außerdem Abweichungen erklären können. Das verlangt Drilldown-Pfade von der Kennzahl auf Aggregationsebene bis zum einzelnen Faktendatensatz mit Ursprungssystem, Belegreferenz und angewandter Faktorversion.

Historisierung und Stichtagslogik

ESG verlangt Zeitreihen und Rückblicke. Unternehmen analysieren Emissionen, Wasserverbräuche oder Unfallkennzahlen über Jahre und müssen Veränderungen erklären. Archivierung oder Stammdatenänderungen dürfen historische Werte nicht unkontrolliert beeinflussen. Das Datenmodell braucht daher Historisierung auf zwei Ebenen:

1. Es muss Faktendaten in einer Form halten, die sich über Berichtsperioden reproduzieren lässt.
2. Es muss Stammdaten und Hierarchien als zeitabhängige Strukturen führen.

Eine Kostenstelle, ein Standort oder eine Lieferantenbeziehung kann sich ändern. Berichte müssen diese Änderungen entweder mit zeitbezogener Gültigkeit abbilden oder über Snapshots fixieren. Eine ESG-Plattform muss außerdem Berichtsläufe festschreiben. Diese Festschreibung erzeugt einen definierten Stand für Prüfung und Veröffentlichung. Nachträgliche Korrekturen müssen als neue Version laufen, damit Altdaten nicht unkontrolliert überschrieben werden.

Anforderungen an Datenqualität

Datenqualität entscheidet über die Verwertbarkeit des Reportings. ESG-Datenqualität umfasst Vollständigkeit, Konsistenz, Plausibilität und Semantik:

• Vollständigkeit prüft, ob alle relevanten Quellen für einen Zeitraum Daten liefern.
• Konsistenz prüft, ob Summen über Hierarchien stimmen und ob Zuordnungen zu Organisationseinheiten gültig bleiben.
• Plausibilität prüft Ausreißer in Energieverbräuchen, Transportdistanzen oder Faktormultiplikationen.
• Semantik prüft, ob Einheiten, Periodenlogik und Scope-Zuordnung korrekt sind. Diese Prüfungen gehören in automatisierte Validierungsregeln im Datenfluss.

Eine ESG-Plattform braucht zudem ein Issue-Management, das Qualitätsabweichungen als Vorgänge mit Verantwortlichen, Fristen und Korrekturpfaden führt.

SAP-Architekturbausteine für das ESG-Datenmodell

Drei Architekturpfade dominieren in SAP-Umgebungen. Eine individuelle Entwicklung auf SAP-Analytics-Basis nutzt SAP Datasphere oder SAP Business Warehouse (BW) als Data-Warehouse-Schicht und SAP Analytics Cloud als Frontend. Spezialisierte SAP-Tools nutzen Sustainability Control Tower, Sustainable Footprint Management und Environment, Health and Safety (EHS) Management, kombiniert nach Bedarf. Drittanbieter-Tools bauen eine separate ESG-Plattform, die über Schnittstellen mit SAP integriert.

Datasphere oder Business Warehouse übernehmen Data-Warehouse-Aufgaben, darunter Persistenz, Historisierung, Berechtigungen, Prozesssteuerung und Modellierung. SAP Analytics Cloud liefert Visualisierungen und kann in vielen Organisationen Planung und Reporting zusammenführen, sofern bereits eine entsprechende Landschaft existiert. Der zentrale Vorteil liegt in der Anpassbarkeit. Das Modell kann ESRS-Strukturen, interne Ziele und Konzernlogiken abbilden, ohne auf Produktgrenzen Rücksicht zu nehmen. SAP-spezifische Funktionen lassen sich tiefer nutzen. Hierarchien, Währungsumrechnung und Mengenumrechnung integrieren sich in das Modell, ohne dass externe Tools die Logik nachbauen müssen. Diese Architektur passt auch dann, wenn ESG-Daten in bestehende Steuerungsberichte und Planungsprozesse einfließen sollen, da die Integration im selben Analytics-Stack liegt.

Der Aufwand steigt jedoch. Die Plattform braucht Quellanbindung, Harmonisierung, Dimensionsmodell, Regelverwaltung, Historisierung, Berechtigungen, Validierungsregeln und Berichtsausgaben. Projektlaufzeiten steigen, da die Organisation fachliche Logik und technische Basis parallel etablieren muss. Kosten steigen durch Entwicklung, Test, Governance-Design und spätere Wartung. Betrieb verlangt Know-how für Datenmodellierung, Datenintegration, Jobsteuerung, Release-Tests und Auditunterstützung. Nicht-SAP-Integration funktioniert, erfordert aber häufig zusätzliche Arbeit für Mapping, Stammdatenharmonisierung und Qualitätssicherung.

Spezialisierte SAP-Tools

SAP-Tools bringen vorgefertigte Funktionen für ESG und decken gängige Standards ab, darunter CSRD und ESRS. Sustainability Control Tower unterstützt die Steuerung, Kennzahlentransparenz und Szenarioarbeit. Sustainable Footprint Management fokussiert Fußabdrucklogik und kann Faktoren und Zuordnungen strukturiert führen. Environment Health and Safety Management deckt EHS-nahe Datenräume ab und bindet damit operative Sicherheitsthemen ein. Der modulare Ansatz erlaubt eine bedarfsgerechte Lizenzierung, da nicht jedes Unternehmen alle Bausteine benötigt. Ein weiterer Vorteil liegt in der Produktpflege. Änderungen an Rahmenwerken fließen in die Tool-Weiterentwicklung ein, was die interne Anpassungslast reduziert.

Grenzen zeigen sich in Produktreife und Funktionsumfang, insbesondere im Vergleich zu Plattformen, die über viele Jahre als ESG-Suiten wachsen. Die Flexibilität ist geringer als bei Eigenentwicklung, da Produktlogik bestimmte Modellierungswege vorgibt. Die Integration von Drittquellen bildet einen zusätzlichen Aufwand, sofern wesentliche ESG-Daten außerhalb des SAP-Systems entstehen. Schulung und Betrieb benötigen neue Rollen, da diese Tools eine eigene Domäne in der Landschaft bilden.

Drittanbieter-Tools und Integration in die SAP-Landschaft

Drittanbieter-Tools liefern oft reife Funktionsbreite und beschleunigen die Implementierung. Standardprozesse, Datenmodelle und Berichtsvorlagen existieren in solchen Umfeldern in der Regel. Eine Strategie zur Reduzierung von SAP-Abhängigkeit lässt sich damit ebenfalls umsetzen, sofern die Organisation ESG als eigenständige Plattformstrategie definiert.

Der Integrationsaufwand steigt aber. SAP-Daten müssen über Extraktion und Mapping in die Plattform, und Ergebnisse müssen häufig zurück in SAP-nahe Reporting- oder Planungsprozesse, sofern dort die Unternehmenssteuerung liegt. SAP-Hierarchien, Währungslogik und Mengenumrechnung fehlen oft als native Funktionen und erfordern Nachbau oder vorgelagerte Transformation in einer Data-Warehouse-Schicht. Anbieterabhängigkeit verschiebt sich vom SAP-Portfolio auf den gewählten Anbieter. Betrieb und Schulung bleiben erforderlich, da eine zusätzliche Plattformdomäne mit Rollen, Monitoring, Release-Management und Governance entsteht.

Handlungsempfehlungen für die SAP-Landschaft

Ein effektives ESG-Reporting in SAP beginnt mit dem Datenmodell und den Kontrollmechaniken. Ein fachliches Vorprojekt muss Wesentlichkeitsanalyse, Berichtsgrenzen und Kennzahlensemantik fixieren. Die Architektur muss SAP S/4HANA als operativen Kern akzeptieren und Reporting-spezifische Persistenz in eine dafür geeignete Schicht verlagern. Das Zielmodell muss Fakten, Dimensionen und Regeln trennen, Historisierung und Stichtagslogik abbilden und Auditpfade lückenlos führen.

Die Tool-Auswahl muss sich an Datenstrategie, Quelllandschaft und Kompetenzen orientieren. Eigenentwicklung auf SAP Datasphere, SAP BW und SAP Analytics Cloud liefert maximale Anpassbarkeit, verlangt aber hohes internes Know-how und Budget für den Betrieb. Spezialisierte SAP-Tools verkürzen Projektlaufzeiten und binden Standards eng ein, bringen aber Grenzen in Flexibilität und Nicht-SAP-Anbindung.

Drittanbieter-Tools liefern Funktionsbreite und teils hohe Reife, erhöhen jedoch Integrationsaufwand und verschieben Abhängigkeiten. Ein Pilotprojekt reduziert Risiko, wenn es Datenqualität, Historisierung, Regelversionierung, Berechtigungen und Lastverhalten prüft und einen vollständigen Drilldown bis zum Quellbeleg demonstriert. Interner Kompetenzaufbau bleibt in jedem Szenario zwingend, fachlich für ESRS-Interpretation und technisch für Datenmodellierung, Integration, Betrieb und Auditvorbereitung.