Zwei Systeme synchron halten: Daten­abgleich in n8n

Kundendaten stehen im CRM, im Newsletter-Tool und in der Buchhaltung – dreimal dieselben Menschen, dreimal gepflegt, und mit der Zeit stimmt keine der drei Versionen mehr mit den anderen überein. Wer das von Hand nachhält, verliert; wer es automatisiert, braucht einen verlässlichen Abgleich. n8n bringt dafür eine eigene Node mit, die zwei Datenbestände vergleicht und genau sagt, was neu ist, was sich geändert hat und was nur auf einer Seite steht. Dieser Artikel zeigt, wie dieser Datenabgleich funktioniert – und wo die ehrlichen Fallstricke liegen.

Warum Daten in zwei Systemen auseinanderlaufen

In fast jedem Betrieb liegen dieselben Stammdaten mehrfach: Kunden im CRM und im Shop, Artikel in der Warenwirtschaft und im Online-Katalog, Mitarbeiter in der Zeiterfassung und im Lohnprogramm. Solange jemand jede Änderung brav an beiden Stellen einträgt, geht das gut. Genau das passiert im Alltag aber nicht. Eine Adresse wird nur im CRM korrigiert, ein Preis nur im Shop, ein Austritt nur in der Personalliste – und die Bestände driften auseinander.

Das eigentliche Problem ist selten das Anlegen neuer Datensätze, sondern das Erkennen von Unterschieden. Welcher der beiden Stände ist der aktuelle? Fehlt ein Eintrag, weil er neu ist – oder weil er auf der anderen Seite gelöscht wurde? Diese Fragen lassen sich nicht raten, sie brauchen einen sauberen Vergleich. Und der beginnt damit, beide Seiten nebeneinanderzulegen.

Vergleichen ist nicht zusammenführen

Eine Abgrenzung vorweg, weil sie oft verwechselt wird: Der Merge-Node führt zwei Datenströme zusammen – er verbindet passende Datensätze zu einem oder hängt Listen aneinander. Der Datenabgleich macht das Gegenteil: Er stellt zwei Bestände gegenüber und arbeitet die Unterschiede heraus. Merge beantwortet die Frage „Wie sieht der gemeinsame Datensatz aus?“, der Abgleich die Frage „Was ist auf beiden Seiten nicht gleich?“.

Für den Abgleich gibt es in n8n die Compare-Datasets-Node. Sie hat zwei Eingänge – Input A und Input B – und erwartet, dass an beiden bereits Daten anliegen. Das heißt: Bevor verglichen wird, müssen beide Quellen geladen sein.

Erst die Quellen holen, dann normalisieren

Der Abgleich vergleicht nur, was ihm gereicht wird. Sie holen also zuerst beide Seiten in den Workflow: die eine per Datenbankabfrage, die andere über eine API oder einen Datei-Export, je nachdem, was das System hergibt. Beide Bestände laufen dann in je einen Eingang der Compare-Datasets-Node.

Ein Schritt davor entscheidet über den Erfolg: Die Felder müssen auf beiden Seiten gleich heißen und gleich aussehen. Heißt die Kundennummer im einen System id und im anderen kundennr, findet der Abgleich keine Paare. Deshalb gehört vor die Node ein Edit-Fields-(Set)-Schritt, der beide Seiten auf einheitliche Feldnamen bringt – die Option „Keep Only Set Fields“ wirft dabei alles Überflüssige weg. Warum sich saubere Daten vor jeder Automatisierung auszahlen, gilt hier doppelt: Ein Abgleich auf uneinheitlichen Feldern meldet Unterschiede, die keine sind.

Die Compare-Datasets-Node und ihre vier Ausgänge

Die Node arbeitet in zwei Stufen. Zuerst sucht sie über ein oder mehrere Schlüsselfelder – eingetragen unter „Input A Field“ und „Input B Field“ – die zusammengehörigen Datensätze. Dann vergleicht sie bei jedem gefundenen Paar die übrigen Felder und entscheidet, ob die beiden gleich oder verschieden sind. Das Ergebnis verteilt sie auf vier getrennte Ausgänge.

Die Compare-Datasets-Node in n8n vergleicht zwei Datenbestände anhand eines Schlüsselfelds und sortiert jeden Datensatz in einen von vier Ausgängen: nur in Quelle A, nur in Quelle B, in beiden identisch oder in beiden vorhanden, aber unterschiedlich. Dieser saubere Schnitt ist die Grundlage jedes Abgleichs – er sagt Ihnen exakt, was angelegt, aktualisiert oder ignoriert werden muss.

Genau diese vier Wege machen die Node so nützlich: Jeder Ausgang lässt sich mit einer eigenen Folgeaktion verdrahten. Die offiziellen Details stehen in der Dokumentation zur Compare-Datasets-Node.

Was mit jedem Ausgang passiert

Die vier Ausgänge übersetzen sich fast eins zu eins in die Aktionen eines Abgleichs. Die folgende Tabelle zeigt das Grundmuster:

Ausgang der Node	Bedeutung und Folgeaktion
In A only	Datensatz existiert nur in A – meist: in B anlegen
In B only	Datensatz existiert nur in B – meist: in A anlegen
Different	Schlüssel gleich, Werte weichen ab – aktualisieren
Same	In beiden identisch – nichts tun

Der „Same“-Ausgang ist dabei der wichtigste stille Helfer: Alles, was ohnehin übereinstimmt, wird gar nicht erst angefasst. Ein guter Abgleich schreibt also nicht bei jedem Lauf alle Datensätze neu, sondern rührt nur an, was sich wirklich unterscheidet. Das schont die Zielsysteme und ihre API-Limits.

Einbahnstraße oder Gegenverkehr

Die zentrale Entscheidung fällt vor dem ersten Node: Fließen die Daten in eine Richtung oder in beide? Die Einbahnstraße ist der ehrlich empfehlenswerte Standard. Ein System gilt als Führungssystem, die andere Seite wird ihm angeglichen. Dann ist immer klar, wer gewinnt: Bei Unterschieden zählt der Stand des Führungssystems, fehlende Datensätze werden nur in eine Richtung nachgezogen.

Der Zweiwege-Abgleich – beide Seiten dürfen sich gegenseitig aktualisieren – klingt bequemer, ist aber deutlich anspruchsvoller, weil er einen Konfliktfall lösen muss: Wurde ein Datensatz auf beiden Seiten unterschiedlich geändert, welcher Stand gewinnt? Die Node bietet dafür unter „When There Are Differences“ vier Strategien an: „Use Input A Version“, „Use Input B Version“, „Use a Mix of Versions“ oder „Include Both Versions“. In der Praxis reicht das allein aber nicht – meist braucht es zusätzlich einen Zeitstempel „zuletzt geändert am“, über den ein nachgelagerter IF- oder Switch-Node entscheidet, welche Version die jüngere ist. Als Faustregel aus Gesprächen mit Betrieben: Wer nicht zwingend beide Richtungen braucht, fährt mit der Einbahnstraße ruhiger.

Optionen, die den Abgleich robust machen

Ein paar Einstellungen entscheiden darüber, ob der Abgleich in der Praxis brauchbare Ergebnisse liefert oder an Nebensächlichkeiten scheitert:

• Fuzzy Compare: Toleriert kleine Typunterschiede – die Zahl 3 und der Text 3 gelten dann als gleich. Ohne diese Option meldet ein Feld, das mal als Zahl und mal als Text ankommt, ständig falsche Unterschiede.
• Fields to Skip Comparing: Nimmt Felder vom Vergleich aus. Sinnvoll für Angaben, die sich immer unterscheiden, ohne dass es zählt – etwa ein „zuletzt abgerufen am“-Zeitstempel des jeweiligen Systems.
• Multiple Matches: Legt fest, ob bei mehreren Treffern zum selben Schlüssel alle Paare verglichen werden („Include All Matches“) oder nur der erste. Ein Hinweis darauf, dass der Schlüssel womöglich nicht eindeutig ist.
• Disable Dot Notation: Steuert, ob verschachtelte Felder über die Schreibweise kunde.email erreichbar sind – wichtig, wenn Ihre Feldnamen selbst Punkte enthalten.

Drei Fallstricke vor dem Scharfschalten

Erstens, und das ist der gefährlichste Punkt: Ein fehlender Datensatz ist zweideutig. Steht ein Eintrag „nur in A“, kann das zweierlei heißen – er ist dort neu, oder er wurde in B absichtlich gelöscht. Aus einem einzelnen Vergleich lässt sich das nicht unterscheiden. Wer den „In A only“-Ausgang blind auf „in B löschen“ verdrahtet, räumt womöglich frische Einträge wieder ab. Löschungen deshalb nie automatisch aus einem Abgleich ableiten, sondern über ein Statusfeld oder eine menschliche Freigabe absichern.

Zweitens: Der Abgleich muss wiederholbar sein, ohne Schaden anzurichten. Läuft er zweimal kurz nacheinander, dürfen keine Dubletten entstehen. Das gelingt nur, wenn das Anlegen und Aktualisieren idempotent gebaut ist – also über den Schlüssel prüft, ob ein Datensatz schon existiert, statt stumpf anzulegen.

Drittens: Der Takt gehört bewusst gewählt. Ein Stammdaten-Abgleich läuft selten in Echtzeit; meist reicht ein nächtlicher Lauf per Schedule Trigger. Ob Ihr Fall eher einen Zeitplan oder einen ereignisgesteuerten Auslöser braucht, klärt der Artikel Webhook oder Polling.

Fazit

Der Datenabgleich ist keine exotische Spezialdisziplin, sondern die Grundlage dafür, dass zwei Systeme dauerhaft dieselbe Wahrheit erzählen. Die Compare-Datasets-Node nimmt Ihnen den Vergleich ab; Ihre Aufgabe ist, die Felder sauber vorzubereiten, eine Richtung festzulegen und mit Löschungen vorsichtig umzugehen. Wenn Sie einen konkreten Abgleich planen und ihn tragfähig aufsetzen wollen, unterstütze ich Sie in der n8n-Beratung.

Welche Ihrer Systeme heute doppelt gepflegt werden und wo sich ein automatischer Abgleich wirklich lohnt, lässt sich am besten am konkreten Fall beurteilen. Genau das schauen wir uns im kostenlosen Prozess-Check gemeinsam an – ehrlich, auch wenn die Antwort manchmal lautet, dass ein sauberer Export einmal pro Woche schon reicht.