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
0040. 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/sendas usual; we route through the right PA and report status to PPF. - Lifecycle changes (
approved,rejected,paid) are auto-reported within ~2 minutes.
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. |
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.
Sender → PA / PDP (Flowie) → [PPF receives extract for e-reporting]
→ Recipient PA / PDP → Recipient ERP0040) 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 | 0040 |
| 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-0040-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:
curl …/afnor/directory-service/v1/siret/code-insee:12345678900012 \
-H "Authorization: Bearer $KEY"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)
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. 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). 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). 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 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 (0040) 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 0040) — 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.