n8n OCR Document Pipeline: Extraction, Validation and Index

Project description

Scanned paperwork is the worst kind of data: it looks like a document and behaves like a photograph. This pipeline takes PDFs with no text layer at all and turns each one into a searchable file plus a single row of structured data. Four documents went through one run, in two languages and four formats, and all four came out with their type, counterparty, numbers, dates and totals extracted, validated and filed. The part worth copying is not the OCR, it is what happens after it: validation runs in plain code, and anything the pipeline cannot be sure about is flagged rather than quietly filed.

Tools & Deliverables

• Four stage n8n pipeline: store the original untouched, OCR a copy, classify and extract with AI, validate in code, then write a searchable PDF and an index row
• Originals are never modified, which keeps the audit trail intact and allows reprocessing when the OCR engine improves
• Deterministic validation layer that re-checks totals against numbers actually present in the OCR text, catches a due date earlier than the document date, measures character quality and scores confidence
• Per-document review flags, so uncertainty is surfaced with the record instead of hidden inside a confidence number
• One index row per document carrying type, language, counterparty, number, dates, total, confidence, flags, summary, links and a snippet
• Processing one document at a time with nothing shared between jobs, which is the shape that scales into isolated workers later

The problem

• A scan is not a document. An image-only PDF has zero selectable characters, so every tool that assumes a text layer returns nothing, and the failure is silent rather than loud.
• OCR output is not structured data. Getting characters off the page is the easy half. Deciding which number is the total, which date is the due date, and which party is the counterparty is where document pipelines actually fail.
• Models produce confident nonsense on bad scans. Ask a model for the total and it will give you one, whether or not that figure appears anywhere in the text. On an invoice, a plausible wrong total is worse than an error message.
• Multiple languages and formats arrive together. An English invoice, a Spanish delivery note, a contract page and an expense claim with handwriting all land in the same inbox and have to come out in one shape.
• Modifying the original destroys the audit trail. Flattening or rewriting the source file means you can never reprocess it later or prove what the document said when it arrived.
• Uncertainty has to be visible. A pipeline that silently files a half-read expense claim creates work later, in the form of an audit nobody can trace back.

Approach

The pipeline splits into four stages that each do one job. The original scan is fetched and stored untouched, then OCR runs on a copy, so the source file is never modified. That separation matters twice over: it preserves the audit trail, and it means every document can be reprocessed when a better OCR engine arrives without going back to the sender. From there the model does the part it is genuinely good at, reading messy text and proposing a document type and a set of fields, and then it hands over.

What follows the model is plain code with no AI in it. The validation node re-checks the proposed total against numbers actually present in the OCR text, so a figure the model invented cannot survive. It catches impossible dates, such as a due date falling before the document date. It measures character quality to spot a scan that OCR'd badly, and it scores confidence from those signals rather than asking the model how sure it feels. Anything suspicious is flagged, not filed silently. The final stage writes a searchable PDF into its own folder and appends one row per document to the index: type, language, counterparty, number, dates, total, confidence, flags, summary, links and a snippet. That row is what makes the archive searchable, because a folder of PDFs is storage while an index is retrieval. Documents are processed one at a time with nothing shared between jobs, which is deliberately the shape that later splits into isolated workers without redesign.

Solution

All four documents came through the run. The English invoice gave up GBP 2,086.80 with its document number and due date. The Spanish delivery note returned EUR 3,613.50 with the language detected and its reference number read correctly. The contract page produced USD 84,000, flagged as an annual licence fee rather than a contract total, which is exactly the distinction that costs money when it is missed. The expense claim came back at 388.59 with a flag saying the document never stated a currency at all.

Those flags are the output I would point a client at first. Each document carries its own: VAT number spacing and ambiguous bank formatting on the invoice, no document number and three candidate dates on the contract, a missing customer tax ID on the delivery note, and line dates without a year on the expense claim. None of those stopped the pipeline, and none of them were hidden. The record arrives with its own list of what a human should look at, which is the difference between an archive you trust and one you have to spot check forever. Every original is still in place, unmodified, next to its searchable copy.

FAQ