AFNOR XP Z12-013: the transmission API to the Approved Platform
AFNOR XP Z12-013 is the French experimental standard that frames the e-invoicing exchange API. Understanding its role between a Compatible Solution and an Approved Platform, and what being aligned with it actually means.
In this article
In short: AFNOR XP Z12-013 is a French experimental standard that frames the API for exchanging electronic invoices - that is, how to technically transmit an invoice to an Approved Platform. It complements EN 16931 (which defines the data of the invoice). Because it is experimental, you align with it; you do not get “certified” against it.
When describing the architecture of the French reform, two standards come up together: EN 16931 for the invoice content, and AFNOR XP Z12-013 for its transport. The first is European and well known; the second is French, more recent, and often misunderstood. Here is what it is, and what it is not.
What is AFNOR XP Z12-013?
AFNOR is the French standardization body. The XP prefix signals an experimental standard: a document published for trial application, which may still evolve and does not (yet) hold the status of a homologated NF standard.
XP Z12-013 frames the technical exchange interface of electronic invoicing in the French framework: how an invoice moves between the actors, in particular between an issuer (or its Compatible Solution) and an Approved Platform (Plateforme Agréée), and between platforms. In practice, it is the framework that lets us speak of a common exchange API rather than one proprietary connector per platform.
The reference normative text is published by AFNOR. This article explains its role in the architecture; for the precise clauses and applicable version, refer to the official AFNOR document.
A transport standard, not a content standard
The key distinction fits in one sentence:
- EN 16931 says which data the invoice must contain (the semantic model). See EN 16931 explained.
- XP Z12-013 frames how to transmit that data (the exchange interface, the API).
The two are complementary: you normalize an invoice against EN 16931, then transmit it according to XP Z12-013. One without the other is not enough for the interoperability the reform aims for.
Why a standardized API?
Without a common framework, each Approved Platform would impose its own interface, and each merchant would have to build one integration per platform. A standardized API aims for the opposite: an issuer transmits its invoices the same way, whatever the downstream Approved Platform, and can change PA without rewriting everything. It is a direct factor of reversibility and reduced vendor lock-in.
What “aligned with XP Z12-013” means
An important point of vocabulary: because XP Z12-013 is an experimental standard, it comes with no certification scheme. A solution therefore cannot be “certified XP Z12-013”. The correct phrasings are:
- aligned with the AFNOR XP Z12-013 standard;
- designed to AFNOR XP Z12-013;
- implements the AFNOR XP Z12-013 API contract.
Be wary of a provider claiming an “XP Z12-013 certification”: that status does not exist.
Where does Gatebold sit?
Gatebold E-Invoice Gateway is a Compatible Solution, not an Approved Platform. Its role:
- extract the invoice emitted from Magento / Adobe Commerce;
- normalize its data against the EN 16931 semantic model and validate it (SIREN/SIRET, VAT, totals consistency, etc.);
- transmit it to your Approved Platform through an API aligned with the AFNOR XP Z12-013 standard.
It is then the Approved Platform, registered with the DGFiP, that produces the regulatory format (Factur-X, UBL or CII) and handles the relay to the DGFiP and to the recipient’s PA. Gatebold produces no regulatory format and holds no registration status: it prepares and transmits conformant data.