Mandatory e-invoicing in France from September 1, 2026: automating reception with n8n

On September 1, 2026 — a few weeks from now — every VAT-registered business in France, regardless of size, will need to be able to receive supplier invoices as structured electronic documents, through a Plateforme de Dématérialisation Partenaire (PDP, an approved e-invoicing operator). The obligation to issue invoices follows a staggered timeline: large companies and mid-caps from the same date, SMEs and micro-businesses from September 1, 2027. Many business owners and accounting firms have latched onto the 2027 date as a comfortable horizon — and overlooked that the reception requirement applies to everyone from day one. This guide explains what the reform actually changes and how to build, with n8n, a pipeline that receives, validates and logs your electronic invoices without manual re-entry.

What the reform actually changes

Three concepts worth separating before building anything:

• The format. A compliant electronic invoice is no longer "a PDF sent by email" — it's a structured document in Factur-X format (a PDF/A-3 file with an embedded machine-readable XML), UBL, or CII (pure XML). Factur-X is the hybrid format most widely adopted by French SMEs: it stays human-readable (the PDF) while carrying structured data (the XML) that a machine can process without OCR or AI re-reading.
• The channel. The Portail Public de Facturation (PPF), originally meant to serve as a free public solution, was dropped from that role in late 2024. Invoices now flow either through Chorus Pro (public contracts) or through a PDP — a private operator approved by the tax authority, which routes the invoice and simultaneously reports transaction data to the DGFiP (France's tax administration).
• The scope. Only B2B transactions between VAT-registered businesses established in France, plus transactions with the public sector, are covered. E-reporting (sales to individuals or foreign customers) follows separate rules, outside the scope of this article.

A 2024 study published in International Tax and Public Finance (Heinemann & Stiller, "Digitalization and cross-border tax fraud: evidence from e-invoicing in Italy," see on Google Scholar) measured the impact of Italy's 2019 mandatory e-invoicing rollout: cross-border VAT losses fell by €2.2–2.6 billion in the very first year, driven by much finer automated detection of reporting inconsistencies. That's exactly the logic behind the French reform — and why the structured format, not digitization for its own sake, sits at the center of the system.

Why automate instead of handling it manually

Receiving an electronic invoice through a PDP means receiving a data feed — a webhook notification or an API to poll — not a PDF landing in an inbox someone checks once a day. Without automation, two concrete risks appear: invoices piling up unprocessed (late payments, supplier penalties), and no reliable traceability in the event of a tax audit — precisely what the reform is designed to strengthen. n8n, already widely used for extracting invoice data from PDFs with AI or generating quotes and invoices, is a natural fit for this new link in the chain: structured reception.

Building the reception pipeline in n8n

1. Trigger on invoice arrival

Most PDPs support two integration modes: a webhook that notifies your system on every new invoice, or a REST API you poll periodically. The webhook is preferable at volume — no invoice slips through between two polling cycles — but it means properly securing that entry point: header authentication or signature verification, exactly as with any inbound webhook from a third party (Stripe, GitHub). With polling, a Schedule Trigger every 15 to 30 minutes is plenty for this kind of flow, paired with an HTTP Request node calling the PDP's "new invoices" endpoint.

2. Extract the structured XML from Factur-X

The Factur-X PDF you receive carries an embedded XML attachment (per the PDF/A-3 standard). Two approaches depending on your PDP: some expose the raw XML directly through their API — the simplest case, where an XML node converts the structure into usable JSON (see our n8n XML node guide) — while others only return the composite PDF, requiring you to extract the embedded attachment before parsing it. Either way, avoid routing this data through an LLM: unlike a scanned invoice with no structure, the Factur-X XML already contains the exact fields (invoice number, SIREN, amounts excl./incl. VAT, VAT rate, due date) — a plain XML parse is faster, free, and free of interpretation errors.

3. Validate required fields before integration

An IF or Switch node checks that required fields are present (issuer SIREN, invoice number, amount, applicable VAT rate) before any write to your accounting system. An incomplete or malformed invoice should trigger an alert branch rather than a silent integration — n8n's Error Workflow is the natural place to centralize these rejections and notify whoever owns the process (Slack, email) without blocking the rest of the flow.

4. Log and archive

This is where the reform directly connects to something already covered on this blog: the GDPR audit trail with n8n and Supabase. The principle is identical — an append-only, server-timestamped table tracking every received invoice, its validation status, and the action it triggered — except the driver here isn't GDPR but the legal obligation to retain invoices for ten years. Pair that tracking table with automatic archiving of the original PDF to S3 storage: structured data stays queryable in your database, and the source document stays available as-is in case of an audit.

5. Secure access to the PDP's API

The API key or OAuth2 token your PDP issues gives access to your entire invoicing flow — a secret as sensitive as a banking credential. Follow the same n8n credential management best practices you'd apply to any other critical integration: a dedicated credential rather than a shared one, periodic rotation, and never a raw key inside a Code node or a versioned environment variable.

Common pitfalls

• Waiting until 2027 because "we're an SME." The 2027 deferral only applies to issuing invoices. Reception is mandatory for everyone from September 2026 — a large supplier can legitimately start sending you electronic invoices from that date.
• Treating Factur-X like a PDF that needs OCR. That's an expensive misunderstanding: the embedded XML already contains the structured data, there's nothing to "guess" with an AI call.
• Forgetting e-reporting. Structured reception and issuing only cover domestic B2B; sales to individuals or foreign customers remain subject to separate reporting obligations — check with your accountant.
• Testing only with clean invoices. Before the deadline, deliberately feed your test workflow edge cases (missing field, zero amount, invalid SIREN) to confirm the error branch actually fires instead of silently breaking the workflow.

Wrapping up

Mandatory e-invoicing isn't a simple administrative checkbox — it's a new stream of structured data entering your information system, with a reception deadline shared by every business from September 1, 2026. n8n lets you build that pipeline — trigger on reception, Factur-X XML parsing, validation, logging, and legal archiving — with a handful of nodes and no custom development. If your immediate priority is precisely tracking and logging this kind of flow reliably and demonstrably, the Compliance & Audit Pack (€149) already ships a timestamped audit-trail SQL schema and the related follow-up workflows — a base you can directly reuse for the logging portion of your e-invoicing reception pipeline.