Entendiendo EN16931: el modelo de datos de factura de Europa
EN16931 es el estándar europeo que define qué debe contener una factura electrónica. No es un formato XML. Es un modelo de datos semántico. Todos los principales formatos de facturación electrónica europeos, ya sea Peppol BIS Billing 3.0, Factur-X, ZUGFeRD o XRechnung, son implementaciones de EN16931 en una sintaxis XML específica.
Entender EN16931 ahorra tiempo al depurar fallos de validación, explicar requisitos de integración a proveedores de ERP o implementar un nuevo perfil de factura desde cero.
Qué especifica realmente EN16931
EN16931 consta de dos partes:
- EN 16931-1 define el modelo de datos semántico: qué elementos de datos puede contener una factura, cuáles son obligatorios y cuáles son las reglas de negocio
- EN 16931-2 define los enlaces de sintaxis: cómo el modelo semántico se mapea a XML UBL 2.1 y XML CII de UN/CEFACT
El resultado es que una factura UBL de Peppol BIS Billing 3.0 y una factura CII de Factur-X pueden representar la misma factura de negocio. El contenido semántico es idéntico. La sintaxis XML es completamente diferente.
Términos de Negocio y Grupos de Negocio
EN16931 organiza los datos de la factura en Grupos de Negocio (BG) y Términos de Negocio (BT).
Un Grupo de Negocio es una colección de términos relacionados. Un Término de Negocio es un único elemento de datos con un identificador definido, nombre, cardinalidad y tipo de datos.
Los grupos más importantes en el nivel superior:
| Grupo | Contenido |
|---|---|
| BG-2 Control de proceso | Identificador de especificación (BT-24), tipo de proceso de negocio (BT-23) |
| BG-4 Vendedor | Nombre, dirección, número de IVA, registro legal |
| BG-7 Comprador | Nombre, dirección, identificador de referencia, dirección electrónica |
| BG-22 Totales del documento | Base imponible, total de la factura, importe del IVA, importe pendiente |
| BG-25 Línea de factura | Cantidad, precio unitario, tipo de IVA, importe neto de la línea |
El modelo completo abarca más de 150 BT en todos los grupos. La mayoría de las implementaciones solo necesitan un subconjunto, pero validar un documento requiere saber qué BT son obligatorios para el perfil objetivo.
Términos de Negocio en los que tropiezan los desarrolladores
La mayoría de los fallos de validación provienen de un pequeño conjunto de BT que se malinterpretan o están mal documentados en las guías de implementación.
BT-24: Identificador de especificación
Debe ser un URI específico que identifique el perfil con el que la factura afirma conformarse. Para Peppol BIS Billing 3.0:
urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0::2.1Equivocarse aquí hace que el validador del receptor rechace la factura antes de comprobar ningún campo. Cada perfil (base EN16931, Peppol BIS 3.0, Peppol BIS 3.0 con extensión nacional) tiene un URI diferente.
BT-10: Referencia del comprador
Se usa de forma diferente según los países. En Alemania, lleva el Leitweg-ID, un identificador de enrutamiento obligatorio para las facturas B2G. En la mayoría de los otros países es una referencia de pedido de compra interno o se deja vacío. El campo es opcional en la base EN16931 pero obligatorio en el perfil nacional alemán.
BT-49: Dirección electrónica del comprador
El ID de participante Peppol del comprador. Formato: esquema:identificador. Para una empresa belga identificada por número empresarial:
<cbc:EndpointID schemeID="0208">0468863455</cbc:EndpointID>Obligatorio cuando se transmite por la red Peppol. Muchas implementaciones lo omiten para facturas B2B fuera de Peppol, lo cual es aceptable en la base EN16931 pero inválido en los perfiles Peppol BIS.
BT-131: Importe neto de la línea de factura
El importe neto de una línea individual, calculado como cantidad por precio unitario menos cualquier descuento a nivel de línea. La regla de negocio BR-CO-10 de EN16931 exige que la suma de todos los valores BT-131 sea igual a BT-106 (suma de los importes netos de las líneas de factura).
El redondeo importa aquí. El estándar espera que la aritmética se realice sobre los valores brutos y se redondee en el nivel de agregado, no por línea. Redondear cada línea de forma independiente y luego sumar produce discrepancias que hacen fallar BR-CO-10 para grandes cantidades.
BT-110: Importe de impuesto de la categoría de IVA
El importe del IVA por categoría fiscal. La regla EN16931 BR-CO-15 exige que el total de la factura menos la base imponible sea igual a la suma de todos los BT-117 (importes de impuesto de la categoría de IVA). Los errores aquí a menudo son causados por aritmética de punto flotante o redondeo prematuro.
Reglas de Negocio: la capa de validación
Las Reglas de Negocio (BR) son restricciones formales expresadas en Schematron. Hay dos categorías.
Reglas estructurales que exigen la presencia y el formato de los campos:
BR-01: An Invoice shall have a Specification identifier (BT-24).
BR-02: An Invoice shall have an Invoice number (BT-1).
BR-04: An Invoice shall have an Invoice currency code (BT-5).Reglas de cálculo que exigen coherencia aritmética:
BR-CO-10: Sum of Invoice line net amount (BT-106) = sum of all BT-131 values.
BR-CO-15: Invoice total VAT amount (BT-110) = sum of all BT-117 values.
BR-CO-16: Amount due for payment (BT-115) = Invoice total with VAT (BT-112)
- Paid amount (BT-113) + Rounding amount (BT-114).Peppol BIS 3.0 añade reglas de extensión nacionales sobre las reglas base de EN16931. Ejemplos:
BR-DE-TMP-32: Delivery date (BT-72) is required for German B2G invoices.
BR-DE-18: VAT identifier of the seller (BT-31) or tax registration (BT-32)
shall be present.Estas reglas de extensión varían por perfil de país y se publican con cada versión de Peppol BIS.
Cómo EN16931 se mapea a UBL y CII
Las dos sintaxis XML manejan los mismos BT pero usan nombres de elementos y estructuras completamente diferentes. Por eso el código que analiza facturas UBL no puede analizar facturas CII sin una implementación separada, aunque ambas sean conformes con EN16931.
Nombre del vendedor (BT-27) en ambas sintaxis:
UBL 2.1:
<cac:AccountingSupplierParty>
<cac:Party>
<cac:PartyName>
<cbc:Name>Acme GmbH</cbc:Name>
</cac:PartyName>
</cac:Party>
</cac:AccountingSupplierParty>UN/CEFACT CII:
<ram:SellerTradeParty>
<ram:Name>Acme GmbH</ram:Name>
</ram:SellerTradeParty>Ambos se mapean a BT-27. El contenido semántico es idéntico. La ruta XML difiere completamente.
Peppol BIS 3.0 usa UBL. Factur-X y ZUGFeRD usan CII. XRechnung soporta ambos. El documento de mapeo EN16931-2 (gratuito desde CEN/TC 434) lista ambas rutas para cada BT y merece tenerlo abierto durante la implementación.
Validación Schematron
La validación EN16931 se implementa como reglas Schematron que son precompiladas a XSLT 2.0. Los conjuntos de reglas oficiales se publican con cada versión de Peppol BIS:
github.com/OpenPEPPOL/peppol-bis-invoice-3/releases
Los artefactos contienen archivos XSLT compilados:
peppol-en16931-ubl.xsl (for UBL invoices)
peppol-en16931-cii.xsl (for CII invoices)Ejecutar cualquiera de ellos contra una factura devuelve SVRL (Schematron Validation Report Language). Una regla que falla tiene este aspecto:
<svrl:failed-assert test="..." location="/Invoice/...">
<svrl:text>
[BR-CO-10]-Sum of Invoice line net amount (BT-106) =
sum of Invoice line net amount (BT-131).
</svrl:text>
</svrl:failed-assert>Se requiere un procesador XSLT 2.0. En .NET, Saxon HE (código abierto, sin licencia empresarial necesaria) es la elección estándar. En Java, tanto Saxon como Xerces funcionan.
Errores de implementación comunes
Mezclar rutas de elementos UBL y CII. Los desarrolladores que trabajan con ambos formatos pegan nombres de elementos del enlace incorrecto. El documento de mapeo EN16931-2 previene esto.
Asumir que las reglas de presencia son las mismas en todos los perfiles. Un campo que es opcional en la base EN16931 puede ser obligatorio en Peppol BIS 3.0 o en una extensión nacional. Validar contra el perfil objetivo, no contra el estándar base.
Redondear en el nivel incorrecto. Calcular los totales aritméticos brutos de todas las líneas, luego redondear el agregado. Redondear cada línea de forma independiente y sumar los valores redondeados produce inconsistencias aritméticas que hacen fallar BR-CO-10, a menudo por unos pocos céntimos en facturas grandes con muchas líneas.
BT-24 incorrecto para el perfil objetivo. Cada perfil tiene un URI de identificador de especificación específico. Usar el URI base de EN16931 en una factura Peppol BIS 3.0 hace que la validación a nivel de perfil rechace el documento inmediatamente.
Códigos de categoría de IVA codificados fijamente. EN16931 define valores de código específicos para las categorías de IVA (S, Z, E, AE, K, G, O, L, M). Muchas implementaciones codifican “S” (tipo estándar) fijamente y fallan al procesar facturas de inversión del sujeto pasivo o de tipo cero.
EN16931 es conocimiento de infraestructura
EN16931 sustenta todos los mandatos europeos de facturación electrónica. A medida que los requisitos se despliegan en Bélgica, Francia, Alemania y Polonia, entender el modelo semántico se vuelve cada vez más importante para los desarrolladores que construyen o mantienen procesos de facturas.
Entender la estructura BT/BG, las reglas de cálculo y los enlaces de sintaxis pone en posición de depurar fallos de validación que de otro modo requerirían horas de lectura de especificaciones, implementar nuevos perfiles de forma limpia y comunicarse claramente con los proveedores de ERP y los equipos de cumplimiento.
El problema práctico no es aprender EN16931 una vez. Es mantener las implementaciones correctas a medida que los conjuntos de reglas se actualizan con cada versión de Peppol BIS, a medida que las extensiones nacionales añaden nuevos campos obligatorios y a medida que los casos extremos de redondeo emergen en producción con datos de facturas reales de sistemas ERP reales.
SealDoc incluye conjuntos de reglas que siguen las versiones de Peppol BIS. Cuando se genera una factura a través de la API de SealDoc, el documento se valida contra el perfil correcto antes de salir del sistema. BR-CO-10 y BR-CO-15 se aplican en el servidor para que los errores de redondeo no lleguen a los compradores. Cuando se recibe un fallo de validación de un socio comercial, el validador público de SealDoc acepta el documento y mapea cada fallo al BT y BR específico que fue violado, lo que reduce el tiempo de diagnóstico de horas a minutos.
Si se implementa EN16931 desde cero, el validador es una herramienta de calibración útil: generar un documento candidato, ejecutarlo, corregir lo que identifica el informe, repetir.