France E-Invoicing Technical Guide: Formats, Data Flows, and Integration
A technical guide to French e-invoicing: the end-to-end 5-corner flow from ERP to PA to buyer and DGFiP, integration options (API, EDI, portal), mandatory fields, lifecycle statuses, and a build checklist.
Table of Contents
If you are the person who actually has to build the integration, the marketing summaries only get you so far. You need to know what leaves your ERP, where it goes, what shape it has to be in, which fields will get an invoice rejected if they are missing, and which statuses you are expected to send back. This guide is written for that person.
France's dématérialisation des factures reform, run by the tax authority (DGFiP), turns invoicing into a structured, platform-mediated, reported process. Reception becomes mandatory for everyone from 1 September 2026, and issuance for large and medium-sized companies from that same date and for small and micro businesses by 1 September 2027, with no further delay planned. This is the technical walkthrough: the data flow, the integration options, the mandatory fields, the lifecycle statuses, and a checklist to build against. Throughout, you will see how Complyance, as an Approved Platform (Plateforme Agréée, or PA), handles the parts you would otherwise build yourself.
The End-to-End Data Flow (5-Corner Model)
France operates a strict 5-corner model. (The country dropped the earlier planned Y-model at the end of 2024.) Invoices do not pass through a single government clearance portal on their way to the buyer. Instead, all B2B e-invoices flow exclusively through certified Approved Platforms (PA). The central Portail Public de Facturation (PPF) is no longer a transmission platform. It acts only as the Central Directory (annuaire) and Data Concentrator for the DGFiP.
Here is the path a domestic B2B invoice takes:
- 1. Supplier ERP generates the invoice.
Your ERP or billing system creates the invoice data, ideally already carrying the mandatory fields.
- 2. Supplier's PA validates and converts.
Your Approved Platform checks the invoice against EN 16931 and French rules, confirms the mandatory fields are present, and converts it into an authorised format (Factur-X, UBL 2.1, or CII).
- 3. The PA locates the buyer via the PPF Central Directory.
Using the PPF annuaire, the platform finds which PA serves the buyer.
- 4. Transmission to the buyer's PA.
The supplier's PA transmits the invoice to the buyer's PA, which delivers it to the buyer.
- 5. Lifecycle statuses flow back.
The buyer's platform returns lifecycle statuses (submitted, rejected, refused, cashed, and others) that travel back to the supplier.
- 6. Data is reported to the PPF / DGFiP.
The platforms transmit the required invoice and e-reporting data to the PPF Data Concentrator for the DGFiP. For B2C and cross-border transactions, the same platform submits e-reporting (transaction and payment data) instead of a structured invoice.
The shape of the flow, in one line:
Supplier ERP -> Supplier PA -> [PPF directory lookup] -> Buyer PA -> Buyer
| |
+--------------> PPF / DGFiP <-----------+
(invoice + e-reporting data;
lifecycle statuses returned)Two things fall out of this design. First, you never integrate directly with the government portal for issuing and receiving. You integrate with your PA. Second, both you and your buyer can be on different PAs and it still works, because the PPF Central Directory connects them.
Integration Options
There is no single "right" way to connect to a PA. The best option depends on your systems, your volume, and your team. Most PAs, including Complyance, support several.
| Integration option | How it works | Best for | Trade-offs |
|---|---|---|---|
| API (REST) | Your systems call the PA's API to submit invoices, fetch statuses, and pull reporting data in real time | Product teams, ERPs with dev resources, high automation | Needs developer effort up front; most flexible and real-time |
| EDI | Structured batch exchange (e.g. scheduled file transfers) between your system and the PA | High-volume, established EDI shops, large enterprises | Robust for volume; less real-time; EDI expertise needed; non-authorised formats such as EDIFACT must be converted by the PA |
| Portal upload | Finance staff upload or key invoices into the PA's web portal manually | Low volume, teams without dev resources, a fallback path | No integration effort; manual, so it does not scale |
1. API is the default for anyone building into an ERP or product. It gives you real-time submission, status retrieval, and error feedback, and it is the easiest to automate end to end.
2. EDI suits organisations that already run batch EDI at scale and want to extend those pipelines rather than adopt a new API surface. Note that EDIFACT is not an authorised French format, so the PA converts it into an authorised structured format before transmission.
3. Portal upload is the safety net, useful for low volumes, edge-case documents, or teams that are not ready to integrate before the deadline. During the transition period (until December 2027) you may also send plain PDFs to your PA for conversion while you finish the automated path.
A good PA lets you mix these: automate the bulk through API or EDI, and keep portal upload available for exceptions.
The Four New Mandatory Fields
On top of the legal mentions French invoices already require, the reform adds four new mandatory fields. If your ERP does not populate these, invoices will fail validation. Map them early.
| Field | What it is | Note |
|---|---|---|
| Buyer SIREN | The buyer's 9-digit legal identifier | Mandatory on domestic B2B invoices; make sure your customer master data captures it |
| Delivery address | The address where goods are delivered | Required when it differs from the billing address |
| Nature of the operation | Indicator for goods, services, or both | Drives VAT logic and reporting classification |
| VAT-on-payments option | Flag for when VAT is due on payment (*option pour le paiement de la TVA d'après les encaissements*) | Signals VAT timing, especially for services |
The one that most often surprises teams is buyer SIREN: many ERPs do not currently store a reliable SIREN for every customer. Auditing and enriching your customer master data is frequently the longest lead-time task in a French e-invoicing project. Start it now.
Lifecycle Statuses
French e-invoicing is not fire-and-forget. As an invoice moves through its life, lifecycle statuses (statuts de cycle de vie) are exchanged between platforms and, for some, reported to the DGFiP. The AFNOR XP Z12-012 specification defines 14 possible statuses, of which 4 are mandatory. The rest (for example Paiement transmis, payment sent) are optional.
The 4 mandatory statuses (must be handled):
- Déposée (submitted). The invoice has been submitted/deposited into the system.
- Rejetée (rejected). A technical refusal; the invoice failed validation or could not be processed.
- Refusée (refused). A commercial refusal; the buyer rejects the invoice on business grounds.
- Encaissée (cashed). Payment received; particularly important for services, because it marks when VAT becomes due.
Optional statuses (good practice, better cash-flow visibility):
- Received, approved, partially approved, in dispute, Paiement transmis (payment sent), and similar milestones that give both parties clearer visibility. These are among the 14 defined statuses but are not mandatory.
For your integration, this means two-way handling: your system must be able to send statuses (for invoices you receive) and consume statuses (for invoices you issue). The mandatory set (Déposée, Rejetée, Refusée, Encaissée) is the non-negotiable minimum. A PA typically manages the exchange and surfaces statuses to you through the API or dashboard.
Issued --> Déposée --> Received --> Approved --> Encaissée
|
+--> Rejetée (technical)
+--> Refusée (commercial)
(bold in spec: Déposée, Rejetée, Refusée, Encaissée are mandatory)Integration Checklist
Use this as a build plan. It moves from data readiness through connection to go-live.
1. Audit your invoice data.
Confirm your ERP can produce every EN 16931 business term you need, plus the four new mandatory fields. Flag gaps.
2. Enrich customer master data.
Capture a reliable buyer SIREN and, where relevant, delivery addresses for every B2B customer. This is usually the long pole.
3. Choose your format(s).
Decide your internal standard (Factur-X, UBL 2.1, or CII), knowing your PA can convert as needed, including non-authorised inputs such as EDIFACT.
4. Pick your integration method(s).
API for automation, EDI for high-volume batch, portal upload as a fallback. Many teams use API plus portal for exceptions.
5. Handle lifecycle statuses both ways.
Build to send and consume statuses, covering the four mandatory ones (Déposée, Rejetée, Refusée, Encaissée) at minimum.
6. Cover e-reporting.
Make sure B2C and cross-border transactions route to e-reporting (transaction data roughly every 10 days, payment data monthly), not just B2B e-invoicing.
7. Test in a sandbox.
Validate payloads, simulate rejections and refusals, and test conversions and status flows before touching production.
8. Plan resilience.
Handle retries and queuing so a downstream outage does not stop your invoicing.
9. Go live before the deadline.
Reception is mandatory for everyone from 1 September 2026; large and medium-sized companies must also issue from that date. Build in buffer.
Why Choose Complyance as Your Approved Platform?
Everything above is buildable, but most of it is undifferentiated plumbing you would rather not maintain. Complyance provides it as an Approved Platform (PA), so your team builds once and stays compliant.
1. One API for the whole flow
Submit invoices, retrieve lifecycle statuses, and pull reporting data through clean, predictable REST APIs, with no direct wrangling with the PPF.
2. Format handling built in
Complyance generates and converts Factur-X, UBL 2.1, and CII, converts non-authorised inputs such as EDIFACT and plain PDFs, and validates every invoice against EN 16931 and French rules before transmission.
3. Mandatory fields and statuses managed
The platform enforces the four new mandatory fields and handles the four mandatory and the optional lifecycle statuses in both directions.
4. E-invoicing and e-reporting together
Domestic B2B invoices and B2C/cross-border reporting run through one integration, so nothing is missed.
5. Developer-first, with fallbacks
A sandbox with test data, human-readable errors, and prebuilt ERP integrations for developers, plus portal upload for teams that are not ready to integrate.
6. Resilience and continuity
Invoices queue safely during downstream outages and send when service resumes, so operations never stop.
Ready to build against an Approved Platform?
Complyance gives your developers one API for formats, flows, statuses, and reporting, with a sandbox to test it all before September 2026. Explore Complyance to start.
Conclusion: Build Once, Stay Compliant
France's e-invoicing model is a well-defined system: a strict 5-corner data flow through Approved Platforms, three authorised formats, four mandatory fields, a set of lifecycle statuses, and a parallel e-reporting obligation. Get the architecture right once and the mandate becomes manageable. Work through this checklist before you ship:
- Audit your ERP data against EN 16931 and the four mandatory fields
- Enrich customer master data with buyer SIREN and delivery addresses
- Choose your internal format and integration method
- Build two-way lifecycle status handling (four mandatory statuses at minimum)
- Route B2C and cross-border transactions to e-reporting
- Test every flow in a sandbox, then plan resilience and go-live
Integrate against an Approved Platform that owns the plumbing, and your team spends its time on your product instead of on compliance edge cases.
Related posts
Frequently Asked Questions
It is the model where all B2B e-invoices flow exclusively between certified Approved Platforms (PA) rather than through a government transmission portal. The supplier's PA transmits to the buyer's PA using the central PPF Central Directory, and both platforms report invoice and e-reporting data to the PPF Data Concentrator for the DGFiP. France dropped the earlier planned Y-model at the end of 2024, and supplier and buyer can be on different PAs.
No. For issuing and receiving invoices, you integrate with your Approved Platform (PA), not directly with the PPF. The PA handles validation, format conversion, transmission, and reporting to the DGFiP on your behalf. The PPF itself is only a Central Directory and Data Concentrator.
Three common ones: API (real-time REST integration, best for automation and ERPs), EDI (batch exchange, best for high-volume enterprises), and portal upload (manual entry through a web portal, best for low volume or as a fallback). Many teams combine API for the bulk with portal upload for exceptions.
Buyer SIREN, delivery address (when different from billing), nature of the operation (goods, services, or both), and the VAT-on-payments option. If your ERP does not populate these, invoices will fail validation. Buyer SIREN in particular often requires enriching your customer master data.
Under AFNOR XP Z12-012 there are 14 possible statuses, and 4 are mandatory: Déposée (submitted), Rejetée (rejected, a technical refusal), Refusée (refused, a commercial refusal by the buyer), and Encaissée (cashed). Others, such as Paiement transmis (payment sent), are optional. Your integration must be able to send and consume these, which a PA typically manages for you.
It should. Domestic B2B transactions are handled through e-invoicing, while B2C and cross-border transactions require e-reporting (transaction data roughly every 10 days, payment data monthly) to the DGFiP. An Approved Platform such as Complyance covers both through a single integration, routing each transaction to the correct flow.
About the Author
Swathy
Content Marketer
I’m a Content Marketer at Complyance, focused on e-invoicing. Over the years, I’ve created a wide range of content, including blog posts, whitepapers, and product guides, which have supported Complyance’s growth across markets such as the UAE and EU regions. My goal is to deliver content that is comprehensive, clear, accurate, and easy to understand, no matter how complex the topic.
