France's e-invoicing mandate: Is your SAP ready for September?

France's e-invoicing mandate lands in September 2026, and the finance teams that will struggle with it are not the ones that ignored the law. They are the ones that treated it as a legal deadline, hired a compliance consultant, bought a platform license, and never looked at their SAP configuration until the integration project started. By then it is too late to do the work calmly. I have seen this pattern on SAP projects for the last decade: the law is the easy part, the system is where it gets expensive.

The deadline, and the gap under the awareness numbers

The facts are not in dispute. France's e-invoicing mandate begins in September 2026, phase 1 for large enterprises, with phase 2 for the mid-market following in 2027. The reform lands in the middle of a wider European sequence: five member states have e-invoicing deadlines arriving in quick succession, France first among the major economies, with Germany and Poland close behind. The European Commission's ViDA framework (VAT in the Digital Age) is the umbrella, and France is its first big implementation wave.

None of this is news to finance teams. That is the strange part. Accountancy Age reported in July that 86% of finance professionals know what ViDA is, while only 22% say they are ready for it. Awareness at 86%, readiness at 22%. The gap is work, and most of that work is configuration inside the ERP.

Think about what that gap means for your own team. If you run finance on SAP, you already know the mechanics of an invoice: which document type, which tax code, which account determination, which output. Every one of those decisions is configuration that exists in your system today. E-invoicing does not replace them. It adds a layer on top that reads them, validates them, and transmits them in a format the tax authority's platform accepts. A layer that strict does not forgive messy setup.

Why the bolt-on fails

Here is the mistake I keep seeing. A team reads the deadline, signs up with a third-party e-invoicing platform, and treats the project as an integration. The vendor will handle the formats, the network, the delivery receipts. All the customer has to do is connect the system and let the invoices flow.

The integration goes live in testing, mostly works, and then the rejections start. A supplier's VAT number is missing a digit in the master record. A customer master has two different addresses for the same entity, and the platform cannot decide which one is legal. An intercompany invoice uses a tax code that the validation rule does not know. A credit memo does not map to the original invoice number. None of these are platform problems. They are configuration and master data problems that have been sitting in the system for years, invisible, because nothing ever validated them.

The bolt-on framing is attractive because it keeps the SAP work small. That is exactly why it fails. E-invoicing compliance in SAP is a core FI/CO configuration decision disguised as an integration project, and it has to be made early enough that the system can be cleaned up before the platform starts rejecting its output.

What the configuration actually touches

In SAP, e-invoicing runs through Document and Reporting Compliance, or DRC. The name makes it sound like a reporting tool, which is misleading. DRC is a rules engine that sits over your existing FI and SD processes, and its rules only work if the configuration underneath is clean.

The FI side matters first. Account determination decides which GL accounts a document posts to, and tax codes decide which VAT rate applies, which exemptions are recognized, and how the document is declared. If your tax codes have drifted (a legacy code used by one plant, a special code for a long-gone promotion, a generic code that three departments share), the validation rules will flag documents that were always technically correct before. The invoice was fine; the configuration was not, and now there is a machine checking it.

The SD side matters just as much. Billing type, pricing procedure, output determination: they decide what an invoice contains, how it is delivered, and whether the system knows the difference between a standard invoice, a credit memo, and a down payment. France's mandate uses hybrid formats like Factur-X, where the same file carries a human-readable PDF and machine-readable XML. That XML is only as good as the underlying billing data. Garbage in, rejected in.

The counter-argument, dealt with honestly

I hear two objections when I make this point. The first: SAP ships standard e-invoicing add-ons, so the configuration is already handled. Partially true. Standard content covers standard scenarios, and France's specific requirements (Factur-X, PEPPOL routing, e-reporting in near real time) need mapping work in most systems. The second: most mid-market shops will use third-party platforms anyway, so why touch SAP at all? True, and irrelevant. The platform consumes what SAP produces. If the SAP side is dirty, the platform is where the dirt surfaces, at the worst possible moment, in front of a tax authority instead of in your own sandbox.

Both objections are really arguments for starting early. The more you plan to outsource, the sooner you need the SAP side stable, because the handoff is where the failure lives.

An e-invoicing readiness audit that starts with FI/CO

If I sat down with your team today, here is what I would do first. Not a legal review. Not a vendor demo. A configuration review, in this order.

1. Inventory the document types that will be e-invoiced. Standard invoices, credit memos, down payments, self-billing. List them, because each one needs a mapping decision and each one will be validated.

2. Review the tax codes in active use. Which are real, which are legacy, which are duplicated. This is where the rejects will come from, and it is the cheapest thing to clean up.

3. Check account determination for the document types above. The rules engine validates the posting, and a document that posts to the wrong account will fail even with a perfect VAT code.

4. Audit customer and vendor master data for the fields the formats require: VAT number, legal address, registration identifier. The platform cannot guess these, and they are wrong in a surprising number of systems.

5. Map the output chain end to end, from billing to the platform, and test it in a sandbox with the formats you will actually send.

The order matters. Master data cleanup and tax code review are boring, unglamorous, and they resolve most of the rejections before the project ever reaches the platform. If you start with the vendor, you will discover these issues later, under time pressure, in a language of error codes you do not yet speak.

The questions to answer before September

Three questions decide whether your project is a calm migration or an August fire drill. First: which legal entities and which document types are in scope for phase 1, and which can wait for phase 2? Second: who owns the output chain, the FI team or the SD team, and have they talked this quarter? Third: what happens to the invoices that the platform rejects, and who is on call to fix them in week one?

The third question is the one nobody asks, and it is the one that defines the experience. Every e-invoicing rollout has a rejection curve in the first weeks. The teams that handle it well have a defined owner, a defined process, and a monitoring view before go-live. The teams that handle it badly discover the rejections in the finance inbox, one forwarded error at a time.

What the wider European wave changes

It is tempting to read September 2026 as a single deadline and plan around it. That would be a mistake. France is the first large economy in a sequence, and the European framework behind it (ViDA) is heading toward a common standard across member states. Germany and Poland are already on the schedule. What you configure for France, with formats like Factur-X and PEPPOL, is largely reusable for the next wave. What you patch in a hurry for France, with hardcoded mappings and manual workarounds, you will have to rebuild for Germany.

This is the argument for doing the FI/CO work properly the first time. Compliance in September is the side effect; the real goal is an output chain that can absorb the next mandate with configuration changes instead of a new project. The teams that treat e-invoicing as a configuration discipline get that advantage. The teams that treat it as a one-off compliance task pay for it twice, once per country.

What ready looks like

Here is the outcome image I leave with clients who do this well. It is October 2026, a month after the mandate. Invoices are flowing to the platform, the rejection rate has dropped to a handful per week, and the person responsible for it can explain each one without opening a ticket. The tax code cleanup that happened in June turned up two legacy codes that had been quietly misstating output VAT for years, and fixing them was a byproduct of the project, not its purpose. The team did not need a hero sprint in August, because the hard work happened in the spring, in the system, in the configuration.

That is what readiness actually looks like: a clean output chain that a validation engine can read without flinching, not a signed contract with a vendor. The September deadline is coming either way. The question is whether you meet it with a configuration project or with a fire drill. Start with the FI/CO review. It is the least glamorous work on the critical path, and it is the work that decides the outcome.

Sources

• France E-Invoicing Mandate Sept 2026 - https://www.europe-infos.fr/

• 86% Know ViDA, 22% Ready - https://www.accountancyage.com/

• European E-Invoicing Deadlines: The Countdown - https://www.sharedserviceslink.com/

• ViDA (VAT in the Digital Age) - https://ec.europa.eu/taxation_customs/vat-digital-age_en

• E-Invoicing Compliance in S/4HANA: Document and Reporting Compliance - https://help.sap.com/docs/document-and-reporting-compliance

• PEPPOL e-Delivery Network Specifications - https://peppol.eu/