Skip to main content
Lifecycle status updates on domestic B2B invoices — acknowledged, accepted, disputed, refused, paid. They are exchanged between PAs over Peppol, with the mandatory codes also forwarded to the PPF.
France requires lifecycle status updates on B2B national invoices to be reported to the PPF. You build each one as a GOBL document and send it through the standard send workflow. Which codes you send depends on whether you operate the supplier or the buyer PA (see Status codes for who issues each) — but 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 GOBL bill.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:

​
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. Codes 201–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. Codes 211 (advice) / 212 (receipt).
The 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 document type and the line key; together they select the code (e.g. type: response + key: accepted → 205; type: update + key: other → 209).
  • bill.Payment — set type to advice (→ 211) or receipt (→ 212).
The one ambiguity. The line key: rejected covers three outcomes — 210 (the default), 207 and 206. To mean 206 or 207, pin the code on the line:
Linking to the invoice. Every status or payment references its invoice by the invoice’s full number (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 the key and the addon fills the bucket’s default code.
  • reason.faults[] — the field-level corrections. Each fault names one field: code is the characteristic type (DIV = the value found, DVA = the value expected), message is the data and value (e.g. "Taux TVA (BT-152): 10.00%"), and paths is the field’s location in the document. Send a DIV/DVA pair to say “you put X, it should be Y.”
  • line.actions[] — what the issuer should do next: provide (supply missing info), reissue a corrected invoice, or raise a credit note (credit-full / credit-partial).
The supplier-issued 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.
bill.Status · type: response · line key: issued. A plain acknowledgement — no reason or action.
bill.Status · type: response · line key: acknowledged. A plain acknowledgement.
bill.Status · type: response · line key: other. A plain acknowledgement.
bill.Status · type: response · line key: processing. A plain acknowledgement.
bill.Status · type: response · line key: accepted. A plain acknowledgement — the invoice is fully 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).
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).
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).
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).
bill.Status · type: response · line key: rejected. The reason faults pinpoint the failing field; the action asks for a corrected reissue (reissue → NIN).
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).
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 the bill.Status / bill.Payment, then run the standard send pipeline:
1

Sign envelope

Closes and signs the silo entry (silo.close).
2

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.
3

Record

gov-fr.directory.record links the status to its referenced invoice.
4

Send over Peppol

peppol.send transmits the CDAR to the counterparty’s PA.
5

Forward to PPF

gov-fr.directory.forward forwards the mandatory codes (210, 212) to the PPF. Non-mandatory codes skip this leg.
The structure mirrors Sending an invoice one-for-one — 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.
1

Import Peppol document

peppol.import receives the inbound SBD and detects that it is a CDAR rather than an invoice.
2

Parse to GOBL

The CII app converts the CDAR XML into a GOBL bill.Status / bill.Payment.
3

Record

gov-fr.directory.record files it against the referenced invoice; it then appears in the invoice’s Related tab.

​
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.

​
Reason codes

Codes 206, 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).
AUTRE is the default if the reason code is omitted
AUTRE is the default if the reason code is omitted
JUSTIF_ABS is the default if the reason code is omitted
TRANSAC_INC is the default if the reason code is omitted

​
FAQ

For TVA, file via DGFiP’s portal — Invopop does not generate CA3 yet. For e-reporting (Flow 10): submit via your Plateforme Agréée — Invopop’s e-reporting workflow batches transactions per period and submits to the PPF.
TVA: DGFiP’s EDI-TVA XML schema. E-reporting Flow 10: a structured JSON/XML payload defined by the PPF specification (currently in beta). Invopop emits Flow 10 via the upcoming fr-ctc-flow10-v1 GOBL addon.
Flow 10 e-reporting: 3× per month (every 10 days) for B2C and cross-border transactions. Lifecycle status (CDAR): per event, near real-time. Specific deadlines depend on the supplier’s tax filing cadence (monthly/quarterly).
Flow 10 uses a JSON envelope wrapping aggregated transaction data, defined in the PPF technical specification. Lifecycle CDAR payloads are XML messages exchanged over Peppol with structured status codes.
More available in our France FAQ section