← Back to all articles

Capire EN16931: il modello di dati della fattura europea

SealDoc Team · · 8 min read

EN16931 è lo standard europeo che definisce cosa deve contenere una fattura elettronica. Non è un formato XML. È un modello di dati semantico. Ogni principale formato di fatturazione elettronica europea, che si tratti di Peppol BIS Billing 3.0, Factur-X, ZUGFeRD o XRechnung, è un’implementazione di EN16931 in una specifica sintassi XML.

Capire EN16931 fa risparmiare tempo nel debug degli errori di validazione, nello spiegare i requisiti di integrazione ai fornitori ERP o nell’implementare un nuovo profilo fattura da zero.

Cosa specifica effettivamente EN16931

EN16931 è composto da due parti:

  • EN 16931-1 definisce il modello di dati semantico: quali elementi di dati può contenere una fattura, quali sono obbligatori e quali sono le regole aziendali
  • EN 16931-2 definisce i binding sintattici: come il modello semantico si mappa su XML UBL 2.1 e XML CII di UN/CEFACT

Il risultato è che una fattura Peppol BIS Billing 3.0 UBL e una fattura Factur-X CII possono rappresentare la stessa fattura commerciale. Il contenuto semantico è identico. La sintassi XML è completamente diversa.

Termini Aziendali e Gruppi Aziendali

EN16931 organizza i dati delle fatture in Gruppi Aziendali (BG) e Termini Aziendali (BT).

Un Gruppo Aziendale è una raccolta di termini correlati. Un Termine Aziendale è un singolo elemento di dati con un identificatore definito, un nome, una cardinalità e un tipo di dato.

I gruppi più importanti al livello superiore:

GruppoContenuto
BG-2 Controllo processoIdentificatore della specifica (BT-24), tipo di processo aziendale (BT-23)
BG-4 VenditoreNome, indirizzo, numero di partita IVA, registrazione legale
BG-7 AcquirenteNome, indirizzo, identificatore di riferimento, indirizzo elettronico
BG-22 Totali documentoBase imponibile, totale fattura, importo IVA, importo dovuto
BG-25 Riga fatturaQuantità, prezzo unitario, aliquota IVA, importo netto di riga

Il modello completo conta oltre 150 BT su tutti i gruppi. La maggior parte delle implementazioni ha bisogno solo di un sottoinsieme, ma validare un documento richiede di sapere quali BT sono obbligatori per il profilo target.

I Termini Aziendali che mettono in difficoltà gli sviluppatori

La maggior parte dei fallimenti di validazione proviene da un piccolo insieme di BT che sono incompresi o scarsamente documentati nelle guide all’implementazione.

BT-24: Identificatore della specifica

Deve essere un URI specifico che identifica a quale profilo dichiara di conformarsi la fattura. Per Peppol BIS Billing 3.0:

urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0::2.1

Sbagliare questo valore causa il rifiuto della fattura da parte del validatore del destinatario prima ancora di controllare qualsiasi contenuto dei campi. Ogni profilo (EN16931 core, Peppol BIS 3.0, Peppol BIS 3.0 con estensione nazionale) ha un URI diverso.

BT-10: Riferimento dell’acquirente

Usato in modo diverso nei vari paesi. In Germania, contiene il Leitweg-ID, un identificatore di instradamento obbligatorio per le fatture B2G. Nella maggior parte degli altri paesi è un riferimento interno all’ordine d’acquisto oppure viene lasciato vuoto. Il campo è facoltativo nella base EN16931 ma obbligatorio nel profilo nazionale tedesco.

BT-49: Indirizzo elettronico dell’acquirente

L’ID partecipante Peppol dell’acquirente. Formato: schema:identificatore. Per un’azienda belga identificata dal numero d’impresa:

<cbc:EndpointID schemeID="0208">0468863455</cbc:EndpointID>

Obbligatorio quando si trasmette sulla rete Peppol. Molte implementazioni lo omettono per le fatture B2B al di fuori di Peppol, il che è accettabile nella base EN16931 ma non valido nei profili Peppol BIS.

BT-131: Importo netto di riga della fattura

L’importo netto per una singola riga, calcolato come quantità per prezzo unitario meno eventuali sconti a livello di riga. La regola aziendale EN16931 BR-CO-10 richiede che la somma di tutti i valori BT-131 sia uguale a BT-106 (somma degli importi netti di riga della fattura).

L’arrotondamento è importante qui. Lo standard si aspetta che l’aritmetica venga eseguita su valori grezzi e arrotondata al livello aggregato, non per riga. Arrotondare ogni riga indipendentemente e poi sommare produce discrepanze che fanno fallire BR-CO-10 per grandi quantità.

BT-110: Importo IVA per categoria fiscale

L’importo IVA per categoria fiscale. La regola EN16931 BR-CO-15 richiede che il totale della fattura meno la base imponibile sia uguale alla somma di tutti i valori BT-117 (importi IVA per categoria). Gli errori qui sono spesso causati dall’aritmetica in virgola mobile o dall’arrotondamento prematuro.

Regole Aziendali: il livello di validazione

Le Regole Aziendali (BR) sono vincoli formali espressi in Schematron. Ci sono due categorie.

Regole strutturali verificano la presenza e il formato dei campi:

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).

Regole di calcolo verificano la coerenza aritmetica:

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 aggiunge regole di estensione nazionali sopra le regole base EN16931. Esempi:

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.

Queste regole di estensione variano per profilo nazionale e vengono pubblicate con ogni release di Peppol BIS.

Come EN16931 si mappa su UBL e CII

Le due sintassi XML gestiscono gli stessi BT ma utilizzano nomi di elementi e strutture completamente diversi. È per questo che il codice che analizza le fatture UBL non può analizzare le fatture CII senza un’implementazione separata, anche se entrambe sono conformi a EN16931.

Nome del venditore (BT-27) in entrambe le sintassi:

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>

Entrambi si mappano su BT-27. Il contenuto semantico è identico. Il percorso XML differisce completamente.

Peppol BIS 3.0 usa UBL. Factur-X e ZUGFeRD usano CII. XRechnung supporta entrambi. Il documento di mappatura EN16931-2 (gratuito da CEN/TC 434) elenca entrambi i percorsi per ogni BT ed è utile da tenere aperto durante l’implementazione.

Validazione Schematron

La validazione EN16931 è implementata come regole Schematron precompilate in XSLT 2.0. I set di regole ufficiali vengono pubblicati con ogni release di Peppol BIS:

github.com/OpenPEPPOL/peppol-bis-invoice-3/releases

Gli artefatti contengono file XSLT compilati:

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

Eseguire entrambi rispetto a una fattura restituisce SVRL (Schematron Validation Report Language). Una regola fallita appare così:

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

È richiesto un processore XSLT 2.0. In .NET, Saxon HE (open source, nessuna licenza enterprise necessaria) è la scelta standard. In Java, funzionano sia Saxon che Xerces.

Errori di implementazione comuni

Mescolare percorsi di elementi UBL e CII. Gli sviluppatori che lavorano con entrambi i formati incollano nomi di elementi dal binding sbagliato. Il documento di mappatura EN16931-2 previene questo errore.

Supporre che le regole di presenza siano uguali tra i profili. Un campo facoltativo nella base EN16931 potrebbe essere obbligatorio in Peppol BIS 3.0 o in un’estensione nazionale. Validare rispetto al profilo target, non allo standard base.

Arrotondamento al livello sbagliato. Calcolare i totali aritmetici grezzi su tutte le righe, poi arrotondare l’aggregato. Arrotondare ogni riga indipendentemente e sommare i valori arrotondati produce incoerenze aritmetiche che fanno fallire BR-CO-10, spesso di pochi centesimi su fatture grandi con molte righe.

BT-24 errato per il profilo target. Ogni profilo ha un URI di identificatore della specifica specifico. Usare l’URI base EN16931 su una fattura Peppol BIS 3.0 causa il rifiuto immediato del documento da parte della validazione del profilo.

Codici categorie IVA hardcoded. EN16931 definisce valori di codice specifici per le categorie IVA (S, Z, E, AE, K, G, O, L, M). Molte implementazioni hardcodano “S” (aliquota standard) e si rompono quando elaborano fatture in reverse charge o a tasso zero.

EN16931 è una conoscenza di infrastruttura

EN16931 è alla base di ogni obbligo europeo di fatturazione elettronica. Man mano che i requisiti vengono introdotti in Belgio, Francia, Germania e Polonia, capire il modello semantico diventa sempre più importante per gli sviluppatori che costruiscono o mantengono pipeline di fatturazione.

Comprendere la struttura BT/BG, le regole di calcolo e i binding sintattici ti mette nella posizione di fare il debug degli errori di validazione che altrimenti richiederebbero ore di lettura delle specifiche, implementare nuovi profili in modo pulito e comunicare chiaramente con i fornitori ERP e i team di conformità.

Il problema pratico non è imparare EN16931 una volta. È mantenere corrette le implementazioni man mano che i set di regole vengono aggiornati con ogni release di Peppol BIS, man mano che le estensioni nazionali aggiungono nuovi campi obbligatori, e man mano che i casi limite di arrotondamento emergono in produzione con dati reali di fatture da sistemi ERP reali.

SealDoc include set di regole che seguono le release di Peppol BIS. Quando generi una fattura tramite l’API SealDoc, il documento viene validato rispetto al profilo corretto prima di uscire dal sistema. BR-CO-10 e BR-CO-15 vengono verificati lato server in modo che gli errori di arrotondamento non raggiungano i tuoi acquirenti. Quando ricevi un errore di validazione da un partner commerciale, il validatore pubblico SealDoc accetta il documento e mappa ogni fallimento al BT specifico e alla BR violata, riducendo il tempo di diagnosi da ore a minuti.

Se stai implementando EN16931 da zero, il validatore è uno strumento di calibrazione utile: genera un documento candidato, passalo attraverso il validatore, correggi ciò che il report identifica, ripeti.

← Back to all articles