Warum Finanz-Agenten Tools aufrufen müssen – statt selbst zu rechnen

Ein LLM prognostiziert, wie eine Zahl aussehen sollte; es führt die Formel nicht aus. Die Lösung für agentenbasierte Finanzprozesse besteht darin, jede Berechnung über deterministische Tools auf einem einzigen abgestimmten Modell zu führen.

Bitten Sie ein großes Sprachmodell, zwei neunstellige Zahlen zu addieren, und es liefert Ihnen oft ein Ergebnis, das auf den ersten Blick völlig korrekt aussieht – und um einige Tausend daneben liegt. Die Ziffern wirken plausibel. Die Größenordnung stimmt. Die Antwort ist falsch. Genau dieses Verhalten ist der Grund, warum die meisten Demos zum Thema “KI im Finanzwesen” in dem Moment auseinanderfallen, in dem ein Controller die Rechnung nachprüft.

Der unbequeme Mechanismus dahinter ist folgender: Ein LLM rechnet nicht. Es prognostiziert das nächste Token. Wenn Sie nach 14.820.116 minus 9.335.402 fragen, subtrahiert das Modell nicht – es erzeugt die Ziffernfolge, die statistisch am wahrscheinlichsten auf Ihre Eingabe folgt, gemessen an allem, was es im Training aufgenommen hat. Bei kleinen, häufig vorkommenden Summen hat es die Muster faktisch auswendig gelernt und liegt richtig. Bei den langen, unregelmäßigen Zahlen, die ein echtes Hauptbuch füllen, rät es lediglich nach Form. Manchmal trifft die Schätzung. Anhand der Ausgabe allein können Sie nicht erkennen, wann das der Fall ist, denn eine selbstbewusst präsentierte falsche Zahl liest sich exakt wie eine selbstbewusst präsentierte richtige.

Die Zahl sieht richtig aus – und genau das ist das Problem

Das ist gravierender als gewöhnliche Softwarefehler, weil der Fehler getarnt auftritt. Eine kaputte Formel in einer Tabellenkalkulation wirft in der Regel #BEZUG! oder einen völlig unmöglichen Summenwert aus. Ein Sprachmodell liefert eine Zahl, die bequem in dem Bereich liegt, den ein CFO erwarten würde. Ein Umsatz, der bei 47,3 Millionen liegen müsste, kommt als 46,9 Millionen zurück. Eine Bruttomarge, die zu 62 % passen müsste, kommt als 64 % zurück. Nichts schlägt Alarm. Der Fehler übersteht die Prüfung gerade deshalb, weil er so erzeugt wurde, dass er wie die Wahrheit aussieht.

Die Benchmarks bestätigen das. Bei FinanceBench, einer Testsammlung aus Frage-Antwort-Beleg-Tripeln aus öffentlichen Geschäftsberichten, beantwortete GPT-4-Turbo in Kombination mit einem Retrieval-System nur eine Minderheit der Fragen korrekt oder versuchte sie überhaupt – in der ursprünglichen Auswertung lag es bei rund vier von fünf Fragen falsch oder verweigerte die Antwort. Selbst wenn man dem Modell exakt das Dokument mit der Antwort vorlegte, wurde die Genauigkeit bei Fragen zu Finanzaufstellungen je nach Formulierung und Position im Kontext irgendwo zwischen den hohen Zehnerwerten und den hohen Achtzigern angegeben. Neuere spezialisierte Stacks liegen deutlich höher, doch genau diese Spannweite ist die Warnung. Ein System, dessen Genauigkeit um vierzig Prozentpunkte schwankt, je nachdem, wo Sie die Frage im Prompt platzieren, ist keine Grundlage für eine Zahl im Aufsichtsratsbericht.

Nichts davon bedeutet, dass das Modell nutzlos ist. Es bedeutet, dass Sie es um genau das gebeten haben, was es strukturell nicht garantieren kann.

Reasoning im Modell, Rechnen in der Ebene

Die Lösung ist kein besserer Prompt und kein größeres Modell. Sie liegt in der Arbeitsteilung.

Sprachmodelle sind tatsächlich gut in den weichen Teilen der Finanzarbeit: zu verstehen, dass “Burn” den Netto-Geldabfluss meint; zu erkennen, dass eine Frage nach der “Runway” den Kassenbestand geteilt durch den monatlichen Burn erfordert; zu bemerken, dass ein Nutzer die Kennzahl vermutlich als Jahreswert (Year-to-Date) und nicht quartalsweise möchte; und um das Ergebnis herum eine verständliche Erklärung in Klartext zu formulieren. Das ist Reasoning, und genau hier verdient sich das Modell seinen Platz.

Was das Modell nicht tun darf, ist die Subtraktion, die Division, die Währungsumrechnung, die Periodenaggregation oder die Kennzahlbildung. Diese gehen an deterministische Tools – tatsächlichen Code, der die Formel jedes Mal auf dieselbe Weise ausführt. Die Aufgabe des Modells besteht darin, das richtige Tool zu wählen, die richtigen Argumente zu liefern und das Ergebnis zurückzulesen. Genau dafür wurden Tool-Calling beziehungsweise Function Calling geschaffen: die sprachliche Komponente flexibel arbeiten zu lassen und die rechnerische Komponente exakt – und beide niemals zu verwechseln.

Klar gesagt: Der Agent sollte darüber nachdenken, was zu berechnen ist, und dann etwas anderes aufrufen, das die Berechnung tatsächlich durchführt. Wenn ein Agent eine Marge in seinem eigenen Kopf berechnet, vertrauen Sie eine Wahrscheinlichkeitsverteilung mit Ihren testierten Konten an. Wenn er ein Tool aufruft, vertrauen Sie der Arithmetik.

Warum ein Tool-Aufruf trotzdem ein abgestimmtes Modell als Fundament braucht

Tool-Calling allein erledigt die Aufgabe nicht – und an dieser Stelle bleiben viele Architekturen des Jahres 2026 einen Schritt zu früh stehen. Einem Agenten eine Funktion calculate_ratio() zu geben, ist notwendig, aber nicht hinreichend, denn die Funktion ist nur so vertrauenswürdig wie die Zahlen, die Sie ihr zuführen. Wenn der Agent eine Umsatzzahl aus einem System zieht, eine Kostenzahl aus einem veralteten Export und eine Mitarbeiterzahl aus einer Folie, dann berechnet das Tool eine vollkommen deterministische Kennzahl über inkonsistente Eingaben. Determinismus auf schlechten Daten liefert Ihnen lediglich ein reproduzierbar falsches Ergebnis.

Die Tools müssen also auf einem einzigen abgestimmten Modell laufen – einem einheitlichen Finanzmodell, das mit dem Hauptbuch übereinstimmt, bei dem jede Zahl eine bekannte Quelle hat und die Eingaben bereits untereinander konsistent sind. Genau das behandelt Rexfin als Fundament. Wir verbinden Ihre Buchhaltungs- und Finanzdatenplattformen (QuickBooks, Xero, NetSuite, Sage, SAP, Oracle, ein Data Warehouse) oder hochgeladene Aufstellungen, bauen ein einziges abgestimmtes Modell, das mit dem Hauptbuch übereinstimmt, und stellen darüber deterministische Berechnungs-Tools bereit. Der Agent denkt; die deterministische Engine rechnet; jede Ausgabe lässt sich bis zur Quelle zurückverfolgen.

Die Reihenfolge ist entscheidend. Verbinden, abstimmen, dann die Engine rechnen lassen – wer den mittleren Schritt überspringt, erhält genau die Zahlen, die kein Controller unterschreibt; das ist der Grund, warum die meisten Demos scheitern. Wir führen durch diesen Ablauf unter So funktioniert es, und dasselbe Prinzip ist der Grund, warum MCP für das Finanzwesen allein nicht ausreicht: Ein geregelter Zugriff auf Ihr ERP versorgt das Modell zwar mit Live-Daten, doch ohne abgestimmte Ebene und deterministische Berechnung betreibt das LLM weiterhin eine fragile, probabilistische Rechnerei auf rohen Feldern.

Was das einem skeptischen CFO bringt

Konkret drei Dinge.

Erstens: Reproduzierbarkeit. Dieselbe Frage, zweimal gestellt, liefert dieselbe Zahl, weil die Rechnung in Code lief und nicht in einem Sampler. Sie können eine Zahl so belegen, wie Sie eine Tabellenformel belegen – indem Sie sie erneut ausführen.

Zweitens: Nachvollziehbarkeit. Weil die Berechnung über ein abgestimmtes Modell lief, verweist jede Ausgabe auf die Quellzeilen zurück, die sie erzeugt haben. Ein Wirtschaftsprüfer, der fragt “Woher stammt das?”, erhält eine Herkunftskette und kein Achselzucken.

Drittens: eine belastbare Grenze für Autonomie. Sobald die Rechenarbeit das Modell verlässt, können Sie Agenten mehr tun lassen, ohne nachts wach zu liegen. Das ist die Voraussetzung für die Autonomiestufen, die festlegen, welche Workflows ein Agent eigenständig ausführen darf, und es ist der Grund, warum geregelte Autonomie sicherer ist, als einen Menschen in jede einzelne Transaktion einzubauen. Sie können einen Agenten nicht steuern, dessen Zahlen Sie nicht reproduzieren können.

Das Fazit

Ein LLM, das selbst rechnet, rät nach der Form einer Zahl. Ein LLM, das ein Tool über ein abgestimmtes Modell aufruft, lässt die Arithmetik die Arithmetik erledigen und behält die Sprache der Sprache vor. Das Erste wirkt in einer Demo magisch und versagt in einer Prüfung. Das Zweite ist unspektakulär – und unspektakulär ist genau das, was Sie unter einem Aufsichtsratsbericht haben wollen.

Wenn Sie agentenbasierte Finanz-Tools bewerten, stellen Sie dem Anbieter eine einzige Frage: Berechnet das Modell die Zahl selbst, oder ruft es etwas Deterministisches auf, das es tut? Kann er das nicht klar beantworten, ist die Rechnung eine Schätzung. Demo buchen – und wir zeigen Ihnen den Unterschied an Ihren eigenen Zahlen.