How to Use n8n with ._Template 122 Invoice Nfe Processor Multimodal
Invoice processing is where finance operations quietly bleed hours. A Nota Fiscal Eletrônica (NF-e) arrives as a PDF, sometimes as an XML, sometimes as a photo of a printout someone scanned on their p
Invoice processing is where finance operations quietly bleed hours. A Nota Fiscal Eletrônica (NF-e) arrives as a PDF, sometimes as an XML, sometimes as a photo of a printout someone scanned on their phone. Someone on your team opens it, reads the supplier name, the CNPJ, the total, the tax breakdown, and the line items, and retypes all of it into your ERP or spreadsheet. Multiply that by a few hundred invoices a month and you have a full-time job that produces zero strategic value and a steady trickle of transcription errors.
The problem: NF-e data is structured, but not in a form you can use
The Brazilian NF-e is technically a structured document — there is an official XML schema behind it. In practice, though, the file that lands in your inbox is rarely the clean XML. It's the DANFE, the printed representation, exported to PDF or scanned to an image. The data you need is trapped in a visual layout: tables that wrap across pages, tax fields in tiny fonts, a barcode with the 44-digit access key, and supplier details in a header block.
Traditional OCR gets you partway. It reads characters, but it doesn't understand that "V. Total da Nota" is the invoice total and that the number next to "CNPJ" is the supplier tax ID. You end up writing brittle regex rules and coordinate-based field extraction that breaks the moment a supplier changes their invoice layout. That fragility is why most teams give up and keep a human in the loop.
The ._Template 122 Invoice NFe Processor Multimodal solves this differently: it treats the invoice as an image and asks a multimodal AI model to read it the way a person would — understanding context, not just characters — and to return clean, validated JSON.
The solution: a multimodal extraction pipeline in n8n
The template wires together a small, focused pipeline. An invoice enters, gets normalized into an image the model can see, is passed to a vision-capable LLM with a strict extraction prompt, and comes out the other side as structured data that flows straight into your accounting system. Because the model reads the visual document directly, it tolerates layout variation across suppliers without any per-vendor configuration.
The core idea is that "multimodal" means the model receives the actual pixels of the DANFE plus a text instruction describing the exact fields you want. It handles wrapped tables, low-quality scans, and inconsistent formatting far better than rule-based parsing, and it returns the same JSON shape every time so your downstream nodes never have to guess.
Step-by-step: building the workflow in n8n
Here is how the pipeline fits together node by node. If you're importing Template 122 directly, these are the pieces you'll be configuring.
1. Trigger node. Start with an Email Trigger (IMAP) node pointed at your accounts-payable inbox, or a Webhook node if invoices arrive from a portal or upload form. For batch processing of historical invoices, a Schedule Trigger paired with a Read Binary Files node pointed at a folder works well. The trigger's only job is to hand the workflow a binary file.
2. Branch by file type. Add a Switch node that inspects the incoming MIME type or file extension. If the file is already the official NF-e XML, route it to an XML node and skip the AI entirely — parsing native XML is free and perfectly accurate. Only PDFs and images should go down the multimodal path. This branching keeps your token spend low and your accuracy at 100% whenever the clean source exists.
3. Normalize to an image. Vision models read images, not PDFs. For PDF invoices, use an Execute Command node calling pdftoppm -png -r 200 input.pdf output (from poppler-utils) to rasterize each page at 200 DPI. That resolution is the sweet spot: high enough that small tax fields stay legible, low enough to keep the payload manageable. Photos and PNGs pass through untouched. Follow this with an Edit Fields (Set) node to base64-encode the binary so it's ready for the API call.
4. The multimodal extraction node. This is the heart of the template. Use the Anthropic node (or an HTTP Request node calling the Claude API directly) with a vision-capable model such as claude-opus-4-8 for the hardest, densest invoices, or claude-haiku-4-5 when you want speed and lower cost on cleaner documents. Attach the base64 image as an image content block, and in the text block provide a precise system prompt: instruct the model to return only JSON matching a fixed schema — supplier_name, supplier_cnpj, access_key (the 44-digit chave de acesso), issue_date, total_value, tax_icms, and a line_items array with description, quantity, unit price, and NCM code. Tell it explicitly to return null for any field it cannot read rather than guessing.
5. Enforce structure. Feed the model's response into a Structured Output Parser (if you're using the LangChain nodes) or a Code node that runs JSON.parse inside a try/catch. This is your guardrail: if the model ever returns malformed output, you catch it here and route to a manual-review branch instead of poisoning your ledger. Pair it with an IF node that validates the CNPJ is 14 digits and the access key is 44 digits — cheap checks that catch the vast majority of misreads.
6. Deliver the data. With clean JSON in hand, the final nodes are boring in the best way. A Google Sheets, Postgres, or HTTP Request node writes the invoice into your ERP or accounting platform. Add a Merge node if you want to reunite the AI-extracted records with the XML-parsed ones into a single output stream before writing.
Benefits: what you actually get back
The payoff is concrete. A clerk who spent three minutes per invoice now spends zero on the ones that pass validation, and maybe thirty seconds reviewing the small percentage flagged for manual check. At a few hundred invoices a month, that's the better part of a work-week reclaimed.
Accuracy improves too, counterintuitively. Humans transpose digits when they're bored; a validation layer that checks CNPJ length and access-key format catches errors no tired employee would. Because the model reads visually, onboarding a new supplier with an unfamiliar invoice layout requires no development work — the pipeline just handles it. And every invoice lands as consistent JSON, which means your reporting, reconciliation, and audit trail all get cleaner as a downstream effect.
Common pitfalls and how to avoid them
Skipping the XML shortcut. The single most common mistake is sending every document to the vision model. If the native NF-e XML is available, parse it — it's free, instant, and exact. Reserve the multimodal path for PDFs and scans. Your Switch node at step 2 is what enforces this discipline.
Low-resolution rasterization. Rendering PDFs at 72 DPI to save bandwidth is a false economy. Tax fields and NCM codes become unreadable and the model starts guessing. Stay at 200 DPI. If a supplier's scans are genuinely poor, that's exactly the case where the more capable model earns its cost.
Trusting output without validation. Never write model output straight to your ERP. Always pass through the JSON parser and the format checks. The goal isn't to remove humans entirely — it's to route only the uncertain cases to them. A workflow with no manual-review branch will eventually book a hallucinated total, and one bad ledger entry erodes all the trust you built.
Ignoring rate limits and cost on batch runs. When you backfill thousands of historical invoices, add a Loop Over Items node with a small batch size and a brief wait between calls. This keeps you under API rate limits and lets you monitor spend before committing to a full run.
Not logging the raw response. Store the model's full JSON output alongside the parsed record. When something looks wrong two weeks later, that log is the difference between a five-minute fix and an afternoon of guessing what the model saw.
Start with a single supplier's invoices, confirm the extracted fields match reality for a couple dozen documents, then widen the trigger to your whole inbox. Within a day you'll have an invoice pipeline that runs itself and only asks for help when it genuinely isn't sure.