France's E-Invoicing Mandate Started September 1. Stripe Didn't Support SIRET as a Tax ID Until October 28.

On October 28, Stripe quietly added fifteen new tax ID types across five API surfaces at once — Customers, Tax IDs, Invoices, Tax Calculations, and Tax Transactions. Most of them are low-volume: Trinidad and Tobago VAT, Mozambique's NUIT, San Marino's COE. Three of them aren't low-volume at all. fr_siret, fr_siren, and fr_spi are the structured identifiers French businesses use for tax and commercial registration, and until that release, Stripe's billing stack had no native field for any of them. The problem is the date. France's e-invoicing mandate — the one that makes some version of this identifier a required invoice field — took effect almost two months earlier, on September 1.

That gap matters for a reason that's easy to miss if you only read the changelog entry as a tax-compliance footnote. A missing SIRET doesn't just create a filing problem for your own company. It creates a payment problem for your customer's AP team, at exactly the moment they're trying to pay you for a renewal.

What France actually requires, and when

France's mandate rolls out in two waves. Since September 1, 2026, every business established in France has had to be able to receive e-invoices — no exceptions by size. Large companies and ETI (mid-size, roughly 250+ employees or over the revenue threshold) also had to start issuing e-invoices and e-reporting their transaction data from that same date. SMEs and micro-enterprises get a second wave: September 1, 2027. The size cutoff for that later wave is fewer than 250 employees combined with turnover of €50 million or less, or a balance sheet of €43 million or less, measured against the last financial year closed before January 1, 2025.

The invoices themselves have to carry specific fields to be valid under the mandate: the buyer's SIREN, a category of operation (goods, services, or mixed), a delivery address when it differs from the billing address, and — once you're issuing — a mention for suppliers who've elected VAT-on-invoicing. Format matters too: a compliant e-invoice has to be structured as Factur-X, UBL, or CII, aligned to the EN 16931 standard, and routed through an approved private platform most sources call a PDP (plateforme de dématérialisation partenaire). A PDF emailed to accounts payable, however well-formatted, doesn't satisfy any of this.

None of those penalties are yours to carry if you're billing from outside France — the issuing and e-reporting fines in that table attach to businesses established in France, not to a US or UK SaaS vendor selling into it. But that's exactly why this is still your problem. Your French customer is the one living under that fine schedule now, which means their own AP and compliance process has gotten noticeably less forgiving about incomplete vendor data on anything crossing their books, foreign invoice or domestic. A finance team that's tightening its intake rules to stay clear of a €500 e-reporting penalty is not going to wave through an invoice that's missing the one registration field their new process checks for. They'll park it and ask you to fix it. For a subscription renewal, "parked and waiting on a fix" looks identical to a stalled charge — except nothing in your dunning stack was built to detect a tax-ID-shaped reason for non-payment, because until October 28, Stripe had nowhere to even store the value that was missing.

Why this isn't the VAT number you already collect

If you've been selling into France on Stripe for any length of time, you've probably already got eu_vat populated for most French business customers — that field has existed for years and most checkout flows that collect a VAT number for EU B2B reverse-charge purposes already capture it. It's tempting to assume that covers you. It doesn't. A VAT number and a SIREN are different identifiers serving different registries, and the mandate's required buyer field is specifically the SIREN — the 9-digit national company registration number, not the VAT ID. A French customer with a perfectly valid VAT number on file can still have an invoice bounced by their AP workflow for missing the SIREN, because that's the field the e-invoicing format actually checks for.

This is the same shape of problem we found in Stripe's new failed_tax_calculation error code: a billing-stack gap that doesn't look like a payment failure, doesn't fire a payment_failed webhook, and doesn't show up in any dashboard built around declined cards. The renewal invoice gets created and even finalizes fine on the Stripe side — the breakdown happens downstream, in your customer's own compliance pipeline, somewhere your churn reporting has no visibility into at all.

That jump from 7% to 60% in four months tells you two things at once. French businesses scrambled hard once the September deadline got close — and even after the scramble, 40% of them were still not fully ready for a mandate that was already live. That's the population your renewal invoices were landing on through the back half of 2026: a customer base actively tightening its own AP rules in real time, with Stripe's native fields for the one identifier that mandate cares about most not shipping until seven weeks after the deadline passed.

What to fix this week if you bill customers in France

• Add a SIRET/SIREN field to checkout and your customer settings page for any French business customer, using tax_id_data with type fr_siret or fr_siren on Customer create, or the Tax IDs API directly. This is additive — existing customers keep billing normally without it, which is exactly why it's easy to forget to backfill.
• Backfill your existing French customer base. Anyone who signed up before October 28 has no SIRET on file no matter how long they've been paying you. Pull your customer list filtered by country, and either prompt for it in the billing portal or reach out directly — don't wait for the first rejected invoice to find out who's missing it.
• Check what your invoice template actually renders. Having the field populated on the Customer object doesn't help if your invoice PDF or your e-invoicing integration doesn't surface it. Confirm the SIREN appears on the document your customer's AP system actually ingests, not just in your own database.
• Separate this from your normal churn and dunning categories. A renewal that stalls because a French buyer's AP team is blocking on a missing tax field isn't a save opportunity for a retention offer and it isn't a card problem your Smart Retries settings will ever touch. Run anything you suspect is this, rather than a genuine cancellation, through a churn calculator before it gets logged as a customer decision instead of a billing-data gap.
• If you also sell into Australia, New Zealand, Portugal, or Czechia, check the same release for au_acn, au_wpn, nz_bn, pt_nif, and cz_dic — Stripe shipped all five in the same October 28 batch, and each is a signal that a local tax authority has started expecting that identifier on commercial documents.

This lands in roughly the same place as Stripe's company_details addition to Billie: a structured identity field that doesn't change whether the underlying regulation applies to you, but does change whether your billing stack has anywhere to put the data the regulation now requires. A cancellation flow — ours included — is built to catch the subscriber who's actively trying to leave. It has no role to play in a renewal that's stuck in a French AP queue for a missing registration number, because that customer was never trying to cancel. They were trying to pay you, and your invoice didn't have the one field their compliance process was checking for.

Frequently asked questions

Stop losing subscribers today

One script tag. One function call. A live cancellation flow in under 10 minutes.