210 Refusée (refused) and 212 Encaissée (paid) are the two that must be forwarded to the PPF. The codes 200 Déposée and 213 Rejetée are emitted automatically by Invopop, so you never build or send them.
Invoice lifecycle
After an invoice is issued it moves through a sequence of lifecycle events. Each event is a GOBLbill.Status or bill.Payment that references the invoice and carries one CDV ProcessConditionCode. For the full list of codes — with the document each maps to and which party issues it — see Status codes.
The paths below are common examples, not an exhaustive set: any code can in principle follow another (e.g. a 205 approval can still be followed by a 210 refusal). The typical sequences are:
| Path | Sequence |
|---|---|
| Happy path | 201 issued → 202 received → 203 made available → 204 taken into account → 205 approved → 211 payment advice → 212 receipt |
| Partial approval | 202 → 206 partially approved → 212 |
| Dispute resolved | 202 → 207 in dispute → 208 suspended → 209 completed → 205 approved |
| Refused | 202 → 210 refused |
bill.Status vs bill.Payment
A lifecycle event is modelled as the GOBL document that matches its nature:
bill.Status— processing events: the recipient acknowledging, making available, taking into account, accepting, partially accepting, disputing, suspending or refusing the invoice, or the supplier completing a suspension. These describe where the invoice is in its handling. Codes201–210.bill.Payment— payment events: a payment advice (the buyer tells the supplier a payment has been sent) or a payment receipt (the supplier confirms funds received). These describe money movement, so they use GOBL’s dedicated payment document, which carries the amount, method and value date. Codes211(advice) /212(receipt).
fr-ctc-flow6-v1 addon maps each document to its CDV ProcessConditionCode — you set the natural GOBL fields, not the code.
Building a status
You build the natural GOBL document and the addon derives the CDV code — the full(type, key) → code mapping is in the Status codes table:
bill.Status— set the documenttypeand the linekey; together they select the code (e.g.type: response+key: accepted→205;type: update+key: other→209).bill.Payment— settypetoadvice(→211) orreceipt(→212).
key: rejected covers three outcomes — 210 (the default), 207 and 206. To mean 206 or 207, pin the code on the line:
series + code) and issue date. On a bill.Status line this field is doc; on a bill.Payment line it is document. On receipt the platform resolves the invoice by the supplier’s SIREN + number + year and links the two in the console’s Related tab.
Direction is automatic. You always provide the same supplier (the seller) and customer (the buyer) as on the invoice; the addon derives each party’s CDV role code. For statuses and payment receipts that is SE (Seller) on the supplier and BY (Buyer) on the customer. A 211 payment advice is issued by the payer (the buyer), so it inverts the role codes — in the built document the supplier carries BY and the customer SE. You don’t swap the parties; only the derived roles flip, and the addon handles it.
Reasons, faults and actions
For the dispute and refusal codes (206, 207, 208, 210) the line carries a reason, and that’s where the meaningful detail lives:
reason.key+reason.ext.fr-ctc-flow6-reason— the rejection bucket and the exact CDV reason code (see Reason codes). Set only thekeyand the addon fills the bucket’s default code.reason.faults[]— the field-level corrections. Each fault names one field:codeis the characteristic type (DIV= the value found,DVA= the value expected),messageis the data and value (e.g."Taux TVA (BT-152): 10.00%"), andpathsis the field’s location in the document. Send aDIV/DVApair to say “you put X, it should be Y.”line.actions[]— what the issuer should do next:provide(supply missing info),reissuea corrected invoice, or raise a credit note (credit-full/credit-partial).
209 Complétée requires no reason, but it can carry one to supply data back — e.g. completing a bank-details suspension by returning the corrected IBAN as a MAJ fault (the value to apply) under a finance-terms reason. The line description summarises what was supplied.
Examples
One example per code you build, each referencing the same invoice (INV-2026-0042, supplier SIREN 698680774). Every example pairs the Minimal hand-authored GOBL input with the Built version produced by gobl build — which adds the derived fields (the fr-ctc-flow6-* extensions, party roles, ISO scheme ids and endpoints). The interesting detail is on the dispute / partial / refusal codes: their reason carries faults (the exact field, its actual vs expected value, and the XML path) plus an action telling the issuer what to do next. The plain acknowledgements (201–205) carry no reason — the code itself is the message.
201 — Émise par la plateforme (Issued by platform)
201 — Émise par la plateforme (Issued by platform)
bill.Status · type: response · line key: issued. A plain acknowledgement — no reason or action.202 — Reçue par la PA (Received)
202 — Reçue par la PA (Received)
bill.Status · type: response · line key: acknowledged. A plain acknowledgement.203 — Mise à disposition (Made available)
203 — Mise à disposition (Made available)
bill.Status · type: response · line key: other. A plain acknowledgement.204 — Prise en charge (Taken into account)
204 — Prise en charge (Taken into account)
bill.Status · type: response · line key: processing. A plain acknowledgement.205 — Approuvée (Approved)
205 — Approuvée (Approved)
bill.Status · type: response · line key: accepted. A plain acknowledgement — the invoice is fully approved.206 — Approuvée partiellement (Partially approved)
206 — Approuvée partiellement (Partially approved)
bill.Status · type: response · line key: rejected + pinned ext 206. The reason faults show the invoiced vs approved quantity; the action requests a partial credit note (credit-partial → CNP).207 — En litige (In dispute)
207 — En litige (In dispute)
bill.Status · type: response · line key: rejected + pinned ext 207. The reason faults pinpoint the disputed field — actual VAT rate (DIV) vs expected (DVA) and its XML path; the action requests a full credit note (credit-full → CNF).208 — Suspendue (Suspended)
208 — Suspendue (Suspended)
bill.Status · type: response · line key: querying. The reason names what is missing (order reference); the action asks the supplier to provide it (provide → PIN).209 — Complétée (Completed)
209 — Complétée (Completed)
bill.Status · type: update · line key: other. Issued by the supplier to lift a suspension raised over bank details: a finance-terms reason (condition CBB, coordonnées bancaires à modifier) whose fault supplies the corrected IBAN — code MAJ (the value to apply), the IBAN in the message, and the paths pointing at the invoice’s IBAN field (BT-84).210 — Refusée (Refused by buyer)
210 — Refusée (Refused by buyer)
bill.Status · type: response · line key: rejected. The reason faults pinpoint the failing field; the action asks for a corrected reissue (reissue → NIN).211 — Paiement transmis (Payment advice)
211 — Paiement transmis (Payment advice)
bill.Payment · type: advice. Issued by the buyer (payer); the methods carry the amount and the value_date the payment date. Because it is payer-issued, the built version inverts the CDV roles — BY on the supplier and SE on the customer (you still place the seller in supplier and the buyer in customer; see Direction is automatic).212 — Encaissée (Payment receipt)
212 — Encaissée (Payment receipt)
bill.Payment · type: receipt. Issued by the supplier (payee); the methods carry the amount received.Sending
A status is sent with the same workflow as an invoice — there is no dedicated status step. You build thebill.Status / bill.Payment, then run the standard send pipeline:
Generate CDAR
cii.generate (doc type fr-ctc-cdar-flow6) converts the bill.Status / bill.Payment into its CDAR XML payload. This is the only step that differs from the invoice workflow, which generates a UBL invoice here instead.sign → generate → record → send → forward — so you can reuse the same workflow shape, swapping the UBL invoice generation for the CDAR generation above.
Receiving
Incoming statuses arrive over the same Peppol transport as invoices.Import Peppol document
peppol.import receives the inbound SBD and detects that it is a CDAR rather than an invoice.Status codes
Each code maps to a GOBL document. Most derive from the document’s natural(type, key) pair; 206 and 207 additionally pin an extension (see Building a status). Issued by is the party that sends the event — the counterparty receives it; the two codes marked automatic are emitted by Invopop, you never build them.
| Code | French | English | Document | type · line key | Issued by |
|---|---|---|---|---|---|
200 | Déposée | Deposited | — | — | Invopop (automatic) |
201 | Émise par la plateforme | Issued by platform | bill.Status | response · issued | Supplier’s platform |
202 | Reçue par la PA | Received by recipient | bill.Status | response · acknowledged | Buyer |
203 | Mise à disposition | Made available | bill.Status | response · other | Buyer |
204 | Prise en charge | Taken into account | bill.Status | response · processing | Buyer |
205 | Approuvée | Approved | bill.Status | response · accepted | Buyer |
206 | Partiellement approuvée | Partially approved | bill.Status | response · rejected + ext 206 | Buyer |
207 | En litige | Disputed | bill.Status | response · rejected + ext 207 | Buyer |
208 | Suspendue | Suspended | bill.Status | response · querying | Buyer |
209 | Complétée | Completed | bill.Status | update · other | Supplier |
210 | Refusée | Refused by buyer | bill.Status | response · rejected | Buyer · mandatory to PPF |
211 | Paiement transmis | Payment advice | bill.Payment | advice | Buyer (payer) |
212 | Encaissée | Cashed / paid | bill.Payment | receipt | Supplier (payee) · mandatory to PPF |
213 | Rejetée | Rejected by platform | — | — | Invopop (automatic) |
Reason codes
Codes206, 207, 208 and 210 require at least one reason on the line, and the reason’s code must come from that status’s allow-list. Set the bucket via the reason key and the exact CDAR code via the fr-ctc-flow6-reason extension; if you set only the bucket, the addon fills the default code marked ⚹. Codes 205, 209, 211 and 212 don’t require a reason — though 209 may optionally carry one to supply data back (see Reasons, faults and actions).
206 — Partiellement approuvée (Partially Approved)
206 — Partiellement approuvée (Partially Approved)
AUTRE is the default if the reason code is omitted| Reason code | French | English |
|---|---|---|
AUTRE ⚹ | Autre | Other |
TX_TVA_ERR | Taux de TVA erroné | Incorrect VAT rate |
MONTANTTOTAL_ERR | Montant total erroné | Incorrect total amount |
CALCUL_ERR | Erreur de calcul de la facture | Invoice calculation error |
NON_CONFORME | Mention légale manquante | Missing legal mention |
DOUBLON | Facture en doublon | Duplicate invoice |
DEST_ERR | Erreur de destinataire | Recipient error |
TRANSAC_INC | Transaction inconnue | Unknown transaction |
EMMET_INC | Émetteur inconnu | Unknown issuer |
CONTRAT_TERM | Contrat terminé | Contract ended |
DOUBLE_FACT | Double facture | Double invoicing |
CMD_ERR | N° de commande incorrect ou manquant | Incorrect or missing order number |
ADR_ERR | Adresse de facturation électronique erronée | Incorrect electronic billing address |
SIRET_ERR | SIRET erroné ou absent | Incorrect or missing SIRET |
CODE_ROUTAGE_ERR | CODE_ROUTAGE absent ou erroné | Missing or incorrect routing code |
REF_CT_ABSENT | Référence contractuelle nécessaire | Contractual reference required |
REF_ERR | Référence incorrecte | Incorrect reference |
PU_ERR | Prix unitaires incorrects | Incorrect unit prices |
REM_ERR | Remise erronée | Incorrect discount |
QTE_ERR | Quantité facturée incorrecte | Incorrect invoiced quantity |
ART_ERR | Article facturé incorrect | Incorrect invoiced item |
MODPAI_ERR | Modalités de paiement incorrectes | Incorrect payment terms |
QUALITE_ERR | Qualité d’article livré incorrecte | Incorrect quality of delivered item |
LIVR_INCOMP | Problème de livraison | Delivery problem |
207 — En litige (Disputed)
207 — En litige (Disputed)
AUTRE is the default if the reason code is omitted| Reason code | French | English |
|---|---|---|
AUTRE ⚹ | Autre | Other |
TX_TVA_ERR | Taux de TVA erroné | Incorrect VAT rate |
MONTANTTOTAL_ERR | Montant total erroné | Incorrect total amount |
CALCUL_ERR | Erreur de calcul de la facture | Invoice calculation error |
NON_CONFORME | Mention légale manquante | Missing legal mention |
DOUBLON | Facture en doublon | Duplicate invoice |
DEST_ERR | Erreur de destinataire | Recipient error |
TRANSAC_INC | Transaction inconnue | Unknown transaction |
EMMET_INC | Émetteur inconnu | Unknown issuer |
CONTRAT_TERM | Contrat terminé | Contract ended |
DOUBLE_FACT | Double facture | Double invoicing |
CMD_ERR | N° de commande incorrect ou manquant | Incorrect or missing order number |
208 — Suspendue (Suspended)
208 — Suspendue (Suspended)
JUSTIF_ABS is the default if the reason code is omitted| Reason code | French | English |
|---|---|---|
JUSTIF_ABS ⚹ | Justificatif absent ou insuffisant | Missing or insufficient supporting document |
SIRET_ERR | SIRET erroné ou absent | Incorrect or missing SIRET |
CODE_ROUTAGE_ERR | CODE_ROUTAGE absent ou erroné | Missing or incorrect routing code |
REF_CT_ABSENT | Référence contractuelle nécessaire | Contractual reference required |
REF_ERR | Référence incorrecte | Incorrect reference |
CMD_ERR | N° de commande incorrect ou manquant | Incorrect or missing order number |
ADR_ERR | Adresse de facturation électronique erronée | Incorrect electronic billing address |
210 — Refusée (Refused by buyer)
210 — Refusée (Refused by buyer)
TRANSAC_INC is the default if the reason code is omitted| Reason code | French | English |
|---|---|---|
TRANSAC_INC ⚹ | Transaction inconnue | Unknown transaction |
TX_TVA_ERR | Taux de TVA erroné | Incorrect VAT rate |
MONTANTTOTAL_ERR | Montant total erroné | Incorrect total amount |
CALCUL_ERR | Erreur de calcul de la facture | Invoice calculation error |
NON_CONFORME | Mention légale manquante | Missing legal mention |
DOUBLON | Facture en doublon | Duplicate invoice |
DEST_ERR | Erreur de destinataire | Recipient error |
EMMET_INC | Émetteur inconnu | Unknown issuer |
CONTRAT_TERM | Contrat terminé | Contract ended |
DOUBLE_FACT | Double facture | Double invoicing |
CMD_ERR | N° de commande incorrect ou manquant | Incorrect or missing order number |
ADR_ERR | Adresse de facturation électronique erronée | Incorrect electronic billing address |
REF_CT_ABSENT | Référence contractuelle nécessaire | Contractual reference required |
FAQ
How do I schedule periodic reports for France?
How do I schedule periodic reports for France?
What format does France expect for periodic reports?
What format does France expect for periodic reports?
fr-ctc-flow10-v1 GOBL addon.How often must I submit France PA reports?
How often must I submit France PA reports?
What format does France PA expect for periodic reports?
What format does France PA expect for periodic reports?
🇫🇷 Invopop resources for France
🇫🇷 Invopop resources for France
| Compliance | Compliance timeline |
| Apps | |
| Guides | ChorusPro Guide PA Guide — Registration · Invoicing · Status · Reporting |
| FAQ | France FAQ |
| GOBL | |
| GitHub | gobl.xinvoice |