¿Qué es Peppol BIS 3.0? Una introducción práctica para desarrolladores
Si se construye software de facturación en Europa, tarde o temprano se encontrará Peppol.
Para muchos desarrolladores, el primer encuentro es confuso: XML por todas partes, identificadores extraños, descubrimiento SMP y SML, facturas UBL, reglas EN16931, fallos de validación con mensajes crípticos.
Este artículo explica Peppol BIS Billing 3.0 desde una perspectiva de ingeniería práctica. Sin jerga corporativa. Solo las partes que los desarrolladores realmente necesitan entender.
¿Qué es Peppol?
Peppol es una red europea de interoperabilidad para el intercambio de documentos empresariales electrónicos. El caso de uso más común es la facturación electrónica.
En lugar de enviar PDF por correo electrónico, los proveedores envían documentos de factura estructurados directamente entre sistemas. Una factura Peppol es legible para máquinas, estandarizada, validada y procesable automáticamente.
Esto permite que los sistemas contables y las plataformas ERP procesen facturas con un mínimo de trabajo manual.
¿Qué significa BIS 3.0?
BIS son las siglas de Business Interoperability Specifications (Especificaciones de Interoperabilidad Empresarial). Peppol BIS Billing 3.0 define:
- la estructura de la factura
- los campos requeridos
- las reglas de validación
- las listas de códigos permitidos
- las expectativas de transporte
La sintaxis se basa en UBL 2.1 y EN16931. En la práctica: EN16931 define el modelo semántico de la factura, UBL define la sintaxis XML y Peppol añade reglas de interoperabilidad por encima. Se puede leer más sobre el modelo semántico EN16931 en Entendiendo EN16931.
Por qué Europa avanza hacia la facturación electrónica obligatoria
Varios países de la UE avanzan hacia la facturación electrónica obligatoria. Ejemplos incluyen Bélgica, Alemania, Francia, Polonia e Italia. Los gobiernos buscan reducir el fraude del IVA, automatizar el procesamiento fiscal, facilitar la contratación pública interoperable y estandarizar el intercambio de facturas.
Esto significa que el conocimiento de Peppol se está convirtiendo en conocimiento de infraestructura.
¿Cómo es una factura Peppol?
Una factura Peppol es un documento XML UBL 2.1.
<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
<cbc:CustomizationID>
urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0::2.1
</cbc:CustomizationID>
<cbc:ProfileID>urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</cbc:ProfileID>
<cbc:ID>INV-2025-001</cbc:ID>
<cbc:IssueDate>2025-11-12</cbc:IssueDate>
<cac:AccountingSupplierParty>
<!-- seller details -->
</cac:AccountingSupplierParty>
<cac:AccountingCustomerParty>
<!-- buyer details -->
</cac:AccountingCustomerParty>
<cac:LegalMonetaryTotal>
<!-- totals -->
</cac:LegalMonetaryTotal>
</Invoice>A diferencia de los PDF, estos documentos están pensados para ser consumidos por software. Un solo campo inválido puede causar un rechazo.
El papel de EN16931
EN16931 es el estándar semántico europeo de facturas. Define conceptos como número de factura, importe del IVA, identificador del comprador, condiciones de pago y desgloses fiscales. Peppol BIS 3.0 se construye sobre este modelo semántico.
Por eso los desarrolladores a menudo ven referencias como BT-10, BT-49 y BR-CO-10. Estos son términos empresariales y reglas de negocio definidos por EN16931.
Puntos de dolor habituales para los desarrolladores
La mayoría de las implementaciones Peppol acaban encontrando los mismos problemas.
Problemas de espacio de nombres. UBL usa muchos espacios de nombres XML. Equivocarse en las declaraciones produce errores crípticos del analizador antes de que se ejecute ninguna lógica de negocio.
Errores de validación. Los fallos de validación Schematron pueden ser difíciles de depurar. Los mensajes de error hacen referencia a códigos BR que requieren leer la especificación EN16931 para interpretarlos.
Formatos de identificador. Los ID de participante y de endpoint son estrictos. Una empresa belga que usa el esquema de número empresarial 0208 debe tener exactamente ese código de esquema como prefijo.
Firmas XML. Los problemas de canonización a menudo rompen la validación de firmas. Esta es una categoría de errores particularmente desagradable porque el XML parece correcto al leerlo, y la firma es válida, pero no se verifican mutuamente. Consulta los problemas de validación de firmas XML en Peppol para más detalles.
Perfiles específicos por país. Alemania, Bélgica y Francia aplican requisitos adicionales sobre la especificación base de Peppol BIS 3.0. Un documento válido para un país puede ser inválido para otro.
Descubrimiento SMP y SML
Peppol usa un mecanismo de descubrimiento similar al DNS. El flujo funciona aproximadamente así:
- Se hace un hash del identificador del participante
- Se construye un nombre de host DNS a partir del hash
- Se consulta el SML (Service Metadata Locator) para encontrar el SMP del participante
- Se consulta el SMP (Service Metadata Publisher) para obtener los metadatos del servicio
- Se determinan los tipos de documento admitidos y las URL de endpoint
- Se entrega el documento a través de un Punto de Acceso
La respuesta del SMP en sí es un documento XML firmado. Esa firma es la que causa los problemas de canonización mencionados anteriormente.
Por qué las facturas PDF no son suficientes
Las facturas PDF tradicionales son legibles para humanos. Las facturas Peppol son legibles para máquinas. Muchos sistemas modernos combinan ambas: PDF/A-3 para la representación visual, XML incrustado para la automatización.
Esta es la base de Factur-X y ZUGFeRD. Consulta Factur-X vs ZUGFeRD vs XRechnung vs Peppol para una comparación de cómo estos formatos se relacionan entre sí.
La parte difícil
Generar XML UBL válido no es la parte difícil. La parte difícil es generar XML que supere la interoperabilidad del mundo real:
- Validación Schematron a través de múltiples conjuntos de reglas nacionales
- Descubrimiento SMP con prefijos de espacio de nombres dinámicos
- Verificación de firmas XML en documentos que han sido reserializados
- Campos obligatorios específicos por país que no están en la especificación base
- Reglas de redondeo que producen resultados diferentes dependiendo de si se redondea por línea o por documento
En próximos artículos cubriremos: EN16931 en detalle, UBL vs CII, los internos del descubrimiento SMP, los problemas de firmas XML y los errores de validación Peppol más comunes.
El coste real de la parte difícil no es leer la especificación. Es la carga operativa: mantener los conjuntos de reglas Schematron actualizados con cada versión de Peppol BIS, gestionar correctamente los fallos de descubrimiento SMP, mantener las variaciones de reglas específicas por país para Alemania, Bélgica, Francia y Polonia.
SealDoc es una API que gestiona esta capa. Se envían los datos de la factura como carga JSON. La API genera el documento UBL, ejecuta la validación Schematron de EN16931 y Peppol BIS 3.0, realiza el descubrimiento SMP, envuelve el documento en un sobre AS4 y lo entrega al Punto de Acceso del receptor. Si el receptor no es accesible o el documento falla la validación, se obtiene un error estructurado que indica exactamente qué paso falló y por qué.
Para pruebas y depuración, el validador público de SealDoc acepta archivos de factura UBL y CII y devuelve un informe en lenguaje claro de todas las reglas EN16931 y Peppol BIS 3.0 violadas, con el número BT y el código de regla de negocio. No se requiere cuenta.