Reconciliation: warum Ihre Systeme leise auseinanderdriften, und niemand sie abgleicht

Zwei Zahlen, die nicht zusammenpassen

Vor ein paar Wochen saß ich mit einem Geschäftsführer vor zwei Dashboards. Auf dem einen stand: 1.180 aktive Kunden im CRM. Auf dem anderen: 1.224 zahlende Abonnenten im Abrechnungssystem. Es waren dieselben Kunden, dieselben Verträge, und zwischen den beiden Systemen lief seit zwei Jahren eine Automatisierung, die genau dafür gebaut worden war, dass diese Zahlen übereinstimmen.

44 Kunden Unterschied. Niemand im Raum konnte sagen, welche 44. Niemand wusste, ob das CRM 44 zu wenig hatte oder die Abrechnung 44 zu viel. Und niemand wusste, seit wann.

Das ist kein exotischer Sonderfall. Das ist der Normalzustand. Ich habe in den letzten Jahren in viele Automatisierungs-Konten geschaut, und überall dort, wo zwei Systeme über eine Automatisierung verbunden sind, laufen die Daten mit der Zeit auseinander. Langsam, leise, ohne Fehlermeldung. Der Workflow läuft jeden Tag grün durch, und trotzdem stimmen die beiden Seiten am Ende nicht überein.

Dieser Artikel handelt von dem Mechanismus, der das verhindert, und den fast niemand baut. Im Englischen heißt er Reconciliation, auf Deutsch Abgleich, und das Wort trifft es ganz gut: Zwei Systeme, die sich uneinig sind, wieder zur Deckung bringen. Es ist die unscheinbarste Komponente einer Integration und in den meisten Fällen die einzige, die Ihnen sagt, ob der ganze Rest überhaupt funktioniert.

Warum "synchronisiert" nicht dasselbe ist wie "gleich"

Wenn jemand eine Automatisierung baut, die zwei Systeme verbindet, dann denkt er in Ereignissen. Ein neuer Kunde im CRM, also lege ihn in der Abrechnung an. Eine Kündigung in der Abrechnung, also setze den Status im CRM auf inaktiv. Jedes Ereignis löst eine Aktion aus, und solange jedes Ereignis sauber durchläuft, sind die beiden Seiten danach identisch.

Das ist die Theorie. Sie hat einen Haken: Sie setzt voraus, dass jedes einzelne Ereignis ankommt und korrekt verarbeitet wird. Für immer. Bei jeder Buchung, jeder Kündigung, jeder Adressänderung, ohne Ausnahme, über Jahre hinweg.

Genau das passiert nie. Eine Synchronisation ist eine Kette von Annahmen darüber, dass nichts verloren geht. Ein Abgleich ist die Überprüfung, ob diese Annahmen gestimmt haben. Das sind zwei grundverschiedene Dinge, und die meisten Unternehmen bauen nur das erste.

Der Denkfehler liegt darin, Synchronisation für einen Zustand zu halten. "Die Systeme sind synchron" klingt wie eine Eigenschaft, die einmal hergestellt wird und dann bestehen bleibt. In Wirklichkeit ist Synchronisation ein fortlaufender Prozess, der ständig kleine Fehler produziert. Ohne eine zweite Instanz, die diese Fehler einsammelt, summieren sie sich.

Wie Drift entsteht, obwohl alles grün läuft

Die wichtigste Frage ist nicht, ob Ihre Daten auseinanderlaufen, sondern wie schnell. Und die Antwort hängt davon ab, wie viele Wege es gibt, auf denen ein Ereignis verloren geht. In der Praxis sind es überraschend viele.

Da ist der Webhook, der nicht ankommt. Das Abrechnungssystem schickt eine Benachrichtigung über eine Kündigung, aber Ihre Plattform hatte in dem Moment einen kurzen Aussetzer, oder das Abrechnungssystem hat den Webhook nach drei fehlgeschlagenen Versuchen aufgegeben. Das Ereignis ist weg. Es kommt kein zweites. Der Kunde bleibt im CRM für immer aktiv.

Da ist die manuelle Änderung. Jemand aus dem Support öffnet die Abrechnung und storniert einen Vertrag von Hand, weil der Kunde angerufen hat. Diese Stornierung über die Oberfläche löst oft keinen Webhook aus, oder einen anderen als der reguläre Weg. Das CRM erfährt nichts davon.

Da ist die Verarbeitung, die zur Hälfte durchläuft. Der Workflow holt den neuen Kunden, legt ihn in der Abrechnung an, und beim Schritt danach, dem Update des CRM-Status, läuft er in ein Timeout. Der Kunde existiert jetzt in beiden Systemen, aber mit zwei verschiedenen Zuständen. Kein roter Lauf, weil viele Plattformen einen teilweise erfolgreichen Durchlauf trotzdem als erfolgreich zählen.

Da ist die Reihenfolge. Zwei Ereignisse kommen kurz hintereinander, eine Adressänderung und gleich danach eine zweite Korrektur, aber die Automatisierung verarbeitet sie parallel, und die ältere überschreibt am Ende die neuere. Im CRM steht jetzt die falsche Adresse, und nichts deutet darauf hin.

Da ist die stille Annahme über Felder. Vor einem Jahr hat jemand im Abrechnungssystem ein Pflichtfeld hinzugefügt. Seitdem schlägt das Anlegen neuer Kunden manchmal fehl, aber nur bei denen, die dieses Feld nicht gesetzt haben. Die Automatisierung fängt den Fehler ab und macht weiter, und Sie verlieren still einen Bruchteil aller Neukunden.

Jeder dieser Wege für sich ist selten. Vielleicht trifft es einen von tausend Datensätzen. Aber bei tausend Buchungen im Monat ist das ein Datensatz im Monat, zwölf im Jahr, und nach zwei Jahren stehen Sie vor 44 Kunden, von denen niemand mehr weiß, wo sie herkommen. So entsteht Drift. Nicht durch einen großen Ausfall, den jeder bemerkt, sondern durch viele winzige Lücken, die einzeln unter dem Radar bleiben.

Was ein Abgleich eigentlich ist

Ein Abgleich beantwortet eine einzige Frage: Stimmen die beiden Systeme gerade überein, und wenn nicht, wo genau weichen sie ab?

Er funktioniert grundlegend anders als eine Synchronisation. Die Synchronisation reagiert auf Ereignisse, ein Auslöser nach dem anderen, in dem Glauben, dass die Summe aller Auslöser am Ende den richtigen Zustand ergibt. Der Abgleich ignoriert Ereignisse vollständig. Er nimmt beide Systeme zu einem Zeitpunkt, schaut sich den vollständigen Bestand auf jeder Seite an und vergleicht sie Datensatz für Datensatz.

Das ist der entscheidende Unterschied. Eine Synchronisation kann nicht erkennen, dass ihr ein Ereignis durchgerutscht ist, weil sie nur von den Ereignissen weiß, die sie gesehen hat. Was sie nie gesehen hat, existiert für sie nicht. Der Abgleich kennt diese blinde Stelle nicht, weil er nicht den Ereignissen folgt, sondern dem tatsächlichen Bestand. Er fragt nicht "habe ich alles verarbeitet", sondern "ist das Ergebnis am Ende richtig".

In der klassischen Softwareentwicklung ist das ein vertrautes Muster. Jede ernstzunehmende Integration zwischen zwei Systemen hat einen periodischen Abgleich, oft Reconciliation Job genannt, der nachts läuft und meldet, was nicht passt. In der No-Code-Welt fehlt dieses Muster fast immer. Die Plattformen machen es leicht, auf ein Ereignis zu reagieren, und schwer, zwei vollständige Bestände gegeneinanderzuhalten. Also baut es niemand, und die Drift bleibt unsichtbar, bis ein Kunde anruft.

Die Anatomie eines Abgleich-Jobs

Ein Abgleich besteht im Kern aus fünf Schritten, und es lohnt sich, jeden einzeln zu verstehen, weil die meisten Fehler in genau einem davon stecken.

Der erste Schritt ist das Einsammeln beider Seiten. Sie holen den vollständigen relevanten Bestand aus System A und aus System B. Nicht die letzten hundert Datensätze, nicht die der letzten Woche, sondern alle, die übereinstimmen sollen. Das klingt banal, ist aber die Stelle, an der die meisten Abgleiche scheitern, weil die Plattform die Daten in Seiten zu hundert Stück ausliefert und der Workflow nur die erste Seite holt.

Der zweite Schritt ist der Schlüssel. Sie brauchen ein Feld, das einen Datensatz in System A eindeutig einem in System B zuordnet. Eine Kundennummer, eine E-Mail-Adresse, eine externe ID. Ohne einen verlässlichen Schlüssel können Sie nicht abgleichen, sondern nur raten. Und der Schlüssel muss stabil sein. Eine E-Mail-Adresse ändert sich, eine Kundennummer im besten Fall nie.

Der dritte Schritt ist der Vergleich. Sie gehen beide Bestände durch und sortieren jeden Datensatz in eine von drei Kategorien: existiert in beiden und ist gleich, existiert nur auf einer Seite, oder existiert in beiden, aber mit unterschiedlichen Werten. Diese Sortierung ist der eigentliche Kern des Abgleichs.

Der vierte Schritt ist die Bewertung. Nicht jede Abweichung ist ein Fehler. Ein Kunde, der vor zwei Minuten angelegt wurde und noch nicht im zweiten System ist, ist kein Problem, sondern nur der normale Verzug der Synchronisation. Ein Kunde, der seit drei Wochen auf einer Seite fehlt, ist ein Problem. Der Abgleich muss diese beiden Fälle unterscheiden können, sonst ertrinken Sie in Fehlalarmen.

Der fünfte Schritt ist die Reaktion. Was passiert mit den Abweichungen, die übrig bleiben? Hier gibt es mehrere Möglichkeiten, und die Wahl entscheidet darüber, ob Ihr Abgleich hilft oder selbst zur Gefahr wird. Dazu gleich mehr.

Drei Arten von Abweichungen, und was sie bedeuten

Wenn Sie zwei Bestände gegeneinanderhalten, fällt jede Abweichung in eine von drei Kategorien, und jede erzählt eine andere Geschichte.

Der Datensatz fehlt in System B, ist aber in System A. Meistens bedeutet das, dass ein Ereignis verloren ging, das ihn nach B hätte bringen sollen. Der Kunde wurde im CRM angelegt, aber nie in der Abrechnung, weil der Anlage-Schritt damals fehlschlug. Das ist der gefährlichste Fall, weil hier oft echtes Geld liegt. Ein Kunde, der nutzt, aber nicht zahlt, weil er in der Abrechnung nie ankam.

Der Datensatz fehlt in System A, ist aber in System B. Das ist die Umkehrung, und sie deutet oft auf das Gegenteil hin: Etwas wurde in A gelöscht oder deaktiviert, aber die Information kam nie in B an. Der Kunde hat gekündigt, im CRM steht er auf inaktiv, aber die Abrechnung bucht weiter ab. Diese Variante landet schneller vor Gericht als die erste, weil hier jemand für etwas zahlt, das er beendet hat.

Der Datensatz existiert in beiden, aber die Werte unterscheiden sich. Die Adresse ist verschieden, der Status ist verschieden, der Tarif ist verschieden. Das ist der subtilste Fall, weil beide Systeme den Kunden kennen und alles oberflächlich in Ordnung aussieht. Erst beim Feld-für-Feld-Vergleich fällt auf, dass die eine Seite einen anderen Stand hat als die andere. Solche Abweichungen entstehen durch Reihenfolge-Probleme, durch manuelle Eingriffe oder durch Updates, die nur eine Richtung kannten.

Der praktische Wert dieser Einteilung liegt darin, dass jede Kategorie eine andere Ursache hat und eine andere Reaktion verlangt. Ein fehlender Datensatz lässt sich oft automatisch nachziehen. Ein Wertunterschied braucht eine Entscheidung, welche Seite recht hat, und die kann eine Automatisierung nicht immer treffen.

Was Sie mit einer Abweichung tun, und was nicht

Die naheliegende Idee ist: Wenn der Abgleich eine Abweichung findet, soll er sie gleich beheben. Fehlt der Kunde in der Abrechnung, leg ihn an. Steht der Status falsch, korrigiere ihn. Ein Abgleich, der sich selbst repariert, klingt nach der eleganten Lösung.

Hier rate ich zur Vorsicht. Ein Abgleich, der automatisch korrigiert, ist ein mächtiges Werkzeug und genauso schnell ein gefährliches. Wenn Ihr Abgleich einen Denkfehler hat, dann repariert er nicht, sondern beschädigt, und zwar in großem Maßstab und auf einen Schlag. Ich habe einen Fall gesehen, in dem ein selbstheilender Abgleich nachts hunderte Kunden auf inaktiv setzte, weil er kurzzeitig nur die halbe Seite eines Bestands geladen hatte und alle fehlenden für gekündigt hielt. Die Synchronisation hatte über Monate winzige Schäden angerichtet. Der Abgleich richtete an einem Abend einen großen an.

Deshalb trenne ich die drei Reaktionen sauber. Die erste ist melden. Der Abgleich findet die Abweichungen und schreibt sie in eine Liste, die ein Mensch morgens durchgeht. Das ist der richtige Startpunkt für fast jeden Abgleich, weil Sie erst einmal sehen wollen, was er findet, bevor Sie ihm erlauben, etwas zu tun.

Die zweite ist automatisch beheben, aber nur für die Fälle, die eindeutig und ungefährlich sind. Ein fehlender Datensatz, der eindeutig nur angelegt werden muss, lässt sich gefahrlos nachziehen. Ein Wertkonflikt, bei dem unklar ist, welche Seite recht hat, gehört niemals in die automatische Behebung.

Die dritte ist isolieren. Manche Abweichungen sind so ungewöhnlich, dass die richtige Reaktion lautet: anhalten, den Datensatz beiseitelegen und nichts tun, bis ein Mensch hingeschaut hat. Wenn ein Kunde in beiden Systemen einen völlig anderen Tarif hat, ist das kein Fall für eine automatische Regel, sondern ein Hinweis, dass irgendwo etwas grundlegend schiefläuft.

Meine Faustregel: Lassen Sie den Abgleich am Anfang nur melden. Erst wenn Sie ein paar Wochen lang gesehen haben, was für Abweichungen tatsächlich auftauchen, und verstehen, woher sie kommen, schalten Sie die automatische Behebung für die wenigen wirklich eindeutigen Fälle frei. Alles andere bleibt bei einem Menschen.

Der häufigste Fehler: der Abgleich, der selbst lügt

Es gibt eine besonders tückische Art, einen Abgleich falsch zu bauen, und sie ist gefährlicher als gar kein Abgleich. Das ist der Abgleich, der immer "alles in Ordnung" meldet, weil er die eine Seite nie vollständig sieht.

Der typische Hergang: Der Abgleich holt aus System A den vollen Bestand, aus System B aber nur die erste Seite von hundert Datensätzen, weil die API in Seiten ausliefert und der Workflow das übersieht. Jetzt vergleicht er tausend Datensätze aus A mit hundert aus B. Er müsste eigentlich Alarm schlagen, denn neunhundert fehlen scheinbar. Stattdessen ist er oft so gebaut, dass er nur prüft, ob jeder Datensatz aus B auch in A vorkommt, und das tun ja alle hundert. Ergebnis: grün. Alles passt. In Wirklichkeit hat er neunzig Prozent der einen Seite nie angeschaut.

Das ist der schlimmste Zustand überhaupt. Sie haben jetzt nicht nur Drift, Sie haben auch noch ein Frühwarnsystem, das Ihnen aktiv versichert, dass alles stimmt. Das Vertrauen, das ein grüner Abgleich erzeugt, ist gefährlicher als das offene Eingeständnis, dass niemand hinschaut.

Deshalb braucht jeder Abgleich eine Plausibilitätsprüfung über sich selbst. Die einfachste ist ein Mengenvergleich: Wenn System A 1.224 Datensätze meldet und System B nur 130, dann ist nicht das Ergebnis "keine Abweichungen" plausibel, sondern die Vermutung, dass der Abgleich selbst kaputt ist. Ein Abgleich, der nicht weiß, wie viele Datensätze er auf jeder Seite gesehen hat, ist kein Abgleich, sondern ein Placebo.

Wie oft, und über welchen Zeitraum

Ein Abgleich, der jede Minute läuft, ist meistens verschwendet. Ein Abgleich, der einmal im Jahr läuft, kommt zu spät. Die richtige Frequenz hängt davon ab, wie teuer eine Abweichung pro Tag ist, die niemand bemerkt.

Bei Abrechnungsdaten, wo jeder Tag falscher Abbuchung Geld und Vertrauen kostet, ist täglich ein guter Rhythmus. Ein nächtlicher Lauf, der morgens eine kurze Liste auf den Tisch legt, fängt die meisten Probleme, bevor sie groß werden. Bei Daten, die sich selten ändern und wenig kosten, wenn sie kurz auseinanderlaufen, reicht wöchentlich.

Wichtiger als die reine Frequenz ist die Frage des Zeitfensters. Wenn Sie täglich um drei Uhr nachts beide Bestände einsammeln, dann erwischen Sie zwangsläufig Datensätze, die gerade mitten in der Verarbeitung sind. Der Kunde wurde um 02:59 in A angelegt und ist um 03:00 noch nicht in B. Das ist keine echte Abweichung, sondern nur der normale Verzug.

Die saubere Lösung ist eine Toleranzgrenze. Sie ignorieren Abweichungen, die jünger sind als ein bestimmter Zeitraum, sagen wir eine Stunde. Alles, was länger als eine Stunde auseinanderläuft, ist verdächtig. Alles darunter ist vermutlich nur Synchronisation, die noch nicht fertig ist. Ohne diese Grenze produziert Ihr Abgleich jeden Morgen eine Handvoll Geister-Abweichungen, die sich von selbst auflösen, und nach einer Woche schaut niemand mehr auf die Liste.

Ein konkreter Aufbau: CRM gegen Abrechnung

Damit das nicht abstrakt bleibt, hier der Aufbau, den ich für den Fall vom Anfang gebaut habe, in der Form, in der er sich mit Make oder n8n umsetzen lässt.

Der Job startet einmal täglich um vier Uhr morgens, nach dem Hauptlauf der nächtlichen Synchronisation. Schritt eins holt aus dem CRM alle Kunden mit Status aktiv, über alle Seiten hinweg, und merkt sich die Gesamtzahl. Schritt zwei holt aus der Abrechnung alle Verträge mit Status laufend, ebenfalls vollständig, und merkt sich auch hier die Zahl.

Schritt drei ist die Plausibilitätsprüfung: Wenn eine der beiden Seiten weniger als achtzig Prozent der Datensätze geliefert hat, die sie beim letzten Lauf hatte, dann bricht der Job ab und meldet "Abgleich nicht vertrauenswürdig". Lieber kein Ergebnis als ein falsches.

Schritt vier baut aus beiden Beständen je eine Zuordnung über die Kundennummer und vergleicht sie. Heraus kommen drei Listen: nur im CRM, nur in der Abrechnung, in beiden mit unterschiedlichem Status. Schritt fünf filtert aus allen drei Listen die Datensätze heraus, die jünger als eine Stunde sind.

Schritt sechs schreibt das Ergebnis in eine Tabelle und schickt eine Nachricht in den Team-Kanal, aber nur, wenn überhaupt etwas übrig blieb. Ein Abgleich, der jeden Morgen "null Abweichungen" meldet, wird nach zwei Wochen ignoriert. Ein Abgleich, der nur dann meldet, wenn etwas ist, behält seine Aufmerksamkeit. Und einmal in der Woche, am Montag, kommt eine kurze Zusammenfassung mit den Mengen auf beiden Seiten, damit das Team sieht, dass der Job noch lebt, auch wenn er nichts gefunden hat.

Beim ersten Lauf fand dieser Abgleich nicht 44, sondern 61 Abweichungen. Siebzehn davon waren kurzlebige Verzögerungen, die beim nächsten Lauf weg waren. Übrig blieben die 44, und sie zerfielen in zwei Gruppen: 31 Kunden, die im CRM gekündigt waren, aber in der Abrechnung weiterliefen, und 13, die in der Abrechnung angelegt, aber nie ins CRM gekommen waren. Die ersten 31 kosteten den Kunden nichts, im Gegenteil. Die 13 dagegen nutzten, ohne dass je eine Rechnung gestellt wurde.

Der Abgleich als Frühwarnsystem

Der eigentliche Wert eines Abgleichs liegt nicht darin, dass er die 44 alten Fälle aufräumt. Das ist nur die einmalige Inventur am Anfang. Der bleibende Wert liegt darin, dass er ab jetzt jeden neuen Fall fängt, solange er noch klein ist.

Sobald der Abgleich läuft, verändert sich die Bedeutung jeder neuen Abweichung. Eine einzelne Abweichung, die plötzlich auftaucht, ist oft das erste Symptom eines Problems, das gerade erst entstanden ist. Drei neue fehlende Datensätze an einem Morgen können bedeuten, dass gestern jemand am Webhook etwas geändert hat. Eine Welle von Wertkonflikten kann bedeuten, dass ein Pflichtfeld dazugekommen ist. Der Abgleich übersetzt eine technische Veränderung, die Sie sonst erst Wochen später bemerkt hätten, in eine sichtbare Zahl am nächsten Morgen.

So wird aus der Inventur ein Sensor. Die Synchronisation tut die Arbeit. Der Abgleich misst, ob die Arbeit stimmt, und schlägt an, wenn sie es nicht mehr tut. Ein Workflow ohne Abgleich ist ein Auto ohne Tankanzeige. Es fährt, bis es plötzlich nicht mehr fährt, und dann stehen Sie am Straßenrand und wissen nicht, warum.

Wem die Drift gehört

Zum Schluss der unbequeme Teil, der nichts mit Technik zu tun hat. In den meisten Unternehmen, in denen ich Drift gefunden habe, lag das eigentliche Problem nicht im Workflow, sondern in der Frage, wer für die Übereinstimmung der beiden Systeme verantwortlich ist. Und die Antwort lautete fast immer: niemand.

Das CRM gehört dem Vertrieb. Die Abrechnung gehört der Buchhaltung. Die Automatisierung dazwischen hat irgendwann jemand gebaut, der vielleicht nicht mehr im Unternehmen ist. Solange alles grün läuft, fühlt sich keiner zuständig. Und genau deshalb bemerkt niemand die Drift, denn die Drift lebt im Zwischenraum, der keinem gehört.

Ein Abgleich verändert das, und zwar nicht nur technisch. Er macht die Drift sichtbar, und sichtbare Drift verlangt einen Besitzer. Die Liste der Abweichungen, die jeden Morgen aufschlägt, braucht einen Menschen, der entscheidet, was damit passiert. In dem Moment, in dem dieser Mensch benannt ist, hat der Zwischenraum zum ersten Mal jemanden, der sich für ihn verantwortlich fühlt. Das ist oft die wichtigere Wirkung als der Code selbst.

Was Sie diese Woche tun können

Sie brauchen keinen großen Abgleich-Job, um anzufangen. Sie brauchen eine einzige Zahl von jeder Seite. Zählen Sie, wie viele aktive Kunden in Ihrem CRM stehen. Zählen Sie, wie viele laufende Verträge Ihre Abrechnung hat. Schreiben Sie beide Zahlen nebeneinander.

Wenn sie übereinstimmen, haben Sie in zehn Minuten ein gutes Gefühl gewonnen. Wenn sie es nicht tun, haben Sie gerade ein Problem entdeckt, das vorher unsichtbar war, und das ist der wertvollere Ausgang. Denn die Lücke war die ganze Zeit da. Sie haben sie nur zum ersten Mal angeschaut.

Falls Sie nicht sicher sind, ob Ihre Systeme still auseinanderlaufen, schauen wir uns das gemeinsam an. In unserem kostenlosen Automations-Check gehen wir Ihre Workflows durch und prüfen, ob die Zahlen, auf die Sie sich verlassen, auf beiden Seiten wirklich dieselben sind.