--- title: "France · PPF compliance" description: "Sending invoices to French buyers under the e-invoicing reform: PPF, PA / PDP status, Service Exécutant, deadlines, and how Flowie reports on your behalf. Flowie is registered Plateforme Agréée (PA, formerly PDP) number 0064." canonical: "https://docs.get-flowie.com/compliance/fr/" source: "https://docs.get-flowie.com/compliance/fr/index.html" --- # France · PPF compliance Compliance · 🇫🇷 France # France — Portail Public de Facturation (PPF) ## TL;DR * From **1 September 2026** , every French business _must be able to receive_ e-invoices — and large & mid-sized (ETI) businesses _must send_ them. * From **1 September 2027** , SMEs and micro-enterprises _must send_ e-invoices too. * Flowie is a registered **Plateforme Agréée (PA)** — number `0064`. _The DGFiP renamed PDP → PA in 2025; most market actors and existing contracts still use "PDP" interchangeably._ * You don't talk to PPF directly. Send via [`POST /v1/documents/send`](<../../reference/index.html#send-document>) as usual; we route through the right PA and report status to PPF. * Lifecycle changes (`approved`, `rejected`, `paid`) are auto-reported within ~2 minutes. Already with another PA? Porting to Flowie is a documented, four-call path A taxpayer may change _Plateforme Agréée_ at any time and keeps its SIREN/SIRET addressing, so nothing downstream is re-addressed. The [**portability guide**](<../../guides/portability.html>) walks the whole hand-over: import from a SIRET (single or in bulk), build and parse the normalised inter-PA message, and beat the three legal clocks — 24 h to acknowledge, 5 _jours ouvrés_ to decide, _le silence vaut accord_ past the delay. ## Deadlines Date| Who| What ---|---|--- **2026-09-01**| All FR businesses (any size)| **Receive** e-invoices in Factur-X, UBL, or CII. **2026-09-01**| Large & mid-sized (GE / ETI) businesses| **Send** e-invoices; e-reporting starts. **2027-09-01**| SMEs & micro-entrepreneurs| **Send** e-invoices. Continuous| All| Lifecycle status reporting (e-reporting) within 24h. DGFiP can — and does — shift these dates The reform was already postponed once (from 2024 to 2026). Watch the [changelog](<../../changelog.html>); we update this page within 24h of any official communication. ## Background — Y- and 4-corner models France adopted the **Y-model** (also called the "5-corner model"): every invoice flows through a registered platform — the public PPF or a private **PA** (Plateforme Agréée, formerly PDP) — which forwards it to the recipient's platform _and_ sends a copy of the headers to PPF for tax-administration. [code] Sender → PA / PDP (Flowie) → [PPF receives extract for e-reporting] → Recipient PA / PDP → Recipient ERP [/code] PA vs PDP — what changed in 2025 The original 2024 ordonnance used the term **PDP** (_Plateforme de Dématérialisation Partenaire_). A 2025 DGFiP rename to **PA** (_Plateforme Agréée_) modernised the label, but the legal regime, accreditation process, and our number (`0064`) are unchanged. Most existing contracts, market communication, and even the [official DGFiP list]() URL still say "PDP". This page leads with PA but keeps PDP visible — both refer to the same thing. The "4-corner" model (used by Italy, Belgium, and the rest of Peppol) is corner1→corner2→corner3→corner4 without the central tax-administration leg. France's 5th corner is the leg to PPF. ## Flowie's PA (Plateforme Agréée) status Field| Value ---|--- PA / PDP number| `0064` Legal entity| Flowie SAS SIREN| `987 654 321` Authorized formats| Factur-X 1.0.07, UBL 2.1 (Peppol BIS 3), UN/CEFACT CII D16B Authorized flows| B2B, B2G, B2C-receipt Audit certificate| [PDP-0064-2026.pdf]() DGFiP listing| [impots.gouv.fr/pdp]() ## Required fields for French invoices The Peppol BIS 3.0 schema is mandatory; PPF adds a CIUS-FR profile on top. The most common gotchas: * document.buyerReferencestringrequired for B2G **"Service Exécutant"** code given to you by the public buyer. Without it, PPF rejects with `00058`. * document.orderReferencestringrequired for B2G **"Engagement Juridique"** — public-procurement commitment number. * seller.additionalIdentifiers[siret]14 digitsrequired SIRET (the SIREN + 5-digit establishment code). Flowie populates this from the registry on company creation. * document.note (Cadre de facturation)enumrequired A1 (basic), A2 (deposit), … A24 (auto-billing). Defaults to A1; pass another only if you know what you're doing. * document.payment.ibanFR-IBANoptional Required for credit-transfer payments. PPF doesn't enforce, but most public buyers do. ## Routing & the Annuaire PPF maintains the **Annuaire** — the official directory of every French business and which PDP it uses. Flowie syncs nightly. To look up a French recipient's preferred PDP: [code] curl …/afnor/directory-service/v1/siret/code-insee:12345678900012 \ -H "Authorization: Bearer $KEY" [/code] The response includes the recipient's PDP code. We use this automatically on every send to a French Peppol ID — you never need to look it up yourself. ## Lifecycle statuses (statuts du cycle de vie) New — the interactive lifecycle reference This section is the summary. The full referential — animated state diagram, mandatory / recommended / libre filters, per-status API code, CDAR field guide — lives on the [**Lifecycle explorer**](); the end-to-end implementation path (webhook handler, responsibility matrix, go-live checklist) is the [**Integration playbook**](). The B2B reform mandates _both_ e-invoicing and _e-reporting_ — transmission of each invoice's lifecycle status to the DGFiP via your PA (Plateforme Agréée). The status set is fixed by AFNOR **XP Z12-012** (CDAR field `MDT-105`): **14 codes, 200–213** , in three tiers — **4 obligatoires** (200, 210, 212, 213 — always produced, always reach the DGFiP concentrator), **5 recommandés** (203, 204, 205, 206, 211) and **5 libres** coded statuses (201, 202, 207, 208, 209 — optional between platforms). Anything outside 200–213 is a custom status that carries _no_ official code and is _not_ transmitted to the PPF. Flowie emits these automatically when you call [`POST /documents/{id}/lifecycle`](<../../reference/index.html#update-lifecycle>). The 4 **mandatory** statuses (the ones the PPF/DGFiP require): Code| Statut (FR)| Meaning| Flowie lifecycle ---|---|---|--- `200`| Déposée| The sending platform attests the invoice is received, checked & compliant — start of the lifecycle.| `submitted` `210`| Refusée| The buyer refuses the invoice in full — a deliberate **business / commercial** refusal (see [below](<#refus-rejet>)). Auto-cancels the invoice.| `rejected` (buyer) `212`| Encaissée| The supplier confirms payment received (partial or full). Feeds the VAT (CA3) pre-fill.| `paid` `213`| Rejetée| A functional control at the sending or receiving platform detected an anomaly — a **technical / format** rejection (see [below](<#refus-rejet>)). Auto-cancels the invoice.| `failed` The 10 **optional** statuses — 5 _recommandés_ and 5 _libres_ — emit them when the corresponding business event happens; they give your counterparty visibility but are not strictly required (and a platform must never fail an invoice because one didn't arrive): Code| Statut (FR)| Tier| Meaning ---|---|---|--- `201`| Émise par la plateforme| Libre| The sender's PA confirms it transmitted the invoice to the recipient's PA. `202`| Reçue par la plateforme| Libre| The recipient's PA confirms receipt from the sender's PA. `203`| Mise à disposition| Recommandé| The recipient's PA has made the invoice available to the recipient. `204`| Prise en charge| Recommandé| The recipient acknowledges receipt of the invoice. `205`| Approuvée| Recommandé| The recipient accepts the invoice in full. `206`| Approuvée partiellement| Recommandé| The recipient accepts the invoice only partially. `207`| En litige| Libre*| The recipient disputes all or part of the invoice _without_ a full refusal. `208`| Suspendue| Libre| The recipient requests supporting documents; processing is suspended. `209`| Complétée| Libre| The supplier has supplied the awaited documents (resolves `208`). `211`| Paiement transmis| Recommandé| The recipient confirms the invoice was paid (or the supplier confirms a refund). * `207 En litige` reads _libre_ in the v2.3 transmission table; some industry readings class it _recommandé_. Optional either way — see the [tier guide](). **Chorus Pro statuses are not B2B codes.** _"Mise en paiement"_ and _"Mandatée"_ belong to the legacy Chorus Pro (B2G public-sector) flow, not the B2B 200–213 set. Their closest B2B equivalent is `211 Paiement transmis`; in a PPF/B2B context treat them as _libre_. Likewise the code ranges `250/251/282` (données réglementaires), `300/301/303/304` (e-reporting), `400/401` (annuaire) and `500/501` (flux) are **not** invoice business statuses — don't map a lifecycle to them. Listen for `compliance.reported` webhooks to know when each report lands. `compliance.reported.failed` means the PPF rejected the submission itself — see codes below. ## Refus (210) vs rejet (213) — and their motifs **Dedicated reference:** for the full treatment of the negative statuses — `210 Refusée`, `213 Rejetée` and `208 Suspendue` (on hold), with the global-process diagram, per-status API calls and the cross-country mapping — see [Refusal, rejection & on-hold](). The summary below covers refus vs rejet. Both statuses are **mandatory** and both **auto-cancel** the invoice (VAT cancelled; the supplier must issue a corrected invoice, and an _avoir_ /credit note if the original was already accepted). They differ in _who_ says no and _why_ : | `213 — Rejetée` (rejet)| `210 — Refusée` (refus) ---|---|--- **Who**| A platform (sending PA, receiving PA, or the PPF) — _automatic_.| The buyer / recipient — a _human, deliberate_ decision. **Why**| Non-conformity: technical / syntactic / semantic / regulatory.| A business disagreement about a _valid, well-formed_ invoice. **When**| _Before_ the buyer validly processes the invoice. The norm splits it into **« Rejetée à l'émission »** (sender-side — never validly issued) and **« Rejetée en réception »** (caught receiving-side).| _After_ a valid invoice has been delivered to and seen by the buyer. ### Typical rejet (213) triggers * Invalid or corrupt format (Factur-X / UBL / CII not EN 16931-compliant) * Failed syntactic or semantic / coherence control (BR-FR-CTC schematron) * Antivirus failure, or an attachment over the size limit * Invoice-number uniqueness breach (duplicate for this seller) * Invalid SIREN / SIRET against the PPF annuaire * Addressing / routing error — _destinataire introuvable_ * A mandatory data element is missing ### Typical refus (210) reasons * Amount inconsistent with the order / quote / contract * Contested unit price or quantity * Goods not delivered / service not rendered * Double-billing / duplicate of an invoice already received * A mandatory legal mention is missing (CGI art. 242 nonies A) * Payment terms that don't match the contract **The motif is coded — and the codes circulating online are fake.** For _both_ `210` and `213` (and « Rejetée à l'émission »/« en réception ») the CDAR status message carries the reason in **two fields** : `MDT-113` (_ReasonCode_ , a coded value drawn from a restricted controlled vocabulary — rule `BR-FR-CDV-CL-09`) plus an optional free-text `MDT-114` (_Reason_). The literal motif strings widely circulated by vendor blogs and AI summaries — `TX_TVA_ERR`, `REJ_UNI`, `REJ_COH`, `REJ_ADR`, `CMD_ERR`, `DOUBLE_FACT`, `ROUTAGE_ERR`, `CALCUL_ERR` ("~45 codes / 6 families") — **do not appear anywhere in the official AFNOR XP Z12-012** ; they are fabricated. The authoritative `Code motif → Libellé` list lives _only_ in the **« Tableau des motifs de STATUTS »** sheet of the XP Z12-012 Excel annex inside the _Spécifications externes B2B_ ZIP (current v3.2). Flowie surfaces whatever `MDT-113`/`MDT-114` the platform returned verbatim on the `document.lifecycle` webhook and on `GET /v1/documents/{id}` — we do **not** invent a code. _(International mapping note:`BR-FR-CDV-CL-05` maps refus to UNTDID-1373 status `50 — Rejected`, distinct from the French 210/213.)_ ## French use cases & frameworks Two different vocabularies get conflated here. The **B2B reform** uses the **cas d'usage of AFNOR XP Z12-014**. The older **cadres de facturation** (`A1`, `A2`…) are a **legacy Chorus Pro (B2G public-sector)** construct that the B2B reform does _not_ reuse. And `A / B1 / B2 / C` are the **circuits of the schéma en Y** (which party uses the PPF vs a PA) — _not_ invoice types. ### B2B vs e-reporting — the big split * **B2B domestic** invoices flow as structured e-invoices through PA platforms — this is _e-invoicing_. * **B2C, international and intra-community** transactions are covered by _e-reporting_ — you transmit transaction / payment _data_ to the DGFiP, you do **not** exchange a structured invoice through the PPF/PA network. ### Cas d'usage B2B (AFNOR XP Z12-014) XP Z12-014 enumerates the B2B business scenarios in three families (data-implementation, third-party, lifecycle-impacting). The count grows by version: **v1.2 = 42 cas** (Oct 2025), **v1.3 = 44 cas** (Feb 2026, adds case 43 international B2B e-reporting + case 44 DROM/COM/TAAF), and **v1.4 = 45 cas** (30 June 2026, adds case 45 _auto-facture bidirectionnelle_). This is the summary; the full referential — all 45 numbered, a deep dive on every theme, and how to model each with Flowie — is on the dedicated [**Use cases (XP Z12-014)**]() page. The scenarios most relevant to an integration: Theme| Cas d'usage| Summary ---|---|--- **Acompte** (advance / deposit)| 20–21, 32, 24, 34| A deposit invoice (_facture d'acompte_), then a final invoice referencing it. 32 = monthly payments; 24 = arrhes; 34 = partial collection / cancellation. **Avoir / facture rectificative** (credit note)| _no standalone case_| A credit note is a first-class _document type_ that must reference the original invoice and travel the same circuit — it is **not** its own numbered case. (18 = notes de débit; 22a/22b = escompte.) **Autofacturation** (self-billing)| 19b, 23, 19a, 17b| The buyer or a third party issues the invoice for the seller (e.g. a marketplace). 19a = tiers facturant sous mandat; 23 = particulier ↔ pro. **Autoliquidation** (reverse charge)| _no dedicated case_| Handled as a **VAT mention / attribute** on the invoice, not a numbered case. (13 = sous-traitance paiement direct; 14 = co-traitance B2B.) **Tiers payeur / mandats / débours**| 2–12, 15, 16, 17a, 39| Third-party payers, payment intermediaries, transparent intermediaries (débours), subrogation. **TVA — régimes particuliers**| 25, 29, 33, 42, 30| Gift vouchers/cards (25); assujetti unique / VAT group (29); TVA sur marge (33); détaxe (42); TVA déjà collectée B2C↔B2B bridge (30). **B2C → e-reporting**| 27, 28, 30| Toll (27), restaurant receipts (28), B2C e-reporting bridge (30) — these are _e-reporting_ , not invoice exchange. **International / intracommunautaire → e-reporting**| 43 (43a/43b), 44| Foreign-party and intra-community operations reported as _data_ ; 44 = DROM/COM/TAAF. **Edge cases**| 1, 31, 35, 36, 37, 40, 41| Multi-order/multi-delivery (1), mixed (31), notes d'auteur (35), secret professionnel (36), SEP (37), netting/compensation (40), barter (41). ### Cadres de facturation (legacy Chorus Pro / B2G) If you see `A1`…`A25` in a Flowie flow, that is the **Chorus Pro (public-sector)** mapping — _what_ document is deposited and by _whom_ — carried over for B2G, not part of the new B2B reform. The most common: Cadre| Meaning ---|--- `A1`| Dépôt par un fournisseur d'une facture (à régler ou avoir) — the standard case, the vast majority. `A2`| Dépôt d'une facture déjà payée (e.g. carte d'achat). `A3`| Dépôt d'un mémoire de frais de justice. `A4` / `A5` / `A7` / `A8`| Works contracts: projet de décompte mensuel (A4), état d'acompte (A5), projet de décompte final (A7), décompte général & définitif signé (A8). `A9` / `A10`| Demande de paiement d'un sous-traitant (A10 = marchés de travaux). `A12`| Facture / demande de paiement d'un cotraitant, validée par le mandataire. `A13`–`A25`| Further works décomptes by cotraitant, MOE (maîtrise d'œuvre) or MOA (maîtrise d'ouvrage). _(No`A11` or `A21` exist in the transmission table.)_ ## PPF error codes Code| Meaning| Fix ---|---|--- `00025`| Invoice number doesn't follow PPF pattern.| Use alphanumeric only; max 20 chars; no special characters except `-` and `/`. `00043`| Duplicate invoice number for this seller.| Increment your numbering. PPF tracks (sellerSiret, number) tuples. `00058`| Missing Service Exécutant for public buyer.| Set `document.buyerReference`. `00104`| SIRET unknown in Annuaire.| Buyer hasn't registered yet — they must onboard before you can invoice them. `00200`| Schema validation error.| Inspect `error.details[]` — usually a missing required field. `00306`| Recipient PDP rejected.| Read the recipient PDP's reason; often Cadre de facturation mismatch. `00500`| PPF temporarily unavailable.| We retry automatically; you'll see `compliance.reported` when it recovers. ## Testing your French integration Use these sandbox primitives: What you want to test| How ---|--- Happy-path PPF acceptance| Company VAT `FR12345678901`; `simulateCompliance: "accept"`. Service-Exécutant rejection| `simulateCompliance: "reject_00058"`; send without `buyerReference`. Annuaire miss| Send to `0009:00000000000000` → PPF returns `00104`. PPF outage| `simulateCompliance: "timeout_30s"` — exercise circuit breaker. 10-minute paid batching| Mark as `paid`; use [time-travel](<../../sandbox/index.html#test-clock>) to skip 10 min and watch the report fire. ## FAQ ### Why does this page mix "PA" and "PDP"? PDP (_Plateforme de Dématérialisation Partenaire_) was the original name used by the 2021 ordonnance and the 2024 reform documentation. The DGFiP renamed it to **PA** (_Plateforme Agréée_) in 2025. The legal regime, the accreditation criteria, and our number (`0064`) are unchanged — only the label moved. Both terms appear in market communication; we lead with PA but keep PDP visible because every existing contract, every backup of the DGFiP list, and most ERP integrations still use PDP. ### Do I need a separate contract with the DGFiP? No. Your contract with Flowie covers PA / PDP services. We handle the DGFiP relationship. ### What happens if Flowie loses PA / PDP status? PA authorization is renewed every 3 years. If for any reason ours lapses, we have a contractual fallback to route through PPF directly — your integration doesn't change. Discounted period guaranteed for any disruption. ### Can I use my own PA / PDP for some invoices? Yes — set `settings.preferredPDP` on the company. We fall back to your choice when the recipient's PA allows it. ### Does Factur-X count as e-invoice or PDF? Both. Factur-X is a hybrid — a human-readable PDF/A with a structured XML embedded. PPF accepts it as e-invoice; recipients can render the PDF if they don't process the XML. Flowie generates Factur-X by default for FR domestic invoices. ## References **Primary sources** (French government & EU regulator): * [impots.gouv.fr · Facturation électronique]() — DGFiP's official taxpayer portal; mandate scope, calendar, FAQ. * [impots.gouv.fr · Liste officielle des PDP]() — Authoritative list of registered _Plateformes de Dématérialisation Partenaires_. * [CEDEF (Bercy) · Facturation électronique]() — Ministry of Economy explainer; legal-text references. * [Ordonnance n° 2021-1190 du 15 septembre 2021]() — Foundational legal text creating the e-invoicing obligation (Légifrance). * [Loi de finances 2024 · Article 91]() — Article that re-set the calendar to September 2026 / 2027. * [EU Commission · eInvoicing in France]() — Pan-EU reference factsheet. * [OpenPeppol · France profile]() — Authoritative Peppol facts (FR is a Peppol Authority since 2025). * [Flowie · PDP authorization (number 0064)]() — Our DGFiP-issued PDP certificate. **Industry analyses** (independent confirmation of the timeline): * [PwC France · Réforme de la facturation électronique]() — Big-4 implementation analysis. * [FNFE-MPE · Forum national de la facture électronique]() — Industry consortium tracking the reform.