Wenn der KI-Agent in n8n falsche Rechnungsdaten liefert, ohne zu scheitern

Der teuerste Fehler bei der Rechnungsdatenextraktion mit einem KI-Agenten in n8n ist der, bei dem nichts rot wird. Der Workflow läuft durch, das JSON ist gültig, jedes Pflichtfeld ist gefüllt. Nur steht im Betragsfeld der Nettowert statt des Bruttowerts, oder eine Rechnungsnummer, die auf dem Beleg nirgends steht. Eine Fehlermeldung gibt es dafür nicht: Der Fehler ist inhaltlich, nicht technisch.

Warum meldet n8n keinen Fehler, wenn der Wert inhaltlich falsch ist?

n8n prüft die Form der Antwort, nicht ihre Richtigkeit. Der Structured Output Parser erzwingt ein JSON-Schema, also Feldnamen, Datentypen und Pflichtfelder. Ob der Betrag dem entspricht, was auf der Rechnung steht, kann er nicht wissen. Die n8n-Dokumentation beschreibt den Knoten genau so: Er liefert Felder „based on a JSON Schema“.

Der Auto-fixing Output Parser schließt diese Lücke nicht. Er ruft laut Dokumentation ein zweites Sprachmodell auf, wenn der erste scheitert. Das repariert kaputtes JSON, keine falschen Zahlen. Ein sauber formatierter, inhaltlich falscher Datensatz gilt für beide Knoten als Erfolg.

Wie oft liefert ein KI-Agent inhaltlich falsche Rechnungsfelder?

Gute Modelle liegen bei rund einem Prozent Fehlerquote auf Dokumentebene, und dieses eine Prozent meldet sich nicht von selbst. In einer Masterarbeit an der Technischen Hochschule Brandenburg hat Florian Pruß (18. September 2025, Betreuer Prof. Dr. Emanuel Kitzelmann) LLM-Extraktionen gegen einen unabhängigen Blind-Datensatz von 10.000 real verarbeiteten Rechnungen der aifinyo AG geprüft (TH Brandenburg, Masterarbeit). Gemessen wurde die Document Accuracy: Ein Beleg gilt nur dann als korrekt, wenn Rechnungsnummer, Rechnungsdatum und Betrag alle stimmen.

• Claude 3 Sonnet, Few-Shot mit Chain-of-Thought: 99,36 Prozent Document Accuracy, der beste gemessene Wert.
• GPT-4.1, Few-Shot: 99,02 Prozent.
• Gemma 3 27B-IT, Few-Shot: 97,61 Prozent, als offenes Modell für datenschutzkritische Aufstellungen interessant.
• Gemma 3 1B-IT: 24,97 Prozent. Kleine lokale Modelle sind für diese Aufgabe keine Sparvariante, sondern unbrauchbar.
• Das produktiv eingesetzte OCR-System zum Vergleich: 87,24 Prozent.

99,36 Prozent klingen nach erledigt. Auf 10.000 Rechnungen sind das rund 64 Belege mit mindestens einem falschen Kernfeld, die alle geräuschlos durchlaufen. Die Qualität des Eingangstexts wiegt dabei ähnlich schwer wie die Modellwahl: Dieselbe Strategie mit demselben Modell erreichte über einen sauberen PDF-Textlayer 99,77 Prozent Overall Accuracy, über eine Tesseract-OCR-Strecke nur 97,87 Prozent.

Woran erkennen Sie falsche Rechnungsdaten aus dem KI-Agenten?

An Widersprüchen zu Daten, die Sie bereits haben. Ein einzelnes Feld lässt sich nicht auf Richtigkeit prüfen, ein vollständiger Satz von Feldern schon, weil die Felder einer Rechnung rechnerisch und sachlich zusammenhängen. Sechs Gegenprüfungen gehören in jeden Rechnungs-Workflow:

• Rechenprobe: Summe der Positionen plus ausgewiesene Umsatzsteuer muss den Bruttobetrag ergeben. Fängt die Netto-Brutto-Verwechslung und verlorene Positionszeilen.
• Steuerprobe: ausgewiesener Umsatzsteuerbetrag gegen Nettobetrag mal Steuersatz. Ergibt sich kein gängiger Satz, ist der Beleg ein Prüffall.
• Stammdatenabgleich: Lieferantenname, Umsatzsteuer-Identifikationsnummer und IBAN gegen den Kreditorenstamm. Eine geänderte IBAN bei bekanntem Lieferanten ist immer ein Prüffall.
• Dublettenprüfung: Rechnungsnummer, Kreditor und Betrag gegen die bereits gebuchten Belege.
• Datumsplausibilität: Rechnungsdatum weder in der Zukunft noch außerhalb des offenen Buchungszeitraums, Fälligkeit gleich Rechnungsdatum plus Zahlungsziel.
• Bestellabgleich: Betrag und Menge gegen Bestellung und Wareneingang, mit einer festgelegten Toleranz.

Diese Kontrollen sind keine Erfindung der KI-Ära, sie stehen im Gesetzestext von gestern. Die GoBD nennen in Randziffer 100 ausdrücklich „Erfassungskontrollen (Fehlerhinweise, Plausibilitätsprüfungen)“, „Abstimmungskontrollen bei der Dateneingabe“ und „Verarbeitungskontrollen“ als Teil des internen Kontrollsystems, Randziffer 40 verlangt „inhaltliche Plausibilitätskontrollen“ (BMF-Schreiben vom 28. November 2019). Wer diesen Prüfschritt beim Umstieg auf einen KI-Agenten wegrationalisiert, entfernt eine Kontrolle, die vorher da war.

Welche Schwellenwerte gehören in den Validierungslayer?

Zwei Größen entscheiden, ob ein Beleg automatisch durchläuft: wie viele Gegenprüfungen er besteht und wie viel Geld an ihm hängt. Bewährt hat sich eine Ampel mit drei Pfaden statt einer einzigen Ja-Nein-Schwelle.

• Grün: alle Rechenproben stimmen, Kreditor und IBAN sind bekannt, keine Dublette, Betrag unterhalb Ihrer Freigabegrenze. Läuft automatisch weiter.
• Gelb: eine einzelne weiche Abweichung, etwa ein neuer Kreditor oder eine überschrittene Bestelltoleranz. Geht in eine Prüfliste, ein Mensch bestätigt oder korrigiert.
• Rot: Rechenprobe gerissen, IBAN weicht ab, Dublettenverdacht oder ein leeres Pflichtfeld. Wird nie automatisch gebucht.

Entscheidend ist, woher die Ampel ihre Werte nimmt. Nicht aus der Selbsteinschätzung des Modells: Ein Sprachmodell, das nach seiner eigenen Konfidenz gefragt wird, liefert eine plausible Zahl, keine gemessene. Die Schwellen müssen aus rechenbaren Prüfungen entstehen, also aus Arithmetik und Stammdatenvergleich. Wie eine solche Eskalation organisatorisch aussieht, steht in unserem Eskalationsmodell für KI-Agenten.

Ab welchem Betrag muss ein Mensch freigeben?

Eine gesetzliche Euro-Grenze gibt es nicht. Die GoBD schreiben Kontrollen und Funktionstrennung vor, ihre konkrete Ausgestaltung ist laut Randziffer 100 ausdrücklich abhängig von der Komplexität der Geschäftstätigkeit und der Organisationsstruktur. Die Grenze setzen Sie also selbst, und der richtige Ausgangspunkt ist Ihre vorhandene Unterschriftenregelung: Wenn im Haus ab 5.000 Euro die Geschäftsführung unterschreibt, hat der Agent oberhalb dieser Grenze nichts allein zu entscheiden.

Ein Beispiel aus der eigenen Buchhaltung, das kein Prompt löst: Zwei Auftraggeber von NordFlux rechnen im Gutschriftsverfahren nach § 14 Abs. 2 UStG ab, der Kunde stellt die Rechnung also für uns aus. Auf dem Beleg steht „Gutschrift“, NordFlux ist Rechnungssteller, der Absender ist Leistungsempfänger. Eine Extraktion, die das Wort auf die kaufmännische Bedeutung abbildet, macht daraus eine Rechnungskorrektur mit negativem Vorzeichen und dreht echten Umsatz ins Minus. Das Dokument ist sauber gelesen, jedes Feld stimmt, nur die Bedeutung ist umgekehrt. Dagegen hilft eine Regel im Validierungslayer: Steht die eigene Umsatzsteuer-Identifikationsnummer im Feld des Rechnungsstellers, ist es eine Ausgangsrechnung, egal was in der Überschrift steht.

Wie bauen Sie den Validierungslayer in n8n?

Als eigenen Abschnitt zwischen Extraktion und Zielsystem, nicht als längeren Prompt. Fünf Bausteine reichen für den Anfang:

• Extraktion kapseln: eigener Sub-Workflow, Rückgabe strikt über den Structured Output Parser, keine Freitextfelder.
• Prüfen im Code-Node, nicht im LLM: Rechenproben sind Arithmetik. Ein Sprachmodell, das nachrechnet, fügt eine zweite Fehlerquelle hinzu.
• Prüfergebnis mitführen: bestandene und gerissene Regeln als eigenes Feld am Datensatz. Ohne diese Liste lässt sich später nicht sagen, welche Regel wie oft greift.
• Switch-Node auf die Ampel: drei Pfade, grün ins Buchhaltungssystem, gelb in die Prüfliste, rot in den Fehler-Workflow mit Benachrichtigung.
• Protokollieren in eine eigene Tabelle: Eingangsdokument, extrahierte Werte, Prüfergebnis, Entscheidung und entscheidende Person. Die n8n-Executions haben eine begrenzte Aufbewahrung und ersetzen kein Prüfprotokoll.

Randziffer 100 der GoBD verlangt, dass Kontrollen nicht nur eingerichtet und ausgeübt, sondern auch protokolliert werden, nach Randziffer 102 gehört die Beschreibung des Kontrollsystems in die Verfahrensdokumentation. Ein Validierungslayer ohne Protokoll erfüllt also nur die Hälfte seines Zwecks. Wie der Ablauf im Gesamtbild aussieht, zeigen wir bei der Automatisierung des Rechnungseingangs und in der Buchhaltungsautomatisierung.

Häufige Fragen

Kann ein zweites Sprachmodell die Prüfung übernehmen?

Teilweise. Eine unabhängige zweite Extraktion und ein Vergleich Feld für Feld markiert unsichere Belege zuverlässig. Als alleiniger Richter taugt es nicht: Zwei Modelle können denselben Lesefehler machen, und ein Modell, das seine eigene Ausgabe bewertet, urteilt nicht unabhängig. Rechenproben und Stammdatenabgleiche gehören in Code.

Hilft ein besseres Modell nicht einfach gegen Halluzinationen?

Es hilft messbar, löst das Problem aber nicht. Selbst der Spitzenwert von 99,36 Prozent lässt auf 10.000 Belegen rund 64 fehlerhafte Dokumente übrig, und die Qualität des Eingangstexts wiegt ähnlich schwer wie die Modellwahl.

Worin unterscheidet sich das von einem Fehler im Output Parser?

Ein Parser-Fehler ist sichtbar: Der Knoten scheitert, die Ausführung wird rot, ein Error-Workflow greift. Der stille inhaltliche Fehler ist der gefährlichere Fall, weil alles gültig aussieht. Er braucht eine eigene Prüfschicht, keine bessere Fehlerbehandlung.

Erledigt sich das mit der E-Rechnung von selbst?

Nur zum Teil. Bei XRechnung oder ZUGFeRD lesen Sie die Werte aus dem eingebetteten XML aus, statt sie schätzen zu lassen. Belege ohne strukturierte Daten bleiben aber im Eingang, und Rechenprobe, Kreditorenabgleich und Dublettenprüfung sind unabhängig vom Format nötig.

Wie aufwendig ist es, den Validierungslayer nachzurüsten?

Die Technik ist der kleinere Teil: Rechenproben, Datumsplausibilität und Dublettenprüfung sind in einem Code-Node schnell gebaut. Der Aufwand liegt in der Abstimmung. Welche Toleranz gilt beim Bestellabgleich, ab welchem Betrag entscheidet ein Mensch, wer bearbeitet die gelbe Liste. Klären Sie das mit der Buchhaltung, bevor der erste Beleg automatisch gebucht wird.