> ## Documentation Index
> Fetch the complete documentation index at: https://invopop-fi-party-endpoints.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# France FAQ

> Frequently asked questions about invoicing compliance in France

### Compliance questions

**France**

<AccordionGroup>
  <Accordion title="When does mandatory B2B e-invoicing start in France?">
    1 September 2026 for receiving (all businesses) and issuing for large/mid-size companies. 1 September 2027 extends issuing to SMEs and micro-businesses. B2G via Chorus Pro has been mandatory since 2017–2020 (phased by company size).
  </Accordion>
</AccordionGroup>

**Chorus Pro**

<AccordionGroup>
  <Accordion title="When is Chorus Pro mandatory in France?">
    For all B2G transactions with French public administrations — phased in by supplier size from 2017, fully mandatory since 2020. Once an invoice is destined for a public entity, Chorus Pro is the only legal channel.
  </Accordion>

  <Accordion title="What is required to issue invoices under Chorus Pro?">
    Suppliers must register on Chorus Pro's portal and obtain credentials. Foreign businesses without a SIRET can register with their local tax ID but must verify acceptance with the receiving administration on a case-by-case basis.
  </Accordion>
</AccordionGroup>

**PA (Plateforme Agréée)**

<AccordionGroup>
  <Accordion title="How are credit notes and corrections handled?">
    E-invoices cannot be deleted or retracted. Instead a credit note or corrected invoice is sent referencing the original.
  </Accordion>

  <Accordion title="Are there special supplier obligations under France PA?">
    The supplier must be registered in the Annuaire (the DGFiP-maintained directory of B2B participants) via an approved PA. Once registered, Invopop becomes the supplier's PA for sending and receiving over Peppol.
  </Accordion>

  <Accordion title="Do SMEs have to register in the Annuaire before their e-invoicing mandate applies?">
    Yes. From 1 September 2026 every French business, regardless of size, must be able to receive e-invoices, which requires an Annuaire registration through a PA. SMEs and micro-businesses are not required to issue e-invoices or e-report until 1 September 2027 — those obligations follow the company's size band, so registering to receive does not bring them forward. Until then they can be [registered for receiving only](/guides/fr-pa-registration#registering-without-e-reporting).
  </Accordion>

  <Accordion title="What's the difference between e-invoicing and e-reporting?">
    **E-invoicing** transmits the invoice itself between trading parties via Peppol, with the PPF receiving the regulated dataset as a fifth corner. **E-reporting** is a periodic submission to the PPF covering transactions out of scope for e-invoicing — B2C, cross-border B2B, and any flow where the counterparty is not in the Annuaire.
  </Accordion>

  <Accordion title="Do I need to act if I'm B2C-only?">
    Yes — B2C is exempt from e-invoicing but is subject to e-reporting. From 1 September 2026 (large and medium-sized companies) or 1 September 2027 (all businesses), B2C transactions must be reported periodically to the PPF.
  </Accordion>

  <Accordion title="Do I have to e-report imports?">
    If the supply is taxable under French reverse charge (i.e. VAT is paid on import), the transaction must be e-reported.
  </Accordion>

  <Accordion title="When should I e-report payment data?">
    Report payment data only when VAT is due on receipt of payment, such as for services under "cash VAT" (TVA sur les encaissements).
  </Accordion>

  <Accordion title="Does this apply to foreign businesses without a Fixed Establishment (FE) in France?">
    E-invoicing does not apply. If the business is liable to French VAT, e-reporting applies to the relevant flows. E-reporting for reverse-charge VAT and intra-EU acquisitions is deferred until 1 September 2027.
  </Accordion>
</AccordionGroup>

**Peppol**

<AccordionGroup>
  <Accordion title="Is sending invoices via Peppol mandatory?">
    Mandatory dates vary by country. Belgium requires structured B2B e-invoicing — Peppol BIS by default — from January 2026. Germany is phasing in B2B e-invoicing between 2025 and 2028. France's Factur-X via Peppol applies once the PA reform takes effect. Outside mandates, Peppol delivery is voluntary but increasingly expected for B2G and cross-border trade.
  </Accordion>

  <Accordion title="Does a Peppol invoice need to be EN16931 compliant?">
    Yes. Every document exchanged on Peppol BIS uses a UBL or CII syntax that conforms to the EN16931 European e-invoicing standard, plus the relevant Peppol BIS specification. Invopop generates compliant XML automatically when you use the Peppol app.
  </Accordion>

  <Accordion title="Why does Peppol require proof of ownership?">
    Peppol is a federated network — anyone could otherwise register a Participant ID for a company they don't represent. Proof of ownership ties the Participant ID to a verifiable contact at the company, which is what allows the registration to be published on the SML.
  </Accordion>

  <Accordion title="What documents count as proof of ownership?">
    Requirements vary by Authority. In Belgium, for example, the supplier must provide a recent extract from the Banque-Carrefour des Entreprises (KBO/BCE) plus a signed mandate. Invopop walks the registering party through the local requirements during the registration wizard.
  </Accordion>

  <Accordion title="Are received Peppol invoices considered legally valid?">
    Yes — a Peppol BIS document delivered through a certified Access Point is treated as the legal e-invoice in any country that recognises Peppol. The signed UBL or CII XML is the authoritative record; archive it alongside any human-readable rendering you generate.
  </Accordion>

  <Accordion title="How long must I retain received Peppol invoices?">
    Retention is set by each country's tax authority — typically 7 to 10 years in the EU. Invopop preserves the original XML and any generated PDF in the silo entry so you can satisfy local archival requirements wherever you operate.
  </Accordion>
</AccordionGroup>

### Invoicing questions

**France**

<AccordionGroup>
  <Accordion title="How do I configure my workspace for French invoicing?">
    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.
  </Accordion>

  <Accordion title="How can I view an XML attached to a PDF?">
    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](https://www.systoolsgroup.com/pdf/extractor/).
  </Accordion>
</AccordionGroup>

**Chorus Pro**

<AccordionGroup>
  <Accordion title="What invoice formats does Chorus Pro support?">
    Chorus Pro primarily supports CII format based on EN16931. Invopop currently focuses on CII with plans to add additional formats in the future.
  </Accordion>

  <Accordion title="Do I need a SIRET number to use Chorus Pro?">
    French businesses need a SIRET number. Foreign businesses can use their local tax identifier, but should verify acceptance with the receiving French institution.
  </Accordion>

  <Accordion title="Can I modify invoices after sending to Chorus Pro?">
    Yes, you can modify and resubmit invoices until the receiving institution accepts them. Once accepted, invoices become locked and cannot be modified.
  </Accordion>

  <Accordion title="How do I find my invoice in Chorus Pro?">
    Use your GOBL invoice series and code combined as the invoice identifier in the Chorus Pro portal to locate your submitted invoices.
  </Accordion>

  <Accordion title="Are there file size limits for Chorus Pro invoices?">
    Chorus Pro has specific file size and format requirements. Invopop handles these automatically when generating CII XML files from your GOBL invoices.
  </Accordion>

  <Accordion title="What GOBL fields are required for Chorus Pro?">
    The recipient's SIRET (or equivalent identifier) plus a Chorus Pro service code where applicable. Invopop generates EN 16931 CII XML by default — UBL is also accepted by Chorus Pro.
  </Accordion>
</AccordionGroup>

**PA (Plateforme Agréée)**

<AccordionGroup>
  <Accordion title="Is Invopop ready for the September 2026 mandate?">
    Invopop is an [officially approved Plateforme Agréée](https://www.impots.gouv.fr/je-consulte-la-liste-des-plateformes-agreees) 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](/guides/fr-pa) for the current state.
  </Accordion>

  <Accordion title="What GOBL addons are required for France PA?">
    The base [FR tax regime](https://docs.gobl.org/regimes/fr) 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.
  </Accordion>

  <Accordion title="Is a self-billed invoice a different document type in France?">
    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`](https://docs.gobl.org/addons/fr-ctc-flow2-v1#standard-self-billed) add-on applies it automatically. See [Self-billing](/guides/fr-pa-invoicing#self-billing) for the full flow.
  </Accordion>

  <Accordion title="How many pops does a B2B e-invoice through France PA cost?">
    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](/get-started/pricing) for how pops work.
  </Accordion>

  <Accordion title="What does the record document step check against the Annuaire?">
    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:

    | Role | Annuaire state | Outcome |
    | - | - | - |
    | Both | The SIREN has no effective entry | **Rejected** |
    | Receiving | The SIREN has at least one effective entry | **Accepted** |
    | Sending | The SIREN's only entry is the PPF's default line (matricule `9998`) | **Accepted** |
    | Sending | The party's `0225` peppol endpoint matches one of the SIREN's entries | **Accepted** |
    | Sending | The party's `0225` peppol endpoint matches none of the SIREN's entries | **Rejected** |

    Sandbox invoices skip the Annuaire check entirely.
  </Accordion>

  <Accordion title="What should I do if the customer isn't registered in the Annuaire?">
    Don't block the sale. An exchange where only one party has an
    effective Annuaire entry is a
    [non-regulated flow](/guides/fr-pa#key-concepts): it leaves
    e-invoicing (flux 2) and is covered by
    [e-reporting](/guides/fr-pa-reporting) (flux 10) instead.

    In practice:

    * Run a [Directory lookup](/guides/fr-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](https://annuaire-entreprises.data.gouv.fr)
    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.
  </Accordion>

  <Accordion title="Should I check the Annuaire at order time or at invoice time?">
    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](/guides/fr-lookup).
  </Accordion>
</AccordionGroup>

**Peppol**

<AccordionGroup>
  <Accordion title="What should we do if the customer doesn't belong to the Peppol network?">
    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
  </Accordion>

  <Accordion title="How do I handle B2C invoices in Peppol?">
    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.
  </Accordion>

  <Accordion title="How do I handle 'Receiver Not Found' errors?">
    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.
  </Accordion>

  <Accordion title="Should I set the `$regime` field when using Peppol?">
    No. The regime is automatically derived from the supplier's settings, which is the recommended approach for Peppol — leave it unset on the document.
  </Accordion>

  <Accordion title="Where do I find Peppol GOBL documentation?">
    See the [`eu-en16931-v2017`](https://docs.gobl.org/addons/eu-en16931-v2017) addon for the field and validation rules Peppol BIS Billing 3.0 builds on, and the [Peppol app reference](/apps/peppol) for supported document types and Participant ID schemes.
  </Accordion>
</AccordionGroup>

### Registering supplier questions

**France**

<AccordionGroup>
  <Accordion title="How do I onboard a new supplier in France?">
    For B2B PA flows: register the supplier via the France PA Register Party workflow (publishes the SIREN to the Annuaire and Peppol). For Chorus Pro: register the supplier with their SIRET on Chorus Pro's portal and link credentials in the Chorus Pro app.
  </Accordion>

  <Accordion title="How are supplier credentials stored in Invopop for France?">
    France PA does not require supplier-side certificates — Peppol uses Invopop's AP cert. Chorus Pro uses an OAuth token bound to the supplier's account; the token is encrypted at rest in Invopop.
  </Accordion>
</AccordionGroup>

**Chorus Pro**

<AccordionGroup>
  <Accordion title="What happens if my supplier registration fails?">
    Ensure the supplier has a valid Chorus Pro account and provided correct credentials. Contact support if registration workflow issues persist.
  </Accordion>

  <Accordion title="What credentials does Chorus Pro require to authenticate a supplier?">
    OAuth 2.0 client credentials issued by Chorus Pro after registration. Invopop stores the token encrypted; suppliers can revoke access at any time through Chorus Pro's portal.
  </Accordion>
</AccordionGroup>

**PA (Plateforme Agréée)**

<AccordionGroup>
  <Accordion title="How do I register a supplier with France PA?">
    Run the France PA Register Party workflow with the supplier's SIREN. Invopop publishes them to the Annuaire and the Peppol SMP — they are then routable for both invoicing and e-reporting through Invopop.
  </Accordion>

  <Accordion title="My company already uses another Plateforme Agréée for one flow. Can I register with Invopop for another?">
    Yes. This is a common setup, for example a company handling AR with one PA and AP with another. Run the [registration workflow](/guides/fr-pa-registration) with a SIREN and suffix of your choice for the flow you want Invopop to handle, such as `434061839_AR`. Invoices and statuses addressed to an entry are delivered to the platform that registered it, so the two flows never conflict and act fully independently.
  </Accordion>

  <Accordion title="Can a supplier keep sending invoices through Invopop but receive them through another PA?">
    Yes. Keep the existing Invopop registration for sending, and have the other PA register a new `SIREN_suffix` electronic address in the Annuaire and Peppol for receiving, such as `434061839_AP`. The supplier then gives that address to their own suppliers.

    Electronic addresses work like email addresses:

    * Invoices arrive at whichever address the sender uses, and are delivered to the PA that registered it.
    * Invoices you send from an address get their lifecycle status updates back at that same address.

    Invoices sent to the Invopop-registered address still reach Invopop, so make sure suppliers switch to the new one.
  </Accordion>

  <Accordion title="Can I register a supplier to receive invoices without enabling e-reporting?">
    Yes. Copy the PPF register supplier template and remove the **Register party for reporting** step. The party gets its Annuaire line and Peppol inbox and can receive invoices, but no reporting cadence starts. When its obligations begin, run the removed step against the party to complete the registration. See [Registering without e-reporting](/guides/fr-pa-registration#registering-without-e-reporting).
  </Accordion>

  <Accordion title="What certificates does France PA require to authenticate a supplier?">
    None at the supplier level. The Plateforme Agréée holds an OpenPeppol-issued mTLS certificate (Invopop's), and the PA-to-PPF channel uses additional DGFiP credentials managed by Invopop.
  </Accordion>

  <Accordion title="Registration fails with 'Le SIREN en entrée n'existe pas...'. What does that mean?">
    This error means the PPF has not yet referenced the SIREN in the annuaire de la facturation électronique. Before an accredited platform like Invopop can register a directory entry, the PPF has to list the SIREN first — even if the company is correctly registered and active with the tax administration, there may still be no directory entry for a PA to take over.

    The fix has to come from the tax administration, not from Invopop:

    1. Confirm the business is in scope for the reform using the [PPF's questionnaire](https://www.impots.gouv.fr/facturation-electronique-qu-est-ce-que-ca-change-pour-moi).
    2. If it's in scope but still missing from the directory, have the business or its accountant contact the Service des Impôts des Entreprises (SIE) that handles it and ask for the SIREN to be referenced in the annuaire.
    3. For general questions about the reform, the DGFiP runs a free national helpline: 0 806 807 807.

    Invopop has no way to create the directory entry directly — only the SIE can. Once the supplier confirms the SIREN is referenced, re-run the [registration workflow](/guides/fr-pa-registration).
  </Accordion>

  <Accordion title="How many pops does registering a merchant (seat) for France cost?">
    It depends on the flows the merchant uses:

    * **E-invoicing (B2B)** — **150 pops** per merchant: 50 pops for the French directory (Annuaire) registration plus 100 pops for Peppol.
    * **E-reporting only (B2C or international B2B)** — **50 pops** per merchant to register the party for reporting.

    Each registered merchant counts as a seat: the same seat pops are deducted on registration and again every 30 days for as long as the merchant stays registered — see [Pops & pricing](/get-started/pricing) for how seats are billed.
  </Accordion>
</AccordionGroup>

**Peppol**

<AccordionGroup>
  <Accordion title="How do I register for a Peppol inbox in Invopop?">
    Upload the company as a party (Console → Parties → Suppliers → + New Supplier, or via the Create an Entry API) with name, tax\_id, address, and email. Then run it through the party registration workflow — the contact will receive a registration wizard link to provide proof of ownership.

    Once approved, the party is registered on the Peppol network (SMP+SML+Peppol visibility by default with the `ubl-invoice` doc group) and ready to receive invoices.
  </Accordion>

  <Accordion title="I get 'XXXX:XXXXXXXXX is already registered' when registering a supplier — what now?">
    A supplier with that Participant ID already exists in your workspace. Either reuse the existing party or, if it really is a new entity, check whether it should be registered under an alternative scheme (for example Belgium's `9925` VAT scheme rather than the default `0208`).
  </Accordion>

  <Accordion title="How do I assign multiple inboxes to a single supplier?">
    Register them through different silo entries, even though they represent the same legal party. The supplier must upload proof of ownership for each inbox.
  </Accordion>

  <Accordion title="What are Participant IDs?">
    Unique identifiers for entities on the Peppol network, made up of two parts:

    * **Scheme** — identifies the type of identifier (e.g. `9920` for Spanish VAT, `0208` for Belgian KBO/BCE)
    * **Code** — the actual identification number

    Participant IDs are usually based on VAT numbers or local business identifiers, and Invopop can derive them automatically from a Tax ID. Some countries support multiple schemes — Belgium, for example, defaults to `0208` but some entities are only registered under `9925` (VAT). If you hit a "receiver not found" error, the recipient may be registered under an alternative scheme.
  </Accordion>

  <Accordion title="What visibility level should I set on my Peppol Party?">
    Peppol Party visibility determines what you can send and receive:

    * `smp` — SMP only, for testing
    * `smp+sml` — SMP and SML, useful when you only want to send
    * `smp+sml+peppol` — SMP, SML, and the Peppol Directory, recommended for both sending and receiving (and for being discoverable in the Directory)

    In general, use the highest visibility available.
  </Accordion>
</AccordionGroup>

### Receiving questions

**France**

<AccordionGroup>
  <Accordion title="How do I import received invoices in France?">
    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.
  </Accordion>

  <Accordion title="How does Invopop convert received French invoices into GOBL?">
    UBL via [`gobl.peppol`](https://github.com/invopop/gobl.peppol); CII and Factur-X via [`gobl.cii`](https://github.com/invopop/gobl.cii). The original structured XML (or PDF/A-3 with embedded XML) is preserved as a silo entry attachment.
  </Accordion>
</AccordionGroup>

**PA (Plateforme Agréée)**

<AccordionGroup>
  <Accordion title="How do I import received invoices via France PA?">
    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.
  </Accordion>

  <Accordion title="What format do received France PA invoices arrive in?">
    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.
  </Accordion>

  <Accordion title="Can I receive invoices at more than one platform (PDP) for the same company?">
    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](/guides/fr-lookup) in the Annuaire to confirm where it currently routes.
  </Accordion>
</AccordionGroup>

**Peppol**

<AccordionGroup>
  <Accordion title="How do I import received invoices via Peppol?">
    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.
  </Accordion>

  <Accordion title="Can I remove UBL or CII from the 'Peppol receive invoice' workflow if I only use one format?">
    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.
  </Accordion>

  <Accordion title="How are incoming Peppol documents converted into GOBL?">
    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.
  </Accordion>
</AccordionGroup>

### Reporting questions

**France**

<AccordionGroup>
  <Accordion title="How do I schedule periodic reports for France?">
    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.
  </Accordion>

  <Accordion title="What format does France expect for periodic reports?">
    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.
  </Accordion>
</AccordionGroup>

**PA (Plateforme Agréée)**

<AccordionGroup>
  <Accordion title="How often must I submit France PA reports?">
    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).
  </Accordion>

  <Accordion title="What format does France PA expect for periodic reports?">
    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.
  </Accordion>

  <Accordion title="How many pops does e-reporting in France cost?">
    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](/get-started/pricing) for how pops work.
  </Accordion>

  <Accordion title="A buyer has refused an invoice (210 Refusée). What happens next?">
    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.

    | Who | What they do |
    | - | - |
    | **Buyer** | Refuses with a reason code, and does not book the invoice (or reverses the entry if already booked). Their input VAT for the period drops accordingly. |
    | **Supplier** | Reverses the invoice in their own accounts with an internal credit note (*avoir interne*), which stays internal and is never sent. Adjusts output VAT for the period. |
    | **Supplier** | Fixes the underlying problem, then issues a replacement as a new invoice with a new number. The refused number is never reused. |
    | **Invopop** | Records the refusal against the original invoice, passes the reason code back to you, and forwards the mandatory copy to the PPF. |

    **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.
  </Accordion>
</AccordionGroup>

<Card title="Participate in our community" icon="forumbee" href="https://community.invopop.com" arrow="true" horizontal>
  Ask and answer questions about France's regulation →
</Card>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.