A partir de septiembre de 2026, todas las empresas francesas deberán enrutar sus facturas y datos de IVA a través de una plataforma certificada. 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 comprador
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 diarios enviados al PPF
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, informes 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
Contexto regulatorio: La reforma de facturación electrónica francesa obliga a todas las empresas francesas a utilizar una Plateforme Agréée (PA) certificada o el PPF (Portail Public de Facturation) del gobierno para transmitir facturas y reportar datos de IVA a la DGFiP, a partir de septiembre de 2026. 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.
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, al activar el Tax Report Setting sobre la cuenta SIREN (Paso 2) se transfiere automáticamente la entrada del Annuaire a B2Brouter. 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 comprador 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 — las presentaciones a la DGFiP se simulan en sandbox, no se requiere SIRET ficticio. 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.
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.
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 está diseñada para facturas B2B reales a partir de septiembre de 2026. Mientras tanto, la DGFiP borrará los registros del período QAS antes de que la reforma entre en vigor — por lo que cualquier factura que envíes durante tu piloto no creará 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.
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 (activar B2Brouter en producción transferiría la entrada)
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 IVA 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:
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.
Crea tu cuenta de empresa usando un SIREN del CSV (ver Paso 1).
Suscríbete a un plan eDocExchange (las suscripciones de staging son simuladas — sin cargo).
Activa el Tax Report Setting de la DGFiP (ver Paso 2).
⚠️ Tras activar el Tax Report Setting de la DGFiP, el registro del Annuaire de tu empresa tarda hasta 24 horas en propagarse — tanto en staging como en producción. Esta es una restricción de la infraestructura de la DGFiP, no un retraso de B2Brouter. No podrás enviar facturas hasta el día siguiente.
Al día siguiente: crea un contacto de prueba usando un segundo SIREN del CSV (ver Paso 3).
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
Una empresa francesa con varios establecimientos o servicios se modela en B2Brouter como una cuenta matriz (la entidad principal) y, opcionalmente, una o varias unidades organizativas (UOs) colgadas de la matriz. La factura siempre se emite desde una matriz o desde una UO concreta, pero el grupo de integración es común.
La cuenta matriz siempre es a nivel de SIREN (cin_scheme="0002", la entidad legal). Un SIRET nunca es matriz: crear una matriz francesa con cin_scheme="0009" devuelve 422 parameter_matriu_must_be_siren. Los establecimientos (SIRET) y servicios se modelan siempre como UOs bajo esa matriz SIREN.
Lo que cambia según tu situación no es el nivel de la matriz sino dónde activas el Tax Report Setting de la DGFiP:
Si el SIREN aún no está registrado en ninguna otra Plateforme Agréée (PA): activa el Tax Report Setting sobre la matriz SIREN. Las UOs sin Tax Report Setting propio declaran a través de la matriz automáticamente. Es el flujo estándar (Escenario 1).
Si el SIREN ya está registrado en otra PA y solo quieres llevar a B2Brouter un establecimiento concreto: mantén la matriz a SIREN pero no actives el Tax Report Setting sobre ella (transferiría la entrada existente del Annuaire). En su lugar, crea el establecimiento como UO SIRET y activa el Tax Report Setting sobre esa UO, de modo que el registro existente del SIREN quede intacto (Escenario 2).
Esta decisión determina dónde se activa la declaración, no el identificador de la matriz (que siempre es SIREN). Si dudas si tu SIREN ya está registrado, consulta primero el Annuaire con el Directory lookup.
Cuentas legacy (normalización): hasta junio de 2026, la plataforma permitía crear una cuenta matriz con un SIRET. Si tienes cuentas creadas así, deben normalizarse: sustituir el identificador de la matriz por el SIREN (cin_scheme="0002", cin_value = el SIREN de 9 dígitos) y crear el SIRET correspondiente como UO bajo esa matriz SIREN.
En B2Brouter, una cuenta o contacto francés se define con un identificador principal (cin_scheme + cin_value) y, opcionalmente, un sub-identificador (routing_codes.cin1_scheme + routing_codes.cin1_value) cuando hay que apuntar a un servicio concreto dentro de un establecimiento.
Identificador principal de la cuenta / UO (cin_scheme + cin_value):
cin_scheme
Identificador
Formato
Ejemplo
0002 (2)
SIREN — entidad legal
9 dígitos + Luhn
123456789
0009 (9)
SIRET — establecimiento
14 dígitos (SIREN + 5 dígitos) + Luhn
12345678900012
8040
Suffix — UO sin SIRET propio
Alfanumérico [A-Za-z0-9_\-\/]+
SUF01, ADMIN
Sub-identificador (routing code) — solo para UOs SIRET con varios servicios internos:
EAS Peppol del participante FR: el identificador electrónico en la red Peppol siempre es 0225 (FRCTC Electronic Address). Los schemes 224 (Code Routage) y 8040 (Suffix) son sub-identificadores internos del directorio y no se publican como EAS Peppol propio.
Suffix vs Code Routage — El Suffix (8040) es el cin_scheme principal de una UO sin SIRET propio. El Code Routage (224), en cambio, siempre va en routing_codes.cin1_scheme="224" de una UO con SIRET — nunca como cin_scheme principal.
Importante: un SIRET solo (sin SIREN delante) no es un identificador completo publicado válido. Un SIRET vive siempre en una UO bajo la matriz SIREN; la composición publicada es SIREN_SIRET, donde el SIREN proviene de la cuenta matriz.
Ver los 4 formatos finales de identificador en el Annuaire
Composición Annuaire
Qué representa
SIREN
Entidad entera (matriz)
SIREN_SIRET
Establecimiento (Caso 1 / Caso 4)
SIREN_SIRET_<CR>
Servicio dentro de un establecimiento (Caso 2 / Caso 5)
SIREN_<SUFFIX>
UO sin SIRET propio (Caso 3 / Caso 6)
Ninguna de estas composiciones es issue-only por sí misma — tampoco la fila SIREN sola. Que una dirección también reciba facturas (que se publique un transporte 0225 para ella) depende únicamente del flag issue_only de ese Tax Report Setting, no de la composición utilizada. Ver la nota sobre issue_only en el Escenario 3 más abajo.
Para ver los campos exactos de la API que generan cada formato, consulta la tabla Casos y topologías más abajo.
La estructura depende de dos factores: si el SIREN está libre de otras PAs y si quieres emitir o también recibir. Tres escenarios cubren todas las configuraciones habituales.
Si el SIREN ya está registrado en otra PA y quieres llevar a B2Brouter un establecimiento concreto sin alterar ese registro existente, la matriz sigue siendo a nivel de SIREN (un SIRET nunca es matriz). La diferencia respecto al Escenario 1 es solo dónde se activa el Tax Report Setting: no sobre la matriz SIREN (que transferiría la entrada existente del Annuaire), sino sobre la UO SIRET. La UO publica de forma independiente (ver unidades organizativas con Tax Report Setting propio), de modo que el registro del SIREN con la otra PA queda intacto.
La topología es la misma que los Casos 1 y 2 (matriz SIREN + UO SIRET, opcionalmente con un servicio por Code Routage):
#
Caso
Cuenta matriz
UO que lleva el Tax Report Setting
Direccionamiento Annuaire
4
C — Établissement-only
cin_scheme="0002" (SIREN), sin TRS
cin_scheme="0009" (SIRET) + Tax Report Setting propio
SIREN_SIRET
5
C — + Service
cin_scheme="0002" (SIREN), sin TRS
cin_scheme="0009" (SIRET) + routing_codes.cin1_scheme="224" + Tax Report Setting propio
SIREN_SIRET_<CR>
Caso 4 (C Établissement-only) — Una única UO SIRET lleva el Tax Report Setting; la matriz SIREN no tiene ninguno.
Caso 5 (C + Service) — Como el Caso 4, más servicios internos de ese establecimiento direccionados por un Code Routage (routing_codes.cin1_scheme="224" en la UO SIRET).
Escenario 3 — Issue-only (solo emisión, sin publicar transporte 0225)
Si el SIREN ya está en otra PA y solo quieres emitir desde B2Brouter (sin publicar un transporte 0225 que entraría en conflicto con el de la otra PA), usa el flag issue_only=true en la cuenta matriz. B2Brouter no registrará ningún transporte 0225 en el PPF.
Caso puro — solo issue_only=true (sin suffix):
cin_scheme="0002" (SIREN) + issue_only=true
Sin UOs, sin suffix
Direccionamiento Annuaire: SIREN (el resto lo gestiona la otra PA)
Sub-caso con suffix: cuando además hace falta direccionamiento interno SIREN_<SUFFIX>, crea el suffix como Suffix UO (Caso 6), no en la matriz:
parent_id = matriz SIREN, cin_scheme="8040", cin_value="<SUFFIX>", con issue_only=true en esa UO
Un suffix (como cualquier SIRET o Code Routage) es siempre una UO, nunca colocado en la propia matriz
Direccionamiento Annuaire: SIREN_<SUFFIX>
Un suffix no significa issue-only. El suffix (SIREN_<SUFFIX>) es solo un detalle de direccionamiento — que esa dirección también reciba facturas depende exclusivamente de issue_only, no de la presencia del suffix:
issue_only=true + suffix → se crea la Ligne SIREN_<SUFFIX> en el Annuaire, pero no se publica transporte 0225 para ella → solo emisión, sin recepción. Úsalo cuando la recepción de esa dirección ya la gestiona otra PA.
Sin issue_only (por defecto) + suffix → sí se publica el transporte 0225 para SIREN_<SUFFIX> → emisión y recepción en la misma dirección con suffix, igual que cualquier otra dirección.
Si quieres emitir y recibir en una dirección con suffix, no pongas issue_only en ese Tax Report Setting.
issue_only es independiente del suffix: puedes tener issue_only=true sin ningún suffix (matriz SIREN pura, solo emisión). El suffix en el slot secundario es solo un sub-caso opcional para direccionamiento interno.
Contactos: mismo modelo, regla de oro más estricta
Los contactos en B2Brouter (clientes y proveedores franceses) siguen exactamente la misma jerarquía (matriz + UOs) y los mismos cin_scheme (SIREN / SIRET / Code Routage / Suffix). Gestiona los contactos exactamente igual que tus cuentas: el contacto matriz debe ser el SIREN, y cualquier SIRET, Code Routage o Suffix debe ser una UO. Aunque el sistema admite técnicamente un contacto matriz a otro nivel, hacerlo puede provocar roturas cuando más adelante añadas UOs del mismo cliente, así que mantén siempre el SIREN como matriz.
Regla de oro para contactos: la matriz es siempre el SIREN; modela cualquier SIRET, Code Routage o Suffix como UOs, igual que con las cuentas.
Con la matriz a SIREN, los casos de los 3 escenarios son aplicables a contactos (las UOs pueden ser SIRET, Code Routage o Suffix según la estructura del cliente).
Para crear una UO de contacto, usa el mismo endpoint que para un contacto normal — POST /accounts/{ACCOUNT_ID}/contacts — añadiendo parent_id apuntando al contacto matriz. tin_value y tin_scheme son heredados de la matriz y no pueden divergir.
Contactos legacy (normalización): igual que con las cuentas, hasta junio de 2026 un contacto podía crearse con un SIRET como matriz. Si tienes contactos creados así, deben normalizarse: sustituir el identificador del contacto matriz por el SIREN (cin_scheme="0002") y crear el SIRET correspondiente como UO bajo ese contacto SIREN.
Recordatorio de estructura: la cuenta matriz es siemprecin_scheme="0002" (SIREN) — ver Estructura de la cuenta. Lo que cambia entre escenarios no es el identificador de la matriz sino dónde activas el Tax Report Setting (sobre la matriz SIREN en el Escenario 1, sobre la UO SIRET en el Escenario 2). Los establecimientos se crean siempre como UOs en el Paso 1b.
Si ya tienes una cuenta de B2Brouter para tu empresa, recupera su id con el endpoint List Accounts y omite el paso de creación.
Si aún no has creado una, usa el endpoint Create Account (ruta eDocSync/API) o el asistente de incorporación de la interfaz web (ruta eDocExchange). Ambos producen el mismo resultado.
Al crear una cuenta de empresa francesa:
cin_scheme: siempre "0002" (SIREN, 9 dígitos) para la cuenta matriz. Un SIRET no se acepta como identificador de matriz: crear una matriz francesa con cin_scheme "0009" devuelve 422 parameter_matriu_must_be_siren. Los establecimientos (SIRET) se crean como unidades organizativas bajo la matriz SIREN (ver el Paso 1b).
cin_value: El SIREN de tu empresa (9 dígitos).
tin_value: Número de IVA francés en el formato FR{kk}{siren}, donde kk es la suma de comprobación de dos dígitos (p. ej. FR32123456789). Es obligatorio para la facturación DGFiP; no necesitas calcular el checksum tú mismo. Si indicas solo el SIREN o solo el número de IVA, B2Brouter deriva el otro automáticamente al activar el Tax Report Setting de la DGFiP. Esta derivación solo ocurre al activar: si no indicas el número de IVA ni activas el Tax Report Setting, queda vacío y la facturación fallará, así que activa el setting para evitar problemas.
Si la estructura de tu empresa requiere UOs (ver Casos 1, 2, 4, 5 y 6 en Topologías), crea cada UO con POST /accounts añadiendo parent_id (el ID de la cuenta matriz creada en el Paso 1a).
Esta funcionalidad requiere una versión de la API que admita UOs con parent_id. Consulta el changelog de la API para la versión mínima.
Restricciones:
parent_id es obligatorio para crear una UO.
Una UO no puede contener tin_value ni tin_scheme (los hereda de la matriz).
Una UO no puede ser parent de otra UO (solo un nivel de profundidad).
UO de establecimiento que lleva su propio TRS (Escenario 2, casos 4/5)
Mismos campos que el caso 1 (o el caso 2 para un servicio): parent_id (matriz SIREN) + cin_scheme="0009" + cin_value=<SIRET> [+ routing_codes.cin1_scheme="224" + routing_codes.cin1_value=<CR> para un servicio]. La diferencia es que esta UO tiene su propio Tax Report Setting mientras que la matriz SIREN no tiene ninguno.
Campos obligatorios en todos los payloads UO: además de parent_id y cin_*, debes incluir country, email, address, city, postalcode y province. Sin estos campos, la creación devuelve HTTP 422 (“Region/Province/Country can’t be blank”). tin_value y tin_scheme se heredan de la matriz y no se deben repetir.
Ejemplo — UO de tipo Établissement con Service opcional (Casos 1 y 2):
Para un establecimiento sin Code Routage (Caso 1 puro), omite el bloque routing_codes.
Ejemplo — UO de establecimiento que lleva su propio Tax Report Setting (Escenario 2, casos 4/5):
La UO se crea exactamente como en el Caso 1/2 (abajo, una variante de servicio con Code Routage). La diferencia en el Escenario 2 es que después activas un Tax Report Setting sobre esta UO (no sobre la matriz SIREN), de modo que el registro existente del SIREN en el Annuaire con otra PA se preserva (ver el Paso 2).
La UO lleva el SIRET como cin_scheme="0009" principal y, para un servicio, lo identifica vía routing_codes.cin1_value. El Code Routage nunca va como cin_scheme principal. Para una UO solo de establecimiento (Caso 4), omite el bloque routing_codes.
Ejemplo — UO de tipo Suffix (Caso 6):
Ventana de terminal
curl--requestPOST \
--urlhttps://api-staging.b2brouter.net/accounts \
--header'X-B2B-API-Key: {YOUR_API_KEY}' \
--header'X-B2B-API-Version: {YOUR_API_VERSION}' \
--header'Content-Type: application/json' \
--data'{
"account": {
"name": "Exemplar SAS — 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"
}
}'
Los casos Issue-only (Escenario 3) no se crean como UO — son la propia matriz SIREN, definida en el Paso 1a con cin_scheme="0002" (y issue_only=true, más un suffix 8040 opcional). Los casos 4 y 5 (Escenario 2), en cambio, sí son UOs: una matriz SIREN más una UO SIRET que lleva su propio Tax Report Setting.
Paso 2: Activar la configuración de informe fiscal para DGFiP
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 SIREN/SIRET se vuelve descubrible por cualquier plataforma en el ecosistema de facturación electrónica francés.
Crea un transporte Peppol 0225 — habilitando a tu empresa para recibir facturas electrónicas desde cualquier plataforma conectada a Peppol en Francia.
⚠️ Reemplazo de transporte:
Si la cuenta sobre la que activas ya tiene un transporte Peppol, será reemplazado por el nuevo transporte 0225 (FRCTC Electronic Address) durante la activación. 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; una UO sin TRS declara a través de la matriz. Tres configuraciones:
TRS solo en el SIREN: la empresa se publica como SIREN y los establecimientos declaran a través de ella (caso estándar, Escenario 1).
TRS 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), de modo que la entidad entera y los establecimientos concretos son direccionables cada uno.
TRS 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.
El start_date determina cuándo comienza el reporte fiscal. A partir de esa fecha, las facturas que emitas generarán informes fiscales y serán transmitidas al PPF.
Cuándo comienza el reporte fiscal. Debe ser hoy o una fecha futura. 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 informes fiscales. Elige "mixed" si tu empresa vende tanto bienes como servicios. En una factura mixta, el informe fiscal del Flux 1 se emite con el código de proceso de servicios (S1/S2/S4/S7) y solo reporta los breakdowns de servicios; la DGFiP no tiene ningún cadre “M” propio para el Flux 1 (consulta Códigos de proceso). Esta configuración se puede actualizar tras la activación.
naf_code
string
Sí
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 informes fiscales. Puedes encontrar tu código NAF en el extracto Kbis de tu empresa o en sirene.fr.
enterprise_size
string
Sí
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€).
reason_vat_exempt
string
No
Código de motivo de exención de IVA 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 IVA.
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 informes 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; enterprise_size y naf_code son opcionales. Por defecto false. Ver Modo reception-only.
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.
Si tu cuenta solo necesita recibir facturas electrónicas (no emitirlas) — por ejemplo, una empresa que aún no está obligada a emitir pero quiere estar registrada en el Annuaire para que sus proveedores le puedan enviar facturas via Peppol — puedes activar el DGFiP Tax Report Setting con annuaire_only: true.
Qué activa:
Registra tu empresa en el Annuaire del PPF (visible para los emisores).
Crea el transporte Peppol 0225 para la recepción.
Qué suprime respecto a una activación completa:
No se generan tax reports Flux 1 al emitir facturas.
No se envían mensajes CDAR (ciclo Déposée → Reçue → Approuvée…).
Los campos enterprise_size y naf_code no son obligatorios.
Este modo es útil para empresas receptoras en fase de evaluación, o para entidades que tienen un proveedor de facturación diferente pero quieren recibir vía B2Brouter. Cuando quieras emitir, actualiza el Tax Report Setting a modo completo con un PATCH (ver Tax Report Settings Guide).
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
"0009" (SIRET) o "0002" (SIREN)
ID de organización — usado para buscar al destinatario en el Annuaire
cin_value
SIRET o SIREN
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. "FR78225214234")
ID fiscal — número de IVA 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, "0190" para Leitweg-ID alemán, "0184" 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.
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 topologías aplicables.
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):
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 informes fiscales). Úsala para inspeccionar antes de enviar o para mostrar el estado del destinatario en tu UI.
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 informe fiscal Flux 1 (facturación electrónica B2B nacional).
Contacto NO registrado en el Annuaire (in_dgfip_annuaire: false): la factura no genera un informe 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 informe 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 informes 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.
⚠️ La web annuaire-entreprises.data.gouv.fr es para datos fiscales generales; no garantiza el registro en el Annuaire DGFiP — son bases diferentes.
A partir de septiembre de 2026 este comportamiento permisivo dejará de aplicarse: las declaraciones simplemente fallarán si el identificador no consta como activable en la DGFiP, aunque el SIREN/SIRET sea válido.
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. B2Brouter gestiona todos los requisitos específicos de Francia automáticamente: generación de informes 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 de la factura está limitado a 20 caracteres como máximo. Un número más largo se rechaza con HTTP 422 (number demasiado largo).
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.
El array tax_report_ids en la respuesta contiene el ID del informe fiscal generado. Úsalo para hacer seguimiento del ciclo de vida de la presentación (ver Verificar el estado de un informe fiscal).
Tres campos de pago son obligatorios para las facturas electrónicas B2B francesas (IssuedInvoice). Proporciónalos como campos directos de la API:
Campo
Campo DGFiP
Descripción
Requerido
remittance_information
PMD
Referencia de pago y menciones legales (registro de empresa, capital social, RCS)
Sí — B2B nacional y transfronterizo
payment_method_text
PMT
Descripción textual del método de pago
Sí — B2B nacional y transfronterizo
payment_terms
AAB
Fecha de vencimiento, penalizaciones por pago tardío, condiciones de descuento
Sí — B2B nacional y transfronterizo
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
Si falta algún campo obligatorio, la solicitud devuelve HTTP 422 con mensajes de error explícitos para cada campo ausente. No son silenciosos — la factura nunca se crea. Corrige los campos faltantes y vuelve a enviar.
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 la fuente canónica — no los pases como texto libre dentro de payment_method_text.
Las facturas B2C (IssuedSimplifiedInvoice) no requieren estos campos.
Importación desde otros formatos (UBL, CII, Factur-X): Para estas integraciones, usa el campo extra_info con etiquetas estructuradas:
#PMD# FA-2026-0048 — Exemplar SAS, RCS Paris 123 456 789
Cuando una línea tiene category: "E" (exenta de IVA), 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 IVA de la DGFiP (BT-121)
Código
Referencia legal
Categoría fiscal
Descripción
VATEX-FR-FRANCHISE
Art. 293 B CGI
Z (tipo cero)
Franchise en base de TVA
VATEX-FR-CNWVAT
—
E (exento)
No establecido en Francia
VATEX-FR-AE
—
E (exento)
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.
Las empresas que operan bajo el régimen de franchise en base de TVA operan a tipo cero (categoría fiscal Z), no exento (categoría E). Para facturas de franchise, establece percent: 0.0 y category: "E" con comment: "VATEX-FR-FRANCHISE" en cada línea de impuesto — B2Brouter transcodifica automáticamente la categoría a Z:
{
"taxes_attributes":[
{
"name":"TVA",
"percent":0.0,
"category":"E",
"comment":"VATEX-FR-FRANCHISE"
}
]
}
Operaciones fuera del ámbito del IVA (categoría O)
Algunas operaciones quedan fuera del ámbito de aplicación del IVA 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 del IVA): la línea no lleva IVA.
Débours (gastos reembolsables adelantados en nombre del cliente): se traspasan sin IVA.
{
"taxes_attributes":[
{"name":"TVA","percent":0.0,"category":"O"}
]
}
El informe 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.
Para emitir una nota de crédito, establece is_amend: true y referencia la factura original usando amended_number y amended_date. B2Brouter genera un CreditNote UBL con código de tipo 381 e incluye la referencia de facturación.
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.
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
Corrección de una factura registrada (servicios)
B7
Bienes
Corrección de una factura registrada (bienes)
Ningún cadre “M” en el Flux 1: aunque type_operation acepta "mixed", el informe fiscal del Flux 1 nunca lleva un código de proceso de la serie M. Una factura mixta se resuelve con el código de servicios correspondiente (S1/S2/S4/S7) y solo reporta sus breakdowns de servicios. Las filas M de arriba se listan como referencia, pero el Flux 1 no las produce.
Francia usa un modelo en Y (5 esquinas), no de clearance. La factura se transmite al comprador con independencia de que se registre un informe fiscal Flux 1; el PPF no valida previamente las facturas antes de que lleguen al comprador. La Factura y el Informe fiscal son ciclos de vida separados que solo coinciden en la entrega del Flux 1. Un error en el informe fiscal no deshace una factura que ya ha llegado al comprador.
La factura ha sido creada y está en cola para transmisión al PPF.
sent
200 — Déposée
La factura se ha depositado correctamente en el PPF.
registered
202 — Reçue
El PPF la ha validado y entregado al comprador.
accepted
205 — Approuvée
El comprador ha aprobado la factura.
refused
210 — Refusée
El comprador ha rechazado la factura.
paid
212 — Encaissée
El pago de la factura se ha confirmado.
error
—
Se produjo un error durante la transmisión o la validación del PPF. El campo errors en la respuesta de la factura contiene el motivo de rechazo del PPF. Si la factura fue rechazada antes del registro (estado sending o sent), elimínala, corrige el problema y envía una nueva; las facturas con error no pueden retransmitirse directamente. Una factura registrada (CDV 202 o posterior) no puede eliminarse ni volver a enviarse: ya está en el ciclo de vida del comprador. Corrígela con un abono o una rectificación (código de proceso S7/B7), o anúlala.
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.
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:
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.
Encaissée es el último estado del ciclo CDV de una factura B2B francesa, justo después de la aprobación del comprador. Indica que el pago se ha confirmado (ver el mapping CDV completo en la tabla Estados de la factura).
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)
Próximamente gestionables vía API. De momento, la API solo permite marcar la factura cuando esté completamente pagada (state: "paid").
Si gestionas los pagos desde un ERP, mantén el control interno de los parciales y no marques el estado en el PPF hasta que el total esté cubierto. Alternativamente, puedes gestionar los parciales desde la app de B2Brouter: abre la factura → Crear cobro → define el importe pagado.
El informe 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
Informe 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 — Reçue)
registered
✅ Terminal — Factura aceptada y registrada por la DGFiP (condición CDV 300)
refused
❌ Terminal — Rechazada por la DGFiP (condición CDV 301)
error
❌ Terminal — Error de transmisión o procesamiento del PPF
annulled
La factura ha sido anulada tras el registro
Flux 10 — Facturas B2B transfronterizas y B2C (e-Reporting):
Estado
Descripción
new
Informe 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 — Reçue)
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
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 Envío de un archivo de Flux 10.
Ventas a personas físicas no registradas como sujetos pasivos de IVA 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: 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 informe 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 del IVA francés y siguen la vía de e-Reporting del Flux 10.
B2Brouter agrupa todos los informes fiscales Flux 10 de un día natural en Ledgers enviados al PPF una vez al día (programados a las 02:00 AM hora del servidor). Puedes identificar los informes fiscales Flux 10 por un ledger_id no nulo en la respuesta del informe fiscal.
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, IVA sobre servicios devenga al cobro) — document type xml.ledger.dgfip.payments.
La combinación de roles y modos da hasta 3 ledgers diarios por cuenta:
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 + día + (rol, modo) bajo lock para evitar duplicados.
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.
Actualización del estado de las facturas recibidas
