← Blog
fattura elettronicaxmlfatturapaitaly

Anatomy of a FatturaPA

26 March 2026

Anatomy of a FatturaPA

An Italian electronic invoice is an XML file. Not a PDF, not a JSON: XML, with namespaces, an XSD schema, and a vocabulary entirely in Italian. Open it in a text editor and it tells you who you are, who your client is, how much they owe you, and how much tax is on top.

But it also tells you something else. It tells you what happens when a government designs a file format.

Let's take a real example and read it line by line.

The header: who transmits, not who invoices

The file begins with:

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

The namespace — that Agenzia delle Entrate URL — is the format's signature. The version FPR12 means "Fattura tra Privati, version 1.2": this distinguishes B2B/B2C invoices from invoices to the Public Administration, which use FPA12. Same structure, different routing.

The first real section is DatiTrasmissione — transmission data:

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

Here the first non-obvious distinction emerges: the transmitter is not necessarily the invoice sender. IdTrasmittente identifies who submitted the file to the SDI — the Sistema di Interscambio, Italy's government invoice routing system. When using an intermediary service like InvoiceTronic, this would be their identifier. Here it's the business owner's personal tax code.

ProgressivoInvio is a sequential transmission number. It is not the invoice number — that comes later, in DatiGeneraliDocumento. These are two completely separate numbering sequences: one for your protocol with the SDI, one for your fiscal invoice numbering.

The CodiceDestinatario with seven zeros is the convention for "the recipient has no active SDI channel." The invoice will land in their cassetto fiscale — a private area on the tax authority's online portal. If the recipient had registered a certified email (PEC), you'd put that in a PECDestinatario field instead. If they had an intermediary, you'd have a 7-character alphanumeric code.

Seller and buyer, Italian legal style

Then comes the vocabulary that tells you this format was written by tax lawyers, not software engineers.

CedentePrestatore — the one who transfers a good or provides a service, i.e., the seller. CessionarioCommittente — the one who receives the transfer or commissions the service, i.e., the client. Not "from" and "to". Not "sender" and "recipient". Terms straight out of the Italian VAT code, transcribed directly into the 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>

There are two distinct identifiers: IdFiscaleIVA (the VAT number, used for commercial transactions) and CodiceFiscale (the personal tax code, used for personal identification). For an Italian sole proprietorship, both are required.

RegimeFiscale is a code indicating the VAT regime. RF01 is the standard regime. RF19 is the flat-rate regime (forfettario) — a simplified scheme for those billing under €85,000 per year, which exempts from VAT but changes many things about the file's structure. There are roughly twenty codes in total, each with different implications for how the invoice is structured.

Then the client:

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

There's a subtle but telling error here. For an individual, you use <Nome> and <Cognome>. For a company, you use <Denominazione>. This client is clearly a company — SAS is a type of Italian partnership — but the file uses the individual fields. The SDI often accepts this anyway, because its validation is structural and checksum-based, not logically consistent across fields. This tolerance is deliberate: better to accept an invoice with imperfect registry data than to reject it and create compliance problems for thousands of users.

The body: the actual document

The second part of the file is FatturaElettronicaBody. It contains the document's fiscal data:

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

TipoDocumento is another code. TD01 is the standard invoice. There are also TD02 (advance payment on invoice), TD04 (credit note), TD06 (professional fee note), TD16–TD19 (self-invoices for reverse charge scenarios), and others. Each variant has different rules about which fields are required.

The Data field uses ISO 8601 — YYYY-MM-DD. One of the few universally sensible format choices in the entire document.

Line items and VAT

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

You'll notice VAT is declared twice: once as a rate on each line item, then again in the summary with the explicit calculation. The software must compute Imposta = ImponibileImporto × AliquotaIVA / 100, round to two decimal places, and write it down. The SDI verifies mathematical consistency.

EsigibilitaIVA indicates when the VAT is due to the treasury:

  • I — immediata: due in the period the invoice is issued
  • D — differita: due in the period payment is received
  • S — scissione dei pagamenti (split payment): used for Public Administration invoices, where the client pays the VAT directly to the treasury

For the vast majority of B2B invoices between private parties, it's I.

What the format reveals

One thing that becomes clear reading the full FatturaPA XSD is that it didn't sacrifice precision for simplicity. The format can represent genuinely complex situations: multi-party invoices, reverse charge, intra-EU operations, debit and credit notes, advance payments, withholding tax, discounts and surcharges, payment terms with IBAN.

That complexity isn't a design flaw — it reflects the real complexity of the Italian tax system, which in turn reflects decades of layered legislation. The XSD is, in a sense, a faithful representation of the VAT code.

The choice of XML — old, verbose, with namespaces — wasn't accidental. The format dates to 2014. At the time, XML was still the default institutional choice for government-to-government data exchange across Europe. And XML has a concrete advantage for this use case: digital signatures. The P7M format used for qualified electronic signatures is designed to wrap binary or XML files, and XML signature validation is standardized by W3C through XMLDSig — the xmlns:ds namespace in the header.

Today you'd probably use JSON with JWS. But the 2014 format won't change anytime soon: there's an entire ecosystem of software, intermediaries, and accounting systems built on top of the v1.2 XSD. Backward compatibility in fiscal contexts is permanent.

If you're building an integration with Italian electronic invoicing, the starting point is the official FatturaPA format documentation published by AgID. The format is more readable than it looks at first — it just takes a bit of patience with the vocabulary.