Der Großteil der Bankabstimmung sollte nie ein Modell berühren. Eine Bankzeile und eine Buchung, die in Betrag, Datum und Referenz übereinstimmen, sind dasselbe Ereignis, und Regeln paaren sie in Millisekunden. Reservieren Sie das LLM für die Ausnahmen: die wenigen Prozent an Zeilen, in denen Beträge aggregiert sind, Referenzen fehlen und ein Zahlername im Freitext Ihr einziger Anhaltspunkt ist.
Bankabstimmung ist ein Matching-Problem, und der Großteil davon ist wirklich einfach. Automatisierung verdient ihren Platz beim Rest, weshalb der Reflex, ein Modell auf die gesamte Datei anzusetzen, der teure Fehler ist. Sie nehmen eine Aufgabe, die ein Hash-Join in Millisekunden löst, verpacken sie in ein probabilistisches System, das pro Aufruf Geld kostet, driftet und sich einem Controller nicht erklären kann, und handeln sich einen Prüfaufwand für Matches ein, die nie in Frage standen. Das Modell sollte eine Zeile erst dann sehen, nachdem die deterministische Schicht bei ihr aufgegeben hat.
Der deterministische Kern bewältigt das Volumen
Beginnen Sie damit, beide Seiten als Feeds zu behandeln, die vor dem Aufeinandertreffen bereinigt werden müssen. Kontoauszüge kommen als MT940, BAI2 oder CAMT.053 an; das Ledger stammt aus Ihrem ERP. Normalisieren Sie Beträge und Vorzeichen, parsen Sie Valutadaten gegen Buchungsdaten und reduzieren Sie das Referenzfeld auf die Kennungen, die tatsächlich Bedeutung tragen: Rechnungsnummern, End-to-End-IDs, den strukturierten Verwendungszweck des Zahlers. Das ist unglamouröse Klempnerei und entscheidet über alles Nachgelagerte. Ein Referenz-Parser, der eine führende Null falsch liest, produziert Breaks, die keine Matching-Logik mehr auffangen kann.
Matchen Sie dann in Stufen, den stärksten Schlüssel zuerst:
- Exaktes Match über eine eindeutige Referenz plus Betrag. Das klärt den Großteil der sauberen Firmenzahlungen und braucht kein Scoring.
- Betrag und Valutadatum innerhalb eines Toleranzfensters, geblockt nach Kontrahentenkonto, für Zeilen, bei denen die Referenz fehlt, die Zuordnung aber eindeutig ist.
- Many-to-One und One-to-Many: eine einzelne Bankgutschrift, die mehrere Rechnungen begleicht, oder eine Sammelzahlung, aufgeteilt über mehrere Buchungen. Lösen Sie diese als Subset-Sum über eine begrenzte Kandidatenmenge, nicht indem Sie ein Modell bitten, Zahlen zu addieren.
Alles, was eine Stufe paart, wird automatisch festgeschrieben und mit der Regel protokolliert, die die Entscheidung getroffen hat. Was alle Stufen überlebt, ist die Exception-Queue. Halten Sie diese Queue klein und ehrlich; wenn eine Regel Dinge paart, die sie nicht paaren sollte, verstecken Sie Fehler, statt abzustimmen. Ein falsches Match, das zwei unabhängige Ereignisse gegeneinander aufrechnet, ist schlimmer als ein Break, denn ein Break wird angeschaut, ein schlechtes Match nicht.
Das LLM arbeitet die Ausnahmen ab, als Vorschlagender
Die Ausnahmen sind der interessante Teil, und sie sind gerade deshalb interessant, weil das Signal Sprache ist. Eine Überweisung kommt mit “Zahlung betr. die Lieferung im März, abzüglich der besprochenen Gutschrift” und ohne Rechnungsnummer. Ein Kunde bezahlt drei Rechnungen in einer Summe und rundet ab. Der Name eines Kontrahenten auf dem Auszug ist ein Handelsname, der in Ihrem Ledger nie auftaucht. Regeln können aus einem Verwendungszweckfeld keine Absicht herauslesen. Ein Modell kann das, wenn Sie einschränken, was Sie von ihm verlangen.
Geben Sie dem Modell eine eng umrissene Aufgabe. Präsentieren Sie ihm für eine ungematchte Bankzeile eine Shortlist von Kandidaten-Buchungen, die ein günstiger Retrieval-Schritt bereits nach Betragsbereich, Datumsfenster und unscharfem Kontrahenten gefiltert hat, und bitten Sie es, sie zu ranken und das Match gegen konkrete Felder zu begründen. Lassen Sie es keinen Kontrahenten erfinden, keinen Betrag anpassen und nicht über die Kandidatenmenge hinausgreifen. Sein Output ist ein Vorschlag mit einem Confidence-Score und der genutzten Evidenz, mehr nicht. Ein hoher Score über Ihrem Schwellenwert kann automatisch festgeschrieben werden; das mittlere Band wird an einen Menschen geroutet, mit der Begründung des Modells bereits angehängt; ein niedriger Score bleibt ein Break.
Zwei Disziplinen bewahren das davor, zu verrotten:
- Ein gelabeltes Eval-Set aus echten historischen Ausnahmen mit bekannt-korrekten Zuordnungen, das bei jeder Prompt- oder Modelländerung läuft und auf Precision an Ihrem gewählten Schwellenwert bewertet wird. Sie verwalten ein False-Positive-Budget, also beobachten Sie die Matches, die es festschreibt, nicht nur die, die es verpasst.
- Point-in-Time-Korrektheit. Wenn Sie das Eval erneut abspielen, füttern Sie das Modell nur mit dem, was am Abstimmungsdatum bekannt war. Eine offene Rechnung, die später storniert wurde, muss offen aussehen, sonst leckt Ihr Test die Zukunft und schönt den Score.
Die Kontrahenten-Auflösung liegt unter beiden Schichten. Ob eine Regel auf die Kontonummer blockt oder das Modell über einen Namen argumentiert, “ACME LTD”, “Acme Limited” und “ACME (UK)” müssen zuerst zu einer Entität kollabieren, was eine Entity-Resolution-Aufgabe ist, die es sich lohnt, einmal zu erledigen und überall wiederzuverwenden.
Der Audit-Trail ist das Deliverable
Ein Controller unterschreibt keine Match-Rate. Er unterschreibt die Fähigkeit, für jede Zuordnung beantworten zu können, warum das System sie für richtig hielt. Bauen Sie den Trail also als primären Output, nicht als etwas, das Sie anschrauben, sobald das Matching funktioniert. Jedes festgeschriebene Match trägt die beiden Quelldatensätze, die Stufe oder das Modell, das es vorgeschlagen hat, die verglichenen Felder, den Score, falls es einen gab, und den Menschen, der es bestätigt hat, wenn ein Mensch es tat.
Dieser Datensatz ist es, der die Automatisierung zum Quartalsende und im Audit verteidigbar macht. Er macht das Modell auch sicher erweiterbar, denn wenn ein Match falsch ist, sehen Sie genau, welches Feld welche Schicht in die Irre geführt hat, und beheben die Ursache, statt an einem Prompt herumzustellen. Die Lineage von der Bankzeile über die Buchung bis zur Entscheidung, die sie verbunden hat, ist das, was Sie tatsächlich bauen. Das Matching ist nur, wie Sie sie befüllen.
Halten Sie die Trennung sauber, und das System bleibt günstig und erklärbar: Regeln klären das Volumen ohne Kosten pro Aufruf und mit einer Regel, auf die Sie zeigen können, das Modell behandelt nur, was wirklich gelesen werden muss, und nichts wird festgeschrieben ohne einen Datensatz, hinter den sich ein Mensch stellen kann. Kehren Sie diese Trennung um, und Sie bezahlen ein Modell fürs Rechnen, während ein Controller genau das verliert, wofür er gekommen ist.
Häufige Fragen
Sollte ein LLM Transaktionen matchen?
Nein, jedenfalls nicht den Großteil. Das Matching über Betrag, Datum und Referenz ist deterministisch und sollte als Regelwerk gegen einen Index laufen. Reservieren Sie das Modell für die Exception-Queue, wo die Evidenz ein Namensstring oder eine Zahlungsnotiz ist, die Regeln nicht parsen können.
Wie halten Sie die Matches eines LLM auditierbar?
Behandeln Sie das Modell als Vorschlagenden, nicht als Entscheider. Es schlägt ein Match mit einem Confidence-Score und den herangezogenen Feldern vor; die Zuordnung wird erst durch einen Regel-Schwellenwert oder einen Menschen festgeschrieben, und sowohl der Vorschlag als auch die Entscheidung werden mit den zugehörigen Quelldatensätzen in den Trail geschrieben.
Mit welcher Break-Rate sollten wir nach der Automatisierung rechnen?
Das hängt vollständig von Ihrer Datenqualität und Referenzdisziplin ab, also begegnen Sie jeder pauschalen Zahl mit Skepsis. Messen Sie Ihre eigene Straight-Through-Rate an einem gelabelten Sample vor und nach der Einführung und verfolgen Sie die Exception-Queue über ein volles Quartalsende hinweg, nicht in einer ruhigen Woche.