Quando si invia una fattura a eConnect, il documento attraversa una serie di fasi di elaborazione. Il modo esatto in cui avviene l'elaborazione dipende dal tipo di file (XML o PDF) e dalla qualità del file fornito. Questo articolo spiega cosa accade dietro le quinte.

eConnect prevede due percorsi di elaborazione fondamentalmente diversi:

Elaborazione XML (percorso diretto): se si invia una fattura UBL valida (SI-UBL 2.0, Peppol BIS Billing 3.0 o un altro formato XML supportato), questa viene elaborata direttamente. La piattaforma legge i dati strutturati dall'XML, li valida e instrada il documento verso il destinatario. Questo è il percorso più veloce e affidabile.

Elaborazione PDF (conversione tramite IDR): se si invia una fattura in formato PDF, questa viene elaborata dall'Intelligent Document Recogniser (IDR). L'IDR estrae i dati della fattura tramite OCR e riconoscimento di pattern, e produce una fattura UBL sulla base dei dati riconosciuti. Questo processo è intrinsecamente meno affidabile rispetto all'elaborazione XML diretta, poiché dipende dalla qualità del PDF.

Suggerimento: l'invio in formato UBL è sempre preferibile rispetto al PDF. È più veloce, più economico e più affidabile. Verifichi presso il Suo fornitore o nel Suo pacchetto software se l'esportazione UBL è disponibile.

Quando si invia un file XML, eConnect esegue i seguenti passaggi:

La piattaforma riconosce automaticamente il formato del file in base al CustomizationID e allo schema XML. I formati supportati includono NLCIUS, BIS Billing V3, XRechnung, CII e Factur-X.

La fattura viene validata rispetto alle regole del profilo riconosciuto. Questo comprende:

• Validazione dello schema: il file XML è conforme alla struttura dello schema UBL 2.1 o CII?
• Business rules: i calcoli sono corretti? I campi obbligatori sono compilati? I valori delle code list corrispondono?
• Regole specifiche per Paese: vengono rispettate le regole NL-R-, DK-R- o altre regole nazionali?

Suggerimento: Riceve il messaggio che non sono state trovate "regole di validazione"? Generalmente significa che il CustomizationID nel Suo XML manca o non viene riconosciuto. Senza un profilo identificabile, il validatore non può applicare le regole di business. Verifichi che la Sua fattura contenga un CustomizationID valido, come quello di NLCIUS o BIS Billing V3.

Una caratteristica distintiva dell'elaborazione eConnect è la riparazione automatica dei file XML. Tramite trasformazioni XSL vengono corretti gli errori noti. La piattaforma accetta in linea di principio qualsiasi UBL; i campi non essenziali mancanti vengono compilati con valori predefiniti. Questa funzione di riparazione viene continuamente sviluppata sulla base del feedback dei clienti ed è pronta per la produzione.

Esempi di riparazioni automatiche:

• I campi opzionali mancanti vengono completati con valori predefiniti corretti
• Gli errori di formato noti nei campi identificativi vengono corretti
• I dati di contatto incompleti vengono integrati (se il campo ElectronicMail del fornitore è vuoto, eConnect inserisce automaticamente support@econnect.eu, in modo che le fatture rifiutate raggiungano comunque il mittente)

Se il destinatario supporta un formato diverso da quello di origine, la PSB trasforma automaticamente il documento. Ad esempio, una fattura NLCIUS può essere trasformata in XRechnung se il destinatario è un ente pubblico tedesco. Ciò è possibile perché tutti i formati supportati si basano sullo stesso modello semantico (EN 16931).

Tecnico: quando si scarica una fattura tramite l'API, è possibile specificare il formato di ricezione desiderato tramite il parametro targetDocumentTypeId. La PSB trasforma quindi il documento nel formato indicato.

eConnect non riconosce mai un ordine di vendita (documento d'ordine) come una fattura e non lo converte automaticamente in fattura. Se si invia un ordine di vendita in un punto dove è prevista una fattura, il documento viene rifiutato.

Il fornitore deve fornire personalmente un documento di fattura corretto: una UBL Invoice con il corretto InvoiceTypeCode. eConnect non modifica il documento di origine e non esegue questa conversione.

Eccezione -- orderflip: tramite la funzione orderflip, i dati dell'ordine possono servire da base per preparare una fattura in bozza (draft). Si tratta di un'azione utente separata, non di una conversione automatica di un ordine di vendita in fattura definitiva. Il fornitore deve completare personalmente tale bozza e presentarla come documento di fattura definitivo (UBL Invoice + InvoiceTypeCode).

Attenzione: non confonda il riconoscimento del tipo di documento con il riconoscimento dei riferimenti. Un numero d'ordine di vendita che deve essere riconosciuto su una fattura (come OrderReference o order_reference) è un campo di riferimento, non il tipo di documento in sé. eConnect legge tale numero d'ordine dalla fattura e lo collega come riferimento, senza però modificare il tipo del documento.

ZUGFeRD e Factur-X sono formati di fatturazione ibridi: un file PDF/A-3 con una fattura XML CII incorporata. Per questi documenti la piattaforma tenta prima di estrarre l'XML incorporato dal PDF. Se l'XML è valido, viene elaborato direttamente, come una normale fattura XML. Solo se l'XML incorporato non risulta valido, il sistema ricorre all'elaborazione OCR tramite l'IDR.

Una fattura ZUGFeRD che supera la validazione in validatori esterni ma viene comunque elaborata tramite OCR indica un problema con l'XML incorporato nel processo di validazione eConnect. In tal caso è possibile contattare il supporto.

Tecnico: la piattaforma legacy può memorizzare esclusivamente fatture UBL valide. Quando una fattura ZUGFeRD viene elaborata tramite l'IDR come PDF, l'output dell'IDR deve prima essere trasformato in UBL valido (BIS Billing V3 o NLCIUS). Se tale trasformazione non riesce perché i dati di origine non contengono campi sufficienti per una fattura UBL valida, la piattaforma non può memorizzare la fattura. Nella PSB/Control questo problema è meno rilevante, poiché le fatture vengono memorizzate nel formato originale e trasformate solo al momento della consegna.

Se si invia un file XML non valido, il sistema ricorre automaticamente al PDF allegato. Il funzionamento è il seguente:

1. La piattaforma tenta prima di elaborare la componente XML.
2. Se l'UBL non è valido, viene utilizzato il PDF allegato come fallback.
3. Il PDF viene elaborato tramite il percorso IDR (OCR e riconoscimento di pattern).

Questo meccanismo garantisce che la fattura venga sempre elaborata, anche se l'XML contiene errori. Si tratta tuttavia di un percorso più costoso e più lento rispetto all'elaborazione XML diretta.

Se un UBL viene rifiutato (perché non valido), eConnect elabora comunque gli altri allegati presenti nella stessa e-mail, come un PDF. Il mittente riceve quindi un'e-mail con:

• la notifica che la fattura UBL non verrà elaborata, incluso il messaggio di errore;
• la notifica che gli eventuali altri allegati nell'e-mail verranno elaborati.

Attenzione: questo messaggio di errore sulla fattura XML non può essere sopprimibile finché altri allegati nella stessa e-mail vengono elaborati.

Esempio -- BR-AE-10 (Inversione contabile): un UBL con categoria IVA AE (Inversione contabile) senza BT-121 (codice motivo esenzione IVA) o BT-120 (testo motivo esenzione IVA) attiva la regola di validazione BR-AE-10. Per la categoria AE deve essere presente almeno uno di questi campi. L'UBL viene rifiutato, un PDF allegato viene elaborato tramite il fallback IDR, e il messaggio di errore relativo all'UBL rimane visibile nell'e-mail al mittente.

Esempio -- BR-CO-18 / BR-Z-01 / BR-Z-05 (Zero rated / aliquota zero): un UBL con categoria IVA Zero rated (Z) su una riga fattura, maggiorazione o sconto documento, senza il corrispondente riepilogo IVA completo (BG-23), attiva la regola di validazione BR-CO-18 (riepilogo mancante), BR-Z-01 (nessuna riga di riepilogo con categoria Z) o BR-Z-05 (aliquota IVA per categoria Z diversa da 0). Anche qui si applica il dual-path: l'UBL viene rifiutato su questa/e regola/e, mentre un PDF allegato nella stessa e-mail viene comunque elaborato e arriva nella Posta in arrivo. L'errore è nell'UBL inviato dal mittente o dal suo software -- eConnect non modifica i riepiloghi IVA. La correzione richiede un nuovo UBL corretto (riepilogo Z completo, aliquota 0, righe e totali coerenti); inviare solo il PDF non è un sostituto strutturale sul percorso Peppol/UBL nativo. Dettaglio first-line: support/troubleshooting-sending.md § calcolo totale IVA.

SI-UBL 1.2 (Simplerinvoicing 1.2) è stato definitivamente dismesso dal 1° gennaio 2024. Le fatture in questo formato vengono rifiutate sulla rete Peppol. eConnect può talvolta ancora trasformare file SI obsoleti ricevuti via e-mail in NLCIUS valido, a condizione che i dati essenziali siano presenti. In caso di dati mancanti la validazione può fallire.

Attenzione: riceve messaggi di errore durante l'invio di fatture? Verifichi se il Suo pacchetto software genera ancora SI-UBL 1.2. In tal caso, chieda al Suo fornitore un aggiornamento a NLCIUS/SI-UBL 2.0 o BIS Billing V3.

L'elaborazione differisce leggermente tra la piattaforma legacy e la PSB/Control:

• Piattaforma legacy: una fattura viene sempre prima trasformata in UBL valido (BIS Billing V3 o NLCIUS) prima di essere memorizzata. Se tale trasformazione non riesce, la fattura non può essere memorizzata.
• PSB/Control: una fattura viene validata e memorizzata al momento della ricezione. La trasformazione avviene solo successivamente quando necessario, ad esempio al momento della consegna a un sistema ERP. Ciò significa che una fattura può essere memorizzata nella PSB, ma che successivamente può verificarsi un errore di trasformazione se il formato di destinazione non può essere generato.

eConnect elabora i campi UBL alla ricezione come forniti nell'UBL di origine e non ne modifica il contenuto. Non esiste alcun mapping dei campi configurabile dal cliente lato destinatario per riscrivere i valori forniti. I valori mancanti o errati devono essere corretti dal mittente nell'UBL di origine. eConnect corregge solo errori tecnici di formato noti e completa i campi opzionali non essenziali con valori predefiniti (vedere riparazione automatica dell'XML sopra).

Un esempio concreto con una nota di credito intracomunitaria in entrata (campi di consegna):

Entrambi i campi vengono elaborati da eConnect alla ricezione come forniti. BT-80 è obbligatorio solo quando la fattura include un gruppo Deliver-to-address (BG-15). eConnect non fornisce un mapping lato destinatario per riscrivere BT-72 o BT-80. Le correzioni di valori mancanti o errati sono effettuate dal mittente nell'UBL di origine.

Un indirizzo nella visualizzazione della fattura che mostra una mescolanza di dati di indirizzo di residenza e casella postale non è una mescolanza creata da eConnect in fase di ricezione. eConnect trasmette i campi indirizzo UBL (cac:PostalAddress) 1:1 e non riscrive né normalizza gli indirizzi. Se l'UBL di origine mescola i componenti di indirizzo di residenza e casella postale in un unico blocco PostalAddress, la visualizzazione segue tale origine.

Uno schema tipico di mescolanza nell'UBL di origine:

• cbc:StreetName = via e numero civico (indirizzo di residenza)
• cbc:AdditionalStreetName = CAP dell'indirizzo di residenza, nel campo errato
• cbc:BuildingName = Casella postale N (il campo canonico per la casella postale in UBL è cbc:Postbox)
• cbc:PostalZone = CAP della casella postale

La visualizzazione della fattura mostra quindi spesso la riga della via insieme a PostalZone/CityName, producendo visivamente un "indirizzo misto" senza che eConnect combini o corregga alcun campo. Entrambi i componenti dell'indirizzo possono essere corretti singolarmente, ma la loro combinazione in un blocco indirizzo condiviso con CAP incrociati è un errore di mapping nell'UBL di origine.

Azione: apra l'UBL di origine e verifichi gli elementi figli di PostalAddress della parte interessata. Il fornitore corregge il mapping: o un indirizzo di residenza coerente (StreetName con il PostalZone corrispondente), oppure una casella postale nel campo corretto (Postbox) con il CAP corrispondente -- non entrambi mescolati con CAP incrociati. Una volta corretto l'UBL di origine, la visualizzazione si risolve automaticamente.

Esempio -- fattura di credito "Payee/destinatario = propria organizzazione": con credito versus debito, AccountingSupplierParty e AccountingCustomerParty non si invertono. La direzione (da pagare o da ricevere) è nel tipo di documento e nel segno di PayableAmount, non in parti invertite. eConnect non modifica i ruoli delle parti e non riapplica automaticamente una precedente correzione Payee se l'UBL di origine è già corretto -- stesso principio di passthrough come sopra. Dettagliato con esempio: Varianti nota di credito.

Varianti di ricerca: "fattura di credito Payee", "fattura di credito Payee propria organizzazione", "Supplier Customer invertire credito".

Esempio -- IBAN o conto bancario (PaymentMeans) nella ricezione via Peppol: l'IBAN e gli altri dati di pagamento su una fattura ricevuta via Peppol provengono dall'UBL di origine del fornitore, di norma in cac:PaymentMeans / cac:PayeeFinancialAccount (metodo di pagamento e numero di conto; eventualmente un altro beneficiario tramite PayeeParty, ad esempio in caso di factoring). eConnect non compila questo numero di conto autonomamente e non modifica il contenuto del valore fornito -- anche qui vale il passthrough 1:1. Se l'IBAN su una visualizzazione PDF differisce dai dati XML strutturati, la differenza risiede in ciò che il fornitore ha inserito nell'UBL rispetto al PDF, non in una modifica di eConnect.

Azione in caso di IBAN errato o divergente: contatti il fornitore per ottenere una e-fattura corretta con l'IBAN corretto nell'UBL. Verifichi tramite un download XML se il campo PaymentMeans/IBAN differisce effettivamente. Verifichi anche il canale di invio: l'icona Peppol e l'icona di scansione (Scan & Riconoscimento) sulla piattaforma mostrano la differenza tra invio XML e riconoscimento PDF (vedere Icone sulla piattaforma). In una e-fattura via Peppol non c'è riconoscimento IDR/scansione sull'IBAN -- quel percorso vale solo per l'invio PDF via Scan & Riconoscimento.

Esempio -- più conti bancari concatenati in un unico campo PaymentMeans: talvolta la corrispondenza con il fornitore fallisce sull'IBAN perché nell'UBL trasmessa sono concatenati più numeri di conto in cac:PayeeFinancialAccount/cbc:ID (ad esempio IBAN1 seguito direttamente da IBAN2, come un'unica stringa invece di blocchi di conto separati), ed eventualmente anche più codici BIC concatenati in cac:FinancialInstitutionBranch/cbc:ID. Ciò deriva dall'UBL di origine o dal mapping del fornitore: eConnect trasmette l'XML 1:1 e non separa né normalizza IBAN/BIC sul percorso Peppol/XML. Nella stessa fattura via PDF (Scan & Riconoscimento), l'OCR di norma riconosce i numeri di conto come conti separati e corretti nell'UBL generata -- la differenza risiede nel percorso di origine (UBL concatenata erroneamente rispetto al riconoscimento OCR), non in un errore casuale della piattaforma.

Azione: verifichi il canale di invio (icona Peppol rispetto a icona di scansione). In caso di invio via Peppol/XML vale il passthrough sopra descritto: mostri il campo PaymentMeans tramite un download XML e faccia correggere l'UBL di origine dal fornitore con blocchi PaymentMeans/PayeeFinancialAccount separati, oppure un unico IBAN primario corretto per blocco. Se dallo stesso mittente arriva anche un PDF, l'OCR può fornire temporaneamente IBAN utilizzabili e separati -- la soluzione strutturale rimane la correzione dell'UBL di origine. Non confonda questo con la validazione IDR-IBAN tramite il verification store: è un percorso di riconoscimento PDF distinto.

Correzione su misura tramite consulenza (non self-service): eConnect può, sulla base di consulenza, configurare l'RBE (rule/business engine) per correzioni automatiche nel flusso. Si tratta di lavoro su misura tramite consulenza eConnect, non qualcosa che il cliente configura autonomamente. Non esiste una riscrittura self-service configurabile dal cliente dei campi UBL forniti lato destinatario.

Desidera verificare se il Suo file XML viene elaborato correttamente? Utilizzi il Validatore eConnect gratuito per testare la Sua fattura in anticipo.

• La struttura di una fattura UBL
• Qual è la differenza tra XML, UBL, BIS Billing V3 e NLCIUS?
• Campi di invio importanti in UBL
• SEEF: il formato standard per le e-fatture nel settore energetico
• Scarica file XML di esempio
• Dalla semantica alla sintassi