Skip to main content
France runs two parallel flows, and which one an invoice takes depends on whether the customer is registered in the Annuaire (the French directory).
  • Customers subject to VAT in France are handled through the e-invoicing flow for domestic B2B transactions, with status updates reported back throughout.
  • Customers not subject to VAT in France — international or B2C transactions, and territories excluded from the mandate such as Guyane, Mayotte, New Caledonia and French Polynesia — go through e-reporting instead.
This guide assumes you have already connected the Chargebee app and completed the general setup — see the Chargebee overview first if you haven’t. Required apps: France, Peppol, OASIS UBL
Before processing any invoices, you must register your supplier in the Annuaire through Invopop. See the registration guide for the e-invoicing flow and the e-reporting registration steps for the reporting flow.

​
Workflow

A single template covers both French flows and picks between them automatically from the result of the Lookup in Directory step.
  • found result means the customer is subject to e-invoicing, so Invopop records the document in the Annuaire, forwards it to the PPF, and sends it over Peppol.
  • not found result means the transaction falls outside domestic e-invoicing — international B2B, B2C, or a customer in a territory excluded from the mandate — so it is recorded for e-reporting. For those, the Can Send action checks whether the customer is reachable on the Peppol network: if it is (a Belgian party, for example), the workflow sends the invoice over Peppol as well.

Chargebee France

Add to my workspace →

​
Customer routing & identifiers

A single SIREN registered in the Annuaire can have several directory entries, registered under the same or different Plateformes Agréées. Each entry has a unique identifier — mapped to the Peppol inbox — in one of the SIREN, SIREN_SIRET, SIREN_SIRET_suffix or SIREN_suffix forms. When no Peppol inbox is set on the customer, Invopop defaults to 0225:SIREN, ignoring any SIRET present in the customer’s identities. Use the custom fields below to control this. Set the Peppol inbox to target a specific directory entry, or provide the customer’s SIREN and SIRET so the directory lookup can resolve them. All three are configured as Single line text custom fields (or as metadata, using the hyphenated key):

​
E-reporting transaction fields

The e-reporting path applies the fr-ctc-flow10-v1 addon, which defines two invoice tax extensions. By default, the addon sets the billing mode to M1 — or M2 when the invoice is fully paid — and the B2C transaction category to TNT1. Use the custom fields below to override these defaults:
The metadata keys listed above follow the Chargebee metadata format (hyphens, no cf_ prefix). If you prefer to use custom fields instead, replace hyphens with underscores and add the cf_ prefix. See Custom fields & metadata for details.

​
FAQ

Invoicing questions
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.
Transactions exempt under articles 261 to 261 E of the CGI — insurance, medical care, education and the rest of that range — sit outside the e-invoicing mandate, and the PPF rejects them if you deposit one. When an invoice’s whole VAT breakdown is exempt and carries a VATEX-FR-CGI261* code, Invopop records it but sends no F1 and raises no lifecycle status, and the dashboard shows it as Exempt. Keep issuing the invoice to your customer as usual. An invoice that mixes exempt and taxable lines is still sent normally, and so is VATEX-FR-FRANCHISE. See VAT-exempt invoices.
Each invoice or lifecycle status sent through France PA costs 5 pops: 1 pop for the conversion to UBL/CII, 2 pops to send it over Peppol, 1 pop to forward it to the PPF, and 1 pop for the silo entry. See Pops & pricing for how pops work.
Before an invoice is recorded, the PPF record document step looks up both the supplier and the customer SIREN in the Annuaire. What each party must satisfy depends on the workflow’s role:Sandbox invoices skip the Annuaire check entirely.
Don’t block the sale. An exchange where only one party has an effective Annuaire entry is a non-regulated flow: it leaves e-invoicing (flux 2) and is covered by e-reporting (flux 10) instead.In practice:
  • Run a Directory lookup against the customer’s SIREN before you generate the invoice — ideally in a separate validation workflow run against customer data, so you can prompt them to fix their registration ahead of time.
  • If the SIREN has no effective entry, route the invoice through your reporting workflow rather than the PA send workflow.
  • If it slips through, the send workflow degrades rather than failing: the Verify document can be sent step branches and forwards the invoice to the PPF as déposée – non transmise.
A missing entry is common and not necessarily an error. A SIREN visible in the public annuaire-entreprises registry is not the same as an effective entry in the DGFiP Annuaire, which only covers entities in scope of the mandate. It can also be absent because the buyer hasn’t yet appointed a PA, or because their tax records don’t match.
Both, for different reasons. A lookup at order or onboarding time is a data-quality check: it lets you warn the customer and get their SIREN or PA sorted before invoicing. A lookup at invoice time is the one that decides the flow, because registrations are added and withdrawn continuously and a party found at checkout may no longer be routable days later (and vice versa).Treat the early result as advisory, resolve again at generation, and store the resolved electronic address on the transaction — the routing address isn’t always the bare SIREN. See Directory lookup.
You don’t decide it yourself. When the invoice is recorded, Invopop looks the customer up in the Annuaire: a party whose line is routed to Chorus Pro is a public entity, and the invoice is marked B2G. The Is B2G? workflow step reads that answer and branches to Send to Chorus Pro instead of Peppol. See the public sector guide.
Not if your company has a French SIREN and is registered in the Annuaire through Invopop. Invopop holds the connection with Chorus Pro, so B2G invoices use the same send workflow as any other French invoice. Only foreign entities without a French SIREN still go through the standalone Chorus Pro app, which requires Chorus Pro credentials.
The service code (code service or code routage) is a private-id identity on the customer, and the commitment number (numéro d’engagement juridique) is the purchase order reference in ordering.purchases[0].code. Both are supplied by the public entity. The public sector guide lists every field.
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 eu-en16931-v2017 addon for the field and validation rules Peppol BIS Billing 3.0 builds on, and the Peppol app reference for supported document types and Participant ID schemes.
Receiving questions
Register the recipient with Invopop as their Plateforme Agréée. Inbound documents (UBL, CII, Factur-X) are converted to GOBL and stored in the Expenses folder. Chorus Pro inbound flow is separate and routes via the Chorus Pro app.
UBL via gobl.peppol; CII and Factur-X via gobl.cii. The original structured XML (or PDF/A-3 with embedded XML) is preserved as a silo entry attachment.
Register the recipient via Invopop as their PA. Inbound UBL/CII/Factur-X documents are routed to the configured Import workflow and become GOBL silo entries. Lifecycle status updates (CDAR) feed back to the issuer through the same channel.
UBL, CII, or Factur-X (PDF with embedded CII XML), all conforming to EN 16931 and the French CTC profile. Invopop preserves the original and exposes the GOBL conversion.
Yes. A single company can be reachable at several destinations by registering different routing identifiers (electronic addresses) in the Annuaire — one per PDP or inbox. Invoices addressed to a given identifier are delivered to the platform registered against it, so you can route some invoices to Invopop and others to a different PDP (for example a travel-and-expense tool) for the same SIREN.The Annuaire supports several address formats that map to increasingly granular destinations within the same company:
  • SIREN — the company as a whole.
  • SIREN_SIRET — a specific establishment.
  • SIREN_SIRET_ROUTINGCODE — a site, department, or workflow within an establishment.
  • SIREN_SUFFIX — a custom routing suffix.
Give each PDP or inbox a distinct identifier and share the matching address with each issuer, so their invoices reach the intended destination. You can look up an electronic address in the Annuaire to confirm where it currently routes.
An invoice arriving from another platform goes through three controls, run in the order the PPF applies them:
  • Syntax — the invoice XML against the Flux 2 schematron for its syntax.
  • Addressing — both parties carry a SIREN registered in the Annuaire, the transport addresses belong to the parties the invoice names, and the invoice is addressed to a party registered in your workspace.
  • Unicity — the invoice is not already recorded for this party, number and year.
An invoice that passes every control is recorded on the receiving side. Only invoices are validated this way; incoming lifecycle statuses are simply recorded.
Each control rejects under its own CDAR motif, carried on the 213 Rejetée status returned to the platform that sent the invoice:
  • REJ_SEMAN — rejet pour erreur sémantique, when the invoice fails the Flux 2 schematron.
  • ADR_ERR — adresse de facturation électronique erronée, when the addressing control fails.
  • REJ_UNI — rejet sur contrôle unicité, when the invoice is already recorded.
Register the recipient as a Peppol participant with Invopop as their Access Point. Incoming documents are routed through your configured Import workflow, which converts the UBL or CII payload to GOBL and stores the entry in the Expenses folder.
Yes. Either format can be removed based on your needs. The default template includes both for comprehensiveness, but if you’re certain you’ll only receive invoices in one syntax, dropping the other simplifies the workflow and reduces the apps you need to activate.
The Import workflow’s UBL and CII parser steps map the inbound XML into a GOBL invoice. From there you can route it to webhooks, Google Drive, accounting integrations, or any other destination — the GOBL representation is the single source of truth for downstream processing.
More available in our France FAQ section

Participate in our community

Ask and answer questions about your Chargebee integration →