One Month into France’s E-Invoicing Mandate: What We Have Learned

France’s e-invoicing reform went live on 1 September 2026. After a little more than a month in production, we now have enough real-world experience to look beyond specifications, test environments and implementation guides.

At Arratech, France has become our largest single source of customer support activity. We analysed the support cases raised by our customers before and after go-live to understand where the actual friction has been.

The perhaps surprising conclusion is that exchanging an invoice is rarely the difficult part.

Most questions have instead been about onboarding taxpayers, choosing the right participant identifiers, switching between Plateformes Agréées (PAs), understanding lifecycle statuses, handling French invoice formats and knowing exactly where the responsibility of the customer ends and that of the PA begins.

We have listed some of the things we have learned.

1. Onboarding and KYC create more questions than invoice transport

The single largest category of France-related support cases concerned taxpayer onboarding and KYC.

Customers repeatedly asked what documentation was required, who should provide it, when a company could be activated and how the mandate appointing a PA should be handled.

This was also one of our own early operational bottlenecks.

Initially, some KYC and approval steps required manual intervention from Arratech. That may work when onboarding a few companies, but it does not scale when partners suddenly want to onboard their entire customer base of taxpayers right before a regulatory deadline.

We therefore worked to automate the onboarding steps that do not require our direct review.

Our lesson: in a national e-invoicing infrastructure, onboarding is part of the digital infrastructure. It cannot be treated as an administrative process sitting beside it.

2. Identifiers are deceptively complicated

One of the most frequent sources of confusion has been identifiers.

France combines several identifier schemes, each with its own purpose. A French company's Peppol participant identifier uses scheme 0225, the French electronic address, which is built on the company's SIREN and may be extended with a SIRET, a routing code or a suffix. Within the invoice itself, the company's legal registration identifier is its SIREN under a different scheme, 0002.

Combine Peppol identifiers, SIREN and SIRET with the routing data in the French Annuaire, and it becomes easy to make mistakes.

Our lesson: documentation should not simply list valid identifiers. It should explain which identifier goes where and why.

3. PA switching started almost immediately

We expected migration between PAs to become important eventually.

We did not expect it to become so important immediately.

Within the first weeks we were already handling companies moving both to and from Arratech, including bulk migrations involving many taxpayers.

One particularly interesting situation occurred when a taxpayer tried to join us, only to discover that it already had a PA without knowing it. Its address in the Annuaire was already linked to another platform, and that link had to be changed correctly before the switch could happen.

Initially, parts of our migration process were too time-consuming. That quickly proved unsustainable and we are now automating it as far as possible. Changing PA should be no more remarkable than bringing a Peppol ID to another Service Provider and updating the SMP record.

Our lesson: provider portability is a fundamental property of a well-functioning e-invoicing and tax reporting ecosystem.

4. Lifecycle statuses are a new integration problem of their own

Sending the invoice is only the beginning.

The French model introduces lifecycle statuses, a.k.a CDARs, that allow the parties and the tax authority to track what happens to an invoice. Customers needed to understand which statuses Arratech generates automatically, which statuses their own application must generate, and how those statuses travel between the network participants and PAs.

This becomes especially important for software vendors integrating once with Arratech while serving many underlying businesses.

Our objective has been to hide as much of the French complexity as possible. Where appropriate the customer submits a status once, and we generate the messages that the other PA and the French public infrastructure each require..

Our lesson: a good PA API should expose the business event, not force every ERP or invoicing platform to recreate the entire French network architecture.

5. Factur-X raises an interesting question: what is the invoice?

Factur-X takes a distinctive approach to combining human-readable and structured invoice information.

A Factur-X invoice is a PDF/A-3 document containing a structured XML invoice as an embedded file. The PDF is the visual representation that a person can read, while the XML contains the structured information that receiving software can process.

This is essentially the reverse of the approach commonly used with Peppol BIS Billing, where the structured XML is the business document and binary content, like a PDF representation, can be carried as an attachment.

Having two representations of the same invoice raises an obvious question: what happens if the PDF and XML disagree?

Which amount, payment term or bank account is the real one?

The answer is less settled than one might expect. The Factur-X specification treats the PDF as a whole, including the embedded XML, as the invoice, and for France it sets no rule on which part prevails. It does note that the tax administration may consider the structured data to be the source of invoice information for tax purposes, and in France it is the structured data that the PA uses to report to the tax authority. Germany has made this explicit. For ZUGFeRD, which is very similar to Factur-X, the Federal Ministry of Finance has issued guidance stating that the structured XML is leading if the two differ, and the Factur-X specification itself now states that in Germany the embedded XML is the invoice. In France, we are still waiting for the same clarity.

Our lesson: hybrid invoices might provide the best of both worlds for humans and software, but implementations need to treat the structured data as authoritative and ensure that the visual representation remains consistent with it.

6. Cross-border invoicing adds another dimension

A French company does not suddenly stop trading internationally because France introduces a domestic e-invoicing mandate.

We have therefore received several questions about the interaction between the French regulated model and ordinary Peppol traffic.

Can the same company receive domestic French invoices and invoices from foreign suppliers? Which processes need to be published in the Peppol SMP? Does a company need multiple registrations? What happens when a foreign Peppol Access Point tries to reach a French recipient?

This is particularly relevant to Arratech because many of our customers operate across several jurisdictions.

Our lesson: national e-invoicing systems must never be designed as islands. Domestic compliance and international interoperability need to coexist.

7. E-reporting may be harder to understand than e-invoicing

Another recurring source of questions has been e-reporting.

For a traditional B2B invoice, the mental model is relatively straightforward: an invoice moves from supplier to buyer and relevant information is reported to the tax authority.

B2C and certain international transactions are different. The reporting model, aggregation rules and payment information do not necessarily correspond to B2B invoice exchanges over Peppol.

This distinction matters particularly for businesses with large consumer transaction volumes.

It also means that an integration with a French PA cannot simply be viewed as “adding another invoice transport protocol”.

Our lesson: e-invoicing and e-reporting should be explained and implemented as related but distinct processes.

8. Some of the biggest problems were our own

The first month also exposed weaknesses in our own implementation.

We had manual processes that did not scale. Some France-specific documentation arrived too late. We encountered issues with Factur-X and the French Extended profile. Some assumptions inherited from conventional Peppol implementations did not fit every French use case.

That is exactly why production experience matters.

Specifications tell you what a piece of software is supposed to do. Production traffic tells you what customers actually try to do.

The important measure for us is therefore not whether support tickets occur, but whether each recurring ticket results in better documentation, automation or product behaviour.

Our lesson: France uses Peppol for exchange between PAs but adds its own rules on top, and how those differences play out in practice can only be learned in production.

What surprised us most

Looking across the support cases, one pattern stands out.

Most problems were not caused by the actual transport of invoices.

They occurred at the boundaries between systems and organisations: Who represents this taxpayer? Which PA currently controls its registration? Which identifier should be used? Which party sends a CDAR and which of them are mandatory? Which rules apply to this particular invoice? Is this domestic e-invoicing, cross-border Peppol or e-reporting?

This is an important lesson for France, but we believe it applies much more broadly.

As more countries introduce continuous transaction controls (CTC) and regulated e-invoicing networks, the difficult part will increasingly be orchestration rather than transport.

The infrastructure needs to manage identities, capabilities, routing, regulatory reporting, lifecycle events and provider changes, while presenting a relatively simple interface to the ERP, accounting platform or invoicing application above it.

One month down, many lessons to come

France’s new model is still young.

Since 1 September, all businesses within the scope of the reform must be capable of receiving electronic invoices, while large companies and intermediate-sized enterprises (ETIs) have also entered the mandatory issuance phase. The ecosystem of businesses, software vendors and PAs is consequently learning in production at considerable scale.

For Arratech, the first month has already changed parts of our platform and our thinking.

We have automated processes that were manual at launch, improved France-specific documentation, fixed issues exposed by real production traffic and learned considerably more about how customers actually integrate with the French model.

And that may be our biggest lesson from the first month:

Going live is not the end of an implementation. It is when you finally start learning how users and the network actually behave.

LET’S TALK ABOUT FRANCE