Finance-KI-Tools scheitern im produktiven Einsatz nicht, weil die zugrunde liegenden Modelle schlecht sind, sondern wegen ihrer Architektur. Echte Finanzdaten sind volumenstark, ausnahmeintensiv und dulden keine probabilistischen Ausgaben. Diese Eigenschaften legen die Grenzen von Single-Prompt-Ansätzen schnell offen.
Die Lücke zwischen Demo und Produktion in der Finance-KI
Ein Tool, das in einer Sandbox sauber wirkt, bricht an einem echten Hauptbuch aus vorhersehbaren Gründen zusammen. Die Transaktionsvolumina steigen massiv. Kategorisierungsregeln widersprechen sich. Tochtergesellschaften verwenden unterschiedliche Hauptbuchstrukturen. Ausnahmen werden zur Regel statt zum Sonderfall.
Systeme, die in einer kontrollierten Umgebung korrekt gearbeitet haben, beginnen ungenaue Ergebnisse zu erzeugen, Referenzen zu erfinden oder vollständig zu hängen. Der Fehlerfall ist nicht dramatisch. Er ist schleichend und schwer zu erkennen.
Warum echte Finanzdaten generische Large Language Models aushebeln
Drei Eigenschaften verursachen das Problem.
- Volumen auf Transaktionsebene. Schlanke Organisationen verarbeiten monatlich Tausende von Transaktionen aus mehreren Quellen. Das in ein Context Window zu pressen ist unpraktikabel und führt zu schlechten Ergebnissen.
- Hohe Ausnahmedichte. Finanzprozesse hängen an Sonderfällen: Stornierungen, Teilzahlungen, konzerninterne Transaktionen, Währungsanpassungen. Systeme, die für typische Szenarien optimiert sind, scheitern genau dort, wo der eigentliche Wert liegt.
- Deterministische Anforderungen. Finanzberichte dürfen keine Näherungswerte tolerieren. Fachkräfte im Rechnungswesen benötigen reproduzierbare, prüfbare Prozesse, keine interpretativen Ausgaben.
Was agentenbasiertes Reasoning behebt
Agentenbasiertes Reasoning ersetzt einen einzelnen umfassenden Prompt durch eine Reihe verbundener, spezialisierter Agenten, die jeweils eine eng umrissene Funktion übernehmen. Ein Agent ruft Transaktionen ab und normalisiert sie. Ein anderer wendet Buchungsregeln an. Ein weiterer validiert den Bankabgleich. Ein weiterer verdichtet die Ergebnisse.
Diese Architektur bringt drei konkrete Vorteile.
- Trennung der Verantwortlichkeiten. Enge Zuständigkeiten mit begrenzten Eingaben begrenzen Fehler und machen Abweichungen nachvollziehbar statt intransparent.
- Determinismus dort, wo er benötigt wird. Buchhalterische Vorgänge laufen als stabile Regeln, nicht als probabilistische Antworten. Das Modell liefert das Reasoning, die Logik bleibt konsistent.
- Prüfbarkeit. Jede Operation erzeugt nachvollziehbare Dokumentation. Teams prüfen konkrete Agentenentscheidungen, statt Black-Box-Ausgaben zu interpretieren.
"Finance verzeiht keine Fehler."
Warum Cortena das auf die harte Tour gelernt hat
Im August 2025 führten wir eine Beta mit fünf Early Adopters durch, die Live-Xero-Daten angebunden hatten. Die Integration funktionierte. Die Oberflächen hielten stand. Doch die KI-Engine verschlechterte sich unter echten Datenvolumina auf eine Weise, die wir in Tests nicht gesehen hatten. Statt die Oberfläche zu flicken, haben wir das Fundament rund um agentenbasiertes Reasoning neu aufgebaut. Wir sind im September 2025 mit einem engeren initialen Anwendungsbereich, Cashflow-Analyse und einer deutlich stabileren Architektur neu gestartet.
Was das für Finance-Teams bedeutet, die KI-Tools bewerten
Drei Fragen helfen Ihnen, bei der Bewertung von Finance-KI den Lärm auszublenden.
- Funktioniert es mit Ihren echten Daten? Fordern Sie einen Test mit Ihrem tatsächlichen Transaktionsvolumen an, nicht mit einem vereinfachten Beispiel.
- Was passiert, wenn es falsch liegt? Ein Tool, das stillschweigend scheitert, ist schlechter als eines, das Ausnahmen klar kennzeichnet.
- Handelt es sich um ein Modell oder um mehrere Agenten? Die Architektur ist wichtiger als der Modellname auf der Verpackung.
Each agent: narrow inputs · stable rules · traceable output