XP Z12-013 API in 2026: What ERP-to-Plateforme Agréée Integration Teams Should Test
Published August 2026 by Solarc Labs
XP Z12-013 is the standard API bridge between enterprise systems and approved platforms
DGFiP lists XP Z12-013 among the applicable standards for the reform, and AFNOR describes it as the API standard for interfacing enterprise information systems with approved platforms. The integration job therefore spans more than invoice upload: it includes the contracts used by enterprise systems, compatible solutions and Plateformes Agréées to exchange reform-related flows. For an ERP team, the practical value of the standard is a common model to test against, not a reason to assume every provider integration is identical.
Start the test plan with authorization and ownership boundaries
The published XP Z12-013 documentation describes OAuth2-based authorization as part of the standard API design. Before testing business payloads, prove which technical identity calls the API, how credentials or keys are rotated, which organisation or tenant the identity can act for, and how failed authorization is surfaced. Keep those controls separate from invoice-data validity. An authorization failure and a structurally invalid invoice need different owners, evidence and remediation paths.
Test incoming and outgoing flows, not only sales-invoice submission
The standard API model distinguishes inbound from outbound flows and sales from purchase flows, and it also needs to support adjacent objects such as lifecycle information, directory interactions and e-reporting. Build the integration matrix around the flows the business will actually use rather than one outbound sales demo. At minimum, document which source system produces each outgoing object, which application consumes each incoming object and which identifiers let the two sides reconcile the same transaction.
Async delivery, search recovery and webhooks need failure testing
The XP Z12-013 documentation is designed for asynchronous processing and describes webhook-style event delivery alongside search/retrieval patterns. Test what happens when the receiving application is unavailable, an event is delivered more than once, a webhook is missed, or the consumer needs to reconstruct the authoritative state after an outage. A robust integration should be able to replay or reconcile without creating duplicate business actions or declaring an invoice complete merely because one HTTP request returned successfully.
Verify the chosen PA implementation instead of assuming the standard is mandatory everywhere
The published XP Z12-013 implementation documentation explicitly notes that implementation of the standardized APIs by Plateformes Agréées is not mandatory. Treat the standard as a strong interoperability reference, then compare it with the actual API, authentication, webhook and operational contract exposed by the PA you selected. InvoiceBatch FR is not a Plateforme Agréée and does not implement the regulated transmission layer. Its role remains upstream corpus/readiness evidence; actual API conformance and production behavior must be tested with the chosen PA.
Primary sources
Sources used for this article
Continue the job