Refusal, rejection & on hold — when an invoice stops, stalls or dies

Most of the French lifecycle is about an invoice moving forward. This page is about the three statuses where it doesn't: 210 Refusée (the buyer refuses a valid invoice), 213 Rejetée (a platform rejects a non-conform one) and 208 Suspendue (processing is paused pending documents). Two of them are mandatory and terminal — they cancel the invoice for VAT and force a corrective — so getting them right matters more than any happy-path status. The third is the reversible "on hold". This is the full reference: the code and label, who emits it and when, the exact Flowie call, the coded motif — and how the same three ideas surface outside France.

The three at a glance

Where they sit in the global process

The happy path runs 200 → … → 212. These three are the exits and the pause off that rail. 213 can fire before the invoice validly enters (at emission or at reception); 210 fires after the buyer has the invoice; 208 is a loop inside processing that 209 unwinds.

See the full 14-status graph, animated, on the lifecycle explorer. The rule that makes these exits legal without every intermediate status: optional statuses may be skipped, so a lifecycle can jump straight from 200 to 210 or 213.

210 · Refusée — business refusal

What it is. A deliberate, human decision by the buyer to refuse a valid, well-formed invoice that was correctly delivered. It is not about format — the invoice passed every technical control — it is about the content of the deal. 210 is mandatory, terminal, and cancels the invoice for VAT: the supplier must issue a corrective invoice, plus an avoir (credit note) if the original had already been accepted.

When to use it. After the invoice is delivered and visible to the buyer (typically after 203/204), when a business reason makes it unacceptable:

• Amount inconsistent with the order, quote or contract
• Contested unit price or quantity
• Goods not delivered / service not rendered
• 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

How to emit it with Flowie. One call, from the buyer org:

curl -X POST https://api.flowie.ink/v1/documents/{document_id}/lifecycle \
  -H "Authorization: Bearer $FLOWIE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "status": "rejected",
    "reasonCode": "<code from the AFNOR motif annex>",
    "reason": "Prix unitaire ligne 3 non conforme au devis"
  }'

Flowie builds the CDAR, transmits 210 to the DGFiP (it is one of the four mandatory statuses), and fires lifecycle.updated. The reasonCode/reason travel verbatim as MDT-113/MDT-114 — see the motif section.

213 · Rejetée — technical rejection

What it is. An automatic rejection by a platform control — the sending PA, the receiving PA, or the PPF concentrator — because the invoice is non-conform. The invoice never validly entered the network. It is mandatory and terminal. The norm splits it into « Rejetée à l'émission » (caught sender-side, before it ever leaves) and « Rejetée en réception » (caught at the recipient's platform).

What triggers it.

• 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

How you see it with Flowie. 213 is automatic — you don't emit it, you observe it. When a control fails, Flowie fires document.failed (and, for the reporting leg, compliance.reported.failed) with the platform's motif attached. Then:

• Read reasonCode/reason off the webhook (or GET /v1/documents/{id}).
• Fix the payload and call POST /v1/documents/send again.

208 · Suspendue — on hold

What it is. The buyer pauses processing because something is missing — a delivery note, a PO reference, a supporting document. Unlike 210/213, 208 is not terminal: the invoice is alive, just parked. It is a libre (optional) status, but a very useful one — it tells the supplier exactly what's blocking payment.

The resolution loop. Suspension is one half of a pair:

1. Buyer emits 208 Suspendue with a motif describing what's needed.
2. Supplier supplies the material and emits 209 Complétée — the complementary data travels in the status message (MDG-43, code MAJ); the invoice itself is not re-sent.
3. The invoice returns to 204 processing, and can then be approved (205), partially approved (206), or ultimately refused (210).

How to emit it with Flowie. Suspension rides the same disputed call as 207 En litige; the reasonCode "suspended" is the discriminator that makes Flowie transmit 208 rather than 207:

curl -X POST https://api.flowie.ink/v1/documents/{document_id}/lifecycle \
  -H "Authorization: Bearer $FLOWIE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "status": "disputed",
    "reasonCode": "suspended",
    "reason": "Bon de livraison manquant pour les lignes 4–7"
  }'

The supplier then resolves it by attaching the requested material (which emits 209):

curl -X POST https://api.flowie.ink/v1/documents/{document_id}/actions \
  -H "Authorization: Bearer $FLOWIE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "action": "link", "relatedDocumentId": "doc_..." }'

Refus vs rejet vs litige vs suspension

Four statuses say some version of "not yet / not this". They are genuinely different — here is the whole quartet side by side so you never pick the wrong one:

The coded motif — MDT-113 / MDT-114

For 210 and 213 a motif is required; for 207 and 208 it is expected. The CDAR carries it in two fields:

Outside the French DGFiP leg (Peppol / non-FR flows), reasonCode uses the 14 official Peppol status reason codes (OPStatusReason) instead — the full table lives in the API reference · status reason codes.

API cheat-sheet

Every status here surfaces on the lifecycle.updated webhook and on GET /v1/documents/{id}/lifecycle. Build your consumer to be idempotent and out-of-order-tolerant — see the playbook's reference handler.

Beyond France — the same idea elsewhere

"Technical rejection", "business refusal" and "on hold" are not French inventions — every clearance or four-corner model has some notion of them, even when the codes and the bindingness differ. The generic equivalents:

References

• Lifecycle explorer — all 14 statuses (200–213), interactive, with per-status API code and the CDAR field guide.
• France overview · refus & rejet — the summary table and the fabricated-motif warning in context.
• Integration playbook · webhook handler — idempotent, out-of-order-safe consumer for lifecycle.updated.
• Machine-readable referential (JSON) — terminal, reasonRequired, untdid1373 and transitions for every code.
• FNFE-MPE — AFNOR XP Z12-012 annexes (including the « Tableau des motifs de STATUTS ») and Schematrons.