Skip to main content
The France PA invoicing flow covers regulated B2B exchanges where both parties are registered in the French Directory. All other scenarios are handled by the e-reporting (flux 10) flow. This guide walks through how to implement e-invoicing obligations in France:
  • Workflows: sending and receiving workflows for French documents (payments, statuses and invoices).
  • Sending: recording the invoice, generating the format, transmitting over Peppol, and forwarding the F1 copy to the PPF.
  • Receiving: detecting the inbound format, importing it into GOBL, and recording it against your registered party.
  • Invoice formats: UBL, CII, and Factur-X and how to choose between them.
  • Self-billing: how autofacturation maps onto the same send and receive workflows using the self-billed tag.
  • Example invoices: minimal GOBL documents and their built versions, ready to paste into the GOBL builder.

​
Workflows

These workflows are shared between invoice and status documents. The same workflow processes the different schemas and will perform different actions depending on the document type.

​
Sending

The send workflow records the invoice for compliance, generates the chosen format, transmits it to the receiver’s PA over Peppol, and forwards the F1 copy to the PPF as the fifth corner. The PPF record document step validates SIRENs and checks both parties against the Annuaire. Documents where either side is missing are rejected and should branch into the reporting flow for non-regulated transactions.

PPF send invoice

Add to my workspace →

​
Receiving

The receive workflow detects the inbound format, imports it into a GOBL document, and records it against your registered party. The same workflow handles UBL, CII, and Factur-X — the format-detection branch routes each payload to the correct importer.

PPF receive invoice

Add to my workspace →

​
Invoice formats

The PA specification accepts five formats. In practice the three base formats below cover essentially all real-world traffic, and Invopop supports both sending and receiving on all three. Switching formats is a workflow configuration away rather than a data-model change. You author and validate one GOBL invoice, and the workflow’s generation step produces whichever format the counterparty expects.

​
Billing mode

Mandatory on every flux 2 and flux 10 B2B invoice and set in GOBL under tax.ext.fr-ctc-billing-mode. The prefix carries the nature of the operation: B goods (biens), S services, M mixed, plus a suffix for the payment context. The full list of billing-mode codes is documented in the fr-ctc-flow2-v1 addon reference. Suffix 7 covers invoices issued after the sale was already cashed in and reported through e-reporting. For example, a company requesting a B2B invoice after paying a restaurant bill. Marking it S7/B7 tells the PPF not to count the VAT a second time. Suffix 1 is the ordinary case — a plain invoice submitted for payment. Left unset, the add-on defaults the mode to M1 (M2 when fully paid) — pin the prefix that matches the nature of the operation, as the example invoices do.

​
VAT tax keys → UNTDID 5305

GOBL sets the untdid-tax-category (and cef-vatex exemption reason where one applies) from the tax key on each line — you pick the key, the add-on derives the codes: The full field-level rules (permitted document types, VAT percents, and party identifier schemes) are maintained in the add-on.

​
Self-billing

In self-billing (also called autofacturation), the customer, rather than the supplier, creates and issues the invoice on the supplier’s behalf. The buyer’s platform acts as the sending PA and triggers the flow 1 reporting to the PPF, while the supplier’s platform receives the invoice. Invopop covers self-billing with the same send and receive workflows described above. The only difference is on the document, which carries the self-billed tag.
France does not treat self-billing as a document type of its own: it is a standard invoice with the untdid-document-type extension set to 389. The fr-ctc-flow2-v1 add-on derives that code from the self-billed tag automatically, so you never set it yourself.
The parties keep their natural roles, the vendor remains the supplier, and the buyer the customer. When Invopop detects the tag, it acts on behalf of the customer and adjusts the flow automatically:
  • The customer, rather than the supplier, is validated as the registered party.
  • The invoice is delivered over Peppol to the supplier’s PA.
  • The invoice is recorded and forwarded to the PPF as a self-billed invoice.
France also requires the autofacturation note on the invoice, which appears as a legal note, as shown in the example below.

​
Step by step

How each step of the self-billing use case maps to an action in Invopop, on both the buyer (sending) and supplier (receiving) side. Statuses are built and exchanged as described in the status guide.

​
Example invoices

Each example below pairs a hand-authored minimal GOBL invoice with the built version produced by gobl build. Paste either into the GOBL builder to preview the document, or use the minimal version as a starting point for your own integration.
A regulated B2B invoice between two French parties, both registered in the Annuaire. The fr-ctc-flow2-v1 add-on drives validation for the PA e-invoicing flow.Notice:
  • both parties carry a SIREN identity with iso-scheme-id 0002 and a peppol inbox under scheme 0225 so the workflow can route via Peppol,
  • fr-ctc-billing-mode S1 marks the standard submission (dépôt) of a services invoice; untdid-document-type 380 confirms the commercial invoice type,
  • the payment, payment-method, and payment-term notes carry the French legal-mention text (penalty clauses, late-payment terms, early-payment discount), each tagged with the appropriate UNTDID 4451 subject code,
  • ordering.code records the customer’s purchase order reference.
A domestic B2B invoice for construction works supplied by a subcontractor to a taxable main contractor. Because both parties are French, this stays in the PA e-invoicing flow (fr-ctc-flow2-v1) even though it carries no VAT — it is not e-reporting.Notice:
  • the VAT combo uses the reverse-charge key, which sets untdid-tax-category AE and produces a 0.00 VAT total, with no tax rate or amount on the line,
  • the reverse-charge note text is set explicitly to cite article 283-2 nonies (subcontracting); left to the regime default it would cite the generic article 283-1,
  • fr-ctc-billing-mode is S1 — a plain services submission: the reverse charge is carried entirely by the VAT key and note. S5 (subcontractor invoice) applies only to subcontracting with payment delegation (paiement direct), which is not the case here,
  • the reverse charge only applies where the customer is a taxable person — invoicing a non-taxable property owner would carry standard VAT instead.
A credit note that partially cancels a previously issued PA invoice. The preceding array references the original invoice by series, code, and issue date.Notice:
  • type is credit-note and untdid-document-type is 381 (commercial credit note),
  • the preceding block makes the link to the original invoice explicit — required for PA matching at the PPF.
An advance (down-payment) invoice — used when a payment is collected before the final goods or services are delivered.Notice:
  • the prepayment tag sets untdid-document-type to 386 (advance payment invoice),
  • no billing mode is set explicitly: the add-on defaults fr-ctc-billing-mode to M1 (submission of a mixed invoice — here a service plus a good); the advance nature is carried by the document type, not the billing mode,
  • the final invoice issued at delivery normally references this advance to net it off the total.
The final invoice that closes out the advance example above: the full contract is invoiced, and the down payment already billed (FAC 2024-AV-001) is netted off the total.Notice:
  • fr-ctc-billing-mode is pinned to M4 (mixed, final invoice after down payment); left unset it would default back to M1,
  • flow 2 forbids advance-payment document types (386, 500, 503) on final invoices, so untdid-document-type stays 380 (BR-FR-CO-08),
  • payment.advances records the 8,400.00 already paid, referencing the advance invoice — totals.due comes out to the remaining 12,000.00,
  • the due-date payment terms cover only the outstanding balance.
A restaurant cashes in a B2C sale — VAT is collected on the spot and reported through e-reporting — and the guest’s company then asks for a proper invoice. That B2B invoice still travels the flux 2 e-invoicing flow, but must be marked so the VAT is not declared twice.Notice:
  • fr-ctc-billing-mode is pinned to S7 (services, VAT already collected): the VAT was already reported with the B2C sale, so this invoice must not re-declare it. Left unset, the add-on would default to an already-paid mode and the VAT would be counted twice,
  • B7 is the goods counterpart — e.g. retail goods sold over the counter and invoiced to a business afterwards,
  • the 100% advance records the on-site card payment, leaving totals.due at 0.00,
  • restaurant meals carry the intermediate 10% VAT rate.
A domestic B2B invoice issued by the customer on behalf of the supplier under a self-billing (autofacturation) agreement. Self-billed invoices between two French parties still travel through the PA e-invoicing flow (fr-ctc-flow2-v1).Notice:
  • the self-billed tag sets untdid-document-type to 389 (self-billed invoice) — supplier and customer keep their real commercial roles, the tag records that the customer produced the document,
  • the PA validation flips the routing check on self-billed types: it is the customer, as issuer, that must carry the 0225 inbox matching its SIREN,
  • the legal note carries the mandatory Autofacturation mention, auto-tagged with untdid-text-subject ABL; the standard French payment mentions (PMT, PMD, AAB) are filled with regime defaults at build time,
  • the reduced 5.5% VAT rate applies to the foodstuffs being supplied.
A domestic B2B invoice destined for Factur-X output — a human-readable PDF with the UN/CEFACT CII XML embedded (the French implementation of the same specification as ZUGFeRD). It combines the fr-facturx-v1 add-on for the Factur-X format with fr-ctc-flow2-v1, so the same document is also valid for the PA e-invoicing flow.Notice:
  • the two add-ons compose: fr-facturx-v1 drives the Factur-X output while fr-ctc-flow2-v1 applies the PA validation; the eu-en16931-v2017 profile they share is added automatically as a dependency,
  • each party declares only a SIRET identity — at build time the regime derives the legal SIREN identity (iso-scheme-id 0002) from it, next to the 0225 Peppol inboxes required for PA routing,
  • fr-ctc-billing-mode is S2 (services, already paid) because the 100% advance settles the invoice at issue; that mode requires payment terms whose due dates cover the total, leaving totals.due at 0.00,
  • the French payment mentions (PMT, PMD, AAB) are filled with regime defaults at build time.

​
FAQ

Two channels depending on the recipient: B2G uses Chorus Pro (CII format); B2B from September 2026 uses the Plateforme Agréée model (UBL, CII, or Factur-X via Peppol). Invopop is an approved PA — install the France PA app for B2B and the Chorus Pro app for B2G.
In Factur-X PDFs, the XML file is embedded within the PDF itself. To extract and view it, use the Attachments section in Adobe Acrobat Reader, or a tool like the SysTools PDF Extractor.
Invopop is an officially approved Plateforme Agréée under the DGFiP mandate. Registration, invoicing, and lifecycle status are available today; e-reporting (Flow 10) is in active development. See the PA hub readiness matrix for the current state.
The base FR tax regime plus the EN 16931 profile. For Peppol delivery, peppol-bis-v3. The forthcoming fr-ctc-flow10-v1 addon covers e-reporting payloads — separate from the e-invoicing flow.
No. Most Peppol countries treat self-billing as a document type of its own, but France models it as a standard invoice with the untdid-document-type extension set to 389. In GOBL you never set the code yourself: add the self-billed tag and the fr-ctc-flow2-v1 add-on applies it automatically. See Self-billing for the full flow.
In countries where Peppol is the standard but not mandatory, you may still need to issue an e-invoice when the recipient isn’t on the network. Both parties can agree on an alternative transfer method, but the invoice must still be EN16931 compliant.Recommended approach:
  • Set up a separate workflow that generates the XML without the send-Peppol-document step
  • Or reuse your existing workflow without the customer Peppol ID — the send step is automatically skipped
  • Fetch the generated XML and deliver it through the agreed channel, typically email
B2C invoices typically lack the structured customer information required for Peppol delivery, and most consumers don’t have inboxes. Use a conditional workflow:
  1. Add an If/Else step that checks for a customer inbox using count(customer.inboxes, true) > 0.
  2. On the false branch, generate a PDF and email it to the customer, then stop the flow.
This routes B2B invoices through Peppol while keeping a smooth path for consumers.
If a job fails with KO and receiver not found in the peppol network, treat it like an invalid email address — the recipient simply isn’t reachable on Peppol. Add the Lookup Participant ID step (ideally in a separate validation workflow run against customer data) so you catch missing IDs before generating the invoice.
No. The regime is automatically derived from the supplier’s settings, which is the recommended approach for Peppol — leave it unset on the document.
See the oasis-ubl-v2 addon and the Peppol app reference for required fields, supported document types, and Participant ID schemes.
More available in our France FAQ section