Referenzdaten

Referenzdaten sind die strukturgebenden Codelisten, Klassifikationen und Kennzahlensysteme, mit denen ein Unternehmen Materialien, Lieferanten, Konditionen und Buchungsobjekte einheitlich beschreibt. Sie sind keine transaktionalen Daten und keine reinen Stammdaten, sondern bilden den Bezugsrahmen, gegen den Stammdaten und Belege validiert werden.

Detaillierte Erklärung

Referenzdaten unterscheiden sich von Stammdaten durch ihre Stabilität und übergeordnete Funktion. Materialstammdaten beschreiben ein konkretes Produkt; Referenzdaten beschreiben die Kategorien, Einheiten und Codes, mit denen man Produkte überhaupt erst beschreiben kann. Typische Beispiele sind eCl@ss-Klassen, UNSPSC-Codes, Mengeneinheiten nach ISO 80000, Währungscodes nach ISO 4217, Länderschlüssel ISO 3166, Zahlungsbedingungen, Steuerschlüssel und Kontenrahmen.

Im DACH-Raum spielen besonders die Sachkonten-Referenzrahmen SKR03 und SKR04 von Datev eine zentrale Rolle. Sie definieren, welche Buchungen auf welche Konten gehen — und damit, wie der Einkauf Kontierungen für Bestellungen und Rechnungen wählt. Ohne korrekte Verknüpfung zwischen Materialgruppe und Sachkontenfindung gibt es keinen sauberen Three-Way-Match und keine korrekte Kostenstellenzuordnung.

Nach ISO 8000-110 gehört Referenzdatenqualität zu den vier Grunddimensionen Genauigkeit, Vollständigkeit, Konsistenz und Aktualität. Schwach gepflegte Referenzdaten erzeugen einen Multiplikatoreffekt: ein einziger fehlerhafter Mengeneinheitscode (z. B. STK statt PAA für Paar) verfälscht potenziell tausende Bewegungsdaten. Deshalb sind Referenzdaten klassischer Gegenstand zentraler Pflege durch Stammdatenmanagement-Verantwortliche.

Konkret im Einkaufskontext gibt es vier Referenzdaten-Cluster: erstens Klassifikationen wie eCl@ss (in der DACH-Industrie marktführend, von BMW, Siemens, Bosch genutzt) und Materialgruppenstrukturen; zweitens Lieferanten-Identifier wie D-U-N-S-Number und Bankidentifikatoren wie BIC/SWIFT; drittens technisch-buchhalterische Listen wie Zahlungsbedingungen, Incoterms-Codes und Steuerschlüssel; viertens organisatorische Referenzen wie Kostenstellen, Werkscodes und Lagerorte.

Plattformen wie SAP S/4HANA pflegen Referenzdaten in Customizing-Tabellen, die nur durch Administratoren änderbar sind und deren Änderungen Transportwege durch Test- und Produktivsystem durchlaufen. Coupa und JAGGAER ASN bieten dafür eigene Reference-Data-Module, die per API mit Drittsystemen wie eCl@ss-Klassifikationsservern oder Datev-Kontenrahmen synchronisiert werden.

EuGH-Rechtsprechung (insbesondere in der Linie nach Lex EuGH C-260/91 zu Codelisten und harmonisierter Beschreibung) bestätigt: einheitliche Klassifikation ist Voraussetzung für Vergleichbarkeit, und Vergleichbarkeit ist Voraussetzung für faire Auftragsvergabe. Referenzdaten sind damit nicht nur internes Werkzeug, sondern haben rechtliche Außenwirkung.

Praxisbeispiel (konkretes Einkaufsszenario)

Ein Hersteller medizintechnischer Geräte mit 1.150 Mitarbeitern in Heidelberg führt eine konzernweite eCl@ss-Klassifikation ein. Bisher wurden Materialien in 14 internen Materialgruppen geführt, die historisch gewachsen, teils überlappend und nicht maschinenlesbar mit Lieferantenkatalogen abgleichbar waren. Ziel: jede aktive Materialnummer erhält eine eCl@ss-Klasse auf der vierten Hierarchieebene, die Lieferantenstammdaten werden mit D-U-N-S-Number angereichert, und die Sachkontenfindung wird auf SKR04 umgestellt.

Schritt eins: Aufbau einer Referenzdaten-Governance. Eine Stammdatenpflege-Stelle wird Ankerpunkt für alle Codelisten-Änderungen. Die Klassifizierungsquote (Anteil Materialien mit korrekter eCl@ss-Klasse) wird als KPI im Einkaufscontrolling verankert.

Schritt zwei: Mapping. Über drei Monate werden 8.400 aktive Materialnummern auf eCl@ss gemappt — teils manuell, teils per regelbasiertem Mapping. Die Trefferquote im automatischen Schritt liegt bei 71 Prozent, die übrigen 29 Prozent gehen in eine Klärungsschleife mit Konstruktion und Einkauf.

Schritt drei: Verknüpfung mit Sachkontenfindung. Die Kontierungslogik wird so eingestellt, dass eine eCl@ss-Klasse über die Materialgruppe das richtige SKR04-Sachkonto zieht. Beispiel: eCl@ss-Klasse 23-30-04-08 (Wälzlager) führt auf Konto 5400 Roh-, Hilfs- und Betriebsstoffe; eCl@ss-Klasse 27-30-90-90 (Hilfsstoff Schmierfett) führt auf Konto 6020 Reinigungs- und Pflegematerial.

Ergebnis nach neun Monaten: Klassifizierungsquote bei 96,5 Prozent, Reduktion manueller Kontierungen um 78 Prozent, sauberer ABC- und XYZ-Datenanalyse erstmals möglich, weil vergleichbare Klassifikation existiert.

Typische Fehler & Verhandlungskontext

Der häufigste Fehler ist die fehlende Trennung zwischen Stamm- und Referenzdaten. Wenn jeder Materialdisponent eigene Materialgruppen anlegen darf, vermehren sich Codelisten unkontrolliert — und die Vergleichbarkeit über Werke oder Sparten hinweg geht verloren. Referenzdatenpflege gehört in eine zentrale Hand, ob nun Stammdaten-Team oder dedizierte Master-Data-Governance.

Zweitens scheitern viele Klassifikationsprojekte an unrealistischen Tiefenanforderungen. eCl@ss hat acht Hierarchieebenen — eine Klassifikation auf Ebene 8 ist für die meisten Mittelständler nicht wirtschaftlich pflegbar. Die Empfehlung: Pflichtfeld auf Ebene 4, Ebene 5 und tiefer optional bei strategischen Materialgruppen. So bleiben Aufwand und Nutzen im Gleichgewicht.

Drittens unterschätzen Einkaufsorganisationen die Aktualisierungspflicht. eCl@ss-Versionen wechseln alle 18–24 Monate, Datev-Kontenrahmen werden jährlich aktualisiert, Steuerschlüssel ändern sich bei Gesetzesänderungen. Wer Referenzdaten als einmaliges Setup betrachtet, hat nach drei Jahren einen Reform-Stau, der mehr kostet als kontinuierliche Pflege.

Im Verhandlungskontext sind Referenzdaten ein unterschätzter Hebel. Wer mit einem Lieferanten dieselbe eCl@ss-Klassifikation und denselben D-U-N-S-Identifier teilt, kann Kataloge, Preisvergleiche und Spend-Analysen automatisieren. Das senkt die Transaktionskosten und erhöht die Verhandlungstransparenz. Lieferanten, die nicht klassifizieren können oder wollen, signalisieren oft eine schwache eigene Datenbasis — was bei der Lieferantenbewertung relevant ist.

Ein vierter Fehler liegt in der unklaren Rollenverteilung zwischen Einkauf, Buchhaltung und IT bei Referenzdatenänderungen. Wenn die Buchhaltung den Kontenrahmen jährlich aktualisiert, ohne den Einkauf einzubinden, brechen Sachkontenfindungen ab. Eine gemeinsame Master-Data-Governance-Runde mit Vertretern aller Bereiche, die Referenzdaten ändert oder konsumiert, vermeidet diese Reibungen und stellt die ISO-8000-Datenqualitätsdimensionen dauerhaft sicher.

Fünfter Fehler ist das Fehlen einer Mapping-Tabelle bei Klassifikationswechseln. Wer von einer hausinternen Materialgruppensystematik auf eCl@ss umstellt, braucht eine vollständige 1:n-Zuordnung und ein Stichdatum, ab dem nur noch die neue Klassifikation gilt. Ohne Mapping bleiben historische Bewegungsdaten weiterhin in der alten Logik, neue in der neuen — Reports werden inkonsistent. Sechster Fehler: Referenzdatenänderungen werden ohne Wirkungsanalyse durchgezogen. Wer eine Mengeneinheit umbenennt oder ein Sachkonto stilllegt, ohne zu prüfen, welche Materialstämme, Bestellungen und offenen Belege darauf verweisen, erzeugt Folgefehler in dutzenden Geschäftsprozessen. Best Practice ist ein Impact-Report vor jeder Änderung, der die Anzahl betroffener Datensätze pro betroffenem Modul zeigt — und ein Migrationsplan mit Stichdatum, Übergangsphase und Cleanup. Reife Stammdatenorganisationen führen Referenzdatenänderungen quartalsweise mit Release-Charakter durch, vergleichbar mit Software-Releases, mit klarer Kommunikation an alle Konsumenten.

Verwandte Begriffe

• [[stammdatenmanagement-mdm]]
• [[eclass]]
• [[klassifizierungsquote]]
• [[d-u-n-s-number]]
• [[bic-swift]]