The French e-invoicing lifecycle — interactive reference

Every invoice exchanged under the French reform carries a cycle de vie — a sequence of statuses fixed by AFNOR XP Z12-012 (CDAR data element MDT-105): 14 codes, 200–213. Four are obligatoires (200, 210, 212, 213 — always transmitted to the DGFiP concentrator), five are recommandés (203, 204, 205, 206, 211), and the remaining five coded statuses are libres (201, 202, 207, 208, 209 — optional between platforms). Anything outside the referential is a custom status that never leaves your own tooling. This page is the full referential: who emits each status, in which phase, the allowed transitions — and the exact API call that emits or observes it with Flowie (Plateforme Agréée n° 0040).

Interactive explorer

Filter by tier, click any status for its full definition and the code to add, or press play to watch an invoice travel the network — each step logs the webhook Flowie fires.

The three tiers — obligatoire, recommandé, libre

The official referential (the « Transmission » column of the DGFiP external specifications, kept by AFNOR XP Z12-012) classifies the 14 coded statuses in three tiers — and everything outside the referential forms a fourth, uncoded family:

^† 207 En litige is the one contested cell: the v2.3 dossier’s transmission table reads libre, while several industry readings (and some trainings) class it recommandé. Treat it as optional either way; we track every annex revision and will update this page if the classification moves.

The 14 statuses of the referential (MDT-105)

The referential splits in two phases, carried in the CDAR’s MDT-77 type code: Transmission statuses (305 — produced automatically by the platforms as the invoice moves) and Traitement statuses (23 — business decisions produced by the buyer or the supplier).

For the crucial difference between 210 Refusée (business refusal by the buyer) and 213 Rejetée (technical rejection by a platform), plus 208 Suspendue (on hold) and their coded motifs (MDT-113/MDT-114) — see the dedicated Refusal, rejection & on-hold reference (or the summary on the France overview).

Status → Flowie API cheat-sheet

One table to bookmark. Automatic means Flowie emits the status for you — you only observe it (webhook lifecycle.updated, or GET /v1/documents/{id}/lifecycle). Everything else is one call to POST /v1/documents/{id}/lifecycle.

Skipping statuses — what a minimal legal flow looks like

Because only 4 of the 14 statuses are mandatory, a perfectly legal lifecycle can be as short as 200 → 212 (deposited, then collected) — or 200 → 210 / 200 → 213 when things go wrong. The recommended statuses are not checkpoints: an invoice does not have to pass through 204 to be approved, and a buyer may refuse (210) without ever emitting 207 En litige first. Use the Mandatory filter in the explorer above to see the minimal graph.

Two consequences for your integration:

• Never assume ordering. Your webhook consumer must accept lifecycle.updated events that jump tiers (e.g. straight from submitted to paid). Idempotent, out-of-order-tolerant handlers are the norm — see the playbook’s reference handler.
• Emit generously, consume defensively. Emitting the recommended (and even the libre) statuses costs one API call each and materially improves your counterparty’s (and your own) visibility — but never require them from the other side: a platform is not allowed to fail an invoice because an optional status never arrived.

Canonical scenarios

The five playable scenarios in the explorer, in prose — these are the flows to test before go-live:

How statuses travel — the CDAR message

Between platforms, a lifecycle status is not a bare number: it travels as a CDAR (Cross Domain Acknowledgement and Response) message — the UN/CEFACT CrossDomainAcknowledgementAndResponse document, which France pins to the D22B XSD and constrains with the BR-FR-CDV Schematron rules. It is the only lifecycle syntax in the French socle minimal — the UBL ApplicationResponse familiar from Peppol is not an accepted syntax for the French CDV flux. The fields that matter:

Flowie builds, signs and routes CDAR messages for you in both directions: your POST …/lifecycle becomes an outbound CDAR; inbound CDARs from the buyer’s platform become lifecycle.updated webhooks with reasonCode/reason passed through verbatim — we never invent or re-map a motif (the motif code lists circulating on vendor blogs are largely fabricated; trust only the AFNOR annex).

International mapping — UNTDID 1373 & Peppol

Each French code has a generic UNTDID 1373 equivalent (BR-FR-CDV-CL-05), carried in MDT-88:

Peppol is a different layer. Peppol status flows use UBL ApplicationResponse twice — the Message Level Response (validation outcome) and the Invoice Response (buyer decision, 7-code UNCL4343 subset: AB IP UQ CA RE AP PD). There is no official normative table mapping the French 2xx codes to UNCL4343 as of mid-2026; the informal overlaps (205≈AP, 206≈CA, 210≈RE, 211/212≈PD…) break down for the transmission phase, where 200/213 correspond to Peppol’s MLR / transport-receipt layer rather than to an Invoice Response. When you exchange cross-border through Flowie we translate at the edge and always keep the French codes authoritative for the DGFiP leg.

Custom statuses — your workflow, off the wire

Beyond the five coded libre statuses (201, 202, 207, 208, 209 — which do travel between platforms when supported), anything outside 200–213 is a custom status: useful, unregulated, and strictly local. Typical examples and how to model them with Flowie without polluting the regulated lifecycle:

Tags and notes never generate a CDAR and are never reported to the DGFiP — which is exactly the point. If a state should be visible to your counterparty, use the regulated status; if it’s internal process, keep it libre.

Machine-readable referential (JSON Schema)

Everything on this page is also published as data, so your integration (or your AI agent) can consume the referential instead of scraping it:

const { statuses } = await (await fetch(
  "https://docs.get-flowie.com/schemas/fr-lifecycle-statuses.json")).json();

const mandatory = statuses.filter(s => s.tier === "mandatory");
// → 200 Déposée, 210 Refusée, 212 Encaissée, 213 Rejetée

const next = Object.fromEntries(statuses.map(s => [s.code, s.transitionsTo]));
// next[204] → [205, 206, 207, 208, 210]

The dataset carries a semantic version plus the DGFiP / AFNOR spec versions it was verified against (specVersions); we bump it with every annex revision. The tables above and the interactive diagram are generated from the same facts — if you spot a divergence, that's a bug: tell us.

Test the full lifecycle in the sandbox

The sandbox ships a working replica of this state machine. A five-minute session that exercises every mandatory status:

1. Send an invoice with a flw_test_ key — status 200 is synthesized immediately.
2. Drive the buyer side: POST …/lifecycle {"status":"under_review"} then {"status":"approved"} (codes 204, 205).
3. Mark it paid from the supplier org (212) — with simulateCompliance: "accept" on the org, a synthetic compliance.reported webhook fires, exactly like the real PPF acknowledgement.
4. Now break things: simulateCompliance: "reject_00058" replays a PPF rejection end-to-end (compliance.reported.failed), and an illegal transition (e.g. received → paid) returns 409 invalid_transition with the allowed next states.

Full test matrix — including timeout and flaky simulators for your retry logic — in the integration playbook.

References

• impots.gouv.fr · Facturation électronique — DGFiP official portal (mandate scope, calendar, external specifications ZIP with the XP Z12-012 annexes).
• AFNOR XP Z12-012 — the lifecycle referential itself (statuses, CDAR profile, motif annex). The motif list lives only in the « Tableau des motifs de STATUTS » sheet of the official annex.
• EU Commission · eInvoicing in France — pan-EU factsheet.
• FNFE-MPE — Forum national de la facture électronique.
• France overview — deadlines, required fields, PPF error codes, refus/rejet motifs.
• Integration playbook — ship a French-compliant integration end to end.