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 — or rejecting it with a 213.
  • Invoice formats: UBL, CII, and Factur-X and how to choose between them.
  • Public sector: invoices to public entities travel over Chorus Pro instead of Peppol, and public entities can now invoice you the same way.
  • Self-billing: how autofacturation maps onto the same send and receive workflows using the self-billed tag.
  • VAT-exempt invoices: why an invoice exempt under articles 261 to 261 E is recorded but never sent to the PPF.
  • Reading submitted invoices: follow every sent and received invoice, and its PPF state, from the France dashboard.
  • 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. The mandatory 200 Déposée status is transmitted automatically alongside the F1. 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. It also sets aside invoices that fall outside the mandate — see VAT-exempt invoices below. The Forward document to PPF step generates and transmits to the PPF the F1 copy of the invoice and its 200 Déposée status. When the step’s Deposited and not transmitted toggle is enabled, the status carries the NON_TRANSMISE reason and reports a déposée – non transmise instead of the standard déposée. This should be used when the recipient has no active receiving address. Gate that branch on the Peppol Validate endpoint action: when it returns false, the invoice can’t be delivered over Peppol and the workflow should route into a forward step configured as not transmitted.

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. Before an invoice arriving from another platform is recorded, it goes through a series of controls and is rejected if invalid. Only invoices are automatically validated and rejected; incoming lifecycle statuses are simply recorded. An invoice that fails a control is not recorded. The workflow creates a silo entry holding a new 213 Rejetée under the motif of the control that turned the invoice down, and runs it through the rejection workflow. Set that workflow once for the whole workspace in Incoming Document Rejection Workflow, under the France app’s configuration. Selecting a Rejection Workflow directly on the receiving step overrides it, so a flow that needs its own can have one.

PPF receive invoice

Add to my workspace →

​
Public sector (B2G and G2B)

An invoice to a French public entity follows the same path as any other: it is recorded the same way, and its F1 copy and 200 Déposée status reach the PPF unchanged. Only delivery differs — it goes to Chorus Pro instead of Peppol. You do not decide this yourself. The Is B2G? step answers it, reading what the record step already worked out — or, for an invoice that has not been recorded, looking the counterparty up in the Annuaire itself: Branch on that result the same way you branch on Directory lookup. Keep it after the record step, which is where the answer comes from. Everything after it is shared: both paths forward to the PPF.

PPF send invoice (public sector)

Add to my workspace →
Chorus Pro adds its own rules on top of the norm, and they apply only to public-sector invoices. The record step enforces them once an invoice is identified as b2g — invoice numbers of 20 characters or fewer, a SIRET alongside every SIREN, an IBAN of exactly 27 characters, and the length limits Chorus Pro places on names, notes and references. An invoice that breaks one is rejected at record rather than minutes later by Chorus Pro.

​
Receiving from a public entity (G2B)

G2B is the same exchange in reverse: a French public entity issues an invoice to your business. It is new with the 2026 reform — public bodies previously had no route to invoice the private sector electronically. The path differs from a B2B invoice in where it comes from, not in what you do with it:
  1. The public entity submits the invoice to Chorus Pro, in UBL or Factur-X.
  2. Chorus Pro delivers it to Invopop, addressed to the Annuaire line your party is registered under. That line is what decides which workspace receives it — so the party must be registered before any public entity can invoice it.
  3. Invopop converts it to GOBL and starts your Chorus Pro workflow on it.
  4. The invoice is recorded against your party, exactly as an inbound Peppol invoice would be.
From there it behaves like any other received invoice: it appears in the France dashboard, and you answer with status updates as the invoice is accepted, disputed or paid. Two things are worth knowing. The lifecycle statuses you send back follow the AFNOR norm rather than Chorus Pro’s own vocabulary — Chorus Pro translates its internal codes before they reach you, so Rejetée arrives as 210 and its own rejection motifs arrive as their AFNOR equivalents. And the workspace an invoice lands in is decided entirely by the Annuaire line it is addressed to, which is why registration is a prerequisite rather than a convenience.

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

​
VAT-exempt invoices

The e-invoicing obligation in article 289 bis of the CGI does not cover transactions exempt from VAT under articles 261 to 261 E — insurance, medical care, education and the other exemptions in that range. Those invoices are outside the mandate and must not be deposited at the PPF, which rejects them outright. Invopop recognises them and stops before sending. An invoice is treated as exempt when both of the following hold:
  • every VAT category on the invoice is E (exempt) or O (outside scope), and
  • the breakdown carries one of the VATEX-FR-CGI261* exemption codes in the cef-vatex extension.
When that happens:
  • the invoice is recorded in your workspace as usual, so it stays on the France dashboard and in the silo;
  • no F1 copy is sent to the PPF, and no lifecycle status is forwarded for it — neither the automatic déposée nor any status you record later, such as Encaissée. With no deposit, the PPF has nothing to record a status against;
  • the PPF status column shows Exempt;
  • the workflow completes successfully rather than failing.
Issue the invoice to your customer exactly as before. Being outside the e-invoicing mandate changes nothing about your ordinary invoicing obligations, including the mandatory mention of the legal basis for the exemption required by article 242 nonies A of Annex II to the CGI. In GOBL that text comes from a tax.note with category VAT; the cef-vatex extension alone only produces the code.
An invoice that mixes exempt and taxable lines stays inside the mandate and is deposited normally — the rule only applies when the whole VAT breakdown is exempt. Exemptions under other articles are unaffected too: VATEX-FR-FRANCHISE (franchise en base, article 293 B) is deposited as usual. E-reporting is a separate obligation and is not affected by this rule. If the transaction falls under e-reporting — a non-taxable customer, or a counterparty outside France — report it there as you normally would.

​
Reading submitted invoices

The France dashboard’s E-Invoicing Flow 2 tab lists every invoice the workspace has sent or received, newest first. In the Console, open the Apps view, select the France app, and switch to the E-Invoicing Flow 2 tab. Each row shows the Invoice code, the Supplier and Customer SIREN, the PPF status of the mandatory F1 copy, the Role (Sender when you issued the invoice, Receiver when it arrived from a counterparty), the Silo entry that holds the invoice document, the Issue date, the Owner SIREN (the registered party the invoice belongs to), the document Type (standard, self-billed, corrected, credit note, …), and the Invoice ID. The PPF status column tracks the copy forwarded to the tax authority:
Clicking the Invoice code looks up all associated statuses on the E-Invoicing Flow 6 tab, filtered by the Invoice ID.
Filter the table by Supplier SIREN, Customer SIREN, Invoice code, or Invoice ID.

​
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

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.
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 Q&A available in our France FAQ section