Extracting data from PDF invoices with AI in n8n: OCR, LLMs, and structured output

A small business that receives thirty supplier invoices a week easily loses two to three hours re-typing them into its accounting tool: invoice number, date, net amount, VAT, supplier reference. The work is repetitive, error-prone, and adds no value. This is exactly the kind of task n8n can automate end to end: receiving the invoice, reading its content, extracting the useful fields in a reliable format, then storing or exporting the result to your management tool. This guide covers both possible architectures and the concrete pipeline to build.

Two approaches to reading a PDF invoice

Not all PDF invoices look the same to a machine. An invoice generated by software (Stripe, an online accounting tool, an ERP) contains genuinely selectable text. A scanned or photographed invoice is just an image: there's no text to extract until optical character recognition has happened.

For a native text PDF, the Extract from File node (n8n-nodes-base.extractFromFile) is enough: it pulls the raw text content out of the document, with no external dependency or API cost. It's the fastest and cheapest option when your suppliers send clean PDFs.

For a scanned PDF or a photo, two options exist:

• Classic OCR then an LLM: a dedicated service (Google Cloud Vision, Mistral OCR, Nanonets) first turns the image into text, which is then passed to a language model for structured extraction. This is the most robust approach at high volume or with complex tables (multiple line items), since these tools specialize in layout recognition.
• Direct multimodal LLM: recent models (GPT-4o, Claude, Gemini) read an image or PDF directly with no separate OCR step — you send them the file encoded in base64 and they extract the text and structure in a single pass. Simpler to set up for moderate volume, with a single API key to manage instead of two separate services.

In practice, start with the direct multimodal LLM: it covers the majority of cases with a single node and a single credential. Only switch to a dedicated OCR service if you're processing hundreds of documents a day (lower per-unit cost) or very dense line-item tables where a specialized OCR proves more reliable than a general-purpose model.

Building the pipeline in n8n

1. Trigger

Three common sources depending on your setup:

• Email attachment (IMAP or Gmail Trigger): the invoice lands directly in a dedicated inbox (e.g. invoices@).
• Watched folder (Google Drive Trigger or Dropbox): your suppliers or team drop the PDFs there.
• Webhook: an upload form or another tool pushes the file via POST.

In all three cases, the trigger node must produce a binary (the PDF file) usable by the following nodes — check the binary property field (data by default) in the node settings.

2. Extracting the text

• Native text PDF → Extract from File, PDF mode, plain-text output.
• Scanned PDF → convert the binary to base64 (often automatic depending on the model node), then call a vision-capable Chat Model (OpenAI GPT-4o, Anthropic Claude, Google Gemini) with the file attached to the message.

3. Structured extraction with an LLM chain

Whether the text comes from Extract from File or a vision LLM, the next step is identical: a Basic LLM Chain (chainLlm) paired with a Structured Output Parser that enforces a precise JSON schema. It's the same mechanism we cover in our guide to getting started with n8n's AI nodes — applied here to a concrete case. A typical invoice schema:

{
  "invoice_number": "string",
  "invoice_date": "string (YYYY-MM-DD format)",
  "supplier": "string",
  "amount_excl_tax": "number",
  "vat_amount": "number",
  "amount_incl_tax": "number",
  "currency": "string",
  "line_items": [
    { "description": "string", "quantity": "number", "unit_price": "number" }
  ]
}

The chain's prompt needs to be explicit about ambiguous cases: what to do when a field is missing (return null, never invent a value), how to normalize dates, and which amount to rely on when several appear (deposit, balance). This prompt rigor is what separates a usable extraction from a half-hallucinated JSON blob.

Validating and storing the data

Before any storage step, add a logic-validation step in an IF or Code node: the net amount plus VAT should match the total to the cent, the date should fall within a plausible range, and the invoice number should never be empty. These simple checks catch the majority of failed extractions without an extra call to the model.

For storage, a Supabase table (extracted_invoices) is the most flexible option: it later enables queries, dashboards, or syncing to your accounting tool. Our guide to connecting n8n to Supabase covers setting up credentials and insert queries. For a team more comfortable with spreadsheets, a direct export to Google Sheets works just as well to get started.

Handling the hard cases

No extraction pipeline reaches 100% automatic reliability, and that isn't the goal: the goal is to only send a human the cases that are genuinely ambiguous.

• Handwritten invoice or poor scan quality: if the model returns a low confidence score or null fields on critical information (amount, supplier), route the invoice to manual review rather than inserting it as-is. The human-approval pattern with the Wait node and Slack buttons, covered in our dedicated article, fits perfectly here: a Slack message displays the extracted fields, and a click approves or corrects them before final insertion.
• API call failure (timeout, model error): set up a dedicated Error Workflow to catch these failures and notify someone, rather than silently losing the invoice — see our guide on error handling in n8n.
• Duplicates: before inserting, check with a Supabase query whether an identical invoice number for the same supplier already exists, to avoid double entries if the same email gets forwarded by accident.

Costs and volume

For an economical multimodal LLM (something like GPT-4o mini or equivalent), a one- to two-page invoice costs on the order of a few cents in input tokens (the image weighs more than plain text, but it's still marginal against the human time saved). Beyond a few dozen documents processed in a burst (say, importing a month of archives), pace your calls to avoid 429 errors — our article on OpenAI and Anthropic API rate limits in n8n details tuning Loop Over Items and the Wait node for exactly this case.

Going further

This pipeline — trigger, extraction, structured output, validation, storage — mirrors the exact architecture of the document-ingestion workflow in the RAG Assistant Pack (€119), except the goal here is extracting precise fields rather than semantic search. If your needs go beyond simple extraction and include a full audit trail (who processed which invoice, when, with what result), the Compliance & Audit Pack (€149) provides the ready-to-connect Supabase logging building block behind this kind of pipeline.