fattura elettronicaxmlfatturapaitalia

Anatomia di una FatturaPA

26 marzo 2026

Una fattura elettronica italiana è un file XML. Non è un PDF, non è un JSON: è XML, con namespace, schema XSD, e un vocabolario interamente in italiano. Se la apri con un editor di testo, ti parla subito di dove siete, chi sei, chi è il tuo cliente, quanto gli devi, e quante tasse ci sono sopra.

Ma ti parla anche di altro. Ti parla di come si progettano le cose quando a farlo è uno Stato.

Prendiamo un esempio reale e leggiamolo riga per riga.

L'intestazione: chi trasmette, non chi fattura

Il file comincia così:

<?xml version="1.0" encoding="UTF-8"?>
<p:FatturaElettronica
  xmlns:p="http://ivaservizi.agenziaentrate.gov.it/docs/xsd/fatture/v1.2"
  versione="FPR12"
  ...>

Il namespace — quella URL dell'Agenzia delle Entrate — è la firma del formato. La versione FPR12 significa "Fattura tra Privati, versione 1.2": questo distingue le fatture B2B/B2C da quelle verso la Pubblica Amministrazione, che usano FPA12. Stessa struttura, routing diverso.

La prima sezione vera si chiama DatiTrasmissione:

<DatiTrasmissione>
  <IdTrasmittente>
    <IdPaese>IT</IdPaese>
    <IdCodice>RSSMRA80A01H501U</IdCodice>
  </IdTrasmittente>
  <ProgressivoInvio>42026</ProgressivoInvio>
  <FormatoTrasmissione>FPR12</FormatoTrasmissione>
  <CodiceDestinatario>0000000</CodiceDestinatario>
</DatiTrasmissione>

Qui emerge subito la prima distinzione non ovvia: il trasmittente non è necessariamente il mittente della fattura. L'IdTrasmittente identifica chi ha inviato il file all'SDI — il Sistema di Interscambio, il sistema di smistamento del governo. Nel caso di un intermediario come InvoiceTronic, sarebbe il loro codice. Qui è il codice fiscale del titolare dell'impresa.

Il ProgressivoInvio è un numero sequenziale di trasmissione. Non è il numero fattura — quello viene dopo, in DatiGeneraliDocumento. Sono due numerazioni completamente separate: una per il tuo protocollo interno con l'SDI, una per la numerazione fiscale delle fatture.

Il CodiceDestinatario con sette zeri è la convenzione per "il destinatario non ha un canale SDI attivo". La fattura finirà nel suo cassetto fiscale — un'area riservata sul portale dell'Agenzia delle Entrate. Se il destinatario avesse registrato una PEC, si metterebbe quella nel campo PECDestinatario. Se avesse un intermediario, avrebbe un codice a 7 caratteri alfanumerici.

Il cedente e il cessionario

Poi arriva il vocabolario che ti fa capire che il formato è stato scritto da giuristi, non da sviluppatori.

CedentePrestatore — chi cede un bene o presta un servizio, cioè il venditore. CessionarioCommittente — chi riceve la cessione o commissiona la prestazione, cioè il cliente. Non "from" e "to". Non "sender" e "recipient". Termini di diritto tributario italiano del codice IVA, trascritti direttamente nell'XSD.

<CedentePrestatore>
  <DatiAnagrafici>
    <IdFiscaleIVA>
      <IdPaese>IT</IdPaese>
      <IdCodice>12345678901</IdCodice>
    </IdFiscaleIVA>
    <CodiceFiscale>RSSMRA80A01H501U</CodiceFiscale>
    <Anagrafica>
      <Denominazione>Arancio Studio di Mario Rossi</Denominazione>
    </Anagrafica>
    <RegimeFiscale>RF01</RegimeFiscale>
  </DatiAnagrafici>
  ...
</CedentePrestatore>

Ci sono due identificativi distinti: IdFiscaleIVA (partita IVA, usata per le transazioni commerciali) e CodiceFiscale (codice fiscale personale, usato per l'identificazione anagrafica). Per una ditta individuale italiana, entrambi sono obbligatori.

Il RegimeFiscale è un codice a due cifre che indica il regime IVA. RF01 è il regime ordinario. RF19 è il forfettario — il regime agevolato per chi fattura meno di 85.000 euro l'anno, che esenta dall'IVA ma cambia molte cose nella struttura del file. Ci sono circa venti codici in totale, ognuno con le sue implicazioni.

Poi il cliente:

<CessionarioCommittente>
  <DatiAnagrafici>
    <Anagrafica>
      <Nome>Azienda</Nome>
      <Cognome>Agricola Datteri Sas</Cognome>
    </Anagrafica>
  </DatiAnagrafici>
  ...
</CessionarioCommittente>

Qui c'è un errore sottile ma significativo. Per una persona fisica si usano <Nome> e <Cognome>. Per una società si usa <Denominazione>. Questo cliente è chiaramente una SAS — una società — ma il file usa i campi per persona fisica. L'SDI spesso accetta comunque, perché la validazione è su struttura e checksum, non sulla coerenza logica dei dati anagrafici. Questo tipo di tolleranza è deliberata: meglio accettare una fattura con anagrafica imperfetta che respingerla e creare problemi di compliance a migliaia di utenti.

Il corpo: il documento vero

La seconda parte del file è FatturaElettronicaBody. Contiene i dati fiscali del documento:

<DatiGeneraliDocumento>
  <TipoDocumento>TD01</TipoDocumento>
  <Divisa>EUR</Divisa>
  <Data>2026-03-16</Data>
  <Numero>2</Numero>
  <ImportoTotaleDocumento>29.90</ImportoTotaleDocumento>
</DatiGeneraliDocumento>

TipoDocumento è un altro codice. TD01 è la fattura ordinaria. Esistono TD02 (acconto su fattura), TD04 (nota di credito), TD06 (parcella dei professionisti), TD16-TD19 (autofatture per l'inversione contabile), e altri ancora. Ogni variante ha regole diverse su quali campi sono obbligatori.

La Data usa ISO 8601 — YYYY-MM-DD. Una delle poche scelte di formato universalmente sensate in tutto il documento.

Le righe e l'IVA

<DettaglioLinee>
  <NumeroLinea>1</NumeroLinea>
  <Descrizione>Abbonamento Barba Studio - Piano Pro</Descrizione>
  <Quantita>1.00</Quantita>
  <PrezzoUnitario>24.51</PrezzoUnitario>
  <PrezzoTotale>24.51</PrezzoTotale>
  <AliquotaIVA>22.00</AliquotaIVA>
</DettaglioLinee>
<DatiRiepilogo>
  <AliquotaIVA>22.00</AliquotaIVA>
  <ImponibileImporto>24.51</ImponibileImporto>
  <Imposta>5.39</Imposta>
  <EsigibilitaIVA>I</EsigibilitaIVA>
</DatiRiepilogo>

Noti che l'IVA viene dichiarata due volte: nell'aliquota di ogni riga, e poi di nuovo nel riepilogo con il calcolo esplicito. Il software deve calcolare Imposta = ImponibileImporto × AliquotaIVA / 100, arrotondare a due decimali, e scriverlo. L'SDI verifica la coerenza matematica.

EsigibilitaIVA indica quando l'IVA è dovuta all'erario:

I — immediata: dovuta nel periodo in cui è emessa la fattura
D — differita: dovuta nel periodo in cui avviene il pagamento
S — scissione dei pagamenti (split payment): usata per le PA, dove è il cliente a versare l'IVA direttamente all'erario

Per la stragrande maggioranza delle fatture B2B tra privati è I.

Cosa rivela il formato

Una cosa che si nota leggendo lo XSD completo della FatturaPA è che non ha sacrificato la precisione alla semplicità. Il formato può rappresentare situazioni molto complesse: fatture multiparte, reverse charge, operazioni intracomunitarie, nota di debito e credito, acconti, ritenute d'acconto, sconti e maggiorazioni, dati di pagamento con IBAN.

La complessità non è un difetto di progettazione: riflette la complessità reale del sistema fiscale italiano, che a sua volta riflette decenni di norme stratificate. Lo XSD è, in un certo senso, una rappresentazione fedele del codice IVA.

La scelta di XML — anziano, verboso, con namespace — non è casuale. Il formato è del 2014. In quel momento XML era ancora la scelta istituzionale predefinita per gli scambi dati tra sistemi governativi europei. E XML ha un vantaggio concreto per questo caso d'uso: la firma digitale. Il formato P7M usato per le firme elettroniche qualificate è pensato per wrappare file binari o XML, e la validazione della firma su XML è standardizzata da W3C tramite XMLDSig — il namespace xmlns:ds che compare nell'intestazione.

Oggi probabilmente si userebbe JSON con JWS. Ma il formato del 2014 non sarà cambiato tanto presto: c'è un intero ecosistema di software, intermediari, e gestionali costruito sopra lo XSD v1.2. La backward compatibility, in ambito fiscale, è permanente.

Se stai costruendo un'integrazione con la fattura elettronica italiana, il posto da cui partire è la documentazione ufficiale del formato FatturaPA pubblicata da AgID. Il formato è più leggibile di quanto sembri a prima vista — ci vuole solo un po' di pazienza con il vocabolario.