France's e-invoicing mandate lands 1 September 2026. The developer's playbook.

The deadline nobody can opt out of

On 1 September 2026, every business established in France that is subject to VAT - whether or not it actually charges it, so micro-entrepreneurs under the franchise en base are included - must be able to receive electronic invoices through the new national system. Not "should". Must.

The issuance side is phased (large and mid-sized companies start the same day; SMEs and micro-businesses follow on 1 September 2027), but reception applies to everyone at once, on day one.

And France just raised the stakes. The 2026 Finance Law increased the penalty for failing to issue an invoice electronically from €15 to €50 per invoice (capped at €15,000 per calendar year), and the fine for missing e-reporting transmissions from €250 to €500 per transmission - and note that transaction data and payment data are two separate reporting obligations, each with its own €15,000 annual cap (official summary). These penalties bite as each company category's obligations kick in - September 2026 for the first wave, 2027 for the rest.

There's a grace mechanism for a first offence - fix it spontaneously or within 30 days of a first administrative request and the fine is waived - but it's a narrow safety valve, not a strategy.

If you build B2B SaaS with French business customers - billing, vertical management software, anything that touches invoices - this is not only your customers' accountants' problem. It's a systems integration problem too, and your users are about to ask where e-invoicing lives in your product.

This article is the developer's playbook: what the French reform actually requires from a software stack, how it differs from the Peppol-native mandates you may have read about (Belgium's, for instance), and what you can realistically wire up today.

What the law actually requires

The French reform has three moving parts. In order of how soon they bite:

Reception, for everyone, from day one. From 1 September 2026, all VAT-subject businesses established in France must be able to receive structured electronic invoices. Their suppliers' invoices will arrive through the new platform network - not as PDF attachments in an inbox. To be reachable, a business needs to be connected to an accredited platform and listed in the central directory (annuaire).

Issuance, phased by company size. Large companies (grandes entreprises) and mid-sized companies (ETI) must issue their B2B domestic invoices electronically from 1 September 2026. SMEs and micro-enterprises get one more year, until 1 September 2027.

E-reporting, on the same calendar. Most transactions that fall outside the B2B domestic mandate - B2C sales, cross-border flows - must be reported to the tax administration on a schedule, following the same phased timeline as issuance. The exact scope has carve-outs (certain exempt operations and imports, among others), defined by Article 290 of the tax code - worth checking against your customers' transaction mix rather than assuming.

The accepted formats are the three from the "socle": UBL 2.1, UN/CEFACT CII, and Factur-X (the Franco-German hybrid PDF+XML format). All three are EN 16931-compliant formats.

France is not Belgium: the accredited-platform model

If you followed Belgium's mandate - in force since 1 January 2026, with a tolerance period that ended on 1 April - unlearn one assumption: France did not simply adopt Peppol as the transmission network.

The French architecture routes invoices through plateformes agréées ("PA" - accredited platforms; you'll still see the older term PDP, plateformes de dématérialisation partenaires, in a lot of writing). These are private operators vetted and registered by the DGFiP, France's tax administration. Around a hundred platforms have been accredited so far - the official list of accredited platforms is public.

The state's own portal, the PPF (portail public de facturation), was originally going to be a free exchange platform for everyone. That plan was scrapped: the PPF's role has been reduced to running the central directory (which platform serves which business) and acting as the data concentrator that forwards invoice data to the tax authority. The directory itself has been live since 2025 - what changes on 1 September 2026 is that the legal obligations start biting.

Every invoice exchange happens platform-to-platform.

Here's my take, and I'm genuinely curious whether French devs agree: dropping the free public exchange portal turned compliance into a market. Every VAT-subject business in France now needs a relationship with a private platform to satisfy a legal obligation. You can read that as pragmatism (running B2B invoice exchange for every company in France is a very different beast from Chorus Pro's B2G scope) or as quietly outsourcing a public mandate to a hundred vendors. If you're building in France, it changes your integration reality either way - there is no "just use the government API" escape hatch.

So the flow looks like this:

[ Supplier ] → [ Supplier's accredited platform ] → [ Buyer's accredited platform ] → [ Buyer ]
                     │                                                                    │
                     └────────── tax data ────────────────┘
                                          ↓
                               [ PPF / DGFiP ]

If the shape looks familiar, it should - it's a four-corner model with a tax-authority listener, structurally close to what Peppol calls the five-corner model. And the convergence is not accidental: in July 2025, the DGFiP became the Peppol Authority for France. Accredited platforms interoperate, and Peppol is one of the rails that interoperability increasingly runs on.

If your product already speaks Peppol for Belgium or another market, you are architecturally most of the way there - but for France, the invoice must transit through an accredited platform, and your integration needs to account for that.

Why your engineering team owns this

Here's the checklist the mandate implies for any software that issues or manages invoices for French businesses:

• Generate invoices in a structured EN 16931 format (UBL 2.1, CII, or Factur-X) - PDF export doesn't count
• Route them through an accredited platform (you almost certainly don't want to become one - accreditation is a regulated, audited process)
• Resolve recipients through the central directory. Note that the regulated French flow defines its own addressing: the external specifications use a dedicated routing scheme (0225) keyed on SIREN granularity - distinct from the generic Peppol identifiers you may already know
• Receive inbound invoices and lifecycle statuses through the same channel
• Handle the mandatory invoice status lifecycle - France defines four compulsory statuses (déposée, rejetée, refusée, encaissée - that last one feeds VAT pre-filling), a heavier lifecycle than most Peppol markets require
• Keep e-reporting in mind for the transactions the mandate doesn't cover

Little of that lives in a finance tool alone. Most of it lives in your codebase - with your auth, your retry logic, your webhooks, your audit trail. The realistic split is shared: your customers' accountants and platforms handle the fiscal side; the product they run their business on handles the data and the integration.

And the reception deadline is the sneaky one. It has its own enforcement path: a business that isn't connected to an accredited platform can be put on formal notice by the tax administration, gets three months to comply, and only then faces a €500 fine, followed by €1,000 for every further three-month period until it's fixed. On top of the legal stick, there's the operational one - suppliers will start pushing invoices through the network from September, phased over 2026-2027, and a French business whose management SaaS can't surface inbound e-invoices will feel the gap immediately.

A TypeScript path

Here's where getpeppr fits - with the availability boundaries stated upfront, because you should hold every vendor to that standard: getpeppr is a TypeScript-first e-invoicing API, live on the Peppol network today (Belgium in production), and its French CTC leg is in a free pilot programme, not general production. More on that in a minute.

The developer experience: a JSON object goes in, a validated EN 16931 invoice goes out. One API key, and for multi-tenant SaaS, one integration serving N legal entities.

npm install @getpeppr/sdk

import { Peppol } from "@getpeppr/sdk";

const peppol = new Peppol({
  apiKey: process.env.GETPEPPR_API_KEY!,
});

const result = await peppol.invoices.send({
  number: "INV-2026-042",
  buyerReference: "PO-2026-114", // Peppol requires a buyer or order reference
  date: "2026-09-01",
  dueDate: "2026-10-01",
  to: {
    name: "Acme SARL",
    peppolId: "0009:12345678200002", // 0009 = SIRET scheme (synthetic, Luhn-valid)
    street: "10 rue de la Paix",
    city: "Paris",
    postalCode: "75002",
    country: "FR",
  },
  lines: [
    {
      description: "SaaS subscription - August 2026",
      quantity: 1,
      unitPrice: 490,
      vatRate: 20,
    },
  ],
});

To be precise about what this is: a generic Peppol send - the way French companies are addressed on the Peppol network today. The regulated French CTC flow adds its own routing on top (the 0225 scheme mentioned above) and runs through an accredited platform; that's the leg currently in pilot.

The SDK (v2 on npm) validates your JSON locally before anything leaves your process; the API then generates the UBL and runs full EN 16931 validation server-side.

And because a playbook should cover more than the happy send, the two pieces most teams underestimate:

// Before sending: is the recipient reachable, and for which document types?
const recipient = await peppol.directory.lookup("0009:12345678200002");

// After sending: delivery is asynchronous. Your webhook endpoint receives
// invoice.accepted / invoice.refused / invoice.error events, signed with
// HMAC-SHA256. Inbound invoices arrive on the same surface, as
// inbound.invoice.received events.

The sandbox is free and unlimited - sk_sandbox_ keys deliver to test recipients only, so you can wire up the send flow end-to-end (validation errors, webhooks, error handling) without touching production networks. A first sandbox invoice is an afternoon of work in a typical Node.js codebase; the full integration - reception, status lifecycle, retries, your data model - is a proper engineering project, which is rather the point of starting now.

Now the honest part, in full. France's CTC flow is not something getpeppr serves in general production today: getpeppr is not an accredited platform. The French leg runs through Storecove, an accredited platform registered with the French tax administration. The France flow is in a pilot programme - currently being validated, not generally available. The pilot is free (€0/month, €0/invoice) in exchange for test cases and feedback. Final compliance always depends on your own flow validation and obligations. No API vendor replaces tax or legal counsel - anyone claiming otherwise is overselling.

Why mention a product whose France flow is still in pilot? Because that's the actual state of this market, seven-ish weeks out. The accreditation list is still being populated, and most vendors' French pipelines are younger than they sound. Whoever you evaluate, ask the same three questions: is your French flow live or in pilot? Which accredited platform carries it? How many real French invoices has it processed? The answers are more informative than any landing page.

Belgium vs France, side by side

Two mandates, one direction of travel - and the EU's ViDA reform makes structured e-invoicing the default for intra-EU B2B by 2030.

Next steps

If you're a developer at a SaaS with French business customers, three things worth doing before September:

1. Map your invoice surface. Where do invoices get created, stored, and displayed in your product? Reception is the day-one obligation - where would inbound e-invoices even land today?

2. Check how your customers are addressed. French businesses resolve through SIREN/SIRET identifiers in the central directory. If you don't store those cleanly, start there - it's a data model fix, not an integration.

3. Wire the Peppol flow in a sandbox. getpeppr's docs - free sandbox, no sales call. If the French pilot is relevant to you, it's open for applications at hello@getpeppr.dev.

1 September 2026 isn't a soft launch. The directory has been live since 2025, the platforms are interconnecting now - what arrives in September is the obligations, and the fines behind them. The teams that treat this as an engineering project now will be the ones whose September is boring.

Over to you

I'd rather this be a discussion than a lecture, so - honestly:

• If you build SaaS for French businesses: are you integrating e-invoicing into your product, or telling your customers to sort it out with their accountant's platform? Both are defensible; I'm curious where the line falls.
• If you're already live on Peppol (Belgium, the Nordics, Singapore): does the French accredited-platform model look like fragmentation to you, or a reasonable local adaptation that Peppol interop will eventually paper over?
• If you've looked at the pilot phase or talked to a plateforme agréée: what's the one integration detail you wish you'd known earlier?