Unsere Lead-Agent-Demo bereitet ein Briefing für das Erstgespräch mit einem fiktiven Interessenten vor. Der Interessent gleicht jede Woche 3.000 Abonnements zwischen HubSpot und Stripe ab, hat in der Vorwoche 240 Abweichungen gefunden und möchte für eine Person aus dem Operations-Team einen Abweichungsbericht mit reinem Lesezugriff.
Ein gutes Briefing bereitet das erste Gespräch vor. Den Abgleich löst es nicht. Um diese Grenze greifbar zu machen, haben wir den Abgleich selbst als separates geprüftes Beispiel gebaut. Es ruft kein Modell auf.
Alles Folgende nutzt einen konstruierten Datensatz mit bekannten Antworten. Es gibt keine Live-Verbindung zu HubSpot oder Stripe.
Zuerst den Vergleichsvertrag festlegen
Die eigentliche Schwierigkeit beim Abgleich liegt in der Entscheidung, was „dasselbe“ bedeutet. Das Beispiel legt seinen Vertrag ausdrücklich fest:
- Zeilen werden exakt über eine stabile Abonnement-ID verknüpft, ohne unscharfe Zuordnung;
- beide Seiten müssen denselben Monatszeitraum beschreiben;
- Beträge sind EUR, als nicht negative, sichere Ganzzahlen in Cent;
- Status stammen aus einem vereinbarten Vokabular:
active,paused,cancelled,past_due.
Das sind normalisierte Vergleichsfelder, keine Rohschemata der Anbieter. In einem echten System muss jemand entscheiden, ob ein Betrag Steuern, Rabatte, anteilige Abrechnung und Erstattungen enthält und wie die Status jedes Tools auf das gemeinsame Vokabular abgebildet werden. Diese Entscheidung gehört der verantwortlichen Person aus Finanzen oder Operations beim Kunden, nicht einem Modell.
Jedes Paar erhält ein Ergebnis und seine Gründe
Die Engine indexiert beide Seiten nach Abonnement-ID und weist jeder ID eines von drei Ergebnissen zu:
| Ergebnis | Wann | Betragsdifferenz |
|---|---|---|
match |
Beide Zeilen gültig, gleicher Betrag und Status | 0 |
discrepancy |
Betrag oder Status weicht ab, oder eine Seite fehlt | Bekannt, oder null, wenn eine Seite fehlt |
review |
Doppelte ID, abweichender Zeitraum, nicht unterstützte Währung, ungültiger Betrag, unbekannter Status | null |
Der Kern des Vergleichs ist kurz. Vereinfacht aus der Demo:
if (reasons.length) outcome = "review";
else {
amountDeltaCents = billing.amountCents - crm.amountCents;
if (!Number.isSafeInteger(totalDeltaCents + amountDeltaCents))
throw new Error("Amount total exceeds safe integer range");
if (amountDeltaCents) reasons.push("amount_mismatch");
if (crm.status !== billing.status) reasons.push("status_mismatch");
outcome = reasons.length ? "discrepancy" : "match";
}
Zwei Entscheidungen sind hier wichtig. Ein fehlendes Gegenstück wird als Abweichung markiert, sein Geldwert bleibt aber unbekannt: Wir erfinden keinen Betrag für eine Zeile, die nicht existiert. Und würde die laufende Summe den Bereich sicherer Ganzzahlen verlassen, bricht der Lauf ab, statt zu runden.
Jedes Ergebnis behält seine Quellzeilen und Begründungscodes, sodass eine prüfende Person sieht, warum ein Paar markiert wurde, ohne etwas erneut auszuführen.
Gegen Antworten prüfen, die die Engine nie sieht
Ein Abgleich, der 240 Abweichungen meldet, wirkt richtig, wenn man 240 erwartet hat. Das ist kein Test. Wir brauchten für jede Zeile eine unabhängige Antwort.
Der Generator erzeugt 3.000 CRM-Zeilen, 3.000 Abrechnungszeilen und ein separates Manifest der erwarteten Ergebnisse:
| Erwarteter Fall | Anzahl |
|---|---|
| Übereinstimmende Abonnements | 2.730 |
| Betragsabweichungen von +5,00 € | 180 |
| Statusabweichungen | 60 |
| Nicht unterstützte Währung (USD), zur Prüfung | 30 |
Die Engine liest das Manifest nicht. Ein Verifier vergleicht anschließend jedes Paar: Klassifizierung, Begründungscodes und Betragsdifferenz je Paar sowie die belegte Summe.
Auf diesem Datensatz klassifiziert der Lauf alle 3.000 Paare wie erwartet. Er findet alle 240 eingebauten Abweichungen ohne falsch positive und ohne übersehene Fälle, und jeder Begründungscode stimmt. Die belegte Betragsdifferenz beträgt 900,00 € bei null Cent Fehler. Der Vergleich selbst läuft in Millisekunden; der Build erzeugt und prüft ihn jedes Mal neu.
Was die Zahlen bedeuten
Die 900 € sind eine Betragsdifferenz, die untersucht werden muss. Sie sind kein zurückgewonnener Umsatz und keine Einsparung für einen Kunden.
Sie decken auch nicht alles ab. Die 30 USD-Paare bleiben ungeklärt in der Prüfwarteschlange und sind von der belegten Summe ausgenommen, weil der Vertrag keine Regel zur Währungsumrechnung enthält. Sie zu einem angenommenen Kurs umzurechnen, ergäbe eine glattere und weniger ehrliche Summe.
Die öffentliche Seite veröffentlicht die Zusammenfassung, vier Beispiele mit Quellenbezug, die Prüfwarteschlange mit 30 Einträgen und offenen Entscheidungen sowie eine Belegdatei mit jeder Eingabezeile, jedem erwarteten Fall und jedem tatsächlichen Ergebnis. Jede Person kann die Klassifizierungen ohne unseren Quellcode nachprüfen.
Warum kein Modell?
Eine Verknüpfung über eine exakte ID und die Subtraktion von Ganzzahlen sind Aufgaben, bei denen ein Modell Kosten, Latenz und eine neue Fehlerquelle hinzufügt, ohne Urteilsvermögen beizutragen. An anderer Stelle derselben Geschichte setzen wir Modelle ein: Ein Entscheidungsmodell wählt den Kontext für das Erstgespräch aus, und ein generatives Modell entwirft das Lead-Briefing. Keines von beiden soll Finanzarithmetik bestätigen.
Wo ein Modell später helfen könnte, ist die Arbeit rund um den Vergleich: eine Gruppe von Prüffällen erklären oder Fragen an die Person entwerfen, die für die Statuszuordnung verantwortlich ist. Das wäre eine separate, gemessene Ergänzung, kein Ersatz für die deterministische Prüfung.
Was das belegt und was nicht
Null Fehler belegen hier, dass diese Implementierung ihre eigene kontrollierte Prüfung auf einem konstruierten Datensatz mit festgelegten Regeln besteht. Sie belegen keine Genauigkeit im Produktivbetrieb, keine robuste Zuordnung von Entitäten, keine korrekte Auslegung der Regeln eines Kunden, keine Akzeptanz durch prüfende Personen, keine verkürzte Untersuchungszeit und keine Einsparungen.
Für einen echten Piloten ist das nützliche Versprechen ein Prozess:
- Die Vergleichsregeln mit den Personen vereinbaren, die für sie verantwortlich sind.
- Die Implementierung gegen einen freigegebenen Referenzdatensatz prüfen, einschließlich repräsentativer Ausnahmen.
- Mehrdeutige Fälle sichtbar halten, statt sie in eine Summe zu zwingen.
- Messen, wie viel Untersuchungsarbeit für das Team bleibt.
Erst nach diesen Schritten kann jemand eine Aussage über Korrektheit oder Wirtschaftlichkeit treffen.
Sie können das Abgleichsbeispiel ansehen und seine Belege herunterladen. Wenn Ihr Team jede Woche Datensätze zwischen zwei Systemen abgleicht, sind ein Beispielexport und Ihre aktuellen Zuordnungsregeln ein guter Ausgangspunkt für ein Gespräch über einen Piloten.