AuditCopilot: LLMs zur Betrugserkennung in der doppelten Buchführung

Das Paper, das ich diese Woche lese, ist AuditCopilot: Leveraging LLMs for Fraud Detection in Double-Entry Bookkeeping (arXiv:2512.02726), eingereicht im Dezember 2025 von Kadir, Macharla Vasu, Nair und Sonntag. Es bewegt sich an der Schnittstelle zwischen der Forschung zu LLM-Agenten und finanzieller Compliance: dem Einsatz von Foundation-Modellen zur Erkennung betrügerischer Journalbuchungen in realen Unternehmens-Hauptbüchern. Von allen Papieren auf der Leseliste von Bean Labs ist dies dasjenige, das sich am direktesten mit demselben Rohdatenformat befasst, das uns wichtig ist.

Das Paper

Jede Prüfung eines börsennotierten Unternehmens – vorgeschrieben durch den PCAOB Auditing Standard AS 2401 – muss Journal Entry Testing (JET) beinhalten: systematische Prüfungen des Hauptbuchs auf Einträge, die bei regelbasierten Heuristiken anschlagen. Dabei handelt es sich um Regeln wie „Buchung nach Mitternacht“, „runder Betrag“, „ungewöhnliches Kontenpaar“ oder „Buchung durch einen selten aktiven Benutzer“. Diese Regeln funktionieren, erzeugen aber enorme Mengen an falsch-positiven Ergebnissen: Wirtschaftsprüfer verbringen die meiste Zeit damit, offensichtliches Rauschen zu verwerfen.

AuditCopilot stellt die Frage, ob LLMs diese Regeln ersetzen oder ergänzen können. Das System übergibt jede Journalbuchung – strukturiert als JSON-ähnliches Textfragment mit Feldern für Buchungsdatum, Soll-/Haben-Beträge, Konten-IDs, Steuersätze und eine Reihe vorberechneter binärer Anomalie-Flags – an einen LLM-Prompt, der ein binäres Anomalie-Label und eine natürlichsprachliche Erklärung zurückgibt. Die Autoren benchmarken Mistral-8B, Gemma-2B, Gemma-7B und Llama-3.1-8B sowohl auf einem synthetischen Unternehmens-Hauptbuch als auch auf einem realen anonymisierten Steuer-Hauptbuch und vergleichen sie mit traditionellen JETs und einer Isolation-Forest-Baseline.

Kernideen

• Auf dem synthetischen Datensatz (5.000 Buchungs-IDs, ~1 % echte Anomalierate) erreicht Mistral-8B mit dem vollständigen Prompt eine Präzision von 0,90, einen Recall von 0,98 und einen F1-Score von 0,94 – im Vergleich zur JET-Baseline mit einer Präzision von 0,53, einem Recall von 0,90, einem F1-Score von 0,50 und entscheidend nur 12 falsch-positiven Ergebnissen gegenüber den 942 bei JET.
• Der „vollständige“ AuditCopilot-Prompt enthält nicht nur die Merkmale des rohen Eintrags, sondern auch globale Datensatzstatistiken (Mittelwert, Median, 95. und 99. Perzentil der Beträge) sowie einen vorberechneten Isolation-Forest-Score pro Zeile. Dieses Kontext-Engineering ist die tragende Säule des Systems.
• Auf dem realen Datensatz erreicht Gemma-7B mit dem vollständigen Prompt eine Präzision von 0,89, einen Recall von 0,78 und einen F1-Score von 0,83. Wenn der Isolation-Forest-Hinweis entfernt wird, bricht die Präzision auf 0,14 ein – das LLM allein trägt die Last nicht.
• Die Erklärungen sind der am besten vertretbare Beitrag des Systems: Im Gegensatz zu einem numerischen Anomalie-Score wird jeder markierte Eintrag mit einer schriftlichen Begründung versehen („dieser Betrag überschreitet das 99. Perzentil für dieses Konten-Cluster und wurde außerhalb der Geschäftszeiten gebucht“), die ein Prüfer schnell akzeptieren oder verwerfen kann.
• Keinerlei Fine-Tuning. Alles läuft Zero-Shot oder mit einem kurzen System-Role-Prompt, was gut für die Bereitstellungskosten ist, aber auch bedeutet, dass die Ergebnisse stark von der Prompt-Vorlage abhängen.

Was Bestand hat – und was nicht

Das Ergebnis der Reduzierung falsch-positiver Ergebnisse ist beeindruckend und real. Der Sprung von 942 auf 12 falsch-positive Ergebnisse bei denselben Daten ist die Art von operativem Gewinn, die tatsächlich darüber entscheidet, ob ein Tool in der Praxis eingesetzt wird. Ich glaube an diese Richtung.

Allerdings habe ich ernsthafte Vorbehalte gegenüber dem Design der Evaluierung.

Erstens wurden die Ground-Truth-Labels des synthetischen Datensatzes selbst aus JET-Regeln konstruiert. Die injizierten Anomalien entsprechen genau den Mustern, für deren Erkennung JETs entwickelt wurden. Dass „das LLM JET übertrifft“ auf einem JET-beschrifteten Testset, könnte teilweise widerspiegeln, dass das LLM lernt, dieselben Regeln aus den Kontextstatistiken im Prompt nachzuahmen, anstatt darüber hinaus zu generalisieren.

Zweitens ist die Isolation-Forest-Ablation auf realen Daten in einer Weise vernichtend, die im Paper zu wenig diskutiert wird. Der F1-Score sinkt ohne IF-Scores von 0,83 auf 0,24. Das sagt mir, dass das LLM primär als flexibler Schwellenwert über dem IF-Signal fungiert und nicht als eigenständiger Anomaliedetektor. Das System ähnelt eher einem ML-Ensemble mit einer naturalsprachlichen Hülle als einem „Foundation-Modell, das prüferische Schlussfolgerungen zieht“.

Drittens gibt es nur einen realen Datensatz von einem einzigen Industriepartner. Die Autoren räumen dies ein, aber es bedeutet, dass wir die Generalisierungsfähigkeit über Unternehmensgrößen, Buchhaltungssysteme oder Branchen hinweg nicht beurteilen können.

Viertens vergleicht das Paper mit JETs und einer einzigen ML-Baseline (Isolation Forest). Autoencoder-basierte Anomalieerkennung, XGBoost mit Feature-Engineering und einfache logistische Regression auf IF-Scores fehlen völlig. Der Raum dessen, was hier als „klassisches ML“ gilt, ist sehr eng gefasst.

Die Halluzinationsfrage wird nicht thematisiert. Die Autoren bezeichnen die Erklärungen als einen Schlüsselbeitrag, aber es gibt keine Untersuchung darüber, ob die schriftlichen Begründungen faktisch korrekt oder konsistent mit der binären Vorhersage sind.

Warum das für Finanz-KI wichtig ist

Dies ist das Paper, das dem, was Bean Labs entwickelt, am nächsten kommt. Beancount-Ledger sind doppelte Buchführungssysteme. Jede Transaktion besteht aus einer Reihe von Buchungszeilen. Die Anomalieerkennung über diese Zeilen hinweg – ungewöhnliche Konten, Beträge außerhalb der Norm, unplausible Datums-Muster – ist eine offensichtliche erste Funktion für einen autonomen Finanzassistenten.

Das Ergebnis von AuditCopilot deutet darauf hin, dass der richtige Ansatz für eine Beancount-Prüfung wahrscheinlich nicht darin besteht, „ein LLM mit einer rohen Transaktion zu prompten und zu fragen, ob sie verdächtig ist“, sondern vielmehr darin, „einen leichtgewichtigen statistischen Kontext zu berechnen (Baselines auf Kontenebene, zeitliche Verteilung, Isolation-Forest-Scores) und dem LLM diesen angereicherten Kontext zu geben“. Der Wert des LLM liegt in der Synthese und Erklärung, nicht in der reinen Anomalie-Bewertung.

Die Reduzierung falsch-positiver Ergebnisse ist ebenfalls direkt relevant. Ein Beancount-Audit-Tool, das 942 potenzielle Anomalien pro Durchlauf anzeigt, wird ignoriert werden. Eines, das 12 hochgradig vertrauenswürdige Kandidaten mit Erklärungen liefert, wird verwendet werden. Das ist keine Performance-Metrik – das ist eine Produkt-Metrik.

Die Sicherheitsbedenken beim Rückschreiben, die mir am wichtigsten sind, werden in diesem Paper nicht angesprochen. AuditCopilot liest und markiert nur; es schlägt keine Korrekturen vor und verändert das Hauptbuch nicht. Das ist der richtige Umfang für ein erstes Paper, aber das schwierige Problem für Bean Labs bleibt bestehen: Wenn man eine markierte Anomalie hat, wie entscheidet man sicher, was damit zu tun ist?

Was man als Nächstes lesen sollte

• Understanding Structured Financial Data with LLMs: A Case Study on Fraud Detection (arXiv:2512.13040, ACL 2026) – führt FinFRE-RAG ein, das Retrieval-Augmented In-Context Examples zum gleichen Betrugserkennungsproblem hinzufügt und Benchmarks über vier öffentliche Betrugsdatensätze hinweg durchführt; adressiert direkt die Beschränkung auf einen einzelnen Datensatz von AuditCopilot.
• Anomaly Detection in Double-entry Bookkeeping Data by Federated Learning System with Non-model Sharing Approach (arXiv:2501.12723) – befasst sich mit dem Datenschutz-Constraint, der das Zusammenführen von Hauptbuchdaten über Firmen hinweg verhindert; der föderierte Ansatz ist wahrscheinlich notwendig für jeden produktiven Beancount-Prüfungsdienst, der auf Client-Daten trainieren möchte, ohne diese zu zentralisieren.
• GuardAgent: Safeguard LLM Agents by a Guard Agent via Knowledge-Enabled Reasoning (arXiv:2406.09187) – das Problem der Sicherheitsdurchsetzung, das AuditCopilot bewusst umgeht: Wenn Anomalien markiert sind, wie stellt man sicher, dass ein Rückschreibe-Agent keine Änderungen vornimmt, die Buchhaltungsinvarianten verletzen?