en16931 ubl: qué debe generar tu software de facturas

en16931 ubl: qué debe generar tu software de facturas

Si tu software emite facturas, pero cada cliente o plataforma te exige una adaptación distinta, el problema no se resuelve añadiendo otro botón para exportar XML. La búsqueda en16931 ubl responde a una duda operativa concreta: qué información debe contener una factura electrónica, cómo debe representarse y qué comprobaciones necesita superar para que el destinatario pueda procesarla sin intervención manual.

En Fundy planteamos esta decisión como un problema de integración y calidad del dato, no como una elección entre extensiones de archivo. Antes de desarrollar un conector, conviene separar el significado de los datos, la estructura del documento y las condiciones del canal de entrega. Mezclar esas tres capas genera deuda técnica: reglas fiscales duplicadas, transformaciones difíciles de mantener y rechazos que el equipo administrativo termina resolviendo a mano.

Qué son exactamente y por qué aparecen juntos

EN 16931 es una norma europea que define el modelo semántico de los elementos esenciales de una factura electrónica. UBL, siglas de Universal Business Language, es una familia de documentos empresariales estructurados en XML que incluye facturas y notas de abono. Aparecen juntos porque UBL permite expresar mediante etiquetas y estructuras los conceptos que define el modelo europeo.

No son dos formatos competidores. EN 16931 establece qué significa la información y qué reglas debe cumplir; UBL proporciona una sintaxis para representarla. La vinculación de EN 16931 con UBL 2.1 especifica cómo trasladar los términos del modelo a elementos concretos del XML. Existe también una vinculación con UN/CEFACT CII, de modo que no debes interpretar que cualquier factura conforme al modelo europeo tenga que utilizar necesariamente UBL.

Un XML puede estar bien formado y, aun así, contener una factura que incumpla las reglas del modelo europeo. También puede ser válido frente al esquema de UBL y fallar al comprobar importes, identificadores o condiciones de negocio. Por eso, pedir al proveedor «un XML UBL» resulta insuficiente para definir un desarrollo o aceptar una entrega.

Para concretar el requisito, necesitas identificar varias piezas:

• El modelo de referencia: qué información y reglas de negocio debe respetar la factura.
• La sintaxis y su versión determinan los documentos y elementos XML disponibles.
• Si el receptor exige una especificación de uso, incorpora sus restricciones y reglas adicionales al contrato de integración.
• El canal de intercambio tiene condiciones propias de direccionamiento, autenticación, envío y respuesta.

Una especificación de uso del núcleo, denominada CIUS, restringe o concreta la utilización del modelo para un contexto determinado. No debe confundirse con una sintaxis nueva. Peppol BIS Billing 3.0 es un ejemplo de especificación de uso basada en EN 16931 que utiliza UBL y añade reglas aplicables a ese intercambio. Generar UBL sin atender a esas reglas no garantiza que una factura supere las validaciones correspondientes.

Tampoco basta con adjuntar un PDF. El PDF sirve para representar visualmente una factura, pero por sí solo no aporta un documento estructurado conforme a EN 16931 que el sistema receptor pueda interpretar automáticamente. Puedes generar una representación legible para las personas, siempre que proceda de los mismos datos y no se convierta en una segunda fuente de importes o conceptos.

En el alcance de unas integraciones de software para empresas, esta separación permite repartir responsabilidades: el ERP aporta los datos de negocio, una capa de transformación construye el documento requerido y el componente de transporte gestiona su entrega. Así puedes cambiar de canal sin reescribir el cálculo de impuestos ni las reglas de facturación.

EN16931: el modelo semántico

El modelo semántico define conceptos como el número de factura, la fecha de emisión, el vendedor, el comprador, las líneas, los impuestos y los totales. También establece relaciones y condiciones: qué información es obligatoria, qué elementos pueden repetirse y qué datos pasan a ser necesarios cuando se cumple una determinada circunstancia.

Sus términos de negocio se identifican mediante códigos BT, mientras que los grupos de información utilizan códigos BG. Estas referencias ayudan a documentar correspondencias sin depender de cómo llame cada ERP a sus columnas. El identificador interno de un cliente, por ejemplo, no equivale automáticamente a su identificador fiscal ni a la dirección electrónica utilizada para el intercambio.

El primer entregable técnico debería ser un mapa de correspondencias entre los datos del sistema y los términos de negocio exigidos por el receptor. Ese documento debe registrar el origen de cada valor, su transformación, las condiciones de obligatoriedad y el tratamiento de los datos ausentes. Si falta una información obligatoria, la solución no consiste en inventarla durante la exportación: hay que corregir el proceso que debe capturarla.

Para llevar ese modelo a software mantenible, recomendamos trabajar en esta secuencia:

1. Define un modelo interno de factura independiente del canal de envío. Incluye cabecera, partes, líneas, descuentos, cargos, impuestos, medios de pago y totales con tipos de datos explícitos. Evita convertir el XML de un destinatario en el modelo central de todo el ERP.
2. Documenta las correspondencias hacia UBL. El número de factura se representa mediante cbc:ID dentro del documento correspondiente, mientras que las líneas de una factura utilizan estructuras cac:InvoiceLine. Estas referencias ilustran la correspondencia, pero no sustituyen la especificación completa de vinculación.
3. Separa los tipos documentales. UBL contempla documentos Invoice y CreditNote; no conviene resolver todos los abonos cambiando el signo de una factura sin comprobar el documento y las reglas que exige el intercambio.
4. Conserva la versión del generador y de las reglas utilizadas. Cuando aparezca una incidencia, debes poder identificar cómo se construyó el documento enviado y reproducir su validación.

Los importes merecen un tratamiento específico. El total de una factura no puede calcularse por una vía en el ERP y por otra en el exportador sin una política compartida. Bases imponibles, descuentos, cargos y cuotas deben mantener las relaciones aritméticas previstas por las reglas aplicables. Utiliza aritmética decimal y define dónde se redondea, qué precisión admite cada campo y cómo se comprueba la coherencia entre líneas y totales.

El mismo cuidado se aplica a los impuestos. No basta con enviar un porcentaje: el documento puede necesitar una categoría fiscal y, cuando corresponda, información sobre la exención. Un valor que parece suficiente en pantalla puede resultar ambiguo para otro sistema. Asimismo, las unidades de medida y los códigos de moneda deben ajustarse a las listas admitidas, no a abreviaturas libres introducidas por cada usuario.

La validación debe organizarse por capas, porque cada una detecta una clase distinta de errores:

• Comprueba la estructura antes de evaluar el contenido de negocio. El análisis del XML y la validación XSD revisan cuestiones como sintaxis, espacios de nombres, elementos y tipos de datos.
• Las reglas de EN 16931 verifican condiciones semánticas y relaciones entre valores. Los artefactos de validación pueden utilizar Schematron para expresar estas comprobaciones.
• Aplica después las reglas específicas del intercambio, incluidas las restricciones de la CIUS y las listas de códigos correspondientes a la versión exigida.
• La entrega requiere un control separado: registra la respuesta del canal y distingue entre documento enviado, recibido, validado y aceptado cuando esos estados estén disponibles.

Superar el XSD no demuestra conformidad semántica, y superar la validación semántica no acredita la aceptación del destinatario. Tampoco garantiza por sí solo el cumplimiento de todas las obligaciones legales que puedan resultar aplicables en un país. El formato, la conservación, la comunicación con administraciones y otros requisitos deben analizarse según el contexto normativo del proyecto.

Para comprobar la implementación, no te limites a una factura sencilla. Prepara casos con varias líneas, distintos tipos impositivos, descuentos, cargos, exenciones y abonos, siempre que formen parte de tu operativa. Añade casos negativos: ausencia de identificadores obligatorios, códigos no admitidos o totales incoherentes. El resultado esperado debe incluir tanto la aceptación de documentos correctos como el rechazo explicable de los incorrectos.

El equipo administrativo necesita mensajes accionables, no únicamente una ruta XML. «Falta el dato fiscal del comprador requerido para esta operación» permite corregir el origen; un código técnico aislado obliga a escalar la incidencia. Guarda ambos niveles de detalle y relaciona el error con la factura, el campo de origen y la regla incumplida, evitando exponer datos sensibles en registros de acceso amplio.

Antes de encargar el desarrollo, pide ejemplos válidos, reglas de validación, versiones admitidas y condiciones de entrega del receptor. Si quieres contrastar ese material con tu ERP, agenda una consultoría con Fundy y trae una factura anonimizada junto con la especificación de destino. Podremos identificar qué datos faltan, dónde debe hacerse cada transformación y qué pruebas conviene incluir en el alcance antes de comprometer el desarrollo del conector.