← Back to all articles

UBL vs CII: quale sintassi XML per la fattura scegliere?

SealDoc Team · · 5 min read

Due sintassi XML possono rappresentare una fattura elettronica conforme a EN16931: UBL 2.1 e UN/CEFACT Cross Industry Invoice (CII). Entrambe sono corrette. Entrambe sono accettate da EN16931. Ed entrambe sono strutturalmente abbastanza diverse da non poter essere analizzate dall’altra senza un’implementazione separata.

Se stai costruendo un pipeline di fatturazione in Europa nel 2026, probabilmente le incontrerai entrambe. Ecco cosa devi sapere per scegliere quella giusta e gestire l’altra.

Cosa hanno in comune

Sia UBL che CII sono serializzazioni dello stesso modello semantico: EN16931. Il nome del venditore è il nome del venditore. Un importo IVA è un importo IVA. I termini aziendali (BT) e i gruppi aziendali (BG) sono identici in entrambe le sintassi.

EN 16931-2 definisce la mappatura ufficiale da ogni BT al suo percorso XML in entrambe le sintassi. Il documento è gratuito da CEN/TC 434 ed è il riferimento autorevole quando si ha bisogno di implementare entrambe.

Entrambi i formati sono basati su standard internazionali e sono accettati dai validatori EN16931. Entrambi producono fatture strutturate leggibili dalla macchina.

Come differiscono strutturalmente

Le differenze sono significative e pervasive. Nomi degli elementi, prefissi di namespace, strutture di annidamento e convenzioni degli attributi sono tutti diversi.

Nome del venditore (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 un annidamento profondo con namespace per componenti aggregati (cac:) e di base (cbc:). CII è più piatto, con namespace ram: (Reusable Aggregate Module) e rsm: (Reusable Schema Module).

Importo di riga della fattura (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>

I codici valuta in CII sono attributi degli elementi in alcuni punti e assenti in altri (con valuta dichiarata a livello di intestazione). UBL è più coerente: currencyID appare su ogni elemento di importo monetario.

Elemento radice e namespace

UBL 2.1 usa tre namespace:

<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 tre namespace diversi:

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

Non c’è sovrapposizione tra i due set di namespace. Un parser che punta a un formato non può elaborare l’altro.

Quale formato è obbligatorio dove

La scelta raramente dipende da te. Il formato è determinato dal paese di destinazione, dal canale di consegna e dal quadro di conformità.

FormatoImposto da
UBL 2.1Peppol BIS Billing 3.0 (trasporto di rete)
CIIFactur-X, ZUGFeRD, XRechnung (sia CII che UBL accettati)
CII o UBLFrancia (Portail Public de Facturation: entrambi accettati)

Peppol BIS Billing 3.0 è solo UBL. Se trasmetti sulla rete Peppol, devi produrre UBL.

Factur-X e ZUGFeRD sono CII. L’allegato factur-x.xml all’interno di un PDF/A-3 è sempre CII.

XRechnung accetta sia CII che UBL, ma CII (CrossIndustryInvoice) è più comunemente testato dai validatori dei portali governativi tedeschi.

Conversione tra formati

Non esiste una conversione automatica senza perdita di dati tra UBL e CII. Il contenuto semantico è identico, ma:

  • Alcuni campi si mappano ad attributi in un formato e a elementi nell’altro
  • La profondità di annidamento differisce, influenzando il modo in cui si leggono gli elementi sequenziali come le voci di riga
  • Il posizionamento del codice valuta differisce tra i formati (alcune implementazioni CII assumono che la valuta dell’intestazione si applichi a tutte le righe)
  • I formati delle date differiscono: UBL usa YYYY-MM-DD, CII usa YYYYMMDD con un attributo format="102"

La conversione è possibile ma richiede un livello di mappatura dedicato. L’uso di XSLT è comune; la community OpenPEPPOL fornisce mappature di riferimento.

Prestazioni e tooling

UBL è più ampiamente supportato nelle librerie .NET e Java. OASIS UBL esiste dal 2006 e la maggior parte del tooling XML enterprise ha un supporto esplicito per esso.

CII è meno comune nel tooling per sviluppatori europei al di fuori di Francia e Germania. Esistono librerie parser ma tendono ad essere più specializzate.

Saxon HE gestisce la validazione Schematron per entrambe. I file XSLT precompilati delle release GitHub di Peppol BIS includono file XSLT separati:

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

Eseguire ciascuno rispetto al formato di input appropriato.

Quale implementare per primo

Per la maggior parte degli sviluppatori che iniziano una nuova integrazione di fatture europee nel 2026, UBL è il punto di partenza migliore:

  • Il trasporto sulla rete Peppol richiede UBL
  • La maggior parte dei paesi UE accetta UBL sui portali nazionali
  • Il tooling .NET e Java è più maturo
  • La specifica UBL è più coerente nel posizionamento degli attributi

Se operi specificamente in Francia o Germania, CII diventa necessario per Factur-X e ZUGFeRD. Si tratta di un secondo livello di implementazione, non di una sostituzione.

Per l’archiviazione, PDF/A-3 con CII incorporato è lo standard. La maggior parte dei pipeline che trasmette Peppol UBL sulla rete genera anche un PDF Factur-X CII per l’archivio dell’acquirente. I due servono funzioni diverse e coesistono.

Una nota sulla validazione

Indipendentemente dalla sintassi che usi, valida rispetto alle regole Schematron del profilo corretto. Una fattura che è UBL valido potrebbe fallire le regole Peppol BIS 3.0 se mancano elementi obbligatori specifici di Peppol. Una fattura che è CII valido potrebbe fallire il profilo Factur-X EN 16931 se campi facoltativi richiesti da quel profilo sono assenti.

Il problema più profondo è che la maggior parte dei pipeline ha bisogno di entrambe. Una consegna Peppol richiede UBL. L’archivio dell’acquirente richiede un PDF Factur-X con CII incorporato. Mantenere due percorsi di generazione XML indipendenti, due passaggi di validazione e due set di file di regole Schematron raddoppia la superficie per i bug di correttezza.

SealDoc genera entrambi dallo stesso input. Una singola chiamata API con i dati della tua fattura produce il documento UBL per la trasmissione Peppol e il PDF/A-3 con CII incorporato per l’archivio dell’acquirente. La validazione Schematron viene eseguita su entrambi gli output prima che uno dei due venga restituito. Non devi mantenere nessun percorso di generazione XML né tenere traccia delle release di Peppol BIS.

Per controllare i file esistenti, il validatore pubblico SealDoc accetta sia UBL che CII e segnala i fallimenti per numero BT e codice di regola aziendale. Utile per diagnosticare documenti ricevuti dai partner commerciali o per calibrare un’esportazione fatture di terze parti rispetto ai requisiti EN16931.

← Back to all articles