Skip to main content
Lifecycle status updates on domestic B2B invoices are exchanged between PAs over Peppol, with the mandatory codes also forwarded to the PPF. Each status must be built as a GOBL silo entry and processed through the invoicing workflow. Which codes you send depends on whether you operate the supplier or the buyer PA (see Status codes for who issues each).

​
Status codes

Status codes correspond to a lifecycle event that is modeled as a GOBL document that matches its purpose. Payment events 211 and 212 are GOBL bill/payment documents. Other codes are invoice lifecycle events bill/status. The fr-ctc-flow6-v1 addon maps each document to its CDV ProcessConditionCode. You set the GOBL fields, not the code.

​
Issued by the platform

Emitted automatically by Invopop as the Plateforme Agréée — you never build or send these.

​
Issued by the buyer

​
Issued by the supplier

​
Invoice lifecycle

After an invoice is issued it moves through a sequence of lifecycle events. Each event is a GOBL status or GOBL payment that references the invoice and carries one CDV ProcessConditionCode. For the full list of codes 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:

​
Workflows

A status is sent or received with the same workflow as an invoice.
There is no dedicated status workflow. The invoicing workflow will generate the appropriate format for each type (CDAR) and report to the tax authority when required. If you have installed the workflows from the invoicing guide, then you’re ready to generate status lifecycle events.

​
Building a status

You never set the CDV code directly — you build the GOBL document and the fr-ctc-flow6-v1 addon derives it. Start from the schema and let the document type plus the line key select the code. Each example shows its type and key pair. In this example, response + accepted derives 205.
bill/status
Keep the same supplier and customer as on the invoice, whichever direction the event travels, and point the line’s doc at the invoice’s full number and issue date. The platform resolves the invoice by supplier SIREN + number + year and links the two in the console’s Related tab.
bill/status
The line key: rejected covers three outcomes:
  • 210 Refused (default).
  • 207 Disputed.
  • 206 Partially approved.
To pin statuses 206 or 207, set the fr-ctc-flow6-status extension:
bill/status
For 211 (payment advice) and 212 (cashed) set a payment schema. Its type alone derives the code and the payment methods carry the amount, while the invoice reference sits in the line’s document field. Codes for each payment direction are derived and there’s no need to swap parties.
bill/payment

​
Reasons, faults and actions

Codes 206, 207, 208 and 210 must carry at least one reason on the line. The reason says why, the faults say which field, and the actions say what the supplier should do next. Together on a 206 partial-approval line — “you invoiced 10, we approved 8, send a partial credit note”:
The supplier’s 209 Complétée uses the same structure in reverse: it lifts a 208 suspension by returning the requested data as a fault — code MAJ, with the corrected value in message. See the 209 example.

​
Available reasons for codes

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

​
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, direction is automatic).
bill.Payment · type: receipt. Issued by the supplier (payee); the methods carry the amount received.

​
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