How to Stop AI Hallucinations in
Document Automation

The Real Problem: Trust Without Verification

Here is a workflow that exists in hundreds of businesses right now: a PDF arrives — an invoice, a purchase order, a supplier contract, a job application. An AI model reads it, extracts the relevant fields, and writes those values directly into a database or CRM. Clean, fast, no human in the loop.

And it works. Until it doesn't.

One day the model reads "£12,400" as "£1,2400." Or it extracts a vendor name and returns the vendor's address instead. Or it fills a date field with "as soon as possible" because that phrase appeared near a deadline in the document. Or it confidently returns a VAT number that doesn't exist because the document had a formatting anomaly and the model interpolated something plausible-looking.

That data is now in your system. And unless you have a validation layer between the model's output and your database, you have no way of knowing it happened until something downstream breaks.

This is the hallucination problem in document automation. It's not about the model making things up out of thin air — it's about the model returning plausible-but-wrong values with the same confidence it returns correct ones. The fix is not a better prompt. The fix is a system that doesn't trust the model's output until it has verified it against a rigid schema.

What "Hallucination" Actually Means in Document Processing

In the context of document data extraction, hallucination takes three distinct forms. Understanding which type you're dealing with determines which part of your validation layer catches it.

Most automation setups that use LLMs for document extraction protect against none of these. The model returns a JSON object, the workflow maps the keys to database fields, and the values go in. The assumption is that if the JSON looks right, the data is right.

That assumption is wrong often enough to cause real problems — and it compounds. A corrupted invoice record doesn't just sit there; it affects your accounts payable run, your supplier relationships, and your tax records.

Why a Better Prompt Won't Fix This

The instinct when something goes wrong with an AI extraction is to fix the prompt. Make it more specific. Tell the model exactly what format you want. Add examples. This helps — but it doesn't solve the structural problem.

Prompt improvements reduce the frequency of errors. They don't eliminate them, and they don't detect them when they occur. A prompt that says "return the invoice total as a number with two decimal places" will produce correctly formatted totals most of the time. But when the document has a formatting quirk the model hasn't seen before, or when the OCR layer upstream produced garbled text, the model will still return something — and that something will still look like a number.

This is not a pessimistic position — it's a realistic one, and it leads to a much more robust architecture than chasing the perfect prompt. Instead of asking "how do I make the model not hallucinate," the better question is: "how do I verify the output before it goes anywhere important?"

The answer is a validation layer. And that validation layer doesn't rely on the model at all — it uses deterministic, rule-based schema checks that either pass or fail with no ambiguity.

The Two-Layer Architecture: Structured Output + Schema Validation

The architecture that makes document automation reliable has two distinct layers. Each one does a different job, and you need both.

Layer 1 (structured output) reduces the frequency of malformed output. Layer 2 (schema validation) catches whatever slips through. Together, they create a system where the only data that reaches your database is data that has been verified against explicit, machine-enforced rules.

The key insight is that Layer 2 is entirely independent of the AI model. It doesn't care how the model generated its answer, what prompt you used, or which LLM you're running. It applies a rigid set of rules to a JSON object. Either the JSON passes — or it doesn't. There's no probability here. No hallucination can survive a validation layer that says "this field must be a positive number less than 1,000,000 in the format 0.00."

JSON Schema in Practice: What the Validation Node Checks

Let's make this concrete. Say you're extracting data from supplier invoices. Here's the kind of JSON Schema your validation node would enforce.

{
  "type": "object",
  "required": [
    "invoice_number",
    "invoice_date",
    "supplier_name",
    "line_items",
    "subtotal",
    "tax_amount",
    "total_due",
    "payment_terms",
    "currency"
  ],
  "additionalProperties": false,
  "properties": {
    "invoice_number": {
      "type": "string",
      "minLength": 1,
      "maxLength": 50
    },
    "invoice_date": {
      "type": "string",
      "format": "date",
      "description": "ISO 8601 — YYYY-MM-DD only"
    },
    "due_date": {
      "type": ["string", "null"],
      "format": "date"
    },
    "supplier_name": {
      "type": "string",
      "minLength": 1,
      "maxLength": 200
    },
    "supplier_vat": {
      "type": ["string", "null"],
      "pattern": "^[A-Z]{2}[0-9A-Z]{2,12}$"
    },
    "currency": {
      "type": "string",
      "enum": ["GBP", "USD", "EUR", "CAD", "AUD"]
    },
    "subtotal": {
      "type": "number",
      "minimum": 0,
      "maximum": 10000000,
      "multipleOf": 0.01
    },
    "tax_amount": {
      "type": "number",
      "minimum": 0,
      "maximum": 10000000,
      "multipleOf": 0.01
    },
    "total_due": {
      "type": "number",
      "minimum": 0,
      "maximum": 10000000,
      "multipleOf": 0.01
    },
    "payment_terms": {
      "type": "string",
      "enum": ["NET_7", "NET_14", "NET_30", "NET_60", "DUE_ON_RECEIPT"]
    },
    "line_items": {
      "type": "array",
      "minItems": 1,
      "items": {
        "type": "object",
        "required": ["description", "quantity", "unit_price", "line_total"],
        "properties": {
          "description": { "type": "string", "minLength": 1 },
          "quantity":    { "type": "number", "minimum": 0 },
          "unit_price":  { "type": "number", "minimum": 0 },
          "line_total":  { "type": "number", "minimum": 0 }
        }
      }
    }
  }
}

Notice what this schema enforces that a prompt cannot:

• Dates must be ISO 8601. "Next month," "31st May," and "05/31/26" all fail. Only "2026-05-31" passes. If the model returns anything else, the record is flagged — even if the value is technically correct, you know the format is wrong for your database.
• Currency must be one of five specific codes. The model cannot return "pounds," "sterling," "£," or "British Pounds" — any of which would break a downstream currency conversion lookup. Only the exact enum value is accepted.
• VAT numbers must match a specific regex pattern. A fabricated or garbled VAT number that doesn't fit the EU/UK format structure fails immediately.
• All monetary values must be to the penny. multipleOf: 0.01 catches any rounding errors or format anomalies before they reach accounts payable.
• No extra fields allowed. additionalProperties: false means if the model adds a field you didn't ask for — perhaps a hallucinated "confidence_score" or "notes" field — the entire record fails. The shape must match exactly.
• Required fields must be present. The model cannot return a record with a missing invoice number or supplier name. Null values are only permitted where explicitly allowed.

And here's the key business-rule check you add on top of the schema — a simple arithmetic verification you run in a Code node immediately after schema validation passes:

// Check that line items sum to the subtotal (within 1p rounding tolerance)
const data = $input.item.json;

const lineTotal = data.line_items
  .reduce((sum, item) => sum + item.line_total, 0);

const lineTotalRounded  = Math.round(lineTotal * 100) / 100;
const subtotalRounded   = Math.round(data.subtotal * 100) / 100;
const expectedTotal     = Math.round((data.subtotal + data.tax_amount) * 100) / 100;
const extractedTotal    = Math.round(data.total_due * 100) / 100;

const linesMismatch  = Math.abs(lineTotalRounded - subtotalRounded) > 0.01;
const totalMismatch  = Math.abs(expectedTotal - extractedTotal) > 0.01;

if (linesMismatch || totalMismatch) {
  return [{
    json: {
      ...data,
      _validation_status: "FAILED",
      _validation_errors: [
        linesMismatch ? `Line items sum (${lineTotalRounded}) ≠ subtotal (${subtotalRounded})` : null,
        totalMismatch ? `Subtotal + tax (${expectedTotal}) ≠ total_due (${extractedTotal})`   : null,
      ].filter(Boolean)
    }
  }];
}

return [{
  json: { ...data, _validation_status: "PASSED" }
}];

No LLM is involved in either of these checks. They are pure logic. A hallucinated invoice total that doesn't match the sum of line items will fail this check every single time, regardless of how confidently the model returned it.

Building the Validation Layer in n8n

Here's how the complete document automation workflow looks in n8n, from PDF arrival to database write.

The workflow has two lanes from step 6 onward. Data that passes validation flows straight to your system with no human involvement. Data that fails validation never touches your database — it goes to a review queue with a precise error message telling a human exactly what was wrong.

This is the key operational shift: instead of reviewing every extracted record, your team only reviews the ones that failed. If your validation pass rate is 95%, that's a 20× reduction in manual review load compared to checking everything. And the 5% that do reach human review come with a specific error message — "line items sum (£1,248.50) ≠ subtotal (£1,248.00)" — so the reviewer knows exactly where to look on the original document.

The Escalation Path: What Happens When Validation Fails

A failed validation record should never be silently dropped — that's just a different kind of data problem. And it should never auto-retry without modification, because the same document will produce the same failure.

The escalation path needs to do three things:

Most teams we work with find that after the first two to four weeks of running this architecture, their failure patterns are clear enough to add targeted pre-processing steps that bring the validation pass rate from ~90% to ~97%. The remaining 3% tend to be genuine anomalies — documents with unusual structure, handwritten annotations over printed fields, or supplier formatting that genuinely doesn't conform to any recognisable pattern. Those few records are flagged, reviewed, and entered manually. That's the right outcome.

Realistic Accuracy Numbers — And What "100% Accurate" Actually Means

Let's be honest about what you can expect.

The claim that document automation can be "100% accurate" needs to be unpacked. Without a validation layer, LLM-based extraction achieves somewhere between 85% and 95% field-level accuracy on well-structured PDFs — higher for digital PDFs, lower for scanned ones, lower still for documents with unusual layouts or dense tables. That sounds reasonable until you realise that 95% field-level accuracy on a 20-field invoice means roughly one field is wrong in every invoice. Across hundreds of invoices a month, that's hundreds of errors in your accounts payable data.

With a validation layer, the accuracy claim changes meaning:

The "100% accurate" statement means: every record that enters your database has passed a deterministic schema check. No hallucinated values are in your system. The records that don't pass are flagged for human review — and that's a feature, not a failure. You've correctly identified the documents where automated extraction wasn't reliable enough to trust.

Over time, as you tune your pre-processing, your prompt, and your schema based on the failure patterns you observe, the straight-through rate improves. Teams that start at 85% straight-through typically reach 95%+ within three months of running the full architecture.

Pre-Launch Checklist for Any Document Automation Workflow

Before you put a document automation workflow into production, work through this checklist. Each item is a failure mode we've seen in the wild.

Frequently Asked Questions