France E-Invoicing API: Integration Requirements for Developers
France e-invoicing is an integration project as much as a finance project. ERP systems, billing applications, accounting platforms and other business software need a reliable way to exchange invoice and reporting data with the French e-invoicing ecosystem.
Table of Contents
Introduction
France e-invoicing is an integration project as much as a finance project. ERP systems, billing applications, accounting platforms and other business software need a reliable way to exchange invoice and reporting data with the French e-invoicing ecosystem.
For developers, the key question is not only which API to call. It is how the source system, invoice data, validation rules, recipient addressing, Plateforme Agréée (PA), status handling and reporting flows fit together.
The French technical framework provides common standards, but a successful implementation still requires provider-specific testing and careful data design.
What Is the France E-Invoicing API Layer?
The French technical framework defines a common API-interfacing model through AFNOR XP Z12-013. Other related standards cover invoice and status-message formats and security and identification aspects. XP Z12-012 addresses invoice and status-message formats, while XP Z12-014 covers security and identification aspects.
These standards provide a common technical basis for connecting business information systems with the French e-invoicing ecosystem. They do not mean that every PA exposes the same public API.
Each PA can have its own endpoints, authentication method, sandbox, credentials, message handling, error catalogue, rate limits, onboarding process and versioning policy.
Before development, obtain the current technical documentation from the selected PA. Treat the common French standards as the architecture baseline and the PA documentation as the implementation contract.
API and PA Are Not the Same Thing
An API is an integration mechanism. A PA is the regulated operator used for the relevant French e-invoicing and reporting flows.
A business may use several architecture patterns. An ERP can connect directly to a PA. An integration or middleware layer can sit between the ERP and PA. A compatible business solution can also connect to a PA on the company's behalf.
The important point is that the API connection does not replace the PA architecture.
For France, developers should understand which component performs validation, routing, invoice exchange, transaction reporting and payment reporting. Those responsibilities should be documented before coding begins.
Start With the Data Model
Do not begin an e-invoicing project with API endpoints. Begin with the business data.
Map the source fields available in the ERP, billing system, accounting application or other source system to the French invoice and reporting requirements.
Typical invoice data includes:
- Seller identity and VAT information
- Buyer identity and applicable SIREN information
- Invoice number and issue date
- Invoice lines, quantities and amounts
- VAT rates and tax treatment
- Tax-exclusive and tax-inclusive totals
- Payment terms and relevant payment information
- References and delivery information where applicable
- Transaction category, such as goods, services or mixed operation
The same exercise is needed for transaction and payment reporting where the business is subject to e-reporting.
Routing Is Part of the Integration
A technically valid invoice still needs to reach the correct recipient.
French e-invoicing uses directory and addressing information involving identifiers such as SIREN, SIRET and the applicable addressing line or routing information.
Recipient master data therefore becomes part of the technical integration. The system should be able to identify the receiving entity and use the current routing information required for delivery.
A routing failure should be treated as an integration exception, not simply as a missing finance field.
Validation Has Several Layers
Validation should happen before and during exchange.
A practical integration can check:
- Required fields
- Data types and formats
- Invoice dates
- Line calculations and totals
- VAT rates and treatment
- Seller and buyer identifiers
- Invoice syntax
- French business rules
- Recipient addressing
The French framework contains common technical and lifecycle concepts. The selected PA can also apply additional operational controls.
Early validation is useful because it lets the business correct source data before an invoice reaches the exchange stage.
Inbound and Outbound Exchange
Developers should design reception alongside issuance.
Outbound processing normally starts with an invoice in the source system, transforms the data, validates it and sends it through the applicable PA architecture.
Inbound processing can involve PA-to-PA exchange and delivery to the receiving solution. The receiving application then needs to preserve the structured invoice, validation information and relevant identifiers before passing the document into the ERP or accounts-payable workflow.
This means an inbound API endpoint is only one possible technical component. The selected PA's current interface model determines whether the receiving solution uses push, retrieval, notifications or another mechanism.
Statuses and Lifecycle Tracking
The French framework defines common lifecycle concepts and minimum statuses, while the PA determines how those statuses are exposed through its API and portal.
The integration should track the applicable deposit, rejection, delivery, receipt, acceptance, payment and other lifecycle states supported by the PA and French framework.
Do not treat every application status as a regulatory status. A provider may also expose workflow states that are useful to the business but are not part of the common French lifecycle model.
Every status should remain linked to the original ERP document so finance teams can reconcile the invoice without searching through technical logs.
E-Reporting and Payment Data
The integration may also need to prepare e-reporting data.
B2C transactions, relevant international transactions and payment information can originate outside the ERP. A retailer, for example, may have consumer transactions in a POS and e-commerce platform while its B2B invoices remain in the ERP.
Payment data can also follow a different technical flow from invoice submission. Depending on the PA, payment information may use a separate reporting operation or file flow.
Developers should therefore confirm the selected PA's specific interface and reconciliation model instead of assuming that payment reporting uses the same endpoint as invoice submission.
Engineering Recommendations for Reliability
Engineering controls are not French legal terminology, but they are important for a production integration.
Use persistent message status and a correlation identifier that links the ERP document to the integration request and PA response.
Where supported, use idempotency keys or a business-level deduplication key. Persist the relationship between the ERP invoice, integration message, PA submission identifier and resulting lifecycle statuses.
Do not blindly retry every failed request. A timeout may be a temporary technical problem, while a missing buyer identifier is a permanent data problem that requires correction.
Monitoring should cover failed submissions, rejected invoices, delayed statuses, authentication failures, routing errors and e-reporting transmission failures.
Security and Auditability
Invoice data is commercially sensitive. API architecture should include secure authentication, credential management, encryption, access controls, audit logging and controlled handling of secrets.
PA registration includes security and infrastructure requirements. The integrator should separately assess the selected PA's authentication, hosting, access-control, logging and incident-management model.
Application logs should contain enough information to trace a transaction without unnecessarily exposing full invoice payloads or sensitive financial data.
Common Standard, Provider-Specific Implementation
AFNOR XP Z12-013 reduces architectural fragmentation, but it does not create one identical API across all PAs.
Before development, confirm the selected PA's:
- API endpoints and environments
- Authentication method
- Message examples and schemas
- Sandbox credentials
- Status model
- Error codes
- Rate limits
- Retry guidance
- Webhook or polling model
- Versioning and change-notification policy
This step prevents a common implementation mistake: building against an old sample payload and assuming it represents every PA.
Testing the Integration
End-to-end testing should cover more than a successful invoice submission.
Test source-data mapping, structured formats, validation failures, recipient routing, inbound delivery, status updates, corrected invoices, credit notes, duplicate prevention, e-reporting and payment-reporting scenarios where applicable.
For every outbound document, retain at least the ERP invoice identifier, source-system version, integration message identifier, payload hash where appropriate, PA submission identifier, routing result, validation result and lifecycle statuses.
For inbound invoices, retain the supplier invoice number, PA message identifier, received structured payload, validation results and the ERP accounts-payable record.
This gives technical and finance teams a shared audit trail across the lifecycle.
How Complyance Can Fit
Complyance can provide an integration and technology layer between existing ERP, accounting or billing systems and the French e-invoicing infrastructure.
The exact PA arrangement, supported formats, API functions and reporting responsibilities should be confirmed for the intended deployment.
The goal is to keep core business systems focused on business data while the integration layer manages the country-specific transformation, validation and exchange logic required for the deployment.
Developer Checklist
Before production, confirm:
- Source fields are mapped and owned
- Buyer and seller identifiers are maintained
- Recipient addressing is tested
- Invoice formats validate correctly
- PA authentication is secured
- Inbound and outbound exchange are tested
- Lifecycle statuses return to the correct ERP record
- Rejections and corrections are recoverable
- E-reporting data is mapped where required
- Payment reporting is handled where applicable
- Correlation and deduplication controls are implemented
- Monitoring and audit trails are available
Conclusion
France e-invoicing API integration is not simply an exercise in sending invoice JSON or XML to an endpoint.
The API sits inside a wider architecture covering business data, French validation rules, recipient addressing, PA exchange, lifecycle management and applicable reporting.
Developers who design around that complete lifecycle can build an integration that is easier to monitor, troubleshoot and adapt as the French technical framework evolves.
Official Source
DGFiP external specifications and technical standards
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.
