From September 2026, all French companies must route their invoices and VAT data through a certified platform. B2Brouter simplifies this: you send your invoice data via a REST API call, and B2Brouter handles PPF registration, document generation (UBL/CII/Factur-X), routing to your clients, and tax reporting to the DGFiP — all through a single integration.
B2Brouter is a certified Plateforme Agréée (PA) for the French DGFiP e-invoicing reform. Connect via REST API and B2Brouter handles the entire compliance stack on your behalf:
What B2Brouter does for you
Details
PPF registration
Publishes your SIREN/SIRET to the Annuaire automatically on activation
Flux 1 — B2B e-invoicing
Generates UBL/CII/Factur-X, transmits to PPF, routes to buyer’s platform
Flux 6 — Invoice lifecycle
Manages CDAR status messages (Déposée, Reçue, Approuvée, Refusée, Encaissée)
Flux 10 — e-Reporting
Aggregates B2C and cross-border B2B transactions (intra-EU and extra-EU) into daily Ledgers sent to PPF
Peppol 0225 reception
Receives invoices from any French or Peppol-connected platform
Document generation
You send invoice data as JSON — B2Brouter generates the compliant UBL/CII/Factur-X document and transmits it to the PPF. No XML generation required on your side
All transmitted documents (invoices, tax reports, CDAR messages) are stored by B2Brouter for the legally required 10-year retention period. No additional storage setup required on your side
Regulatory context: The French e-invoicing reform mandates that all French companies use a certified Plateforme Agréée (PA) or the government’s PPF (Portail Public de Facturation) to transmit invoices and report VAT data to the DGFiP, starting September 2026. As a certified PA, B2Brouter handles the PPF connection entirely on your behalf — no SFTP, no electronic certificates, no direct PPF integration required.
There are two main use cases for integrating with B2Brouter for France e-invoicing:
eDocExchange — For companies or groups of companies that integrate their management software (ERP, accounting platform) directly with B2Brouter. The onboarding process (account creation, Tax Report Settings configuration) is typically performed once per company through the web UI. Day-to-day operations (issuing invoices, tracking their lifecycle) happen through the API. To add further company accounts to your integration group, follow the same onboarding wizard from the same B2Brouter user account — no separate API call required.
eDocSync — For software vendors and ERP providers who want to offer DGFiP compliance to their own customers from within their product. This is B2Brouter’s white-label / embedded / marque blanche model: B2Brouter operates entirely in the background, end customers interact exclusively with the vendor’s interface and are unaware of B2Brouter. The software vendor is responsible for account provisioning, invoice submission, and lifecycle tracking via the B2Brouter API. End customers do not need a B2Brouter login or subscription.
For eDocSync, account provisioning volume determines the right plan:
Few companies (reseller model): Add each client company as an account in your B2Brouter integration group via the web UI, following the standard onboarding wizard. This works well for tens of companies and shares a single API key.
100+ companies: Contact our Sales team or open a Support Ticket to discuss a dedicated eDocSync plan with bulk provisioning (volume-based pricing for editors).
In both cases, all France-specific compliance features (Annuaire registration, Flux 1/6/10 transmission, CDAR lifecycle) work identically.
B2Brouter is itself a Plateforme Agréée: you integrate with B2Brouter — it is not a relay or connector to another PA. If your SIREN/SIRET is currently registered with a different PA, activating B2Brouter (Step 2) transfers the Annuaire entry automatically. You cannot use B2Brouter as a pass-through to submit invoices under a different PA’s certification.
Routing to recipients on other PAs: When your buyer is registered with a different PA, B2Brouter routes the invoice via the standard Peppol four-corner model (C2 → C3): B2Brouter’s Peppol access point (C2) looks up the recipient’s Peppol address in the Annuaire and delivers the document to the buyer’s access point (C3) — regardless of which PA they use. No additional configuration is required on your side.
Testing environments: Use sandbox for initial API testing and payload validation — DGFiP submissions are simulated in sandbox, no fictitious SIRET required. For full end-to-end testing with the DGFiP QAS (qualification) environment, use B2Brouter’s staging environment as described below.
Do not mix environments. Production uses real SIREN/SIRET numbers and connects to the DGFiP production Annuaire. Staging uses fictitious test identifiers and connects to the DGFiP QAS (qualification) environment. API keys, accounts, and contacts are not shared between environments.
Register at app.b2brouter.net to start a production integration. When you activate the DGFiP Tax Report Setting, your company’s SIREN/SIRET is published to the real PPF Annuaire, making it discoverable by any platform in the French e-invoicing ecosystem.
This option is designed for real B2B invoices starting September 2026. In the meantime, the DGFiP will clear QAS-period records before the reform goes live — so any invoices you send during your pilot will not create compliance obligations. This is the right starting point if you have already chosen B2Brouter and want to test the full integration with your actual company data.
Register at app-staging.b2brouter.net to use B2Brouter’s test environment, which is connected to the DGFiP’s QAS (qualification) environment.
This is the best option if:
You are evaluating multiple platforms before committing
Your SIREN/SIRET is already published in the Annuaire with another PA (activating B2Brouter in production would transfer the entry)
You prefer not to associate your company identifier with test activity
The staging environment is self-provisioned: once you have test identifiers (see below), you can start end-to-end testing in under 24 hours.
Staging SIRET validation: In the staging environment, any valid 14-digit number is accepted as a SIRET without checksum validation. The fictitious identifiers from the Chorus Pro QAS CSV are pre-registered in the DGFiP QAS annuaire and work end-to-end. In production, SIRET format and checksum are validated.
Important: The DGFiP does not allow real SIREN or SIRET numbers in their QAS environment. You must use fictitious test identifiers. You can obtain these yourself via the Chorus Pro QAS portal (free, 5-minute process) or request a pre-assigned set by opening a Support Ticket in the staging app.
One account per SIREN: B2Brouter creates one account per SIREN (the VAT number key is derived from the SIREN). If you provide a SIRET, the SIREN is extracted from it. Two different SIRETs from the same company (same SIREN) will resolve to the same account. If your company operates from multiple establishments (different SIRETs), these are modelled as organisational units within the same B2Brouter account — not as separate accounts. Contact Support if you need to configure multi-establishment invoicing. Keep this in mind when selecting rows from the CSV: pick SIRETs with distinct SIRENs (first 9 digits) for each independent company you need to test.
The Chorus Pro QAS portal lets you generate a “Matelas de données” (data set) — a CSV file containing fictitious SIREN/SIRET identifiers pre-registered in the DGFiP test environment. Follow these steps:
You can use a temporary email address (e.g. temp-mail.io).
Use any name; this account is purely for obtaining test identifiers.
Check your inbox for the “Initialisation de mot de passe Chorus Pro” email and set your password (link valid 60 minutes).
Log in → go to Domaines → Matelas de données → click Générer un matelas de données and confirm.
Go to Consultation du matelas de données. Wait until both statuses show “Disponible”:
Statut pour Chorus Pro: Disponible
Statut pour l’annuaire de facturation PPF: Disponible
Generation typically takes a few minutes. Refresh the page to check.
Click “Générer et télécharger le fichier CSV du matelas structures et utilisateurs” to download your test identifiers.
The CSV contains multiple fictitious SIREN/SIRET numbers in rows labelled “Privé” and “Public”. Use only rows from the “Privé” (private sector) section for your test accounts. Public sector entities (SIREN 'Public') are rejected by the DGFiP QAS annuaire — attempting to activate e-Reporting on a public-sector account returns HTTP 422 (“La création d’une ligne annuaire n’est pas possible pour une entité associée à un SIREN ‘Public’”). This is correct behaviour: public entities use Chorus Pro directly, not a PA.
Use one private-sector SIREN for your emitter account and another for your test contact.
⚠️ After activating the DGFiP Tax Report Setting, your company’s Annuaire registration takes up to 24 hours to propagate — both in staging and in production. This is a DGFiP infrastructure constraint, not a B2Brouter delay. You will not be able to send invoices until the following day.
The following day: create a test contact using a second SIREN from the CSV (see Step 3).
Authentication uses a static API key passed in the X-B2B-API-Key HTTP header. There is no OAuth2 flow — generate your API key in the B2Brouter UI under Settings → API Keys. Keep it confidential and never include it in client-side code. Also set X-B2B-API-Version in every request.
Base URL: All examples below use https://api-staging.b2brouter.net. For production, replace with https://api.b2brouter.net.
Account structure: Parent and organisational units
A French company with several establishments or services is modelled in B2Brouter as a parent account (the main entity) and, optionally, one or more organisational units (UOs) hanging from the parent. Invoices are always issued from a parent account or from a specific UO, but the integration group is shared.
The concrete structure depends on one key decision: whether your SIREN is free of other PAs or already registered with one.
If your SIREN is not yet registered with any other Plateforme Agréée (PA), the parent account is always at SIREN level (legal entity). The rest of establishments and services are modelled as UOs under that parent.
If your SIREN is already registered with another PA and you only want to bring one specific establishment into B2Brouter, the parent account will be at SIRET level (the establishment), not at SIREN. The UOs under that SIRET are services or suffixes.
This decision drives which identifier pattern applies (see table below). If unsure, check the Annuaire first with the Directory lookup.
In B2Brouter a French account or contact is defined by a principal identifier (cin_scheme + cin_value) and, optionally, a sub-identifier (routing_codes.cin1_scheme + routing_codes.cin1_value) when you need to address a specific service inside an establishment.
Account / UO principal identifier (cin_scheme + cin_value):
cin_scheme
Identifier
Format
Example
0002 (2)
SIREN — legal entity
9 digits + Luhn
123456789
0009 (9)
SIRET — establishment
14 digits (SIREN + 5 digits) + Luhn
12345678900012
8040
Suffix — UO without its own SIRET
Alphanumeric [A-Za-z0-9_\-\/]+
SUF01, ADMIN
Sub-identifier (routing code) — only for SIRET UOs with several internal services:
EAS Peppol of the FR participant: the electronic identifier on the Peppol network is always 0225 (FRCTC Electronic Address). Schemes 224 (Code Routage) and 8040 (Suffix) are internal directory sub-identifiers and are not published as standalone Peppol EAS.
Suffix vs Code Routage — The Suffix (8040) is the principal cin_scheme of a UO without its own SIRET. The Code Routage (224), in contrast, always goes in routing_codes.cin1_scheme="224" on a UO with SIRET — never as a principal cin_scheme.
Important: a SIRET on its own (without a SIREN in front) is not a valid published identifier. Even when Case C uses a SIRET as the cin_value of the parent, the SIREN is derived internally from the first 9 digits of the SIRET, and the published composition is always SIREN_SIRET.
See the 4 final identifier formats at the Annuaire
Annuaire composition
Meaning
SIREN
Whole entity (Parent)
SIREN_SIRET
Establishment (Case 1 / Case 4)
SIREN_SIRET_<CR>
Service inside an establishment (Case 2 / Case 5)
SIREN_<SUFFIX>
UO without its own SIRET (Case 3 / Case 6)
None of these compositions are issue-only by themselves — including the bare SIREN row. Whether an address also receives invoices (a 0225 transport is published for it) depends solely on the issue_only flag on that Tax Report Setting, not on which composition it uses. See the note on issue_only under Scenario 3 below.
To see the exact API fields that produce each format, see the Cases and topologies table below.
Your structure depends on two factors: whether your SIREN is free of other PAs, and whether you want to issue or also receive. Three scenarios cover all standard configurations.
If your SIREN is already registered with another PA and you want to bring one specific establishment into B2Brouter with capacity to issue and receive, the parent will be at SIRET level. The UOs under that SIRET are services identified by Code Routage.
Case 4 (C Établissement-only) — Only one SIRET establishment, no internal subdivisions.
Case 5 (C + Service) — The SIRET establishment has several internal services. The service UO repeats the parent’s SIRET as principal cin_scheme="0009" and carries the Code Routage at routing_codes.cin1_scheme="224".
Why the Case 5 UO repeats the SIRET: validation requires cin_scheme="0009" (SIRET) as principal on every office with a Code Routage. The Code Routage always goes in routing_codes.cin1_scheme="224", never as a principal cin_scheme.
Scenario 3 — Issue-only (issue only, without publishing transport 0225)
If your SIREN is already with another PA and you only want to issue from B2Brouter (without publishing a 0225 transport that would conflict with the other PA’s), use the issue_only=true flag on the parent account. B2Brouter will not register any 0225 transport with the PPF.
Pure case — only issue_only=true (no suffix):
cin_scheme="0002" (SIREN) + issue_only=true
No UOs, no suffix
Annuaire address: SIREN (the rest handled by the other PA)
Sub-case with suffix — when you also need internal addressing SIREN_<SUFFIX>:
issue_only is independent of the suffix: you can have issue_only=true without any suffix (pure SIREN parent, issue only). The secondary-slot suffix is just an optional sub-case for internal addressing.
A suffix does not mean issue-only. The suffix (SIREN_<SUFFIX>) is only an addressing detail — whether it also receives invoices depends exclusively on issue_only, not on the presence of the suffix itself:
issue_only=true + suffix → the SIREN_<SUFFIX> Ligne is created in the Annuaire, but no 0225 transport is published for it → issue-only, no reception. Use this when reception for that address is already handled by another PA.
No issue_only (default) + suffix → the 0225 transport is published for SIREN_<SUFFIX> → issue and receive at that same suffixed address, exactly like any other address.
If you want to both issue and receive at a suffixed address, do not set issue_only on that Tax Report Setting.
Contacts in B2Brouter (French clients and suppliers) follow exactly the same hierarchy (parent + UOs) and the same cin_scheme values (SIREN / SIRET / Code Routage / Suffix). The system technically allows the contact parent to be at any level.
Golden rule for contacts: keep the parent always at SIREN level. Even though the system accepts other levels as the parent (SIRET, Code Routage or Suffix), keeping SIREN as the root guarantees consistency if you later need to add UOs of the same client.
With the parent at SIREN, the cases from the 3 scenarios apply to contacts (UOs can be SIRET, Code Routage or Suffix depending on the client’s structure).
To create a contact UO, use the same endpoint as for a regular contact — POST /accounts/{ACCOUNT_ID}/contacts — adding parent_id pointing to the parent contact. tin_value and tin_scheme are inherited from the parent and cannot diverge.
Structure reminder: the cin_scheme you use on the parent account depends on which case you’ve chosen in Account structure. If your SIREN is free, use 0002 (SIREN); if your SIREN is already registered with another PA, use 0009 (SIRET) as the parent — Scenario 2.
If you already have a B2Brouter account for your company, retrieve its id with the List Accounts endpoint and skip the creation step.
If you haven’t yet created one, use the Create Account endpoint (eDocSync/API path) or the web UI onboarding wizard (eDocExchange path). Both produce the same result.
When creating a French company account:
cin_scheme: "0002" for SIREN (9 digits) or "0009" for SIRET (14 digits). Use SIRET when available — it identifies a specific establishment and is preferred by the PPF.
cin_value: The SIREN or SIRET of your company.
tin_value: French VAT number in the format FR{kk}{siren}, where kk is the two-digit checksum (e.g. FR32123456789). This field is optional at account creation: if omitted, B2Brouter automatically derives and sets it from the SIREN when you activate the DGFiP Tax Report Setting. It is mandatory for DGFiP invoicing but you do not need to calculate it yourself.
If your company structure requires UOs (see Cases 1, 2, 5 and 6 in Topologies), create each UO with POST /accounts adding parent_id (the parent account id created in Step 1a).
This feature requires an API version that supports UOs with parent_id. Check the API changelog for the minimum version.
Restrictions:
parent_id is mandatory to create a UO.
A UO cannot include tin_value or tin_scheme (they are inherited from the parent).
A UO cannot be parent of another UO (only one level of nesting).
Mandatory fields on every UO payload: besides parent_id and cin_*, you must include country, email, address, city, postalcode and province. Without these, the creation returns HTTP 422 (“Region/Province/Country can’t be blank”). tin_value and tin_scheme are inherited from the parent and must not be repeated.
Example — Établissement UO with optional Service (Cases 1 and 2):
The UO repeats the parent’s SIRET (cin_value) and identifies the service via routing_codes.cin1_value. The Code Routage never goes as principal cin_scheme.
Example — Suffix UO (Case 6):
Terminal window
curl--requestPOST \
--urlhttps://api-staging.b2brouter.net/accounts \
--header'X-B2B-API-Key: {YOUR_API_KEY}' \
--header'X-B2B-API-Version: {YOUR_API_VERSION}' \
--header'Content-Type: application/json' \
--data'{
"account": {
"name": "Exemplar SAS — Administrative Unit",
"parent_id": {PARENT_ACCOUNT_ID},
"cin_scheme": "8040",
"cin_value": "SUF01",
"country": "fr",
"email": "admin-unit@example.com",
"address": "1 Rue de la Paix",
"city": "Paris",
"postalcode": "75001",
"province": "Île-de-France"
}
}'
Case 4 (C — Établissement-only) and all Issue-only cases (Scenario 3) are not created as UOs — they are parents defined in Step 1a with their own cin_scheme (and issue_only=true where appropriate).
This is the key onboarding step. When you create a Tax Report Setting with code: "dgfip", B2Brouter automatically:
Registers your company in the PPF’s Annuaire — your SIREN/SIRET becomes discoverable by any platform in the French e-invoicing ecosystem.
Creates a Peppol 0225 transport — enabling your company to receive electronic invoices from any Peppol-connected platform in France.
⚠️ Transport replacement:
If your account already has a Peppol transport, it will be replaced by the new 0225 (FRCTC Electronic Address) transport during activation. If your SIREN/SIRET was previously registered with another PA, B2Brouter will close the existing Annuaire entry and open a new one. Update any existing integration that references the old transport identifier.
The start_date determines when tax reporting begins. From that date, invoices you issue will generate tax reports and be transmitted to the PPF.
When tax reporting begins. Must be today or a future date. Defaults to tomorrow if omitted.
type_operation
string
Yes
Default operation type for this company: "services", "goods", or "mixed". Determines the DGFiP process code (S1/B1/M1 etc.) used in tax reports. Choose "mixed" if your company sells both goods and services. This setting can be updated after activation.
naf_code
string
Yes
The company’s NAF/APE code (Nomenclature d’Activités Française). This is the 2-digit section code assigned by INSEE that identifies the company’s main economic activity (e.g. "62" for IT and software services, "47" for retail, "86" for health). The DGFiP uses this code for tax reporting classification. You can find your NAF code on your company’s Kbis extract or on sirene.fr.
enterprise_size
string
Yes
The company’s size category as defined by INSEE. Allowed values: "micro" (Microentreprise — < 10 employees, CA ≤ 2 M€), "pme" (PME — 10 to 249 employees, CA ≤ 50 M€), "eti" (ETI — 250 to 4 999 employees, CA ≤ 1.5 Md€), or "ge" (Grande Entreprise — 5 000+ employees or CA > 1.5 Md€).
reason_vat_exempt
string
No
Default VAT exemption reason code for this company. Defaults to "VATEX-FR-FRANCHISE" (franchise en base de TVA). Set this if your company operates under a specific VAT exemption regime. See VAT-exempt lines and Franchise en base de TVA for the full list of accepted codes.
email
string
No
Contact email for tax-related notifications.
auto_generate
boolean
No
Always true for DGFiP (legal obligation). Cannot be changed.
auto_send
boolean
No
Automatically transmit tax reports to the PPF. Defaults to true.
enabled
boolean
No
Whether the setting is active. Defaults to true. Annuaire registration only occurs when true.
annuaire_only
boolean
No
When true, the account is only registered with the Annuaire of the PPF for reception. No Flux 1 tax reports are generated and no CDAR messages are sent; enterprise_size and naf_code become optional. Defaults to false. See Reception-only mode.
If the Annuaire registration fails (invalid SIREN/SIRET, or a temporary DGFiP service outage), the Tax Report Setting creation is rolled back and an error is returned. Correct the issue and retry.
If your account only needs to receive electronic invoices (not issue them) — for example, a company not yet required to issue but that wants to be registered with the Annuaire so its suppliers can send invoices via Peppol — you can activate the DGFiP Tax Report Setting with annuaire_only: true.
What it activates:
Registers your company with the PPF Annuaire (visible to issuers).
Creates the Peppol 0225 transport for reception.
What it skips compared to a full activation:
No Flux 1 tax reports are generated when issuing invoices.
No CDAR messages (Déposée → Reçue → Approuvée… cycle) are sent.
enterprise_size and naf_code are not required.
This mode is useful for receiving companies in evaluation, or for entities that have a different invoicing provider but want to receive via B2Brouter. When you want to start issuing, update the Tax Report Setting to full mode with a PATCH (see Tax Report Settings Guide).
A French B2B contact needs routing identifiers (how the invoice reaches the recipient) and tax identification (how the recipient appears in the UBL XML).
Field
Value
Purpose
cin_scheme
"0009" (SIRET) or "0002" (SIREN)
Organisation ID — used to look up the recipient in the Annuaire
cin_value
SIRET or SIREN
Organisation ID — the identifier registered in the Annuaire
tin_scheme
9957
Tax ID — ISO 6523 code for French fiscal identifier
tin_value
FR{kk}{siren} (e.g. "FR78225214234")
Tax ID — French VAT number in the UBL XML
pin_scheme
"0225"
EAS Peppol of the FR participant (FRCTC Electronic Address) — required for French contacts
pin_value
Recipient’s Annuaire composition
Contact’s Peppol identifier; follows the same composition as the parent at the Annuaire (SIREN, SIREN_SIRET, SIREN_SIRET_<CR> or SIREN_<SUFFIX> — see Identifier levels)
country
"fr"
Required for DGFiP routing logic
currency
"EUR"
Default currency for this contact’s invoices
transport_type_code
"peppol"
Recommended — ensures delivery via the Peppol network
document_type_code
"xml.ubl.invoice.frcius.v1"
Recommended — France CIUS UBL invoice format
Transport and document type: For French contacts registered in the Annuaire, we recommend explicitly setting transport_type_code: "peppol" and document_type_code: "xml.ubl.invoice.frcius.v1". Without pin_value, creation returns HTTP 422 (“Peppol Endpoint ID can’t be blank”). You can verify that a contact is registered in the Annuaire before creating it by using the Directory lookup or the official Peppol Directory.
Contacts in Belgium, Germany, and other EU countries: For B2B invoices to non-French companies, use their national identifier scheme (e.g. "0208" for Belgian KBO/BCE, "0190" for German Leitweg-ID, "0184" for Dutch KVK) and the appropriate country code. If the recipient has an active Peppol access point, B2Brouter routes the invoice via standard Peppol BIS 3.0 — no configuration needed. For transactions with any non-"fr" contact, Flux 10 cross-border e-Reporting is generated automatically.
Multi-level contacts: if your client has several establishments or services that need separate identifiers, create the parent contact first at SIREN level and then add UOs with parent_id. See Account structure for the golden rule and applicable topologies.
B2Brouter routes invoices automatically. To inspect how a recipient will be routed before sending — for example to confirm they are registered in the Annuaire — use the Directory lookup (Flux 11):
Recipient is registered and active at the PPF Annuaire
information_flags
FR_ASSUJETTI_INACTIVE
Recipient has an out-of-date registration or no assigned PA
information_flags
FR_ASSUJETTI_UNKNOWN
The PPF has no conclusive information (e.g. 404)
source
array of "peppol", "annuaire"
Sources consulted. If both appear, B2Brouter found the recipient in both directories
This lookup is informational: B2Brouter already resolves routing automatically when creating an invoice (see Annuaire verification and tax report generation). Use it to inspect before sending or to display the recipient’s status in your UI.
B2Brouter automatically verifies whether French contacts (country: "fr") are registered in the DGFiP Annuaire. This verification determines the tax reporting flow:
Contact registered in Annuaire (in_dgfip_annuaire: true or not yet verified): the invoice generates a Flux 1 tax report (domestic B2B e-invoicing).
Contact NOT registered in Annuaire (in_dgfip_annuaire: false): the invoice does not generate a tax report. This prevents invalid Flux 1 submissions for recipients that the PPF cannot route to.
Contact not yet verified (in_dgfip_annuaire: nil): B2Brouter is permissive — the invoice proceeds and generates a tax report. Verification happens asynchronously in the background.
If you create a French contact and immediately send an invoice, the Annuaire verification may not have completed yet. This is by design — B2Brouter does not block invoice creation while verification is pending. If the contact turns out to be unregistered, future invoices to that contact will not generate Flux 1 tax reports until the contact registers with a PA.
The Annuaire check only applies to French domestic contacts (country: "fr"). Non-French contacts always follow the Flux 10 e-Reporting path regardless of Annuaire status.
Important — both companies must be in the DGFiP Annuaire: for an FR → FR sending with a Flux 1 tax report, both the issuer and the receiver must be registered in the DGFiP Annuaire. If one of them is not, the tax report cannot complete and the invoice is sent without a tax declaration.
⚠️ The annuaire-entreprises.data.gouv.fr website is for general fiscal data; it does not guarantee DGFiP Annuaire registration — they are different databases.
From September 2026 this permissive behaviour will stop applying: tax declarations will simply fail if the identifier is not listed as DGFiP-activable, even when the SIREN/SIRET is valid.
Once your company is onboarded and the DGFiP Tax Report Setting is enabled, creating invoices works through the standard Invoice API. B2Brouter handles all France-specific requirements automatically: tax report generation, UBL/CII/Factur-X formatting, and PPF transmission via Flux 1.
Use send_after_import: true to create and transmit in one step. Set it to false if you want to create the invoice first and review it before sending — in that case, the invoice stays in new state until you trigger transmission via a separate call or through the B2Brouter UI.
Invoice date: for accounts with an active DGFiP Tax Report Setting, the invoice date cannot be a future date. A future date returns HTTP 422 (“Only invoices with today’s date are allowed”). The dates in the examples below are illustrative; replace them with the current date when testing.
Sequential invoicing: The API processes one invoice per request. For bulk or batch scenarios, iterate through your invoice list and call the endpoint for each document. The API supports concurrent requests — you can parallelise multiple POSTs without waiting for each response before starting the next.
The tax_report_ids array in the response contains the ID of the generated tax report. Use it to track the submission lifecycle (see Check the state of a Tax Report).
Three payment fields are mandatory for French B2B e-invoices (IssuedInvoice). Provide them as direct API fields:
Field
DGFiP field
Description
Required
remittance_information
PMD
Payment reference and legal mentions (company registration, share capital, RCS)
Yes — B2B domestic and cross-border
payment_method_text
PMT
Textual description of the payment method
Yes — B2B domestic and cross-border
payment_terms
AAB
Due date, late payment penalties, discount conditions
Yes — B2B domestic and cross-border
bank_account_id
—
Id of the bank account associated with your B2Brouter company. Required when payment_method is bank transfer (code 4)
Yes, for bank transfer payments
If any required field is missing, the request returns HTTP 422 with explicit error messages for each absent field. These are not silent — the invoice is never created. Correct the missing fields and resubmit.
Bank account: create the bank account associated with your company first (from the web UI or via API), and reference its id in the invoice with bank_account_id. The bank account holds IBAN and BIC and is the canonical source — do not pass them as free text inside payment_method_text.
B2C invoices (IssuedSimplifiedInvoice) do not require these fields.
Importing from other formats (UBL, CII, Factur-X): For these integrations, use the extra_info field with structured tags:
#PMD# FA-2026-0048 — Exemplar SAS, RCS Paris 123 456 789
When a line has category: "E" (VAT-exempt), you must also provide a comment with the applicable VATEX-FR-CGI261-* exemption code (DGFiP BT-121):
⚠️ Silent blocking: If comment is omitted on a category E line, the invoice is created (HTTP 200) but never transmitted to the PPF. The response will contain a non-empty errors array — check it even on successful responses.
DGFiP VAT exemption codes (BT-121)
Code
Legal reference
Tax category
Description
VATEX-FR-FRANCHISE
Art. 293 B CGI
Z (zero-rate)
Franchise en base de TVA
VATEX-FR-CNWVAT
—
E (exempt)
Non-established in France
VATEX-FR-AE
—
E (exempt)
Autoliquidation (reverse charge)
VATEX-FR-CGI261-1
Art. 261-1° CGI
E (exempt)
Soins et services médicaux
VATEX-FR-CGI261-2
Art. 261-2° CGI
E (exempt)
Services paramédicaux
VATEX-FR-CGI261-3
Art. 261-3° CGI
E (exempt)
Enseignement scolaire, universitaire et formation professionnelle
Companies operating under the franchise en base de TVA regime operate at zero-rate (tax category Z), not exempt (category E). For franchise invoices, set percent: 0.0 and category: "E" with comment: "VATEX-FR-FRANCHISE" on each tax line — B2Brouter transcodes the category to Z automatically:
To issue a credit note, set is_amend: true and reference the original invoice using amended_number and amended_date. B2Brouter generates a UBL CreditNote with type code 381 and includes the billing reference.
The process code determines the PPF flux cadre. B2Brouter assigns it automatically based on type_operation in the Tax Report Setting and the invoice characteristics.
The invoice has been created and is queued for PPF transmission.
sent
200 — Déposée
The invoice has been successfully deposited at the PPF.
registered
202 — Reçue
The PPF has validated and forwarded the invoice to the buyer.
accepted
205 — Approuvée
The buyer has approved the invoice.
refused
210 — Refusée
The buyer has rejected the invoice.
paid
212 — Encaissée
The invoice payment has been confirmed.
error
—
An error occurred during transmission or PPF validation. The errors field in the invoice response contains the PPF rejection reason. Delete the invoice, correct the issue, and submit a new one — errored invoices cannot be retransmitted directly.
Configure webhook endpoints in the B2Brouter UI under Settings → Webhooks. Once configured, B2Brouter sends an HTTP POST to your endpoint each time the invoice reaches a new state.
After an invoice reaches sent state, the GET /invoices/{id} response includes a download_legal_url field. Use it to download the invoice document that was transmitted:
As a one-step alternative, you can call GET /invoices/{id}/as/legal directly, without first fetching download_legal_url from the invoice payload. It returns the archived legal document as stored and does not generate a billable transaction — see Download invoices and Transaction: View_as.
Encaissée is the last state of the CDV cycle of a French B2B invoice, right after the buyer’s approval. It indicates that payment has been confirmed (see the full CDV mapping in the Invoice states table).
B2Brouter propagates the payment confirmation to the PPF via one of two paths, depending on the invoice nature:
API support coming soon. For now, the API only accepts marking the invoice when it is fully paid (state: "paid").
If you manage payments from an ERP, keep partial-payment bookkeeping internally and only mark the invoice’s PPF state once the total has been covered. Alternatively, handle partial payments in the B2Brouter web app: open the invoice → Create payment → enter the paid amount.
Flux 10 covers transactions outside the scope of the domestic B2B e-invoicing obligation that must still be reported to the DGFiP. B2Brouter handles Flux 10 automatically.
Sales to non-VAT-registered individuals in France. Use "type": "IssuedSimplifiedInvoice". The contact_id and payment fields are not required for B2C invoices.
Cross-border transactions (B2B intra-EU and extra-EU)
Sales to or purchases from companies established outside France must be reported via Flux 10. Use the standard IssuedInvoice or ReceivedInvoice type and set the counterparty’s country to the relevant non-"fr" value. B2Brouter detects the cross-border nature automatically.
B2Brouter groups all Flux 10 tax reports from a calendar day into Ledgers sent to the PPF once per day (scheduled at 02:00 AM server time). You can identify Flux 10 tax reports by a non-null ledger_id in the tax report response.
payments — payment ledgers (process codes S2 / B2 / M2, VAT on services accrues at collection) — document type xml.ledger.dgfip.payments.
The combination of roles and modes yields up to 3 daily ledgers per account:
Ledger
Role
Mode
Content
A — Émission
SE
transactions
Issued invoices (B2C and cross-border B2B)
B — Réception
BY
transactions
Intracommunity / extra-EU purchases declared as the buyer
C — Payments
SE
payments
Confirmed payments of your issued invoices (cross-border / B2C Encaissée case)
The pair (BY, payments) does not exist: payment information for your purchases is generated by the seller on their side; you do not declare it.
Each tax report links to a single ledger_id (it cannot belong to more than one ledger at a time). Grouping happens per account + day + (role, mode) under a lock to avoid duplicates.
As a French company registered in the Annuaire with a Peppol 0225 transport, you automatically receive electronic invoices from other French and Peppol-connected platforms.
