Warum keine automatische Kontrolle die Prüfung ersetzt
Julian von jumoca FLOW · Veröffentlicht 27. September 2026
Konfidenzwerte, Quellenangaben, ein zweites Modell, XBRL-Daten, aufgehende Summen: Jede dieser Absicherungen klingt, als dürften KI-Zahlen ungeprüft ins Modell. Warum das bei keiner davon stimmt, was jede wirklich misst und was das für das Wort „automatisch“ heißt.
Warum 99,8 Prozent nicht reichen
Die besten KI-Modelle lesen Abschlüsse erstaunlich gut, und jede Generation wird besser. Warum die Zahlen dann nicht einfach durchwinken?
Weil „automatisch“ ein Versprechen ohne Ausnahme ist. Wer einen Wert ungesehen ins Modell übernimmt, braucht eine Regel, die immer stimmt, nicht fast immer. Nehmen wir an, ein Modell liest 99,8 Prozent aller Zahlen richtig. Bei 150 Zahlen pro Modell enthält dann etwa jeder vierte Durchlauf mindestens eine falsche. Welche das ist, weiß niemand. Sie sieht aus wie die anderen 149.
Und es trifft nicht immer dieselbe Zahl. Mal ist es der Umsatz, beim nächsten Bericht eine Rückstellung. Es gibt also keine Handvoll Felder, auf die man besonders achten könnte. Um die eine falsche Zahl zu finden, müssen Sie sich alle ansehen. Das ist genau die Prüfung, die Sie sich sparen wollten.
Hohe Genauigkeit macht es sogar schlimmer. Nach zweihundert richtigen Werten schaut beim zweihunderteinsten keiner mehr genau hin. Ein Werkzeug, das fast immer stimmt, bringt Ihnen bei, ihm genau dort zu vertrauen, wo Sie es nicht sollten.
Was eine Kontrolle beweisen müsste
Damit eine Kontrolle einen Wert freigeben kann, müsste sie die richtige Zahl unabhängig kennen. Genau das kann sie nicht. Jede automatische Kontrolle vergleicht die Antwort mit etwas aus demselben Dokument, aus einem zweiten KI-Durchlauf oder mit der Einschätzung der KI, die den falschen Wert fabriziert hat.
Eine Kontrolle kann deshalb zeigen, dass etwas falsch ist, aber nie, dass etwas richtig ist. Kommen zwei Wege zu unterschiedlichen Zahlen, ist mindestens eine falsch. Kommen sie zur selben, können trotzdem beide falsch sein.
Viele dieser Kontrollen messen durchaus etwas, nur eben nicht das, was ihnen nachgesagt wird. Im Folgenden wird dies an verschiedenen Kontrollen veranschaulicht.
Konfidenzwerte zeigen, wie sicher das Modell ist, nicht, ob es recht hat
Ein Konfidenzwert sagt, wie sicher sich das Modell seiner Antwort ist. Er entsteht im selben Schritt, in dem auch der Fehler entsteht. Nimmt das Modell die Vorjahreszahl, dann weil sie ihm in diesem Moment als die richtige erscheint. Hätte es Zweifel gehabt, hätte es eine andere Zahl genommen.
Deshalb meldet ein Modell bei einem Fehler, den es nicht bemerkt, keine 50 Prozent. Es meldet so viel wie bei einer richtigen Zahl, oft 99 oder 100 Prozent. Das liegt auch daran, wie ein Sprachmodell eine Zahl schreibt: nicht auf einmal, sondern in kleinen Stücken, sogenannten Tokens, bei 4.011 etwa „4“, „.“ und „011“. Eine echte Wahl gibt es meist nur beim ersten oder zweiten Token, also dort, wo sich entscheidet, welche Zahl überhaupt gemeint ist. Ist dieser Anfang geschrieben, ergibt sich der Rest fast zwangsläufig, und jedes weitere Token kommt mit rund 99 Prozent Sicherheit. Wird der Konfidenzwert, wie häufig, als Durchschnitt über alle Tokens gebildet, gehen die wenigen knappen Entscheidungen zwischen den vielen sicheren Tokens unter.
Die Vorjahreszahl ist schließlich eine völlig plausible Zahl, sie steht in der richtigen Tabelle unter der richtigen Bezeichnung. 100 Prozent heißt nur, dass für das Modell keine andere Antwort in Frage kam, und genau das trifft auf eine plausible Zahl aus der falschen Spalte zu. Ein niedriger Wert heißt übrigens auch nicht, dass die Zahl falsch ist, sondern gibt lediglich an, wie wahrscheinlich die Tokenfolge ist, mit der das Modell diese Zahl ausgewählt hat.
Ein Sprachmodell besteht vollständig aus Wahrscheinlichkeiten. 99 Prozent heißt: In ähnlichen Fällen aus dem Training war dieses Token in 99 von 100 Fällen das richtige. Über den einzelnen Fall sagt das nichts. Ob diese Zahl zu den 99 gehört oder die eine falsche ist, verrät der Wert nicht. Und ob die 99 Prozent bei einem Bericht, den das Modell so noch nie gesehen hat, überhaupt noch stimmen, ist offen.
Eine Quellenangabe zeigt, wo die Zahl steht, nicht ob sie stimmt
Viele Werkzeuge nennen zu jeder Zahl eine Quelle, manche prüfen sogar automatisch, ob die Zahl dort tatsächlich steht. Diese Kontrolle zeigt genau eines: Die Zahl kommt im Dokument vor. Ob es die richtige Zahl für das Feld ist, zeigt sie nicht.
Die typischen Fehler bleiben deshalb unentdeckt. Die Vorjahreszahl, der Umsatz eines einzelnen Segments und die Zahl aus dem Anhang stehen alle im Bericht. Die Kontrolle bestätigt jede davon, und sie hat sogar recht, denn jede steht dort.
Zwei Modelle können sich gemeinsam irren
Ein anderer Ansatz: Ein zweites Modell liest denselben Bericht, oder dasselbe Modell wird zweimal gefragt, und übernommen wird nur, was übereinstimmt. Übereinstimmung zeigt, dass beide dasselbe lesen, nicht, dass sie richtig lesen.
Modelle lernen aus ähnlichen Daten und lesen dieselben Layouts ähnlich. Eine Tabelle mit dem Vorjahr links, eine Einheit, die nur einmal über der Tabelle steht, zwei Zeilen mit fast gleicher Bezeichnung: Was das eine Modell in die Irre führt, führt meist auch das andere in die Irre. Greifen beide zur selben falschen Zahl, wirkt der Fehler durch die Übereinstimmung sogar noch sicherer.
Daran ändern auch Modelle nichts, die eigens auf Finanzberichte trainiert wurden. Ein solches Training macht ein Modell treffsicherer, und es gibt seine Antworten häufig mit noch höheren Konfidenzwerten aus. Es arbeitet aber weiterhin mit Wahrscheinlichkeiten: Es wählt die Zahl, die nach allem, was es gelernt hat, am wahrscheinlichsten passt. Die höhere Trefferquote gilt für die Antworten insgesamt, nicht für die einzelne Zahl. Und weil solche Modelle aus ähnlichen Berichten lernen, teilen sie auch deren typische Fehler, etwa bei ungewöhnlich aufgebauten Tabellen oder Einheiten.
XBRL-Tags passen nicht immer zu Ihrem Modell
Börsennotierte Unternehmen veröffentlichen ihre Abschlüsse zusätzlich maschinenlesbar, mit XBRL-Tags. Da liegt es nahe, die Zahlen der KI damit abzugleichen.
Ein XBRL-Tag ordnet eine Zahl aus dem Abschluss einer festen Position der XBRL-Taxonomie zu, etwa den Umsatzerlösen. Passen diese Positionen genau zu den Feldern Ihres Modells, brauchen Sie keine KI, denn Sie können die Zahlen direkt aus den Tags übernehmen. Passen sie nicht, etwa weil Ihr Modell EBITDA oder Nettoverschuldung anders abgrenzt oder die Zahl nur im Anhang steht, muss jemand entscheiden, welcher Tag zu welchem Feld gehört. Das ist dasselbe Problem wie beim Auslesen der Zahlen aus dem Bericht.
Deshalb können auch XBRL-Tags nicht verlässlich als Kontrolle verwendet werden.
Eine aufgehende Summe beweist weniger, als man denkt
Am überzeugendsten klingt die Rechnung. Ergeben die Einzelposten, die die KI gelesen hat, genau die Summe, die sie gelesen hat, dann müssen sie doch stimmen?
Geht die Summe auf, heißt das nur: Die verwendeten Zahlen passen zueinander. Ob jede Zahl in der richtigen Zeile steht, heißt es nicht. Bei all diesen Fehlern geht die Summe glatt auf:
- Alle Werte samt Summe stammen aus der Vorjahresspalte. Auch das Vorjahr geht auf.
- Alle Werte sind in Tausend statt in Millionen. Die Summe stimmt genauso, sie ist nur tausendmal zu klein.
- Zwei Zeilen sind vertauscht, etwa Umsatzkosten und Vertriebskosten. An der Summe ändert das nichts.
- Zwei gleich große Fehler heben sich auf.
Bestätigen Sie die Summe selbst, fallen die ersten beiden Fälle weg, die letzten beiden nicht. Eine Summenkontrolle prüft, ob die richtigen Zahlen dabei sind, nicht, ob jede an ihrem Platz steht.
Und eine vertauschte Zeile ist nicht harmlos, nur weil die Summe stimmt. Umsatz- und Vertriebskosten bestimmen die Bruttomarge, kurz- und langfristige Verbindlichkeiten jede Liquiditätskennzahl. Jede Kennzahl, die auf einer einzelnen Zeile aufbaut, ist falsch, und die Kontrolle meldet trotzdem: stimmt.
Wofür Kontrollen taugen
Nutzlos sind Kontrollen deshalb nicht. Als Warnung taugen sie, als Freigabe nicht. Schlägt eine Kontrolle an, wissen Sie, dass etwas nicht stimmt und wo Sie nachsehen müssen, und das ist viel wert. Schlägt sie nicht an, wissen Sie nur, dass nichts dagegen spricht, nicht, dass alles stimmt.
| Kontrolle | Was sie zeigt | Was sie nicht zeigen kann |
|---|---|---|
| Konfidenzwert | Wie sicher sich das Modell ist | Ob die Zahl zum Bericht passt |
| Zahl steht in der Quelle | Die Zahl kommt im Dokument vor | Ob es die richtige Zahl für das Feld ist |
| Zwei Modelle stimmen überein | Beide lesen dasselbe | Ob beide richtig lesen |
| Abgleich mit XBRL | Die KI hat dieselbe Zahl gelesen, die das Unternehmen getaggt hat | Ob der Tag dasselbe meint wie Ihr Feld |
| Summe geht auf | Die Zahlen passen zueinander | Ob jede Zahl in der richtigen Zeile steht |
Als Warnung hilft jede davon. Als Freibrief, einen Wert ungeprüft ins Modell zu übernehmen, versagt jede, und zwar genau in den Fällen, auf die es ankommt.
Warum es ohne den prüfenden Blick nicht geht
Jede dieser Kontrollen ersetzt den Blick eines Menschen durch einen Vergleich mit etwas, das auf dieselbe Art falsch sein kann. Richtig ist eine Zahl erst, wenn jemand sie im Bericht gesehen, das Feld im Modell dazu angeschaut und entschieden hat, dass beides zusammengehört.
Das spricht nicht gegen KI. Moderne Modelle lesen in Sekunden, wofür ein Mensch Stunden braucht, und sie liegen meistens richtig. Diesen Vorteil sollte man nutzen. Es geht nur darum, dass kein Wert ungeprüft ins Modell geht. Bei jumoca FLOW steht deshalb nicht die Extraktion im Mittelpunkt, sondern die Prüfung.
Software sollte diesen Blick nicht abschaffen, sondern dafür sorgen, dass er so wenig Zeit wie möglich kostet. FLOW zeigt jeden Wert auf der Berichtsseite, von der er stammt, mit markierter Zahl. Stimmt der Wert, genügt ein Tastendruck, stimmt er nicht, ein Klick auf die richtige Zahl. In die Arbeitsmappe kommt nichts automatisch, auch dann nicht, wenn jede Kontrolle zustimmt.
Welche Fehler durch ungeprüfte KI-Tools schon passiert sind, zeigt der Artikel Warum schneller nicht immer besser ist.