France Factur-X Integration: A Technical Guide for ERP Vendors Before September 2026

France's B2B e-invoicing mandate goes live on September 1, 2026 — 111 days from today. For end-businesses, the question is which platform to sign up with. For ERP vendors building integrations, the question is different: what does our pipeline need to emit, accept, route, and reconcile so that our customers do not show up in the September rejection wave?

This is the technical brief the public-facing guides do not give you. We will walk through the four pieces an ERP integration team needs to ship: the Factur-X profile and CIUS-FR overlay, the AFNOR XP Z12-013 API contract, the CDAR lifecycle loop, and the e-reporting separation layer. If you have already read our France e-invoicing primer for businesses, this picks up where that left off.

What Changed Since February 2026

Three regulatory shifts happened in Q1 2026 that affect how you build:

PDP became PA. On February 2, 2026, the French Loi de Finances 2026 was enacted. The certified-platform designation Plateforme de Dématérialisation Partenaire (PDP) was formally replaced by Plateforme Agréée (PA). The legal framework and the certification regime are the same, but the term "PDP" is now a legacy reference. Any ERP-side strings, documentation, dropdowns, or customer-facing labels that say "PDP" need to be updated to "PA" before September. The DGFiP's official registry currently lists just under 100 certified PAs, with the list growing through the late-February-to-August national pilot.

Factur-X 1.08 / ZUGFeRD 2.4 is the applicable specification. Published jointly by FNFE-MPE and FeRD, Factur-X 1.08 became applicable on January 15, 2026. It is fully backward-compatible with 1.0.07, so existing serialisers do not break — but any ERP vendor running 1.0.06 or earlier should plan a version bump. The two specifications remain a single shared technical artifact.

Penalties hardened. The Finance Bill raised the per-invoice non-compliance fine from €15 to €50, capped per fiscal year. Any rejection your pipeline does not catch before transmission is now meaningfully more expensive for your customer.

The Four Layers ERP Vendors Have to Build

The French model has four pieces. Most ERP vendors already have two of them in some form. The other two are new and unfamiliar.

1. The Format Layer: Factur-X + CIUS-FR

France accepts three structured formats — Factur-X (PDF/A-3 with embedded CII XML), UBL 2.1, and standalone CII. In practice, Factur-X is the format the French market expects. Early PA pilot traffic skews heavily Factur-X, UBL second, pure CII a long-tail niche.

Factur-X has five profiles, each cumulative:

Profile	EN 16931 compliant?	Allowed in French mandate?
MINIMUM	No	No
BASIC WL	No	No
BASIC	No	No
EN 16931	Yes	Yes — minimum allowed
EXTENDED	Yes	Yes
EXTENDED-CTC-FR	Yes (with FR extension)	Yes — recommended

The MINIMUM, BASIC WL, and BASIC profiles are not legal for the B2B mandate, even though many PDF generation libraries default to them because they require the least data. Your serialiser must emit at least the EN 16931 profile.

Above EN 16931 sits CIUS-FR — France's Core Invoice Usage Specification. CIUS-FR adds French-specific mandatory fields on top of the EN 16931 core: SIRET numbers for both parties, French VAT codes, the French tax category mappings, and additional cardinality constraints. CIUS-FR is layered on top of EN 16931 — you do not pick "EN 16931 or CIUS-FR." A French invoice is EN 16931 + CIUS-FR by default.

For ERP vendors serving customers across multiple EU markets, the EXTENDED-CTC-FR profile (defined by FNFE-MPE specifically for the French clearance context) is the safer target — it carries the additional fields the PA needs for lifecycle reporting back to the DGFiP, without forcing you to emit a different XML body for each border.

2. The Routing Layer: Plateforme Agréée

Every B2B invoice in France must travel through a certified PA. There is no direct sender-to-receiver path. The PA is responsible for:

• Validating the invoice against EN 16931 + CIUS-FR + Schematron
• Routing the invoice to the recipient's PA (or to the PPF if the recipient is unaffiliated)
• Reporting the transaction data to the DGFiP
• Returning lifecycle statuses back to the sender

For ERP vendors, the practical question is whether to become a PA, partner with a PA, or integrate against multiple PAs as a neutral gateway. Most mid-sized ERP vendors will go with one of the latter two — the certification effort and ongoing supervision regime for becoming a PA is substantial. The November 2024 PA application window has closed; the next certification cohort starts after September 2026.

3. The API Layer: AFNOR XP Z12-013

This is the layer that surprises ERP integration teams. The Z12-013 standard defines a standardised API for communication between a private business (your ERP customer) and their Plateforme Agréée. The intent is platform portability — a customer switching PAs should not require re-integrating their accounting software.

The standard covers:

• Authentication and credential rotation between the ERP system and the PA
• Invoice submission endpoints (synchronous and asynchronous variants)
• Invoice retrieval (for received invoices)
• Lifecycle status callbacks (PA-to-ERP push for Notifications de cycle de vie)
• E-reporting submission for transactions outside the B2B mandate scope

PA vendors have implemented Z12-013 with varying strictness — some offer it as one option among several proprietary interfaces; others as their only public API. Assume your customer base will spread across multiple PAs and build against the canonical Z12-013 contract, not any single PA's bespoke variant.

The companion standard AFNOR XP Z12-014 documents the workflow and edge cases — PA outages, out-of-band corrections, unknown recipient PAs at submission time. Read it once; it will save a week of integration testing.

The semantic data model is governed by AFNOR XP Z12-012 (May 2025), which defines canonical field mappings between UBL, CII, Factur-X, e-reporting XML, and the CDAR (Cycle de Vie Avec Réponse) lifecycle messages. Map your internal invoice model onto Z12-012 once and you can serialise to any of the three accepted formats without data loss.

4. The Lifecycle Layer: CDAR Status Reporting

The French model expects bidirectional lifecycle reporting. When an invoice is submitted, the PA does not just say "accepted" or "rejected." Over the days that follow, the PA emits lifecycle statuses back to the sender:

• Déposée (deposited)
• Reçue (received by recipient)
• Refusée (rejected by recipient)
• Litige (disputed)
• Encaissée (paid)

These statuses must be consumed by the sending ERP and surfaced to the user. They are also the basis on which the DGFiP audits transaction completeness. An ERP that submits invoices but ignores the lifecycle stream is technically compliant for transmission, but operationally blind — and the user will not understand why their Encaissée status never updated in the ledger.

Build the inbound webhook handler before September. Add the five core statuses to your invoice state machine. Decide what each maps to in your existing AP/AR workflow.

Who Is Affected

The mandate has two surfaces:

Sending. From September 1, 2026, French companies with more than 5,000 employees or €1.5B revenue must issue all domestic B2B invoices through a PA in a structured format. Medium enterprises (250-4,999 employees or €50M-€1.5B revenue) follow on September 1, 2027. All other VAT-registered businesses on September 1, 2028.

Receiving. From September 1, 2026, every VAT-registered French business, regardless of size, must be able to receive structured e-invoices through a PA. This is the more common case ERP vendors will encounter — the small French customer who is not sending structured invoices yet but who needs the AP module to ingest a Factur-X from a large supplier.

For ERP vendors, the calculus is: if you have any French B2B customer base, you need the receiving path in production by September 1. Sending can be staged with your customer's compliance timeline.

What ERP Vendors Should Ship Before September 2026

A practical, ordered checklist. The names are intentionally aligned to the AFNOR vocabulary so support-ticket triage stays consistent.

1. Update terminology to PA. Replace "PDP" in UI strings, documentation, configuration keys, and customer-facing labels with "Plateforme Agréée" or "PA." Internal code can keep the old identifiers for one major version; user-facing surfaces should not.

2. Bump your Factur-X library to 1.08 or later. Confirm the output passes EN 16931 Schematron and CIUS-FR business rules. Default the profile selection to EN 16931 or EXTENDED-CTC-FR, never to MINIMUM or BASIC.

3. Build the receiving path first. It is required for every French customer on September 1. The sending path can ramp with each customer's compliance phase. Your inbound handler needs to: receive a Z12-013 callback or pull, parse the Factur-X (PDF + CII) or UBL or CII, extract structured data for the AP queue, and archive the original XML with full traceability.

4. Integrate against AFNOR XP Z12-013, not a single PA's proprietary API. Build the canonical Z12-013 client. Add PA-specific adapters as needed, but keep them thin. When a customer switches PAs in 2027, the cost should be a config change, not a re-integration.

5. Implement the CDAR lifecycle webhook. Add an inbound endpoint that accepts the five core statuses (Déposée, Reçue, Refusée, Litige, Encaissée) and updates the invoice state machine. Decide how each maps to your existing AP/AR ledger states. Document the dispute (Litige) path explicitly — most ERPs do not have a clean "the recipient pushed back on this invoice" state today.

6. Separate the e-reporting path. B2C, cross-border B2B, and exempt transactions flow through a different submission endpoint than B2B e-invoicing — but through the same PA. The data model is similar but distinct. If you have customers selling to consumers or exporting within the EU, the e-reporting submission needs to be wired up alongside e-invoicing.

7. Add a pre-send validator. Most rejections will come from CIUS-FR violations (missing SIRET, wrong VAT category, sub-EN 16931 profile selection) and from Schematron failures. A local pre-send check catches these in your UI rather than as a PA rejection minutes later. Use the Invoice Navigator validator to test invoice output against the latest French rule set, or wire our validation API into your pre-send hook.

8. Map your error vocabulary. PAs return rejection reasons in a partially standardised vocabulary across vendors. Build a mapping from PA-specific rejection messages to your internal error states so support staff can triage consistently regardless of which PA the customer is on.

Penalties and Why Pre-Send Validation Pays Off

The 2026 Finance Bill set per-invoice non-compliance at €50 (up from €15 in earlier drafts), with annual caps. The penalty applies to the sender, but ERP vendors carry the operational pain: every rejection is a support ticket, every penalty is a churn risk, and every CIUS-FR violation that ships to production is one your competitor will fix and you will not. Pre-send validation is the cheaper path even at low rejection rates.

Where This Connects to Other EU Mandates

France's PA model is one of three CTC (Continuous Transaction Controls) architectures emerging in the EU, alongside Italy's SdI and Spain's Verifactu. All three converge on the same mechanics: structured EN 16931 invoices, server-side validation, lifecycle reporting, with country-specific overlays.

The work is portable. The AFNOR Z12-012 semantic model maps onto Italy's FatturaPA model and onto Spain's Verifactu envelope. The CDAR webhook architecture is reusable for Italy's Notifica di scarto and Spain's registro de eventos. Build it well for France, and the next two mandates land lighter. See our briefs on the Italy SDI v1.9.1 changes and the Factur-X vs ZUGFeRD differences, plus the underlying EN 16931 and CII references.

FAQ

What is the difference between PDP and PA in French e-invoicing?

PDP (Plateforme de Dématérialisation Partenaire) and PA (Plateforme Agréée) refer to the same certified e-invoicing platform model. France's 2026 Finance Bill, enacted on February 2, 2026, formally replaced the term PDP with PA in all regulatory documentation. The certification regime, technical requirements, and supervisory framework are unchanged. ERP vendors should update user-facing terminology to PA; internal references to PDP remain valid as legacy identifiers.

Which Factur-X profile do I need for the French 2026 mandate?

At minimum, the EN 16931 profile. The MINIMUM, BASIC WL, and BASIC profiles are not EN 16931-compliant and are not accepted for the B2B mandate. For French invoices, you must also apply the CIUS-FR business rules on top of EN 16931. For ERP vendors building cross-border integrations, the EXTENDED-CTC-FR profile is the recommended target — it carries the additional French-specific fields a PA needs for lifecycle reporting and DGFiP transmission.

What is the AFNOR XP Z12-013 API?

AFNOR XP Z12-013 is the French national standard defining a standardised API for communication between a private business's IT system (typically an ERP, accounting software, or e-invoicing client) and a Plateforme Agréée. It covers authentication, invoice submission, invoice retrieval, lifecycle status callbacks, and e-reporting submission. The intent is platform portability — a business should be able to switch PAs without re-integrating their internal systems.

Do I have to use Factur-X, or can I use UBL or CII?

France accepts three structured formats: Factur-X (PDF/A-3 with embedded CII XML), UBL 2.1, and standalone CII. All three must comply with EN 16931 and CIUS-FR. Factur-X dominates in practice — most early PA traffic uses it because of the hybrid PDF/XML format. UBL is the second-most common choice, particularly for ERP vendors already serving Belgian, Dutch, or Nordic customers. Pure CII without the PDF wrapper is legally valid but rarely used.

What happens if an ERP doesn't implement the CDAR lifecycle webhook?

CDAR (Cycle de Vie Avec Réponse) lifecycle statuses are pushed back from the PA to the sender's ERP after submission — Déposée, Reçue, Refusée, Litige, Encaissée. An ERP that does not consume these statuses is still technically compliant for transmission, but the user will not see when an invoice was actually received by the recipient or when it was paid. Operationally this breaks AR reconciliation and dispute handling. The lifecycle webhook is not optional in practice.

Is the September 2026 deadline going to be pushed back again?

France has pushed its e-invoicing timeline twice — originally July 2024, then July 2024 to a later date, then to September 2026. As of May 2026, the DGFiP has reaffirmed the September 1, 2026 launch for large enterprises, the national pilot is running through August, and just under 100 PAs are certified. There is no current signal of another postponement. ERP vendors should plan to ship by September 1, with the standard caveat that any large-scale CTC rollout can hit late surprises.

What's the penalty for a non-compliant invoice in France?

€50 per invoice, raised from €15 in the 2026 Finance Bill, with annual caps applied per non-compliant party. The penalty is levied on the sender. For ERP vendors, the operational cost — support tickets, churn risk, customer trust — is typically larger than the per-invoice fine, which is why pre-send validation is the better investment.