The French text is the legally binding one. This page is a working guide for a reader who does not read French; it is not a substitute for the instruments themselves, and wherever a decision turns on wording, the French wording governs.
Which formats must a plateforme agréée handle?
The principle is stated without ambiguity: approved platforms offer a minimum common set of formats shared across all plateformes agréées, and that common set is what guarantees the interoperability of exchanges. It contains three formats, all built on the European standard EN 16931:
- Factur-X — hybrid: a PDF/A-3 carrying an embedded XML file;
- UBL — Universal Business Language, structured XML;
- CII — Cross Industry Invoice, structured XML.
Every plateforme agréée must be able to issue in all three and to receive and process all three. Other formats may circulate between platforms by bilateral agreement, but only the common set guarantees that an exchange completes whichever operator sits opposite. That guarantee is the reason a group can standardise internally without negotiating format with each counterparty.
Two questions are worth putting to a candidate platform in writing, because the answers vary and neither is covered by the registration itself: which version of the spécifications externes it currently applies — 3.2 dates from 30 April 2026 — and whether it supports issuing, or only reception. The official list distinguishes operators meeting all conditions, interoperability tests included, from those whose registration remains conditional on passing them, marked sous réserve. A platform that receives all three formats but issues in only one will not tell you so unprompted.
Two structural points that a reader outside France usually has to be told. An opérateur de dématérialisation (OD) is not registered and cannot transmit to the administration on its own; it sits behind a plateforme agréée. And the portail public de facturation (PPF) neither issues nor receives any more: it keeps the central annuaire (CGI, art. 289 bis) and the concentrateur (CGI, art. 242 nonies G), and nothing else. There is no free public issuing channel to fall back on. Chorus Pro remains the public-sector (B2G) platform and is unaffected.
How do the three formats actually differ?
| Format | Structure | Readable without tooling | Typical use | Cross-border equivalence |
|---|---|---|---|---|
| Factur-X | Hybrid: PDF/A-3 + embedded XML | Yes — the PDF is a complete visual rendering | Exchanges with a human in the loop: business validation, small counterparties without deep integration, an archive someone will open | ZUGFeRD, its German twin, from version 2.0.1 |
| UBL | Structured XML only | No | Machine-to-machine flows, ERP-to-ERP integration, high volume | One of the two syntaxes retained by EN 16931, used in other European arrangements |
| CII | Structured XML only | No | Machine-to-machine flows, industrial and logistics sectors already tooled for it | One of the two syntaxes retained by EN 16931, used in other European arrangements |
Which question actually decides it?
Usually a single one: does a human being have to read this invoice in transit? If yes — because a buyer validates visually, because an accountant reconciles by eye, because the recipient is a small structure with no integration — Factur-X saves you producing and transporting a separate rendering. If no, XML alone is lighter, faster to validate and simpler to evolve. Between UBL and CII the criterion is almost always the installed base: keep the syntax your ERP, your platform and your partners already handle. Neither confers a regulatory advantage, and no plateforme agréée may refuse either.
What does each choice cost you downstream?
This is the part a compliance checklist does not cover, and it is where the money is. The format decision is cheap on the day it is made and expensive for the following decade, because it propagates into four places that are not the issuing pipeline.
Validation surface. Structured-only XML has one artefact to validate against the schema and the business rules. Hybrid has two, plus the invariant that binds them. Every specification release — and there have been three in eighteen months — has to be regression-tested against both parts, not one.
Human review. Structured-only XML is unreadable to the people who approve invoices. Somebody will build a viewer, and that viewer becomes an undeclared second rendering with exactly the divergence risk described below, except that this one is not even in the file. Factur-X pushes that cost into the format, where it is at least visible.
Archiving and retrieval. A hybrid file is self-describing years later: open it and you see what the counterparty saw. A structured-only archive is only as good as the tooling that reads it, and the tooling has to survive as long as the retention obligation. For a group that changes ERP every seven or eight years, that is a real dependency, not a hypothetical one.
Cross-border reuse. This is the item that most often reverses a decision taken on French grounds alone. If the same group entity also issues into the German mandate, an issuing chain built around the hybrid transposes with little rework, because ZUGFeRD from version 2.0.1 is the German twin of Factur-X — subject to checking the profile emitted, since the MINIMUM and BASIC-WL profiles are excluded there. If the estate is already structured-XML end to end for other European regimes, adding a hybrid rendering for France alone buys a maintenance burden for one market.
Reporting extraction. The same structured data has to feed e-reporting — the transmission of transaction data covering B2C operations, international operations and payment data for supplies of services — on a rhythm set by the entity's VAT regime, which under the régime réel normal with monthly VAT means transmission every ten days. A format whose structured part your systems can query directly makes that a mapping exercise; a format your systems treat as an opaque payload to be handed to the platform makes it a second extraction pipeline. This is the cost most often discovered after go-live, because reception projects never surface it.
The reasonable rule for a group: pick one format posture per issuing chain, not per country, and let France's neutrality between the three work for you rather than generating a French exception.
Why is the hybrid format an engineering trap?
In a Factur-X invoice, the XML is what counts. The structured part is the one that is processed, controlled and reported; the PDF is only a rendering. The rule is the same in Germany for hybrid formats: where the two diverge, the XML part prevails.
The consequence is nastier than it looks. If the PDF rendering and the XML diverge, the legally operative content is the one nobody read. A customer validates an amount on screen, approves it and pays — and the data transmitted to their platform, and onward, says something else. The gap does not announce itself at issuance. It surfaces at a reconciliation, an audit or a dispute, long afterwards.
The architectural rule that follows admits no exception: both parts must be generated from a single source of data, in the same processing run, from the same set of values. In information systems formed by sedimentation — which is most of them — the PDF comes out of a reporting tool and the XML out of an interface layer. Those two chains have their own rounding, their own truncation rules and their own refresh times. They will diverge. The question is not whether, but when, and whether you notice before your customer does.
For a group, add one specifically cross-border failure mode: a shared service centre that renders the PDF from the consolidation ledger and the XML from the local French ledger has built the divergence into the architecture. The two ledgers do not have to disagree by much. Under French invoicing rules, a mismatch can amount to two invoices for one transaction, and VAT stated in excess is a risk in its own right.
Are lifecycle statuses just acknowledgements?
No, and this is the second source of serious error. A status is a declaration with legal effect, not a technical ping. Four are mandatory.
| Status | Nature | What it commits |
|---|---|---|
| Déposée (deposited) | Technical | The invoice has been deposited on the issuing platform. |
| Rejetée (rejected) | Technical rejection by a platform | Format or business-rule non-conformity. The document does not enter the circuit. |
| Refusée (refused) | Commercial refusal by the recipient | Three admitted grounds only. Must not be used to formalise an ordinary disagreement. |
| Encaissée (collected) | Payment | Carries payment data where VAT is due on collection. |
The distinction between rejetée and refusée is the one English-language material most often flattens into a single word, and the consequences differ. The admitted grounds for refusal number three: a regulatory non-conformity not caught by the receiving platform — typically the absence of the purchase order required under article L441-9 of the code de commerce — an unrecognised transaction, and a breach of contractual conditions preventing processing. The administration is explicit that refusée must not be used for a simple commercial dispute.
A system that automatically projects internal error codes onto these normalised statuses should be audited on that point specifically, and on that point alone if time is short. Turning a price discrepancy into refusée issues a declaration the company did not intend to make. The definitions are set out in our glossary entry on rejetée and refusée.
Other statuses are recommended rather than mandatory: they circulate between plateformes agréées without being reported to the administration — mise à disposition, prise en charge, approuvée, en litige, suspendue, complétée, paiement transmis. That is where the commercial life of an invoice belongs, not in refusée: en litige exists for exactly this.
How fast do the specifications change?
Fast enough that a project scoped as a single compliance exercise is in debt on the day it ships.
| Reference | Version | Date |
|---|---|---|
| Spécifications externes B2B | 3.2 (in force) | 30 April 2026 |
| 3.1 | 31 October 2025 | |
| 3.0 | 18 December 2024 | |
| AFNOR XP Z12-012 — invoice message formats, profiles and lifecycle statuses | 1.3 | 26 February 2026 |
Two further standards complete the set: XP Z12-013, the API for interfacing company information systems with approved platforms, and XP Z12-014, the B2B use cases applicable under the reform. All three AFNOR documents and EN 16931 itself are paywalled, with no free official full text; we do not link them, and neither should a specification that expects its readers to check the citation.
One point of honesty: a version 1.4 of XP Z12-012, dated June 2026, is mentioned by secondary sources we have not been able to corroborate against a reference publication. Confirm the version in force with AFNOR before citing it in a specification or a contract. Three versions of the external specifications in eighteen months, plus business-rule updates on the standards side: size a format maintenance cycle, not a one-off implementation.
What does a foreign group have to decide that a domestic filer does not?
Four things, none of which the French-language material needs to spell out because a domestic filer never faces them.
- Whose format decision is it? The obligation attaches to the unité légale identified by its SIREN — the French legal entity, not the group. A group holding three French SIRENs can perfectly well run three different formats, and will, unless someone decides otherwise on purpose.
- Which flows are even in scope? An invoice from your French entity to a group company established outside France is not in the domestic e-invoicing channel at all; it is an e-reporting transaction. Modelling every intragroup flow as an e-invoice builds a format pipeline you do not need.
- Who owns the rendering? Where the ERP sits outside France and only the interface layer is local, the single-source rule has to be enforced across an organisational boundary as well as a technical one.
- What happens in September 2027? Smaller French entities of the group join the issuing obligation then — see the 2027 wave checklist. That date should not be treated as settled: every previous slippage in this reform arrived through a loi de finances, and the projet de loi de finances for 2027 had not been tabled as at 3 September 2026. Format work is among the items worth doing anyway, because it is slow and it is not wasted if the date moves.
The background to all of this — who is caught, which wave, what the penalties are — is set out in our note on what changed on 1 September 2026. Our running list of terminology and factual corrections, including the PDP point, is at corrections.
What should be written down before anyone builds?
And record why, because the file is what protects you. The DGFiP has been explicit that the tolérance de démarrage is neither a postponement nor a suspension of the obligation: the penalties have applied since 1 September 2026, and what the tolerance describes is that they are not applied immediately, automatically and blindly to businesses able to demonstrate good faith and corrective measures already under way. A dated decision record naming the format chosen, the specification version implemented and the single-source guarantee is part of that demonstration. An empty file attracts no tolerance at all.
In practice
Choosing a format is a technical decision; emitting a status is a binding one. Once the chain is automated, the question that follows format conformity is control: which operations a system is authorised to execute, who validates them, and what evidence survives. A mapping rule written on a Friday evening in an integration layer is neither a policy nor a proof, yet it produces legal effects on every run. Where those flows cross ERP, platform API, treasury and reporting, BarzelOps runs governed cross-system workflows with durable state, approval checkpoints and tenant isolation. Tenant isolation is the relevant property for a group operating several French legal units on one automation estate.
Frequently asked questions
Which formats are mandatory?
Three base formats built on EN 16931: Factur-X, UBL and CII. Every plateforme agréée must be able to issue in all three and to receive and process all three.
Do we have to choose between Factur-X, UBL and CII?
All three are compliant. The choice is operational: Factur-X if a human reads the invoice in transit, UBL or CII if the exchange is purely machine-to-machine. Between UBL and CII, keep the syntax your chain already handles.
In a Factur-X invoice, does the PDF or the XML prevail?
The XML. Where they diverge, the operative content is the one nobody read — hence the rule that both parts must be generated from a single source of data.
Which lifecycle statuses are mandatory?
Four: déposée, rejetée, refusée and encaissée. Rejetée is a technical rejection by a platform; refusée is a commercial refusal by the recipient, admitted on three grounds only.
Which version of the external specifications is in force?
Version 3.2 of 30 April 2026, after 3.1 of 31 October 2025 and 3.0 of 18 December 2024.
Should we still say PDP?
No. Since décret n° 2026-677 and the arrêté of 27 July 2026 the official term is plateforme agréée (PA). English-language coverage still says PDP almost universally, which dates a document immediately.
In practice
The control has to run before the invoice becomes irreversible.
An accepted structured invoice can be corrected but never deleted, and from the penalty date every defect has a price. Barzel puts the approval threshold, the duplicate check and the signed record in front of submission, so the process can be defended on the day an auditor or the tax authority asks.
338 days leftPME, TPE and micro-entreprises: issuing and e-reporting from 1 September 2027
BarzelOps
Governed workflow automation across the systems that run the business.
- Durable, idempotent execution: a timeout is retried once, never filed twice.
- Human approval checkpoints that pause the workflow and resume it.
- Isolation per entity or client, signed evidence receipts and a portable manifest; HubSpot, Xero, Gmail, Google Drive and Slack.
Free tier: 100 calls a dayPaid plans from $19 a monthLive on MCPize
BarzelVault
The AI action firewall: decide what an agent may do before it does it.
- Approval thresholds and policy checks enforced before execution; human approvals that expire and escalate.
- Cryptographically signed audit receipts: trigger, inputs, policy version, approver, outcome.
- Credential isolation, spend and action limits, and an emergency kill switch.
Free tier: 10,000 calls a monthPaid plans from $199 a monthLive on MCPize
Enterprise: written quote by email within two business days. No sales call.
Related
- France's e-invoicing reform: what changed on 1 September 2026
- Building an audit trail across ERP, plateforme agréée and recipient
- Keeping control when AI agents issue invoices into an irreversible national system
- The 2027 wave: what a smaller French entity of a foreign group needs ready
- Glossary: Factur-X, plateforme agréée and the rest of the vocabulary
- Governed workflow automation: the cost is the exit
Sources
- impots.gouv.fr, Spécifications externes B2B, version 3.2 of 30 April 2026; earlier versions 3.1 of 31 October 2025 and 3.0 of 18 December 2024.
- Décret n° 2026-677 du 27 juillet 2026 and arrêté du 27 juillet 2026, Journal officiel of 28 July 2026.
- CGI, art. 289 bis (annuaire) and art. 242 nonies G (concentrateur).
- Code de commerce, art. L441-9 (mandatory particulars, purchase order).
- impots.gouv.fr, Facturation électronique et plateformes agréées; Liste des plateformes agréées.
- AFNOR standards XP Z12-012 — Formats et profils des messages factures et statuts de cycle de vie, version 1.3 of 26 February 2026; XP Z12-013 — API pour interfacer les systèmes d'informations des entreprises avec les plateformes agréées; XP Z12-014 — Cas d'usage B2B applicables dans le cadre de la réforme facture électronique; and European standard EN 16931 — paywalled, with no free official full text; not linked.
This article is for information and does not constitute tax or legal advice. The French text is the binding one.