Wer im Betrieb regelmäßig mit Sicherheitsdatenblättern aus verschiedenen Quellen arbeitet, kennt das Problem: Jeder Lieferant liefert sein SDS in einem anderen Format, einem anderen Layout, mit unterschiedlicher Tiefe der Angaben. Das Ergebnis ist manueller Aufwand beim Einpflegen, Prüfen und Weiterverarbeiten. Das eSDScom XML Format adressiert genau diesen Punkt – es definiert eine gemeinsame Sprache für SDS-Daten. Dieser Artikel erklärt, was das Format leistet, wo es seine Stärken hat und wo in der Praxis Hürden entstehen.
Was das eSDScom XML Format ist und woher es stammt
eSDScom steht für „electronic Safety Data Sheet communication" und bezeichnet einen offenen Branchenstandard für den strukturierten, maschinenlesbaren Austausch von Sicherheitsdatenblatt-Daten im XML-Format. Das Format wurde maßgeblich von einem Konsortium aus Chemieverbänden und Softwareunternehmen entwickelt, unter anderem unter Beteiligung des Verbands der Chemischen Industrie (VCI) und vergleichbarer europäischer Organisationen. Die offizielle Spezifikation und weitere Informationen sind auf eSDScom.com verfügbar.
Der Kerngedanke: Statt ein SDS als PDF zu erstellen und zu versenden – also als Dokument, das ein Mensch liest, aber ein System kaum automatisiert auswerten kann – wird das SDS in eine strukturierte XML-Datei überführt. Jeder Abschnitt, jede Angabe, jede H- und P-Phrase, jede Konzentration wird in einem definierten Datenfeld abgelegt. Das schafft Voraussetzungen für automatisierte Importprozesse, Systemintegrationen und datengestützte Auswertungen.
Das Format hat mehrere Versionsstände durchlaufen. Aktuell relevanter Referenzstand für neue Implementierungen ist eSDScom 4.0; ältere Installationen arbeiten teilweise noch mit Version 3.0. Das Format basiert auf dem international genutzten SDS-Standard nach REACH und bildet die 16-Abschnitte-Struktur inhaltlich ab. Damit ist es kein Ersatz für das SDS selbst, sondern eine strukturierte Repräsentation desselben.
Wie die 16-Abschnitte-Struktur im XML abgebildet wird
Ein Sicherheitsdatenblatt besteht nach REACH aus 16 Pflichtabschnitten, von der Identifikation des Stoffs über Angaben zur Toxikologie bis zu Transport und Entsorgung. Das eSDScom XML Format übersetzt diese Abschnitte in eine hierarchische Datenstruktur mit klar benannten Feldern und Wertelisten.
Das bedeutet konkret: Wo ein PDF-SDS in Abschnitt 2 die Gefahreneinstufung als Fließtext enthält, findet sich im XML-Dokument ein strukturiertes Feld mit GHS-Piktogramm-Codes, Signalwörtern, H-Sätzen und P-Sätzen als separate, maschinenlesbare Einträge. Statt zu lesen „Entzündbare Flüssigkeit, Kategorie 2, H225", liefert das XML: Gefahrenklasse = „Flam. Liq. 2", H-Satz = „H225", jeweils als eigenständiger Datensatz.
Für die Weiterverarbeitung ist das ein erheblicher Unterschied. Ein System, das XML-Importe verarbeitet, kann diese Angaben direkt in ein Gefahrstoffverzeichnis übernehmen, automatisch auf bekannte KMR-Einstufungen prüfen oder mit Lagerklassen abgleichen – ohne manuelle Eingabe. Das PDF bleibt als Lesedokument relevant, aber die operative Datenbasis stammt aus dem strukturierten XML.
Wo das Format seine größten Stärken entfaltet
Der praktische Nutzen des eSDScom Formats zeigt sich vor allem in drei Szenarien:
Automatisierter SDS-Import in Verwaltungssysteme
Unternehmen, die Sicherheitsdatenblätter in einem digitalen System verwalten, profitieren am deutlichsten. Statt ein neues SDS manuell einzupflegen – Produktname übertragen, Einstufung abtippen, H-Sätze heraussuchen – kann ein System eine XML-Datei einlesen und die Felder automatisch befüllen. Das reduziert nicht nur den Aufwand, sondern eliminiert auch typische Übertragungsfehler, die beim manuellen Abtippen aus PDF-Dokumenten entstehen.
Ein typisches Szenario: Ein Chemielieferant stellt neben dem PDF auch eine eSDScom XML-Datei bereit. Das empfangende Unternehmen importiert diese Datei in sein System, das daraufhin Produktname, CAS-Nummer, Einstufungsdaten und Schutzmaßnahmen direkt übernimmt. Was sonst 15–20 Minuten manueller Arbeit bedeutet, ist in Sekunden erledigt.
Versionsverfolgung und Änderungserkennung
XML-Daten lassen sich systematisch vergleichen. Wenn ein Lieferant eine aktualisierte Version eines SDS liefert, kann ein System mit XML-Import die Unterschiede zwischen alter und neuer Version feldgenau ermitteln – welcher H-Satz wurde hinzugefügt, welcher Grenzwert hat sich verändert, welche Einstufung ist neu. Das macht den Versionsvergleich von Sicherheitsdatenblättern erheblich strukturierter als den manuellen Vergleich zweier PDF-Dokumente Seite für Seite.
Systemintegration und Weiterverarbeitung
Strukturierte Daten aus eSDScom lassen sich in nachgelagerte Prozesse einbinden: Gefahrstoffverzeichnis, Betriebsanweisungen, Gefährdungsbeurteilung, ERP-Systeme. Wer zum Beispiel beim Wareneingang neue Chemikalien erfasst, kann XML-Daten direkt in das Gefahrstoffkataster übernehmen, ohne parallele Dateneingabe in mehreren Systemen.
Typische Herausforderungen bei der Einführung
Das Format löst echte Probleme – aber seine Einführung ist kein Selbstläufer. In der Praxis entstehen an mehreren Stellen Hürden, die unterschätzt werden.
Nicht alle Lieferanten stellen XML bereit
Die Verbreitung von eSDScom XML ist in der Chemieindustrie gewachsen, aber noch nicht flächendeckend. Gerade kleinere oder spezialisierte Lieferanten liefern ihr SDS ausschließlich als PDF. Wer eSDScom als Eingangsprozess plant, muss damit rechnen, dass ein erheblicher Teil der Lieferanten diesen Kanal nicht bedient – und weiterhin auf manuelle Eingabe oder PDF-Extraktion angewiesen bleibt. Das bedeutet: XML-Import und PDF-Verarbeitung müssen parallel beherrscht werden.
Qualität der XML-Dateien variiert
Ein XML-Dokument ist nur so gut wie die Daten, die darin stecken. In der Praxis zeigt sich, dass eSDScom XML-Dateien nicht immer vollständig oder fehlerfrei befüllt sind. Pflichtfelder können leer sein, Kodierungen inkonsistent, oder Versionsangaben fehlen. Wer XML-Dateien ungeprüft importiert, kann Fehler in sein System übernehmen – ähnlich wie beim unkritischen Übernehmen von PDF-Inhalten. Eine Validierungsroutine beim Import ist daher keine Kür, sondern Pflicht.
Technische Integration erfordert Ressourcen
eSDScom XML ist kein Plug-and-Play. Die Integration in ein bestehendes System – ob ERP, Gefahrstoffsoftware oder eigene Datenbank – erfordert technische Entwicklungsarbeit oder eine Softwarelösung, die diesen Import bereits unterstützt. Für viele mittelständische Unternehmen ohne dedizierte IT-Kapazitäten ist das eine reale Hürde. Die Frage ist nicht nur, ob das Format sinnvoll ist, sondern ob die interne Infrastruktur bereit ist, es zu nutzen.
Formatversionen und Kompatibilität
eSDScom hat verschiedene Versionsstände. Ältere XML-Dateien entsprechen möglicherweise nicht der aktuellen Schemadefinition. Systeme, die nur eine bestimmte Version unterstützen, können mit älteren oder neueren Dateien Probleme haben. Das klingt technisch – ist aber ein operatives Problem, sobald ein Import fehlschlägt und unklar ist, warum.
Was Unternehmen vor der Einführung klären sollten
Bevor ein Betrieb auf eSDScom XML setzt, lohnt es sich, einige Punkte strukturiert zu prüfen. Die folgende Liste ist keine Checkliste im Sinne einer Vollständigkeitsgarantie, sondern eine Orientierung für die Bewertung der eigenen Ausgangssituation:
- Lieferantenabdeckung prüfen: Welcher Anteil der aktuellen SDS-Lieferanten stellt bereits XML-Dateien bereit? Wenn weniger als ein Drittel das tut, bleibt der manuelle Pfad dominant und der Mehrwert begrenzt.
- Zielsystem definieren: In welches System sollen die XML-Daten importiert werden? Unterstützt dieses System eSDScom XML nativ oder braucht es eine Schnittstelle?
- Validierungslogik planen: Wie wird sichergestellt, dass importierte XML-Daten vollständig und korrekt sind, bevor sie produktiv genutzt werden?
- Parallelprozesse einplanen: PDF-basierte SDS werden nicht verschwinden. Welcher Prozess gilt für Lieferanten, die kein XML bereitstellen?
- Versionsstände abstimmen: Welche eSDScom-Version unterstützt das Zielsystem? Gibt es Lieferanten, die eine abweichende Version liefern?
- Zuständigkeiten klären: Wer ist verantwortlich für den XML-Import-Prozess, die Fehlerbehandlung und die Qualitätssicherung der importierten Daten?
- Pilotphase einplanen: Vor dem Rollout auf alle Lieferanten empfiehlt sich ein kontrollierter Pilotbetrieb mit zwei bis drei XML-Lieferanten, um Importfehler und Prozesslücken frühzeitig zu erkennen.
- Rückfalloption definieren: Was passiert, wenn ein XML-Import fehlschlägt? Gibt es einen definierten Fallback-Prozess?
eSDScom XML und die Rolle von SDS-Verwaltungstools
Für Unternehmen, die eSDScom XML nutzen möchten, ohne eigene Integrationsprojekte zu stemmen, ist die entscheidende Frage: Welche Softwarelösung beherrscht diesen Import und verarbeitet die Daten sinnvoll weiter? Gerade im Mittelstand ist ein schlankes, spezialisiertes Tool oft sinnvoller als ein vollumfängliches EHS-System, das viele Funktionen mitbringt, die im Betrieb nicht gebraucht werden.
SDS Engine ist auf die Verwaltung von Sicherheitsdatenblättern ausgerichtet und unterstützt strukturierte Datenverarbeitung, ohne den organisatorischen Aufwand eines großen EHS-Projekts zu erzeugen. Das ist besonders relevant für Betriebe, die eSDScom XML als Eingangsprozess nutzen wollen, aber keine dedizierten IT-Ressourcen für individuelle Schnittstellenentwicklung haben.
Wichtig bleibt dabei: Kein Tool ersetzt die inhaltliche Prüfung. Ob ein importiertes SDS korrekt und vollständig ist, ob Einstufungen aktuell sind, ob Betriebsanweisungen angepasst werden müssen – das sind Entscheidungen, die fachkundige Personen treffen. XML-Import beschleunigt den Datenpfad, nicht die fachliche Bewertung.
Einordnung: Wann lohnt sich der Aufwand wirklich?
eSDScom XML ist kein universell sinnvoller Standard für jeden Betrieb. Der Nutzen hängt direkt davon ab, wie viele SDS regelmäßig verarbeitet werden und wie viele Lieferanten das Format bereits unterstützen. Für einen Betrieb mit 15 Produkten von vier Lieferanten, die kein XML liefern, ist der Einführungsaufwand unverhältnismäßig. Für ein Unternehmen mit 200 oder mehr aktiven SDS aus einer größeren Zahl von Lieferanten, von denen ein relevanter Teil XML bereitstellt, kann eSDScom den manuellen Aufwand deutlich reduzieren und die Datenqualität verbessern.
Der entscheidende Schritt ist eine realistische Bestandsaufnahme: Wie viele SDS werden jährlich neu eingebunden oder aktualisiert? Wie viele Lieferanten könnten XML liefern? Welche Folgeprozesse – Gefahrstoffverzeichnis, Gefährdungsbeurteilung, Betriebsanweisungen – würden von strukturierten Daten profitieren? Die Antworten darauf bestimmen, ob eSDScom XML ein sinnvoller nächster Schritt ist oder ob andere Maßnahmen im SDS-Prozess zuerst Priorität haben sollten.