--- title: "Refusal, rejection & suspension — the negative lifecycle statuses" description: "The three ways an e-invoice stops, stalls or dies: 210 Refusée (business refusal), 213 Rejetée (technical rejection) and 208 Suspendue (on hold). Codes, descriptions, who emits them and when, the exact Flowie API call, coded motifs (MDT-113/114) — for France, generalized to Italy SDI, Peppol and UNTDID 1373. Plus the supplier" canonical: "https://docs.get-flowie.com/compliance/fr/refusal-rejection" source: "https://docs.get-flowie.com/compliance/fr/refusal-rejection.html" --- # Refusal, rejection & suspension — the negative lifecycle statuses Compliance · 🇫🇷 France # 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 one distinction that trips everyone up **Rejet (213)** is a _platform_ saying an invoice is malformed _before_ it validly exists — technical, automatic. **Refus (210)** is a _buyer_ saying no to a valid invoice _after_ receiving it — a business decision. They map to _different_ AFNOR codes, carry different motifs, and put the responsibility on different parties. Conflating them is the single most common integration bug in this area. ## The three at a glance 210 · MDT-105 ### Refusée Refused — business refusal The buyer deliberately refuses a valid, well-formed invoice. Cancels it; the supplier must issue a corrective (and an _avoir_ if it was already accepted). ObligatoireTerminal · échecBuyerMotif required 213 · MDT-105 ### Rejetée Rejected — technical rejection A platform control (format, SIRET, duplicate, antivirus…) rejects the invoice. It never validly entered the network. Fix the payload and send a _new_ invoice. ObligatoireTerminal · échecPlatformMotif required 208 · MDT-105 ### Suspendue Suspended — on hold The buyer pauses processing pending supporting documents. **Reversible** : the supplier answers with `209 Complétée` and the invoice re-enters processing. LibreNon-terminalBuyerMotif expected Code| Label| Tier| Emitted by| Phase| Terminal?| Effect| UNTDID 1373 ---|---|---|---|---|---|---|--- `210`| Refusée| Obligatoire| Buyer| Traitement | Yes — **failure**| Invoice cancelled for VAT; corrective required| `50` Rejected `213`| Rejetée| Obligatoire| Any platform| Transmission | Yes — **failure**| Invoice never validly existed; re-send a new one| `8` Rejected (technical) `208`| Suspendue| Libre| Buyer| Traitement | No — reversible| Processing paused; resolves via `209 Complétée`| `39` Suspended ## 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. Transmission Traitement Settlement 200Déposée 204Prise en charge 205Approuvée 212Encaissée 213 Rejetée 208 209 Suspendue → Complétée 210 Refusée Happy terminal (212) Terminal failure (210, 213) Reversible hold (208 → 209) 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 Refuse, or dispute first? `210` is final. If the disagreement might still be resolved, prefer `207 En litige` (dispute) or `208 Suspendue` (ask for documents) first — both are reversible and keep the invoice alive. Reach for `210` only when you are certain the invoice must be cancelled and re-issued. The list above is the easy half. The refusals people actually argue about are the ones where the invoice is _wrong about the buyer_ — a stale postal address, a SIRET belonging to the wrong establishment, a name that no longer matches the register. Those have their own section: [Can I refuse for that?](<#cases>) **How to emit it with Flowie.** One call, from the **buyer** org: [code] 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": "", "reason": "Prix unitaire ligne 3 non conforme au devis" }' [/code] 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](<#motifs>). ## 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 Never mutate a rejected invoice `213` is terminal because the invoice legally never existed. You do **not** "resubmit" or patch it — you fix the payload and send a _new_ invoice (which starts its own lifecycle at `200`). Re-using the number of a `213`'d invoice is fine; re-using the number of a `210`'d one needs a corrective, because that invoice _did_ exist. **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}`](<../../reference/index.html#get-document>)). * Fix the payload and call [`POST /v1/documents/send`](<../../reference/index.html#send-document>) 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`: [code] 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" }' [/code] The supplier then resolves it by attaching the requested material (which emits `209`): [code] 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_..." }' [/code] ## 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: Status| Who| About| Terminal?| Resolves to ---|---|---|---|--- `213` Rejetée| Platform (auto)| Non-conformity (technical / format / regulatory)| **Yes**| — (send a new invoice) `210` Refusée| Buyer| Business refusal of a valid invoice| **Yes**| — (corrective + avoir) `207` En litige| Buyer| Contests all/part, without refusing outright| No| `205` / `206` / `210` `208` Suspendue| Buyer| Pauses pending supporting documents| No| `209` → back to `204` Not a status: code 214 "Visée" There is no `214` in the B2B referential — it stops at `213`. _Visée_ / _Mise en paiement_ / _Mandatée_ belong to the legacy **Chorus Pro B2G** flow; their closest B2B equivalent is `211 Paiement transmis`. Treat them as custom/local statuses in a B2B context. ## Can I refuse for that? — the identity & address cases Nearly every real refusal question is a variant of one question: _the invoice is wrong about who I am or where I am — is that a refusal?_ Two answers are needed, and integrations routinely confuse them. 1. **May you?** Technically, always. **No platform adjudicates a refusal.** Nothing in XP Z12-012 restricts which motifs a buyer may invoke; your PA transmits the `210` and its `MDT-113` whatever you put in them. There is no referee who will tell you your reason was not good enough. 2. **Should you?** That is the real question, and it never depends on how wrong the data looks. It depends on **which of three layers** the error sits in — and all three get called "the customer's address" in everyday speech, which is why this is the hardest corner of the negative path. Before you copy a `reasonCode`: it has two vocabularies One field, two allow-lists, decided by the leg the status travels on. On the **French DGFiP leg** — every domestic B2B invoice through the PPF/PA network — `reasonCode` must be an **AFNOR XP Z12-012 motif** from that status's `BR-FR-CDV-CL-09` allow-list. Flowie forwards what you send **verbatim** ; it does _not_ translate between vocabularies. And the motif is **FATAL** on `206`, `207`, `208`, `210` and `213`, so a wrong one fails the CDAR schematron rather than degrading quietly. The **14 Peppol`OPStatusReason` codes** named throughout this section (`REC`, `REF`, `LEG`…) are the vocabulary for _Peppol and non-FR_ flows — read them here as the _reason family_ , and send the matching XP Z12-012 motif on a French invoice. **Simplest safe route:** omit `reasonCode` and Flowie fills the valid per-status default (`NON_CONFORME` on a `210`), then put the specifics in the free-text `reason`. See [the motif section](<#motifs>). ### Three layers that all look like "the address" Layer| Carried in| What it decides| Who catches an error ---|---|---|--- 1 · Identity _who the counterparty legally is_ | Buyer **SIREN** `BT-47` (scheme `0002`, mandatory) · buyer **SIRET** `BT-46` (scheme `0009`) · `BT-48` VAT · seller side `BT-30` / `BT-29` | The legal debtor, the taxable person, and who deducts the VAT. | Partly the platform — coherence rules (`BR-FR-09`) and the annuaire (`BR-FR-11`) → `213` 2 · Addressing _where it physically goes_ | Buyer electronic address `BT-49` — the _ligne annuaire_ reception point, addressed as `{siren}_{siret}[_{suffix}]` | Which mailbox the invoice is delivered to. Nothing else. | The platform, always → `213` _destinataire introuvable_ 3 · Description _what the invoice says about you_ | Postal address `BG-8` (`BT-50`, `BT-52`, `BT-53` — mandatory in France) · delivery address `BG-15` · company name · contacts | Nothing technical. It is the paper trail: what the invoice _states_ about the parties. | **Nobody.** Schematron checks presence and shape, never truth. Why a layer-3 error is always yours to decide A control can see that `BT-52` is _present_ and that `BT-53` _looks like_ a French post code. It cannot see that you moved out of that building in 2019. **Every wrong-but-well-formed value passes every`213` control and lands in your lap.** So "shouldn't the platform have caught this?" — no. And "can I `213` it myself?" — also no: `213` belongs to platforms. Once the invoice is in your hands, every "no" available to you is a `210`, a `207` or a `208`. ### The test: substantive, or merely formal? For layer-3 errors the whole question collapses onto one distinction. An error is **substantive** when it changes what the invoice _means_ — a different legal person, a different VAT treatment, a different amount owed. It is **formal** when the invoice still identifies both parties and the operation unambiguously, and is merely inaccurate while doing so. * **Substantive →`210` is the right call.** The invoice has to be cancelled and re-issued; there is nothing to regularize. * **Formal →`210` is available, but disproportionate.** The settled EU line is that substantive conditions prevail over formal ones, so a regularizable mention defect does not by itself cost you the deduction (CJEU _Barlis 06_ C-516/14 and _Senatex_ C-518/14). Refusing anyway is legal and it costs you: it cancels the invoice for VAT, obliges the supplier to re-issue, restarts the payment clock in practice (the corrective carries its own date), and publishes a terminal failure into the DGFiP's lifecycle feed under your name. `209 Complétée` cannot fix a wrong mention — a common wrong turn Suspending with `208` and having the supplier answer `209` is the natural reflex, and it is the wrong tool for a bad _mention_. The complementary data on `209` travels in the **status message** (`MDG-43`, code `MAJ`) — [the invoice itself is never re-sent](<#suspension>). A mandatory mention lives _inside_ the invoice, so correcting one always needs a new document: a **facture rectificative**. Use `208` when something is _missing around_ the invoice (a delivery note, a PO reference); use `207` or `210` when something is _wrong inside_ it. ### Can I refuse an invoice if the postal address is wrong but the SIRET and the addressing are correct? Layers 1 and 2 are correct: the invoice reached your real reception point and names your real SIREN and SIRET. Only `BG-8` is stale — an old street, a moved office, a merged site. Don't refuse This is the textbook **formal** defect. You are unambiguously identified by `BT-47` and `BT-46` — the identifiers the reform made authoritative — and the postal address is descriptive of that identification, not constitutive of it. Your deduction is not at risk, and `210` would cancel an invoice whose amounts are right. **What to do instead.** Two defensible playbooks, in order of preference: 1. **Tolerate and regularize** — the default. Approve (`205`), pay, and ask the supplier for a _facture rectificative_ for your file. Nothing is at risk and the payment clock never stops. 2. **Hold the line without killing the invoice** — `207 En litige` with a `LEG`-family motif (the [XP Z12-012 code](<#motifs>) on a French invoice) and free text naming the field and the correct value. Reversible: it keeps the invoice alive and the pressure on. If the supplier issues the corrective, process the new one. Go straight to `210` only where your own policy is that a defective mandatory mention is never paid. …unless the wrong address is not a typo An address error stops being formal the moment it moves the **VAT treatment**. If the address is not a stale street but a _different establishment under a different regime_ — a **DROM/COM** address on what you booked as a metropolitan supply ([cas d'usage 44]()), or a foreign branch, which pushes the operation out of domestic B2B e-invoicing and into [e-reporting]() altogether — then it is substantive. Refuse: `210` with `LEG`. The same applies to the **delivery address** `BG-15` on a goods invoice: `BR-FR-14` makes it mandatory precisely because it feeds the place of supply, so a wrong one there is usually substantive, not cosmetic. ### Can I refuse an invoice if the SIRET is wrong but the SIREN is correct? Start from the structure, because it settles most of the case on its own: **a SIRET contains its SIREN** — nine digits of SIREN plus a five-digit NIC. So a SIRET error that leaves the SIREN correct can only ever point at _another establishment of the same company_. It can never change the legal person, the taxable person, or who has the right to deduct. `BR-FR-09` encodes exactly that invariant on the seller side: the first nine digits of `BT-29` must equal `BT-30`. There is therefore no version of this case where your counterparty is wrong. There are only four versions of _how far the invoice gets_ : What the wrong SIRET actually is| Who catches it| Outcome| Your move ---|---|---|--- Its first nine digits **don't match** the stated SIREN | Schematron coherence control, sender-side | `213` **à l'émission** — it never leaves | Nothing. The supplier fixes the payload and sends a _new_ invoice — and may reuse the number, since a `213`'d invoice never existed. Well-formed, prefix matches, but the SIRET is **closed or absent from the annuaire** | Annuaire lookup at the sending or receiving PA (`BR-FR-11`) | `213` **en réception** — _destinataire introuvable_ | Nothing — you never see the invoice. A **real, active establishment of your company** — just not the one that ordered | **Nobody.** It routes and delivers normally. | Delivered — `202` / `203` / `204` | Yours to decide — see the verdict below. Correct on your side; it is the **seller's own** SIRET (`BT-29`) that is wrong, its SIREN right | Nobody, once `BR-FR-09` passes | Delivered normally | Your deduction is safe — the taxable person is the SIREN. Ask for a rectificative: it matters for the supplier's e-reporting attribution, not for your VAT. Don't refuse — and above all, not on `REC` In the third row you _are_ the counterparty. Refusing with `REC` (_Receiver unknown — the invoice is not addressed to this party_) would be factually false: with the SIREN right, the invoice **is** addressed to your legal person, and a `REC` on the record invites exactly the dispute you were trying to avoid. If you do refuse, the honest families are `REF` (references incorrect) or `LEG` — sent as the matching [XP Z12-012 motif](<#motifs>) on the French leg. `REC` belongs to the case one row up in identity: **a wrong SIREN** — and there you should refuse, because paying and deducting on an invoice addressed to another legal person is not an option. **What to do with a right-company, wrong-establishment invoice.** * **Default: route it internally and approve.** The wrong SIRET changes your cost-centre allocation, not your VAT. * **Ask for a rectificative when the establishment genuinely matters** — separately managed sites with their own accounting, or an establishment whose VAT regime differs (again **DROM/COM**). A regime difference is substantive: then `210` with `LEG`. * **If it recurs, fix it upstream, not per invoice.** The supplier is addressing the wrong _ligne annuaire_. Point them at the composed reception-point form `{siren}_{siret}[_{suffix}]` — and if you expose several reception points on one SIRET, tell them which `suffixeAdressage` to use. See [Reception-point addressing](<../../reference/index.html#reception-point-addressing>), and hand them [the supplier-side section on a wrong maille](<#wrong-maille>). ### The other cases, answered Same test throughout, applied to the errors that actually turn up. "Refuse?" answers _should you_ , not _may you_. The invoice is wrong about…| Layer| Substantive?| Refuse?| Do this (codes are Peppol families — [FR motif](<#motifs>) on a French invoice) ---|---|---|---|--- Your **SIREN** `BT-47` — a different legal person | 1| **Yes**| **Yes** | `210` · `REC`. Never pay or deduct on another entity's invoice. Your **SIRET** `BT-46`, SIREN right | 1| No| No | Approve; ask for a rectificative. `REF` if you refuse anyway — [not `REC`](<#case-siret>). Your **postal address** `BG-8` | 3| No| No | Approve; ask for a rectificative. [Full case ↑](<#case-address>) Your **VAT number** `BT-48` on a reverse-charge or intra-community invoice | 1| **Yes**| **Yes** | `210` · `LEG`. `BR-AE-03` / `BR-IC-03` make it the basis of the VAT treatment, not a decoration. The **delivery address** `BG-15` on a goods invoice | 3| Usually **yes** — it feeds place of supply| Usually | `210` · `LEG` if the VAT treatment moves; otherwise a rectificative. Your **company name** only — typo, or an old trade name | 3| No| No | Approve. Ask for a rectificative if the name is legally wrong rather than misspelled. A **missing legal mention** — the €40 recovery indemnity, late-payment penalties, the discount statement (`BR-FR-05`) | 3| No| No | `207` · `LEG` and ask. Refuse only on policy. A missing **PO / contract reference** | —| No| No | `208` · `REF` — the supplier can supply it and `209` lifts the hold. This is what suspension is for. A missing **delivery note or supporting document** | —| No| No | `208` · `REF`, then `209`. The **IBAN** differs from the one you hold on file | —| Treat as fraud until proven otherwise| Not yet | `208` · `PAY` and verify **out of band** , on a number you already had. Do not pay, and do not refuse on the assumption it is a mistake — supplier-impersonation fraud looks exactly like this. The **amount, price, quantity or items** | —| **Yes**| If unresolved | `207` · `PRI` / `QTY` / `ITM` first; `210` when the disagreement holds. Nothing — it is a **duplicate** you already received | —| **Yes**| **Yes** | `210` · `OTH` with free text naming the original invoice number. Codes are the 14 official Peppol `OPStatusReason` values — the full table is in the [API reference · status reason codes](<../../reference/index.html#reason-codes>). On the French DGFiP leg the coded motif is drawn from the XP Z12-012 annex instead; see [the motif section](<#motifs>). ### Is it still refusable? — what the transition graph allows Everything above asks _which error_ justifies a refusal. The other half of the question is _when_ : a refusal that was available yesterday may not be available today, because the lifecycle is a state machine and some states have no route to `210` left. Flowie enforces that machine — a transition that isn't in it comes back `400` `invalid_transition` rather than being silently accepted — so this is a hard answer, not a matter of judgement. Where the invoice is now| Still refusable?| The route ---|---|--- `received` · `under_review` 203 / 204 | **Yes, directly** | `rejected` is a legal target from both. You do _not_ have to dispute first — [optional statuses may be skipped](). `disputed` 207 / 208 | **Yes** | `disputed → rejected`. This is what makes `207` the safe first move: it keeps both exits open. `approved` 205 | **Not directly** | `approved → rejected` is not in the machine. Go `approved → disputed → rejected`. [Full case ↓](<#case-approved>) `partially_paid` | **Yes, via dispute** | `partially_paid → disputed → rejected`. A part-paid invoice is not yet closed. `paid` 212 | **No** | Terminal — no transitions out at all. [Full case ↓](<#case-paid>) `rejected` · `failed` 210 / 213 | **No — already refused** | Both terminal. Nothing to do but wait for the replacement invoice, which starts its own lifecycle. [Can I undo it? ↓](<#case-undo>) This is the API's finite-state machine, which is what returns `400`. It is deliberately narrower than what the AFNOR norm leaves theoretically expressible — where the two differ, the machine is the contract you integrate against. The full transition list per status is in the [machine-readable referential](<../../schemas/fr-lifecycle-statuses.json>) and on [the lifecycle explorer](). ### Can I refuse an invoice I have already approved? **Not in one call — but the route is not closed.** `approved → rejected` is not a legal transition, so a direct attempt returns `400 invalid_transition`. Dispute first, then refuse: [code] # 1 — reopen the approved invoice 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": "", "reason": "Prix unitaire ligne 3 contesté après contrôle" }' # 2 — then refuse 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": "", "reason": "Écart non résolu avec le devis" }' [/code] But it costs the supplier more than a normal refusal Refusing an invoice you had accepted is not the same event as refusing one you never accepted. The invoice _was_ valid and accepted, so cancelling it now requires an **_avoir_ (credit note)** in addition to the corrective invoice — the acceptance has to be unwound, not just the invoice replaced. That is why approving is the decision to be careful about: `205` is cheap to emit and expensive to reverse. If you are not sure, `207` or `208` keeps the invoice open at no cost. ### Can I refuse an invoice I have already paid? No — and there is no transition to try `paid` is **terminal** : the machine defines no transitions out of it, so there is no `disputed` back door the way there is from `approved`. A payment closes the lifecycle. Recovering money on a paid invoice is a **credit note** and, if it comes to it, a commercial or legal matter — not a lifecycle status. One distinction worth knowing before you post a payment: `partially_paid` is **not** terminal. It transitions to `paid` or `disputed`, so a part-paid invoice can still be disputed and then refused. If you are paying against an invoice you have doubts about, a partial payment leaves you an exit that a full payment does not. ### Can I undo a 210 I sent by mistake? No. `210` is terminal and there is no reverse transition `rejected` has an **empty** transition list — you cannot walk it back to `approved`, and no API call, support ticket or platform intervention re-opens it. The invoice is cancelled for VAT and the refusal has already travelled to the supplier and to the DGFiP. This is the single strongest argument for reaching for `207` instead whenever you are less than certain: `207` is free to change your mind about, `210` is not. **What actually happens next.** The supplier issues a fresh invoice, which starts its own lifecycle at `200`. Note the asymmetry with a technical rejection, which the page covers [above](<#rejection>): because a `210`'d invoice _did_ validly exist, its number cannot simply be reused — the replacement is a corrective referencing it. A `213`'d invoice never existed, so its number is free. If the refusal was your error, say so quickly and in writing: nothing in the protocol distinguishes a mistaken refusal from a deliberate one, so only the commercial conversation can. ### Can I refuse part of an invoice? Refusal is all-or-nothing — but partial _approval_ is not There is no partial `210`: a refusal cancels the whole invoice, because VAT and the invoice number attach to the document, not to its lines. What you _can_ do is accept it only in part. `206 Approuvée partiellement` is emitted by approving with a `remainingAmount` — there is no separate `partially_approved` status to set, the amount is the discriminator, exactly as `reasonCode: "suspended"` is what makes an approval-side `disputed` travel as [`208` rather than `207`](<#suspension>). [code] # 206 — accept part of the invoice, and say how much is left unapproved 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": "approved", "remainingAmount": 240.00, "reasonCode": "", "reason": "Lignes 4-7 non livrées — 240,00 EUR non approuvés" }' [/code] A motif is **required** on `206`, and the CDAR carries the approved and non-approved amounts in their own blocks (`MAP`, `MAPTTC`, `MNA`, `MNATTC`). It is _recommandé_ , not transmitted to the DGFiP, and leads to `211` — so it settles the invoice rather than reopening it. Expect a corrective or a credit note for the difference. **So which do you reach for?** Use `206` when you know exactly what you owe and want to pay that much now. Use `207` when the disagreement is still open: name the lines with the code for it (`PRI`, `QTY`, `ITM`) plus free text, which leaves the supplier three ways out — credit the disputed lines, correct and re-issue, or convince you — and leaves you both exits (`205` or `210`). Use `210` only when the whole document has to die. And if the good lines are urgent while the bad ones are not, the cleanest commercial answer is often neither: ask the supplier to split the invoice into two documents, one payable now. ### The five-step rule of thumb 1. **Did a platform already say no?** Then it is a `213` and there is nothing for you to do but wait for the new invoice. 2. **Is a refusal still available at all?** — `paid` and an existing `210` / `213` are terminal; `approved` needs `207` first. [The transition table](<#timing>) settles it. 3. **Is the legal person wrong?** — a wrong SIREN, not a wrong SIRET. → `210` · `REC`. 4. **Does the error move the VAT treatment or the amount?** → `210` (after `207`, if it might still be settled). 5. **Otherwise it is formal.** → Approve and ask for a _facture rectificative_ , or `207` / `208` to hold the line. Not `210`. The motif is never adjudicated, but it is permanently on the record Because no one vets your reason, the discipline has to be yours. A `210` and its `MDT-113` travel verbatim to the supplier _and_ to the DGFiP, and they are terminal — so a habit of refusing formal defects becomes a visible pattern in your own lifecycle data and in your suppliers' DSO, with no offsetting benefit. Reach for `207` or `208` whenever the invoice can still be saved; keep `210` for the invoices that genuinely must die. ## I sent it to the wrong _maille_ — the supplier's side Everything above answers the buyer's question. This section answers the supplier's, and it is the most common real-world failure of the French model: the invoice is perfect and it went to the wrong **maille** — the wrong level of granularity in the recipient's addressing. France nests three of them, and only one is the one your customer actually declared. Maille| What you send| Scheme| What it means ---|---|---|--- Legal unit | **SIREN** — 9 digits| `0002` | The company. One routing declaration covering everything it receives. Establishment | **SIRET** — 14 digits| `0009` | One site of that company. A SIRET-level declaration beats the SIREN-level one. Reception point _ligne annuaire_ | `{siren}_{siret}[_{suffix}]` | — business routing, [never folded into the Peppol id](<../../reference/index.html#reception-point-addressing>) | One mailbox inside that establishment — the `suffixeAdressage` picks a service, a cost centre, an ERP queue. Getting the maille wrong has exactly **two** outcomes, and which one you got decides everything that follows: whether the invoice fiscally exists, whether you keep its number, and whether you owe an _avoir_. Read the status before you do anything else. Which of the two happened to me? **The invoice is`213 Rejetée`** — nobody received it, it never existed → [fix and re-send, same number](<#maille-rejected>). **The invoice reached`202` / `203` / `204` or beyond** — someone received it, so it exists → [avoir + facture rectificative, new number](<#maille-delivered>). There is no third case and no in-between: _delivery_ is what makes the invoice real. ### My invoice was rejected before delivery — what do I do? This is the ordinary outcome of a wrong maille, and the cheap one. A `213` is emitted by a _platform_ , automatically, before any human reads the invoice — [the 213 section](<#rejection>) lists the controls that fire it, of which _destinataire introuvable_ and an annuaire miss are the two addressing ones. The invoice never validly entered the network. No avoir, no corrective, same invoice number There is nothing to cancel, because nothing exists to cancel. Fix the recipient and send a **new document with the same number** — the per-seller uniqueness control has nothing to collide with, since the rejected one never validly existed. An _avoir_ here would be a fiscal mistake: you would be crediting an invoice that has no existence. 1. **Read the actual motif — do not guess it.** The platform's `reasonCode` and `reason` arrive on `document.failed` and are readable on [`GET /v1/documents/{id}`](<../../reference/index.html#get-document>). Be sceptical of any code you did not read off your own API response: the strings that circulate for this exact case — `ADR_ERR`, `ROUTAGE_ERR`, `DEST_INC` — [appear nowhere in the AFNOR referential](<#motifs>). 2. **Re-check the recipient in the annuaire, at the right maille.** Not the identifier you hold on file — the one they declared. [How, below.](<#maille-lookup>) 3. **Re-send with[`POST /v1/documents/send`](<../../reference/index.html#send-document>).** Never patch or "resubmit" the rejected document: `213` is terminal, and the corrected invoice is a new document that starts its own lifecycle at `200`. 4. **Do it the same day.** Nothing legally protects you here, but nothing works against you either — an invoice the buyer never received cannot have started their payment clock, and the replacement carries its own issue date. A slow fix costs you DSO, not a dispute. ### The invoice was delivered, but to the wrong establishment or service — what now? Here the maille was **technically valid** — a real SIRET, a live _ligne annuaire_ — just not the right one. Nothing failed, so nothing was rejected: the invoice routed, delivered, and is sitting in somebody's queue. That is the expensive case, and the reason is structural. **No control can tell a valid address from the intended one** ; this is [layer 2 behaving exactly as designed](<#cases-layers>). You cannot recall it There is no un-send, no re-route, and no supplier-side status that withdraws a delivered invoice. `213` belongs to platforms and the pre-delivery window has closed. The invoice exists, it has consumed its number, and it is on the lifecycle feed. From here the only exits are the buyer's (`210` / `207`) or a document of your own that cancels it. **Pick up the phone before you pick up the avoir.** The cheapest resolution involves no new document at all — and from the buyer's side it is also the _recommended_ one: an invoice that reaches the right legal person at the wrong establishment is a [formal defect they are advised not to refuse](<#case-siret>). If they will route it internally and approve it, you are done, and the original date stands. Ask before you cancel; a cancellation you initiate cannot be undone either. **If they will not — or if the establishment genuinely matters** (separately managed sites with their own accounting, or an establishment whose VAT regime differs, DROM/COM above all) — the regularisation is the standard two-document cycle: 1. An **_avoir_** (credit note) cancelling the original and referencing its number. 2. A **facture rectificative** with a **new number** , addressed to the correct maille. Both are real documents with lifecycles of their own. The original number is spent — unlike the `213` case, you do not get it back. Check the SIREN before you decide how bad this is A wrong **SIRET** with the right SIREN still reached your customer's legal person: the taxable person is right, their deduction is safe, and the fix is administrative. A wrong **SIREN** reached a _different legal person_ altogether — that buyer should refuse with `REC`, you must cancel, and none of it is negotiable. The invoice also went to a company that has no business holding it, which is a data-protection problem on top of an invoicing one. The full asymmetry is in [the buyer-side case](<#case-siret>). ### Can I re-use the invoice number after a wrong-maille send? After a `213`, yes. After delivery, no. Number continuity follows _existence_ , not effort. A `213`'d invoice never validly entered the network, so its number was never consumed and the uniqueness control has nothing to collide with — re-use it. A delivered invoice consumed its number the moment it existed, whatever happened next: the _avoir_ and the _facture rectificative_ each take a **new** number in your sequence, and the rectificative references the original. The same rule settles the refusal case from the other direction. An invoice the buyer _refused_ did validly exist, so its number is spent too — a rejection frees a number, a refusal does not. [More on that asymmetry ↑](<#case-undo>) ### How do I find the right reception point before re-sending? Two questions hide in this one, and people answer the wrong one. _Does this address exist?_ is a directory lookup. _Is it the one this customer wants invoices on?_ is a question for the customer. The annuaire answers the first authoritatively and the second only partly. By hand, the public annuaire is searchable on the Chorus Pro portal by SIREN, SIRET or company name. Programmatically, from Flowie: [code] # 1 — which maille did this taxpayer actually declare? # `level` answers it in one word: "siren" or "siret". curl https://api.flowie.ink/v1/portability/annuaire/{siren} \ -H "Authorization: Bearer $FLOWIE_API_KEY" # 2 — pre-flight the recipient you are about to send to curl -X POST https://api.flowie.ink/v1/directory/verify \ -H "Authorization: Bearer $FLOWIE_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "peppolId": "0009:75297877500027", "documentType": "INVOICE" }' [/code] * [`GET /v1/portability/annuaire/{siren}`](<../../reference/index.html#portability>) returns `level` — literally _which maille_ the deciding declaration sits at — plus `addressingId`, the routing platform's matricule, and every raw _ligne d'adressage_ as evidence. `declared: false` means nobody declared anything and the PPF default applies. * [`POST /v1/directory/verify`](<../../reference/index.html#verify-recipient>) is the recommended pre-flight before every send: it says whether the recipient exists and can accept the document type. * [`GET /v1/directory/search`](<../../reference/index.html#search-directory>) turns a company name or a VAT number into candidates when you have no identifier at all. The annuaire tells you what exists, not which one they want A company with fifteen establishments can have a live _ligne annuaire_ on all fifteen — all correct, all deliverable, fourteen of them wrong for your invoice. Nothing in the directory says which one should receive _yours_ : that is a commercial fact, and the only reliable source for it is the customer. When they run several reception points on one SIRET, ask which `suffixeAdressage` to use and store it **against the customer record, not against the invoice**. A recurring wrong maille is an onboarding bug, not a per-invoice one. ### Does a wrong maille restart the payment deadline? The two cases diverge here as well, and only one of them is clean. * **Rejected before delivery.** The buyer received nothing, so there is no received invoice for a payment term to run from. The replacement carries its own issue date and the clock starts there. Fixing it the same day costs a day of DSO and nothing else. * **Delivered to the wrong establishment.** Murkier, and not something the protocol settles. The invoice _was_ received by the buyer's legal person — the argument that no term ever started is weak — but the service that has to approve it never saw it. If it is regularised by an avoir and a rectificative, the rectificative carries its own date in practice; if the buyer simply routes it internally and approves, the original date stands and you have lost only the days it sat in the wrong queue. This is a commercial argument, and the lifecycle is your evidence No status, motif or timestamp in the CDV decides who bears the delay — the lifecycle records _when_ each thing happened and stops there. That is still the thing worth having: [`GET /v1/documents/{id}/lifecycle`](<../../reference/index.html#get-lifecycle>) returns the full event log, so you can say exactly when the invoice was rejected or delivered, and to which reception point. Pull it before you argue about late-payment penalties, not after. ### How do I catch a wrong maille before my customer does? Three signals, in the order they can reach you. Two are events you subscribe to; the third is a _silence_ you have to go looking for, and it is the one that hides a wrong-but-valid maille. Signal| What it means| Wrong maille? ---|---|--- `document.failed` | A platform control rejected it — `213`. The motif is on the payload. | **Often.** _Destinataire introuvable_ and an annuaire miss both land here. [Handle it ↑](<#maille-rejected>) `document.delivered` | It reached a reception point; some mailbox accepted it. | **Cannot tell you.** Delivery proves the address was _live_ , never that it was _right_. `lifecycle.updated` that never arrives | Delivered, then nothing — no `203`, no `204`, no approval, for weeks. | **The classic symptom.** An invoice nobody is processing is usually an invoice in a queue nobody reads. So the real answer is upstream: after-the-fact detection only ever finds the first case, and the second is invisible by construction. Three habits remove most of both. * **Pre-flight every send** with [`POST /v1/directory/verify`](<../../reference/index.html#verify-recipient>). One call, and it turns a `213` two days later into an answer before you have committed the invoice number. * **Store the maille on the customer, not on the invoice.** Capture the reception point — `{siren}_{siret}[_{suffix}]`, suffix included — at onboarding, from the customer, and re-check it against [the annuaire](<../../reference/index.html#portability>) whenever a send fails. * **Alert on delivered-and-silent.** Anything past `document.delivered` with no `lifecycle.updated` beyond your customer's usual approval window deserves a phone call. It is the only detector that catches a valid wrong address. ## 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: Field| Name| Content ---|---|--- `MDT-113`| ReasonCode| A **coded** value from the restricted controlled vocabulary of the XP Z12-012 annex (rule `BR-FR-CDV-CL-09`). `MDT-114`| Reason| Optional free text — e.g. `"Prix unitaire ligne 3 non conforme au devis"`. 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](<../../reference/index.html#reason-codes>). The motif codes circulating online are fabricated The literal strings widely repeated 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**. 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 forwards whatever `MDT-113`/`MDT-114` the platform returned **verbatim** — we never invent or re-map a motif. ## API cheat-sheet Code| Your side| What you do ---|---|--- `210` Refusée| Buyer| `POST …/lifecycle {"status":"rejected","reasonCode":"…","reason":"…"}` `213` Rejetée| Supplier| **Automatic** — observe `document.failed` / `compliance.reported.failed`, fix, re-send. `208` Suspendue| Buyer| `POST …/lifecycle {"status":"disputed","reasonCode":"suspended","reason":"…"}` `209` Complétée| Supplier| `POST …/actions {"action":"link","relatedDocumentId":"…"}` (or `add-note`) — lifts the suspension. Every status here surfaces on the `lifecycle.updated` webhook and on [`GET /v1/documents/{id}/lifecycle`](<../../reference/index.html#get-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: Concept| 🇫🇷 France (CDV)| 🇮🇹 Italy · SDI| Peppol · Invoice Response (UNCL4343)| UNTDID 1373 ---|---|---|---|--- **Technical rejection** | `213` Rejetée | _Notifica di scarto_ (NS) — SDI rejects the file | Negative _Message Level Response_ (transport / validation layer) | `8` / `27` **Business refusal** | `210` Refusée | _Esito committente — rifiuto_ (mainly B2G/PA; no formal B2B refusal channel) | `RE` Rejected | `50` **On hold / query** | `208` Suspendue | No native SDI code — handled commercially, off-platform | `UQ` Under Query | `39` Suspended **Dispute (soft)** | `207` En litige | No native SDI code | `UQ` Under Query | `46` Litigious These mappings are informal — the French codes stay authoritative There is **no official normative table** mapping the French 2xx codes to Peppol UNCL4343 as of mid-2026, and the semantics genuinely differ: Italy's _esito committente_ is largely a B2G construct and does _not_ invalidate a cleared B2B invoice the way `210` does; Peppol's `UQ` covers both "dispute" and "on hold". When you exchange cross-border through Flowie we translate at the edge and always keep the **French codes authoritative for the DGFiP leg**. Use this table to reason about equivalence, not as a wire-format spec. ## References * [Lifecycle explorer]() — all 14 statuses (200–213), interactive, with per-status API code and the CDAR field guide. * [Business terms · the four mentions the reform added]() — the SIREN, SIRET, delivery-address and nature-of-operation fields the [refusal cases](<#cases>) turn on, with their France requirement level. * [Reference · reception-point addressing](<../../reference/index.html#reception-point-addressing>) — the `{siren}_{siret}[_{suffix}]` form to hand a supplier that keeps reaching the wrong establishment. * [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)](<../../schemas/fr-lifecycle-statuses.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.