The French e-invoicing mandate: what it means for your software (2026-2027)

France is moving all invoicing between businesses to structured e-invoices. Since 1 September 2026, every VAT-registered business established in France must be able to receive e-invoices, and large companies and mid-caps must issue them. Small and medium businesses follow on 1 September 2027. An e-invoice is not a PDF sent by email: it is a structured file, in Factur-X, UBL or CII format, sent through a platform approved by the French tax authority (the DGFiP).

If you run business software or a SaaS product that issues invoices to or for French companies, this changes how your invoices are built and how they travel. This article explains the mandate from a developer's point of view, with an example we know from the inside: Izi-Devis, the quoting and invoicing software for tradespeople that LPR Studio builds and runs itself, and that we are preparing for the mandate right now.

The timeline

The dates come from the tax authority's official guidance (in French). Two practical points follow:

• A French SME must already have chosen a receiving platform, even if it does not issue e-invoices yet, because its larger suppliers already send them.
• An SME may start issuing before 2027. For a software vendor, this is the window to test with real customers before the deadline.

The e-invoicing obligation covers transactions between businesses established in France. Sales to consumers and operations with foreign businesses are handled by e-reporting instead: the French company reports the amounts to the tax authority through its platform, on the same timeline.

What your software has to change

Invoicing rules stay the same. What changes is the format and the route.

A structured format. Invoices must use one of three formats: UBL, UN/CEFACT CII or Factur-X. The first two are pure XML; Factur-X is a hybrid, covered below.

Four new mandatory fields. Since 1 September 2026, French invoices must also show:

• the customer's SIREN, the French company registration number;
• the category of the operation: supply of goods, supply of services, or both;
• whether the supplier has opted to pay VAT on debits (on invoicing rather than on payment), where relevant;
• the delivery address of goods, when it differs from the billing address.

For a software product, each one is a field to add, validate and, above all, backfill for existing customers. The customer SIREN matters most: it is how the receiving platform is found.

A mandatory approved platform. The supplier no longer sends the invoice straight to its customer. It hands it to its approved platform, which looks up the customer in a central directory run by the tax authority and forwards the invoice to the customer's own platform. Along the way, the platform extracts the data the tax authority needs.

A lifecycle. Each invoice gets statuses: submitted, rejected, made available, approved, disputed, paid. Your software can read them to show where each invoice stands, and some must be published by the parties themselves.

Factur-X, UBL or CII?

All approved platforms must accept all three formats. The right choice depends on who receives your invoices.

Factur-X is a human-readable PDF, built to the PDF/A-3 archiving standard, with a CII XML file embedded inside. A customer without specialised tooling sees a normal invoice; their platform reads the XML. It is the easiest format to adopt for software that already produces PDF invoices, and the one most small French businesses use. The specification is published by the FNFE-MPE, the French e-invoicing association, jointly with its German counterpart (the German name is ZUGFeRD).

UBL and CII are pure XML, common between large companies and across Europe. UBL is also the format of the Peppol network, which many EU countries use. If your product already speaks Peppol UBL, you are closer to compliance than you may think, but the French data requirements still apply.

The detail that trips most teams up is the Factur-X profile, which sets how much data the XML carries:

The exact list of accepted profiles is set by the French standard AFNOR XP Z12-012, which is still evolving, so check with your platform. In practice, EN 16931 is the safe choice.

Three automated checks prevent most rejections:

1. Validate the XML against the schema (XSD) and business rules (schematron) of the Factur-X version you target.
2. Validate the PDF/A-3 with a tool such as veraPDF: embedded fonts, declared colour profile. A PDF generated "the usual way" almost never passes.
3. Check VAT consistency: the VAT category of every line, reverse charge, exemptions. This is where the hardest-to-explain rejections come from.

Connecting your software to an approved platform

The tax authority separates two roles. An approved platform is registered with the DGFiP to transmit invoices and tax data; the official list is published on impots.gouv.fr. A compatible solution is software that produces compliant invoices and is connected to at least one approved platform. That is what your product needs to become.

An API connector has five building blocks:

• Onboarding each customer company on the platform, with its SIREN and identity checks, then registering it in the central directory as a recipient.
• Issuing: when an invoice is finalised, generate the file, submit it and store the reference the platform returns.
• Tracking statuses, by polling or through notifications, so users see the state of each invoice without logging in elsewhere.
• Receiving: fetch supplier invoices, parse all three formats and display them cleanly.
• Edge cases: consumer customers, missing SIREN, recipient not found in the directory, platform downtime. Each needs a defined path, never a silent failure.

The same principles as any integration apply: one source of truth per piece of data, and exchanges that recover cleanly after an outage. Choosing a platform is also a vendor decision, worth the same care as any other: see avoiding vendor lock-in.

A real example: preparing Izi-Devis for the mandate

Izi-Devis is quoting and invoicing software for French tradespeople, designed, built and run by LPR Studio itself. Its users are exactly the businesses facing the 2027 deadline: one-person to small companies billing both consumers and professionals. Here is where it stands, without embellishment.

Factur-X has been live since September 2026. An option in the company settings embeds an EN 16931 XML file in the PDF of every new invoice. The XML is checked against the Factur-X schema and business rules before it is embedded. One deliberate choice: if embedding fails, the invoice is still finalised as a regular PDF. A tradesperson should never be blocked from invoicing by a technical error.

The new mandatory fields are in the documents. The category of the operation (goods, services or mixed) and the VAT-on-debits option are set per document; they print on the PDF, and the category feeds the XML. The customer's SIREN is carried in the XML, along with late-payment penalties and the fixed recovery fee that French invoices must mention.

The connection to an approved platform is built and in testing. It was developed in October 2026 and runs today on the partner platform's test environment, on internal accounts, before opening to tradespeople. What already works in testing:

• Guided onboarding: SIREN, legal representative and VAT regime are pre-filled; the platform then checks identity and company registration, and the business is registered in the directory to send and receive.
• Automatic submission when an invoice, deposit invoice, progress invoice or credit note is finalised. A PDF/A-3 compliant copy is produced for the platform, and temporary errors are retried automatically.
• Cases where e-invoicing does not apply: consumer customer, missing SIREN, recipient not in the directory. The invoice is then emailed as before, and the user sees why.
• Lifecycle status tracking, polled every five minutes and shown in plain language on each invoice.
• Receiving supplier invoices in all three formats (CII, UBL and Factur-X), on a dedicated page.

What is not done yet, stated as such: e-reporting of consumer sales, publishing statuses from the user's side (disputing a received invoice, declaring a payment), and a few data points still incomplete in the XML, such as a separate delivery address and reverse-charge encoding. They are planned before the September 2027 deadline.

Lessons that apply to any software product:

1. Never block invoicing because of the e-invoicing chain: provide a fallback, and tell the user.
2. Test compliance automatically: our tests generate a sample invoice and credit note and run them through veraPDF, the reference PDF/A validator, whenever the chain changes.
3. Start with the data: a reliable SIREN on every business customer is worth more than any feature.
4. Roll out gradually: a few accounts first, on the test environment, then production.

A checklist before September 2027

If your company uses business software that issues invoices in France, or you build a SaaS that invoices on behalf of French customers:

1. List what you issue (invoices, deposits, credit notes) and to whom: French businesses, consumers, foreign companies.
2. Clean the data: customer SIRENs, VAT category per line, delivery addresses.
3. Pick the format: Factur-X with the EN 16931 profile for SME customers, UBL or CII for customers with automated pipelines.
4. Pick an approved platform with a documented API and a test environment, and check it on the official list.
5. Build and test the connector on that environment with real cases: credit notes, deposits, reverse charge, customers without a SIREN.
6. Plan for e-reporting if you also sell to consumers or abroad.

For a small business, an off-the-shelf invoicing tool is often enough: many vendors already offer a compatible version. It becomes a development project when invoicing lives inside custom business software, or when you build the software that issues invoices yourself. Our guide to choosing a tech stack for business software covers the wider build decisions.