LLMs erreichen 2,3 % bei der Beancount DSL-Generierung: Der LLMFinLiteracy-Benchmark

Dies ist das Paper, auf das ich seit LOG-001 gewartet habe: ein direkter empirischer Test, ob LLMs valide Beancount-DSL-Transaktionen aus natürlichsprachlichen Finanzszenarien generieren können. Figueroa et al. von der Hochschule für Technik und Wirtschaft Berlin präsentieren das, was sie – soweit ich das beurteilen kann, zu Recht – als die erste veröffentlichte Evaluierung von LLMs zur Generierung von Finanztransaktionen im Plain-Text-Accounting bezeichnen. Die kurze Antwort lautet: Sie können es nicht, zumindest nicht zuverlässig, selbst mit Chain-of-Thought-Prompting und der Bereitstellung der tatsächlichen Beancount-Bilanz als Kontext.

Das Paper

Figueroa, Grundmann, Freidank, Löser und Nejdl evaluieren fünf Open-Weight-Modelle der ~7B-Klasse in einem Benchmark mit zwei Aufgaben, den sie LLMFinLiteracy nennen. Aufgabe 1 verlangt von den Modellen, Text-Szenarien zu generieren, die eine bestimmte Liquiditätskennzahl (Current, Quick oder Cash Ratio) beeinflussen würden, basierend auf einer echten Quartalsbilanz eines von fünf DAX-Unternehmen (Airbus, Bayer, Deutsche Telekom, Mercedes-Benz, SAP). Aufgabe 2 verlangt von den Modellen, diese Szenarien in kompilierbare Beancount-Transaktionen zu übersetzen. Der Beancount-Compiler dient dabei als Ground-Truth-Syntaxprüfung; menschliche Fachexperten bewerten die semantische Korrektheit. Das Paper führt eine 12-stufige Fehlertaxonomie über die beiden Aufgaben hinweg ein und nutzt einen 9-stufigen Chain-of-Thought-Prompt, der Regeln der doppelten Buchführung, ein Input/Output-Beispiel und die reale Unternehmensbilanz im Beancount-Format enthält. Die evaluierten Modelle – Llama-3-8B, Qwen-2-7B, Mistral-7B, CodeLlama-7B und CodeQwen-1.5-7B – wurden aufgrund der Sensibilität von Finanzdaten alle On-Premise ausgeführt. Der Korpus umfasst insgesamt 1.500 generierte Samples, wobei 300 stratifizierte Einträge von menschlichen Experten bewertet wurden.

Kernaussagen

• Nur 7 von 300 evaluierten Szenario-Transaktions-Paaren (2,3 %) waren durchgehend korrekt; selbst bei einer Beschränkung auf die drei Allzweckmodelle steigt die Rate nur auf 3,8 %.
• Die beiden besten Modelle, Qwen-2-7B und Mistral-7B, produzieren nur in 21,67 % bzw. 20,00 % der Fälle korrekte Szenarien und nur in 16,67 % bzw. 10,00 % der Fälle korrekte, kompilierbare Transaktionen.
• Code-spezialisierte Modelle (CodeLlama, CodeQwen) erzielten bei beiden Aufgaben 0 %; sie antworteten auf das Prompt-Template mit der wörtlichen Zeichenfolge "Processed — Waiting for next input" und ignorierten die Aufgabe vollständig.
• Die Syntax ist nicht der Flaschenhals: Kein Modell produzierte auch nur einen einzigen Syntaxfehler. Die Fehler liegen vollständig in der buchhalterischen Logik – Saldierungsfehler dominieren bei Qwen-2 (61,67 %) und Llama-3 (38,33 %), während Mistral zumeist Konten referenziert, die in der bereitgestellten Bilanz nicht existieren (45 % Fehler durch unbekannte Konten).
• Ein signifikanter Teil der Transaktionen, die erfolgreich kompilieren, ist semantisch falsch – der Lieblingstrick der Modelle besteht darin, die Verringerung einer Verbindlichkeit als "Verkauf von Schulden" zu bezeichnen, was zwar die Barmittel erhöht, aber aus dem falschen Grund.
• GPT-4o, das als automatisierter Beurteiler eingesetzt wurde, scheiterte daran, Inkonsistenzen in allen 10 ihm gezeigten unsinnigen Szenarien zu erkennen. Dies bestätigt, dass LLM-Selbst-Evaluierung kein zuverlässiger Qualitätsfilter für Buchhaltungsergebnisse ist.
• Modelle kopieren weitgehend das Input/Output-Beispiel im Prompt, anstatt zu generalisieren: Die 7 korrekten Paare ähneln stark der Struktur der bereitgestellten Beispieltransaktion.

Was Bestand hat – und was nicht

Der empirische Kernbeitrag des Papers ist solide. Der Beancount-Compiler ist ein objektives, reproduzierbares Korrektheitskriterium, und die Verwendung realer Unternehmensbilanzen anstelle von Spielzeugdaten erhöht die ökologische Validität. Die hierarchische Fehlertaxonomie ist durchdacht – die Evaluierung beim ersten Fehler zu stoppen, verhindert eine künstliche Aufwertung durch "Teilpunkte" für unbrauchbare Ausgaben.

Dennoch gibt es offensichtliche Einschränkungen, die von den Autoren größtenteils eingeräumt werden. Fünf ~7B Open-Weight-Modelle aus den Jahren 2023–2024 sind nur ein schmaler Ausschnitt der aktuellen Leistungsfähigkeit; GPT-4o und Claude wurden aus Datenschutzgründen ausgeschlossen, was verständlich ist, aber bedeutet, dass die Schlagzeile (2,3 % korrekt) das Potenzial der technologischen Spitze unterschätzt. Die Formeln der Finanzkennzahlen wurden bewusst aus den Prompts herausgehalten, um das inhärente Domänenwissen zu testen – eine methodisch interessante Entscheidung, die die Ergebnisse jedoch unvergleichbar mit jedem System macht, das sinnvollerweise eine Formeldokumentation enthalten würde. Zudem sind 300 menschlich bewertete Proben über fünf Modelle, drei Kennzahlen und fünf Unternehmen bescheiden; die Zellen pro Modell und Kennzahl sind mit 12 Proben zu klein, um starke Rückschlüsse auf die Varianz zu ziehen.

Die interessanteste methodische Lücke ist das Fehlen jeglicher iterativen oder feedbackbasierten Protokolle. Kein Tool-Calling, keine Selbstkorrektur, keine Compiler-Feedback-Schleife – nur One-Shot-Generierung. Da CRITIC (LOG-012) und verwandte Arbeiten zeigen, dass tool-interaktive Verfeinerung die Genauigkeit bei Aufgaben mit verifizierbaren Ergebnissen erheblich verbessert, wäre ein Beancount-Compiler-in-the-Loop-Experiment weitaus informativer in Bezug auf die Einsatzfähigkeit gewesen.

Warum dies für Finanz-KI wichtig ist

Jede Designentscheidung für den Bean Labs Write-Back-Agenten basiert auf Annahmen darüber, was LLMs mit der Beancount DSL leisten können. Dieses Paper ist der erste empirische Ankerpunkt. Die zentralen Ergebnisse sind ernüchternd, aber auch auf nützliche Weise interpretierbar.

Erstens sind die Fehlermodi spezifisch und nicht zufällig. Saldierungsfehler und unbekannte Konten sind die beiden dominanten Probleme, und beide sind mit einer Compiler-in-the-Loop-Feedbackschleife behebbar: Der Beancount-Compiler sagt einem genau, welches Konto unbekannt ist und ob die Transaktion ausgeglichen ist. Eine Agentenarchitektur, die auf der Compiler-Ausgabe iteriert – anstatt einmal zu generieren und dann aufzuhören –, sollte die hier gezeigten One-Shot-Ergebnisse deutlich übertreffen. Zweitens ist die Syntax quasi "gratis". Die Modelle haben die Oberflächengrammatik von Beancount offensichtlich gelernt; sie können nur die finanzielle Absicht nicht zuverlässig in korrekte Kontenbewegungen übersetzen. Diese Unterscheidung ist wichtig dafür, wo man in Prompting und Fine-Tuning investieren sollte. Drittens erhöht die Erkenntnis, dass GPT-4o die Buchhaltungsqualität nicht automatisch bewerten kann, die Messlatte für jedes automatisierte Verifizierungssystem: Man benötigt den Compiler plus Stichproben durch Fachexperten, keinen LLM-Kritiker.

Das Paper bestätigt auch etwas, das ich bereits bei der Arbeit zur Anomalieerkennung (LOG-049) vermutet habe: LLMs, die auf Finanztransaktionen operieren, neigen dazu, zu schnell zu "kompilieren und abzusenden". Die Kategorie "Inkorrekt | Kompiliert" – Transaktionen, die die Syntaxprüfung bestehen, aber semantisch falsch sind – ist genau der Fehlermodus, den eine Sicherheitsleitplanke für Write-Backs abfangen muss. Eine Transaktion kann perfekt ausgeglichen sein und dennoch Einnahmen als Verringerung einer Verbindlichkeit buchen, was durch eine rein syntaktische Prüfung unentdeckt bliebe.

Was man als Nächstes lesen sollte

• AnoLLM: Large Language Models for Tabular Anomaly Detection (OpenReview:7VkHffT5X2, ICLR 2025) – Likelihood-basierte Anomalie-Bewertung als Alternative zum Batch-Erkennungsansatz; lässt sich natürlich mit einem Beancount-Compiler-Signal kombinieren, um strukturell valide, aber statistisch anomale Einträge zu markieren.
• ReDAct: Uncertainty-Aware Deferral for LLM Agents (arXiv:2604.07036) – leitet Entscheidungen mit geringer Konfidenz an ein größeres Modell oder einen Menschen weiter; adressiert direkt die Frage, wann ein Beancount-Write-Back-Agent die Entscheidung an einen Menschen delegieren sollte, anstatt nach einer Compiler-Feedbackschleife fortzufahren.
• CRITIC: Large Language Models Can Self-Correct with Tool-Interactive Critiquing (arXiv:2305.11738, ICLR 2024) – die relevanteste existierende Arbeit für den Aufbau eines Compiler-in-the-Loop-Korrekturagenten auf Basis der in diesem Paper evaluierten Architektur.