Spesen- und Rechnungsprüfung mit KI automatisieren

Die Spesenprüfung war schon immer eine Stichprobenprüfung, weil es nie bezahlbar war, jeden Beleg von Hand zu prüfen. KI hebt diese Einschränkung auf. Man bewertet jede Position auf Richtlinienverstöße, Dubletten und Betrugssignale und leitet dann nur die priorisierten Ausnahmen an eine prüfende Person weiter. Aus der Prüfung wird eine vollständige Abdeckung der Grundgesamtheit mit einer menschlichen Warteschlange obendrauf statt einer Fünf-Prozent-Stichprobe.

Man stelle sich den alten Prozess vor. Eine prüfende Person zieht fünf Prozent der Belege, gleicht Quittungen mit der Richtlinie ab, überfliegt ein paar Beträge und winkt den Rest per Rückschluss durch. Das vollständige Scoring verändert die Ökonomie, aber es verändert nicht, wo die Schwierigkeit sitzt. Die Eingaben kommen als fotografierte Quittungen, PDF-Rechnungen, Feeds der Kartennetzwerke und Freitextbeschreibungen an, und keine davon ist sich einig, wie der Name eines Händlers geschrieben wird. Macht man bei Extraktion und Entity Resolution einen Fehler, erbt jedes nachgelagerte Flag diesen Fehler. Also beginnt die Arbeit dort und nicht beim Modell.

Extraktion und Entity Resolution kommen zuerst

Jeder Beleg muss zu einem Satz von Feldern werden, mit denen man argumentieren kann: Betrag, Währung, Datum, Händler, Kategorie, Steueranteil, Zahlungsmittel, Mitarbeitende, Kostenstelle. Quittungen sind das chaotische Ende. Ein zerknitterter, schräg fotografierter Restaurantbeleg liefert eine Summe, ein Trinkgeld, eine Steuerzeile und ein Datum, und jedes davon kann um eine Ziffer falsch gelesen werden. Man extrahiert mit Konfidenzwerten pro Feld und behandelt Beträge mit geringer Konfidenz als ungeklärt, statt ihnen stillschweigend zu vertrauen. Ein falscher Betrag, der wie ein richtiger aussieht, ist der Fehlermodus, der teuer wird.

Die Händleridentität ist das schwierigere Problem. “AMZN Mktp DE”, “Amazon.de” und “Amazon EU Sarl” auf einer Rechnung sind für Prüfzwecke ein Lieferant und drei Zeichenketten auf dem Papier. Erst die Entity Resolution gegen eine kanonische Lieferanten- und Händlertabelle erlaubt es, eine Kartenfeed-Zeile mit ihrer Quittung und mit der letztlichen Rechnung zu vergleichen. Ohne sie fallen sowohl die Dublettenerkennung als auch der Three-Way-Abgleich auseinander, weil der Join-Schlüssel ein Name ist, den niemand standardisiert hat.

• Die Merchant Category Codes der Kartennetzwerke liefern eine Kategorie, die man nicht ableiten musste, sowie einen Gegencheck gegen die vom Mitarbeitenden angegebene Kategorie.
• Die letzten vier Kartenziffern und Autorisierungszeitstempel erlauben es, eine Quittung an eine konkrete Transaktion zu binden, statt aus Betrag und Datum zu raten.
• Währung und FX-Datum sind wichtig: Ein zum Kurs des falschen Tages umgerechneter Beleg ist ein echtes Leck, und man kann es erst erkennen, sobald das Datum vertrauenswürdig ist.

Richtlinienverstöße sind Regeln, keine Modelle

Das meiste, was eine Spesenprüfung aufdeckt, ist deterministisch. Tagegeld überschritten, Alkohol dort geltend gemacht, wo er nicht zulässig ist, ein Hotel über dem Städtelimit, ein Taxi an einem Tag geltend gemacht, an dem der Mitarbeitende auch Kilometergeld abgerechnet hat, eine fehlende Quittung oberhalb des Schwellenwerts, Vorsteuer auf eine nicht erstattungsfähige Kategorie zurückgeholt. Das sind Regeln, die gegen saubere Felder laufen. Man sollte nicht zu einem Modell greifen, wo eine Regel korrekt und gegenüber dem Mitarbeitenden, dessen Beleg man abgelehnt hat, erklärbar ist.

Die technische Disziplin besteht darin, die Regel-Engine ehrlich zu halten, während sich die Richtlinie ändert. Limits verschieben sich, Kategorien kommen hinzu, ein Land ändert sein Tagegeld quartalsweise. Man versioniert das Regelwerk und bewertet jeden Beleg gegen die zum Transaktionsdatum geltende Richtlinie, nicht gegen die heute geltende. Bewertet man die Spesen des letzten Quartals unter den Limits dieses Quartals, erzeugt man Verstöße, die es nie gab. Das ist ein Problem der Point-in-Time-Korrektheit, dasselbe, das Feature-Pipelines beißt, und es taucht hier in dem Moment auf, in dem jemand zum Quartalsende eine frühere Periode prüft.

Auch Regeln brauchen ein Budget für False Positives. Eine Limitüberschreitung von elf Cent ist technisch ein Verstoß und praktisch Rauschen. Man setzt pro Regel Wesentlichkeitsschwellen, unterdrückt triviale Verstöße und behält sie im Audit-Trail, damit eine prüfende Person sie dennoch sehen kann, falls sich ein Muster abzeichnet. Das Ziel ist eine Warteschlange, die ein Mensch tatsächlich abarbeiten kann.

Dubletten und Betrug brauchen Scoring – und ein Gedächtnis für das Geschehene

Dubletten sind die ertragreichste Kategorie und diejenige, die reine Regeln verfehlen. Dasselbe Abendessen zweimal eingereicht, einmal von der Quittung und einmal vom Kontoauszug der Karte. Eine Rechnung, die auf der Bestellposition und dann noch einmal als Einzelfall bezahlt wird. Ein Auftragnehmer, der dieselbe Arbeit über zwei Monate hinweg mit leicht verschobenen Daten abrechnet. Exact-Match-Deduplizierung fängt die trägen Fälle. Der Rest braucht Fuzzy-Matching:

• Blocke Kandidaten nach Betragsband, Datumsfenster und aufgelöstem Lieferanten, damit du nicht jeden Beleg mit jedem anderen vergleichst.
• Bewerte jedes Paar anhand des normalisierten Betrags, der zeitlichen Nähe, der Händleridentität und gemeinsamer Karten- oder Rechnungskennungen.
• Markiere Paare oberhalb eines Distanzschwellenwerts und gewichte jüngere Einreichungen desselben Mitarbeitenden stärker.

Das Betrugs-Scoring sitzt obendrauf. Runde Beträge, die sich knapp unter Genehmigungsschwellen häufen, ein Anstieg der Belege zum Quartalsende, Quittungen, deren ausgewiesene Steuer sich nicht mit der ausgewiesenen Summe abgleichen lässt, Bild-Metadaten, die besagen, dass das Foto nach der behaupteten Transaktion aufgenommen wurde, oder dasselbe Quittungsbild, das über zwei Belege hinweg wiederverwendet wird. Wo bestätigte Betrugsfälle vorliegen, hilft überwachtes Scoring; wo nicht, erledigt die Ausreißererkennung gegen die eigene Historie eines Mitarbeitenden und einer Kostenstelle den Großteil der Arbeit. So oder so priorisiert man nach erwarteter Rückholung, nicht nach roher Anomalie, sodass die Prüf-Warteschlange danach geordnet ist, was sich zu verfolgen lohnt.

Zwei Dinge halten die Flags über die Zeit verteidigbar. Erstens ein Audit-Trail: Jedes Flag protokolliert die Felder, auf die es angesprungen ist, die Richtlinienversion, den Schwellenwert und den Modell-Score, sodass ein abgelehnter Mitarbeitender eine Begründung und eine prüfende Person eine Lineage erhält. Zweitens Drift-Monitoring. Ausgabenmuster bewegen sich mit der Reiserichtlinie, dem Personalbestand und dem Kalender, und ein im Januar justierter Schwellenwert löst bis Juni klammheimlich zu oft oder zu selten aus. Man hält ein Eval-Set aus entschiedenen Belegen zurück, verfolgt darauf monatlich Precision und Recall und kalibriert neu, bevor die Warteschlange entweder überläuft oder verstummt. Ein Modell, das niemand nachprüft, ist ein Modell, das schon aufgehört hat, zu dem Geschäft zu passen, das es prüft.