22 May 2026

France's E-Invoicing Mandate, Flow by Flow

Author: Roman Abilkhatov, D365 Finance Solution Architect

What every Dynamics customer needs to know before September 2026

A practical guide to France's E-invoicing mandate and the lifecycle statuses that come with them.

Written for finance leaders, programme directors and D365 architects who'd rather get this right the first time.

The short answer

On 1 September 2026, France switches on the largest e-invoicing reform in EU history. Every business established in France must be able to receive structured e-invoices from that date. Large and mid-size companies must also issue them and produce e-reporting data. SMEs and micro-companies follow on 1 September 2027.

Here's what makes this different from "another EU mandate". The DGFiP did not bolt e-invoicing onto an existing tax return. They built a 5-corner network where private accredited platforms route invoices between buyers and sellers, and a defined set of numbered flows pushes specific data to the tax administration. If your D365 system, your accredited platform, and the PPF cannot speak the same flow vocabulary, you cannot transact in France from September.

The flows you need to know are F1 (regulatory data to the tax administration), F2 (the invoice itself between platforms), F6 (the lifecycle status messages every invoice generates), F8 and F9 (specific e-reporting variants), F10 (the main e-reporting channel for B2C, cross-border and payment data) and F13/F14 (the directory operations that tell platforms where to send things).

That's the operating vocabulary. The rest of this piece walks through what each one does, what changes for Microsoft Dynamics customers, and what to do next.

Why this matters more than your average tax mandate

I've worked on Microsoft Dynamics finance transformations since the AX 4.0 days. Most country e-invoicing rollouts I've seen are variations on a theme: generate an XML, post it to a government endpoint, store the receipt. France is not that. France is a full network reform.

Three things make it different.

First, the 2024 redesign killed the original Y-model where the Portail Public de Facturation (PPF) would have handled invoice issuance for free. The PPF is now a directory and a data concentrator. Private Plateformes Agréées (PAs) do the routing. You must contract with one to operate in France from September 2026.

Second, the flow numbering is a real specification, not a vendor's marketing schema. The DGFiP "Spécifications Externes" v3.1 and the AFNOR standards XP Z12-012 (formats), XP Z12-013 (API) and XP Z12-014 (44 B2B use cases) define exactly which flow carries which data, in which direction, and with which sequencing rules. Get a flow number wrong in your design document and your SI's blueprint will fail review.

Third, this is the EU's biggest test case for the ViDA framework that lands in July 2030. France is where Microsoft, the major PAs, and the SI ecosystem are calibrating their playbooks. Whatever you build now will inform every country project that follows.

The architecture in 60 seconds: the 5-corner model

Before the flow numbers make sense, you need to visualize the picture they sit inside. The current model has five actors:

1. The issuer (supplier). Generates the invoice from their ERP.
2. PA-e. The issuer's accredited platform. Validates and routes.
3. PA-r. The recipient's accredited platform. Validates and presents to the buyer.
4. The recipient (buyer). Consumes the invoice from PA-r.
5. The PPF. Annuaire (central directory of buyers and their PAs), Data Concentrator (regulatory data hub) and lifecycle status receiver.

Default protocol between PAs is Peppol eDelivery, unless both PAs agree otherwise. Per industry tracking, 106 platforms had received definitive approval as of early 2026.

That's the topology. The flows are what travel across the lines.

The e-invoicing flows (B2B domestic)

These are the flows that move every domestic French B2B invoice from your D365 sales order to the buyer's inbox and to the DGFiP.

Diagram 1: B2B e-invoicing flows F1 (regulatory data to PPF), F2 (invoice between PAs) and F6 (lifecycle statuses).

Flow 2 — The invoice itself

F2 is the one most architects fixate on, and rightly so. It's the actual structured e-invoice in UBL, CII or Factur-X, moving from PA-e to PA-r. The PA-r then makes it available to the buyer.

What's in it: the full commercial invoice. Header, lines, tax breakdowns, payment terms, references, attachments. Everything the buyer needs to process the document in their AP system.

What carries it: by default, Peppol eDelivery. Two PAs can agree to use something else, but Peppol is the working assumption.

Why it matters for D365: this is what your Electronic Reporting (ER) configuration produces. The UBL 2.1 your ER format generates becomes the F2 payload that your PA submits onward.

Flow 1 — The regulatory data extract

F1 is the quieter twin of F2. While F2 moves between PAs, F1 carries a defined subset of the invoice data from PA-e to the PPF Data Concentrator.

The DGFiP doesn't want or need to handle every commercial detail of every invoice. They need the data the tax authority requires for VAT compliance, audit, and risk-scoring. F1 carries exactly that subset, no more.

Why it matters: F1 is what gives the DGFiP visibility without centralising the whole invoice ecosystem. From a D365 perspective, F1 is generated by your PA from the F2 payload. You don't build a separate F1 export. But your data model has to be clean enough that the F1 extract makes sense.

Flow 6 — The lifecycle statuses (CDAR)

F6 is the flow that catches most teams out, because it's not one message. It's a stream of them across the life of every invoice.

Four lifecycle statuses are mandatory and must reach the PPF:

1. Déposée (Deposited). Invoice has been submitted to a PA.
2. Rejetée (Rejected). PA validation failed (technical or format error).
3. Refusée (Refused). Recipient has commercially rejected the invoice.
4. Encaissée (Cashed). Payment has been received, where VAT-on-receipts ("TVA sur les encaissements") applies, including for down payments (acomptes).

Additional operational statuses are defined but not mandatory: Reçue (Received), En litige (In dispute), En attente (Pending), and so on. Some PAs will require more of these than others.

Each status is a CDAR message (Compte Rendu d'Acceptation/Refus) carried over the F6 channel. Each must be timestamped and stored against the originating invoice for the full ten-year archive.

Why this is the biggest D365 work item: you cannot just push an invoice and walk away. Your D365 environment must consume inbound CDAR messages from your PA, map them to status fields on the source invoice, and present them in a way Finance can act on. A "Refused" status means the invoice needs reissuing. "Cashed" closes the VAT timing question. Without this loop, you have an open-loop solution that will fail audit.

The e-reporting flows (B2C, cross-border, payment)

E-reporting is the second pillar of the reform. It catches everything the B2B e-invoicing network misses: sales to private consumers, sales to overseas buyers, purchases from overseas suppliers, and payment receipts where VAT timing depends on cash collection.

Flow 10 — The main e-reporting channel

F10 is where the bulk of e-reporting traffic goes. It carries:

1. B2C domestic transaction data. Typically aggregated per day, with total amounts and VAT per rate. No personal data on consumers ever flows to the PPF.
2. Cross-border B2B sales and purchases. Reported at the invoice level (identification numbers, VAT amounts, applicable rates, country of establishment, invoice references).
3. Cross-border B2C transactions. Aggregated and reported periodically.
4. Payment data. For services where VAT is due on payment receipt, and for down payments.

The DGFiP spec v3.1 sub-divides F10 into 10.1, 10.2, 10.3 and 10.4 across the annex documents, mapped to these transaction types. In day-to-day project conversation you'll mostly hear "F10" as a single shorthand, but if your PA contract references the sub-flows individually, that's why.

Once a PA submits an F10 transmission, the PPF runs technical and functional checks and returns a lifecycle message via F6 confirming whether the batch was accepted or rejected. Note the dual use of F6: in e-invoicing it tracks one invoice's lifecycle; in e-reporting it acknowledges a whole transmission file.

Flow 8 and Flow 9 — Alternative e-reporting variants

F8 and F9 sit alongside F10 in the v3.1 spec as alternative e-reporting channels. They cover transmission patterns that don't fit the standard F10 envelope, for instance specific reporting cases that the spec routes separately. They're less common in standard scope but every PA must support them, and your project's PA contract should confirm coverage.

Where you'll see them in practice: if a B2B invoice cannot be transmitted as a B2B e-invoice (for example, because the buyer is not yet registered in the Annuaire), the spec allows reframing the transaction through an e-reporting flow rather than the B2B e-invoicing flow. That's the tolerance the DGFiP built in to keep suppliers compliant when buyer-side onboarding is behind schedule.

Reporting frequency

This part trips up CFOs more than the flow numbers. The cadence depends on your VAT regime:

1. Standard monthly VAT regime. Transaction data three times per month (every 10 days). Payment data once per month.
2. Simplified regime / VAT franchise. Monthly or bimonthly.

Submission deadline is generally 10 days after the end of each period. Strict.

If you've already mapped out "every 10 days = three submissions per month" and built your D365 batch schedule around it, you're on the right track. Just remember that payment data follows a different (monthly) cadence under the standard regime, so two parallel schedules.

The directory flows: F13 and F14

The Annuaire (central directory) is what lets PA-e know which PA-r to route the invoice to in the first place. Every French business is registered with their chosen PA and their associated routing identifiers.

F13 and F14 are the flows that maintain that directory:

1. F13. PA submitting directory updates to the PPF (new buyer registrations, PA changes, routing updates).
2. F14. PA querying the PPF directory to resolve a buyer's current PA before sending F2.

These are infrastructure flows. You won't configure them in D365 directly. Your PA handles them on your behalf. But they matter for cutover planning: your PA must have your D365 entity registered in the Annuaire before you can issue your first F2 invoice.

A note on the missing numbers

You'll notice the numbering jumps. F1, F2, F6, F8, F9, F10, F13, F14. What about F3, F4, F5, F7, F11, F12?

Some are reserved, some were used in earlier versions of the specification and consolidated when the model moved from Y-shape to 5-corner in 2024, and some live in narrow circuits within the spec annexes. The v3.1 specification cleaned up the numbering significantly but kept continuity with earlier numbers for the flows that survived. Treat the eight flows above as the operating set for the September 2026 mandate and ignore the gaps. Your PA contract and your DGFiP-aligned design documentation will cover anything beyond that scope.

Formats: UBL, CII, Factur-X

Three formats are accepted. All three must comply with EN 16931 (the European semantic standard).

1. UBL 2.1 (Universal Business Language). XML, OASIS-managed, widely used across Peppol-aligned countries.
2. CII (Cross Industry Invoice / UN/CEFACT). XML, the more traditional EDI lineage.
3. Factur-X. Hybrid PDF/A-3 with embedded structured XML, designed for human readability plus machine processing.

Paper invoices and unstructured PDFs are not valid for B2B transactions under the mandate. Factur-X is the format that bridges the human-vs-machine debate cleanly, which is why it's the one most French SMEs are gravitating toward. UBL 2.1 remains the lingua franca for larger groups already running Peppol elsewhere in Europe.

D365 Finance ships Electronic Reporting (ER) format configurations for all three. Your job is to configure them correctly, not to build them from scratch.

What this means for Microsoft Dynamics customers

If you run D365 Finance and Operations, or any flavour of legacy AX from 4.0 through 2012 R3, the September 2026 mandate is a real implementation project, not a configuration tweak.

The standard Microsoft position is well-known to readers of our LinkedIn article on France e-Invoicing in Dynamics 365 Finance. Microsoft delivers the French e-invoicing functionality as part of the 2026 Wave 1 release, with the relevant capabilities landing in D365 F&O 10.0.48 at general availability in June 2026 and broader Wave 1 GA in August 2026. Microsoft's framework handles the heavy lifting: the invoice data model, the ER format configurations, the submission service, and the catalogue of country flows.

What Microsoft does not deliver, and what every D365 customer running in France will need to build or buy (unless they use EDICOM):

1. PA connector. The integration that pushes F1, F2, F6, F10 traffic to your chosen accredited platform (Ecosio, Pagero, Generix, Tradeshift, Docaposte, B2Brouter and others) and consumes the return traffic.
2. Inbound vendor invoice parsing. Your AP team must be able to pull F2 invoices in from PA-r, parse them into pending vendor invoice records, and run the matching and approval logic D365 already supports.
3. Lifecycle status mapping. The F6 CDAR stream needs to land somewhere meaningful in D365 against the source invoice, with audit trail.
4. Pre-submission validation. Catching errors before they hit your PA saves rejection cycles and protects your invoice numbering integrity.
5. Cutover orchestration. Annuaire registration, parallel run, hypercare, and the master-data prep (SIRET, IBAN, vendor and customer records) that makes or breaks readiness.

For legacy AX customers (AX 4.0, AX 2009, AX 2012, AX 2012 R3) the gap is bigger because Microsoft does not deliver Electronic Reporting natively to those versions. You either migrate to D365 F&O cloud (and the September 2026 mandate is the single strongest business case I've seen for that move), or you run a parallel compliance layer until you do.

Where Dr Dynamics fits

We've built and now operate a Dynamics e-invoicing connector that covers the full version range from AX 4.0 through D365 Finance and Operations. The connector configures Microsoft's standard Electronic Reporting where it's available, and provides the equivalent extraction and outbound layer for legacy AX versions where it isn't. Same flows. Same format compliance. Same lifecycle handling.

A few things we built in because we got tired of seeing other implementations skip them.

A built-in validator. Every outbound invoice is checked against the EN 16931 ruleset, the French CIUS profile, and the F1/F2 schema your PA expects, before it leaves D365. Pre-submission validation cuts rejection cycles by an order of magnitude. Most teams underestimate how much time their finance staff will burn chasing F6 "Rejected" statuses if the validator isn't there. We learned this the hard way on earlier country mandates. The validator is now standard in every deployment.

Configuration over code. The D365 connector deliberately sits on top of Microsoft's ER framework wherever possible. Wave updates land in your tenant the way Microsoft intends. Your team doesn't carry a fork.

PA-agnostic. You pick the Plateforme Agréée. We configure to their schemas. Switching PA later costs you a configuration pack, not a rebuild.

Live on real projects. We're already working with several organisations on their September 2026 readiness: a mix of large French groups, multi-entity multinationals with a French branch, and recovery engagements where a stalled SI implementation needed a finance-architect-led reset. The connector is being battle-tested in real conditions, not built to a spec sheet.

What to do this quarter

If you're a CFO, finance director or programme sponsor reading this in May 2026, the runway to September enforcement is four months. That's enough, if you start now.

This month: confirm your PA shortlist. Ecosio, EDICOM, Pagero, Generix, Tradeshift, Docaposte, B2Brouter are the names you'll hear most often. Sign the contract in parallel with implementation planning, not after.

Next month: lock down your D365 version. 10.0.48 (June 2026 GA) is the minimum to consume the standard French e-invoicing functionality natively. If you're on an older release, plan the update into your cutover schedule now.

By end of June: design workshop, master-data audit (SIRET, IBAN, customer and vendor records), validator integration plan.

July through August: build, SIT against your PA's sandbox, UAT, cutover. Microsoft's 2026 Wave 1 GA in August gives you a final tailwind, not a starting gun.

September: live, with a working F6 lifecycle dashboard and a validator catching errors before they hit the PA.

If you slipped that schedule by even six weeks, you have a problem. If you haven't started yet, the problem is bigger than it looks.

Cheat sheet: all eight flows for September 2026 in one shareable graphic.

Book a readiness call

A 30-minute call costs you nothing. You bring your PA shortlist, your D365 version, and whichever September 2026 question is keeping you up at night. We bring the architecture call, the connector demo, a walkthrough of the validator catching real-world F2 errors, and a straight answer on what your current SI is quoting.

The September 2026 enforcement date does not move because your project plan slipped. Start the conversation now.

Book a 30-minute readiness call • E-Invoicing for Dynamics AX & D365