Intelligent Document Processing im Finanzwesen, durchgängig gedacht

Intelligent Document Processing ist die Pipeline, die ein eingehendes Finanzdokument in strukturierte, validierte Daten verwandelt, auf die ein nachgelagertes System reagieren kann, ohne dass ein Mensch sie eintippt. Sie läuft in vier Stufen ab: das Dokument klassifizieren, die relevanten Felder extrahieren, diese Felder gegen Systeme validieren, die bereits die Wahrheit halten, und das Ergebnis entweder ins Straight-Through-Processing oder in eine Prüf-Queue routen. OCR steckt in Stufe zwei. Es erledigt einen Teil der Arbeit, und selten den Teil, der bricht.

Die meisten Teams lernen das auf die harte Tour. Sie kaufen eine OCR-Engine, richten sie auf einen Stapel Rechnungen und Kontoauszüge, erzielen im Demo 96 Prozent Zeichengenauigkeit und sehen dann zu, wie die echte Pipeline ins Stocken gerät, weil niemand entschieden hat, was mit den anderen vier Prozent passiert. Die Zeichenerkennung war nie der Engpass. Der Engpass ist zu wissen, welches Dokument man in der Hand hält, welche Felder tragend sind und was zu tun ist, wenn das Modell unsicher ist.

Klassifizieren, bevor Sie extrahieren

Der erste Fehler ist, einen einzigen Extraktor über alles laufen zu lassen. Ein Zahlungsavis, ein unterschriebener Kreditvertrag, eine KYC-Nebenkostenabrechnung und ein Depotauszug haben in Layout wie in den benötigten Feldern fast nichts gemeinsam. Ein einziges Modell auf sie alle anzusetzen produziert Brei und verschleiert, schlimmer noch, wo die Genauigkeit versagt.

Klassifizieren Sie zuerst. Ein Dokumentklassifikator ordnet jede eingehende Datei einem Typ zu, und dieser Typ entscheidet, welches Extraktionsschema und welche Validierungsregeln greifen. Das bringt Ihnen zweierlei. Sie können Extraktoren pro Dokumentklasse abstimmen, statt ihr Verhalten zu mitteln, und Sie erhalten eine Genauigkeitszahl pro Klasse, was die einzige Granularität ist, mit der Sie eine Regression zuordnen können, wenn zum Quartalsende das Volumen hochschnellt und etwas verrutscht.

Die Klassifikation hat eigene Fehlerbilder, die es zu benennen lohnt:

• Gemischte PDFs, bei denen eine einzige Datei ein Anschreiben, drei Rechnungen und einen Auszug enthält. Sie brauchen ein Splitting auf Seitenebene, bevor Sie klassifizieren, sonst ist das Typ-Label bedeutungslos.
• Nahezu identische Klassen, etwa eine Gutschrift gegenüber einer Rechnung aus demselben Lieferanten-Template. Genau hier greift ein Klassifikator klammheimlich daneben, und die Kosten schlagen zwei Stufen später auf.
• Neue Typen ohne Trainingsbeispiele. Der Klassifikator sollte “unbekannt” sagen und an einen Menschen routen können, statt die nächstliegende ihm bekannte Klasse zu raten.

Extraktion ist ein Schema-Problem

Sobald Sie den Typ kennen, füllt die Extraktion ein Schema. Für eine Rechnung bedeutet das den Lieferanten, die Steuernummer, die Positionen, die Währung, die Summen und die Zahlungsbedingungen. Die ingenieurstechnische Disziplin besteht darin, Extraktion als Erzeugung typisierter, eingeschränkter Werte zu behandeln, statt als Freitext, den Sie später bereinigen.

Ein Betragsfeld sollte eine Zahl in einer bekannten Währung zurückgeben, nicht die Zeichenkette “USD 1.240,00 ” mit einem angehängten Leerzeichen, das einen nachgelagerten Join zerlegt. Ein Datum sollte zu einem Zeitpunktwert geparst werden, dessen Zeitzonen-Annahme explizit gemacht wird, denn ein um einen Tag falsch gelesenes Wertstellungsdatum verändert die Abstimmung. Wir hängen an jeden extrahierten Wert eine Confidence auf Feldebene, weil die spätere Routing-Entscheidung davon abhängt, und eine Confidence auf Dokumentebene wirft genau die Information weg, die Sie brauchen.

Das Layout zählt mehr als die Modellwahl. Tabellen, die über Seiten umbrechen, Positionen mit verbundenen Zellen, Stempel und Handschrift über gedruckten Formularen sowie gescannte Faxe mit 150 DPI verschlechtern die Extraktion allesamt auf Arten, die ein sauberes PDF nie zeigt. Bauen Sie das Eval-Set aus den hässlichen echten Dokumenten, nicht aus den sauberen, die der Anbieter geschickt hat, sonst beschreibt Ihre Genauigkeitszahl eine Grundgesamtheit, die Sie nie verarbeiten werden.

Validierung ist der Ort, an dem sich Finance-IDP bezahlt macht

Ein Feld kann korrekt extrahiert und trotzdem fachlich falsch sein. Die Validierung ist die Stufe, die das abfängt, und sie ist es, die eine Pipeline in Finanzqualität von einem Demo trennt. Extrahierte Werte werden gegen Systeme geprüft, die bereits autoritative Daten halten:

• Der Lieferant auf einer Rechnung wird per Entity Resolution zu einem Datensatz im Lieferantenstamm aufgelöst, nicht per Fuzzy-String-Match, der “ACME Corp” mit “ACME Corporation Ltd” paart und das falsche Bankkonto bezahlt.
• Positionen und Summen stimmen rechnerisch überein, und eine Summe, die sich nicht aus ihren Positionen ergibt, wird markiert, bevor sie das Hauptbuch erreicht.
• Eine Rechnung wird dort, wo ein Drei-Wege-Abgleich (three-way matching) gilt, gegen ihre Bestellung und ihren Wareneingang gematcht, und die Toleranzen dieses Abgleichs sind konfigurierbar, denn eine Rundungsdifferenz von zwei Cent sollte keine Zahlung stoppen, während eine Lücke von zweitausend Dollar es sollte.
• Bankdaten werden gegen den hinterlegten Datensatz sowie gegen Sanktions- und Betrugsregeln geprüft, da eine geänderte Kontonummer bei einem bekannten Lieferanten eines der häufigsten Signale für Zahlungsbetrug ist.

Ein Validierungsfehler ist ein Routing-Signal, wer ihn also unterdrückt, hebt den Sinn der Stufe auf. Jeder extrahierte Wert trägt seine Herkunft (Lineage) zurück zur Seite, zur Region und zur Modellversion, die ihn erzeugt hat, sodass Sie, wenn ein Controller eine Zahl anzweifelt, zeigen können, woher sie stammt. Dieser Prüfpfad verdient seinen Platz. Unter den meisten Finanzkontroll-Regimen ist er der Unterschied zwischen einer Pipeline, die Sie in Produktion bringen können, und einer, die ein Prototyp bleibt.

Routing, Straight-Through und die Prüf-Queue

Die letzte Stufe entscheidet über das Schicksal jedes Dokuments. Wenn jedes tragende Feld die Extraktion oberhalb seines Schwellenwerts durchlaufen und die Validierung bestanden hat, geht das Dokument straight through, im Zielsystem verbucht ohne menschliche Berührung. Fiel ein Feld unter den Schwellenwert oder scheiterte an einer Validierungsregel, wird es in eine Prüf-Queue geroutet, mit hervorgehobenen Low-Confidence-Feldern und angezeigter Quellregion, sodass ein Prüfer in Sekunden bestätigt, statt das Ganze neu einzutippen.

Zwei Design-Entscheidungen bestimmen, ob das in Produktion funktioniert:

• Schwellenwerte werden pro Feld aus einem gelabelten Eval-Set festgelegt und so justiert, dass das Volumen der Prüf-Queue zum False-Positive-Budget passt, das das Finanzteam besetzen kann. Legen Sie sie nach Bauchgefühl fest, und Sie überfluten entweder die Queue oder lassen schlechte Daten stillschweigend durch. Beides untergräbt das Vertrauen in die Pipeline, und das Zweite ist weit teurer.
• Korrekturen der Prüfer fließen als gelabelte Daten zurück. Jede menschliche Korrektur ist ein Trainingsbeispiel, und eine Pipeline, die sie einfängt, verbessert sich dort, wo sie am schwächsten war, statt still zu driften. Beobachten Sie die Straight-Through-Rate pro Dokumentklasse über die Zeit; eine fallende Rate ist meist Drift, eine neue Dokumentvariante oder eine geänderte Vorlage stromaufwärts, und Sie wollen erkennen, welches davon, bevor das Quartalsende kommt.

Betreiben Sie es so, und das Prüfteam schrumpft von Menschen, die jedes Dokument eintippen, zu Menschen, die über den Bruchteil urteilen, den die Pipeline markiert. Der Erfassungsjob verschwindet. Der Urteilsjob bleibt, und das ist der richtige Platz für einen Menschen.