A partir del setembre de 2026, totes les empreses franceses hauran d’encaminar les seves factures i dades d’IVA a través d’una plataforma certificada. B2Brouter ho simplifica: tu envies les dades de la factura amb una crida REST API, i B2Brouter s’encarrega del registre al PPF, la generació del document (UBL/CII/Factur-X), l’encaminament cap als teus clients i la declaració fiscal a la DGFiP, tot des d’una sola integració.
B2Brouter és una Plateforme Agréée (PA) certificada per a la reforma francesa de facturació electrònica de la DGFiP. Connecta’t via REST API i B2Brouter gestionarà per tu tota la capa de compliance:
Què fa B2Brouter per tu
Detalls
Registre al PPF
Publica automàticament el teu SIREN/SIRET a l’Annuaire quan actives el servei
Flux 1 — facturació electrònica B2B
Genera UBL/CII/Factur-X, transmet al PPF i encaminа a la plataforma del comprador
Flux 6 — cicle de vida de la factura
Gestiona els missatges d’estat CDAR (Déposée, Reçue, Approuvée, Refusée, Encaissée)
Flux 10 — e-Reporting
Agrega operacions B2C i B2B transfrontereres (intra-UE i extra-UE) en Ledgers diaris enviats al PPF
Recepció Peppol 0225
Rep factures de qualsevol plataforma francesa o connectada a Peppol
Generació de documents
Tu envies dades de factura en JSON i B2Brouter genera el document UBL/CII/Factur-X compliant i el transmet al PPF. No cal que generis XML pel teu compte
Formats d’entrada
JSON REST API, Factur-X PDF/A-3 (amb CII XML incrustat), UBL 2.1 XML, CII XML
Arxiu legal
Tots els documents transmesos (factures, tax reports, missatges CDAR) s’emmagatzemen a B2Brouter durant el període legal obligatori de 10 anys. No cal cap infraestructura addicional al teu costat
Context normatiu: La reforma francesa de facturació electrònica estableix que totes les empreses franceses han d’utilitzar una Plateforme Agréée (PA) certificada o el PPF (Portail Public de Facturation) de l’Estat per transmetre factures i declarar dades d’IVA a la DGFiP a partir del setembre de 2026. Com a PA certificada, B2Brouter gestiona completament la connexió amb el PPF en nom teu: sense SFTP, sense certificats electrònics i sense cap integració directa amb el PPF.
Hi ha dos casos d’ús principals per integrar-se amb B2Brouter per a la facturació electrònica a França:
eDocExchange: per a empreses o grups d’empreses que integren directament el seu programari de gestió (ERP, plataforma comptable) amb B2Brouter. El procés d’onboarding (creació del compte, configuració de Tax Report Settings) normalment es fa una vegada per empresa des de la interfície web. L’operativa del dia a dia, com emetre factures i seguir-ne el cicle de vida, es fa via API. Per afegir més comptes d’empresa al teu grup d’integració, només cal seguir el mateix assistent d’onboarding des del mateix usuari de B2Brouter; no cal cap crida API separada.
eDocSync: per a vendors de programari i proveïdors ERP que volen oferir compliment DGFiP als seus clients des del seu propi producte. És el model white-label / embedded / marque blanche de B2Brouter: B2Brouter opera completament en segon pla, els clients finals només interactuen amb la interfície del vendor i no saben que B2Brouter hi és al darrere. El vendor és responsable del provisionament de comptes, l’enviament de factures i el seguiment del cicle de vida via l’API de B2Brouter. Els clients finals no necessiten login ni subscripció a B2Brouter.
Per a eDocSync, el volum de provisionament de comptes determina el pla adequat:
Poques empreses (model reseller): afegeix cada empresa client com a compte dins del teu grup d’integració de B2Brouter des de la interfície web, seguint l’assistent estàndard. Funciona bé per a desenes d’empreses i comparteix una única API key.
100+ empreses: contacta amb el nostre equip comercial o obre un ticket de suport per parlar d’un pla eDocSync dedicat amb provisionament massiu.
En tots dos casos, totes les funcionalitats de compliance específiques de França (registre a l’Annuaire, transmissió Flux 1/6/10, cicle de vida CDAR) funcionen igual.
B2Brouter és una Plateforme Agréée: t’integres amb B2Brouter; no és un relay ni un connector cap a una altra PA. Si el teu SIREN ja està registrat amb una altra PA, activar el Tax Report Setting sobre el compte SIREN (pas 2) transfereix automàticament l’entrada de l’Annuaire a B2Brouter. Per portar només un establiment i conservar aquell registre existent, vegeu l’Escenari 2 a Estructura del compte. No pots utilitzar B2Brouter com a passarel·la per enviar factures sota la certificació d’una altra PA.
Encaminament a destinataris d’altres PA: quan el comprador està registrat amb una PA diferent, B2Brouter encamina la factura utilitzant el model estàndard Peppol de quatre cantonades (C2 → C3): el punt d’accés Peppol de B2Brouter (C2) consulta l’adreça Peppol del destinatari a l’Annuaire i entrega el document al punt d’accés del comprador (C3), independentment de quina PA utilitzi. No cal cap configuració extra al teu costat.
Entorns de prova: utilitza sandbox per a les primeres proves d’API i validació de payloads. Els enviaments DGFiP es simulen al sandbox i no cal cap SIRET fictici. Per a proves completes end-to-end amb l’entorn QAS (qualification) de la DGFiP, utilitza l’entorn staging de B2Brouter, tal com s’explica a continuació.
No barregis entorns. Producció utilitza números SIREN/SIRET reals i connecta amb l’Annuaire de producció de la DGFiP. Staging utilitza identificadors ficticis de prova i connecta amb l’entorn QAS de la DGFiP. API keys, comptes i contactes no es comparteixen entre entorns.
Registra’t a app.b2brouter.net per començar una integració en producció. Quan activis el DGFiP Tax Report Setting, el SIREN/SIRET de la teva empresa es publicarà a l’Annuaire real del PPF i serà visible per qualsevol plataforma de l’ecosistema francès de facturació electrònica.
Aquesta opció està pensada per a factures B2B reals a partir del setembre de 2026. Mentrestant, la DGFiP netejarà els registres del període QAS abans que la reforma entri en vigor, de manera que les factures que enviïs durant el pilot no generaran obligacions de compliment. És el millor punt de partida si ja has escollit B2Brouter i vols provar la integració completa amb dades reals de la teva empresa.
Registra’t a app-staging.b2brouter.net per utilitzar l’entorn de proves de B2Brouter, connectat a l’entorn QAS de la DGFiP.
És la millor opció si:
Estàs avaluant diverses plataformes abans de decidir-te
El teu SIREN/SIRET ja està publicat a l’Annuaire amb una altra PA i activar B2Brouter en producció en transferiria l’entrada
Prefereixes no associar l’identificador de la teva empresa amb activitat de proves
L’entorn staging és autoprovisionat: un cop tinguis identificadors de prova, pots començar proves end-to-end en menys de 24 hores.
Validació del SIRET a staging: a l’entorn staging, qualsevol número vàlid de 14 dígits s’accepta com a SIRET sense validar el checksum. Els identificadors ficticis del CSV QAS de Chorus Pro ja estan preregistrats a l’annuaire QAS de la DGFiP i funcionen end-to-end. En producció sí que es valida el format i checksum del SIRET.
Important: la DGFiP no permet SIREN ni SIRET reals al seu entorn QAS. Has d’utilitzar identificadors ficticis de prova. Pots obtenir-los tu mateix mitjançant el portal QAS de Chorus Pro (gratuït, procés d’uns 5 minuts) o demanar-ne un conjunt preassignat obrint un ticket de suport a l’app de staging.
Un compte per SIREN: B2Brouter crea un compte per SIREN i la clau del VAT number es deriva del SIREN. Si proporciones un SIRET, se n’extreu el SIREN. Dos SIRET diferents de la mateixa empresa (mateix SIREN) es resolen com un mateix compte. Si la teva empresa opera des de diversos establiments (SIRET diferents), aquests es modelen com a unitats organitzatives dins del mateix compte de B2Brouter, no com a comptes separats. Contacta amb Support si necessites configurar facturació multiestabliment. Tingues-ho present quan seleccionis files del CSV: tria SIRET amb SIREN diferents (els primers 9 dígits) per a cada empresa independent que vulguis provar.
Obtenir identificadors de prova via Chorus Pro QAS
El portal Chorus Pro QAS et permet generar un “Matelas de données” (joc de dades), és a dir, un fitxer CSV amb identificadors ficticis SIREN/SIRET preregistrats a l’entorn de proves de la DGFiP. Segueix aquests passos:
Pots utilitzar una adreça de correu temporal, com ara temp-mail.io.
Pots posar qualsevol nom; aquest compte només serveix per obtenir identificadors de prova.
Revisa la teva safata d’entrada per trobar el correu “Initialisation de mot de passe Chorus Pro” i defineix la teva contrasenya. L’enllaç és vàlid durant 60 minuts.
Inicia sessió → ves a Domaines → Matelas de données → fes clic a Générer un matelas de données i confirma.
Ves a Consultation du matelas de données. Espera fins que tots dos estats mostrin “Disponible”:
Statut pour Chorus Pro: Disponible
Statut pour l’annuaire de facturation PPF: Disponible
La generació acostuma a trigar pocs minuts. Refresca la pàgina per comprovar-ho.
Fes clic a “Générer et télécharger le fichier CSV du matelas structures et utilisateurs” per descarregar els teus identificadors de prova.
El CSV conté diversos números ficticis SIREN/SIRET en files etiquetades com “Privé” i “Public”. Utilitza només les files de la secció “Privé” per als teus comptes de prova. Les entitats del sector públic (SIREN 'Public') són rebutjades per l’annuaire QAS de la DGFiP; si intentes activar l’e-Reporting en un compte del sector públic rebràs un HTTP 422. És el comportament correcte: les entitats públiques utilitzen Chorus Pro directament, no una PA.
Utilitza un SIREN del sector privat per al compte emissor i un altre per al contacte de prova.
Crea el compte de la teva empresa utilitzant un SIREN del CSV (vegeu Pas 1).
Subscriu-te a un pla eDocExchange. Les subscripcions a staging són simulades i no tenen cost.
Activa els DGFiP Tax Report Settings (vegeu Pas 2).
⚠️ Després d’activar el DGFiP Tax Report Setting, el registre de la teva empresa a l’Annuaire pot trigar fins a 24 hores a propagar-se, tant a staging com a producció. És una limitació de la infraestructura DGFiP, no un retard de B2Brouter. No podràs enviar factures fins l’endemà.
L’endemà, crea un contacte de prova amb un segon SIREN del CSV (vegeu Pas 3).
L’autenticació utilitza una API key estàtica enviada a la capçalera HTTP X-B2B-API-Key. No hi ha cap flux OAuth2: genera la teva API key des de la interfície de B2Brouter a Settings → API Keys. Guarda-la de manera confidencial i no la incloguis mai en codi client-side. A més, estableix X-B2B-API-Version a cada petició.
Base URL: tots els exemples següents utilitzen https://api-staging.b2brouter.net. Per a producció, substitueix-lo per https://api.b2brouter.net.
Estructura del compte: matriu i unitats organitzatives
Una empresa francesa amb diversos establiments o serveis es modela a B2Brouter com un compte matriu (l’entitat principal) i, opcionalment, una o més unitats organitzatives (UOs) penjades del matriu. La factura sempre s’emet des d’una matriu o d’una UO concreta, però el grup d’integració és comú.
El compte matriu sempre és a nivell de SIREN (cin_scheme="0002", l’entitat legal). Un SIRET no és mai matriu: crear una matriu francesa amb cin_scheme="0009" retorna 422 parameter_matriu_must_be_siren. Els establiments (SIRET) i serveis es modelen sempre com a UOs sota aquest matriu SIREN.
El que canvia segons la teva situació no és el nivell del matriu sinó on actives el Tax Report Setting de la DGFiP:
Si el SIREN encara no està registrat a cap altra Plateforme Agréée (PA): activa el Tax Report Setting sobre el matriu SIREN. Les UOs sense Tax Report Setting propi declaren a través del matriu automàticament. És el flux estàndard (Escenari 1).
Si el SIREN ja està registrat a una altra PA i només vols portar a B2Brouter un establiment concret: mantén el matriu a SIREN però no activis el Tax Report Setting sobre ell (transvasaria l’entrada existent de l’Annuaire). En comptes d’això, crea l’establiment com a UO SIRET i activa el Tax Report Setting sobre aquella UO, de manera que el registre existent del SIREN quedi intacte (Escenari 2).
Aquesta decisió determina on s’activa la declaració, no l’identificador del matriu (que sempre és SIREN). Si dubtes si el teu SIREN ja està registrat, consulta primer l’Annuaire amb el Directory lookup.
Comptes legacy (normalització): fins al juny de 2026, la plataforma permetia crear un compte matriu amb un SIRET. Si tens comptes creats així, cal normalitzar-los: substituir l’identificador del matriu pel SIREN (cin_scheme="0002", cin_value = el SIREN de 9 dígits) i crear el SIRET corresponent com a UO sota aquell matriu SIREN.
A B2Brouter, un compte o contacte francès es defineix amb un identificador principal (cin_scheme + cin_value) i, opcionalment, un sub-identificador (routing_codes.cin1_scheme + routing_codes.cin1_value) quan cal apuntar a un servei concret dins d’un establiment.
Identificador principal del compte / UO (cin_scheme + cin_value):
cin_scheme
Identificador
Format
Exemple
0002 (2)
SIREN — entitat legal
9 dígits + Luhn
123456789
0009 (9)
SIRET — establiment
14 dígits (SIREN + 5 dígits) + Luhn
12345678900012
8040
Suffix — UO sense SIRET propi
Alfanumèric [A-Za-z0-9_\-\/]+
SUF01, ADMIN
Sub-identificador (routing code) — només per a UOs SIRET amb diversos serveis interns:
EAS Peppol del participant FR: l’identificador electrònic a la xarxa Peppol és sempre 0225 (FRCTC Electronic Address). Els schemes 224 (Code Routage) i 8040 (Suffix) són sub-identificadors interns del directori i no es publiquen com a EAS Peppol propi.
Suffix vs Code Routage — El Suffix (8040) és el cin_scheme principal d’una UO sense SIRET propi. El Code Routage (224), en canvi, sempre va a routing_codes.cin1_scheme="224" d’una UO amb SIRET — mai com a cin_scheme principal.
Important: un SIRET sol (sense SIREN davant) no és vàlid com a identificador complet publicat. Un SIRET viu sempre en una UO sota el matriu SIREN; la composició publicada és SIREN_SIRET, on el SIREN prové del compte matriu.
Veure els 4 formats d'identificador final a l'Annuaire
Composició Annuaire
Què representa
SIREN
Entitat sencera (matriu)
SIREN_SIRET
Establiment (Cas 1 / Cas 4)
SIREN_SIRET_<CR>
Servei dins un establiment (Cas 2 / Cas 5)
SIREN_<SUFFIX>
UO sense SIRET propi (Cas 3 / Cas 6)
Cap d’aquestes composicions és issue-only per si mateixa — tampoc la fila SIREN sola. Que una adreça també rebi factures (que es publiqui un transport 0225 per a ella) depèn únicament de la flag issue_only d’aquell Tax Report Setting, no de la composició utilitzada. Vegeu la nota sobre issue_only a l’Escenari 3 més avall.
Per veure els camps API exactes que generen cada format, consulta la taula Casos i topologies més avall.
L’estructura depèn de dos factors: si el SIREN està lliure d’altres PA, i si vols emetre o també rebre. Tres escenaris cobreixen totes les configuracions habituals.
Si el SIREN ja està registrat a una altra PA i vols portar a B2Brouter un establiment concret sense alterar aquell registre existent, el matriu segueix sent a nivell de SIREN (un SIRET no és mai matriu). La diferència respecte a l’Escenari 1 és només on s’activa el Tax Report Setting: no sobre el matriu SIREN (que transvasaria l’entrada existent de l’Annuaire), sinó sobre la UO SIRET. La UO publica de manera independent (vegeu unitats organitzatives amb Tax Report Setting propi), de manera que el registre del SIREN amb l’altra PA queda intacte.
La topologia és la mateixa que els Casos 1 i 2 (matriu SIREN + UO SIRET, opcionalment amb un servei per Code Routage):
Cas 4 (C Établissement-only) — Una única UO SIRET porta el Tax Report Setting; el matriu SIREN no en té cap.
Cas 5 (C + Service) — Com el Cas 4, més serveis interns d’aquell establiment adreçats per un Code Routage (routing_codes.cin1_scheme="224" a la UO SIRET).
Escenari 3 — Issue-only (només emissió, sense publicar transport 0225)
Si el SIREN ja està a una altra PA i només vols emetre des de B2Brouter (sense publicar un transport 0225 que entraria en conflicte amb el de l’altra PA), usa la flag issue_only=true al compte matriu. B2Brouter no registrarà cap transport 0225 al PPF.
Cas pur — només issue_only=true (sense suffix):
cin_scheme="0002" (SIREN) + issue_only=true
Sense UOs, sense suffix
Adreçament Annuaire: SIREN (resta gestionat per l’altra PA)
Sub-cas amb suffix: quan a més cal adreçament intern SIREN_<SUFFIX>, crea el suffix com a Suffix UO (Cas 6), no a la matriu:
parent_id = matriu SIREN, cin_scheme="8040", cin_value="<SUFFIX>", amb issue_only=true en aquella UO
Un suffix (com qualsevol SIRET o Code Routage) és sempre una UO, mai col·locat a la matriu mateixa
Adreçament Annuaire: SIREN_<SUFFIX>
issue_only és independent del suffix: pots posar issue_only=true a la matriu SIREN sense cap suffix (només emissió). Un suffix, quan en cal un, és una Suffix UO a part (Cas 6).
Un suffix no vol dir issue-only. El suffix (SIREN_<SUFFIX>) és només un detall d’adreçament — que aquella adreça també rebi factures depèn exclusivament d’issue_only, no de la presència del suffix:
issue_only=true + suffix → es crea la Ligne SIREN_<SUFFIX> a l’Annuaire, però no es publica transport 0225 per a ella → només emissió, sense recepció. Fes servir això quan la recepció d’aquella adreça ja la gestiona una altra PA.
Sense issue_only (per defecte) + suffix → sí es publica el transport 0225 per a SIREN_<SUFFIX> → emissió i recepció a la mateixa adreça amb suffix, igual que qualsevol altra adreça.
Si vols emetre i rebre a una adreça amb suffix, no posis issue_only en aquell Tax Report Setting.
Els contactes a B2Brouter (clients i proveïdors francesos) segueixen exactament la mateixa jerarquia (matriu + UOs) i els mateixos cin_scheme (SIREN / SIRET / Code Routage / Suffix). Gestiona els contactes exactament igual que els teus comptes: el contacte matriu ha de ser el SIREN, i qualsevol SIRET, Code Routage o Suffix ha de ser una UO. Encara que el sistema admet tècnicament un contacte matriu a un altre nivell, fer-ho pot provocar trencaments quan més endavant afegeixis UOs del mateix client, així que mantén sempre el SIREN com a matriu.
Regla d’or per a contactes: el matriu és sempre el SIREN; modela qualsevol SIRET, Code Routage o Suffix com a UOs, igual que amb els comptes.
Amb el matriu a SIREN, els casos dels 3 escenaris són aplicables a contactes (les UOs poden ser SIRET, Code Routage o Suffix segons l’estructura del client).
Per crear una UO de contacte, fes servir el mateix endpoint que per a un contacte normal — POST /accounts/{ACCOUNT_ID}/contacts — afegint parent_id apuntant al contacte matriu. tin_value i tin_scheme són heretats del matriu i no es poden divergir.
Contactes legacy (normalització): igual que amb els comptes, fins al juny de 2026 un contacte es podia crear amb un SIRET com a matriu. Si tens contactes creats així, cal normalitzar-los: substituir l’identificador del contacte matriu pel SIREN (cin_scheme="0002") i crear el SIRET corresponent com a UO sota aquell contacte SIREN.
Pas 1: recupera o crea el compte de la teva empresa
Recordatori d’estructura: el compte matriu és semprecin_scheme="0002" (SIREN) — vegeu Estructura del compte. El que canvia entre escenaris no és l’identificador del matriu sinó on actives el Tax Report Setting (sobre el matriu SIREN a l’Escenari 1, sobre la UO SIRET a l’Escenari 2). Els establiments es creen sempre com a UOs al Pas 1b.
Si ja tens un compte de B2Brouter per a la teva empresa, recupera el seu id amb l’endpoint List Accounts i salta’t el pas de creació.
Si encara no l’has creat, utilitza l’endpoint Create Account (camí eDocSync/API) o l’assistent d’onboarding de la interfície web (camí eDocExchange). Tots dos produeixen el mateix resultat.
En crear un compte d’empresa francesa:
cin_scheme: sempre "0002" (SIREN, 9 dígits) per al compte matriu. Un SIRET no s’accepta com a identificador de matriu: crear una matriu francesa amb cin_scheme "0009" retorna 422 parameter_matriu_must_be_siren. Els establiments (SIRET) es creen com a unitats organitzatives sota el matriu SIREN (vegeu el Pas 1b).
cin_value: el SIREN de la teva empresa (9 dígits).
tin_value: número d’IVA francès en format FR{kk}{siren}, on kk és el checksum de dos dígits (p.ex. FR32123456789). És obligatori per a la facturació DGFiP; no cal que calculis el checksum tu. Si només informes el SIREN o només el número d’IVA, B2Brouter deriva l’altre automàticament quan actives el DGFiP Tax Report Setting. Aquesta derivació només passa en activar: si no informes el número d’IVA ni actives el Tax Report Setting, queda buit i la facturació fallarà, així que activa el setting per evitar problemes.
Si l’estructura de la teva empresa requereix UOs (vegeu casos 1, 2, 4, 5 i 6 a Topologies), crea cada UO amb POST /accounts afegint parent_id (l’ID del compte matriu creat al Pas 1a).
Aquesta funcionalitat requereix una versió de l’API que admeti UOs amb parent_id. Consulta el changelog de l’API per saber-ne la versió mínima.
Restriccions:
parent_id és obligatori per crear una UO.
Una UO no pot contenir tin_value ni tin_scheme (els hereta del matriu).
Una UO no pot ser parent d’una altra UO (només un nivell de profunditat).
UO d’establiment que porta el seu propi TRS (Escenari 2, casos 4/5)
Mateixos camps que el cas 1 (o el cas 2 per a un servei): parent_id (matriu SIREN) + cin_scheme="0009" + cin_value=<SIRET> [+ routing_codes.cin1_scheme="224" + routing_codes.cin1_value=<CR> per a un servei]. La diferència és que aquesta UO té el seu propi Tax Report Setting mentre que el matriu SIREN no en té cap.
Camps obligatoris en tots els payloads UO: a banda de parent_id i cin_*, has d’incloure country, email, address, city, postalcode i province. Sense aquests camps, la creació retorna HTTP 422 (“Region/Province/Country can’t be blank”). El tin_value i tin_scheme s’hereten del matriu i no s’han de repetir.
El SIRET d’una UO Établissement comença sempre pels 9 dígits del SIREN matriu (definició INSEE). Si el matriu té SIREN 123456789, els seus SIRETs vàlids tenen la forma 123456789XXXXX.
Exemple — UO de tipus Établissement amb Service opcional (Casos 1 i 2):
Per a un establiment sense Code Routage (Cas 1 pur), omet el bloc routing_codes.
Exemple — UO d’establiment que porta el seu propi Tax Report Setting (Escenari 2, casos 4/5):
La UO es crea exactament com al Cas 1/2 (a sota, una variant de servei amb Code Routage). La diferència a l’Escenari 2 és que després actives un Tax Report Setting sobre aquesta UO (no sobre el matriu SIREN), de manera que el registre existent del SIREN a l’Annuaire amb una altra PA es preserva (vegeu el Pas 2).
La UO porta el SIRET com a cin_scheme="0009" principal i, per a un servei, l’identifica via routing_codes.cin1_value. El Code Routage mai va com a cin_scheme principal. Per a una UO només d’establiment (Cas 4), omet el bloc routing_codes.
Exemple — UO de tipus Suffix (Cas 6):
Finestra del 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 — Unitat Administrativa",
"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"
}
}'
Els casos d’Issue-only (Escenari 3) no es creen com a UO — són el mateix matriu SIREN, definit al Pas 1a amb cin_scheme="0002" (i issue_only=true, més un suffix 8040 opcional). Els casos 4 i 5 (Escenari 2), en canvi, sí que són UOs: un matriu SIREN més una UO SIRET que porta el seu propi Tax Report Setting.
Aquest és el pas clau de l’onboarding. Quan crees un Tax Report Setting amb code: "dgfip", B2Brouter:
Registra la teva empresa a l’Annuaire del PPF: el teu SIREN/SIRET passa a ser visible per a qualsevol plataforma de l’ecosistema francès de facturació electrònica.
Crea un transport Peppol 0225: això permet que la teva empresa rebi factures electròniques de qualsevol plataforma francesa connectada a Peppol.
⚠️ Substitució del transport:
Si el compte sobre el qual actives ja té un transport Peppol, es substituirà pel nou transport 0225 (FRCTC Electronic Address) durant l’activació. Si el SIREN sobre el qual actives estava registrat prèviament amb una altra PA, B2Brouter tancarà l’entrada existent a l’Annuaire i n’obrirà una de nova. Si necessites conservar aquell registre existent, no activis sobre el SIREN; activa sobre una UO SIRET (vegeu “On activar” més avall). Actualitza qualsevol integració existent que faci referència a l’identificador de l’antic transport.
On activar el Tax Report Setting: {ACCOUNT_ID} pot ser el matriu SIREN, una UO SIRET, o tots dos. Cada compte (matriu o UO) que té Tax Report Setting propi es publica a l’Annuaire amb la seva pròpia adreça; una UO sense TRS declara a través del matriu. Tres configuracions:
TRS només al SIREN: l’empresa es publica com a SIREN i els establiments declaren a través seu (cas estàndard, Escenari 1).
TRS al SIREN i a una o més UOs SIRET: l’empresa es publica alhora com a SIREN i com a cada SIREN_SIRET (una adreça d’Annuaire per compte activat), de manera que l’entitat sencera i els establiments concrets són adreçables cadascun.
TRS només a una UO SIRET, no al SIREN: només es publica aquell establiment (SIREN_SIRET); el SIREN no (Escenari 2). Usa-ho quan el SIREN ja està registrat amb una altra PA i vols conservar aquell registre.
El start_date determina quan comença la declaració fiscal. A partir d’aquesta data, les factures que emetis generaran tax reports i es transmetran al PPF.
Quan comença la declaració fiscal. Ha de ser avui o una data futura. Si s’omet, el valor per defecte és demà.
type_operation
string
Sí
Tipus d’operació per defecte per a aquesta empresa: "services", "goods" o "mixed". Determina el codi de procés DGFiP (S1/B1, etc.) utilitzat als tax reports. Tria "mixed" si l’empresa ven tant béns com serveis. En una factura mixta, el tax report del Flux 1 s’emet amb el codi de procés de serveis (S1/S2/S4/S7) i només reporta els breakdowns de serveis; la DGFiP no té cap cadre “M” propi per al Flux 1 (vegeu Codis de procés). Aquest ajust es pot modificar després de l’activació.
naf_code
string
Sí
El codi NAF/APE de l’empresa. És el codi de secció de 2 dígits assignat per l’INSEE que identifica l’activitat econòmica principal de l’empresa. La DGFiP l’utilitza per classificar la declaració fiscal.
enterprise_size
string
Sí
La categoria de mida de l’empresa definida per l’INSEE. Valors admesos: "micro", "pme", "eti" o "ge".
reason_vat_exempt
string
No
Codi per defecte del motiu d’exempció d’IVA per a l’empresa. Per defecte és "VATEX-FR-FRANCHISE".
email
string
No
Correu de contacte per a notificacions fiscals.
auto_generate
boolean
No
Sempre true per a DGFiP per obligació legal. No es pot canviar.
auto_send
boolean
No
Transmet automàticament els tax reports al PPF. Per defecte és true.
enabled
boolean
No
Indica si la configuració està activa. Per defecte és true. El registre a l’Annuaire només es produeix quan és true.
annuaire_only
boolean
No
Quan és true, el compte només es registra a l’Annuaire del PPF per a recepció. No es generen tax reports Flux 1 ni missatges CDAR; enterprise_size i naf_code són opcionals. Per defecte és false. Vegeu Mode reception-only.
Si el registre a l’Annuaire falla, per exemple per SIREN/SIRET invàlid o per una caiguda temporal dels serveis DGFiP, la creació del Tax Report Setting es desfà i es retorna un error. Corregeix el problema i torna-ho a provar.
Si el teu compte només necessita rebre factures electròniques (no emetre’n) — per exemple, una empresa que encara no està obligada a emetre però vol estar registrada a l’Annuaire perquè els seus proveïdors li puguin enviar factures via Peppol — pots activar el DGFiP Tax Report Setting amb annuaire_only: true.
Què activa:
Registra la teva empresa a l’Annuaire del PPF (visible per als emissors).
Crea el transport Peppol 0225 per a la recepció.
Què suprimeix respecte a un activament complet:
No es generen tax reports Flux 1 al moment d’emetre factures.
No s’envien missatges CDAR (cicle Déposée → Reçue → Approuvée…).
Els camps enterprise_size i naf_code no són obligatoris.
Aquest mode és útil per a empreses receptores en fase d’avaluació, o per a entitats que tenen un proveïdor de facturació diferent però volen recepcionar via B2Brouter. Quan vulguis emetre, actualitza el Tax Report Setting a mode complet amb un PATCH (vegeu Tax Report Settings Guide).
Un contacte B2B francès necessita identificadors d’encaminament i identificació fiscal.
Camp
Valor
Finalitat
cin_scheme
"0009" (SIRET) o "0002" (SIREN)
Identificador de l’organització, utilitzat per cercar el destinatari a l’Annuaire
cin_value
SIRET o SIREN
Identificador registrat a l’Annuaire
tin_scheme
9957
Tax ID, codi ISO 6523 per a l’identificador fiscal francès
tin_value
FR{kk}{siren}
Número d’IVA francès que apareix a l’UBL XML
pin_scheme
"0225"
EAS Peppol del participant FR (FRCTC Electronic Address) — obligatori per a contactes francesos
pin_value
Composició Annuaire del destinatari
Identificador Peppol del contacte; segueix la mateixa composició que la matriu a l’Annuaire (SIREN, SIREN_SIRET, SIREN_SIRET_<CR> o SIREN_<SUFFIX> — vegeu Nivells d’identificador)
country
"fr"
Obligatori per a la lògica d’encaminament DGFiP
currency
"EUR"
Moneda per defecte per a les factures d’aquest contacte
transport_type_code
"peppol"
Recomanat per garantir l’entrega via xarxa Peppol
document_type_code
"xml.ubl.invoice.frcius.v1"
Recomanat: format de factura UBL France CIUS
Transport i tipus de document: per a contactes francesos registrats a l’Annuaire, recomanem establir explícitament transport_type_code: "peppol" i document_type_code: "xml.ubl.invoice.frcius.v1". Sense pin_value la creació retorna HTTP 422 (“Peppol Endpoint ID can’t be blank”). Pots verificar abans si un contacte està registrat a l’Annuaire fent servir el Directory lookup o el Peppol Directory oficial.
Contactes a Bèlgica, Alemanya i altres països de la UE: per a factures B2B a empreses no franceses, utilitza l’esquema nacional corresponent i el country adequat. Si el destinatari té un access point Peppol actiu, B2Brouter encaminarà la factura via Peppol BIS 3.0. Per a qualsevol transacció amb un contacte amb country diferent de "fr", es generarà automàticament Flux 10 d’e-Reporting transfronterer.
Contactes amb estructura multinivell: si el teu client té diversos establiments o serveis que cal identificar per separat, crea primer el contacte matriu a nivell SIREN i després afegeix UOs amb parent_id. Vegeu Estructura del compte per a la regla d’or i les topologies aplicables.
Opcional: verifica l’encaminament del destinatari (consulta al directori)
B2Brouter encamina les factures automàticament. Si vols inspeccionar com s’encaminarà un destinatari abans d’enviar, per exemple per confirmar si està registrat a l’Annuaire, utilitza la consulta al directori (Flux 11):
Destinatari registrat i actiu a l’Annuaire del PPF
FR_ASSUJETTI_INACTIVE
Destinatari amb registre fora de vigència o sense PA assignada
FR_ASSUJETTI_UNKNOWN
El PPF no té informació concloent (per exemple, 404)
source
array de "peppol", "annuaire"
Orígens consultats. Si apareixen tots dos, B2Brouter ha trobat el destinatari a ambdós directoris
Aquesta consulta és informativa: B2Brouter ja resol l’encaminament automàticament en crear la factura (vegeu Verificació a l’Annuaire i generació de tax reports). Fes-la servir per inspeccionar abans d’enviar o per pintar l’estat del destinatari a la teva UI.
B2Brouter verifica automàticament si els contactes francesos (country: "fr") estan registrats a l’Annuaire de la DGFiP. Aquesta verificació determina el flux de declaració fiscal:
Contacte registrat a l’Annuaire (in_dgfip_annuaire: true o encara no verificat): la factura genera un tax report de Flux 1.
Contacte NO registrat a l’Annuaire (in_dgfip_annuaire: false): la factura no genera tax report. Això evita enviaments Flux 1 invàlids a destinataris que el PPF no pot encaminar.
Contacte encara no verificat (in_dgfip_annuaire: nil): B2Brouter és permissiu; la factura continua i genera tax report. La verificació es fa de manera asíncrona en segon pla.
Si crees un contacte francès i immediatament hi envies una factura, és possible que la verificació de l’Annuaire encara no hagi acabat. És intencionat: B2Brouter no bloqueja la creació de factures mentre la verificació està pendent. Si després resulta que el contacte no està registrat, les futures factures cap a aquest contacte no generaran tax reports Flux 1 fins que el contacte es registri en una PA.
La comprovació de l’Annuaire només s’aplica a contactes francesos domèstics (country: "fr"). Els contactes no francesos sempre segueixen el camí d’e-Reporting Flux 10 independentment de l’estat de l’Annuaire.
Important — ambdues empreses a l’Annuaire DGFiP: per a un enviament FR → FR amb tax report Flux 1, tant l’emissor com el receptor han d’estar registrats a l’Annuaire de la DGFiP. Si una de les dues no hi és, el tax report no es pot completar i la factura s’envia sense declaració.
⚠️ La web annuaire-entreprises.data.gouv.fr és per a dades fiscals generals; no garanteix la inscripció a l’Annuaire DGFiP — són bases diferents.
A partir de setembre de 2026 aquest comportament permissiu deixarà d’aplicar-se: les declaracions simplement fallaran si l’identificador no consta com a activable a la DGFiP, encara que el SIREN/SIRET sigui vàlid.
Un cop la teva empresa ha completat l’onboarding i el DGFiP Tax Report Setting està activat, la creació de factures funciona mitjançant l’Invoice API estàndard. B2Brouter gestiona automàticament tots els requisits específics de França: generació de tax reports, format UBL/CII/Factur-X i transmissió al PPF via Flux 1.
Utilitza send_after_import: true per crear i transmetre en un sol pas. Estableix-lo a false si vols crear la factura primer i revisar-la abans d’enviar-la; en aquest cas, la factura quedarà en estat new fins que en desencadenis la transmissió amb una crida separada o des de la interfície de B2Brouter.
Data de la factura: per a comptes amb DGFiP Tax Report Setting actiu, la date de la factura no pot ser una data futura. Si es passa una data posterior a avui, l’enviament retorna HTTP 422 (“Only invoices with today’s date are allowed”). Els exemples d’aquesta guia usen dates fictícies; substitueix-les per la data actual quan facis proves.
Número de factura: el number de la factura està limitat a 20 caràcters com a màxim. Un número més llarg es rebutja amb HTTP 422 (number massa llarg).
Facturació seqüencial: l’API processa una factura per petició. En escenaris batch o massius, itera sobre la llista de factures i crida l’endpoint per a cada document. L’API admet peticions concurrents, de manera que pots paral·lelitzar múltiples POSTs.
Tres camps de pagament són obligatoris per a les factures electròniques B2B franceses (IssuedInvoice). Proporciona’ls com a camps directes de l’API:
Camp
Camp DGFiP
Descripció
Obligatori
remittance_information
PMD
Referència de pagament i mencions legals
Sí, per a B2B domèstic i transfronterer
payment_method_text
PMT
Descripció textual del mètode de pagament
Sí, per a B2B domèstic i transfronterer
payment_terms
AAB
Data de venciment, penalitzacions per retard i condicions de descompte
Sí, per a B2B domèstic i transfronterer
bank_account_id
—
Id del compte bancari associat al teu compte de B2Brouter. Obligatori quan payment_method és transferència bancària (codi 4)
Sí, si pagament per transferència
Si falta algun dels camps obligatoris, la petició retorna HTTP 422 amb errors explícits per a cada camp absent. La factura no es crea.
Bank account: crea primer un bank account associat al teu compte (des de la interfície web o via API) i referencia el seu id a la factura amb bank_account_id. El bank account inclou IBAN i BIC i és la font canònica d’aquesta informació — no els passis com a text lliure dins payment_method_text.
Les factures B2C (IssuedSimplifiedInvoice) no requereixen aquests camps.
Importació des d’altres formats (UBL, CII, Factur-X): per a aquestes integracions, utilitza el camp extra_info amb etiquetes estructurades:
#PMD# FA-2026-0048 — Exemplar SAS, RCS Paris 123 456 789
Quan una línia té category: "E" (exempta d’IVA), també has de proporcionar un comment amb el codi d’exempció VATEX-FR-CGI261-* aplicable.
⚠️ Bloqueig silenciós: si s’omet comment en una línia de categoria E, la factura es crea però mai no es transmet al PPF. La resposta contindrà un array errors no buit, així que cal revisar-lo fins i tot en respostes exitoses.
Codis d’exempció d’IVA DGFiP
Codi
Referència legal
Categoria
Descripció
VATEX-FR-FRANCHISE
Art. 293 B CGI
Z
Franchise en base de TVA
VATEX-FR-CNWVAT
—
E
No establert a França
VATEX-FR-AE
—
E
Autoliquidació
VATEX-FR-CGI261-1
Art. 261-1° CGI
E
Cures i serveis mèdics
VATEX-FR-CGI261-2
Art. 261-2° CGI
E
Serveis paramèdics
VATEX-FR-CGI261-3
Art. 261-3° CGI
E
Ensenyament escolar, universitari i formació professional
VATEX-EU-F / -I / -J
—
E
Règim de la marge (margin scheme)
Codis d’exempció de nivell UE: a més dels codis nacionals VATEX-FR-* de dalt, la DGFiP també accepta la llista VATEX-EU-* (extensions UNCL5305 / EN16931). El règim de la marge utilitza VATEX-EU-F, VATEX-EU-I o VATEX-EU-J en una línia de categoria E. Indica el codi aplicable al comment de la línia.
Les empreses sota el règim franchise en base de TVA operen a tipus zero (categoria Z), no com a exemptes (E). Per a aquestes factures, estableix percent: 0.0, category: "E" i comment: "VATEX-FR-FRANCHISE" a cada línia d’impost; B2Brouter transcodificarà automàticament la categoria a Z.
Algunes operacions queden fora del camp d’aplicació de l’IVA i han de portar la categoria O amb percent: 0.0, no la categoria E (exempta) ni Z (tipus zero). Dos casos habituals:
Détaxe (operacions fora del camp de l’IVA): la línia no porta IVA.
Débours (despeses reembossables avançades en nom del client): es traspassen sense IVA.
{
"taxes_attributes":[
{"name":"TVA","percent":0.0,"category":"O"}
]
}
El tax report del Flux 1 sintetitza automàticament el TaxSubtotal de categoria O corresponent. La categoria NS també s’accepta i es transcodifica a O.
Per emetre una nota de crèdit, estableix is_amend: true i referencia la factura original amb amended_number i amended_date. B2Brouter generarà un UBL CreditNote amb codi de tipus 381 i inclourà la referència de facturació.
El codi de procés determina el flux cadre del PPF. B2Brouter l’assigna automàticament segons type_operation del Tax Report Setting i les característiques de la factura.
Codi de procés
Tipus d’operació
Descripció
S1
Services
Factura estàndard de serveis
B1
Goods
Factura estàndard de béns
M1
Mixed
Factura estàndard d’operacions mixtes
S2
Services
Factura pagada de serveis
B2
Goods
Factura pagada de béns
M2
Mixed
Factura pagada d’operacions mixtes
S4
Services
Factura amb bestretes (serveis)
B4
Goods
Factura amb bestretes (béns)
M4
Mixed
Factura amb bestretes (mixt)
S7
Services
Rectificació d’una factura registrada (serveis)
B7
Goods
Rectificació d’una factura registrada (béns)
Cap cadre “M” al Flux 1: encara que type_operation accepta "mixed", el tax report del Flux 1 mai porta un codi de procés de la sèrie M. Una factura mixta es resol amb el codi de serveis corresponent (S1/S2/S4/S7) i només reporta els seus breakdowns de serveis. Les files M de dalt es llisten com a referència, però el Flux 1 no les produeix.
França fa servir un model en Y (5 cantonades), no de clearance. La factura es transmet al comprador independentment que es registri un informe fiscal Flux 1; el PPF no valida prèviament les factures abans que arribin al comprador. La Factura i l’Informe fiscal són cicles de vida separats que només coincideixen en el lliurament del Flux 1. Un error en l’informe fiscal no desfà una factura que ja ha arribat al comprador.
La factura s’ha creat i està en cua per transmetre’s al PPF
sent
200 — Déposée
La factura s’ha dipositat al PPF correctament
registered
202 — Reçue
El PPF l’ha validat i lliurat al comprador
accepted
205 — Approuvée
El comprador ha aprovat la factura
refused
210 — Refusée
El comprador ha rebutjat la factura
paid
212 — Encaissée
El pagament de la factura s’ha confirmat
error
—
S’ha produït un error durant la transmissió o la validació al PPF. El camp errors conté el motiu del rebuig. Si la factura s’ha rebutjat abans del registre (estat sending o sent), elimina-la, corregeix el problema i envia’n una de nova; les factures amb error no es poden retransmetre directament. Una factura registrada (CDV 202 o posterior) no es pot eliminar ni tornar a enviar: ja és dins el cicle de vida del comprador. Corregeix-la amb un abonament o una rectificació (codi de procés S7/B7), o anul·la-la.
Configura endpoints de webhook des de la interfície de B2Brouter a Settings → Webhooks. Un cop configurats, B2Brouter enviarà un HTTP POST al teu endpoint cada vegada que la factura arribi a un nou estat.
Quan una factura arriba a l’estat sent, la resposta de GET /invoices/{id} inclou el camp download_legal_url. Fes-lo servir per descarregar el document de factura que s’ha transmès.
Com a alternativa en un sol pas, pots cridar directament GET /invoices/{id}/as/legal, sense haver d’obtenir primer download_legal_url del payload de la factura. Retorna el document legal arxivat tal com està emmagatzemat i no genera cap transacció facturable — consulta Descarregar factures i Transaction: View_as.
Encaissée és l’últim estat del cicle CDV d’una factura B2B francesa, just després de l’aprovació pel comprador. Indica que el pagament s’ha confirmat (vegeu el mapping CDV complet a la taula Estats de factura).
B2Brouter propaga la confirmació de pagament al PPF per una de dues vies, segons la naturalesa de la factura:
Properament gestionables per API. De moment, l’API només permet marcar la factura quan estigui completament pagada (state: "paid").
Si gestiones els pagaments des d’un ERP, mantén el control intern dels parcials i no marquis l’estat al PPF fins que el total estigui cobert. Alternativament, pots gestionar els parcials des de l’app de B2Brouter: obre la factura → Crear cobrament → defineix l’import pagat.
El Flux 10 cobreix transaccions fora de l’obligació de facturació electrònica B2B domèstica però que igualment s’han d’informar a la DGFiP. B2Brouter gestiona el Flux 10 automàticament.
Si ja generes el teu propi <Report> F10 i només necessites un canal acreditat per dipositar-lo, consulta Submissió d’un fitxer de Flux 10.
Vendes a particulars no registrats a l’IVA a França. Utilitza "type": "IssuedSimplifiedInvoice". El contact_id i els camps de pagament no són obligatoris per a factures B2C.
Operacions transfrontereres (B2B intra-UE i extra-UE)
Les vendes o compres amb empreses establertes fora de França s’han d’informar via Flux 10. Utilitza el tipus estàndard IssuedInvoice o ReceivedInvoice i estableix el country de la contraparte a un valor diferent de "fr". B2Brouter detectarà automàticament la naturalesa transfronterera.
Territoris francesos d’ultramar: els departaments DROM Guadalupe (gp), Martinica (mq) i La Reunió (re) es tracten com a França domèstica. Les factures a contactes d’aquests territoris generen un tax report del Flux 1 i porten IdentificationCode FR, exactament igual que la França metropolitana. La resta de territoris d’ultramar (Guaiana gf, Mayotte yt, Polinèsia Francesa pf, Nova Caledònia nc, TAAF tf, Saint-Pierre-et-Miquelon pm) queden fora del territori de l’IVA francès i segueixen el camí d’e-Reporting del Flux 10.
B2Brouter agrupa tots els tax reports Flux 10 d’un dia natural en Ledgers enviats al PPF una vegada al dia. Pots identificar-los perquè tenen ledger_id no nul a la resposta del tax report.
Cada ledger s’identifica per dues dimensions internes:
Rol DGFiP (SE o BY):
SE (Seller / émission) — per a les vendes que emets.
BY (Buyer / réception) — per a les compres intracomunitàries que has de declarar com a comprador.
Mode (transactions o payments):
transactions — ledgers de factures (codis de procés S1 / B1 / M1) — document type xml.ledger.dgfip.transactions.
payments — ledgers de pagaments (codis de procés S2 / B2 / M2, TVA sobre serveis es merita al cobrament) — document type xml.ledger.dgfip.payments.
La combinació de rols i modes dóna fins a 3 ledgers diaris per compte:
Ledger
Rol
Mode
Contingut
A — Emissió
SE
transactions
Factures emeses (B2C i cross-border B2B)
B — Recepció
BY
transactions
Compres intracomunitàries / extra-UE que has de declarar com a comprador
C — Pagaments
SE
payments
Pagaments confirmats de les teves factures emeses (cas Encaissée cross-border / B2C)
El parell (BY, payments) no existeix: la informació de pagament de les teves compres la genera el venedor des de la seva banda; no la declares tu.
Cada tax report es vincula a un únic ledger_id (no pertany a més d’un ledger alhora). L’agrupació es fa per compte + dia + (rol, mode) sota lock per evitar duplicats.
Com a empresa francesa registrada a l’Annuaire amb transport Peppol 0225, rebràs automàticament factures electròniques d’altres plataformes franceses i connectades a Peppol.
