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. Statuses on invoices received from a public entity travel to Chorus Pro instead; see the public sector guide. 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

Invopop automatically emits 200 on the invoices you send and 213 on the invoices your parties receive, automatically, as the Plateforme Agréée — you never build or send these. 201 is optional: Invopop doesn’t emit it in every case, and if your process needs it you can send it yourself as a bill/status with a line of key issued, like any other status (see the 201 example).
Don’t rely on receiving a 201. The regulatory confirmation is the PPF’s acceptance of the F1 copy and the 200 status, which the Forward document to PPF step waits for.
A 213 depends on which side of the invoice you are on:
  • Invoices your parties receive: Invopop raises it when an incoming invoice fails its controls (see Receiving).
  • Invoices you send: the buyer’s platform may raise one, and it arrives through your receive workflow like any other status. The PPF also raises one when it rejects the deposit, for example as a duplicate; the Forward document to PPF step then fails with the PPF’s reasons in the job’s faults.
  • Invoices that fail Invopop’s checks before sending: there is no 213. The send job fails, with the reasons in its faults.

​
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. To receive the statuses your counterparties send, the Peppol app’s Incoming Workflow must point at the receive workflow (see Receiving).

​
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. When it records the status, the platform resolves the invoice by supplier SIREN + number + year and writes the invoice’s UUID into the line’s doc.uuid. From then on the two are linked, both in the console’s Related tab and through the API’s Find related entries endpoint. Some statuses can be recorded even when no invoice matches; they’re stored without the link.
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, including the optional 201, 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. Optional: send it only if your process needs it. 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.

​
Reading submitted statuses

The France dashboard’s E-Invoicing Flow 6 tab lists every lifecycle status sent or received by the workspace, newest first. In the Console, open the Apps view, select the France app, and switch to the E-Invoicing Flow 6 tab. Each row shows the referenced Invoice code and Invoice year, the CDAR Code (for example 205 Approved), the Silo entry that holds the status document, the Owner SIREN, the invoice’s Supplier SIREN, the Role (Sender when you issued the status, Receiver when it arrived from the counterparty’s PA), the PPF status of the mandatory forward (same vocabulary as the invoicing guide), the Issue date, and the Invoice ID this status was recorded against. The PPF status only applies to the mandatory status codes — 200 Déposée, 210 Refusée, 212 Encaissée, and 213 Rejetée, the only ones forwarded to the PPF. All other codes are exchanged between PAs over Peppol only, so their PPF status stays at Ready. Statuses recorded against a VAT-exempt invoice show Exempt and are never forwarded. That invoice was never deposited, so the PPF has nothing to record a status against.
Clicking the Invoice code looks up the exact invoice on the E-Invoicing Flow 2 tab, filtered by the Invoice ID.
Filter the table by Owner SIREN, Invoice ID, Invoice code, or Status code. Via the API, a recorded status carries the invoice’s UUID in lines[].doc.uuid, including statuses received from another PA. To list every status recorded against an invoice, call Find related entries on the invoice’s entry.

​
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.
Recording a transaction for e-reporting (B2C or international B2B) costs 2 pops per invoice: 1 pop to record it and 1 pop for the silo entry. On top of that, each report submission costs 10 pops. See Pops & pricing for how pops work.
A refusal cancels the invoice. It can’t be corrected, re-sent, or revived — the transaction has to be re-invoiced from scratch, and the refusal is reported to the DGFiP.Refusal is not a dispute. It is reserved for a short list of grounds: a legal or contractual omission the platforms don’t check (a missing PO reference, for instance), a transaction the buyer doesn’t recognise, or an objective contractual block. Disagreement over price, quantity, or delivery is a dispute — the invoice stays in force and payable while the parties sort it out. Expect buyers to reach for “refuse” when they mean “contest”, and give them a separate path if you’re building the UI.Payment terms restart. The replacement invoice carries its own due date, so agree explicitly with the counterparty how late-payment penalties are treated across the gap rather than assuming the original clock survives.Most refusals are preventable. The common grounds trace back to the mandatory mentions: buyer SIREN, delivery address where it differs from billing, nature of the operation, and any PO reference the buyer requires. Getting those right on issue removes most of the exposure.
More available in our France FAQ section