CONSIGLI PER LA CORRETTA FORMATTAZIONE DEL FILE FATTURA XML

27 Gennaio 2021

DOMANDA

Come deve essere compilata una fattura emessa nei confronti di un Cliente dell’Irlanda del Nord a seguito della BREXIT?

RISPOSTA

Come è noto il 24 dicembre 2020 è stato raggiunto l’accordo tra Regno Unito e Unione europea finalizzato a regolare il futuro delle relazioni economiche tra i due sistemi dopo la Brexit. L’accordo, entrato in vigore il primo gennaio 2021, prevede che il Regno Unito non sia più parte del territorio doganale e fiscale (IVA e accise) dell’Unione Europea.

Nell’ambito dell’accordo è stata introdotta una modifica nei rapporti doganali tra UE e Gran Bretagna che tiene conto della peculiare situazione dell’Irlanda del Nord e stabilisce che la stessa, a partire dal 1° gennaio 2021 per evitare una frontiera fisica tra l’Irlanda e l’Irlanda del Nord, rimarrà soggetta alla normativa dell’UE sull’IVA per le cessioni, gli acquisti intracomunitari e le importazioni di beni ivi situati.

A tal fine per identificare i soggetti passivi che effettuano nell’Irlanda del Nord cessioni di beni intracomunitarie o acquisti intracomunitari di beni, è stato introdotto un nuovo Codice Paese «XI», diverso da quello del Regno Unito “GB” che accompagnerà l’identificativo fiscale di tali soggetti.

Ciò premesso, in attesa di istruzioni operative puntuali da parte dell’Agenzia delle Entrate, AssoSoftware suggerisce il seguente comportamento nella compilazione delle fatture elettroniche e/o analogiche con operatori dell’Irlanda del Nord relative ad acquisti/cessioni di beni

L’identificativo fiscale dell’operatore dell’Irlanda del Nord (Cedente o Cessionario) dovrà essere compilato indicando nel “Codice Paese” il valore “XI” al posto di “GB”
Il codice Nazione facente parte dell’Indirizzo fisico della Sede o della Stabile organizzazione dovrà continuare a riportare il valore “GB”.

7 maggio 2019

DOMANDA
Come devono essere compilati i campi (‘CessionarioCommittente’ / ‘DatiAnagrafici’) ‘IdCodice’ e/o ‘CodiceFiscale’ nel caso di una fattura transfrontaliera intestata ad un privato (che non ha partita IVA comunitaria)?
Se viene compilato solo il campo <Codicefiscale>, ci ritorna l’errore 306 Codice Fiscale non valido.

RISPOSTA
Nel caso di Cliente estero (compreso il privato) non deve essere compilato il campo <CodiceFiscale> (campo valido solo per i residenti italiani) ma <IdFiscaleIVA> inserendo obbligatoriamente il codice Paese estero nel campo <IdPaese> (in questo caso il valore di <IdCodice> non viene controllato) e l’identificativo fiscale estero nel campo <IdCodice> se impresa e conosciuto, diversamente il campo può essere riempito con la ragione sociale o altro elemento identificativo, ovvero un valore di default (es. tutti 9). Il CAP nel caso di Paese estero deve essere riempito con tutti zeri.

11/03/2019

DOMANDA
Ho inviato ad un mio Cliente una fatture elettronica costruita seguendo la codifica standard suggerita da AssoSoftware (vedi www.assosoftware.it/eventi-e-news/standard-fe-e-protocollo-d-intesa). Il Cliente ha chiamato dicendo che la fattura non è valida e deve essere rifatta senza l’arricchimento standard. Cosa devo fare?

RISPOSTA
In premessa si ricorda che una fattura elettronica non scartata dallo SDI è correttamente emessa e non può essere rifiutata dal Cliente destinatario della merce o prestazione che ha ricevuto la fattura e lo stesso ha l’obbligo di registrarla contabilmente.
Si precisa ulteriormente che le informazioni gestionali aggiunte secondo lo standard AssoSoftware non alterano il contenuto informativo fiscalmente valido ma vanno ad inserirsi nell’area parametrica appositamente prevista per tali finalità (Tag 2.2.1.16 <AltriDatiGestionali>, blocco che consente di agli utenti di inserire, con riferimento ad una linea di dettaglio, informazioni utili ai fini amministrativi, gestionali etc.). E’ solo il caso di ricordare infine che lo Standard di Codifica AssoSoftware, sviluppato all’interno dell’Associazione dei Produttori di Software, è largamente condiviso ed utilizzato dalle software house Italiane (anche non associate) ed è stato iniziato il percorso con UNINFO (di cui AssoSoftware è socio ordinario) per far diventare lo Standard una Prassi di Riferimento UNI.

11/03/2019

I files fattura xml secondo le specifiche ministeriali possono essere firmati o non firmati. Nel caso di files non firmati l’estensione dovrebbe essere obbligatoriamente .xml; nel caso di files firmati digitalmente secondo il formato CAdES-BES l’estensione dovrebbe essere convenzionalmente .p7m; nel caso di files firmati digitalmente secondo il formato XAdES-BES l’estensione dovrebbe essere convenzionalmente .xml. Purtroppo si trovano a volte files con estensione incongruente con il contenuto della firma apposta e questo può generare difficoltà di lettura nei software gestionali.

22/02/2019

Il nodo <Allegati> non dovrebbe essere utilizzato come elemento descrittivo di commento.
Se è descritto un allegato, comprensivo di <NomeAttachment> e <DescrizioneAttachment> , il contenuto de0 l sotto elemento <Attachment> deve essere presente e non può essere vuoto.

11/03/2019

Le Note di Credito sono documenti di variazione negativa di imponibili e imposte. Tale effetto è predeterminato dalla tipologia associata al documento (TD04). I valori degli importi a credito devono quindi obbligatoriamente essere riportati sempre positivi sia nelle righe che nel riepilogo per aliquota. Eventuali documenti TD04 che riportano valori a credito negativi dovranno essere elaborati ignorando il segno.

22/02/2019

I valori numerici o alfanumerici dovrebbero essere riportati all’interno dei relativi tag senza spazi prima o dopo.
Si trovano a volte formattazioni del tipo:

<IdFiscaleIVA>
<IdPaese>IT</IdPaese>
<IdCodice>01010101010      </IdCodice>
</IdFiscaleIVA>

Queste formattazioni sono chiaramente errate e possono causare anomalie di elaborazione dei file anche gravi (es. mancato abbinamento delle fatture ai soggetti destinatari).

22/02/2019

Le specifiche tecniche SDI della fattura XML non indicano obbligatoriamente l’utilizzo della codifica UTF-8 tuttavia è consigliata per una corretta interpretazione dei dati inseriti. Sono da evitare altre codifiche (es. ISO-8859, CP1252, ecc..) che obbligano a conversioni dei dati in fase di lettura del file.
In apertura il file xml dovrebbe riportare come prima riga la versione del file xml e la codifica utf-8:

<?xml version=”1.0″ encoding=”utf-8″?>