Invoices, delivery notes, contracts: most of them arrive as PDF, a good share as scans or as phone photos from the warehouse. Someone types the values over. This is slow, error-prone and wearing for the people who have to do it. With Claude as the reader and n8n as the conductor, this can be automated reliably.
Why classic OCR templates break
Classic document capture works with templates: for each supplier you define where invoice number, date and total sit on the page. That works as long as nothing changes. Then one supplier redesigns their invoice, the next adds a second page with extra line items, the third sends a crooked scan. Every deviation means a new template or a wrong value that only surfaces in accounting.
Claude reads documents differently. The model understands what an invoice is, where the total usually sits, and that "Gesamtbetrag", "Total" and "amount due" mean the same thing. It handles scans, photos and multi-page PDFs and needs no template per supplier. The price: you have to tell the model very precisely what you want back.
Schema first, then the prompt
The most important step happens before the first call. We define a JSON schema for the result. It fixes which fields exist, what type they have and which are mandatory. Claude receives this schema and returns data only in this shape.
{
"document_type": "invoice",
"supplier_name": "string",
"supplier_vat_id": "string | null",
"invoice_number": "string",
"invoice_date": "YYYY-MM-DD",
"po_number": "string | null",
"net_total": "number",
"vat_total": "number",
"gross_total": "number",
"currency": "EUR",
"line_items": [
{ "description": "string", "quantity": "number", "unit_price": "number", "amount": "number" }
],
"confidence": "number between 0 and 1"
}
The schema forces clarity. Should the delivery date be captured? Payment terms? Early payment discount? Every field in the schema gets filled, every missing field is lost. Delivery notes and contracts get their own schemas, often with a classification step in front that decides the document type first.
Validation: do not trust the model blindly
A language model reads well, but it does not calculate reliably and it does not know your master data. So n8n checks every result against fixed rules before anything moves on:
- Net plus VAT equals gross, to the cent. The line items add up to net.
- The VAT ID has the right format for the country and matches the supplier record.
- The PO number exists in the ERP and belongs to this supplier.
- The invoice date is not in the future and not years in the past.
- The invoice number has not been recorded for this supplier before.
These checks are deterministic, cost nothing and catch most reading errors. When a total does not add up, the model has usually missed a line or read a decimal point as a thousands separator. Those are the cases you want to see before they land in the ERP.
Confidence and review queues
Claude provides a confidence score for every extraction, per field if you ask for it. Together with the validation rules this gives three paths:
- All checks passed, high confidence: Straight into the target system.
- Checks passed, but low confidence or an unclear field: Into the review queue. A person sees the document next to the extracted values, corrects and approves.
- Check failed: Also into the review queue, with the specific error as a hint.
The review queue is not a sign that the automation is failing. It holds the cases someone had to look at closely before anyway, now with the groundwork done.
Writing to the target system
After approval, n8n writes the data where it is needed. Invoices go to the ERP or DATEV as incoming documents, delivery notes reconcile goods receipts against purchase orders, contract data such as term, notice period and conditions goes to the CRM or a contract database. To start, a spreadsheet someone keeps an eye on is often enough.
The original file is stored and linked to the extraction, so anyone who later doubts a number sees the document in one click.
Cost, data protection and error rate
Three questions come up in every conversation.
What does it cost? Billing is by processed pages, or more precisely by tokens. A one-page invoice is cheap, a forty-page contract is not. We control this through model choice: for standard documents a smaller, faster model is enough, for complex contracts we use the strongest one. The workflow also checks page count and file size up front instead of pushing every attachment through unseen.
Which data leaves the building? The document itself is sent to the API. This belongs in the data processing agreement and needs sign-off from your data protection officer. Claude is available directly from Anthropic as well as through Amazon Bedrock and Google Cloud, both of which offer regions inside the EU. Under the commercial API terms, inputs are not used for training. Have the current terms confirmed anyway. You can mask names or account numbers in n8n before transmission, but that often removes the information the model needs for matching.
How high is the error rate? Honest answer: it depends on your documents. Clean digital PDFs from known suppliers are read correctly almost every time. Poor scans, handwritten additions and unusual layouts produce more cases for the review queue. What we can say: the validation rules catch the bulk of reading errors before they do damage, and in our experience the remaining error rate is lower than manual entry. Measure it on your own documents: a test run with a few hundred from last quarter shows within days where you stand.
Takeaway
PDF extraction with Claude works when three things come together: a clear schema, hard validation rules and a review queue for the rest. Then typing becomes checking, and only for the cases that need it.
If you want to know what this looks like with your documents, book a free 30-minute intro call at /en#kontakt.