Automating invoice processing with Large Language Models introduces a subtle but expensive failure mode: the confident hallucination of a single digit in a bank account number. While tools like n8n and Gemini excel at extracting vendor names and totals from PDFs, they lack the deterministic logic to verify that an International Bank Account Number (IBAN) is mathematically valid. A new developer workflow addresses this gap by decoupling extraction from validation, using a dedicated Cloudflare Worker API to perform ISO 13616 mod-97 checksums before any payment is processed.

The Extraction Pipeline

The foundation of this automation is a free n8n template designed to triage incoming Gmail messages. The workflow triggers on unread emails labeled 'invoices' containing PDF attachments, splitting multi-invoice emails into separate items for individual processing. It employs Google's Gemini model with a Structured Output Parser to extract critical data pointsβ€”including vendor, invoice number, PO number, dates, currency, and line itemsβ€”into strict JSON format. By setting the temperature to 0 and enforcing a rigid schema, the system ensures that malformed responses fail loudly rather than silently corrupting the ledger. A subsequent normalization step uses code to verify that subtotal plus tax equals the total, flagging low-confidence rows for human review.

Deterministic Validation via Cloudflare

Extraction confidence scores do not guarantee that an IBAN is real, which is why the developer implemented a separate validation layer. Hosted on Cloudflare Workers, this API checks IBANs against country-specific length requirements and the mod-97 checksum algorithm. It also validates BIC formats, EU VAT numbers via the VIES service, UK VAT checksums, and US EIN prefixes. The choice to use a Worker rather than a standard n8n Code node prioritizes reusability across different platforms like Zapier or Make, while also isolating the latency of external checks. For instance, if the VIES service is throttled or unavailable, the API returns a 'checked: false' status with a reason, preventing false negatives that would otherwise block legitimate payments.

Integrating the Two Systems

To wire these components together, developers must extend the Gemini schema to include vendor_iban and vendor_vat fields. After the normalization step, an HTTP Request node sends these values to the validation API's batch endpoint. The system is designed to fail open to a human, never closed to the ledger; any identifier that fails validation or times out is routed to a 'needs review' state. This approach acknowledges that while LLMs are probabilistic, financial infrastructure requires deterministic verification. By treating valid: false as a review flag rather than an automatic rejection, the workflow maintains high throughput while mitigating the risk of sending funds to non-existent accounts.

Key Takeaways

  • LLMs can hallucinate valid-looking IBANs; deterministic checksums are required for financial safety.
  • Strict JSON schemas in n8n prevent silent failures during data extraction.
  • Decoupling validation into a Cloudflare Worker allows for reuse across Zapier, Make, and custom backends.
  • Always fail open to human review when external validation services like VIES are unavailable.

The Bottom Line

LLMs are powerful extractors but terrible auditors; this workflow correctly separates probabilistic guessing from deterministic validation. Treating every AI-generated payment detail as 'guilty until verified' by a checksum is the only safe way to automate finance.