France PA Certification — Complete Technical Guide for the 2026 E-Invoicing Mandate

France's Plateforme Agréée (PA) regime is the technical and legal backbone of the 2026 B2B e-invoicing mandate. A PA is a private platform certified by the DGFiP (Direction Générale des Finances Publiques) to issue, receive, and lifecycle-track structured invoices on behalf of French VAT-registered companies. Certification requires demonstrating compliance with 393 mandatory data fields, passing approximately 1,841 schematron and business-rule validations, and completing a technical interoperability audit with the PPF (Portail Public de Facturation), the state-operated central hub. Flowie holds PA certification for the French market. This guide explains the regulatory architecture, the technical specification, format choices, lifecycle obligations, and the concrete implementation patterns that PA certification demands.

What PA Certification Actually Means Under the DGFiP Regime

The term "Plateforme Agréée" replaced the earlier designation "Plateforme de Dématérialisation Partenaire" (PDP) in official DGFiP communication. The nomenclature shift is more than cosmetic: the PA designation consolidates certification scope to cover both emission and receipt channels under a single approval, whereas earlier drafts of the mandate treated them as separable capabilities.

PA certification is issued by the DGFiP following a formal audit process called "immatriculation technique." This audit verifies:

Technical capability: the platform can generate, validate, and route structured invoices in all three mandated formats (UBL 2.1, UN/CEFACT CII, Factur-X)
Interoperability: the platform can exchange data with the PPF using the standardized API specification
Lifecycle management: the platform can emit, receive, and propagate the mandatory lifecycle statuses (Submitted, Refused, Approved, In Payment, Paid, and others)
Data residency and security: the platform meets the applicable data-protection requirements under GDPR and the DGFiP's hosting guidelines

Certification is not perpetual. Certified platforms must maintain compliance with updated DGFiP specifications — the "Spécifications Externes B2B" — as those specifications evolve. A material change in technical specification triggers a re-attestation obligation.

The mandate applies to all French VAT-registered companies for domestic B2B invoices. The timeline as of early 2026 (the latest stable DGFiP communication) is:

September 1, 2026: receipt obligation begins for all VAT-registered French companies, regardless of size; emission obligation begins for large companies (grandes entreprises) and ETIs (entreprises de taille intermédiaire)
September 1, 2027: emission obligation extends to SMEs (PMEs) and micro-enterprises

These dates supersede the earlier 2024 and 2025 target dates, both of which were deferred. The September 2026 dates should be treated as current planning assumptions but verified against the DGFiP's official publications before any contractual commitment.

The legal basis for the mandate derives from Article 289 of the French Code Général des Impôts, as amended, and the implementing decree published in the Journal Officiel (Legifrance reference cited in this guide's sources). The underlying EU legal authority is Article 218 of the EU VAT Directive 2006/112/EC, which permits member states to mandate electronic invoicing for domestic transactions subject to specific conditions.

The 5-Actor Model and the Data Flow Architecture

The French mandate uses a relay architecture. No invoice travels directly from an issuer to a recipient — every transaction routes through a PA on each side and, at minimum, through the PPF for fiscal reporting. This design gives the DGFiP full transactional visibility without requiring issuers and recipients to connect directly to a government portal.

flowchart LR
    A["Émetteur\n(Issuer)"] -->|"Structured invoice\nUBL / CII / Factur-X"| B["PA Émetteur\n(Issuer's PA)"]
    B -->|"Validated invoice\n+ lifecycle events"| C["PPF\n(Portail Public de Facturation)"]
    C -->|"Format conversion\nif needed"| D["PA Destinataire\n(Recipient's PA)"]
    D -->|"Delivered invoice\n+ status updates"| E["Destinataire\n(Recipient)"]
    B -->|"e-reporting data\n(B2C / cross-border)"| C
    D -->|"Lifecycle callbacks\n(Approved, Paid, etc.)"| C
    C -->|"Status propagation"| B

The five actors each carry distinct obligations:

Émetteur (Issuer) — the French VAT-registered company generating the invoice. Responsible for populating all mandatory fields. Does not interact with the PPF directly.

PA Émetteur (Issuer's PA) — validates the invoice against the 393-field specification and the schematron rules before onward routing. Transmits lifecycle status updates to the PPF. Flowie operates in this role for its issuer clients.

PPF (Portail Public de Facturation) — the state-operated central hub, operated by the DGFiP. Receives all invoices for fiscal visibility, performs format routing, and propagates lifecycle statuses. The PPF is free to use but offers minimal feature set beyond basic transmission.

PA Destinataire (Recipient's PA) — receives the invoice from the PPF (or directly from the issuer's PA in direct-connection scenarios), delivers it to the recipient, and relays lifecycle status updates back. Flowie operates in this role for its recipient clients.

Destinataire (Recipient) — the French VAT-registered company receiving the invoice. Responsible for updating lifecycle statuses (Approved, Refused, In Payment, Paid) within the timelines specified by the DGFiP.

Format conversion is a material service that PAs must provide. An issuer may submit in Factur-X but the recipient's PA may only support UBL. The PPF performs some format bridging, but PAs are required to handle conversion within their own processing chains to guarantee delivery in a format the recipient can consume. This is not a trivial engineering requirement: the three formats share a common semantic model (EN 16931 / XP Z12-014) but differ substantially in encoding.

The 393 Mandatory Fields and 1,841 Validation Rules — What Gets Enforced

The DGFiP "Spécifications Externes B2B" defines 393 mandatory data fields across the invoice data model. These fields cover:

Identification fields: invoice number, issue date, document type code (BT-3), currency code
Seller and buyer data: legal identifiers (SIRET, VAT number, company name, address)
Line-item data: description, quantity, unit price, line amount, VAT classification per line
Tax summary (BG-23): taxable amount, tax rate, tax amount per VAT category
Payment terms: due date, payment means code (IBAN or equivalent), discount terms
Lifecycle fields: process type, routing identifier, and the lifecycle status codes (BT-23 scope)

The specification does not merely list fields — it mandates codelist values for many of them. For example, BT-3 (invoice type code) must conform to the UNTDID 1001 code list. BT-8 (value date type) must conform to UNTDID 2005. Non-conforming values cause hard validation failures that block routing.

Validation is enforced at two layers:

XSD schema validation — structural well-formedness. A UBL document that violates the UBL 2.1 XSD, or a CII document that violates the UN/CEFACT XSD, is rejected at ingest. This catches encoding errors, missing namespace declarations, and malformed field values.

Schematron business-rule validation — semantic correctness across the approximately 1,841 rules. These rules include:

Cross-field consistency checks (e.g., tax amount on a line must equal quantity × unit price × tax rate within rounding tolerance)
Codelist membership checks (values must exist in the referenced UNTDID or other registered code lists)
Conditional-field rules (e.g., BT-134 and BT-135 for invoice period must both be present if either is present)
French-specific extensions prefixed EXT-FR-FE, defined under AFNOR norm XP Z12-013

The AFNOR norms directly relevant to the mandate are:

XP Z12-013 — sectoral exchange model, defining the French-specific extensions (EXT-FR-FE-* fields) layered on top of EN 16931
XP Z12-014 — the core invoice data model, aligned with EN 16931 European standard
XP Z12-015 — CTC (Continuous Transaction Controls) model, governing the lifecycle and status-reporting obligations

A validation failure at either layer produces a structured error response that the PA must relay back to the issuer with the specific rule identifier. This requirement means PA platforms must maintain a machine-readable mapping between rule identifiers and actionable error descriptions — a non-trivial content engineering task, given that the rule set spans multiple AFNOR norms and the DGFiP's own specification extensions.

UBL, CII, and Factur-X — When Each Format Applies and How

The mandate recognises three invoice formats. All three carry the same semantic content (the 393 fields mapped to EN 16931), but they differ in structure, encoding, and operational fit.

Property	UBL 2.1	UN/CEFACT CII	Factur-X
Structure	XML only	XML only	Hybrid: PDF/A-3 embedding XML
Root namespace	`urn:oasis:names:specification:ubl:schema:xsd:Invoice-2`	`urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100`	Varies by profile (Factur-X XML is CII-derived)
PDF human-readable layer	No	No	Yes — PDF/A-3 carries the XML attachment
Primary use case	ERP-to-ERP automated processing; Peppol ecosystem	CII-native ERPs; converters from older EDIFACT workflows	Mixed environments: automated processing AND human-readable archival
Format detection	Root element namespace, not filename or MIME type	Root element namespace	PDF/A-3 container with `AFRelationship=Alternative` attachment named `factur-x.xml`
When to prefer	Large-scale automated AP/AR pipelines; Peppol cross-border	SAP SD/MM native output; existing UN/CEFACT toolchains	SMEs; contexts requiring a human-readable invoice alongside the machine-readable data

Factur-X is the most commonly requested format in practice, because it lets a company satisfy both its human-readable invoice archival obligation and the structured data obligation with a single file. However, Factur-X introduces two operational risks that PAs must handle: (1) the PDF and XML layers can diverge if generated by different systems — the XML layer is legally authoritative, but the divergence creates reconciliation problems; and (2) some PDF generators produce PDF/A-3 containers that fail strict validation even though the embedded XML is correct.

PAs are not permitted to reject an invoice solely because the issuer chose a different format from what the recipient prefers. Format conversion is a routing obligation, not a rejection path.

For EU cross-border transactions, the Peppol network uses UBL 2.1 as its primary format. The PEPPOL BIS Billing 3.0 profile is UBL-based. French companies with significant cross-border volume should confirm with their PA that UBL is supported natively — conversion from Factur-X CII to UBL is a non-trivial transformation given the namespace and codelist differences.

For a broader view of EU-level compliance obligations, including the ViDA directive's trajectory toward mandatory CTC across member states, see the ViDA compliance tracker guide in this hub.

Lifecycle Statuses and the E-Reporting Obligation

Invoice Lifecycle

The French mandate defines a mandatory lifecycle for every structured invoice. Lifecycle statuses are communicated between the issuer's PA, the PPF, and the recipient's PA. The DGFiP requires that status updates propagate within defined time windows.

The primary lifecycle states, mapped to the BT-23 conceptual scope, are:

Submitted (Déposée) — invoice received by the issuer's PA and transmitted to the PPF
Refused (Refusée) — recipient explicitly refuses the invoice (business refusal, not technical rejection); the issuer must issue a credit note or corrected invoice
Approved (Approuvée) — recipient acknowledges the invoice as commercially accepted
In Payment (En cours de paiement) — payment process has been initiated
Paid (Payée) — payment confirmed

Additional statuses cover technical error states (rejected by the issuer's PA before submission, rejected by the PPF validation layer) and routing-specific states (in transit, delivered to recipient's PA).

The status obligation is bilateral. The recipient is required to update status — Approved, Refused, or In Payment — within the timeline the DGFiP specifies. This creates an operational change for many French AP teams who are accustomed to invoice approval workflows that are entirely internal. Under the mandate, a subset of those status transitions must be communicated externally through the PA chain.

E-Reporting Obligation

E-reporting is a separate but parallel obligation from e-invoicing. It covers:

B2C transactions — invoices issued to French consumers (not subject to the PA routing obligation but subject to transaction reporting)
Cross-border B2B transactions — invoices between a French VAT-registered company and a non-French counterparty

For e-reporting, the PA does not route a structured invoice to a recipient's PA. Instead, it transmits a transaction data summary (the "données de transaction") to the PPF at defined intervals. The data elements required for e-reporting are a subset of the 393 mandatory fields — specifically the fiscal identifiers, amounts, VAT breakdowns, and transaction dates.

E-reporting applies to both sales (outbound) and purchases (inbound from non-French suppliers). Companies with significant B2C revenue or international procurement volume must ensure their PA handles e-reporting alongside the standard PA routing flow. These are architecturally distinct submission channels to the PPF.

PPF (State Platform) Versus PA (Private Platforms) — Pick the Right One

The PPF is operated by the DGFiP and is available to all French VAT-registered companies at no charge. It supports the mandatory minimum: structured invoice submission, basic routing, and lifecycle status recording. It does not provide ERP connectors, workflow automation, supplier onboarding tooling, or procurement orchestration.

Dimension	PPF (state platform)	PA (certified private platform)
Cost	Free	Subscription or per-transaction pricing
Format support	UBL 2.1, CII, Factur-X	UBL 2.1, CII, Factur-X (required); ERP-specific connectors vary by vendor
Lifecycle support	Mandatory statuses only	Full lifecycle + workflow integration with ERP and AP/AR systems
ERP connectivity	API only; no pre-built connectors	Pre-built connectors for major ERPs (SAP, Oracle, Microsoft, etc.)
UX / portal	Basic DGFiP portal	Vendor-dependent; ranges from minimal to full AP/AR dashboards
Archival	DGFiP stores fiscal copies	Vendor-dependent; typically includes long-term archival per French law (10 years)
E-reporting	Direct submission via PPF API	Handled by PA on client's behalf
Recommended for	Very small companies with minimal invoice volume and no ERP integration needs	All companies with ERP systems, multi-entity structures, or cross-border invoice volume

The PPF should not be dismissed — it is the state's guarantee that every French company has a compliant path regardless of size. But for any company running invoices through an ERP, the PPF's lack of native connectors means manual upload workflows, which introduce reconciliation errors and do not scale beyond low invoice volumes.

The key architectural decision for a CFO or IT Architect evaluating PA options is: does the platform's validation and routing logic sit between the ERP and the PPF (the PA model), or does the ERP export to a file that gets manually uploaded to the PPF? The latter creates a compliance gap: the ERP's invoice data and the PPF's fiscal record can diverge without automated reconciliation.

For companies managing multiple ERP environments — for example, an SAP instance for one subsidiary alongside an Oracle Fusion instance for another — a PA that abstracts format differences and consolidates lifecycle status back into a single workflow surface is structurally necessary. The multi-ERP orchestration vs replacement guide in this hub covers that architectural decision in detail.

Certification Timeline, Technical Requirements, and Ongoing Obligations

The DGFiP Certification Process

PA certification ("immatriculation technique") is initiated by submitting an application to the DGFiP. The DGFiP does not publish a fixed calendar for audit slots; the process is demand-driven and timelines have varied. The DGFiP's formal test phase ran approximately three months for the cohort that began October 14, 2025, with integration windows reported by approved platforms in the four-to-six-week range. End-to-end timelines from initial application to certification issuance are best estimated as several months and should be verified against current DGFiP capacity.

The technical audit covers five areas:

Specification conformance — demonstration that the platform correctly implements the 393 mandatory fields and passes the schematron rule suite
Interoperability testing — live API exchange tests with the PPF test environment, covering both submission and status callback channels
Format conversion — demonstration of lossless conversion between UBL, CII, and Factur-X for a defined set of test invoices
Security and data residency — review of hosting architecture, encryption, access controls, and GDPR compliance documentation
Operational readiness — demonstration of monitoring, incident response, and SLA commitments for the production environment

Technical Requirements for PA Platforms

At a minimum, a PA must implement:

A structured invoice ingest API accepting all three formats
XSD and schematron validation prior to PPF submission
PPF submission API integration (both synchronous validation and asynchronous status callback)
Lifecycle status propagation in both directions (issuer-side and recipient-side)
E-reporting submission for B2C and cross-border transactions
Long-term archival (10 years per French accounting law) in fiscally admissible format

Ongoing Obligations

Once certified, a PA must:

Monitor DGFiP specification updates and apply conformance changes within the timelines specified in each update notice
Participate in periodic interoperability re-testing if the DGFiP issues a specification version that changes the PPF API or the schematron rule set
Maintain audit logs sufficient to demonstrate compliance to DGFiP inspectors
Notify the DGFiP of material changes to the platform's architecture, hosting location, or security posture

Certification is not a one-time milestone. The specification has been updated multiple times during the period 2022–2026, and PA operators should maintain a standing process for tracking specification releases and assessing their impact on the production validation pipeline.

How Flowie Complies — Architecture and Implementation Choices

PA Registration and Infrastructure

Flowie is registered with the DGFiP as a Plateforme Agréée. Infrastructure runs on cloud environments in Frankfurt and Belgium (EU-resident), satisfying the DGFiP's data residency requirements and Flowie's own ISO 27001:2022 certification scope. GDPR-compliant data processing agreements are in place for all invoice data processed through the PA channel.

Validation Pipeline

Flowie's validation pipeline implements a two-stage approach mirroring the DGFiP's own validation sequence:

Stage 1 — Structural validation: Incoming invoices are validated against the relevant XSD (UBL 2.1 XSD, UN/CEFACT CII XSD, or Factur-X embedded XML XSD). Structural errors are returned synchronously with the specific schema path that failed.

Stage 2 — Business-rule validation: The schematron rule engine evaluates all applicable rules from the EN 16931 core rule set, the PEPPOL BIS extensions where applicable, and the French-specific EXT-FR-FE extensions defined under XP Z12-013. Validation results reference the specific rule identifier (e.g., BR-CO-20, EXT-FR-FE-180) and include the field path and observed value. This structured error response lets ERP connectors surface actionable correction guidance to invoice operators without manual rule lookup.

The rule engine is updated in line with DGFiP specification releases. Each update goes through a change-impact assessment against the production rule set before deployment to avoid regressions on previously valid invoice formats.

Format Handling and Conversion

Flowie accepts invoices in UBL 2.1, CII, and Factur-X at ingest. Internal processing normalises all formats to a canonical invoice object model aligned with XP Z12-014. Outbound delivery converts from that canonical model to the recipient's preferred or required format. Format detection uses the root element namespace exclusively — not filename, MIME type, or document type declaration — because namespace is the only reliably authoritative discriminator across ERP export variations observed in production.

For Factur-X specifically, the extraction and re-embedding of the XML layer from the PDF/A-3 container is handled independently from the PDF payload. The XML layer is the legally authoritative record; the PDF layer is preserved for archival but is not used for validation or routing decisions.

Lifecycle Integration

Lifecycle statuses flow bidirectionally through Flowie's event bus. When a recipient updates a status (Approved, Refused, In Payment), that event is:

Validated against the permitted status transitions for the invoice's current state
Transmitted to the PPF within the required window
Pushed back to the issuer's ERP connector as a structured event

This means the issuer's ERP receives payment status updates through the same channel it uses to submit invoices — there is no separate portal login required to track invoice acceptance. For multi-entity organisations managing dozens of subsidiaries across different ERPs, this consolidated status surface is a material operational difference from the PPF's basic model.

Astral Knowledge Graph and Supplier Resolution

Flowie's Astral knowledge graph plays a specific role in the PA routing layer. When an invoice arrives and the recipient's PA routing must be determined, Astral resolves the recipient's SIRET against its registry of registered PAs, the PPF routing directory, and Flowie's own supplier network. This resolution step determines whether the invoice should route directly to a counterparty's Flowie-side PA account, to a different registered PA via the PPF relay, or to the PPF for basic delivery to a company using only the state portal.

Astral also maintains a record of each supplier's preferred format, which drives the outbound format conversion decision at the PA Destinataire stage. For large procurement organisations with hundreds of active suppliers, this supplier-level configuration eliminates the need to manually specify format preferences per invoice batch.

E-Reporting

Flowie handles e-reporting as an automated side-channel in the same invoice processing pipeline. B2C transaction data and cross-border B2B transaction data are identified at ingest based on the buyer VAT number and country code, extracted into the e-reporting payload format, and submitted to the PPF on the client's behalf at the required reporting cadence. This is transparent to the client's ERP — the ERP submits all invoices through a single Flowie endpoint, and Flowie routes them to the correct downstream channel (PA relay or e-reporting) based on transaction type.

Multi-ERP Environments

Many of Flowie's clients operate across multiple ERP instances — a common pattern in industrial groups with acquired subsidiaries running SAP, Oracle, or mid-market ERPs alongside each other. Flowie's Workflow Builder provides a no-code orchestration layer that lets finance operations teams configure per-entity invoice validation rules, lifecycle routing, and ERP write-back without custom integration code for each ERP instance. The PA validation and routing layer sits beneath Workflow Builder, so the compliance obligations are met uniformly regardless of which ERP submitted the invoice. For details on how this orchestration layer works in multi-ERP contexts, see multi-ERP orchestration vs replacement.

To explore Flowie's France-specific e-invoicing product capabilities, visit the France e-invoicing product page. For integration patterns across ERP systems, see the integrations page. To discuss a specific deployment scenario, contact the Flowie team.

FAQ

When does the France e-invoicing mandate apply to my company?

Receipt obligation begins September 1, 2026 for all French VAT-registered companies, regardless of size. This means your accounts payable systems must be capable of receiving and processing structured invoices from that date. Emission obligation — issuing structured invoices — begins September 1, 2026 for large companies (grandes entreprises) and ETIs (entreprises de taille intermédiaire), and September 1, 2027 for SMEs and micro-enterprises. These dates reflect the latest stable DGFiP communication as of early 2026 and supersede the earlier deferred dates. Verify against the DGFiP's official publications before any contractual planning.

What is the difference between the PPF and a PA?

The PPF (Portail Public de Facturation) is the state-operated central hub managed by the DGFiP. It is free, handles basic invoice routing and fiscal reporting, and is the mandatory relay point for all transactions. A PA (Plateforme Agréée) is a certified private platform that connects to the PPF on the client's behalf, adds ERP integration, advanced validation, format conversion, lifecycle workflow, and e-reporting automation. Every invoice still passes through the PPF — a PA does not bypass it. The PPF is sufficient for very low-volume, manually-operated invoicing; a PA is operationally necessary for any company running invoices through an ERP.

How many mandatory fields does the France PA specification require?

The DGFiP "Spécifications Externes B2B" defines 393 mandatory data fields. These cover identification, party data (seller and buyer), line items, tax summaries (BG-23), payment terms, and lifecycle codes. The specification also includes approximately 1,841 validation rules — XSD structural checks and Schematron business-rule checks — that must all pass for an invoice to be accepted by the PPF. Validation failures reference specific rule identifiers so that ERP operators can identify and correct the data issue.

Which invoice format should we use — UBL, CII, or Factur-X?

The mandate accepts all three formats. Factur-X is the most common choice for companies that also require a human-readable PDF archive, since it embeds the structured XML inside a PDF/A-3 container. UBL 2.1 is the format used by the Peppol network and is preferred for cross-border transactions or companies already operating on Peppol. CII is the native output format of some SAP SD/MM configurations. All three carry the same 393 data fields semantically; the choice is driven by ERP output capability, recipient preference, and archival requirements. A certified PA must support all three and perform conversion between them where needed.

Does e-invoicing cover B2C transactions?

No — the PA routing obligation covers B2B domestic transactions between French VAT-registered companies. B2C invoices (issued to French consumers) and cross-border B2B invoices (with non-French counterparties) are covered by a separate e-reporting obligation. E-reporting requires submitting transaction data summaries to the PPF — not routing full structured invoices through the PA chain. The distinction matters for companies with mixed invoice portfolios: their PA must handle both PA routing and e-reporting as parallel submission channels.

How long does PA certification take, and can a non-French company become a PA?

The DGFiP certification process ("immatriculation technique") typically takes four to six months from initial application to certification issuance, based on the experience of platforms that have completed the audit. This estimate reflects DGFiP capacity as of early 2026. Non-French companies can apply for PA certification — the DGFiP's rules do not restrict certification to French-domiciled entities. However, data residency requirements apply: invoice data for French VAT transactions must be hosted in a jurisdiction that meets the DGFiP's requirements, which in practice means EU-resident infrastructure. A certified non-French PA must also be able to interact with the PPF API in real time, which has implications for latency and connectivity architecture.