Daten transformieren vor dem Import: Feldnamen, Typen und Formate automatisch anpassen

Ein Lieferant schickt seine Artikelliste. Die Spalte heißt “Preis”, nicht “price”. Das Datum steht als “15.03.2026” drin, das ERP erwartet “2026-03-15”. Der Preis ist “12,50” mit Komma, die Datenbank will einen Punkt. Und das Feld “Aktiv” enthält “ja” statt true.

Bevor diese Daten ins System können, muss jemand sie umbauen. In der Praxis passiert das in Excel: Spalten umbenennen, Suchen-und-Ersetzen für Kommas, Datumsformat per Formel umrechnen. Das funktioniert, solange es einmal im Quartal vorkommt. Bei wöchentlichen oder täglichen Imports wird es zum Zeitfresser.

Warum Transformation ein eigener Schritt sein sollte

Im vorherigen Beitrag ging es um Datenvalidierung: Sind die Daten vollständig und korrekt? Aber selbst valide Daten können im falschen Format vorliegen. Die Artikelnummer ist vorhanden und korrekt, aber die Spalte heißt “Artikelnr” statt “article_number”. Der Preis ist eine gültige Zahl, aber mit Komma als Dezimaltrennzeichen.

Validierung prüft ob die Daten stimmen. Transformation bringt sie in die richtige Form.

In der Praxis sind das zwei getrennte Schritte, die oft vermischt werden. Das führt zu Problemen:

Transformation in Excel ist nicht wiederholbar. Jedes Mal manuell Spalten umbenennen und Formate anpassen ist fehleranfällig. Beim dritten Import vergisst jemand eine Spalte.

Transformation im Zielsystem ist riskant. Manche ERP-Systeme bieten Import-Mappings an. Aber wenn die Typkonvertierung schiefgeht, landen falsche Werte in der Produktivdatenbank. Besser: vorher transformieren, prüfen, dann importieren.

Transformation ohne Dokumentation ist unsichtbar. Wenn ein Kollege die Excel-Datei vorbereitet, weiß niemand genau, was er verändert hat. War “12,50” vorher “12.50” oder “1250”?

Die typischen Transformations-Probleme

Feldnamen

Jedes System hat seine eigene Namenskonvention. Der Lieferant schickt “Bezeichnung”, das ERP erwartet “description”. Der Webshop exportiert “Kundenname”, das CRM will “customer_name”. Bei jedem neuen Datenlieferanten beginnt das Mapping von vorn.

Dezimaltrennzeichen

In Deutschland und der Schweiz ist das Komma das Dezimaltrennzeichen: “12,50”. In den meisten Datenbanken und APIs ist es der Punkt: “12.50”. Wird das nicht konvertiert, interpretiert das System “12,50” entweder als String (und kann nicht rechnen) oder als 1250 (und der Preis ist hundertfach zu hoch).

Datumsformate

“15.03.2026” ist für einen Menschen eindeutig. Für eine Datenbank nicht. Ist das DD.MM.YYYY oder MM.DD.YYYY? Und selbst wenn das Format klar ist: Die meisten Systeme erwarten ISO 8601 (YYYY-MM-DD). Eine automatische Konvertierung mit klar definiertem Input-Format beseitigt jede Mehrdeutigkeit.

Boolesche Werte

“ja”, “Ja”, “JA”, “1”, “true”, “aktiv”, “on” meinen alle dasselbe. Aber eine Datenbank akzeptiert typischerweise nur true oder false. Ohne explizite Konvertierung landet “ja” als String in einem Boolean-Feld und verursacht Fehler in jeder Abfrage, die darauf filtert.

Leere Werte und Defaults

Ein leeres Gewichtsfeld kann vieles bedeuten: nicht gemessen, nicht relevant, oder vergessen. Soll das als null, als 0 oder als Standardwert ins System? Diese Entscheidung sollte nicht der Import-Bearbeiter im Einzelfall treffen, sondern eine Regel, die für alle Datensätze gleich gilt.

Wie eine automatisierte Lösung aussieht

Statt jede Datei manuell vorzubereiten, definiert man einmal ein Mapping: Welches Quellfeld wird zu welchem Zielfeld, mit welchem Datentyp und welchem Standardwert.

Ein Beispiel:

Quellfeld	Zielfeld	Datentyp	Pflicht	Default
Artikelnr	article_number	string	ja	-
Bezeichnung	description	string	ja	-
Preis	price	number	ja	0
Gewicht_kg	weight_kg	number	nein	0
Aktiv	is_active	boolean	nein	true
Erstellt_am	created_at	date	nein	-

Mit diesem Mapping passiert die Transformation automatisch:

“Artikelnr” wird zu “article_number”
“12,50” wird zu 12.5
“ja” wird zu true
“15.03.2026” wird zu “2026-03-15”
Ein leeres Gewicht wird zu 0
Felder, die nicht im Mapping stehen, werden entfernt

Das Ergebnis ist ein sauberer Datensatz, der direkt ins Zielsystem kann. Plus ein Bericht, der zeigt, welche Zeilen Probleme hatten:

Row 3: 'weight_kg' could not be converted to number (value: 'k.A.')
Row 12: 'price' is required but empty

Kein Raten, kein Nachfragen, keine Überraschungen nach dem Import.

Umsetzung mit n8n

Der komplette Transformations-Workflow lässt sich in n8n mit vier Nodes abbilden:

Webhook nimmt die Daten entgegen (JSON-Array oder einzelner Datensatz)
Set Node definiert das Mapping: Feldnamen, Datentypen, Defaults, Pflichtfelder und globale Einstellungen (Dezimaltrennzeichen, Datumsformat, Whitespace trimmen)
Code Node wendet das Mapping auf jeden Datensatz an: Felder umbenennen, Typen konvertieren, Defaults einsetzen, Pflichtfelder prüfen
Respond to Webhook gibt die transformierten Daten und den Fehlerbericht zurück

Keine externen Services, keine API-Keys, keine Datenbank nötig. Der Workflow läuft komplett innerhalb von n8n.

Was die Typkonvertierung kann

Die Konvertierung ist lokalisierbar. Das heißt: Sie konfigurieren einmal, dass Ihr Dezimaltrennzeichen ein Komma ist und Ihre Datumsangaben im Format DD.MM.YYYY kommen. Der Workflow wendet das auf alle Datensätze an.

Zahlen: Erkennt Komma und Punkt als Dezimaltrennzeichen, entfernt Tausendertrennzeichen. “1.234,56” wird korrekt zu 1234.56.

Booleans: Versteht “ja/nein”, “true/false”, “1/0”, “aktiv/inaktiv”, “on/off” und alle gängigen Varianten.

Datumsangaben: Parst jedes konfigurierte Eingabeformat und gibt ein einheitliches Ausgabeformat zurück. “15.03.2026” mit Format DD.MM.YYYY wird zu “2026-03-15”.

Strings: Optionales Trimming von Whitespace und Konvertierung leerer Strings zu null.

Wie man das Mapping anpasst

Das gesamte Mapping liegt in einem einzigen Set Node. Neues Feld? Eine Zeile ergänzen. Anderes Datumsformat? Einen Parameter ändern. Kein Code nötig, keine Deployment-Zyklen.

Wann sich das lohnt

Nicht jeder Import braucht eine automatisierte Transformation. Wenn Sie einmal im Jahr eine Datei mit 20 Zeilen manuell anpassen, ist Excel schneller.

Aber sobald einer dieser Punkte zutrifft, rechnet sich die Automatisierung:

Regelmäßige Imports: Wöchentlich oder häufiger von denselben Quellen
Mehrere Datenlieferanten: Jeder liefert in seinem eigenen Format
Hohe Datensatzanzahl: Ab ein paar hundert Zeilen ist manuelles Mapping unpraktikabel
Regulierte Umgebung: Nachvollziehbarkeit ist Pflicht, manuelle Excel-Anpassungen sind nicht auditierbar
Folgeprozesse: Die Daten fließen direkt in ERP, CRM oder Webshop weiter

In diesen Fällen spart ein einmal konfiguriertes Mapping bei jedem Import Zeit und eliminiert eine Fehlerquelle.

Zusammenspiel mit Validierung

Transformation und Validierung ergänzen sich. In der Praxis sieht die Kette so aus:

Quelldaten empfangen (CSV, JSON, API-Export)
Transformieren (Felder mappen, Typen konvertieren, Defaults setzen)
Validieren (Pflichtfelder, Wertebereiche, Formate prüfen)
Importieren (nur wenn Validierung bestanden)

Schritt 2 und 3 lassen sich in n8n hintereinanderschalten: Der Output des Transformations-Workflows geht direkt in den Validierungs-Workflow. Das Ergebnis: Daten, die sowohl im richtigen Format als auch inhaltlich korrekt sind.

Fazit

Daten aus externen Quellen kommen nie im perfekten Format. Feldnamen stimmen nicht, Dezimaltrennzeichen sind falsch, Datumsformate weichen ab. Wer das manuell korrigiert, investiert bei jedem Import Zeit und riskiert Fehler. Wer es einmal als Mapping definiert, transformiert automatisch und nachvollziehbar.

Sie arbeiten regelmäßig mit Daten aus verschiedenen Quellen? Nutzen Sie das fertige n8n Template zur Datentransformation oder vereinbaren Sie ein Erstgespräch, wenn Sie eine durchgängige Import-Pipeline für Ihr Unternehmen aufbauen möchten.

Dieser Beitrag ist Teil 2 der Datenqualitäts-Serie. Teil 1: Datenqualität bei Imports.