Der Hotel-Agent nimmt eine Direktbuchung auf. Der Workflow zeigt grün: API-Aufruf erfolgreich, Bestätigungs-Mail erstellt, CRM aktualisiert. Am Abend bemerkt die Reception, dass im PMS keine Reservation existiert.
Für die Automation war der Run erfolgreich. Für das Hotel ist das Zimmer nicht gebucht.
Dieses Auseinanderlaufen ist der Grund für Reconciliation: Nach der Ausführung wird nicht nur gefragt, ob einzelne technische Schritte erfolgreich aussahen, sondern ob der gewünschte Geschäftszustand im Zielsystem tatsächlich existiert.
Bei Zahlungen und Buchhaltung ist Abgleich selbstverständlich. Bei AI-Automationen wird er oft vergessen, weil der Workflow-Builder bereits überall grüne Häkchen zeigt. Ein grünes Häkchen ist aber nur eine Aussage über einen Schritt — nicht über das Ende des Geschäftsprozesses.
Reconciliation für Automationen beginnt mit der Sollzustand
Bevor Sie etwas abgleichen können, müssen Sie definieren, wie „fertig“ aussieht.
Bei einem Termin könnte die Sollzustand lauten: Im Kalender existiert genau ein Termin mit Kunde, Zeit und Leistung; im CRM steht die Termin-ID; der Kunde hat eine bestätigte Nachricht erhalten.
Bei einer Hotelbuchung: PMS-Reservation mit bestätigter ID, korrekter Rate und Daten; CRM/Guest Record verknüpft; Bestätigung referenziert dieselbe Reservierungs-ID.
Bei einem Follow-up: Nachricht wurde tatsächlich vom Mailprovider akzeptiert, der CRM-Status ist aktualisiert und die nächste Aufgabe ist gesetzt.
Der Workflow-Status success ist keine Sollzustand. Er ist höchstens ein Signal, dass die Prüfung beginnen kann.
Verteilte Workflows können Teilfehler und unterschiedliche Zustände über mehrere Systeme haben; Saga- und Compensating-Transaction-Muster adressieren genau solche mehrstufigen Prozesse.
Empfehlung: Formulieren Sie für jede wichtige Automation einen maschinenprüfbaren Zielzustand.
Drei Arten von Abweichungen, die ein KMU finden sollte
Die erste ist missing: Der Agent wollte einen Termin erstellen, aber im Zielkalender fehlt er. Ursache kann Timeout, Mapping-Fehler, falscher Kalender oder ein späterer manueller Delete sein.
Die zweite ist wrong: Der Termin existiert, aber mit falscher Zeit, falschem Kunden oder altem Preis. Technisch wurde geschrieben; fachlich ist der Zustand falsch.
Die dritte ist duplicate: Die gewünschte Aktion existiert mehrfach. Hier trifft Reconciliation auf Idempotenz.
Es gibt noch einen vierten Zustand, der oft zu Fehlalarmen führt: eventual consistency. Manche Systeme brauchen Zeit, bis ein Write in allen Ansichten sichtbar ist. Wer eine Millisekunde später abgleicht, markiert einen normalen Delay als Incident.
Deshalb braucht jede Regel ein sinnvolles Prüfintervall: nach 30 Sekunden, fünf Minuten oder am Tagesende — je nach Prozess.
Ein Reconciliation-Job ist kein zweiter AI-Agent
Der Abgleich sollte so deterministisch wie möglich sein. Wenn die Frage lautet „Existiert Reservation ID 88421 im PMS?“, brauchen Sie keine kreative Modellantwort.
Ein einfacher Ablauf:
- Intended state speichern. Welcher Vorgang sollte was erzeugen oder ändern?
- Nach sinnvoller Verzögerung Zielsystem lesen. Nicht nur den Workflow-Log.
- Sollzustand vergleichen. Objekt vorhanden, relevante Felder korrekt, Anzahl korrekt, Referenzen konsistent?
- Toleranzen definieren. Kurzfristige Sync-Delays, erlaubte Rundungen oder bewusst manuelle Änderungen berücksichtigen.
- Nur persistente Abweichungen eskalieren. Ein Prüfung durch einen erneuten Versuch kann einen transienten Fehler ausfiltern.
- Ausnahmefall mit zuständiger Person erstellen. Kein generisches „reconciliation failed“, sondern Kunde/Vorgang, Soll, Ist, letzter technischer Schritt und empfohlener Prüfpunkt.
Ein AI-Modell kann danach bei unstrukturierten Logs oder Erklärung helfen. Die Kernprüfung selbst sollte aber nicht auf sprachlicher Interpretation beruhen, wenn strukturierte IDs und Felder existieren.
Der menschliche Teil: nicht jede Differenz automatisch «reparieren»
Stellen Sie sich vor, ein Mitarbeiter hat während eines API-Ausfalls einen Termin manuell auf 15 Uhr verschoben. Der ursprüngliche Agent-Plan lautet noch 14 Uhr. Reconciliation findet die Differenz.
Wenn das System jetzt automatisch auf 14 Uhr „zurückkorrigiert“, zerstört es eine legitime menschliche Änderung.
Darum braucht der Abgleich eine Prioritätsregel. Bei offensichtlichem fehlendem internen Tag kann ein automatische Korrektur okay sein. Bei Kundenzeiten, Preisen, Zahlungen oder Änderungen nach menschlicher Bearbeitung sollte die Ausnahmefall zuerst sichtbar werden.
Logs brauchen zudem Zeitbezug: Welche Version ist jünger? Welche Aktion kam von einem Mitarbeiter? War der Agent währenddessen im reduzierten Betrieb? Diese Informationen entscheiden, ob ein Unterschied Fehler oder aktuelle Wahrheit ist.
Übergabe an Menschen bedeutet hier nicht, den gesamten Workflow manuell zu machen. Es bedeutet, die wenigen nicht eindeutig auflösbaren Differenzen sauber zu routen.
Minimaler Pilot: Tagesabgleich für einen Prozess
Nehmen Sie eine Automation, die täglich 20 bis 200 klare Geschäftsvorgänge erzeugt. Speichern Sie pro Vorgang die erwartete Ziel-ID oder einen stabilen Vorgangsschlüssel (Business Key). Lassen Sie alle 15 Minuten oder am Tagesende einen Abgleich laufen.
Pflanzen Sie Testfehler ein: Löschen Sie einen Testdatensatz, verändern Sie ein Feld, duplizieren Sie einen Vorgang und verzögern Sie bewusst eine Synchronisation. Prüfen Sie, ob das System den echten Fehler findet, aber den normalen Delay nicht unnötig eskaliert.
Messen Sie Anteil Vorgänge mit erfüllter Sollzustand, Anteil fehlender, falscher oder doppelter Einträge, Fehlalarmquote, mittlere Zeit bis zur Erkennung, mittlere Zeit bis zur fachlichen Auflösung und Anteil der Ausnahmefälle mit eindeutigem Verantwortlichen.
Die interessanteste Zahl ist häufig nicht die Anzahl Workflow-Errors. Es ist die Anzahl geschäftlich unvollständiger Fälle, die der Workflow selbst nicht als Fehler gemeldet hat.
Automatisierung endet nicht beim 200 OK. Sie endet, wenn der erwartete Zustand im System und beim Kunden stimmt. Reconciliation ist die Kontrolle, die diesen Unterschied sichtbar macht.
Idempotenz verhindert viele Duplikate. Der Not-Aus begrenzt einen laufenden Fehler. Reconciliation beweist danach, was tatsächlich passiert ist.
Quellen
FAQ
Ist Reconciliation dasselbe wie Logging?
Nein. Logging zeigt, was der Workflow getan hat. Reconciliation vergleicht das beabsichtigte Ergebnis mit dem tatsächlichen Zustand.
Muss jeder Vorgang sofort abgeglichen werden?
Nein. Das Intervall hängt vom Prozess ab. Zu frühe Checks können normale Synchronisationsverzögerungen als Fehler melden.
Sollte die Automation Fehler automatisch reparieren?
Nur bei eindeutig sicheren und reversiblen Abweichungen. Kunden-, Preis- und Zahlungsänderungen brauchen oft menschliche Prüfung.
Braucht Reconciliation AI?
Nicht zwingend. Strukturierte Sollzustands lassen sich oft besser deterministisch prüfen; AI kann bei Erklärung und unstrukturierten Fällen helfen.
Wie hängt Reconciliation mit Idempotenz zusammen?
Idempotenz verhindert doppelte Ausführung; Reconciliation entdeckt unter anderem, wenn Duplikate oder fehlende Ausführungen trotzdem im Zielzustand auftauchen.