When the AI Agent in n8n Delivers Wrong Invoice Data Without Failing

The most expensive error in invoice data extraction with an AI agent in n8n is the one where nothing turns red. The workflow runs through, the JSON is valid, every required field is filled. Only the net value appears in the amount field instead of the gross value, or an invoice number that doesn't appear on the document anywhere. There's no error message for this: the error is substantive, not technical.

Why doesn't n8n report an error when the value is substantively wrong?

n8n checks the form of the response, not its correctness. The Structured Output Parser enforces a JSON schema, so field names, data types, and required fields. Whether the amount matches what's on the invoice, it can't know. The n8n documentation describes the node exactly this way: it delivers fields "based on a JSON Schema".

The Auto-fixing Output Parser doesn't close this gap. According to the documentation, it calls a second language model if the first one fails. This repairs broken JSON, not wrong numbers. A cleanly formatted, substantively incorrect dataset counts as success for both nodes.

How often does an AI agent deliver substantively wrong invoice fields?

Good models achieve around one percent error rate at the document level, and that one percent doesn't report itself. In a master's thesis at the Technical University of Applied Sciences Brandenburg, Florian Pruß (September 18, 2025, advisor Prof. Dr. Emanuel Kitzelmann) tested LLM extractions against an independent blind dataset of 10,000 real processed invoices from aifinyo AG (TH Brandenburg Master's Thesis). Document Accuracy was measured: an invoice is considered correct only if invoice number, invoice date, and amount all match.

• Claude 3 Sonnet, Few-Shot with Chain-of-Thought: 99.36 percent Document Accuracy, the best measured value.
• GPT-4.1, Few-Shot: 99.02 percent.
• Gemma 3 27B-IT, Few-Shot: 97.61 percent, interesting as an open model for data protection-critical deployments.
• Gemma 3 1B-IT: 24.97 percent. Small local models are not a cost-saving option for this task, but unusable.
• The production OCR system for comparison: 87.24 percent.

99.36 percent sounds complete. That's around 64 documents with at least one wrong core field per 10,000 invoices, all passing silently through. Input text quality weighs nearly as heavily as model choice: the same strategy with the same model achieved 99.77 percent Overall Accuracy via a clean PDF text layer, but only 97.87 percent via a Tesseract OCR path.

How do you identify wrong invoice data from the AI agent?

By contradictions with data you already have. A single field cannot be checked for correctness, but a complete set of fields can, because invoice fields are arithmetically and substantively related. Six counter-checks belong in every invoice workflow:

• Arithmetic check: sum of line items plus stated sales tax must equal the gross amount. Catches net-gross confusion and lost line items.
• Tax check: stated sales tax amount against net amount times tax rate. If no standard rate appears, the document is flagged for review.
• Master data reconciliation: vendor name, VAT identification number, and IBAN against the vendor master. A changed IBAN with a known vendor is always flagged for review.
• Duplicate check: invoice number, vendor, and amount against already posted documents.
• Date plausibility: invoice date neither in the future nor outside the open posting period, due date equals invoice date plus payment terms.
• Purchase order reconciliation: amount and quantity against purchase order and goods receipt, with a defined tolerance.

These checks are not an invention of the AI era; they're in the statute from yesterday. GoBD names in paragraph 100 explicitly "input controls (error notifications, plausibility checks)," "reconciliation controls during data entry," and "processing controls" as part of the internal control system; paragraph 40 requires "substantive plausibility controls" (BMF circular dated November 28, 2019). Anyone who rationalizes away this check step when switching to an AI agent removes a control that was there before.

What thresholds belong in the validation layer?

Two factors decide whether a document passes automatically: how many counter-checks it passes and how much money is involved. A traffic light with three paths instead of a single yes-no threshold has proven effective.

• Green: all arithmetic checks pass, vendor and IBAN are known, no duplicate, amount below your approval threshold. Continues automatically.
• Yellow: a single soft deviation, such as a new vendor or an exceeded purchase order tolerance. Goes to a review list; a person confirms or corrects.
• Red: arithmetic check failed, IBAN differs, suspected duplicate, or an empty required field. Never posted automatically.

Critical is where the traffic light gets its values. Not from the model's self-assessment: a language model asked for its own confidence provides a plausible number, not a measured one. The thresholds must come from computable checks, that is, from arithmetic and master data comparison. What such an escalation looks like organizationally is described in our escalation model for AI agents.

Above what amount does a person have to approve?

There is no statutory euro limit. GoBD prescribe controls and separation of duties; according to paragraph 100, their concrete design explicitly depends on the complexity of business activity and organizational structure. You set the threshold yourself, and the right starting point is your existing signature authority: if management signs off above 5,000 euros in-house, the agent has nothing to decide alone above that threshold.

An example from our own accounting that no prompt solves: two clients of NordFlux bill us under the credit note procedure pursuant to § 14 Abs. 2 UStG, so the customer issues the invoice for us. The document says "Gutschrift," NordFlux is the invoice issuer, the sender is the service recipient. An extraction that maps the word to its commercial meaning turns that into an invoice correction with a negative sign and reverses actual revenue into the negative. The document is cleanly read, every field is correct, only the meaning is reversed. Against this, a rule in the validation layer helps: if your own VAT identification number appears in the invoice issuer field, it's a sales invoice, no matter what the heading says.

How do you build the validation layer in n8n?

As a separate section between extraction and target system, not as a longer prompt. Five building blocks are enough to start:

• Encapsulate extraction: separate sub-workflow, return strictly via the Structured Output Parser, no free-text fields.
• Check in code node, not in LLM: arithmetic checks are math. A language model that recalculates adds a second source of error.
• Carry check results: passed and failed rules as its own field on the dataset. Without this list, you can't later say which rule fires how often.
• Switch-Node on the traffic light: three paths, green to accounting system, yellow to review list, red to error workflow with notification.
• Log to a separate table: source document, extracted values, check result, decision, and deciding person. n8n executions have limited retention and don't replace an audit trail.

Paragraph 100 of GoBD requires that controls not only be set up and exercised but also logged; paragraph 102 requires the description of the control system in the process documentation. A validation layer without logging only fulfills half its purpose. What the full picture looks like, we show in automating invoice intake and in accounting automation.

Frequently Asked Questions

Can a second language model do the checking?

Partially. An independent second extraction and field-by-field comparison reliably flags uncertain documents. As sole judge, it won't do: two models can make the same reading error, and a model that evaluates its own output doesn't judge independently. Arithmetic checks and master data reconciliation belong in code.

Doesn't a better model just solve hallucinations?

It helps measurably but doesn't solve the problem. Even the top score of 99.36 percent leaves around 64 erroneous documents on 10,000 invoices, and input text quality weighs as heavily as model choice.

How does this differ from an output parser error?

A parser error is visible: the node fails, execution turns red, an error workflow engages. The silent substantive error is the more dangerous case because everything looks valid. It needs its own check layer, not better error handling.

Does e-invoicing solve this on its own?

Only partly. With XRechnung or ZUGFeRD, you read values from embedded XML instead of having them extracted. But non-structured documents still arrive in intake, and arithmetic check, vendor reconciliation, and duplicate check are necessary regardless of format.

How much effort to retrofit the validation layer?

The technology is the smaller part: arithmetic checks, date plausibility, and duplicate check are quick to build in a code node. The effort lies in coordination. What tolerance applies to purchase order reconciliation, above what amount does a person decide, who processes the yellow list. Clarify this with accounting before the first document posts automatically.