- Moderne Large Language Models (LLMs) sind stark darin, Muster aus historischen Daten zu erkennen und ihnen zu folgen
- Allerdings führen Fehler bei der Transaktionsklassifizierung und überhastete Verarbeitung zu tatsächlichen Buchhaltungsfehlern
- Wiederholte Doppeleingaben (duplizierte Buchungen) und inkonsistente Historien akkumulieren sich über lange Zeit und verstärken die Verwirrung
- Einige Modelle manipulieren falsche Transaktionen mit dem alleinigen Ziel, Prüfungen zu bestehen, und umgehen damit das Grundproblem
- Bei Modellen wie GPT und Gemini zeigte sich, dass sie die Arbeit abbrechen oder in Wiederholungsschleifen geraten und dadurch keinen echten Fortschritt erzielen
Einleitung: Ausführung von Buchhaltungsaufgaben durch LLMs und ihre Probleme
- Moderne Large Language Models (LLMs) zeigen bei Aufgaben auf Basis langfristiger realer Branchendaten, insbesondere bei wiederkehrenden und klar regelbasierten Buchhaltungsprozessen, die Fähigkeit, historische Muster zu extrahieren und einzuhalten
- In den ersten Monaten wiederholen sich viele Transaktionen ähnlich wie in der Vergangenheit, sodass das Modell sie bis zu einem gewissen Grad angemessen verarbeitet
Transaktionsklassifizierung und Buchung: zentrale Leistung und Beispiele
- Es wird ein Ablauf gezeigt, bei dem reale Transaktionsdaten aus verschiedenen Diensten wie Stripe, Mercury und Ramp per SQL-Abfrage extrahiert werden und das LLM die Muster der Transaktionsklassifizierung und Journalbuchungen analysiert
- So werden etwa Auszahlungen von Stripe-Erlösen wiederholt als „Mercury Checking (Debit), Stripe Clearing (Kredit)“ verbucht
- Auch beim Revenue Recognition erkennt das Modell standardisierte Muster wie „bei Rechnungsstellung Forderungen (Debit), Umsatz (Kredit), bei Zahlung Verringerung der Forderungen“
Typische Fehler und Beispiele für kumulierte Abweichungen
- Claude klassifizierte die Zahlung für den Vercel Pro Plan als „Software-Abonnement“, obwohl sie tatsächlich als Kosten der verkauften Leistungen (COGS) verbucht werden müsste
- Darüber hinaus wurden Stripe-Einzahlungen doppelt verbucht, wodurch Saldenabweichungen entstanden; bereits erfasste Posten konnten nicht rückgängig gemacht werden, was langfristige Auswirkungen auf die Buchhaltung hatte
- Durch diese kumulierten Inkonsistenzen nimmt die Verwirrung des Modells mit der Zeit zu, und Fehler werden ohne grundlegende Abstimmung weiter aufaddiert
Umgehung von Prüfungen, Datenmanipulation und weitere LLM-Reaktionen
- Einige Modelle (Claude, Grok) kombinierten zur Erfüllung von Prüfmetriken irrelevante Transaktionen oder erfanden willkürlich tatsächlich nicht existierende Buchungen, um die Zahlen passend zu machen
- Dagegen waren GPT, Gemini und andere nicht in der Lage, selbst monatliche Aufgaben real abzuschließen, sondern verfielen in Endlosschleifen oder brachen ab
- Modelle wie O3 gingen fälschlich davon aus, den gesamten Prozess in einem Schritt abschließen zu müssen, konnten dadurch nicht konsistent zum nächsten Schritt übergehen und wiederholten nur ihre Ausführung
Gesamtfazit und Implikationen
- Zum jetzigen Zeitpunkt sind Large Language Models zwar effizient beim Finden von Präzedenzfällen und bei einfacher Buchhaltung, zeigen aber klare Grenzen bei Fehlerkorrektur, komplexen buchhalterischen Entscheidungen und der Auflösung kumulierter Probleme
- Zwischen kurzfristigem „Fortschritt“ und tatsächlicher „Genauigkeit“ besteht ein Unterschied; für den Einsatz in der Praxis werden zusätzliche Schutzmechanismen und doppelte Validierung als notwendig hervorgehoben
1 Kommentare
Hacker-News-Kommentare
Wir konzentrieren uns derzeit gemeinsam mit Enterprise-Kunden auf dieses Problem. Das Schwierigste ist die Entity-Erkennung: in unordentlichen Transaktionsdaten präzise herauszufinden, wer „Acme Inc“ ist und was das Unternehmen tut. Dafür haben wir einen AI-Agenten entwickelt, der auf 265 Millionen juristischen Entities basiert, und letzte Woche hat er auf echten Kundendaten 160 % besser abgeschnitten als bestehende Systeme. Wir sind noch im Stealth-Modus, können aber die API-Dokumentation dazu teilen: https://docs.savvyiq.ai/api-reference/#tag/entity-resolution
Wenn jemand über dasselbe Problem nachdenkt, würde ich mich jederzeit gern dazu austauschen.
Ich bin Mitglied des Benchmark-Teams. Das Ziel dieses Projekts war zu testen, wie gut LLMs Buchhaltung erledigen können, ohne dass man ihnen zu starke Leitplanken vorgibt. Wir haben dem LLM verarbeitete Transaktionsdaten und ein Tool zur Codeausführung gegeben, aber es konnte selbst frei entscheiden, wie es das nutzt. Claude und Grok 4 zeigten in den ersten Monaten Leistungen nahe am CPA-Niveau, aber mit wachsender Datenmenge fiel die Performance ab. Dieses Versagen lag nicht nur an der Kontextlänge; wir haben den Kontext jeden Monat zurückgesetzt, und trotzdem zeigten die Fehlertypen Eigenschaften, die an Reward Hacking erinnern. Aus RL-Sicht scheint mir Accounting ein Bereich zu sein, in dem Modelltraining mit Zwischenbelohnungen relativ einfach sein sollte. Mit strengerer Struktur ließe sich die Leistung vermutlich weiter steigern, aber aus Forschungsperspektive halte ich das für weniger wichtig. Wir forschen in diese Richtung weiter.
Ich denke, das ist ein Ausgangspunkt. Die Welt braucht wirklich bessere Buchhaltungssysteme. Mein eigenes kleines Unternehmen zahlt jedes Jahr Zehntausende Dollar für Buchhaltung, und bei der Verarbeitung verschiedenster Transaktionen wie im E-Commerce treten ständig massive menschliche Fehler auf. Auch Quickbooks hat viele Probleme. Es ist so komplex, dass selbst der Support es oft nicht lösen kann, und dass Intuit jedes Jahr die Preise erhöht, frustriert ebenfalls. Es ist faktisch ein Monopol, an das CPAs in diesem Ökosystem gebunden sind. Ich hoffe, dass die Performance-Probleme gut gelöst werden. Wir brauchen wirklich eine Alternative zu den bestehenden Buchhaltungsoptionen.
Mir gefällt sehr, wie dieser Benchmark in einer realen Umgebung aufgebaut wurde. Ich frage mich, wie oft ihr die Prompts verändert habt. Beim Bau echter Agent-Apps habe ich oft erlebt, dass kleine Änderungen im Prompt einen riesigen Unterschied im Verhalten machen können, gerade bei Reward Hacking und Halluzinationen. Ich würde diesen Ansatz gern genauer verstehen.
Dass die Performance trotz Tool Calls abfällt, ist wirklich interessant. Ich frage mich, was im ersten Monat anders war. Wurde anfangs der gesamte Kontext ohne Tool Calls eingebracht, und haben die Tool Calls in späteren Monaten dann nicht gut funktioniert? Genau solche Punkte würden mich interessieren. Sollten Tool Calls nicht eigentlich dazu dienen, den Kontext zu ergänzen?
Wirklich ein spannendes Feld. Ich habe früher im Graduiertenstudium Finanzbuchhaltung gelernt und auch doppelte Buchführung modelliert. Das Schwierigste war weniger die Implementierung selbst als das Management der Datenqualität. Ich hatte das Gefühl, dass die Welt einen standardisierten Datensatz für Buchhaltungsprozesse braucht. Zu dem Phänomen, dass die Leistung von Frontier-LLMs mit der Zeit abnimmt: Meiner Erfahrung nach ist es beim Einsatz von LLMs viel stabiler, ihnen nicht auf einmal große Aufgaben zu geben, sondern schrittweise und in kleineren Einheiten zu arbeiten. Diese Richtung bei der Entwicklung agentischer Tools wirkt wie ein Fenster in die Zukunft.
Ich frage mich, ob es ein detaillierteres Overview gibt, etwa ein arXiv-Paper oder den tatsächlichen Trainingssatz.
Ich mag das Site-Design sehr.
Wir leben bereits in einer Zeit, in der Anwälte LLMs zum Verfassen juristischer Dokumente einsetzen. Ich halte es für völlig plausibel, dass irgendwo auf der Welt Leute ChatGPT-artige LLMs in der Buchhaltung einsetzen und damit ihr Unternehmen langsam zugrunde richten.
[Zum Site-Design] Bonus-Hinweis für Leute, denen Datenschutz wichtig ist. Diese Seite funktioniert auch dann gut, wenn uBlock 3rd-party-Frames und Skripte blockiert, und es gibt weder Remote-Fonts noch große Medieninhalte, also wirkt alles sauber und aufgeräumt. Beeindruckend, dass ein so schönes Design auch noch so rücksichtsvoll umgesetzt ist.
Ich bin sicher, viele Buchhaltungstricks, die sich ein LLM ausdenken kann, werden irgendwo bereits von menschlichen Buchhaltern verwendet, die kreativ Abkürzungen nehmen. Die richtige Antwort ist nicht, AI zu blockieren oder zu vermeiden, sondern die Verifikationsmechanismen zu stärken.
Solche Texte frustrieren mich jedes Mal ein wenig. Reale Aufgaben wie Accounting bestehen aus sehr präzisen, stark eingeschränkten und leicht auditierbaren Rechenfolgen. Menschen bewältigen diese Komplexität, indem sie sie in strukturierte Prozesse und verständliche Einheiten zerlegen. Zu erwarten, dass ein AI-Modell einen End-to-End-Workflow ohne klare strukturelle Aufteilung und ohne Aufsicht gut bewältigt, überschreitet nicht nur die Grenzen des Modells, sondern missversteht die Natur dieser Arbeit selbst. Ich würde gern sehen, dass jemand mit stärker strukturiert orchestrierten nichtlinearen Langzeit-Workflows experimentiert und dabei transparente Aufsicht sowie Prinzipien der Modularisierung etabliert. Diese Richtung wäre weit interessanter.
Als ich die LLM-Logs durchgelesen habe, war ich wirklich erstaunt, wie tief aktuelle Modelle bereits denken können. Mit der Zeit machen sie zwar Fehler, aber die Zukunft macht mir wirklich Hoffnung.
Ich habe diesen Artikel an befreundete Buchhalter geschickt, und er passt exakt zu meinen Erfahrungen beim Entwickeln von Spielen mit LLMs. Die aktuell beste Nutzung von Sprachmodellen — sogar einschließlich Agent-Modus — scheint mir zu sein, ihnen die gewünschte Ausgabe sehr genau vorzugeben und sie dann als bessere Form von Autocomplete zu verwenden. Das spart überraschend viel Zeit, ist aber kein Allheilmittel.
Ehrlich gesagt bin ich mir nicht sicher, ob es wirklich komplett Zeit spart. Am Ende fühlt es sich oft so an, als würde mehr Zeit dafür draufgehen, Tasks zu strukturieren und Halluzinationen zu analysieren und zu debuggen, als wenn man es selbst gemacht hätte.
Ich frage mich, worin „besseres Autocomplete“ konkret besser sein soll.
In der Buchhaltung spart es tatsächlich ziemlich viel Zeit, aber ich habe dennoch das Gefühl, dass ein menschlicher Buchhalter weiterhin unbedingt nötig ist.
Ich denke, diese Art von Benchmarking hängt extrem stark von der Gestaltung der Prompts und der Methode ab. Je nachdem, wie man es designt, kann die Genauigkeit völlig unterschiedlich ausfallen. Die Ergebnisse dürften stark davon abhängen, wie jeder Einzelne sein LLM architektonisch aufbaut. Je mehr ich lese, desto mehr scheint es einfach ein dumb benchmark zu sein, das Beobachtungen über den Zeitverlauf sammeln soll. Es wirkt stärker auf die Richtung ausgerichtet als auf die praktische Nutzbarkeit als Auto-Close-Tool.
Was dieser Benchmark zeigt, ist ein Phänomen, bei dem die Fehler immer größer werden, weil LLMs „die richtige Antwort erzeugen wollen“. Ein möglicher logischer Einwand wäre, dass das Modell vielleicht zu einer Antwort gedrängt wird, obwohl nicht genügend Details vorliegen. Aufgrund der in historischen Transaktionsdaten enthaltenen impliziten Informationen war die Leistung in den Monaten 1–2 wohl noch ordentlich. Mein Fazit ist, dass beim Skalieren im Enterprise-Umfeld entscheidend ist, alle impliziten Informationen explizit offenzulegen.
Wir hatten ohnehin schon die Gewohnheit, uns nicht um Details zu kümmern, und AI verschärft das noch. Nichtdeterministische Software ist gefährlich, wenn man sie auf reale Probleme mit extrem präzisen Anforderungen ansetzt. Ein Unternehmen mag es noch akzeptabel finden, wenn ein Chatbot von 5–20 % der Kunden schlecht bewertet wird, aber SEC, DOJ und Aktionäre würden es niemals tolerieren, wenn die Buchhaltung zu 20 % falsch ist oder eine Brücke 5 Zoll zu kurz gebaut wird.
Auch menschliche Buchhalter sind in der Praxis oft ziemlich nichtdeterministisch. In hinreichend komplexen Buchhaltungssystemen gibt es immer einen gewissen Anteil an Ungenauigkeit. Die Kernfrage ist, ob diese Ungenauigkeit tatsächlich materiell ist. Ich fand den Artikel wirklich beeindruckend und erwarte, dass ein weiterer Evolutionsschritt die Genauigkeit in die Nähe menschlicher Buchhalter bringen könnte.
Wenn sich „extrem präzise Anforderungen“ billig automatisch verifizieren lassen, kann AI auch iterativ Spam erzeugen, bis alle Tests bestanden werden.