← Back to all articles

UBL vs CII: ¿qué sintaxis XML de factura elegir?

SealDoc Team · · 6 min read

Dos sintaxis XML pueden representar una factura electrónica conforme con EN16931: UBL 2.1 y UN/CEFACT Cross Industry Invoice (CII). Ambas son correctas. Ambas son aceptadas por EN16931. Y ambas son estructuralmente tan diferentes que el código escrito para una no puede analizar la otra sin una implementación separada.

Si se está construyendo un proceso de facturas en Europa en 2026, probablemente se encontrarán ambas. Aquí está lo que hay que saber para elegir la correcta y manejar la otra.

Qué tienen en común

Tanto UBL como CII son serializaciones del mismo modelo semántico: EN16931. El nombre del vendedor es el nombre del vendedor. El importe del IVA es el importe del IVA. Los términos de negocio (BT) y los grupos de negocio (BG) son idénticos en ambas sintaxis.

EN 16931-2 define el mapeo oficial de cada BT a su ruta XML en ambas sintaxis. El documento es gratuito de CEN/TC 434 y es la referencia de autoridad cuando hay que implementar ambas.

Ambos formatos se basan en estándares internacionales y son aceptados por los validadores EN16931. Ambos producen facturas estructuradas legibles para máquinas.

Cómo difieren estructuralmente

Las diferencias son significativas y generalizadas. Los nombres de elementos, los prefijos de espacio de nombres, las estructuras de anidamiento y las convenciones de atributos son todos diferentes.

Nombre del vendedor (BT-27)

UBL 2.1:

<cac:AccountingSupplierParty>
  <cac:Party>
    <cac:PartyName>
      <cbc:Name>Acme GmbH</cbc:Name>
    </cac:PartyName>
  </cac:Party>
</cac:AccountingSupplierParty>

CII:

<rsm:SupplyChainTradeTransaction>
  <ram:SellerTradeParty>
    <ram:Name>Acme GmbH</ram:Name>
  </ram:SellerTradeParty>
</rsm:SupplyChainTradeTransaction>

UBL usa anidamiento profundo con espacios de nombres de componentes agregados (cac:) y básicos (cbc:). CII es más plano, con espacios de nombres ram: (Reusable Aggregate Module) y rsm: (Reusable Schema Module).

Importe de la línea de factura (BT-131)

UBL 2.1:

<cac:InvoiceLine>
  <cbc:LineExtensionAmount currencyID="EUR">250.00</cbc:LineExtensionAmount>
</cac:InvoiceLine>

CII:

<ram:IncludedSupplyChainTradeLineItem>
  <ram:SpecifiedLineTradeSettlement>
    <ram:SpecifiedTradeSettlementLineMonetarySummation>
      <ram:LineTotalAmount>250.00</ram:LineTotalAmount>
    </ram:SpecifiedTradeSettlementLineMonetarySummation>
  </ram:SpecifiedLineTradeSettlement>
</ram:IncludedSupplyChainTradeLineItem>

Los códigos de moneda en CII son atributos de elementos en algunos lugares y están ausentes en otros (con la moneda declarada a nivel de cabecera). UBL es más consistente: currencyID aparece en cada elemento de importe monetario.

Elemento raíz y espacios de nombres

UBL 2.1 usa tres espacios de nombres:

<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">

CII usa tres espacios de nombres diferentes:

<rsm:CrossIndustryInvoice
  xmlns:rsm="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100"
  xmlns:ram="urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100"
  xmlns:udt="urn:un:unece:uncefact:data:standard:UnqualifiedDataType:100">

No hay superposición entre los dos conjuntos de espacios de nombres. Un analizador diseñado para un formato no puede procesar el otro.

Qué formato se exige dónde

La elección rara vez es propia. El formato viene determinado por el país objetivo, el canal de entrega y el marco de cumplimiento.

FormatoExigido por
UBL 2.1Peppol BIS Billing 3.0 (transporte en red)
CIIFactur-X, ZUGFeRD, XRechnung (ambos CII y UBL aceptados)
CII o UBLFrancia (Portail Public de Facturation: ambos aceptados)

Peppol BIS Billing 3.0 es solo UBL. Si se transmite por la red Peppol, hay que producir UBL.

Factur-X y ZUGFeRD son CII. El adjunto factur-x.xml dentro de un PDF/A-3 es siempre CII.

XRechnung acepta tanto CII como UBL, pero CII (CrossIndustryInvoice) es más comúnmente probado por los validadores de portales del gobierno alemán.

Conversión entre formatos

No hay conversión automática sin pérdidas entre UBL y CII. El contenido semántico es idéntico, pero:

  • Algunos campos se mapean a atributos en un formato y a elementos en el otro
  • La profundidad de anidamiento difiere, lo que afecta a cómo se leen los elementos secuenciales como las líneas de factura
  • La colocación del código de moneda difiere entre formatos (algunas implementaciones CII asumen que la moneda de la cabecera aplica a todas las líneas)
  • Los formatos de fecha difieren: UBL usa YYYY-MM-DD, CII usa YYYYMMDD con un atributo format="102"

La conversión es posible pero requiere una capa de mapeo dedicada. El uso de XSLT es común; la comunidad OpenPEPPOL proporciona mapeos de referencia.

Rendimiento y herramientas

UBL está más ampliamente soportado en las bibliotecas .NET y Java. OASIS UBL existe desde 2006 y la mayoría de las herramientas XML empresariales tienen soporte explícito para él.

CII es menos común en las herramientas de desarrollo europeas fuera de Francia y Alemania. Existen bibliotecas de análisis pero tienden a ser más especializadas.

Saxon HE maneja la validación Schematron para ambos. Los archivos XSLT precompilados de las versiones de Peppol BIS en GitHub incluyen archivos XSLT separados:

peppol-en16931-ubl.xsl    (for UBL invoices)
peppol-en16931-cii.xsl    (for CII invoices)

Ejecutar cada uno contra el formato de entrada apropiado.

Cuál implementar primero

Para la mayoría de los desarrolladores que inician una nueva integración de facturas europeas en 2026, UBL es el mejor punto de partida:

  • El transporte en la red Peppol requiere UBL
  • La mayoría de los países de la UE aceptan UBL en los portales nacionales
  • Las herramientas .NET y Java son más maduras
  • La especificación UBL es más consistente en la colocación de atributos

Si se opera específicamente en Francia o Alemania, CII se vuelve necesario para Factur-X y ZUGFeRD. Esa es una segunda capa de implementación, no un reemplazo.

Para fines de archivo, PDF/A-3 con CII incrustado es el estándar. La mayoría de los procesos que transmiten Peppol UBL por la red también generan un PDF Factur-X CII para el archivo del comprador. Los dos cumplen funciones diferentes y coexisten.

Una nota sobre la validación

Independientemente de la sintaxis usada, hay que validar contra las reglas Schematron del perfil correcto. Una factura que es UBL válido puede fallar las reglas de Peppol BIS 3.0 si faltan elementos específicos de Peppol obligatorios. Una factura que es CII válido puede fallar el perfil EN 16931 de Factur-X si faltan campos opcionales requeridos por ese perfil.

El problema más profundo es que la mayoría de los procesos necesitan ambas. Una entrega Peppol requiere UBL. El archivo del comprador requiere un PDF Factur-X con CII incrustado. Mantener dos rutas independientes de generación XML, dos pasadas de validación y dos conjuntos de archivos de reglas Schematron duplica la superficie de área para errores de corrección.

SealDoc genera ambas a partir de la misma entrada. Una única llamada a la API con los datos de la factura produce el documento UBL para la transmisión Peppol y el PDF/A-3 con CII incrustado para el archivo del comprador. La validación Schematron se ejecuta contra ambas salidas antes de que se devuelva cualquiera de ellas. No hay que mantener ninguna ruta de generación XML ni rastrear las versiones de Peppol BIS.

Para comprobar archivos existentes, el validador público de SealDoc acepta tanto UBL como CII e informa sobre los fallos por número de BT y código de regla de negocio. Útil para diagnosticar documentos recibidos de socios comerciales o para calibrar una exportación de facturas de terceros contra los requisitos EN16931.

← Back to all articles