KI-Transaktionsmatching: Was sagt der Score?

Du öffnest einen Beleg, und die Software zeigt dir ganz oben eine Zahlung. Der Betrag kommt ungefähr hin. Im Buchungstext stehen vertraute Wörter. Ein Klick würde reichen. Aber was hat das System damit tatsächlich festgestellt?

KI-Transaktionsmatching braucht eine präzisere Antwort als „der Score ist hoch“. Eine sortierte Vorschlagsliste kann dir Arbeit sparen, ohne zu belegen, dass diese Zahlung zu diesem Beleg gehört. Ich möchte lieber eine hilfreiche Auswahl mit einer klaren Entscheidungsgrenze bauen, als aus einer Sortierregel einen unerklärten Prozentwert für Sicherheit zu machen.

Diese Unterscheidung wird mit autonomer Abstimmung wichtiger. Microsoft beschrieb am 23. September 2026 die gebündelte Bearbeitung von Abstimmungsausnahmen in seiner Dynamics-365-Roadmap, die verfügbare und kommende Funktionen umfasst. Quelle: Microsoft. Am selben Tag kündigte Smartstream die autonome Untersuchung und Bearbeitung von Abstimmungsausnahmen mit protokollierten Aktionen an. Quelle: Smartstream.

Meine Frage an solche Systeme ist konkret: Was berechtigt einen Vorschlag dazu, eine gespeicherte Zuordnung zu werden? Eine kleine Norman-Demo macht diese Grenze sichtbar.

Was bewertet KI-Transaktionsmatching eigentlich?

Auch in einem KI-Buchhaltungsprodukt beginnen manche nützlichen Entscheidungen mit einfacher Mathematik. Die Rangfolge in Normans Belegprüfung berücksichtigt die Ähnlichkeit des Betrags, die zeitliche Nähe und gemeinsame Wörter. Diese konkrete Funktion arbeitet deterministisch. Unser lokaler Test ruft kein Sprachmodell auf und führt keine Bankaktion aus.

Wir haben die tatsächliche Produktfunktion mit erfundenen Datensätzen ausgeführt. Der Beleg lautet auf 120 Euro von „Demo Office“. Seine Beschreibung enthält „paper supplies“. Beide vorgeschlagenen Zahlungen haben dasselbe Datum wie der Beleg. Zahlung A beträgt 120 Euro, Zahlung B 122 Euro. Zu Beginn sind beide Zahlungsbeschreibungen allgemein gehalten.

Die Sortierung setzt A an die erste Stelle. Damit erfährst du, wo du zuerst nachsehen solltest. Du erfährst weder, wer die Waren gekauft hat, noch warum ein Zahlungsbetrag vom Beleg abweicht. Unser Artikel zur KI-Bankabstimmung erklärt den Umgang mit Ausnahmen. Hier betrachten wir gezielt die vorgelagerte Frage, wie die Vorschläge ihre Reihenfolge bekommen.

Kann ein anderer Text den besten Vorschlag verändern?

Jetzt bleiben Beträge, Daten und die Menge der Kandidaten unverändert. Nur die Beschreibung von B wird zu „Demo Office paper supplies“. B rückt vor A. Ergänzen wir dieselbe Beschreibung bei A, steht A wieder oben. Die Animation verwendet die berechneten Testergebnisse und zeigt die internen Punkte ausschließlich zur Erklärung.

Alle Beträge, Bezeichnungen und Datensätze der Demo sind erfunden. Du siehst ein kommentiertes lokales Replay der Produktlogik, keine Aufnahme eines Kundenkontos. Auf dem tatsächlichen Prüfbildschirm werden weder diese Punktzahlen noch ein Prozentwert für Sicherheit angezeigt.

Keiner dieser Wechsel beweist, dass der neue Spitzenkandidat richtig ist. Wir haben keine bestätigte Beziehung zwischen Beleg und Zahlung vorgegeben. Das Experiment zeigt lediglich: Der Text kann bei dieser Regel den Unterschied zwischen den beiden Betragsähnlichkeiten überwiegen. Diese Aussage lässt sich reproduzieren. Sie ist wesentlich enger als „die KI hat die richtige Zahlung gefunden“.

Warum ist ein Matching-Score keine Wahrscheinlichkeit?

Die Punkte sind Beiträge zu einer Sortierregel. In diesem Beispiel kann das Ergebnis über 100 liegen. Es als Prozentwert auszugeben, wäre schon deshalb falsch. Auch eine Division durch die maximal mögliche Punktzahl würde lediglich die Skala verändern. Sie liefert keine neue Erkenntnis darüber, wie häufig der erste Vorschlag tatsächlich stimmt.

Eine Wahrscheinlichkeitsaussage braucht überprüfte Ergebnisse. Du könntest beispielsweise einen getrennten Testdatensatz mit bestätigten Zuordnungen verwenden, Vorhersagen nach ihrer angegebenen Sicherheit gruppieren und die Werte mit den tatsächlichen Treffern vergleichen. Das ist ein Vorschlag für eine Evaluation, kein Benchmark, den wir für diesen Artikel durchgeführt haben.

Auch die Erklärung sollte diese Grenze respektieren. „Der Betrag hat zu diesem Vorschlag beigetragen“ bedeutet weniger als „der Betrag ist identisch“. Im Replay erhält auch der ähnliche Betrag Punkte. Hinweise helfen bei der Prüfung, dürfen aber nicht stillschweigend als Gleichheitsnachweis gelesen werden. Dieselbe Trennung zwischen Empfehlung und begründeter Handlung diskutieren wir bei der KI-Vorkontierung.

Was passiert, wenn zwei Zahlungen gleich aussehen?

In einem weiteren Test hatten zwei Kandidaten identische Beträge und Daten, allgemeine Beschreibungen und dieselbe Punktzahl. Die Sortierregel löste den Gleichstand über die Reihenfolge der Beschreibungen auf. Alphabetisch zu sortieren ist ein vernünftiges Mittel für eine stabile Liste. Es belegt nicht, welche Zahlung zu einem Beleg gehört.

Dass Betrag und Datum allein nicht eindeutig sind, zeigt auch eine ausschließlich lesende Aggregatabfrage in Normans Produktion. Unter den importierten Ausgaben fanden wir wiederholte Kombinationen aus absolutem Betrag und UTC-Wertstellungsdatum innerhalb derselben Firma und umgerechneten Währung. Von den nicht als gelöscht markierten Datensätzen mit vorhandener Firma, Betrag und Währung gehörte im untersuchten Bestand ungefähr jeder zehnte zu einer solchen Kombination. Geprüft wurde ein Zeitraum von neunzig Wertstellungstagen, der vor dem 24. September endete. Beschreibungen und einzelne Datensätze wurden nicht abgerufen.

Das Ergebnis zeigt nur, dass Betrag und Datum in diesem Bestand keinen gespeicherten Datensatz eindeutig identifizieren. Es belegt keine doppelten Zahlungen, falschen Verknüpfungen oder Ursachen. Auch wie häufig diese Konstellation in der Belegprüfung erscheint, wissen wir daraus nicht. Produktionsabfrage und fiktiver Test beantworten unterschiedliche Fragen. Zusammen begründen sie einen Test auf Mehrdeutigkeit, ohne einen erfundenen Kundenfehler zu behaupten.

Was bestätigst du bei Norman selbst?

Die untersuchte Norman-Oberfläche zeigt Beschreibung, Datum, Betrag und Hinweise zur vorgeschlagenen Zahlung. Auswahl und Sortierung sind getrennt. Du wählst einen Kandidaten und bestätigst anschließend die Verknüpfung. Beim Wechsel zum nächsten Beleg wird diese Auswahl zurückgesetzt.

Das ist für die Entscheidung aussagekräftiger als ein Sicherheitsabzeichen. Die erste Zeile lenkt deine Aufmerksamkeit. Die ausgewählte Zeile beschreibt dagegen die Beziehung, die du herstellen willst. Sind diese Zustände getrennt, kannst du der Rangfolge widersprechen, ohne gegen die Bedienlogik arbeiten zu müssen.

Eine weitere Grenze gehört dazu: Diese Vorschlagsliste im Frontend ist nicht Normans separater Dienst für automatische Belegzuordnung. Der Test prüft weder diesen Dienst noch eine echte Verknüpfungsanfrage oder ein erfolgreiches Buchhaltungsergebnis. Er zeigt eine Rankingfunktion und den im aktuellen Quellstand vorgesehenen Prüfablauf. Außerdem sortiert eine Liste nur die Kandidaten, die sie erhalten hat. Fehlende Belege an anderer Stelle werden durch eine selbstbewusstere Reihenfolge nicht sichtbar.

Wie sollte ein Agent sortierte Vorschläge verwenden?

Ein Agent braucht dieselbe Unterscheidung wie ein Mensch. Seine Eingabe sollte die Identität jedes Kandidaten, die Gründe für die Rangfolge und offene Abweichungen enthalten. Ein ähnlicher Betrag muss als solcher erkennbar bleiben, auch wenn der betreffende Kandidat an erster Stelle steht.

Ich würde die Freigabe einer Aktion an der konkreten Beziehung ausrichten: welcher Beleg, welche Zahlung, welche stützenden Informationen und welche Regel erlauben die Verknüpfung? Eine Richtlinie kann die automatische Bearbeitung einer überprüften Fallklasse erlauben. Diese Erlaubnis sollte ausdrücklich formuliert und getrennt von der Sortierqualität bewertet werden.

Das ist eine Gestaltungsempfehlung. Unser Replay implementiert kein Freigabesystem für Agenten. Im Artikel über Tool-Ergebnisse für KI-Agenten erklären wir, warum die Bedeutung zurückgegebener Daten entscheidend ist. Hier ist diese Bedeutung bewusst begrenzt: „Prüfe diese Kandidaten“ gibt dem Agenten einen Ausgangspunkt. Die Entscheidung über die Zuordnung bleibt dabei offen.

Was solltest du vor automatischer Abstimmung testen?

Beginne mit Fällen, in denen du nur eine Eigenschaft veränderst. Halte Geldbeträge und Daten fest, während du die Beschreibung variierst. Entferne anschließend passende Wörter, ergänze einen Konkurrenten mit gleichem Betrag oder lasse die richtige Zahlung ganz aus der Kandidatenliste weg. Halte sowohl die Reihenfolge als auch eine eventuell vorgeschlagene Aktion fest.

Im letzten Fall kann „ungeklärt“ genau das gewünschte Ergebnis sein. Ein Sortieralgorithmus produziert auch dann eine erste Zeile, wenn sämtliche verfügbaren Kandidaten falsch sind. Eine Evaluation sollte deshalb prüfen, ob das System aufhören kann, statt ausschließlich zu messen, ob ein bekannter Treffer ganz oben landet.

Teste außerdem unvollständige Datensätze. Ein fehlendes Datum ist etwas anderes als ein weit entferntes Datum. Eine leere Beschreibung belegt nicht, dass zwei Händler verschieden sind. Schreibe vor jedem Test auf, was du erwartest: Soll der Kandidat sichtbar bleiben, soll das System weitere Angaben anfordern oder die Verknüpfung ablehnen? So lässt sich das Ergebnis beurteilen. Andernfalls wirkt eine Vorführung schon deshalb erfolgreich, weil immer eine sauber sortierte Liste erscheint, unabhängig davon, was die vorhandenen Informationen tatsächlich belegen können.

Diese Demo ist absichtlich klein. Du kannst nachvollziehen, warum ein Vorschlag seinen Platz wechselt, ohne einer beeindruckenden Erfolgsquote vertrauen zu müssen. Bevor ein Agent Datensätze selbst verknüpfen darf, möchte ich sehen, dass er einen hilfreichen Hinweis von ausreichenden Belegen unterscheidet. Der erste Platz in einer Liste allein kann diese Unterscheidung nicht liefern.