À partir de septembre 2026, toutes les entreprises françaises doivent faire transiter leurs factures et leurs données de TVA par une plateforme certifiée. B2Brouter simplifie cela : tu envoies tes données de facture via un appel REST API, et B2Brouter gère l’enregistrement au PPF, la génération de documents (UBL/CII/Factur-X), le routage vers tes clients, et le rapport fiscal à la DGFiP — le tout via une seule intégration.
B2Brouter est une Plateforme Agréée (PA) certifiée pour la réforme française de facturation électronique DGFiP. Connecte-toi via REST API et B2Brouter gère l’ensemble de la conformité pour toi :
Ce que B2Brouter fait pour toi
Détails
Enregistrement PPF
Publie ton SIREN/SIRET dans l’Annuaire automatiquement lors de l’activation
Flux 1 — facturation électronique B2B
Génère UBL/CII/Factur-X, transmet au PPF, route vers la plateforme de l’acheteur
Flux 6 — cycle de vie de la facture
Gère les messages de statut CDAR (Déposée, Reçue, Approuvée, Refusée, Encaissée)
Flux 10 — e-Reporting
Agrège les transactions B2C et B2B transfrontalières (intra-UE et extra-UE) en Ledgers envoyés au PPF à la fréquence définie par le vat_regime de ton Tax Report Setting
Réception Peppol 0225
Reçoit les factures depuis n’importe quelle plateforme française ou connectée à Peppol
Génération de documents
Tu envoies les données de facture en JSON — B2Brouter génère le document UBL/CII/Factur-X conforme et le transmet au PPF. Aucune génération XML requise de ton côté
Formats d’entrée
JSON REST API, Factur-X PDF/A-3 (avec XML CII intégré), UBL 2.1 XML, CII XML
Archivage légal
Tous les documents transmis (factures, rapports fiscaux, messages CDAR) sont conservés par B2Brouter pendant la période légale de conservation de 10 ans. Aucune configuration de stockage supplémentaire requise de ton côté
Contexte réglementaire : La réforme française de facturation électronique impose que toutes les entreprises françaises utilisent une Plateforme Agréée (PA) certifiée ou le PPF (Portail Public de Facturation) de l’État pour transmettre les factures et déclarer les données de TVA à la DGFiP, à partir de septembre 2026. En tant que PA certifiée, B2Brouter gère entièrement la connexion au PPF pour toi — pas de SFTP, pas de certificats électroniques, pas d’intégration directe au PPF requise.
Il existe deux cas d’usage principaux pour intégrer B2Brouter à la facturation électronique française :
eDocExchange — Pour les entreprises ou groupes d’entreprises qui intègrent leur logiciel de gestion (ERP, plateforme comptable) directement avec B2Brouter. Le processus d’onboarding (création du compte, configuration des Tax Report Settings) s’effectue généralement une fois par entreprise via l’interface web. Les opérations quotidiennes (émission de factures, suivi de leur cycle de vie) se font via l’API. Pour ajouter d’autres comptes d’entreprise à ton groupe d’intégration, suis le même assistant d’onboarding depuis le même compte utilisateur B2Brouter — aucun appel API distinct requis.
eDocSync — Pour les éditeurs de logiciels et fournisseurs d’ERP qui souhaitent offrir la conformité DGFiP à leurs propres clients depuis leur produit. C’est le modèle marque blanche / intégré de B2Brouter : B2Brouter opère entièrement en arrière-plan, les clients finaux interagissent exclusivement avec l’interface de l’éditeur et ignorent l’existence de B2Brouter. L’éditeur du logiciel est responsable de la création des comptes, de la soumission des factures et du suivi du cycle de vie via l’API B2Brouter. Les clients finaux n’ont besoin ni d’identifiant B2Brouter ni d’abonnement.
Pour eDocSync, le volume de provisionnement de comptes détermine le bon plan :
Peu d’entreprises (modèle revendeur) : ajoute chaque entreprise cliente comme compte dans ton groupe d’intégration B2Brouter via l’interface web, en suivant l’assistant d’onboarding standard. Cela fonctionne bien pour des dizaines d’entreprises et partage une seule clé API.
100+ entreprises : contacte notre équipe commerciale ou ouvre un ticket de support pour discuter d’un plan eDocSync dédié avec provisionnement en masse (tarification au volume pour les éditeurs).
Dans les deux cas, toutes les fonctionnalités de conformité spécifiques à la France (enregistrement à l’Annuaire, transmission Flux 1/6/10, cycle de vie CDAR) fonctionnent de manière identique.
B2Brouter est elle-même une Plateforme Agréée : tu t’intègres avec B2Brouter — ce n’est ni un relais ni un connecteur vers une autre PA. Si ton SIREN est actuellement enregistré auprès d’une autre PA, activer le Tax Report Setting sur le compte SIREN (étape 2) transfère automatiquement l’entrée de l’Annuaire vers B2Brouter. Pour n’intégrer qu’un seul établissement tout en conservant cet enregistrement existant, consulte le scénario 2 dans Structure du compte. Tu ne peux pas utiliser B2Brouter comme simple passerelle pour soumettre des factures sous la certification d’une autre PA.
Routage vers des destinataires sur d’autres PA : quand ton acheteur est enregistré auprès d’une autre PA, B2Brouter route la facture via le modèle Peppol standard à quatre coins (C2 → C3) : le point d’accès Peppol de B2Brouter (C2) recherche l’adresse Peppol du destinataire dans l’Annuaire et livre le document au point d’accès de l’acheteur (C3) — quelle que soit la PA qu’il utilise. Aucune configuration supplémentaire n’est requise de ton côté.
Environnements de test : utilise le sandbox pour les premiers tests API et la validation des payloads — les soumissions DGFiP sont simulées en sandbox, aucun SIRET fictif requis. Pour des tests de bout en bout complets avec l’environnement DGFiP QAS (qualification), utilise l’environnement staging de B2Brouter comme décrit ci-dessous.
Ne mélange pas les environnements. La production utilise de vrais numéros SIREN/SIRET et se connecte à l’Annuaire de production de la DGFiP. Le staging utilise des identifiants de test fictifs et se connecte à l’environnement DGFiP QAS (qualification). Les clés API, comptes et contacts ne sont pas partagés entre environnements.
Inscris-toi sur app.b2brouter.net pour démarrer une intégration en production. Quand tu actives le Tax Report Setting DGFiP, le SIREN/SIRET de ton entreprise est publié dans l’Annuaire PPF réel, le rendant identifiable par toute plateforme de l’écosystème français de facturation électronique.
Cette option est conçue pour les vraies factures B2B à partir de septembre 2026. En attendant, la DGFiP purgera les enregistrements de la période QAS avant l’entrée en vigueur de la réforme — donc les factures que tu envoies pendant ton pilote ne créeront aucune obligation de conformité. C’est le bon point de départ si tu as déjà choisi B2Brouter et veux tester l’intégration complète avec les vraies données de ton entreprise.
Inscris-toi sur app-staging.b2brouter.net pour utiliser l’environnement de test de B2Brouter, connecté à l’environnement QAS (qualification) de la DGFiP.
C’est la meilleure option si :
Tu évalues plusieurs plateformes avant de t’engager
Ton SIREN/SIRET est déjà publié dans l’Annuaire auprès d’une autre PA (activer B2Brouter en production transférerait l’entrée)
Tu préfères ne pas associer l’identifiant de ton entreprise à une activité de test
L’environnement staging est auto-provisionné : une fois que tu as des identifiants de test (voir ci-dessous), tu peux démarrer des tests de bout en bout en moins de 24 heures.
Validation des SIRET en staging : dans l’environnement staging, tout numéro valide à 14 chiffres est accepté comme SIRET sans validation de clé de contrôle. Les identifiants fictifs du CSV Chorus Pro QAS sont préenregistrés dans l’annuaire DGFiP QAS et fonctionnent de bout en bout. En production, le format et la clé de contrôle du SIRET sont validés.
Important : la DGFiP n’autorise pas les numéros SIREN ou SIRET réels dans son environnement QAS. Tu dois utiliser des identifiants de test fictifs. Tu peux les obtenir toi-même via le portail Chorus Pro QAS (gratuit, 5 minutes) ou demander un jeu préassigné en ouvrant un ticket de support dans l’application staging.
Un compte par SIREN : B2Brouter crée un compte par SIREN (la clé du numéro de TVA est dérivée du SIREN). Si tu fournis un SIRET, le SIREN en est extrait. Deux SIRET différents de la même entreprise (même SIREN) résoudront vers le même compte. Si ton entreprise opère depuis plusieurs établissements (SIRET différents), ceux-ci sont modélisés comme des unités organisationnelles au sein du même compte B2Brouter — pas comme des comptes séparés. Contacte le Support si tu as besoin de configurer une facturation multi-établissements. Garde cela à l’esprit lors de la sélection des lignes du CSV : choisis des SIRET avec des SIREN distincts (9 premiers chiffres) pour chaque entreprise indépendante que tu dois tester.
Obtenir des identifiants de test via Chorus Pro QAS
Le portail Chorus Pro QAS te permet de générer un « Matelas de données » (jeu de données) — un fichier CSV contenant des identifiants SIREN/SIRET fictifs préenregistrés dans l’environnement de test de la DGFiP. Suis ces étapes :
Tu peux utiliser une adresse e-mail temporaire (par exemple temp-mail.io).
Utilise n’importe quel nom ; ce compte sert uniquement à obtenir des identifiants de test.
Vérifie ta boîte de réception pour l’e-mail « Initialisation de mot de passe Chorus Pro » et définis ton mot de passe (lien valide 60 minutes).
Connecte-toi → va dans Domaines → Matelas de données → clique sur Générer un matelas de données et confirme.
Va dans Consultation du matelas de données. Attends que les deux statuts affichent « Disponible » :
Statut pour Chorus Pro : Disponible
Statut pour l’annuaire de facturation PPF : Disponible
La génération prend généralement quelques minutes. Actualise la page pour vérifier.
Clique sur « Générer et télécharger le fichier CSV du matelas structures et utilisateurs » pour télécharger tes identifiants de test.
Le CSV contient plusieurs numéros SIREN/SIRET fictifs dans des lignes étiquetées « Privé » et « Public ». Utilise uniquement les lignes de la section « Privé » (secteur privé) pour tes comptes de test. Les entités du secteur public (SIREN 'Public') sont rejetées par l’annuaire DGFiP QAS — tenter d’activer l’e-Reporting sur un compte du secteur public renvoie une erreur HTTP 422 (« La création d’une ligne annuaire n’est pas possible pour une entité associée à un SIREN ‘Public’ »). C’est le comportement attendu : les entités publiques utilisent directement Chorus Pro, pas une PA.
Utilise un SIREN du secteur privé pour ton compte émetteur et un autre pour ton contact de test.
Crée le compte de ton entreprise en utilisant un SIREN du CSV (voir Étape 1).
Souscris à un plan eDocExchange (les abonnements staging sont simulés — aucun frais).
Active les paramètres de rapport fiscal DGFiP (voir Étape 2).
⚠️ Après avoir activé le Tax Report Setting DGFiP, l’enregistrement de ton entreprise à l’Annuaire prend jusqu’à 24 heures pour se propager — aussi bien en staging qu’en production. C’est une contrainte de l’infrastructure DGFiP, pas un délai de B2Brouter. Tu ne pourras pas envoyer de factures avant le lendemain.
Le lendemain : crée un contact de test en utilisant un second SIREN du CSV (voir Étape 3).
L’authentification utilise une clé API statique passée dans l’en-tête HTTP X-B2B-API-Key. Il n’y a pas de flux OAuth2 — génère ta clé API dans l’interface B2Brouter sous Paramètres → Clés API. Garde-la confidentielle et ne l’inclus jamais dans du code côté client. Définis aussi X-B2B-API-Version dans chaque requête.
URL de base : tous les exemples ci-dessous utilisent https://api-staging.b2brouter.net. Pour la production, remplace par https://api.b2brouter.net.
Structure du compte : parent et unités organisationnelles
Une entreprise française avec plusieurs établissements ou services est modélisée dans B2Brouter comme un compte parent (l’entité principale) et, éventuellement, une ou plusieurs unités organisationnelles — UO (établissements ou services) liées au compte parent.
Les factures sont émises depuis le compte SIREN ou depuis une UO spécifique, selon l’établissement émetteur.
Le compte parent est toujours créé avec un identifiant SIREN (cin_scheme="0002", l’entité légale). Un identifiant SIRET n’est jamais un compte parent : créer un compte parent français avec cin_scheme="0009" renvoie 422 parameter_matriu_must_be_siren. Les établissements (SIRET) et services sont toujours modélisés comme des UO sous le compte parent SIREN.
Ce qui change selon ta situation, c’est où tu actives le Tax Report Setting DGFiP. Consulte l’arbre de décision dans Cas et topologies.
Pas d’héritage entre UO et parent : pour les comptes dans le territoire de TVA français (FR, et les DROM GP/MQ/RE), une UO n’hérite jamais du rapport fiscal du parent. Chaque compte (parent ou UO) ne regarde que son propre Tax Report Setting : sans en avoir un, l’UO ne déclare pas ; avec un Tax Report Setting propre désactivé (enabled: false), elle ne déclare pas non plus : même résultat (opt-out), pas une exception. Tu dois activer explicitement un Tax Report Setting sur chaque compte qui doit déclarer. (Cet héritage par défaut du parent existe bien pour les établissements français d’autres administrations fiscales historiques.)
Cette décision détermine où le rapport fiscal est activé, pas l’identifiant du parent (qui est toujours le SIREN). En cas de doute sur l’enregistrement de ton SIREN, vérifie d’abord l’Annuaire avec la recherche dans l’annuaire.
Comptes hérités (normalisation) : jusqu’en juillet 2026, la plateforme permettait de créer un compte parent avec un SIRET. Si tu as des comptes créés ainsi, ils doivent être normalisés : remplace l’identifiant du parent par le SIREN (cin_scheme="0002", cin_value = le SIREN à 9 chiffres) et crée le SIRET correspondant comme UO sous ce parent SIREN.
Pourquoi un SIRET est toujours une UO : tout SIRET est toujours modélisé comme une UO sous le parent SIREN, jamais comme un compte ou contact indépendant. Cela évite les incohérences entre le parent et ses UO, en particulier quand tu composes toi-même les identifiants pour un contact en ligne sur une facture, où il n’y a pas de validation préalable du module de contacts pour te protéger d’une composition FR incorrecte.
Dans B2Brouter, un compte ou contact français est défini par un identifiant principal (cin_scheme + cin_value) et, éventuellement, un sous-identifiant (routing_codes.cin1_scheme + routing_codes.cin1_value) quand tu dois adresser un service spécifique au sein d’un établissement.
Identifiant principal du compte / de l’UO (cin_scheme + cin_value) :
cin_scheme
Identifiant
Format
Exemple
0002 (2)
SIREN — entité légale
9 chiffres + Luhn
123456789
0009 (9)
SIRET — établissement
14 chiffres (SIREN + 5 chiffres) + Luhn
12345678900012
8040
Suffixe — UO sans SIRET propre
Alphanumérique [A-Za-z0-9_\-\/]+
SUF01, ADMIN
Sous-identifiant (code de routage) — uniquement pour les UO SIRET avec plusieurs services internes :
EAS Peppol du participant FR : l’identifiant électronique sur le réseau Peppol est toujours 0225 (FRCTC Electronic Address). Les schémas 224 (Code Routage) et 8040 (Suffixe) sont des sous-identifiants internes de l’annuaire et ne sont pas publiés comme EAS Peppol autonomes.
Suffixe vs Code Routage — Le Suffixe (8040) est le cin_scheme principal d’une UO sans SIRET propre. Le Code Routage (224), à l’inverse, va toujours dans routing_codes.cin1_scheme="224" sur une UO avec SIRET — jamais comme cin_scheme principal.
Important : un SIRET seul (sans SIREN devant) n’est pas un identifiant publié valide. Un SIRET vit toujours sur une UO sous le parent SIREN ; la composition publiée est SIREN_SIRET, où le SIREN provient du compte parent.
Voir les 4 formats d'identifiants finaux à l'Annuaire
Composition Annuaire
Signification
SIREN
Entité entière (Parent)
SIREN_SIRET
Établissement (Cas 1 / Cas 4)
SIREN_SIRET_<CR>
Service au sein d’un établissement (Cas 2 / Cas 5)
SIREN_<SUFFIX>
UO sans SIRET propre (Cas 3 / Cas 6)
Aucune de ces compositions n’est émission-seule par elle-même — y compris la simple ligne SIREN. Le fait qu’une adresse reçoive aussi des factures (un transport 0225 est publié pour elle) dépend uniquement du drapeau issue_only sur ce Tax Report Setting, pas de la composition utilisée. Voir la note sur issue_only dans le tableau des topologies ci-dessous.
Pour voir les champs API exacts qui produisent chaque format, consulte le tableau Cas et topologies ci-dessous.
Ta structure dépend de deux facteurs : si ton SIREN est libre de toute autre PA, et si tu veux émettre ou aussi recevoir. Choisis ta configuration avec cet arbre de décision :
Ton SIREN est-il déjà enregistré auprès d’une autre Plateforme Agréée (PA) ?
Non → active le Tax Report Setting sur le parent SIREN (Scénario 1). Modélise les établissements, services internes ou UO sans SIRET avec les Cas 1, 2 et 6 du tableau ci-dessous.
Oui, et tu veux intégrer un établissement spécifique dans B2Brouter sans toucher à l’enregistrement existant → crée l’établissement comme UO SIRET et active le Tax Report Setting uniquement sur cette UO (Scénario 2, Cas 4 et 5) ; le parent SIREN ne porte aucun TRS.
Oui, et tu veux seulement émettre depuis B2Brouter sans publier de transport de réception → active issue_only=true sur le parent SIREN (Scénario 3, ligne « Émission uniquement »).
Dans tous les cas, le compte parent est toujours le SIREN. Ce qui change, c’est où le Tax Report Setting est activé et si un transport 0225 est publié.
Aucune, ou une UO Suffixe (Cas 6) avec son propre issue_only=true
Parent
SIREN ou SIREN_<SUFFIX>
Il n’y a pas de « Cas 3 » : la numérotation vient du schéma d’identifiants interne de la DGFiP et saute directement de 2 à 4. Aucune configuration ne manque : la ligne « Émission uniquement » couvre cet écart.
Le suffixe et issue_only sont indépendants : le suffixe (SIREN_<SUFFIX>) n’est qu’un détail d’adressage : le fait qu’il reçoive aussi des factures dépend exclusivement du drapeau issue_only, pas de la présence du suffixe. Avec issue_only=true + suffixe, la Ligne est publiée dans l’Annuaire mais aucun transport 0225 n’est publié → émission seule, pas de réception. Sans issue_only + suffixe, le transport 0225 est publié → émission et réception à cette même adresse, exactement comme n’importe quelle autre.
Les contacts dans B2Brouter (clients et fournisseurs français) suivent exactement la même hiérarchie (parent + UO) et les mêmes valeurs cin_scheme (SIREN / SIRET / Code Routage / Suffixe). Gère les contacts exactement comme tes propres comptes : le parent du contact doit être le SIREN, et tout SIRET, Code Routage ou Suffixe doit être une UO. Bien que le système autorise techniquement un parent de contact à un autre niveau, cela risque de créer des ruptures quand tu ajoutes plus tard des UO du même client, donc garde toujours le SIREN comme parent.
Règle d’or pour les contacts : le parent est toujours le SIREN ; modélise tout SIRET, Code Routage ou Suffixe comme des UO, exactement comme pour les comptes.
Avec le parent au niveau SIREN, les cas des 3 scénarios s’appliquent aux contacts (les UO peuvent être SIRET, Code Routage ou Suffixe selon la structure du client).
Pour créer une UO de contact, utilise le même endpoint que pour un contact normal — POST /accounts/{ACCOUNT_ID}/contacts — en ajoutant parent_id pointant vers le contact parent. tin_value et tin_scheme sont hérités du parent et ne peuvent pas diverger.
Contacts hérités (normalisation) : comme pour les comptes, jusqu’en juin 2026 un contact pouvait être créé avec un SIRET comme parent. Si tu as des contacts créés ainsi, normalise-les : remplace l’identifiant du contact parent par le SIREN (cin_scheme="0002") et crée le SIRET correspondant comme UO sous ce contact SIREN.
Étape 1 : Récupérer ou créer le compte de ton entreprise
Rappel de structure : le compte parent est toujourscin_scheme="0002" (SIREN) — voir Structure du compte. Ce qui diffère entre les scénarios n’est pas l’identifiant du parent mais où tu actives le Tax Report Setting (sur le parent SIREN au Scénario 1, sur l’UO SIRET au Scénario 2). Les établissements sont toujours créés comme UO à l’étape 1b.
Si tu as déjà un compte B2Brouter pour ton entreprise, récupère son id avec l’endpoint List Accounts et saute l’étape de création.
Si tu n’en as pas encore créé un, utilise l’endpoint Create Account (chemin eDocSync/API) ou l’assistant d’onboarding de l’interface web (chemin eDocExchange). Les deux produisent le même résultat.
Lors de la création d’un compte d’entreprise française :
cin_scheme : toujours "0002" (SIREN, 9 chiffres) pour le compte parent. Un SIRET n’est pas accepté comme identifiant parent : créer un compte parent français avec cin_scheme "0009" renvoie 422 parameter_matriu_must_be_siren. Les établissements (SIRET) sont créés comme unités organisationnelles sous le parent SIREN (voir étape 1b).
cin_value : le SIREN de ton entreprise (9 chiffres).
tin_value : numéro de TVA français au format FR{kk}{siren}, où kk est la clé de contrôle à deux chiffres (par exemple FR32123456789). Il est obligatoire pour la facturation DGFiP ; tu n’as pas besoin de calculer toi-même la clé de contrôle. Si tu fournis seulement le SIREN ou seulement le numéro de TVA, B2Brouter dérive automatiquement l’autre quand tu actives le Tax Report Setting DGFiP. Cette dérivation n’a lieu qu’à l’activation : si tu ne fournis ni le numéro de TVA ni n’actives le Tax Report Setting, il reste vide et la facturation échouera, donc active le paramètre pour éviter les problèmes.
Si la structure de ton entreprise nécessite des UO (voir les Cas 1, 2, 4, 5 et 6 dans Topologies), crée chaque UO avec POST /accounts en ajoutant parent_id (l’id du compte parent créé à l’étape 1a).
Cette fonctionnalité nécessite une version d’API qui prend en charge les UO avec parent_id. Consulte le changelog de l’API pour la version minimale.
Restrictions :
parent_id est obligatoire pour créer une UO.
Une UO ne peut pas inclure tin_value ou tin_scheme (ils sont hérités du parent).
Une UO ne peut pas être parent d’une autre UO (un seul niveau d’imbrication).
UO établissement portant son propre TRS (Scénario 2, Cas 4/5)
Mêmes champs que le Cas 1 (ou Cas 2 pour un service) : parent_id (parent SIREN) + cin_scheme="0009" + cin_value=<SIRET> [+ routing_codes.cin1_scheme="224" + routing_codes.cin1_value=<CR> pour un service]. La différence est que cette UO reçoit son propre Tax Report Setting alors que le parent SIREN n’en a aucun.
Champs obligatoires sur chaque payload d’UO : en plus de parent_id et cin_*, tu dois inclure country, email, address, city, postalcode et province. Sans eux, la création renvoie HTTP 422 (« Region/Province/Country can’t be blank »). tin_value et tin_scheme sont hérités du parent et ne doivent pas être répétés.
Exemple — UO Établissement avec Service optionnel (Cas 1 et 2) :
Pour un établissement sans Code Routage (Cas 1 pur), omets le bloc routing_codes.
Exemple — UO établissement portant son propre Tax Report Setting (Scénario 2, Cas 4/5) :
L’UO est créée exactement comme le Cas 1/2 (ci-dessous, une variante service avec un Code Routage). La différence au Scénario 2 est que tu actives ensuite un Tax Report Setting sur cette UO (pas sur le parent SIREN), afin que l’enregistrement Annuaire existant du SIREN auprès d’une autre PA soit préservé (voir étape 2).
L’UO porte le SIRET comme cin_scheme principal "0009" et, pour un service, l’identifie via routing_codes.cin1_value. Le Code Routage ne va jamais en cin_scheme principal. Pour une UO établissement seul (Cas 4), omets le bloc routing_codes.
Exemple — UO Suffixe (Cas 6) :
Fenêtre de terminal
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"
}
}'
Les cas Émission uniquement (Scénario 3) ne sont pas créés comme des UO — ce sont le parent SIREN lui-même, défini à l’étape 1a avec cin_scheme="0002" (et issue_only=true, plus un éventuel suffixe 8040). Les Cas 4 et 5 (Scénario 2), en revanche, sont des UO : un parent SIREN plus une UO SIRET qui porte son propre Tax Report Setting.
Étape 2 : Activer les paramètres de rapport fiscal pour la DGFiP
C’est l’étape clé de l’onboarding. Quand tu crées un Tax Report Setting avec code: "dgfip", B2Brouter automatiquement :
Enregistre ton entreprise dans l’Annuaire du PPF — ton SIREN/SIRET devient identifiable par toute plateforme de l’écosystème français de facturation électronique.
Crée un transport Peppol 0225 — permettant à ton entreprise de recevoir des factures électroniques depuis toute plateforme connectée à Peppol en France.
⚠️ Remplacement de transport :
Si le compte sur lequel tu actives dispose déjà d’un transport Peppol, il sera remplacé par le nouveau transport 0225 (FRCTC Electronic Address) lors de l’activation. Si le SIREN sur lequel tu actives était précédemment enregistré auprès d’une autre PA, B2Brouter fermera l’entrée Annuaire existante et en ouvrira une nouvelle. Si tu as besoin de conserver cet enregistrement existant, n’active pas sur le SIREN ; active plutôt sur une UO SIRET (voir « Où activer » ci-dessous). Mets à jour toute intégration existante qui référence l’ancien identifiant de transport.
Où activer le Tax Report Setting : {ACCOUNT_ID} peut être le parent SIREN, une UO SIRET, ou les deux. Chaque compte (parent ou UO) qui a son propre Tax Report Setting est publié dans l’Annuaire sous sa propre adresse. Pour les comptes dans le territoire de TVA français (FR, et les DROM GP/MQ/RE), il n’y a pas d’héritage entre UO et parent (voir La règle d’or) : sans son propre TRS, l’UO ne déclare pas, et avec un TRS propre désactivé, elle ne déclare pas non plus. Trois configurations :
TRS uniquement sur le SIREN : l’entreprise est publiée comme SIREN (cas standard, Scénario 1). Les nouvelles UO créées sous ce parent reçoivent automatiquement leur propre TRS cloné à la création (voir la note ci-dessous), donc elles déclarent normalement aussi.
TRS sur le SIREN et sur une ou plusieurs UO SIRET : l’entreprise est publiée à la fois comme SIREN et comme chaque SIREN_SIRET (une adresse Annuaire par compte activé). Tous les TRS DGFiP actifs sous le même SIREN doivent partager le même vat_regime : en activer un avec une valeur différente renvoie 422 dgfip_vat_regime_taken_per_siren.
TRS uniquement sur une UO SIRET, pas sur le SIREN : seul cet établissement est publié (SIREN_SIRET) ; le SIREN lui-même ne l’est pas (Scénario 2). Utilise cela quand le SIREN est déjà enregistré auprès d’une autre PA et que tu veux conserver cet enregistrement.
Si tu crées une UO alors que le parent est déjà actif : B2Brouter crée automatiquement son propre Tax Report Setting DGFiP (avec start_date demain), afin qu’elle commence à déclarer sans étape supplémentaire. Si le parent n’a pas la DGFiP active à ce moment, l’UO est créée sans aucun Tax Report Setting ; quand tu actives le parent plus tard, l’UO reçoit le sien. L’UO ne regarde jamais le paramètre du parent pour décider si elle doit déclarer.
Le start_date détermine quand le rapport fiscal commence. À partir de cette date, les factures que tu émets génèreront des rapports fiscaux et seront transmises au PPF.
Quand le rapport fiscal commence. Doit être aujourd’hui ou une date future. Par défaut, demain si omis.
type_operation
string
Oui
Type d’opération par défaut pour cette entreprise : "services", "goods" ou "mixed". Détermine le code de procédure DGFiP (S1/B1, etc.) utilisé dans les rapports fiscaux. Choisis "mixed" si ton entreprise vend à la fois des biens et des services. Sur une facture mixte, le rapport fiscal Flux 1 est émis sous le code de procédure services (S1/S2/S4/S7) et ne déclare que les ventilations de services ; la DGFiP n’a pas de cadre « M » dédié pour le Flux 1 (voir Codes de procédure). Ce paramètre peut être mis à jour après l’activation.
naf_code
string
Oui
Le code NAF/APE de l’entreprise (Nomenclature d’Activités Française). C’est le code section à 2 chiffres attribué par l’INSEE qui identifie l’activité économique principale de l’entreprise (par exemple "62" pour les services informatiques et logiciels, "47" pour le commerce de détail, "86" pour la santé). La DGFiP utilise ce code pour la classification du rapport fiscal. Tu trouveras ton code NAF sur le Kbis de ton entreprise ou sur sirene.fr.
enterprise_size
string
Oui
La catégorie de taille de l’entreprise telle que définie par l’INSEE. Valeurs autorisées : "micro" (Microentreprise — < 10 salariés, CA ≤ 2 M€), "pme" (PME — 10 à 249 salariés, CA ≤ 50 M€), "eti" (ETI — 250 à 4 999 salariés, CA ≤ 1,5 Md€), ou "ge" (Grande Entreprise — 5 000+ salariés ou CA > 1,5 Md€).
vat_regime
string
Oui, sauf si annuaire_only=true
Le régime de TVA de l’entreprise. Détermine la fréquence de transmission du Flux 10 (e-Reporting) : • reel_normal_mensuel : par décade (jours 1-10, 11-20, 21-fin de mois) pour les transactions ; mensuel pour les paiements. • reel_normal_trimestriel : mensuel. • simplifie : mensuel (régime aboli au 01/01/2027 ; traité comme reel_normal_trimestriel ensuite). • franchise_en_base : bimestriel (bimestres calendaires : jan-fév, mar-avr, mai-juin, juil-août, sep-oct, nov-déc). Sans vat_regime valide, aucune facture déclarable ne peut être transmise : la requête renvoie HTTP 422.
reason_vat_exempt
string
Non
Code de motif d’exonération de TVA par défaut pour cette entreprise. Par défaut "VATEX-FR-FRANCHISE" (franchise en base de TVA). Définis ce champ si ton entreprise opère sous un régime d’exonération de TVA spécifique. Voir Lignes exonérées de TVA et Franchise en base de TVA pour la liste complète des codes acceptés.
email
string
Non
E-mail de contact pour les notifications fiscales.
auto_generate
boolean
Non
Toujours true pour la DGFiP (obligation légale). Ne peut pas être modifié.
auto_send
boolean
Non
Transmet automatiquement les rapports fiscaux au PPF. Par défaut true.
enabled
boolean
Non
Indique si le paramètre est actif. Par défaut true. L’enregistrement à l’Annuaire n’a lieu que si true.
annuaire_only
boolean
Non
Quand true, le compte n’est enregistré à l’Annuaire du PPF que pour la réception. Aucun rapport fiscal Flux 1 n’est généré et aucun message CDAR n’est envoyé ; enterprise_size et naf_code deviennent facultatifs. Par défaut false. Voir Mode réception uniquement.
Si l’enregistrement à l’Annuaire échoue (SIREN/SIRET invalide, ou panne temporaire du service DGFiP), la création du Tax Report Setting est annulée et une erreur est renvoyée. Corrige le problème et réessaie.
Si ton compte a seulement besoin de recevoir des factures électroniques (pas de les émettre) — par exemple, une entreprise pas encore tenue d’émettre mais qui veut être enregistrée à l’Annuaire pour que ses fournisseurs puissent lui envoyer des factures via Peppol — tu peux activer le Tax Report Setting DGFiP avec annuaire_only: true.
Ce que cela active :
Enregistre ton entreprise auprès de l’Annuaire du PPF (visible par les émetteurs).
Crée le transport Peppol 0225 pour la réception.
Ce que cela n’inclut pas, comparé à une activation complète :
Aucun rapport fiscal Flux 1 n’est généré lors de l’émission de factures.
Ce mode est utile pour des entreprises en phase d’évaluation qui reçoivent des factures, ou pour des entités qui ont un autre fournisseur de facturation mais veulent recevoir via B2Brouter. Quand tu veux commencer à émettre, mets à jour le Tax Report Setting en mode complet avec un PATCH (voir le guide des Tax Report Settings).
Un contact B2B français a besoin d’identifiants de routage (comment la facture atteint le destinataire) et d’une identification fiscale (comment le destinataire apparaît dans le XML UBL).
Champ
Valeur
Objectif
cin_scheme
"0002" (SIREN, par défaut) ou "0009" (SIRET, pour adresser un établissement spécifique)
ID de l’organisation — utilisé pour rechercher le destinataire dans l’Annuaire
cin_value
SIREN ou SIRET
ID de l’organisation — l’identifiant enregistré dans l’Annuaire
tin_scheme
9957
ID fiscal — code ISO 6523 pour l’identifiant fiscal français
tin_value
FR{kk}{siren} (par exemple "FR78225214234")
ID fiscal — numéro de TVA français dans le XML UBL
pin_scheme
"0225"
EAS Peppol du participant FR (FRCTC Electronic Address) — requis pour les contacts français
pin_value
Composition Annuaire du destinataire
Identifiant Peppol du contact ; suit la même composition que le parent à l’Annuaire (SIREN, SIREN_SIRET, SIREN_SIRET_<CR> ou SIREN_<SUFFIX> — voir Niveaux d’identifiants)
country
"fr"
Requis pour la logique de routage DGFiP
currency
"EUR"
Devise par défaut pour les factures de ce contact
transport_type_code
"peppol"
Recommandé — assure la livraison via le réseau Peppol
document_type_code
"xml.ubl.invoice.frcius.v1"
Recommandé — format de facture UBL France CIUS
Transport et type de document : pour les contacts français enregistrés à l’Annuaire, nous recommandons de définir explicitement transport_type_code: "peppol" et document_type_code: "xml.ubl.invoice.frcius.v1". Sans pin_value, la création renvoie HTTP 422 (« Peppol Endpoint ID can’t be blank »). Tu peux vérifier qu’un contact est enregistré à l’Annuaire avant de le créer en utilisant la recherche dans l’annuaire ou l’annuaire officiel Peppol.
Contacts en Belgique, en Allemagne et dans d’autres pays de l’UE : pour les factures B2B vers des entreprises non françaises, utilise leur schéma d’identifiant national (par exemple "0208" pour le KBO/BCE belge, "0190" pour le Leitweg-ID allemand, "0184" pour le KVK néerlandais) et le code country approprié. Si le destinataire a un point d’accès Peppol actif, B2Brouter route la facture via le Peppol BIS 3.0 standard — aucune configuration nécessaire. Pour les transactions avec tout contact non "fr", l’e-Reporting transfrontalier Flux 10 est généré automatiquement.
Adresser un établissement spécifique : si le client a plusieurs établissements et que tu dois en identifier un en particulier, utilise cin_scheme: "0009" avec le SIRET à 14 chiffres et définis pin_value sur la composition SIREN_SIRET (par exemple 987654321_98765432100011) au lieu du simple SIREN.
Contacts multi-niveaux : si ton client a plusieurs établissements ou services nécessitant des identifiants séparés, crée d’abord le contact parent au niveau SIREN puis ajoute des UO avec parent_id. Voir Structure du compte pour la règle d’or et les topologies applicables.
Alternative : contact en ligne sur la facture (sans le module contacts)
Au lieu de créer un contact séparément et de le référencer avec contact_id, tu peux envoyer un objet contact en ligne directement à l’intérieur de POST /accounts/{ACCOUNT_ID}/invoices, avec toutes les données du destinataire :
{
"invoice":{
"type":"IssuedInvoice",
"contact":{
"name":"Client Exemple SARL",
"country":"fr",
"currency":"EUR",
"language":"fr",
"cin_scheme":"0009",
"cin_value":"98765432100011",
"tin_scheme":9957,
"tin_value":"FR05987654321",
"pin_scheme":"0225",
"pin_value":"987654321_98765432100011",
"transport_type_code":"peppol",
"document_type_code":"xml.ubl.invoice.frcius.v1"
}
}
}
⚠️ Avertissement important : passe toujours les identifiants corrects (tin / cin / pin) avec la bonne composition FR (parent SIREN + UO), pour éviter de casser la cohérence parent↔UO (voir La règle d’or). À partir de la version d’API 2026-04-20, le système rejette (422) un contact en ligne non simplifié qui ne fournit ni tin_value ni cin_value. currency et language sont obligatoires sur tout contact ; sans eux, la création échoue dans tous les cas.
Facultatif : vérifier le routage du destinataire (recherche dans l’annuaire)
B2Brouter route les factures automatiquement. Pour inspecter comment un destinataire sera routé avant l’envoi — par exemple pour confirmer qu’il est enregistré à l’Annuaire — utilise la recherche dans l’annuaire (Flux 11) :
Le destinataire est enregistré et actif à l’Annuaire du PPF
information_flags
FR_ASSUJETTI_INACTIVE
Le destinataire a un enregistrement obsolète ou aucune PA assignée
information_flags
FR_ASSUJETTI_UNKNOWN
Le PPF n’a pas d’information concluante (par exemple 404)
source
tableau de "peppol", "annuaire"
Sources consultées. Si les deux apparaissent, B2Brouter a trouvé le destinataire dans les deux annuaires
Cette recherche est informative : B2Brouter résout déjà le routage automatiquement lors de la création d’une facture (voir Vérification dans l’Annuaire et génération du rapport fiscal). Utilise-la pour inspecter avant l’envoi ou pour afficher le statut du destinataire dans ton interface.
B2Brouter vérifie automatiquement si les contacts français (country: "fr") sont enregistrés à l’Annuaire de la DGFiP. Cette vérification détermine le flux de rapport fiscal :
Contact enregistré à l’Annuaire (in_dgfip_annuaire: true ou pas encore vérifié) : la facture génère un rapport fiscal Flux 1 (facturation électronique B2B domestique).
Contact NON enregistré à l’Annuaire (in_dgfip_annuaire: false) : la facture ne génère pas de rapport fiscal. Cela évite des soumissions Flux 1 invalides pour des destinataires vers lesquels le PPF ne peut pas router.
Contact pas encore vérifié (in_dgfip_annuaire: nil) : B2Brouter est permissif — la facture est traitée normalement et génère un rapport fiscal. La vérification a lieu en arrière-plan de manière asynchrone.
Si tu crées un contact français et envoies immédiatement une facture, la vérification à l’Annuaire peut ne pas encore être terminée. C’est voulu — B2Brouter ne bloque pas la création de facture pendant que la vérification est en attente. Si le contact s’avère non enregistré, les futures factures vers ce contact ne généreront pas de rapport fiscal Flux 1 tant qu’il ne s’enregistre pas auprès d’une PA.
La vérification à l’Annuaire ne s’applique qu’aux contacts domestiques français (country: "fr"). Les contacts non français suivent toujours le chemin d’e-Reporting Flux 10, quel que soit leur statut Annuaire.
Important — les deux entreprises doivent être dans l’Annuaire DGFiP : pour un envoi FR → FR avec un rapport fiscal Flux 1, à la fois l’émetteur et le destinataire doivent être enregistrés à l’Annuaire DGFiP. Si l’un des deux ne l’est pas, le rapport fiscal ne peut pas se compléter et la facture est envoyée sans déclaration fiscale.
Comment vérifier l’enregistrement à l’Annuaire DGFiP :
⚠️ Le site annuaire-entreprises.data.gouv.fr sert aux données fiscales générales ; il ne garantit pas l’enregistrement à l’Annuaire DGFiP — ce sont des bases de données différentes.
À partir de septembre 2026, ce comportement permissif cessera de s’appliquer : les déclarations fiscales échoueront simplement si l’identifiant n’est pas listé comme activable DGFiP, même si le SIREN/SIRET est valide.
Une fois ton entreprise onboardée et le Tax Report Setting DGFiP activé, la création de factures fonctionne via l’API de facturation standard. B2Brouter gère automatiquement toutes les exigences spécifiques à la France : génération du rapport fiscal, formatage UBL/CII/Factur-X et transmission au PPF via le Flux 1.
Utilise send_after_import: true pour créer et transmettre en une seule étape. Mets-le à false si tu veux d’abord créer la facture et la revoir avant l’envoi — dans ce cas, la facture reste à l’état new jusqu’à ce que tu déclenches la transmission via un appel séparé ou via l’interface B2Brouter.
Date de la facture : pour les comptes avec un Tax Report Setting DGFiP actif, la date de la facture ne peut pas être une date future. Une date future renvoie HTTP 422 (« Only invoices with today’s date are allowed »). Les dates dans les exemples ci-dessous sont indicatives ; remplace-les par la date du jour lors de tes tests.
Numéro de facture : le number de la facture est limité à 20 caractères maximum. Un numéro plus long est rejeté avec HTTP 422 (number trop long).
Facturation séquentielle : l’API traite une facture par requête. Pour des scénarios en masse ou par lot, parcours ta liste de factures et appelle l’endpoint pour chaque document. L’API prend en charge les requêtes concurrentes — tu peux paralléliser plusieurs POST sans attendre chaque réponse avant de démarrer la suivante.
Le tableau tax_report_ids dans la réponse contient l’ID du rapport fiscal généré. Utilise-le pour suivre le cycle de vie de la soumission (voir Vérifier le statut d’un rapport fiscal).
Trois champs de paiement sont obligatoires pour les factures électroniques B2B françaises (IssuedInvoice). Fournis-les comme champs API directs :
Champ
Champ DGFiP
Description
Obligatoire
remittance_information
PMD
Référence de paiement et mentions légales (immatriculation de l’entreprise, capital social, RCS)
Oui — B2B domestique et transfrontalier
payment_method_text
PMT
Description textuelle du mode de paiement
Oui — B2B domestique et transfrontalier
payment_terms
AAB
Date d’échéance, pénalités de retard, conditions d’escompte
Oui — B2B domestique et transfrontalier
bank_account_id
—
Id du compte bancaire associé à ton entreprise B2Brouter. Requis quand payment_method est un virement bancaire (code 4)
Oui, pour les paiements par virement
Si un champ obligatoire manque, la requête renvoie HTTP 422 avec des messages d’erreur explicites pour chaque champ absent. Ce ne sont pas des erreurs silencieuses — la facture n’est jamais créée. Corrige les champs manquants et resoumets.
Compte bancaire : crée d’abord le compte bancaire associé à ton entreprise (depuis l’interface web ou via API), et référence son id dans la facture avec bank_account_id. Le compte bancaire contient l’IBAN et le BIC et en est la source canonique — ne les passe pas en texte libre dans payment_method_text.
Factures B2C (IssuedSimplifiedInvoice) : ces champs ne sont pas requis.
Import depuis d’autres formats (UBL, CII, Factur-X) : pour ces intégrations, utilise le champ extra_info avec des balises structurées :
#PMD# FA-2026-0048 — Exemplar SAS, RCS Paris 123 456 789
Quand une ligne a category: "E" (exonérée de TVA), tu dois aussi fournir un comment avec le code d’exonération VATEX-FR-CGI261-* applicable (DGFiP BT-121) :
⚠️ Blocage silencieux : si comment est omis sur une ligne de catégorie E, la facture est créée (HTTP 200) mais jamais transmise au PPF. La réponse contiendra un tableau errors non vide — vérifie-le même sur les réponses réussies.
Codes d’exonération de TVA DGFiP (BT-121)
Code
Référence légale
Catégorie fiscale
Description
VATEX-FR-FRANCHISE
Art. 293 B CGI
Z (taux zéro)
Franchise en base de TVA
VATEX-FR-CNWVAT
—
E (exonéré)
Avoir net de taxe — avoir sans TVA (le fournisseur renonce à l’ajustement de TVA). Avoirs uniquement (261/381/396, règle G6.21)
VATEX-FR-AE
—
E (exonéré)
Autoliquidation
VATEX-FR-CGI261-1
Art. 261-1° CGI
E (exonéré)
Soins et services médicaux
VATEX-FR-CGI261-2
Art. 261-2° CGI
E (exonéré)
Services paramédicaux
VATEX-FR-CGI261-3
Art. 261-3° CGI
E (exonéré)
Enseignement scolaire, universitaire et formation professionnelle
VATEX-EU-F / -I / -J
—
E (exonéré)
Régime de la marge (margin scheme)
Codes d’exonération au niveau UE : en plus des codes nationaux VATEX-FR-* ci-dessus, la DGFiP accepte aussi la liste de codes VATEX-EU-* (extensions UNCL5305 / EN16931). Le régime de la marge utilise VATEX-EU-F, VATEX-EU-I ou VATEX-EU-J sur une ligne de catégorie E. Fournis le code applicable dans le comment de la ligne.
Les entreprises opérant sous le régime de la franchise en base de TVA sont à taux zéro (catégorie fiscale Z), pas exonérées (catégorie E). Pour les factures en franchise, définis percent: 0.0 et category: "E" avec comment: "VATEX-FR-FRANCHISE" sur chaque ligne de taxe — B2Brouter transcode automatiquement la catégorie en Z :
Certaines opérations sont hors du champ de la TVA et doivent porter la catégorie fiscale O avec percent: 0.0, pas la catégorie E (exonéré) ou Z (taux zéro). Deux cas courants :
Détaxe (opérations hors champ de la TVA) : la ligne ne porte aucune TVA.
Débours (frais remboursables avancés pour le compte du client) : répercutés sans TVA.
{
"taxes_attributes":[
{"name":"TVA","percent":0.0,"category":"O"}
]
}
Le rapport fiscal Flux 1 synthétise automatiquement le TaxSubtotal de catégorie O correspondant. La catégorie NS est aussi acceptée et transcodée en O.
Champs hérités : dans les versions d’API antérieures à 2026-04-20, un avoir était exprimé avec is_amend: true + amended_number + amended_date au lieu de invoice_references. Ces champs restent acceptés dans ces versions pour compatibilité ascendante, mais sont désormais hérités : utilise invoice_references pour les nouvelles intégrations.
Le code de procédure détermine le cadre de flux du PPF. B2Brouter l’assigne automatiquement selon le type_operation du Tax Report Setting et les caractéristiques de la facture.
Code de procédure
Type d’opération
Description
S1
Services
Facture standard pour services
B1
Biens
Facture standard pour biens
M1
Mixte
Facture standard pour opérations mixtes
S2
Services
Facture payée pour services
B2
Biens
Facture payée pour biens
M2
Mixte
Facture payée pour opérations mixtes
S4
Services
Facture avec acomptes (services)
B4
Biens
Facture avec acomptes (biens)
M4
Mixte
Facture avec acomptes (mixte)
S7
Services
Correction d’une facture enregistrée (services)
B7
Biens
Correction d’une facture enregistrée (biens)
Pas de cadre « M » dans le Flux 1 : bien que type_operation accepte "mixed", le rapport fiscal Flux 1 ne porte jamais de code de procédure de série M. Une facture mixte résout vers le code services correspondant (S1/S2/S4/S7) et ne déclare que ses ventilations de services. Les lignes M ci-dessus sont listées pour référence mais ne sont pas produites par le Flux 1.
La France utilise un modèle en Y / à 5 coins, pas un dédouanement (clearance). La facture est transmise à l’acheteur, qu’un rapport fiscal Flux 1 soit enregistré ou non ; le PPF ne dédouane pas les factures avant qu’elles n’atteignent l’acheteur. La Facture et le Rapport fiscal sont des cycles de vie séparés qui ne coïncident qu’à la livraison du Flux 1. Une erreur de rapport fiscal n’annule pas une facture déjà parvenue à l’acheteur.
La facture a été créée et est en file d’attente pour la transmission au PPF.
sent
200 — Déposée
La facture a été déposée avec succès au PPF.
registered
202 — Reçue
Le PPF a validé et transmis la facture à l’acheteur.
accepted
205 — Approuvée
L’acheteur a approuvé la facture.
refused
210 — Refusée
L’acheteur a rejeté la facture.
paid
212 — Encaissée
Le paiement de la facture a été confirmé.
error
—
Une erreur s’est produite pendant la transmission ou la validation PPF. Le champ errors dans la réponse de la facture contient le motif de rejet du PPF. Si la facture a été rejetée avant enregistrement (état sending ou sent), supprime-la, corrige le problème et soumets-en une nouvelle ; les factures en erreur ne peuvent pas être retransmises directement. Une facture enregistrée (CDV 202 ou ultérieur) ne peut pas être supprimée et resoumise : elle est déjà dans le cycle de vie de l’acheteur. Corrige-la avec un avoir ou une correction (code de procédure S7/B7), ou annule-la.
Configure des endpoints de webhook dans l’interface B2Brouter sous Paramètres → Webhooks. Une fois configuré, B2Brouter envoie une requête HTTP POST à ton endpoint chaque fois que la facture atteint un nouvel état.
Une fois qu’une facture atteint l’état sent, la réponse de GET /invoices/{id} inclut un champ download_legal_url. Utilise-le pour télécharger le document de facture transmis :
Comme alternative en une étape, tu peux appeler directement GET /invoices/{id}/as/legal, sans d’abord récupérer download_legal_url depuis le payload de la facture. Il renvoie le document légal archivé tel que stocké et ne génère pas de transaction facturable — voir Télécharger des factures et Transaction : View_as.
Encaissée est le dernier état du cycle CDV d’une facture B2B française, juste après l’approbation de l’acheteur. Il indique que le paiement a été confirmé (voir la correspondance complète des CDV dans le tableau États de la facture).
B2Brouter propage la confirmation de paiement au PPF via l’un des deux chemins, selon la nature de la facture :
Les paiements partiels sont enregistrés avec l’endpoint POST /accounts/{ACCOUNT_ID}/payments, en passant amount et invoice_id. Répète l’appel pour chaque paiement que tu reçois ; une fois que la somme des montants enregistrés couvre le total de la facture, celle-ci passe automatiquement à paid.
Nécessite X-B2B-API-Version: 2026-03-02 ou une version ultérieure.
Pour un paiement unique et complet, tu peux aussi appeler directement mark_as avec state: "paid" (voir Marquer une facture comme payée via l’API) ; pas besoin de passer d’abord par POST /accounts/{ACCOUNT_ID}/payments.
Alternativement, gère les paiements depuis l’application web B2Brouter : ouvre la facture → Créer un paiement → saisis le montant payé.
Le Flux 10 couvre les transactions hors du champ de l’obligation de facturation électronique B2B domestique qui doivent tout de même être déclarées à la DGFiP. B2Brouter gère le Flux 10 automatiquement.
Ventes à des particuliers non assujettis à la TVA en France. Utilise "type": "IssuedSimplifiedInvoice". Le contact_id et les champs de paiement ne sont pas requis pour les factures B2C.
Transactions transfrontalières (B2B intra-UE et extra-UE)
Les ventes à, ou achats auprès d’entreprises établies hors de France doivent être déclarés via le Flux 10. Utilise le type standard IssuedInvoice ou ReceivedInvoice et définis le country de la contrepartie sur la valeur non "fr" pertinente. B2Brouter détecte automatiquement la nature transfrontalière.
Territoires français d’outre-mer : les départements DROM Guadeloupe (gp), Martinique (mq) et La Réunion (re) sont traités comme France domestique. Les factures vers des contacts qui s’y trouvent génèrent un rapport fiscal Flux 1 et portent IdentificationCode FR, exactement comme la France métropolitaine. Les autres territoires d’outre-mer (Guyane gf, Mayotte yt, Polynésie française pf, Nouvelle-Calédonie nc, TAAF tf, Saint-Pierre-et-Miquelon pm) sont hors du territoire de TVA français et suivent le chemin d’e-Reporting Flux 10.
B2Brouter regroupe les rapports fiscaux Flux 10 en Ledgers envoyés au PPF. La fréquence d’envoi n’est pas toujours quotidienne : elle dépend du vat_regime configuré sur le Tax Report Setting (voir Champs des paramètres de rapport fiscal DGFiP), par décade ou mensuel selon le régime, ou bimestriel pour franchise_en_base. En staging, les ledgers sont déposés quotidiennement pour faciliter les tests ; en production, ils suivent la périodicité réelle du régime. Tu peux identifier les rapports fiscaux Flux 10 par un ledger_id non nul dans la réponse du rapport fiscal.
Chaque ledger est identifié par deux dimensions internes :
Rôle DGFiP (SE ou BY) :
SE (Seller / émission) — pour les ventes que tu émets.
BY (Buyer / réception) — pour les achats intracommunautaires que tu déclares en tant qu’acheteur.
Mode (transactions ou payments) :
transactions — ledgers de factures (codes de procédure S1 / B1 / M1) — type de document xml.ledger.dgfip.transactions.
payments — ledgers de paiements (codes de procédure S2 / B2 / M2, la TVA sur services s’accumule à l’encaissement) — type de document xml.ledger.dgfip.payments.
La combinaison des rôles et des modes produit jusqu’à 3 ledgers par compte et période de déclaration :
Ledger
Rôle
Mode
Contenu
A — Émission
SE
transactions
Factures émises (B2C et B2B transfrontalier)
B — Réception
BY
transactions
Achats intracommunautaires / extra-UE déclarés en tant qu’acheteur
La paire (BY, payments) n’existe pas : l’information de paiement pour tes achats est générée par le vendeur de son côté ; tu ne la déclares pas.
Chaque rapport fiscal est lié à un seul ledger_id (il ne peut pas appartenir à plusieurs ledgers à la fois). Le regroupement se fait par compte + période de déclaration + (rôle, mode) sous un verrou pour éviter les doublons.
En tant qu’entreprise française enregistrée à l’Annuaire avec un transport Peppol 0225, tu reçois automatiquement les factures électroniques d’autres plateformes françaises ou connectées à Peppol.
