KI-Finanzberichte: Der Test mit der Erstattung

Du fragst einen KI-Assistenten, wie viel du für Bürobedarf ausgegeben hast. Es gab einen Einkauf über 500 € und eine Erstattung über 200 €. Als Antwort bekommst du eine ordentliche Tabelle, eine kurze Erklärung und eine fett gedruckte Zahl. Schau zuerst auf diese Zahl: Stehen dort 300 € oder 700 €?

KI-Finanzberichte sollten ihre Berechnungen nachvollziehbar machen. Eine gut formulierte Erklärung hilft wenig, wenn die Summe eine Erstattung zum ursprünglichen Aufwand addiert. Ich möchte einen Eingangswert ändern, die Wirkung vorhersagen und genau diese Änderung im Bericht und im Export wiederfinden.

Der Test ist gerade deshalb hilfreich, weil er so klein ist. Du brauchst kein kompliziertes Dashboard, um das erwartete Ergebnis zu verstehen. Trotzdem muss das System mehrere Informationen erhalten, die in einer bloßen Liste von Beträgen leicht verloren gehen: die Buchungsseite, die Bedeutung einer Erstattung und die Beziehung zwischen einer Summe und ihren Bestandteilen.

Was sollte ein KI-Finanzbericht eigentlich liefern?

Am 22. September 2026 stellte Accrual Arc vor: Arbeitsergebnisse zur Prüfung, darunter Excel-Arbeitsmappen und Mandantenberichte. Quelle: Accrual. Am 15. September präsentierte Workiva Agent Studio für KI-Agenten auf Basis von Unternehmenswissen und kontrollierten Arbeitsabläufen. Quelle: Workiva.

Für mich zeigen diese Ankündigungen eine Verschiebung: Das eigentliche Arbeitsergebnis reicht über die Antwort im Chat hinaus. Menschen sollen eine Datei prüfen, die sie anschließend in einem anderen Prozess verwenden. Daraus ergibt sich eine praktische Frage: Welche Informationen begleiten eine Zahl, wenn das Gespräch nicht mehr danebensteht?

Ich erwarte mindestens Zeitraum, Währung, Berechnungsregeln und eine Möglichkeit, die Bestandteile des Ergebnisses zu prüfen. Der Satz, dass die Ausgaben gesunken seien, hilft deutlich weniger, wenn die exportierte Datei nicht erkennen lässt, welche Ausgaben gemeint sind.

Unser Artikel über den KI-Agenten für die Buchhaltung beschreibt den größeren Ablauf. Hier geht es um einen kleineren Ausschnitt: die feste Berechnung hinter einem Bericht in einem KI-Buchhaltungsprodukt. Wir haben Normans Berichtsberechnung und CSV-Formatierung lokal mit erfundenen Daten ausgeführt. Das ist keine Vorführung einer KI, die eine Excel-Arbeitsmappe erstellt.

Wie sollte ein KI-Bericht eine Erstattung behandeln?

Wir beginnen mit einer einzigen Aufwandskategorie. Ihr ordnen wir einen Einkauf über 500 € zu. Anschließend kommen 200 € davon als Erstattung zurück. In diesem Beispiel beträgt die Umsatzsteuer null, die betriebliche Nutzung 100 %. So prüft der Versuch gezielt die Erstattung, ohne mehrere Buchhaltungsfragen in einem Ergebnis zu vermischen.

Der lokale Test verwendet unverändert übernommene Berechnungsfunktionen aus Normans Berichtscode. Die Berechnung nimmt den Betragswert ohne Vorzeichen, berücksichtigt die Buchungsrichtung und kehrt den Beitrag einer Erstattung um. Heraus kommen 300 € Aufwand. Ohne Erstattung liefert dieselbe Berechnung 500 €; bei einer vollständigen Erstattung von 500 € bleibt null übrig.

Die letzte Spalte zeigt eine bewusst falsche Alternative. Sie ist weder eine gemessene Modellausgabe noch ein Beleg für einen früheren Norman-Fehler. Sie zeigt, weshalb ein zunächst plausibler Rechenschritt hier scheitert: Vorzeichen entfernen und anschließend alle Beträge addieren.

Die Kategorie haben wir vorab festgelegt. Der Test sagt also nichts darüber aus, ob ein Modell den Einkauf richtig einordnen würde. Diese Trennung erleichtert die Fehlersuche. Zuerst steht fest, welche Berechnung du erwartest. Danach lässt sich prüfen, ob das System ihr die richtigen Eingaben liefert.

Warum reicht das Vorzeichen eines Betrags nicht aus?

Ein positiver Betrag sieht schnell wie eine Einnahme aus, wenn du an eine einfache Liste von Bankbewegungen denkst. Ein gespeicherter Transaktionsbetrag und seine Buchungsseite sind aber zwei getrennte Informationen. Die Lieferantenerstattung in unserem Beispiel gehört zum Aufwand. Wer jeden positiven Betrag als Umsatz behandelt, beantwortet eine andere Frage.

Für diesen Test gibt es einen Grund aus dem Betrieb. Eine ausschließlich lesende Aggregatabfrage aktiver Norman-Transaktionsdatensätze fand einige Hundert Datensätze ohne Erstattungsmarkierung, deren gespeichertes Vorzeichen von der Buchungsseite abwich. Die Abfrage erfasste einen Zeitraum von neunzig Tagen nach Wertstellungsdatum bis vor den 28. September 2026. Abgerufen wurden Anzahlen, keine einzelnen Transaktionen oder Beschreibungstexte.

Das beschreibt die Speicherung der Daten. Es ist keine Anzahl falscher Berichte und erklärt auch nicht, warum die Datensätze so gespeichert sind. Die geprüfte Gesamtheit unterscheidet sich außerdem von der engeren Auswahl betrieblicher Transaktionen, die ein bestimmter Bericht verwendet.

Im lokalen Test führt ein positiv gespeicherter Betrag von 500 € mit der Buchungsseite Aufwand weiterhin zu 500 € Aufwand. Dieses Verhalten können wir zeigen. Die Produktionsabfrage begründet, warum sich der Test lohnt. Sie macht das fiktive Beispiel nicht zu einer Messung der Genauigkeit im Produktivbetrieb.

Kann eine Summe doppelt gezählt werden?

Jetzt ergänzen wir den Bericht um zwei Betriebskostenpositionen: 400 € Miete und 300 € Büroaufwand nach der Erstattung. Die Betriebskosten betragen zusammen 700 €. Klappst du die Details auf, können alle drei Zahlen gleichzeitig sichtbar sein.

Addierst du jeden sichtbaren Betrag, erhältst du 1.400 €. Die Addition selbst ist korrekt. Der Fehler liegt darin, eine übergeordnete Summe und ihre Bestandteile als unabhängige Ausgaben zu behandeln. Das kann einem Menschen in einer Tabelle passieren und ebenso einem Agenten, der eine dargestellte Tabelle wieder in Daten umwandelt.

Normans CSV-Aufbereitung kennzeichnet Summenzeilen mit Ebene null und Betriebskostendetails mit Ebene eins. Damit bleibt eine wichtige Beziehung im Export erhalten. Daraus folgt allerdings nicht, dass du sämtliche Zeilen der Ebene null addieren kannst. Der vollständige Bericht enthält auch berechnete Zwischensummen und Ergebnisse.

Für unseren Test ist die Regel enger gefasst: Die Betriebskostendetails ergeben zusammen ihre übergeordnete Summe von 700 €, und diese zählt genau einmal. Eine ähnliche Unterscheidung haben wir bei Scores für das Transaktionsmatching untersucht. Ein Wert ist erst dann sinnvoll nutzbar, wenn seine Bedeutung klar ist.

Sollte die CSV zum Bildschirm passen?

Die untersuchte Norman-Ansicht sowie CSV- und PDF-Export verwenden dieselbe Aufbereitung der Berichtszeilen. So haben die Werte eine gemeinsame Quelle, während die Darstellung unterschiedlich bleiben kann. Zugleich lässt sich an einer Stelle prüfen, wie die Summe von 700 € mit ihren Bestandteilen zusammenhängt.

Wir haben den fiktiven Bericht durch die tatsächlichen CSV-Funktionen geschickt. Das englische Zahlenformat schreibt 700.00 und trennt Felder mit Kommas. Das deutsche Format schreibt 700,00 und verwendet Semikolons als Feldtrenner. Beide stellen denselben Betrag dar.

Du kannst die CSV im englischen Format und die CSV im deutschen Format ansehen. Beide enthalten englische Beispielbeschriftungen. Die Dateien stammen aus dem lokalen Test, nicht aus einem Kundenkonto. Wir haben Zellen und Trennzeichen geprüft, aber keinen Import in ein bestimmtes Tabellenprogramm durchgeführt.

Das Format verdient einen eigenen Test, denn auch eine Datei ist eine Schnittstelle. Nach dem Herunterladen steht der erklärende Chat möglicherweise nicht mehr zur Verfügung. Zeitraum, Währung und Zeilenbedeutung müssen diese Übergabe überstehen. Unser Artikel über Ergebnisse von KI-Agenten-Tools behandelt denselben Punkt beim Austausch zwischen Werkzeugen.

Was solltest du prüfen, bevor du dem Bericht vertraust?

Schreibe das erwartete Ergebnis auf, bevor du das System danach fragst. Beginne mit den drei Erstattungsfällen und ergänze anschließend die Summe mit ihren Einzelpositionen. Halte die Eingabedaten konstant und ändere nur das Exportformat. Der Betrag muss gleich bleiben, auch wenn er anders geschrieben wird.

Prüfe danach die Grenzen, die dieser kleine Versuch offenlässt: Kategorien, fehlende Beträge, Datumsfilter, Währungsumrechnung und ältere Erstattungsdatensätze. Eine aus bekannten Eingaben berechnete Null ist etwas anderes als eine Antwort, bei der ein Eingangswert fehlte. Diese Unterscheidung sollte sich prüfen lassen, ohne die Bedeutung einer leeren Zelle erraten zu müssen.

Das sind Empfehlungen für weitere Tests. Dieser Versuch prüft nicht die gesamte Berichtsanwendung. Er ruft kein Modell auf, führt keinen vollständigen Berichts-Endpunkt aus und misst keine buchhalterische Fehlerquote. Sein Nutzen liegt darin, dass du die gezeigte Rechnung und die exportierten Zellen unabhängig kontrollieren kannst.

Damit würde ich die Prüfung eines KI-Finanzberichts beginnen: ein Einkauf, eine Erstattung, eine Summe. Verfolge sie bis in die Datei. Wenn ihre Bedeutung schon auf diesem kurzen Weg verloren geht, macht eine längere Erklärung das Ergebnis nicht vertrauenswürdiger.