PA (Plateforme Agréée) Guide

Send compliant e-invoices through France’s PA system via Peppol and PPF

Introduction

The workflow steps and API used in this guide are subject to change. We are actively working on new approaches to event handling for a more global use case. The examples here are functional and can be used today, but expect updates before the September 2026 mandate.

France handles e-invoicing through approved PA (Plateforme Agréée) platforms as part of its electronic invoicing reform. Invopop is an officially approved PA platform, as listed on the French government’s official list of approved platforms.

Invopop is Plateforme Agréée (Approved Platform) by the French tax administration, meaning we have successfully provided all necessary documentation for the registration procedure and passed the technical compliance verification.

Prerequisites

To use the France PA integration, you will need:

• Invopop workspace with the Peppol and France apps enabled.
• French company registration details including SIREN/SIRET numbers.
• Understanding of your invoicing flows (B2B, B2C, domestic, cross-border) to plan registration and reporting requirements.
• Business processes for status updates to implement the mandatory lifecycle status workflow.

Key Concepts

Annuaire	The French e-invoicing directory where parties must be registered to participate in regulated e-invoicing flows. Not to be confused with the Peppol Directory.
PPF	Portail Public de Facturation — the French government system that receives mandatory invoice data and lifecycle updates. Invopop handles all communications with the PPF automatically.
Regulated Flow	An invoice exchange where both the sender and receiver are registered in the Directory. These follow the complete French e-invoicing process including Peppol transmission and PPF reporting.
Non-Regulated Flow	An invoice exchange where only one party is registered in the Directory. Invoices are stored for e-reporting to the PPF but may not be transmitted via Peppol.
E-Reporting	Periodic reporting to the PPF covering non-regulated flows and B2C transactions.
CDAR	Cross Domain Acknowledgement and Response. The format used for lifecycle status updates (“cycle de vie”) in France, communicated between parties and to the PPF.
Fifth Corner	The tax authority in the Peppol exchange model. Corners 1–4 are sender, sender’s PA, receiver’s PA, and receiver; the fifth corner is the tax authority that receives a copy of the invoice for regulated flows. In France this is the PPF.
F1 Invoice	Simplified UBL format used to forward the invoice to the fifth corner (the tax authority, i.e. the PPF) for regulated flows. Part of e-invoicing, not e-reporting. Generated automatically by Invopop.

E-Invoicing

Annuaire registration

The annuaire is France’s national directory of e-invoicing endpoints. It records every registered company and their PA (Invopop, in this case), so that the tax administration knows how to route regulated e-invoicing flows.

Registering in the annuare enables parties (companies) to send and receive invoices in France. Behind the scenes, it extends the standard Peppol registration workflow with one additional French-specific step to register the party in the Annuaire.

Peppol registration in France always enables both sending and receiving. Once a party is listed in the Annuaire, it must be reachable to receive invoices. There is no send-only option.

How it works

1. Register Party for Approval — submits the party details for Invopop review.
2. Set state to Processing — marks the party as awaiting approval.
3. Wait for Approval — pauses until the party passes the approval check.
4. Register Party — registers the party in the French Directory (gov-fr.party.register). This is the France-specific step added on top of the base Peppol flow.
5. Register Peppol Party — registers the party on the Peppol network with the france document group, enabled for sending and receiving via SMP/SML/Peppol.
6. Set state to Registered — marks the party as fully onboarded.

If you want to understand the base Peppol onboarding this workflow is built on, see the Peppol registration guide. The France PA workflow is the same flow plus the Register Party (France) step before the Peppol registration step.

Workflow code

Template

France PA register party workflow

Registers a party in the Annuaire and on the Peppol network for sending and receiving invoices.

Add to my workspace

Code

Copy and paste into a new Empty Party workflow code view.

Invoice formats

The French PA specification lists five accepted invoice formats. UBL and CII each have a base version and an extended version (adding extra fields for French-specific requirements), and Factur-X rounds out the list. In practice, the three base formats cover essentially all real-world exchanges, and Invopop supports sending and receiving all three:

Format	Description
UBL	XML invoice based on the Peppol France CIUS. The default format used across the Peppol network and the one we recommend for all outgoing flows. An extended UBL variant also exists but is rarely needed.
CII	UN/CEFACT Cross Industry Invoice — another XML format, semantically equivalent to UBL and required by some counterparties (particularly in cross-border and automotive/industrial contexts). An extended CII variant is also accepted.
Factur-X	Hybrid PDF/A-3 with an embedded CII XML payload. Human-readable on top, machine-readable underneath. Common with buyers who want a visual invoice alongside the structured data. Factur-X is a joint Franco-German standard (identical to ZUGFeRD) aligned with the European Norm EN 16931.

We recommend sending as UBL. It’s the native Peppol France CIUS format, has the widest receiver support, and is the cleanest to validate. Choose CII or Factur-X only when a specific counterparty requires it.

The underlying invoice is always the same GOBL document with the fr-ctc-flow2-v1 add-on. The format is only an addition at the end of the workflow — switching format is a configuration change, not a data-model change. That means:

• You author and validate one GOBL invoice.
• The workflow’s generation step produces the chosen format (UBL, CII, or Factur-X).
• Incoming invoices in any of the three formats are converted back into the same GOBL representation for you to consume.

Sending

Invoices

The workflow steps below are subject to change. We are working on new methods of handling events for a more global use case. This example is functional today, but expect refinements before the September 2026 mandate.

The sending workflow records the invoice for France PA compliance, transmits it via Peppol, and then forwards it to the PPF.

This workflow is for B2B regulated flows. The gov-fr.invoice.record step validates this up-front and will reject the invoice if it doesn’t meet the criteria (e.g. if the receiver is not registered in the Annuaire).

For mixed traffic, run a Annuaire lookup step and if-else statements earlier in the workflow and branch non-regulated invoices into the periodic e-reporting path instead.

How it works

1. Set state to Processing — marks the job as in progress.
2. Sign the envelope — locks the GOBL document against further modification.
3. Record Invoice — validates SIRENs, checks both parties against the Annuaire, and records the invoice.
4. Generate UBL Document — produces a Peppol France CIUS–compliant UBL invoice or credit note.
5. Send via Peppol — transmits the invoice to the receiver’s PA platform over the Peppol network.
6. Set state to Sent — marks successful Peppol delivery.
7. Forward to PPF — sends the F1 invoice and the mandatory déposée (deposited) status to the PPF (the fifth corner).
8. Set state to Completed — marks full completion including PPF reporting.

Workflow code

Template

France PA send invoice workflow

Records and sends a France-compliant invoice via Peppol and the PPF.

Add to my workspace

Code

Copy and paste into a new Empty Invoice workflow code view.

Status

Status is moving to a first-class GOBL document. Today a status update is a CDAR XML attached to the originating invoice; we are designing a dedicated GOBL document so lifecycle statuses become standalone documents with their own schema. The workflow below is functional and safe to use now — expect the steps and job arguments to change once the new GOBL status document is released.

France requires mandatory lifecycle status updates to be reported to the PPF for B2B national invoices. You must implement workflows for the two statuses that are your responsibility:

Status	Code	Trigger
Encaissée (cashed/paid)	212	Invoice has been paid
Refusée (refused by buyer)	210	Buyer refuses the invoice (business rejection)

The following statuses are handled automatically by Invopop and do not require a workflow:

Status	Code	When
Déposée (deposited)	200	Sent automatically when the invoice is created
Rejetée (rejected by platform)	213	Sent automatically on processing failure

You can also send additional non-mandatory statuses (e.g. 205 Approuvée, 207 En litige) for lifecycle tracking. The status workflow below handles all of these.

How it works

1. Generate Status (France) — creates a CDAR document with the specified status code and reason code. The status_code, reason_code, and optional reason_text are configured per workflow or passed as job arguments.
2. Send via Peppol — transmits the CDAR to the counterparty over Peppol.
3. Forward to PPF — for mandatory statuses (210, 212), sends the notification to the PPF in the required format.

Using job arguments

Instead of hardcoding the status in the workflow configuration, you can pass the status details as job arguments when creating the job. Arguments take priority over the workflow’s configured values, so you can use a single workflow for multiple status types.

The supported arguments are:

Argument	Description
code	Status code (200–213). Overrides status_code in the workflow config.
reason-code	Reason code (e.g. MONTANTTOTAL_ERR). Overrides reason_code in the workflow config. If omitted, a default reason code is applied based on the status code.
reason-text	Optional free-text explanation. Overrides reason_text in the workflow config.

For example, to trigger a Refusée (refused) status using a workflow that is configured with a different default:

{
  "args": {
    "code": "210",
    "reason-code": "DOUBLON",
    "reason-text": "Duplicate invoice already processed"
  }
}

This approach is useful when you want a single status workflow that can handle multiple status types dynamically, driven by your business logic.

Workflow code

The example below is configured for status 207 (En litige / Disputed) with reason code MONTANTTOTAL_ERR. Change status_code and reason_code to match your use case, or override them at runtime using job arguments as described above.

Template

France PA send status workflow

Generates and forwards a lifecycle status update (CDAR) via Peppol and the PPF.

Add to my workspace

Code

Copy and paste into a new Empty Invoice workflow code view.

We recommend creating a separate workflow for each mandatory status type (paid, refused) with the appropriate code pre-configured, rather than a single generic workflow. This keeps your operational runbooks simple and reduces the risk of sending the wrong code.

Available status codes

Code	French	English	Mandatory to PPF
200	Déposée	Deposited	Yes (automatic)
205	Approuvée	Accepted	No
206	Partiellement approuvée	Partially Approved	No
207	En litige	Disputed	No
208	Suspendue	Suspended	No
209	Complétée	Completed	No
210	Refusée	Refused by buyer	Yes (manual)
211	Paiement transmis	Payment transmitted	No
212	Encaissée	Cashed/Paid	Yes (manual)
213	Rejetée	Rejected by platform	Yes (automatic)

Reason codes by status

Each status code accepts specific reason codes. Statuses not listed below (e.g. 205, 209, 211, 212) do not require a reason code.

200 — Déposée (Deposited)

Reason Code	Description
NON_TRANSMISE	Destinataire non connecté

Default: NON_TRANSMISE

206 — Partiellement approuvée (Partially Approved)

Reason Code	Description
AUTRE	Autre
TX_TVA_ERR	Taux de TVA erroné
MONTANTTOTAL_ERR	Montant total erroné
CALCUL_ERR	Erreur de calcul de la facture
NON_CONFORME	Mention légale manquante
DOUBLON	Facture en doublon
DEST_ERR	Erreur de destinataire
TRANSAC_INC	Transaction inconnue
EMMET_INC	Émetteur inconnu
CONTRAT_TERM	Contrat terminé
DOUBLE_FACT	Double facture
CMD_ERR	N° de commande incorrect ou manquant
ADR_ERR	Adresse de facturation électronique erronée
SIRET_ERR	SIRET erroné ou absent
CODE_ROUTAGE_ERR	CODE_ROUTAGE absent ou erroné
REF_CT_ABSENT	Référence contractuelle nécessaire
REF_ERR	Référence incorrecte
PU_ERR	Prix unitaires incorrects
REM_ERR	Remise erronée
QTE_ERR	Quantité facturée incorrecte
ART_ERR	Article facturé incorrect
MODPAI_ERR	Modalités de paiement incorrectes
QUALITE_ERR	Qualité d’article livré incorrecte
LIVR_INCOMP	Problème de livraison

Default: AUTRE

207 — En litige (Disputed)

Reason Code	Description
AUTRE	Autre
TX_TVA_ERR	Taux de TVA erroné
MONTANTTOTAL_ERR	Montant total erroné
CALCUL_ERR	Erreur de calcul de la facture
NON_CONFORME	Mention légale manquante
DOUBLON	Facture en doublon
DEST_ERR	Erreur de destinataire
TRANSAC_INC	Transaction inconnue
EMMET_INC	Émetteur inconnu
CONTRAT_TERM	Contrat terminé
DOUBLE_FACT	Double facture
CMD_ERR	N° de commande incorrect ou manquant

Default: AUTRE

208 — Suspendue (Suspended)

Reason Code	Description
JUSTIF_ABS	Justificatif absent ou insuffisant
SIRET_ERR	SIRET erroné ou absent
CODE_ROUTAGE_ERR	CODE_ROUTAGE absent ou erroné
REF_CT_ABSENT	Référence contractuelle nécessaire
REF_ERR	Référence incorrecte
CMD_ERR	N° de commande incorrect ou manquant
ADR_ERR	Adresse de facturation électronique erronée

Default: JUSTIF_ABS

210 — Refusée (Refused by buyer)

Reason Code	Description
COORD_BANC_ERR	Erreur de coordonnées bancaires
TX_TVA_ERR	Taux de TVA erroné
MONTANTTOTAL_ERR	Montant total erroné
CALCUL_ERR	Erreur de calcul de la facture
NON_CONFORME	Mention légale manquante
DOUBLON	Facture en doublon
DEST_ERR	Erreur de destinataire
TRANSAC_INC	Transaction inconnue
EMMET_INC	Émetteur inconnu
CONTRAT_TERM	Contrat terminé
DOUBLE_FACT	Double facture
CMD_ERR	N° de commande incorrect ou manquant
ADR_ERR	Adresse de facturation électronique erronée
SIRET_ERR	SIRET erroné ou absent
CODE_ROUTAGE_ERR	CODE_ROUTAGE absent ou erroné
REF_CT_ABSENT	Référence contractuelle nécessaire
REF_ERR	Référence incorrecte
PU_ERR	Prix unitaires incorrects
REM_ERR	Remise erronée
QTE_ERR	Quantité facturée incorrecte
ART_ERR	Article facturé incorrect
MODPAI_ERR	Modalités de paiement incorrectes
QUALITE_ERR	Qualité d’article livré incorrecte
LIVR_INCOMP	Problème de livraison

Default: TRANSAC_INC

213 — Rejetée (Rejected by platform)

Reason Code	Description
REJ_SEMAN	Rejet pour erreur sémantique
REJ_UNI	Rejet sur contrôle unicité
REJ_COH	Rejet sur contrôle cohérence de données
REJ_ADR	Rejet sur contrôle d’adressage
REJ_CONT_B2G	Rejet sur contrôles métier B2G
REJ_REF_PJ	Rejet sur référence de PJ
REJ_ASS_PJ	Rejet sur erreur d’association de la PJ
IRR_VIDE_F	Contrôle de non vide sur les fichiers du flux
IRR_TYPE_F	Contrôle de type et extension des fichiers
IRR_SYNTAX	Contrôle syntaxique des fichiers du flux
IRR_TAILLE_PJ	Contrôle de taille des PJ
IRR_NOM_PJ	Contrôle du nom des PJ
IRR_VID_PJ	Contrôle de PJ non vide
IRR_EXT_DOC	Contrôle de l’extension des PJ
IRR_TAILLE_F	Contrôle de taille max des fichiers
IRR_ANTIVIRUS	Contrôle anti-virus
DEST_INC	Destinataire inconnu
ADR_ERR	Adresse de facturation électronique erronée
DOUBLON	Facture en doublon
CALCUL_ERR	Erreur de calcul de la facture
TX_TVA_ERR	Taux de TVA erroné
MONTANTTOTAL_ERR	Montant total erroné

Default: REJ_SEMAN

Receiving

Incoming invoices and incoming status updates (CDAR) both arrive over the same Peppol transport. The following example shows how invoices are received and processed.

Incoming documents arrive via Peppol in one of the three supported formats (UBL, CII, or Factur-X PDF). The receive workflow branches on the detected format, imports it into the shared GOBL representation, records it against the France PA system as an incoming invoice, and files it in the Invoices · Expenses folder.

How it works

1. Import Peppol Document — receives the inbound Peppol payload and branches on the detected format code:
   • UBL → Import UBL Document (ubl.import) converts the UBL XML to GOBL.
   • CII → Import UN/CEFACT CII Document (cii.import) converts the CII XML to GOBL.
   • PDF → Import PDF (Factur-X) (cii.pdf.import) extracts the embedded CII and converts it to GOBL.
2. Set Folder — files the invoice under Invoices · Expenses.
3. Record Invoice — validates SIRENs, checks both parties against the Annuaire, resolves your registered party as the customer (or supplier if self-billed), and guards against duplicates.
4. Set state to Registered — marks the incoming invoice as successfully received.

Workflow code

Template

France PA receive invoice workflow

Imports an incoming Peppol invoice (UBL, CII, or Factur-X PDF) and records it against the France PA system.

Add to my workspace

Code

Copy and paste into a new Empty Invoice workflow code view.

Reporting

Registration

Reporting is done at the SIREN level, not at the party or invoice level. Before a party can submit any reports, it must be registered for reporting so Invopop has an internal SIREN-keyed record to attach all subsequent reports to.

Registration has two requirements:

1. Record a SIREN. Send the party along with its SIREN. Invopop stores an internal record keyed by that SIREN, which all later invoice and payment reports will be attached to and aggregated under for submission to the PPF.

2. Select a reporting cadence. Periodic reporting is submitted on a fixed schedule tied to the party’s VAT regime. Invoice/transaction data and payment data have separate schedules — choose the cadence that matches the party’s regime for each.

   The schedules are identical for the Quarterly Actual, Simplified VAT, and Non-Established Taxpayer regimes. Only the Monthly Actual Regime differs: invoice/transaction data is reported in ten-day periods, while payments are reported monthly.

   Invoice and transaction data

   VAT Regime	Period	Submit to PPF	PPF → Tax Authorities
   Monthly Actual Regime	Ten-day periods: 1st–10th, 11th–20th, 21st–month end	10 days after the period ends (20th of current month, end of current month, 10th of following month)	1st ten-day: 21st at 08:00 · 2nd ten-day: 1st of following month at 08:00 · 3rd ten-day: 11th of following month at 08:00
   Quarterly Actual Regime	Monthly	10th of the following month	11th of the following month at 08:00
   Simplified VAT Taxation Regime	Monthly	Between the 25th and 30th of the following month	1st of the second following month at 08:00
   Non-Established Taxpayer VAT Regime	Bimonthly (every two calendar months)	Between the 25th and 30th of the following month	1st of the second following month at 08:00

   Payment data

   VAT Regime	Period	Submit to PPF	PPF → Tax Authorities
   Monthly Actual Regime	Monthly	10th of the following month	11th of the following month at 08:00
   Quarterly Actual Regime	Monthly	10th of the following month	11th of the following month at 08:00
   Simplified VAT Taxation Regime	Monthly	Between the 25th and 30th of the following month	1st of the second following month at 08:00
   Non-Established Taxpayer VAT Regime	Bimonthly (every two calendar months)	Between the 25th and 30th of the following month	1st of the second following month at 08:00

Once both are in place, the party is ready to report invoices and payments (see the following sections).

Invoice and payment reports are GOBL documents that use the fr-ctc-flow10-v1 add-on (distinct from the fr-ctc-flow2-v1 add-on used for e-invoicing). The Flow 10 add-on is still under development and some fields are not yet finalized — expect breaking changes until it is released.

How reporting works

Once a party is registered, Invopop drives reporting automatically:

• Automatic regular reports. For each registered SIREN, Invopop aggregates all invoices and payments sent to the reporting workflow during the current period and submits the report to the PPF on the configured cadence. No manual trigger is required — if the data is there by the deadline, the report goes out.
• Corrective reports. You can also trigger a corrective report to fix an error in a previously submitted report. This is the path to use when, for example, an invoice was reported with a wrong amount (a missing zero, a typo) or the wrong transaction was included, and you need to amend a prior period rather than only adjusting future filings.

Both invoice and payment reporting share this model.

Report an invoice

To report an invoice, send it to a reporting workflow. The workflow stores the invoice against the registered SIREN; Invopop then builds and submits the periodic report to the PPF on the cadence selected at registration, and triggers a corrective report whenever one is needed.

The invoice must use the fr-ctc-flow10-v1 add-on (Flow 10), which extends the standard GOBL invoice with the fields required for French e-reporting.

Report a payment

Payment reporting follows the same pattern as invoice reporting: send the payment document to a reporting workflow, Invopop stores it against the registered SIREN, and payment data is included in the periodic (and, when needed, corrective) report at the selected cadence.

Payments also use the fr-ctc-flow10-v1 add-on.

---

🇫🇷 Invopop resources for France

Compliance	Invoicing compliance in France Compliance timeline
Apps	Peppol ChorusPro France
Guides	ChorusPro Guide PA Guide
FAQ	France FAQ
GOBL	France Tax Regime Chorus Pro Addon French Factur-X Addon
GitHub	gobl.xinvoice

France FAQ

Find answers to frequently asked questions about invoicing in France →

Participate in our community

Ask and answer questions about invoicing in France →