Datenformat (CSV, XML, JSON)

CSV, XML und JSON: die drei wichtigsten Datenformate

Die drei im ERP-Alltag dominierenden Datenformate lösen unterschiedliche Aufgaben und lassen sich an ihrer Struktur unterscheiden. Welches das „richtige“ ist, hängt fast nie vom eigenen Geschmack ab, sondern davon, was das Zielsystem, ein Marktplatz oder ein gesetzlicher Standard verlangt.

Wie ein Datenformat funktioniert

Jedes Datenformat definiert drei Dinge: die Struktur (wie Felder und Datensätze angeordnet sind), die Syntax (welche Zeichen als Trennung, Klammerung oder Markierung dienen) und die Codierung (mit welchem Zeichensatz Buchstaben und Sonderzeichen abgelegt werden, im Regelfall UTF-8). Erst wenn Sender und Empfänger dieselben Annahmen über diese drei Ebenen teilen, gelingt der Austausch fehlerfrei.

Der Weg von einem System ins andere führt fast immer über einen Export und einen Import: Das Quellsystem schreibt seine internen Daten in ein vereinbartes Datenformat heraus, das Zielsystem liest diese Datei wieder ein. Weil die Feldnamen und die Struktur auf beiden Seiten selten identisch sind, gehört zu diesem Schritt ein Feld-Mapping – die Zuordnung, welches Feld der Quelle welchem Feld im Ziel entspricht. Bei laufenden Verbindungen übernimmt oft eine Middleware oder ein ETL-Prozess die Umwandlung von einem Format ins andere, sodass Systeme, die unterschiedliche Formate „sprechen“, trotzdem zusammenarbeiten.

Datenformate im ERP-System

Im ERP-System begegnet einem das Datenformat an fast jeder Schnittstelle. Beim Datenimport und -export von Stammdaten ist CSV der Klassiker: Neue Artikel, Preise oder Kunden werden als CSV-Datei eingespielt, Auswertungen als CSV herausgezogen. Sobald es an angebundene Systeme geht – Onlineshop, Marktplatz, Payment, Versand –, dominiert JSON, weil die zugehörigen REST-APIs Daten in diesem Format übertragen. XML wiederum trifft man dort, wo formelle Standards und Prüfbarkeit zählen: bei der E-Rechnung, in EDI-Umgebungen und bei behördlichen Schnittstellen.

Für die Praxis heißt das: Das Datenformat ist selten frei wählbar. Ein Marktplatz gibt sein Produktfeed-Format vor, das Finanzamt verlangt E-Rechnungen in einem bestimmten XML-Standard, eine API liefert und erwartet JSON. Ein gutes ERP-System unterstützt deshalb mehrere Formate und stellt Werkzeuge bereit, um zwischen ihnen zu übersetzen – über konfigurierbare Import-/Export-Profile, über Konnektoren zu Drittsystemen oder über eine angebundene Middleware. Fehlt diese Flexibilität, entsteht schnell manuelle Nacharbeit, weil Daten von Hand umformatiert werden müssen.

Abgrenzung: Datenformat vs. Schnittstelle und Standard

Ein Datenformat wird oft mit verwandten Begriffen verwechselt, ist aber klar davon zu trennen. Eine Schnittstelle bzw. API regelt den Transportweg und die Spielregeln der Kommunikation – wer wann was anfragen darf. Das Datenformat regelt dagegen nur, in welcher Form die übertragenen Daten notiert sind. Bildlich: Die Schnittstelle ist der Briefumschlag samt Zustellweg, das Datenformat die Sprache und Grammatik des Briefinhalts. Eine JSON-Antwort einer REST-API ist also beides zugleich – API als Transport, JSON als Format.

Ebenso zu unterscheiden ist das Datenformat vom fachlichen Standard, der es ausfüllt. XRechnung, ZUGFeRD oder EN 16931 sind keine Datenformate im engeren Sinn, sondern inhaltliche Regelwerke, die vorschreiben, welche Felder eine Rechnung enthalten muss – und die diese Vorgaben technisch meist in XML gießen. Das Format (XML) ist die Technik, der Standard die verbindliche Bedeutung darüber. Wer beides trennt, versteht schneller, warum eine Datei „technisch korrektes XML“ und trotzdem „keine gültige E-Rechnung“ sein kann.

DACH-Besonderheiten: Codierung, Trennzeichen und E-Rechnung

Im deutschsprachigen Raum sorgen zwei Kleinigkeiten regelmäßig für Ärger beim Datenaustausch. Erstens die Zeichencodierung: Umlaute (ä, ö, ü) und das ß werden nur dann korrekt übertragen, wenn Quelle und Ziel dieselbe Codierung – heute üblicherweise UTF-8 – verwenden; andernfalls entstehen die berüchtigten „Buchstabensalat“-Zeichen. Zweitens das Trennzeichen bei CSV: Weil im deutschen Zahlenformat das Komma als Dezimaltrennzeichen dient, nutzen viele Programme in der DACH-Region das Semikolon als Feldtrenner – wird das beim Import verwechselt, verrutschen ganze Spalten.

Rechtlich prägt vor allem die E-Rechnung das Thema Datenformat. Seit 2025 gilt in Deutschland die Pflicht, im B2B-Bereich strukturierte elektronische Rechnungen empfangen zu können; maßgeblich ist die europäische Norm EN 16931, die in Formaten wie XRechnung (reines XML) und ZUGFeRD (XML eingebettet in eine PDF-Datei) umgesetzt wird. Ein einfaches PDF oder ein Scan gilt ausdrücklich nicht als E-Rechnung, weil es kein maschinenlesbares Datenformat mitliefert. Für ERP-Systeme im DACH-Raum ist die saubere Beherrschung dieser XML-basierten Formate damit nicht optional, sondern gesetzliche Pflicht.