DGFiP e-Invoicing y e-Reporting

Guía para integrar la API de B2Brouter y cumplir con la RFE francesa desde tu propio sistema.

Desde septiembre de 2026, todas las empresas francesas deben recibir sus facturas a través de una plataforma certificada, y las grandes empresas y las ETI también deben emitir sus facturas y reportar sus datos de TVA a través de ella. Las PYME (PME) y las microempresas deberán hacerlo a partir de septiembre de 2027. B2Brouter lo simplifica: tú envías los datos de la factura mediante una llamada a la API REST, y B2Brouter se encarga del registro en el PPF, la generación del documento (UBL/CII/Factur-X), el enrutamiento hacia tus clientes y el reporte fiscal a la DGFiP — todo con una sola integración.

B2Brouter es una Plateforme Agréée (PA) certificada para la reforma de facturación electrónica de la DGFiP francesa. Conéctate mediante la API REST y B2Brouter gestiona toda la pila de cumplimiento normativo en tu nombre:

Lo que B2Brouter hace por ti	Detalles
Registro en el PPF	Publica tu SIREN/SIRET en el Annuaire automáticamente al activar
Flux 1: Facturación electrónica B2B	Genera UBL/CII/Factur-X, transmite al PPF, enruta hacia la plataforma del receptor
Flux 6: Ciclo de vida de la factura	Gestiona los mensajes de estado CDAR (Déposée, Reçue, Approuvée, Refusée, Encaissée)
Flux 10: e-Reporting	Agrupa las transacciones B2C y B2B transfronterizas (intra-UE y extra-UE) en Ledgers enviados al PPF con la periodicidad que determina el `vat_regime` de tu Tax Report Setting
Recepción Peppol 0225	Recibe facturas desde cualquier plataforma francesa o conectada a Peppol
Generación de documentos	Tú envías los datos de la factura en JSON — B2Brouter genera el documento UBL/CII/Factur-X conforme y lo transmite al PPF. No se requiere generación de XML en tu lado
Formatos de entrada	API REST JSON, Factur-X PDF/A-3 (con CII XML integrado), UBL 2.1 XML, CII XML
Archivo legal	Todos los documentos transmitidos (facturas, reportes fiscales, mensajes CDAR) son almacenados por B2Brouter durante el período de retención legal de 10 años. No se requiere configuración adicional de almacenamiento en tu lado

El camino hasta tu primera factura: crear tu cuenta → activar DGFiP → crear un contacto → enviar tu primera factura.

Contexto regulatorio: La reforma de facturación electrónica francesa obliga a todas las empresas francesas a utilizar una Plateforme Agréée (PA) certificada para transmitir facturas y reportar datos de TVA a la DGFiP, a partir de septiembre de 2026 (septiembre de 2027 para la emisión y el e-reporting de las PYME y microempresas). Desde el 21 de febrero de 2026, el art. 289 bis del CGI solo prevé las plateformes agréées: el PPF (Portail Public de Facturation) del gobierno ya no es una alternativa. Como PA certificada, B2Brouter gestiona la conexión con el PPF en tu nombre — sin SFTP, sin certificados electrónicos, sin integración directa con el PPF.

¿Para quién es esta guía?

Hay dos casos de uso principales para integrar con B2Brouter para la facturación electrónica en Francia:

eDocExchange — Para empresas o grupos de empresas que integran su software de gestión (ERP, plataforma contable) directamente con B2Brouter. El proceso de incorporación (creación de cuenta, configuración del Tax Report Settings) se realiza normalmente una vez por empresa a través de la interfaz web. Las operaciones diarias (emisión de facturas, seguimiento de su ciclo de vida) se realizan a través de la API. Para añadir más cuentas de empresa a tu grupo de integración, sigue el mismo asistente de incorporación desde la misma cuenta de usuario de B2Brouter — no se requiere llamada API adicional.

eDocSync — Para proveedores de software y editores de ERP que quieren ofrecer el cumplimiento de la DGFiP a sus propios clientes desde dentro de su producto. Este es el modelo de marca blanca / integrado / marque blanche de B2Brouter: B2Brouter opera completamente en segundo plano, los clientes finales interactúan exclusivamente con la interfaz del proveedor y desconocen B2Brouter. El proveedor de software es responsable del aprovisionamiento de cuentas, la presentación de facturas y el seguimiento del ciclo de vida a través de la API de B2Brouter. Los clientes finales no necesitan un inicio de sesión ni una suscripción en B2Brouter.

Para eDocSync, el volumen de aprovisionamiento de cuentas determina el plan adecuado:

Pocas empresas (modelo revendedor): Añade cada empresa cliente como una cuenta en tu grupo de integración de B2Brouter a través de la interfaz web, siguiendo el asistente de incorporación estándar. Funciona bien para decenas de empresas y comparte una única clave API.
100+ empresas: Contacta con nuestro equipo de Ventas o abre un Ticket de Soporte para discutir un plan eDocSync dedicado con aprovisionamiento masivo (precios por volumen para editores).

En ambos casos, todas las funciones de cumplimiento específicas de Francia (registro en el Annuaire, transmisión Flux 1/6/10, ciclo de vida CDAR) funcionan de manera idéntica.

B2Brouter es en sí mismo una Plateforme Agréée: te integras con B2Brouter — no es un relé o conector a otra PA. Si tu SIREN está actualmente registrado con una PA diferente, activar el Tax Report Setting sobre la cuenta SIREN falla: necesitas un código de migración (ver Cambiar de PA). Para llevar solo un establecimiento y conservar ese registro existente, consulta el Escenario 2 en Estructura de la cuenta. No puedes usar B2Brouter como intermediario para enviar facturas bajo la certificación de otra PA.

Enrutamiento a destinatarios en otras PA: Cuando tu receptor está registrado en una PA diferente, B2Brouter enruta la factura a través del modelo de cuatro esquinas Peppol estándar (C2 → C3): el punto de acceso Peppol de B2Brouter (C2) busca la dirección Peppol del destinatario en el Annuaire y entrega el documento al punto de acceso del comprador (C3) — independientemente de qué PA utilicen. No se requiere ninguna configuración adicional en tu lado.

Entornos de prueba: usa el sandbox para las pruebas iniciales de la API y la validación de payloads. En sandbox las escrituras en el Annuaire de la DGFiP se simulan: activar una Tax Report Setting no registra nada en el PPF, así que no necesitas identificadores registrados en el PPF. Ahora bien, el SIREN y el SIRET tienen que superar igualmente el dígito de control, porque el sandbox corre en el entorno de producción. Solo staging acepta cualquier número de 9 o 14 cifras. Para pruebas completas de extremo a extremo con el entorno QAS (calificación) de la DGFiP, usa el entorno de staging de B2Brouter como se describe a continuación.

¿Primera vez con la API? Empieza por la introducción a la API: entornos, clave de API y primera petición.

Antes de empezar: elige tu entorno

Entorno	App B2Brouter	API B2Brouter	Portal Chorus Pro
Producción	app.b2brouter.net	`https://api.b2brouter.net`	chorus-pro.gouv.fr
Staging (test)	app-staging.b2brouter.net	`https://api-staging.b2brouter.net`	qualif.chorus-pro.gouv.fr

No mezcles entornos. Producción usa números SIREN/SIRET reales y se conecta al Annuaire de producción de la DGFiP. Staging usa identificadores de prueba ficticios y se conecta al entorno QAS (calificación) de la DGFiP. Las claves API, cuentas y contactos no se comparten entre entornos.

Opción A: Piloto de producción

Regístrate en app.b2brouter.net para comenzar una integración de producción. Cuando activas el Tax Report Setting de la DGFiP, el SIREN/SIRET de tu empresa se publica en el Annuaire real del PPF, haciéndolo descubrible por cualquier plataforma en el ecosistema de facturación electrónica francés.

Esta opción es para facturas B2B reales. Durante el piloto, antes de septiembre de 2026, la DGFiP debía borrar los registros del período QAS antes de que la reforma entrara en vigor, por lo que las facturas enviadas durante el piloto no creaban obligaciones de cumplimiento. Este es el punto de partida adecuado si ya has elegido B2Brouter y quieres probar la integración completa con los datos reales de tu empresa.

Opción B: Staging (recomendado para evaluación)

Regístrate en app-staging.b2brouter.net para usar el entorno de pruebas de B2Brouter, que está conectado al entorno QAS (calificación) de la DGFiP.

Esta es la mejor opción si:

Estás evaluando múltiples plataformas antes de comprometerte
Tu SIREN/SIRET ya está publicado en el Annuaire con otra PA y todavía no quieres cambiar de PA
Prefieres no asociar el identificador de tu empresa con actividad de prueba

El entorno de staging es auto-aprovisionado: una vez que tienes identificadores de prueba (ver a continuación), puedes comenzar las pruebas de extremo a extremo en menos de 24 horas.

Validación del SIRET en staging: En el entorno de staging, cualquier número válido de 14 dígitos se acepta como SIRET sin validación de suma de comprobación. Los identificadores ficticios del CSV QAS de Chorus Pro están pre-registrados en el annuaire QAS de la DGFiP y funcionan de extremo a extremo. En producción, se validan el formato y la suma de comprobación del SIRET.

Importante: La DGFiP no permite números SIREN o SIRET reales en su entorno QAS. Debes usar identificadores de prueba ficticios. Puedes obtenerlos tú mismo a través del portal QAS de Chorus Pro (gratuito, proceso de 5 minutos) o solicitar un conjunto pre-asignado abriendo un Ticket de Soporte en la app de staging.

Una cuenta por SIREN: B2Brouter crea una cuenta por SIREN (la clave del número de TVA se deriva del SIREN). Si proporcionas un SIRET, el SIREN se extrae de él. Dos SIRETs diferentes de la misma empresa (mismo SIREN) se resolverán en la misma cuenta. Si tu empresa opera desde múltiples establecimientos (diferentes SIRETs), estos se modelan como unidades organizativas dentro de la misma cuenta de B2Brouter — no como cuentas separadas. Contacta con Soporte si necesitas configurar la facturación multi-establecimiento. Ten esto en cuenta al seleccionar filas del CSV: elige SIRETs con SIRENs distintos (primeros 9 dígitos) para cada empresa independiente que necesites probar.

Obtener identificadores de prueba a través del QAS de Chorus Pro

El portal QAS de Chorus Pro te permite generar un “Matelas de données” (conjunto de datos) — un archivo CSV con identificadores SIREN/SIRET ficticios pre-registrados en el entorno de pruebas de la DGFiP. Sigue estos pasos:

Ve a qualif.chorus-pro.gouv.fr → pestaña Entreprise → Créer mon compte.
- Puedes usar una dirección de correo electrónico temporal (p. ej. temp-mail.io).
- Usa cualquier nombre; esta cuenta es puramente para obtener identificadores de prueba.
Revisa tu bandeja de entrada para el correo “Initialisation de mot de passe Chorus Pro” y establece tu contraseña (enlace válido 60 minutos).
Inicia sesión → ve a Domaines → Matelas de données → haz clic en Générer un matelas de données y confirma.
Ve a Consultation du matelas de données. Espera hasta que ambos estados muestren “Disponible”:
- Statut pour Chorus Pro: Disponible
- Statut pour l’annuaire de facturation PPF: Disponible
- La generación suele tardar unos minutos. Recarga la página para verificar.
Haz clic en “Générer et télécharger le fichier CSV du matelas structures et utilisateurs” para descargar tus identificadores de prueba.

El CSV contiene múltiples números SIREN/SIRET ficticios en filas etiquetadas como “Privé” y “Public”. Usa solo las filas de la sección “Privé” (sector privado) para tus cuentas de prueba. Las entidades del sector público (SIREN 'Public') son rechazadas por el annuaire QAS de la DGFiP — intentar activar el e-Reporting en una cuenta del sector público devuelve HTTP 422 (“La création d’une ligne annuaire n’est pas possible pour une entité associée à un SIREN ‘Public’”). Este es el comportamiento correcto: las entidades públicas usan Chorus Pro directamente, no una PA.

Usa un SIREN del sector privado para tu cuenta emisora y otro para tu contacto de prueba.

Una vez que tengas tus identificadores de prueba:

Regístrate en app-staging.b2brouter.net y activa tu cuenta.
Crea tu cuenta de empresa usando un SIREN del CSV (ver Crear la cuenta de tu empresa).
Suscríbete a un plan eDocExchange (las suscripciones de staging son simuladas — sin cargo).
Activa el Tax Report Setting de la DGFiP (ver Activar el Tax Report Setting).
- ⚠️ El registro de tu empresa en el Annuaire no es inmediato: la publicación va con el envío nocturno y queda activa a la mañana siguiente, tanto en staging como en producción. Es el funcionamiento de la infraestructura de la DGFiP, no un retraso de B2Brouter. Hasta entonces no podrás enviar facturas.
Al día siguiente: crea un contacto de prueba usando un segundo SIREN del CSV (ver Crear un contacto).
Envía tu primera factura (ver Emisión de Facturas).

Credenciales de la API

La autenticación usa una clave API estática que se pasa en la cabecera HTTP X-B2B-API-Key. No hay flujo OAuth2 — genera tu clave API en la interfaz de B2Brouter en Configuración → Claves API. Mantenla confidencial y nunca la incluyas en código del lado del cliente. También establece X-B2B-API-Version en cada solicitud.

URL base: Todos los ejemplos a continuación usan https://api-staging.b2brouter.net. Para producción, reemplaza con https://api.b2brouter.net.

Estructura de la cuenta: matriz y unidades organizativas

En Francia, cada empresa tiene un SIREN de 9 dígitos que la identifica como entidad legal, y cada establecimiento o servicio tiene un SIRET de 14 dígitos derivado de ese SIREN. B2Brouter sigue la misma jerarquía, con una cuenta matriz y, bajo ella, una unidad organizativa (UO) por cada establecimiento o servicio. Las facturas se emiten desde la cuenta matriz o desde una UO concreta, según el establecimiento emisor.

Qué países cubre esta guía. Las reglas de cuenta de esta guía (matriz y UO, identificadores, Tax Report Setting) son para empresas establecidas en el territorio de TVA francés: Francia (fr) y los DROM Guadalupe (gp), Martinica (mq) y La Reunión (re). Para un emisor establecido en cualquier otro territorio de ultramar (Guayana, Mayotte, Polinesia Francesa, Nueva Caledonia, San Pedro y Miquelón…) esta guía no establece la configuración de la cuenta: contacta con soporte antes de crearla.

La regla de oro

La cuenta matriz siempre es un SIREN. Cualquier SIRET, Code Routage o Suffix (ver Identificadores y esquemas) se modela siempre como UO bajo esa matriz, nunca como cuenta independiente: es lo que mantiene coherentes los identificadores publicados de la matriz y de sus UOs.

Si creas una cuenta con un SIRET, B2Brouter no la rechaza: deriva el SIREN de los 9 primeros dígitos, crea la cuenta matriz si todavía no existe y cuelga el SIRET como UO. Lo que te devuelve la llamada es la UO. Convertir una matriz existente a SIRET con un PUT sí devuelve 422 parameter_matriu_must_be_siren.

Cada UO tiene su propio Tax Report Setting. Una UO nunca declara a través de la cuenta matriz: si no tiene su propio Tax Report Setting activado, no declara. Ahora bien, al crear una UO bajo una matriz que ya tiene la DGFiP activa, B2Brouter le clona un Tax Report Setting propio para que empiece a declarar sin pasos adicionales. Si no quieres que declare, desactívalo (enabled: false) una vez creada. Ver Escenarios y casos para elegir tu configuración.

Contactos

La regla de oro también vale para los contactos. Los contactos franceses (clientes y proveedores) siguen la misma jerarquía y los mismos cin_scheme: el contacto matriz es siempre el SIREN, y cualquier SIRET, Code Routage o Suffix es una UO. El sistema admite técnicamente un contacto matriz con un identificador distinto del SIREN, pero hacerlo rompe las UOs que añadas después para el mismo cliente. Para crearlos, ver Crear un contacto.

Identificadores y esquemas

Identificadores en B2Brouter

En B2Brouter, las cuentas, las unidades organizativas y los contactos franceses se definen con un identificador principal (cin_scheme + cin_value). Las UOs con SIRET que tienen varios servicios internos añaden un sub-identificador (routing_codes.cin1_scheme + routing_codes.cin1_value) para apuntar a un servicio concreto. Son dos cosas distintas: el Suffix es un cin_scheme principal, mientras que el Code Routage va siempre en el sub-identificador y nunca como cin_scheme principal.

Identificador principal de la cuenta, UO o contacto (cin_scheme + cin_value):

`cin_scheme`	`cin_value`	Qué representa	Ejemplo
`0002` (`2`)	SIREN, 9 dígitos + Luhn	Entidad legal	`842917361`
`0009` (`9`)	SIRET, 14 dígitos (SIREN + 5 dígitos), con dos controles Luhn: el de los 14 dígitos y el del SIREN inicial	Establecimiento	`84291736100011`
`8040`	Suffix, alfanumérico `[A-Za-z0-9_.-]{1,100}`	UO sin SIRET propio	`SUF01`, `ADMIN`

La validación del SIREN y del SIRET es solo aritmética: B2Brouter no consulta el registro Sirene ni ningún otro. Un número inventado que pasa el control se acepta, y puede coincidir con el de una empresa real. Para construir un par de prueba:

Elige 8 dígitos y añade el dígito de control Luhn: tienes el SIREN.
Añade 4 dígitos de establecimiento y el dígito de control Luhn calculado sobre esos 13 dígitos: tienes el SIRET.

Todos los SIREN y SIRET de esta página pasan los dos controles, por ejemplo 842917361 y 84291736100011.

Sub-identificador o routing code (routing_codes.cin1_scheme + routing_codes.cin1_value):

`routing_codes.cin1_scheme`	`routing_codes.cin1_value`	Qué representa	Ejemplo
`0224` (`224`)	Code Routage, alfanumérico `[A-Za-z0-9_\-\/]+` (mínimo 1 carácter)	Servicio dentro de un SIRET	`COMPTA`, `SERV01`, `A123`

Identificador publicado en el Annuaire

En la red Peppol, en cambio, el participante francés se identifica siempre con el esquema 0225 (FRCTC Electronic Address), el código reservado a las direcciones electrónicas francesas. Su valor es siempre una composición publicada en el Annuaire, nunca un identificador solo: un SIRET sin el SIREN delante no es publicable. Los schemes 0224 y 8040 no son esquemas Peppol: solo sirven para componer ese valor.

Identificador del participante Peppol (pin_scheme + pin_value):

`pin_scheme`	`pin_value`	Qué representa
`0225`	`SIREN`	Entidad entera (matriz)
`0225`	`SIREN_SIRET`	Establecimiento
`0225`	`SIREN_SIRET_<CR>`	Servicio dentro de un establecimiento
`0225`	`SIREN_<SUFFIX>`	UO sin SIRET propio

Cada composición corresponde a uno o dos de los casos de la Tabla de casos. Para ver los campos de la API que la generan, consulta Añadir los establecimientos como unidades organizativas.

Escenarios y casos

B2Brouter cubre tres escenarios de configuración. Cuál te corresponde depende de qué quieras hacer desde B2Brouter. Si no sabes si tu SIREN ya está registrado con otra PA, consúltalo en el Annuaire con el Directory lookup.

¿Quieres que el SIREN declare desde B2Brouter?

Respuesta	Escenario	Qué tienes que hacer
Sí	Escenario 1. Declara toda la empresa	Activa el Tax Report Setting en la cuenta matriz SIREN. Los establecimientos, servicios y unidades internas se modelan con los casos 1, 2 y 3. Si el SIREN ya está registrado con otra PA, primero tienes que migrarlo a B2Brouter con un código de migración (ver Migrar desde otra PA o hacia otra).
No, quiero declarar un establecimiento concreto desde B2Brouter	Escenario 2. Declara solo un establecimiento	Crea el establecimiento como UO con el SIRET y activa el Tax Report Setting solo en esa UO, no en la cuenta matriz SIREN. El registro del SIREN con la otra PA no se modifica. Casos 4 y 5.
No, solo quiero emitir desde B2Brouter	Escenario 3. Emite desde B2Brouter, recibe en tu PA	⚠️ Solo disponible en una UO de Suffix: créala bajo el SIREN y activa en ella el Tax Report Setting con `issue_only: true`. La recepción se mantiene en la otra PA. Caso 6, ver Modos del Tax Report Setting.

Tabla de casos

Caso	Unidad organizativa (UO)	Tax Report Setting	Direccionamiento Annuaire (`pin_value`)	Cuándo lo necesitas
1. Établissement Escenario 1	SIRET	Matriz:`ON` UO:`ON`¹	`SIREN_SIRET`	Tienes establecimientos y todos declaran desde la empresa.
2. Service Escenario 1	SIRET + Code Routage	Matriz:`ON` UO:`ON`¹	`SIREN_SIRET_<CR>`	Quieres direccionar un departamento concreto dentro de un establecimiento.
3. Suffix Escenario 1	Suffix	Matriz:`ON` UO:`ON`¹	`SIREN_<SUFFIX>`	Tienes una unidad sin SIRET propio que debe recibir y declarar con dirección propia.
4. Établissement-only Escenario 2	SIRET	Matriz:`OFF` UO:`ON`	`SIREN_SIRET`	El SIREN ya está registrado con otra PA y solo llevas un establecimiento a B2Brouter.
5. Établissement-only + Service Escenario 2	SIRET + Code Routage	Matriz:`OFF` UO:`ON`	`SIREN_SIRET_<CR>`	Como el caso 4, pero direccionando un departamento dentro de ese establecimiento.
6. Issue-only Escenario 3	Suffix con `issue_only`²	Matriz:`OFF` UO:`ON`	`SIREN_<SUFFIX>`	Quieres emitir desde B2Brouter manteniendo la recepción en tu PA actual.

¹ Al crear una UO bajo una matriz que ya tiene la DGFiP activa, B2Brouter le clona un Tax Report Setting propio. Ver La regla de oro.

² Una UO de Suffix publica transporte 0225 y recibe facturas como cualquier otra dirección (caso 3). Lo que le quita la recepción es el flag issue_only de su Tax Report Setting, que solo se acepta en una UO de Suffix (ver Modos del Tax Report Setting).

Crear la cuenta de tu empresa

Este apartado explica cómo crear la cuenta matriz con el SIREN y cómo añadirle las unidades organizativas. El modelo que hay detrás está en Estructura de la cuenta.

Crear la cuenta matriz con el SIREN

Crea la cuenta con POST /accounts. Si ya existe, recupera su id con GET /accounts y sáltate la creación.

Campos específicos de una cuenta francesa:

Campo	Valor	Finalidad
`country`	`"fr"`	Activa las validaciones y el enrutamiento FR
`cin_scheme`	`"0002"`	SIREN, la entidad legal. La matriz es siempre SIREN: ver La regla de oro para saber qué pasa si envías un SIRET
`cin_value`	SIREN de 9 dígitos	Identificador de la empresa, validado con Luhn
`tin_scheme`	`9957`	Código ISO 6523 del identificador fiscal francés
`tin_value`	`FR{kk}{siren}`	Número de TVA que aparece en el UBL. La suma de comprobación `kk` no la tienes que calcular

Ejemplo de solicitud:

curl --request POST \
  --url https://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": {
      "country": "fr",
      "name": "Exemplar SAS",
      "address": "10 Rue Imaginaire",
      "city": "Paris",
      "postalcode": "75001",
      "province": "Île-de-France",
      "email": "john.doe@example.com",
      "tin_value": "FR22842917361",
      "tin_scheme": 9957,
      "cin_scheme": "0002",
      "cin_value": "842917361",
      "rounding_method": "half_up"
    }
  }'

Respuesta de ejemplo:

{
  "account": {
    "id": 83428,
    "name": "Exemplar SAS",
    "tin_value": "FR22842917361",
    "tin_scheme": 9957,
    "cin_scheme": "0002",
    "cin_value": "842917361",
    "address": "10 Rue Imaginaire",
    "city": "Paris",
    "postalcode": "75001",
    "province": "Île-de-France",
    "country": "fr",
    "currency": "EUR",
    "email": "john.doe@example.com",
    "rounding_method": "half_up",
    "created_at": "2026-06-10T09:54:38.000Z",
    "updated_at": "2026-06-10T09:54:38.000Z"
  }
}

Añadir los establecimientos como unidades organizativas (opcional)

Si la estructura de tu empresa requiere UOs (ver la tabla de casos), crea cada UO con POST /accounts añadiendo parent_id (el ID de la cuenta matriz que has creado antes).

Si la cuenta matriz ya tiene el Tax Report Setting de la DGFiP activo, la UO nueva recibe una copia propia y empieza a declarar de inmediato. Si no quieres que declare, desactívale el Tax Report Setting (enabled: false) una vez creada (ver La regla de oro).

Restricciones:

Una UO no puede llevar tin_value ni tin_scheme: los hereda de la matriz y no se deben repetir.
Una UO no puede ser parent de otra UO: solo hay un nivel de profundidad.

Campos obligatorios en todos los payloads UO:

Campo	Valor	Finalidad
`parent_id`	ID de la cuenta matriz	Cuelga la UO de la matriz SIREN: es lo que la convierte en UO
`cin_scheme` y `cin_value`	Según el tipo de UO	Identificador propio de la UO; ver Campos de creación y resultado en el Annuaire. Un SIRET empieza siempre por los 9 dígitos del SIREN matriz, por definición del INSEE: si la matriz es `842917361`, los SIRET válidos tienen la forma `842917361XXXXX`
`country`	`"fr"`	Activa las validaciones y el enrutamiento FR
`email`, `address`, `city`, `postalcode`, `province`	Datos de contacto y dirección de la UO	Obligatorios en cualquier cuenta, también en las UOs

Sin estos campos, la creación devuelve HTTP 422 ("Region/Province/Country can't be blank").

Campos de creación y resultado en el Annuaire

Tipo de UO	Campos a enviar a `POST /accounts`	Resultado en el Annuaire
Établissement (casos 1 y 4)	`parent_id` (matriz SIREN) + `cin_scheme="0009"` + `cin_value=<SIRET>`	`SIREN_SIRET`
Service (casos 2 y 5)	`parent_id` (matriz SIREN) + `cin_scheme="0009"` + `cin_value=<SIRET>` + `routing_codes.cin1_scheme="224"` + `routing_codes.cin1_value=<CR>`	`SIREN_SIRET_<CR>`
Suffix (casos 3 y 6)	`parent_id` (matriz SIREN) + `cin_scheme="8040"` + `cin_value=<SUFFIX>`	`SIREN_<SUFFIX>`

Ejemplos de payload

Los casos 4, 5 y 6: el payload no los distingue de sus equivalentes. Lo que cambia es dónde se activa el Tax Report Setting y, en el caso 6, el flag issue_only. Ver Escenarios y casos.

Caso 1 y 2: UO de tipo Établissement con Service opcional

Para un establecimiento sin Code Routage (Caso 1), omite el bloque routing_codes.

curl --request POST \
  --url https://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, Sucursal Paris",
      "parent_id": {PARENT_ACCOUNT_ID},
      "cin_scheme": "0009",
      "cin_value": "84291736100011",
      "routing_codes": { "cin1_scheme": "224", "cin1_value": "COMPTA" },
      "country": "fr",
      "email": "sucursal-paris@example.com",
      "address": "1 Rue de la Paix",
      "city": "Paris",
      "postalcode": "75001",
      "province": "Île-de-France"
    }
  }'

Caso 3: UO de tipo Suffix

El payload del caso 6 (Issue-only) es idéntico al del caso 3: lo que los diferencia no es el POST /accounts sino el Tax Report Setting que activas después, con issue_only: true. Este flag solo se acepta sobre una UO con cin_scheme="8040". Ver Modos del Tax Report Setting.

curl --request POST \
  --url https://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, Unidad 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"
    }
  }'

Activar el Tax Report Setting

Este es el paso clave de incorporación. Cuando creas un Tax Report Setting con code: "dgfip", B2Brouter automáticamente:

Registra tu empresa en el Annuaire del PPF: tu identificador se vuelve descubrible por cualquier plataforma en el ecosistema de facturación electrónica francés.
Crea un transporte Peppol 0225 (FRCTC Electronic Address): tu empresa queda habilitada para recibir facturas electrónicas desde cualquier plataforma conectada a Peppol en Francia.
⚠️ Si la cuenta sobre la que activas ya tiene un transporte Peppol, será reemplazado por el nuevo transporte 0225 durante la activación.

Identificador ya registrado con otra PA: Si el SIREN sobre el que activas estaba previamente registrado con otra PA, B2Brouter cerrará la entrada existente del Annuaire y abrirá una nueva. Si necesitas conservar ese registro existente, no actives sobre el SIREN; activa sobre una UO SIRET (ver “Dónde activar” más abajo). Actualiza cualquier integración existente que haga referencia al identificador de transporte anterior.

Dónde activar el Tax Report Setting: {ACCOUNT_ID} puede ser la matriz SIREN, una UO SIRET, o ambas. Cada cuenta (matriz o UO) que tiene Tax Report Setting propio se publica en el Annuaire con su propia dirección. Para cuentas del territorio de TVA francés (FR, y los DROM GP/MQ/RE) no hay herencia entre UO y matriz (ver La regla de oro): sin Tax Report Setting propio la UO no declara, y con un Tax Report Setting propio desactivado tampoco. Tres configuraciones:

Tax Report Setting solo en el SIREN: la empresa se publica como SIREN (caso estándar, Escenario 1). Las UOs nuevas bajo esa matriz reciben automáticamente un Tax Report Setting propio clonado al crearse (ver la nota siguiente), por lo que normalmente también declaran.

Tax Report Setting en el SIREN y en una o más UOs SIRET: la empresa se publica a la vez como SIREN y como cada SIREN_SIRET (una dirección de Annuaire por cuenta activada). Todos los Tax Report Settings DGFiP activos del mismo SIREN deben compartir el mismo vat_regime: si activas uno distinto, la solicitud devuelve 422 dgfip_vat_regime_taken_per_siren.

Tax Report Setting solo en una UO SIRET, no en el SIREN: solo se publica ese establecimiento (SIREN_SIRET); el SIREN no (Escenario 2). Úsalo cuando el SIREN ya está registrado con otra PA y quieres conservar ese registro.

Ver Estructura de la cuenta para el modelo completo.

Si creas una UO con la matriz ya activa: B2Brouter le crea automáticamente su propio Tax Report Setting DGFiP (con start_date de mañana), para que empiece a declarar sin pasos adicionales. Si la matriz no tiene la DGFiP activa en ese momento, la UO se crea sin ningún Tax Report Setting; cuando actives la matriz más adelante, la UO recibe uno propio. La UO nunca consulta el de la matriz para declarar.

El start_date determina cuándo comienza el reporte fiscal. A partir de esa fecha, las facturas que emitas generarán reportes fiscales y serán transmitidas al PPF.

Ejemplo de solicitud:

curl --request POST \
  --url https://api-staging.b2brouter.net/accounts/{ACCOUNT_ID}/tax_report_settings \
  --header 'X-B2B-API-Key: {YOUR_API_KEY}' \
  --header 'X-B2B-API-Version: {YOUR_API_VERSION}' \
  --header 'Content-Type: application/json' \
  --data '{
    "tax_report_setting": {
      "code": "dgfip",
      "start_date": "2026-10-01",
      "type_operation": "services",
      "vat_regime": "reel_normal_mensuel",
      "naf_code": "62",
      "enterprise_size": "eti",
      "email": "jane.doe@example.com"
    }
  }'

Respuesta de ejemplo:

{
  "tax_report_setting": {
    "code": "dgfip",
    "start_date": "2026-10-01",
    "auto_generate": true,
    "auto_send": true,
    "enabled": true,
    "type_operation": "services",
    "vat_regime": "reel_normal_mensuel",
    "naf_code": "62",
    "enterprise_size": "eti",
    "email": "jane.doe@example.com",
    "locked": false,
    "created_at": "2026-06-10T10:15:22.000Z",
    "updated_at": "2026-06-10T10:15:22.000Z"
  }
}

Campos del Tax Report Setting de la DGFiP

Campo	Tipo	Requerido	Descripción
code	string	Sí	Debe ser `"dgfip"`.
start_date	date	No	Cuándo comienza el reporte fiscal. Debe ser mañana o posterior: la fecha de hoy se rechaza con `422`. Por defecto mañana si se omite.
type_operation	string	Sí	Tipo de operación predeterminado para esta empresa: `"services"`, `"goods"` o `"mixed"`. Determina el código de proceso de la DGFiP (S1/B1, etc.) usado en los reportes fiscales. Elige `"mixed"` si tu empresa vende tanto bienes como servicios. En una factura mixta, el reporte fiscal del Flux 1 lleva un código de proceso de la serie M (`M1`/`M2`/`M4`) y reporta todos los breakdowns (consulta Códigos de proceso). Esta configuración se puede actualizar tras la activación.
naf_code	string	No	Opcional; solo se valida si se informa. El código NAF/APE de la empresa (Nomenclature d’Activités Française). Es el código de sección de 2 dígitos asignado por el INSEE que identifica la actividad económica principal de la empresa (p. ej. `"62"` para servicios de TI y software, `"47"` para comercio minorista, `"86"` para salud). La DGFiP usa este código para la clasificación de reportes fiscales. Puedes encontrar tu código NAF en el extracto Kbis de tu empresa o en sirene.fr.
enterprise_size	string	No	Opcional; solo se valida si se informa. La categoría de tamaño de la empresa según define el INSEE. Valores permitidos: `"micro"` (Microentreprise — < 10 empleados, CA ≤ 2 M€), `"pme"` (PME — 10 a 249 empleados, CA ≤ 50 M€), `"eti"` (ETI — 250 a 4.999 empleados, CA ≤ 1,5 Md€), o `"ge"` (Grande Entreprise — 5.000+ empleados o CA > 1,5 Md€).
`vat_regime`	string	Sí, salvo `annuaire_only=true`	El régimen de TVA de la empresa. Determina la frecuencia de transmisión del Flux 10 (e-Reporting). Sin un `vat_regime` válido no se pueden transmitir facturas declarables: la solicitud devuelve HTTP 422. Ver la tabla de regímenes.
reason_vat_exempt	string	No	Código de motivo de exención de TVA predeterminado para esta empresa. Por defecto `"VATEX-FR-FRANCHISE"` (franchise en base de TVA). Establécelo si tu empresa opera bajo un régimen específico de exención de TVA.
email	string	No	Correo electrónico de contacto para notificaciones fiscales.
auto_generate	boolean	No	Siempre `true` para DGFiP (obligación legal). No se puede cambiar.
auto_send	boolean	No	Transmitir automáticamente los reportes fiscales al PPF. Por defecto `true`.
enabled	boolean	No	Si la configuración está activa. Por defecto `true`. El registro en el Annuaire solo ocurre cuando es `true`.
annuaire_only	boolean	No	Cuando es `true`, la cuenta solo se registra en el Annuaire del PPF para recepción. No se generan tax reports Flux 1 ni mensajes CDAR, y `vat_regime` no es obligatorio. Por defecto `false`. Ver Modos del Tax Report Setting.
issue_only	boolean	No	Cuando es `true`, B2Brouter emite tus facturas y tax reports mientras la recepción se queda en tu PA actual. Solo se acepta en una UO de Suffix (`cin_scheme="8040"`): en cualquier otra cuenta la solicitud devuelve `422 dgfip_issue_only_suffix_uo_only`. Por defecto `false`. Ver `issue_only`.
peppol_email_fallback	boolean	No	Envía la factura por correo electrónico en formato Factur-X cuando el destinatario francés está en el Annuaire pero confirmado como ausente de Peppol. Por defecto `false`: sin esto, el envío se bloquea. Ver Emitir facturas.

Regímenes de TVA y frecuencia de transmisión

Régimen	Descripción
`reel_normal_mensuel`	Transacciones cada diez días (días 1-10, 11-20, 21-fin de mes); pagos mensualmente.
`reel_normal_trimestriel`	Mensual.
`simplifie`	Mensual. Plazo de envío: día 26 del mes siguiente. Régimen abolido el 2027-01-01; a partir de esa fecha se trata como `reel_normal_trimestriel`.
`franchise_en_base`	Bimensual (bimestres naturales: Ene-Feb, Mar-Abr, May-Jun, Jul-Ago, Sep-Oct, Nov-Dic). Plazo de envío: día 26 del mes siguiente.

Si el registro en el Annuaire falla (SIREN/SIRET inválido, o una interrupción temporal del servicio de la DGFiP), la creación del Tax Report Setting se revierte y se devuelve un error. Corrige el problema y reintenta.

Tax Report Settings - Referencia API

Modos del Tax Report Setting

Si has seguido los pasos anteriores, ya tienes el modo completo y no necesitas leer nada más de este apartado. Los otros dos modos son desviaciones para situaciones concretas.

Modo	Dónde vive el Tax Report Setting	Annuaire	Recepción Peppol 0225	Tax reports	Respuestas (CDAR)
Completo (por defecto)	Matriz o UO	sí	sí	sí	se envían y se reciben
`annuaire_only`	Matriz o UO	sí	sí	no	no se envía ninguna
`issue_only`	Solo UO de Suffix	sí	no (se queda en la PA actual)	sí	se reciben si activas `cdar` en el transporte

El transporte Peppol de solo emisión no es un modo del Tax Report Setting: es el vehículo de emisión que acompaña a issue_only y se crea aparte.

`annuaire_only`: solo recibir

Cuándo lo necesitas: tu empresa todavía no está obligada a emitir, pero quieres estar en el Annuaire para que los proveedores puedan enviarte facturas.

Registra la empresa en el Annuaire y crea el transporte 0225 para la recepción, pero no genera tax reports ni envía mensajes CDAR. El campo vat_regime no es obligatorio en este modo.

curl --request POST \
  --url https://api-staging.b2brouter.net/accounts/{ACCOUNT_ID}/tax_report_settings \
  --header 'X-B2B-API-Key: {YOUR_API_KEY}' \
  --header 'X-B2B-API-Version: {YOUR_API_VERSION}' \
  --header 'Content-Type: application/json' \
  --data '{
    "tax_report_setting": {
      "code": "dgfip",
      "start_date": "2026-10-01",
      "annuaire_only": true,
      "email": "jane.doe@example.com"
    }
  }'

Cuando quieras emitir, actualiza el Tax Report Setting a modo completo con un PATCH.

`issue_only`: emitir desde B2Brouter manteniendo la recepción donde está

Cuándo lo necesitas: quieres emitir desde una UO de Suffix en B2Brouter manteniendo la recepción en la PA que ya tiene tu SIREN. Si lo que quieres es llevártelo, ver Cambiar de PA.

Este flag solo se acepta en una UO de Suffix (cin_scheme="8040") bajo la matriz SIREN. Activarlo sobre la matriz devuelve 422 dgfip_issue_only_suffix_uo_only.

Al activarlo, B2Brouter publica tu línea en el Annuaire del PPF (el directorio de la administración francesa que enruta el Flux 1) con el direccionamiento SIREN_<SUFFIX>, pero no crea ningún transporte Peppol. La línea que la otra PA tiene publicada para tu SIREN queda intacta: lo que publiques tú lo haces bajo SIREN_<SUFFIX>, que es un identificador distinto.

Habilitar la emisión Peppol

El transporte tienes que crearlo tú para la UO de Suffix, con el identificador compuesto y con cdar como único tipo de documento activado. Sin transporte, el primer envío falla con 422 "To use Peppol Network you need to configure this connection to your account".

Tres campos son críticos:

reception: true publica el Suffix en el SML. Hace falta, porque los CDAR llegan por Peppol y sin publicación no te encontrarían.
cdar: true, y ningún otro tipo de documento. Es lo que hace que el modo sea issue-only: recibes las respuestas de las facturas que emites, pero no facturas, que deben seguir llegando a tu PA actual.
pin_value debe ser la composición {SIREN de la matriz}_<SUFFIX> con pin_scheme: 225, el mismo direccionamiento que B2Brouter ya ha publicado en la línea del Annuaire.

curl --request POST \
  --url https://api-staging.b2brouter.net/accounts/{UO_ACCOUNT_ID}/transports \
  --header 'X-B2B-API-Key: {YOUR_API_KEY}' \
  --header 'X-B2B-API-Version: {YOUR_API_VERSION}' \
  --header 'Content-Type: application/json' \
  --data '{
    "transport": {
      "code": "peppol",
      "enabled": true,
      "reception": true,
      "cdar": true,
      "pin_scheme": 225,
      "pin_value": "842917361_SUF01"
    }
  }'

Queda un transporte que emite y que solo recibe CDAR. El registro que la otra PA tiene para tu SIREN no se toca y sigue recibiendo las facturas de tus proveedores.

Si más adelante quieres recibir también por B2Brouter, desactiva issue_only.

Cambiar de PA

El cambio implica dos registros separados que se comportan de manera diferente:

El Annuaire lo actualiza siempre la PA que entra, no la que sale.
El registro Peppol es el que puede bloquear el cambio: un identificador solo puede estar activo con un proveedor a la vez. Hasta que el registro no se mueva o se dé de baja, la activación de la PA que entra falla con 422.

Hay tres maneras de desbloquearlo:

Con código de migración, el camino automático y el recomendado, porque no corta el servicio. Lo emite siempre la PA que tiene el identificador publicado en ese momento, y lo usa la PA que entra al activar. En B2Brouter lo puedes solicitar al salir (ver Salir de B2Brouter) y aportarlo al llegar (ver Venir a B2Brouter).
Con baja de Peppol: la PA que sale despublica el identificador de Peppol. Esto lo libera y la PA que entra ya puede activar, pero te deja sin servicio hasta que lo vuelva a publicar. Ver Despublicar, dar de baja y migrar.
Manualmente, cuando la PA que sale no ofrece ninguna de las dos: contacta con la PA que entra, y es esta quien reclama el cambio a la que sale. Todas las PA francesas están obligadas a ofrecer este camino, así que no tener código no te deja bloqueado (ver Venir a B2Brouter).

Despublicar, dar de baja y migrar

Tres operaciones que a menudo se llaman igual y tienen efectos distintos:

Operación	Efecto	¿Sigue registrado en el SML?
Despublicar del directorio de Peppol	Quita la entrada del catálogo buscable	Sí: sigue enviando y recibiendo
Despublicar de Peppol	Elimina el registro del participante en el SML	No: es la baja que libera el identificador
Migrar con código	Transfiere el registro a la PA nueva sin darlo de baja	Sí, sin interrupción

Solo la segunda libera el identificador. Mientras el registro del SML exista, activar el Tax Report Setting sobre ese identificador seguirá fallando con 422, aunque la otra PA haya despublicado el directorio. Es la confusión más habitual: si te asegura que ya te ha despublicado y la activación sigue fallando, pídele que confirme que ha eliminado el registro del SML y no solo la entrada del directorio.

La comprobación que hace B2Brouter al activar es una consulta DNS en vivo contra el SML, no una consulta a una base de datos nuestra. Por tanto no hay ningún plazo garantizado tras una baja, porque la propagación depende del SML y del DNS, pero puedes reintentar la activación cuando quieras y obtendrás el estado real de ese momento. El código de migración evita todo esto, porque no pasa por ninguna baja.

Venir a B2Brouter

Activar el Tax Report Setting sobre un identificador que publica otro proveedor falla con 422. Repite la misma llamada añadiendo el código que te haya dado ese proveedor:

POST /tax_report_settings con peppol_migration_code. Es la vía principal para Francia: mueve el identificador como parte de la misma activación.
POST /transports o PUT /transports/{code} con migration_code, si lo que creas es el transporte directamente.

Ambos campos son write-only y no aparecen en ningún GET. Si el código no sirve, la llamada falla con migration_code_malformed, migration_code_not_applicable o migration_code_rejected, este último con el motivo real del SML. No queda estado parcial: si la migración falla, el transporte no se crea.

Si la otra PA no te ofrece código ni te despublica, abre un ticket de soporte e iniciamos el procedimiento manual para reclamar tu portabilidad.

Salir de B2Brouter

POST /accounts/{ACCOUNT_ID}/transports/peppol/migration_code devuelve el código que tienes que dar al proveedor nuevo. Es idempotente: repetir la llamada devuelve el mismo código hasta que lo canceles con DELETE en la misma ruta, y un POST posterior genera uno nuevo.

Devuelve 409 not_published_by_b2brouter si el transporte es solo de emisión, porque entonces el identificador no lo publicamos nosotros.

El campo de solo lectura migration_pending de los GET de transportes dice si hay un código emitido y todavía no cancelado. El código en sí no se expone nunca en ningún GET.

Crear un contacto

Un contacto B2B francés necesita identificadores de enrutamiento (cómo llega la factura al destinatario) e identificación fiscal (cómo aparece el destinatario en el XML UBL).

Campo	Valor	Propósito
`cin_scheme`	`"0002"` (SIREN, por defecto) o `"0009"` (SIRET, para un establecimiento concreto)	ID de organización: usado para buscar al destinatario en el Annuaire
`cin_value`	SIREN o SIRET	ID de organización: el identificador registrado en el Annuaire
`tin_scheme`	`9957`	ID fiscal: código ISO 6523 para identificador fiscal francés
`tin_value`	`FR{kk}{siren}` (p. ej. `"FR22842917361"`)	ID fiscal: número de TVA francés en el XML UBL
`pin_scheme`	`"0225"`	EAS Peppol del participante FR (FRCTC Electronic Address), obligatorio para contactos franceses
`pin_value`	Composición Annuaire del destinatario	Identificador Peppol del contacto; sigue la misma composición que la matriz en el Annuaire (`SIREN`, `SIREN_SIRET`, `SIREN_SIRET_<CR>` o `SIREN_<SUFFIX>` — ver Niveles de identificador)
`country`	`"fr"`	Requerido para la lógica de enrutamiento de la DGFiP
`currency`	`"EUR"`	Moneda predeterminada para las facturas de este contacto
`transport_type_code`	`"peppol"`	Recomendado: garantiza la entrega a través de la red Peppol
`document_type_code`	`"xml.ubl.invoice.frcius.v1"`	Recomendado: formato de factura UBL France CIUS

Transporte y tipo de documento: Para contactos franceses registrados en el Annuaire, recomendamos establecer explícitamente transport_type_code: "peppol" y document_type_code: "xml.ubl.invoice.frcius.v1". Sin pin_value, la creación devuelve HTTP 422 (“Peppol Endpoint ID can’t be blank”). Puedes verificar que un contacto está registrado en el Annuaire antes de crearlo usando la búsqueda en el Directorio o el Directorio Peppol oficial.

Contactos en Bélgica, Alemania y otros países de la UE: Para facturas B2B a empresas no francesas, usa su esquema de identificador nacional (p. ej. "0208" para KBO/BCE belga, "0204" para el Leitweg-ID de las administraciones públicas alemanas, "0106" para KVK neerlandés) y el código country apropiado. Si el destinatario tiene un punto de acceso Peppol activo, B2Brouter enruta la factura a través del estándar Peppol BIS 3.0 — no se necesita configuración. Para transacciones con cualquier contacto no "fr", se genera automáticamente el e-Reporting transfronterizo Flux 10.

Ejemplo de solicitud:

curl --request POST \
  --url https://api-staging.b2brouter.net/accounts/{ACCOUNT_ID}/contacts \
  --header 'X-B2B-API-Key: {YOUR_API_KEY}' \
  --header 'X-B2B-API-Version: {YOUR_API_VERSION}' \
  --header 'Content-Type: application/json' \
  --data '{
    "contact": {
      "name": "Client Exemple SARL",
      "address": "25 Avenue de la République",
      "city": "Lyon",
      "postalcode": "69001",
      "country": "fr",
      "currency": "EUR",
      "language": "fr",
      "cin_scheme": "0002",
      "cin_value": "987654324",
      "tin_scheme": 9957,
      "tin_value": "FR14987654324",
      "pin_scheme": "0225",
      "pin_value": "987654324",
      "transport_type_code": "peppol",
      "document_type_code": "xml.ubl.invoice.frcius.v1"
    }
  }'

POST Contact - Referencia API

Direccionar un establecimiento concreto: si el cliente tiene varios establecimientos y necesitas identificar uno en particular, usa cin_scheme: "0009" con el SIRET de 14 dígitos y pin_value con la composición SIREN_SIRET (p. ej. 987654324_98765432400019) en lugar del SIREN solo.

Contactos con estructura multinivel: si tu cliente tiene varios establecimientos o servicios que hay que identificar por separado, crea primero el contacto matriz a nivel SIREN y después añade UOs con parent_id. Ver Estructura de la cuenta para la regla de oro y las estructuras aplicables.

Alternativa: contacto inline en la factura (sin el módulo de contactos)

En lugar de crear un contacto por separado y referenciarlo con contact_id, puedes enviar un objeto contact inline directamente dentro de POST /accounts/{ACCOUNT_ID}/invoices, con todos los datos del receptor:

{
  "invoice": {
    "type": "IssuedInvoice",
    "contact": {
      "name": "Client Exemple SARL",
      "country": "fr",
      "currency": "EUR",
      "language": "fr",
      "cin_scheme": "0009",
      "cin_value": "98765432400019",
      "tin_scheme": 9957,
      "tin_value": "FR14987654324",
      "pin_scheme": "0225",
      "pin_value": "987654324_98765432400019",
      "transport_type_code": "peppol",
      "document_type_code": "xml.ubl.invoice.frcius.v1"
    }
  }
}

⚠️ Aviso clave: pasa siempre todos los identificadores correctos (tin / cin / pin) con la composición FR correcta (matriz SIREN + UO), para no romper la coherencia matriz↔UO (ver La regla de oro). Desde la versión de API 2026-04-20, el sistema rechaza (422) un contacto inline no simplificado que no informe tin_value ni cin_value. currency y language son obligatorios en cualquier contacto; sin ellos la creación falla igualmente. El contacto inline también acepta routing_codes.cin1_scheme / routing_codes.cin1_value para identificar un servicio dentro de un SIRET (Caso 2), con los mismos valores ("224" y el Code Routage) que en un contacto creado a través del módulo de contactos.

Opcional: Verificar el enrutamiento del destinatario (búsqueda en el Directorio)

B2Brouter enruta las facturas automáticamente. Para inspeccionar cómo se enrutará un destinatario antes de enviar — por ejemplo, para confirmar que están registrados en el Annuaire — usa la búsqueda en el Directorio (Flux 11):

curl --request GET \
  --url https://api-staging.b2brouter.net/directory/fr/0009/98765432400019 \
  --header 'X-B2B-API-Key: {YOUR_API_KEY}' \
  --header 'X-B2B-API-Version: {YOUR_API_VERSION}'

Respuesta resuelta: ejemplo:

{
  "external_company": {
    "country": "fr",
    "cin_scheme": "0009",
    "cin_value": "98765432400019",
    "information_flags": ["FR_ASSUJETTI_ACTIVE"],
    "source": ["peppol", "annuaire"]
  }
}

Campos específicos de Francia:

Campo	Valores	Significado
`information_flags`	`FR_ASSUJETTI_ACTIVE`	Destinatario registrado y activo en el Annuaire del PPF
	`FR_ASSUJETTI_INACTIVE`	Destinatario con registro fuera de vigencia o sin PA asignada
	`FR_ASSUJETTI_UNKNOWN`	El PPF no tiene información concluyente (por ejemplo, 404)
`source`	array de `"peppol"`, `"annuaire"`	Orígenes consultados. Si aparecen ambos, B2Brouter ha encontrado al destinatario en los dos directorios

Esta consulta es informativa: B2Brouter ya resuelve el enrutamiento automáticamente al crear la factura (ver Verificación del Annuaire y generación de reportes fiscales). Úsala para inspeccionar antes de enviar o para mostrar el estado del destinatario en tu UI. No garantiza el enrutamiento realmente usado en el envío: si el destinatario resulta no localizable en Peppol, por defecto el envío se bloquea, o se degrada a correo electrónico si la cuenta ha activado el fallback Peppol → correo. Ver la nota más abajo.

GET Lookup Directory - Referencia API

Verificación del Annuaire y generación de reportes fiscales

B2Brouter verifica automáticamente si los contactos franceses (country: "fr") están registrados en el Annuaire de la DGFiP. Esta verificación determina el flujo de reporte fiscal:

Contacto registrado en el Annuaire (in_dgfip_annuaire: true o aún no verificado): la factura genera un reporte fiscal Flux 1 (facturación electrónica B2B nacional).
Contacto NO registrado en el Annuaire (in_dgfip_annuaire: false): la factura no genera un reporte fiscal. Esto evita envíos Flux 1 inválidos para destinatarios a los que el PPF no puede enrutar.
Contacto aún no verificado (in_dgfip_annuaire: nil): B2Brouter es permisivo — la factura procede y genera un reporte fiscal. La verificación ocurre de forma asíncrona en segundo plano.

Si creas un contacto francés e inmediatamente envías una factura, es posible que la verificación del Annuaire aún no se haya completado. Esto es por diseño — B2Brouter no bloquea la creación de facturas mientras la verificación está pendiente. Si el contacto resulta no estar registrado, las facturas futuras a ese contacto no generarán reportes fiscales Flux 1 hasta que el contacto se registre con una PA.

La verificación del Annuaire solo aplica a contactos nacionales franceses (country: "fr"). Los contactos no franceses siempre siguen la ruta de e-Reporting Flux 10, independientemente del estado del Annuaire.

Importante: ambas empresas en el Annuaire DGFiP: para un envío FR → FR con tax report Flux 1, tanto el emisor como el receptor deben estar registrados en el Annuaire de la DGFiP. Si una de las dos no está, el tax report no se puede completar y la factura se envía sin declaración fiscal.

Cómo comprobar el registro en el Annuaire DGFiP:

Producción → facturation.chorus-pro.gouv.fr/annuaire

Staging (QAS) → qas.facturation.chorus-pro.gouv.fr/annuaire

⚠️ La web annuaire-entreprises.data.gouv.fr es para datos fiscales generales; no garantiza el registro en el Annuaire DGFiP — son bases diferentes.

Desde septiembre de 2026 este comportamiento permisivo ya no se aplica: las declaraciones fallan si el identificador no consta como activable en la DGFiP, aunque el SIREN/SIRET sea válido.

Emitir facturas

Una vez que tu empresa está incorporada y el Tax Report Setting de la DGFiP está habilitado, la creación de facturas funciona a través de la API de Facturas estándar, POST /accounts/{ACCOUNT_ID}/invoices. B2Brouter gestiona todos los requisitos específicos de Francia automáticamente: generación de reportes fiscales, formato UBL/CII/Factur-X y transmisión al PPF a través de Flux 1.

Usa send_after_import: true para crear y transmitir en un solo paso. Establécelo en false si quieres crear la factura primero y revisarla antes de enviarla — en ese caso, la factura permanece en estado new hasta que actives la transmisión mediante una llamada separada o a través de la interfaz de B2Brouter.

Fecha de la factura
Para cuentas con DGFiP Tax Report Setting activo, la date de la factura no puede ser una fecha futura. Si se pasa una fecha posterior a hoy, el envío devuelve HTTP 422 (“Only invoices with today’s date are allowed”). Los ejemplos de esta guía usan fechas ficticias; sustitúyelas por la fecha actual cuando hagas pruebas.

Número de factura
⚠️ El number, con la serie incluida, puede tener hasta 35 caracteres (regla BR-FR-01). B2Brouter lo valida al crear la factura: un número más largo o con caracteres no permitidos devuelve HTTP 422. El límite de 20 caracteres solo se aplica a las facturas B2G para Chorus Pro.

Facturación secuencial
La API procesa una factura por solicitud. Para escenarios masivos o por lotes, itera a través de tu lista de facturas y llama al endpoint para cada documento. La API admite solicitudes concurrentes — puedes paralelizar múltiples POSTs sin esperar cada respuesta antes de iniciar el siguiente.

Factura B2B estándar

El caso más común: una factura B2B francesa nacional con TVA estándar (20%).

curl --request POST \
  --url https://api-staging.b2brouter.net/accounts/{ACCOUNT_ID}/invoices \
  --header 'X-B2B-API-Key: {YOUR_API_KEY}' \
  --header 'X-B2B-API-Version: {YOUR_API_VERSION}' \
  --header 'Content-Type: application/json' \
  --data '{
    "send_after_import": true,
    "invoice": {
      "type": "IssuedInvoice",
      "contact_id": 1313228381,
      "number": "FA-2026-0048",
      "date": "2026-09-15",
      "due_date": "2026-10-15",
      "currency": "EUR",
      "payment_method": 4,
      "bank_account_id": {YOUR_BANK_ACCOUNT_ID},
      "remittance_information": "FA-2026-0048",
      "payment_method_text": "Virement bancaire",
      "payment_terms": "Net 30 jours à compter de la date de facture.",
      "invoice_lines_attributes": [
        {
          "quantity": 10.0,
          "description": "Consulting services — architecture review",
          "price": 150.0,
          "unit": 9,
          "taxes_attributes": [
            { "name": "TVA", "percent": 20.0, "category": "S" }
          ]
        },
        {
          "quantity": 5.0,
          "description": "Training sessions — API integration",
          "price": 200.0,
          "unit": 9,
          "taxes_attributes": [
            { "name": "TVA", "percent": 20.0, "category": "S" }
          ]
        }
      ]
    }
  }'

El array tax_report_ids en la respuesta contiene el ID del reporte fiscal generado. Úsalo para hacer seguimiento del ciclo de vida de la presentación (ver Verificar el estado de un reporte fiscal).

POST Invoice - Referencia API

Campos de factura específicos de Francia

Información de pago

Los campos de pago solo llevan datos de pago:

Campo	EN 16931	Descripción	Requerido
`remittance_information`	BT-83	Referencia de pago (por ejemplo, el número de factura)	No
`payment_method_text`	BT-82	Descripción textual del método de pago	No
`payment_terms`	BT-20	Condiciones de pago (vencimiento, descuento por pronto pago que concedes, etc.)	No
`bank_account_id`	—	Id de la cuenta bancaria asociada a tu cuenta de B2Brouter. Obligatorio cuando `payment_method` es transferencia bancaria (código `4`)	Sí, si pago por transferencia

Estos campos nunca se usan como mención legal. No escribas en ellos las penalizaciones por demora, la indemnización de 40 € ni la mención de descuento: envíalas como menciones legales de pago.

Una factura con un importe a pagar positivo necesita due_date o payment_terms (regla BR-CO-25). Sin ninguno de los dos, la petición devuelve HTTP 422 («Due date can’t be blank»).

Cuenta bancaria: crea primero una cuenta bancaria asociada a tu empresa (desde la interfaz web o vía API) y referencia su id en la factura con bank_account_id. La cuenta bancaria contiene IBAN y BIC y es el único sitio donde deben ir: no los escribas en payment_method_text ni en una mención legal.

Menciones legales de pago (PMD, PMT, AAB)

Las facturas francesas llevan tres menciones legales de pago como notas de factura con código de tema (BT-21), una nota por código (reglas BR-FR-05 y BR-FR-06):

Código	Mención	Texto por defecto
`PMD`	Penalizaciones por demora en el pago (pénalités de retard)	Tout retard de paiement engendre une pénalité exigible à compter de la date d’échéance, calculée sur la base de trois fois le taux d’intérêt légal.
`PMT`	Indemnización a tanto alzado de 40 € por gastos de cobro (indemnité forfaitaire)	Indemnité forfaitaire pour frais de recouvrement en cas de retard de paiement : 40 €.
`AAB`	Descuento por pronto pago, o que no lo hay (escompte)	Les règlements reçus avant la date d’échéance ne donneront pas lieu à escompte.

Las menciones son opcionales en la petición. Si no envías una, B2Brouter pone el texto por defecto. Envía tu texto cuando el texto por defecto no se ajuste a tus condiciones, por ejemplo cuando aplicas un tipo de penalización concreto o cuando concedes un descuento por pronto pago: sin tu mención AAB, la factura dice que no hay descuento, aunque tus payment_terms digan lo contrario.

Cómo enviarlas depende de la versión de la API:

Versión de la API 2026-06-26 o posterior: usa el atributo coded_notes, con una entrada por mención.
```
"coded_notes": [
  { "subject_code": "PMD", "text": "Pénalités de retard : 12 % annuel, exigibles dès le lendemain de la date d'échéance." },
  { "subject_code": "PMT", "text": "Indemnité forfaitaire pour frais de recouvrement : 40 €." },
  { "subject_code": "AAB", "text": "Escompte de 2 % pour paiement sous 10 jours." }
]
```
Al actualizar, solo cambian los códigos que envías: cada código enviado sustituye las notas de la factura con ese código, y las demás notas se conservan. Para eliminar una mención, envía el código con _destroy: { "subject_code": "AAB", "_destroy": true }. Un array vacío, o no enviar el atributo, deja las notas como estaban. coded_notes también acepta otros códigos UNTDID 4451 (por ejemplo REG, AAI, TXD, o ABL para las menciones legales de la empresa como el RCS y el capital social, regla BR-FR-07), que salen como notas propias. ACC no se acepta: usa fa_clauses.

Versiones anteriores: escribe las menciones como etiquetas en extra_info:

#PMD#Pénalités de retard : 12 % annuel, exigibles dès le lendemain de la date d'échéance. #PMT#Indemnité forfaitaire pour frais de recouvrement : 40 €. #AAB#Escompte de 2 % pour paiement sous 10 jours.

Para cada código, B2Brouter toma el texto de la entrada de coded_notes; si no la hay, de la etiqueta de extra_info; y si tampoco la hay, usa el texto por defecto.

En una factura que se envía en un formato francés, la petición devuelve HTTP 422 cuando:

el mismo código (PMD, PMT, AAB o TXD) aparece más de una vez (BR-FR-06);
el texto de PMT o AAB supera los 255 caracteres;
una entrada de coded_notes no tiene subject_code o no tiene text.

Importación desde otros formatos (UBL, CII, Factur-X): no tienes que hacer nada. Cada nota PMD, PMT o AAB del fichero se conserva como nota propia con el mismo texto, y PaymentID (BT-83) y PaymentTerms (BT-20) conservan sus valores.

Líneas exentas de TVA (categoría E)

Cuando una línea tiene category: "E" (exenta de TVA), también debes proporcionar un comment con el código de exención VATEX-FR-CGI261-* aplicable (DGFiP BT-121):

⚠️ Bloqueo silencioso: Si se omite comment en una línea de categoría E, la factura se crea (HTTP 200) pero nunca se transmite al PPF. La respuesta contendrá un array errors no vacío — compruébalo incluso en respuestas exitosas.

Códigos de exención de TVA de la DGFiP (BT-121)

Código	Referencia legal	Categoría fiscal	Descripción
`VATEX-FR-FRANCHISE`	Art. 293 B CGI	E (exento)	Franchise en base de TVA (se envía al PPF como `Z`)
`VATEX-FR-CNWVAT`	—	E (exento)	Avoir net de taxe — nota de crédito sin TVA (el proveedor renuncia al ajuste de TVA). Solo notas de crédito (261/381/396, regla G6.21)
`VATEX-FR-AE`	—	AE	Autoliquidación (inversión del sujeto pasivo)
`VATEX-FR-CGI261-1`	Art. 261-1° CGI	E (exento)	Soins et services médicaux
`VATEX-FR-CGI261-2`	Art. 261-2° CGI	E (exento)	Services paramédicaux
`VATEX-FR-CGI261-3`	Art. 261-3° CGI	E (exento)	Enseignement scolaire, universitaire et formation professionnelle
`VATEX-EU-F` / `-I` / `-J`	—	E (exento)	Régimen del margen (régime de la marge)

Códigos de exención de nivel UE: además de los códigos nacionales VATEX-FR-* de arriba, la DGFiP también acepta la lista VATEX-EU-* (extensiones UNCL5305 / EN16931). El régimen del margen usa VATEX-EU-F, VATEX-EU-I o VATEX-EU-J en una línea de categoría E. Indica el código aplicable en el comment de la línea.

Franchise en base de TVA (VATEX-FR-FRANCHISE)

Las facturas en régimen de franchise en base de TVA llevan la categoría fiscal E con el código de exención VATEX-FR-FRANCHISE (regla BR-FR-CO-16). Para facturas de franchise, establece percent: 0.0 y category: "E" con comment: "VATEX-FR-FRANCHISE" en cada línea de impuesto. La factura conserva la categoría E: B2Brouter solo la transcodifica a Z en los datos que envía al PPF (regla BR-FR-MAP-08):

{
  "taxes_attributes": [
    {
      "name": "TVA",
      "percent": 0.0,
      "category": "E",
      "comment": "VATEX-FR-FRANCHISE"
    }
  ]
}

Operaciones fuera del ámbito de la TVA (categoría O)

Algunas operaciones quedan fuera del ámbito de aplicación de la TVA y deben llevar la categoría O con percent: 0.0, no la categoría E (exenta) ni Z (tipo cero). Dos casos habituales:

Détaxe (operaciones fuera del ámbito de la TVA): la línea no lleva TVA.
Débours (gastos reembolsables adelantados en nombre del cliente): se traspasan sin TVA.

{
  "taxes_attributes": [
    { "name": "TVA", "percent": 0.0, "category": "O" }
  ]
}

El reporte fiscal del Flux 1 sintetiza automáticamente el TaxSubtotal de categoría O correspondiente. La categoría NS también se acepta y se transcodifica a O.

Nota de crédito

Desde la versión de API 2026-04-20, para emitir una nota de crédito referencia la factura original con invoice_references:

"invoice_references": [
  {
    "reference_type": "amend",
    "number": "FA-2026-0048",
    "date": "2026-09-15",
    "reason": "Annule et remplace",
    "correction_method": "01"
  }
]

B2Brouter genera un CreditNote UBL con código de tipo 381 e incluye la referencia de facturación.

curl --request POST \
  --url https://api-staging.b2brouter.net/accounts/{ACCOUNT_ID}/invoices \
  --header 'X-B2B-API-Key: {YOUR_API_KEY}' \
  --header 'X-B2B-API-Version: {YOUR_API_VERSION}' \
  --header 'Content-Type: application/json' \
  --data '{
    "send_after_import": true,
    "invoice": {
      "type": "IssuedInvoice",
      "contact_id": 1313228381,
      "number": "NC-2026-001",
      "date": "2026-09-25",
      "due_date": "2026-10-25",
      "is_credit_note": true,
      "invoice_references": [
        {
          "reference_type": "amend",
          "number": "FA-2026-0048",
          "date": "2026-09-15",
          "reason": "Annule et remplace",
          "correction_method": "01"
        }
      ],
      "currency": "EUR",
      "payment_method": 4,
      "bank_account_id": {YOUR_BANK_ACCOUNT_ID},
      "remittance_information": "Pénalités de retard : trois fois le taux d'intérêt légal.",
      "payment_method_text": "Indemnité forfaitaire pour frais de recouvrement en cas de retard de paiement : 40 €.",
      "payment_terms": "Pas d'escompte pour paiement anticipé.",
      "invoice_lines_attributes": [
        {
          "quantity": -1.0,
          "description": "Annulation partielle — Consulting services",
          "price": 500.0,
          "unit": 9,
          "taxes_attributes": [
            { "name": "TVA", "percent": 20.0, "category": "S" }
          ]
        }
      ]
    }
  }'

Campos legacy: en versiones de API anteriores a 2026-04-20, la nota de crédito se expresaba con is_amend: true + amended_number + amended_date en lugar de invoice_references. Estos campos siguen siendo aceptados en esas versiones por compatibilidad, pero quedan como legacy: para integraciones nuevas, usa invoice_references.

Códigos de proceso

El código de proceso determina el flux cadre del PPF. B2Brouter lo asigna automáticamente según type_operation en el Tax Report Setting y las características de la factura. Para indicar un código concreto (por ejemplo S7 o B7), envía transaction_type_code en la factura.

Código de proceso	Tipo de operación	Descripción
S1	Servicios	Factura estándar de servicios
B1	Bienes	Factura estándar de bienes
M1	Mixto	Factura estándar de operaciones mixtas
S2	Servicios	Factura pagada de servicios
B2	Bienes	Factura pagada de bienes
M2	Mixto	Factura pagada de operaciones mixtas
S4	Servicios	Factura con pagos a cuenta (servicios)
B4	Bienes	Factura con pagos a cuenta (bienes)
M4	Mixto	Factura con pagos a cuenta (mixto)
S7	Servicios	TVA ya recaudada (servicios): venta ya declarada por e-reporting B2C (o en la declaración de TVA) y facturada después a una empresa. Consulta el caso 30
B7	Bienes	TVA ya recaudada (bienes): venta ya declarada por e-reporting B2C (o en la declaración de TVA) y facturada después a una empresa. Consulta el caso 30

Facturas mixtas en el Flux 1: con type_operation: "mixed", el reporte fiscal del Flux 1 lleva M1, M2 o M4 y reporta todos los breakdowns de la factura. No existe el código M7: una factura mixta con la TVA ya declarada por e-reporting B2C lleva S7. La regla de declarar solo los servicios se aplica a los datos de cobro (212), no al Flux 1.

Formatos de documento

Código de tipo de documento	Formato	Descripción
`xml.ubl.invoice.frcius.v1`	UBL XML	Factura Peppol France CIUS (Flux 1 / Annuaire)
`xml.cii.cross_industry_invoice.frcius.v1`	CII XML	Factura CII France CIUS
`xml.cii.cross_industry_invoice.facturx.fr.all_profiles.v1`	Factur-X (CII XML)	Factura France CIUS Factur-X (todos los perfiles)

Por defecto, cuando el destinatario es un contacto francés registrado en el Annuaire pero la consulta de su participante SMP en Peppol confirma que está ausente, B2Brouter bloquea el envío con un error de validación peppol_endpoint_not_registered_to_receive, tenga o no el contacto un document_type_code guardado. Para que B2Brouter redirija la factura a correo electrónico en su lugar, hay que establecer peppol_email_fallback: true en el Tax Report Setting de DGFiP de la cuenta con un PATCH; también disponible como casilla en ⚙ Configuración de la cuenta → e-Reporting France.

Con el fallback activado:

La factura se envía por correo electrónico, en formato Factur-X France CIUS (EN 16931, con las menciones francesas, como el modo de facturación BT-23). La configuración del contacto no cambia, y el reporte fiscal del Flux 1 se deposita igualmente por el circuito SFTP de la DGFiP, independientemente del transporte utilizado.
Señal: to_net informa "email" en la factura enviada, y document_type_code refleja el formato realmente utilizado, fijado en el momento de la emisión.
Sin señal previa: sigue sin haber manera de saber que una factura se redirigirá antes de enviarla. Solo se puede detectar después a partir de to_net.
Los identificadores mal formados fallan en silencio: un BT-49 (Peppol Endpoint ID) incorrecto o irresoluble se clasifica como “no localizado en Peppol” y se degrada a correo sin error. Verifica con cuidado los identificadores de tus contactos.

Con el fallback desactivado (el valor por defecto), ese mismo BT-49 mal formado o irresoluble se muestra como el error de validación de bloqueo anterior, de modo que lo detectas antes de que la factura se emita.

Importación de Factur-X y UBL XML

Si tu sistema ya genera facturas Factur-X o UBL XML, envíalas directamente usando el endpoint de importación de documentos:

POST /accounts/{id}/invoices/import

Establece Content-Type como:

application/pdf: para Factur-X (PDF/A-3 con CII XML integrado)
application/xml: para UBL 2.1 o CII XML independientes

Ciclo de vida de la factura

Francia usa un modelo en Y (5 esquinas), no de clearance. La factura se transmite al receptor con independencia de que se registre un reporte fiscal Flux 1; el PPF no valida previamente las facturas antes de que lleguen al receptor. La Factura y el Reporte fiscal son ciclos de vida separados que solo coinciden en la entrega del Flux 1. Un error en el reporte fiscal no deshace una factura que ya ha llegado al receptor.

Estados ↔ CDV de la factura emitida

Estado	CDV	Origen	Descripción
`sending`	—	B2Brouter (C1)	La factura se ha creado y está en cola para transmitirse al PPF
`sent`	`200:Déposée`	B2Brouter (C2)	La factura se ha enviado al receptor y al PPF correctamente
`registered`	`202:Reçue`	Receptor (C3)	El sistema del receptor ha recibido la factura
`read`	`204:Prise en charge`	Receptor (C4)	El receptor ha visualizado la factura
`accepted`	`205:Approuvée`	Receptor (C4)	El receptor ha aprobado la factura
`accepted`¹	`206:Approuvée partiellement`	Receptor (C4)	El receptor ha aprobado la factura parcialmente
`annotated`	`207:En litige`	Receptor (C4)	El receptor ha puesto la factura en litigio
`refused`	`210:Refusée`	Receptor (C4)	El receptor ha rechazado la factura²
`paid`	`212:Encaissée`	Emisor (C1)	Has registrado el cobro de la factura. B2Brouter envía el `212` solo para prestaciones de servicios. Ver Estado Encaissée: confirmación de pago.
`error`	—	Diversos	La validación previa o la transmisión han fallado. El campo `errors` contiene el motivo. Ver Cómo gestionar facturas con error.

¹ El CDV 206 fija el mismo estado que el 205: accepted. El estado de la factura no distingue una aprobación total de una parcial. El importe que ha aprobado el receptor queda registrado como metadato del evento correspondiente, no como campo de la factura.
² El payload de la factura lleva refuse_reason_code con el motivo estructurado del rechazo.

Cómo gestionar facturas con error

Antes del envío:
Para que una factura se pueda enviar, tiene que pasar la validación del schematron. Si no la pasa, el envío devuelve HTTP 422, la factura queda en estado error y no se crea ningún tax report. El mensaje cita el código de la regla que ha fallado, por ejemplo G1.24 para un tipo de TVA no válido. El campo errors contiene el motivo del rechazo, edita la factura con un PATCH y vuelve a enviarla, o elimínala y crea una nueva. No hay ningún endpoint de reintento: el camino es corregir y reenviar.

Después del envío:
DELETE y PATCH devuelven 422: la factura está dentro del ciclo de vida del receptor y la corrección se hace con una nota de crédito. La excepción es el depósito fallido: mientras todos sus tax reports estén en estado error o refused y la factura no haya llegado al receptor, todavía puedes corregirla con un PATCH y volver a enviarla. DELETE sigue devolviendo 422: una factura con un tax report, en cualquier estado, no se puede eliminar.

Seguimiento de estados de la factura

Webhooks (recomendado)

Configura los endpoints de webhook en la interfaz de B2Brouter bajo Configuración → Webhooks. Una vez configurado, B2Brouter envía un HTTP POST a tu endpoint cada vez que la factura alcanza un nuevo estado.

Invoice Status WebHooks - Referencia API

Polling

curl --request GET \
  --url https://api-staging.b2brouter.net/invoices/{INVOICE_ID} \
  --header 'X-B2B-API-Key: {YOUR_API_KEY}' \
  --header 'X-B2B-API-Version: {YOUR_API_VERSION}' \
  --header 'Accept: application/json'

GET Invoice - Referencia API

Descargar el documento de factura original

Después de que una factura alcanza el estado sent, la respuesta de GET /invoices/{id} incluye un campo download_legal_url. Úsalo para descargar el documento de factura que fue transmitido:

curl --request GET \
  --url https://api-staging.b2brouter.net{download_legal_url} \
  --header 'X-B2B-API-Key: {YOUR_API_KEY}' \
  --header 'X-B2B-API-Version: {YOUR_API_VERSION}'

Como alternativa en un solo paso, puedes llamar directamente a GET /invoices/{id}/as/legal, sin obtener antes download_legal_url del payload de la factura. Devuelve el documento legal archivado tal como está almacenado y no genera ninguna transacción facturable — consulta Descargar facturas y Transaction: View_as.

Estado Encaissée: confirmación de pago

Encaissée es el último estado del ciclo CDV de una factura B2B francesa. No lo envía el receptor sino el emisor: B2Brouter lo envía en tu nombre cuando registras un cobro de la factura (ver el mapping CDV completo en la tabla Estados de la factura). Según el art. 41 septies G del anexo IV del CGI, solo corresponde a las prestaciones de servicios: B2Brouter no lo envía para las entregas de bienes ni para los breakdowns con autoliquidación (categoría AE), y en una factura mixta solo declara los breakdowns de servicios. En una factura recibida, marcarla como pagada envía el 211 al proveedor (ver Cómo responder).

B2Brouter propaga la confirmación de pago al PPF por una de dos vías, según la naturaleza de la factura:

Caso	Vía	Mecanismo
Nacional FR → FR (B2Brouter detecta `company.country == "fr"` y `contact.country == "fr"`)	CDAR	Envía un mensaje CDV `212` (transición de estado) sin generar un tax report adicional
Transfronteriza (B2B intra-UE / extra-UE) o B2C (`IssuedSimplifiedInvoice`)	Fichero Flux 10 payments	Genera un tax report en el Ledger C (payments) (ver Modelo de 3 ledgers)

Marcar una factura como pagada vía API

Cuando el cobro está confirmado, marca la factura en el PPF con una llamada al mark_as:

curl --request POST \
  --url https://api-staging.b2brouter.net/invoices/{INVOICE_ID}/mark_as \
  --header 'X-B2B-API-Key: {YOUR_API_KEY}' \
  --header 'X-B2B-API-Version: {YOUR_API_VERSION}' \
  --header 'Content-Type: application/json' \
  --data '{"state":"paid"}'

Pagos parciales

Los pagos parciales se registran con el endpoint POST /accounts/{ACCOUNT_ID}/payments, indicando amount e invoice_id. Repite la llamada por cada pago que recibas; cuando la suma de los importes registrados cubre el total de la factura, esta pasa automáticamente al estado paid.

curl --request POST \
  --url https://api-staging.b2brouter.net/accounts/{ACCOUNT_ID}/payments \
  --header 'X-B2B-API-Key: {YOUR_API_KEY}' \
  --header 'X-B2B-API-Version: {YOUR_API_VERSION}' \
  --header 'Content-Type: application/json' \
  --data '{
    "payment": {
      "invoice_id": {INVOICE_ID},
      "amount": 900.00
    }
  }'

Requiere X-B2B-API-Version: 2026-03-02 o posterior.

Para un pago completo en una sola operación, también puedes usar directamente mark_as con state: "paid" (ver Marcar una factura como pagada vía API); no es necesario pasar antes por POST /accounts/{ACCOUNT_ID}/payments.

Alternativamente, puedes gestionar los cobros desde la app de B2Brouter: abre la factura → Crear cobro → define el importe pagado.

Notas sobre pagos:

Puedes pasar full: true en lugar de amount para registrar el pago completo pendiente: B2Brouter calcula el importe pendiente en el momento de ejecutar la llamada y nunca supera el total de la factura. Si en cambio indicas un amount explícito, no hay ninguna protección contra el sobrepago: es tu responsabilidad no superar el total pendiente.

Eliminar un pago no reabre la factura: se queda en el estado paid.

Si el pago ha generado un tax report de Flux 10 (factura cross-border o B2C), el PUT/DELETE de ese pago devuelve HTTP 422 por el bloqueo de la declaración ya enviada. El caso doméstico FR-FR (CDV 212, sin tax report adicional) no tiene ese bloqueo.

Recepción de facturas

Como empresa francesa registrada en el Annuaire con un transporte Peppol 0225, recibes automáticamente facturas electrónicas de otras plataformas francesas y conectadas a Peppol.

Responder a una factura recibida

Como receptor, respondes con POST /invoices/{id}/mark_as. La mecánica general del mark_as, común a todos los países, está en Cambiar el estado de la factura.

Cada transición de estado emite el CDV correspondiente hacia el emisor. Los rechazos automáticos (213) son la excepción: no piden ninguna llamada, porque B2Brouter deriva el código de motivo de la DGFiP de los errores de validación (REJ_COH si no hay ninguno que clasificar).

Cómo responder: llamada, estado y CDV

Estado	CDV	Llamada	Descripción
`read`	`204:Prise en charge`	`state: "read"`	Te haces cargo de la factura
`accepted`	`205:Approuvée`	`state: "accepted"`	Apruebas la factura
`accepted`	`206:Approuvée partiellement`	`state: "accepted"` + `amount` + `amount_code`¹ + `reason`	Apruebas la factura parcialmente
`annotated`	`207:En litige`	`state: "annotated"` + `dispute: true`² + `reason`	Pones la factura en litigio
`refused`	`210:Refusée`	`state: "refused"` + `reason_code`³	Rechazas la factura
`paid`	`211:Paiement transmis`	`state: "paid"`	Avisas al proveedor de que has pagado la factura. No se envía a la DGFiP

El reason es obligatorio en los casos 206 y 207: sin él, la llamada devuelve 422.

¹ Los valores de amount_code son MAP, MAPTTC, MNA y MNATTC.
² Sin dispute: true, el estado annotated solo contabiliza internamente y no envía ningún CDV.
³ El reason_code es opcional en la llamada, pero el 210 siempre lleva un motivo: si no lo envías, B2Brouter pone NON_CONFORME. Ver Códigos de rechazo.

Ejemplo de petición de aprobación parcial:

curl --request POST \
  --url https://api-staging.b2brouter.net/invoices/{INVOICE_ID}/mark_as \
  --header 'X-B2B-API-Key: {YOUR_API_KEY}' \
  --header 'X-B2B-API-Version: {YOUR_API_VERSION}' \
  --header 'accept: application/json' \
  --header 'content-type: application/json' \
  --data '{
    "state": "accepted",
    "amount": 250.00,
    "amount_code": "MAP",
    "reason": "Una línea no corresponde al pedido"
  }'

Códigos de rechazo

Cuando rechazas una factura puedes añadir un reason_code con el motivo estructurado de la DGFiP: ADR_ERR, REF_CT_ABSENT, CMD_ERR, TX_TVA_ERR, MONTANTTOTAL_ERR, CALCUL_ERR, DOUBLON, NON_CONFORME, DEST_ERR, TRANSAC_INC, EMMET_INC, CONTRAT_TERM y DOUBLE_FACT.

La API también acepta AUTRE, pero la DGFiP no lo permite en un rechazo.

La DGFiP rechaza un rechazo sin comentario. Si no envías ningún reason, B2Brouter escribe el comentario a partir de la etiqueta oficial del reason_code, o del código por defecto NON_CONFORME si no envías ninguno, y el historial de la factura muestra «Comentario del rechazo generado a partir del código de motivo». En la aplicación web el motivo es obligatorio.

Ejemplo de petición:

POST /invoices/{id}/mark_as
{
  "state": "refused",
  "reason": "Incorrect total amount",
  "reason_code": "MONTANTTOTAL_ERR"
}

Ejemplo de respuesta (extracto):

{
  "invoice": {
    "id": 12345,
    "state": "refused",
    "refuse_reason": "Incorrect total amount",
    "refuse_reason_code": "MONTANTTOTAL_ERR"
  }
}

POST mark_as - Referencia API

Verificar el estado de un reporte fiscal

El reporte fiscal hace seguimiento del ciclo de vida técnico de la presentación al PPF. Tanto la generación XML como la transmisión al PPF son asíncronas.

Flux 1: Facturas B2B nacionales

Estado	Descripción
`new`	Reporte fiscal creado, en cola para transmisión
`sent`	Documento depositado en el PPF via SFTP
`acknowledged`	El PPF ha recibido y validado el archivo (condición CDV 500: Recevable)
`registered`	✅ Terminal: Factura aceptada y registrada por la DGFiP (condición CDV 250)
`refused`	❌ Terminal: Rechazada por la DGFiP (condición CDV 251)
`error`	❌ Terminal: Error de transmisión o procesamiento del PPF (p. ej. condición CDV 501: Irrecevable)

Flux 10: Facturas B2B transfronterizas y B2C (e-Reporting)

Estado	Descripción
`new`	Reporte fiscal creado, acumulado para el lote diario del ledger
`sent`	Ledger depositado en el PPF via SFTP
`acknowledged`	El PPF ha recibido el ledger (condición CDV 500: Recevable)
`registered`	✅ Terminal: Ledger aceptado y registrado por la DGFiP (condición CDV 300)
`refused`	❌ Terminal: Rechazado por la DGFiP (condición CDV 301)
`error`	❌ Terminal: Error de transmisión o procesamiento del PPF (p. ej. condición CDV 501: Irrecevable)

Polling

Consulta el estado usando el ID del reporte fiscal de tax_report_ids en la respuesta de la factura:

curl --request GET \
  --url https://api-staging.b2brouter.net/tax_reports/{TAX_REPORT_ID} \
  --header 'X-B2B-API-Key: {YOUR_API_KEY}' \
  --header 'X-B2B-API-Version: {YOUR_API_VERSION}'

GET Tax Report - Referencia API

e-Reporting (Flux 10)

Flux 10 cubre las transacciones fuera del ámbito de la obligación de facturación electrónica B2B nacional que aún deben reportarse a la DGFiP. B2Brouter gestiona Flux 10 automáticamente.

Si ya generas tu propio <Report> F10 y solo necesitas un canal acreditado para depositarlo, consulta Flux 10: depositar un archivo que genera tu sistema.

Transacciones B2C

Ventas a personas físicas no registradas como sujetos pasivos de TVA en Francia. Usa "type": "IssuedSimplifiedInvoice". El contact_id y los campos de pago no son requeridos para facturas B2C.

Transacciones transfronterizas (B2B intra-UE y extra-UE)

Las ventas a o compras de empresas establecidas fuera de Francia deben reportarse a través de Flux 10. Usa el tipo estándar IssuedInvoice o ReceivedInvoice y establece el country de la contraparte al valor no "fr" correspondiente. B2Brouter detecta automáticamente la naturaleza transfronteriza.

Territorios franceses de ultramar (el contacto de la factura, no tu cuenta): los departamentos DROM Guadalupe (gp), Martinica (mq) y La Reunión (re) se tratan como Francia nacional. Las facturas a contactos de esos territorios generan un reporte fiscal del Flux 1 y llevan IdentificationCode FR, exactamente igual que la Francia metropolitana. El resto de territorios de ultramar (Guayana gf, Mayotte yt, Polinesia Francesa pf, Nueva Caledonia nc, TAAF tf, San Pedro y Miquelón pm) quedan fuera del territorio de la TVA francesa y siguen la vía de e-Reporting del Flux 10. Este párrafo habla de la contraparte de la factura; para la cuenta que emite, ver Estructura de la cuenta.

Ledgers Flux 10

B2Brouter agrupa los reportes fiscales Flux 10 en Ledgers enviados al PPF. La frecuencia de envío no es siempre diaria: depende del vat_regime configurado en el Tax Report Setting (ver Campos del Tax Report Setting de la DGFiP), cada diez días o mensual según el régimen, o bimensual para franchise_en_base. En staging, los ledgers se depositan diariamente para facilitar las pruebas; en producción, siguen la periodicidad real del régimen. Puedes identificar los reportes fiscales Flux 10 por un ledger_id no nulo en la respuesta del reporte fiscal.

Modelo de 3 ledgers

Cada ledger se identifica por dos dimensiones internas:

Rol DGFiP (SE o BY):
- SE (Seller / émission): para las ventas que emites.
- BY (Buyer / réception): para las compras intracomunitarias que tienes que declarar como comprador.
Modo (transactions o payments):
- transactions: ledgers de facturas (códigos de proceso S1 / B1 / M1), document type xml.ledger.dgfip.transactions.
- payments: ledgers de pagos (códigos de proceso S2 / B2 / M2, TVA sobre servicios devenga al cobro), document type xml.ledger.dgfip.payments.

La combinación de roles y modos da hasta 3 ledgers por cuenta y período de reporte:

Ledger	Rol	Modo	Contenido
A: Emisión	`SE`	`transactions`	Facturas emitidas (B2C y cross-border B2B)
B: Recepción	`BY`	`transactions`	Compras intracomunitarias / extra-UE declaradas como comprador
C: Pagos	`SE`	`payments`	Pagos confirmados de tus facturas emitidas (caso Encaissée cross-border / B2C)

El par (BY, payments) no existe: la información de pago de tus compras la genera el vendedor desde su lado; no la declaras tú.

Cada tax report se vincula a un único ledger_id (no pertenece a más de un ledger a la vez). La agrupación se hace por cuenta + período de reporte + (rol, modo) bajo lock para evitar duplicados.

Recursos adicionales

Guías:

Casos de uso soportados: los 44 casos de uso de la RFE (XP Z12-014) y cuáles cubre B2Brouter.
Guía de Tax Report Settings: el endpoint de Tax Report Settings a fondo, para todos los países, no solo Francia.
Recibir, integrar y gestionar facturas recibidas: cómo responder a una factura recibida con mark_as, para cualquier red.

Casos de uso:

Enviar facturas a Chorus Pro (B2G): circuito para facturas dirigidas al sector público francés.
Flux 10: depositar un archivo que genera tu sistema: depositar en el PPF un archivo de e-Reporting que has generado en tu sistema.

Otros:

Recursos externos:

DGFiP: reforma de facturación electrónica francesa

DGFiP e-Invoicing y e-Reporting

Guía para integrar la API de B2Brouter y cumplir con la RFE francesa desde tu propio sistema.

¿Para quién es esta guía?

Antes de empezar: elige tu entorno

Opción A: Piloto de producción

Opción B: Staging (recomendado para evaluación)

Obtener identificadores de prueba a través del QAS de Chorus Pro

Credenciales de la API

Estructura de la cuenta: matriz y unidades organizativas

La regla de oro

Contactos

Identificadores y esquemas

Identificadores en B2Brouter

Identificador publicado en el Annuaire

Escenarios y casos

Tabla de casos

Crear la cuenta de tu empresa

Crear la cuenta matriz con el SIREN

Campos específicos de una cuenta francesa:

Añadir los establecimientos como unidades organizativas (opcional)

Restricciones:

Campos obligatorios en todos los payloads UO:

Campos de creación y resultado en el Annuaire

Ejemplos de payload

Caso 1 y 2: UO de tipo Établissement con Service opcional

Caso 3: UO de tipo Suffix

Activar el Tax Report Setting

Campos del Tax Report Setting de la DGFiP

Regímenes de TVA y frecuencia de transmisión

Modos del Tax Report Setting

annuaire_only: solo recibir

issue_only: emitir desde B2Brouter manteniendo la recepción donde está

Habilitar la emisión Peppol

Cambiar de PA

Despublicar, dar de baja y migrar

Venir a B2Brouter

Salir de B2Brouter

Crear un contacto

Alternativa: contacto inline en la factura (sin el módulo de contactos)

Opcional: Verificar el enrutamiento del destinatario (búsqueda en el Directorio)

Verificación del Annuaire y generación de reportes fiscales

Emitir facturas

Factura B2B estándar

Campos de factura específicos de Francia

Información de pago

Menciones legales de pago (PMD, PMT, AAB)

Líneas exentas de TVA (categoría E)

Franchise en base de TVA (VATEX-FR-FRANCHISE)

Operaciones fuera del ámbito de la TVA (categoría O)

Nota de crédito

Códigos de proceso

Formatos de documento

Importación de Factur-X y UBL XML

Ciclo de vida de la factura

Estados ↔ CDV de la factura emitida

Cómo gestionar facturas con error

Seguimiento de estados de la factura

Webhooks (recomendado)

Polling

Descargar el documento de factura original

Estado Encaissée: confirmación de pago

Marcar una factura como pagada vía API

Pagos parciales

Recepción de facturas

Responder a una factura recibida

Cómo responder: llamada, estado y CDV

Códigos de rechazo

Verificar el estado de un reporte fiscal

Polling

e-Reporting (Flux 10)

Transacciones B2C

Transacciones transfronterizas (B2B intra-UE y extra-UE)

Ledgers Flux 10

Modelo de 3 ledgers

Recursos adicionales

Guías:

Casos de uso:

Otros:

Recursos externos:

`annuaire_only`: solo recibir

`issue_only`: emitir desde B2Brouter manteniendo la recepción donde está