FatturaPA XML Format: Structure, File Name and Signature

A FatturaPA invoice is one XML file with a single header and one or more bodies, written to the Agenzia delle Entrate's schema version 1.2.3 and its technical specification version 1.4. The header says who sells, who buys and where the file goes. Each body is one invoice: its general data, its lines and tax summary, its payment details and any attachments. That is the structure whether the invoice is a public-sector invoice (format code FPA12) or a private one (FPR12).

This page is for the integration lead or developer outside Italy who has to produce the file, or check one a system has produced. It reads the Agency's own documents on 31 October 2026 and sets out the blocks, the file name, the signature and the checks that reject a file. How to reach Italy's exchange system and how to archive the result are separate questions and are not covered here.

Which version is current?

Specification 1.4 and schema 1.2.3, valid from 1 April 2025. The Agency's FatturaPA documentation page lists them under "Documentazione valida dal 1 aprile 2025": the XML schema for FatturaPA version 1.2.3, the schema for the ordinary invoice, the schema for the simplified invoice version 1.0.2, style sheets for display, and Specifiche tecniche del formato della FatturaPA versione 1.4. The previous set, specification 1.3.2 with schema 1.2.2, is listed as valid until 31 March 2025.

Specification 1.4 is dated 31 January 2025. Its own revision table gives the history in four lines:

One oddity is worth knowing before you download. The Agency publishes the schema under two names, Schema_VFPA12_V1.2.3.xsd for FatturaPA and Schema_VFPR12_v1.2.3.xsd for the ordinary invoice. On 31 October 2026 we downloaded both and compared them: the two files are byte-identical. The format code in the file, not the schema file you validate against, is what tells the two apart.

What does the file look like from the outside?

A root element, FatturaElettronica, with a required versione attribute holding FPA12 or FPR12. The schema's namespace is http://ivaservizi.agenziaentrate.gov.it/docs/xsd/fatture/v1.2. The root has an optional SistemaEmittente attribute, then the header, one or more bodies, and an optional XML signature element. An abbreviated skeleton, with most elements omitted:

<p:FatturaElettronica versione="FPR12"
    xmlns:p="http://ivaservizi.agenziaentrate.gov.it/docs/xsd/fatture/v1.2">
  <FatturaElettronicaHeader>
    <DatiTrasmissione> ... </DatiTrasmissione>
    <CedentePrestatore> ... </CedentePrestatore>
    <CessionarioCommittente> ... </CessionarioCommittente>
  </FatturaElettronicaHeader>
  <FatturaElettronicaBody>
    <DatiGenerali> ... </DatiGenerali>
    <DatiBeniServizi> ... </DatiBeniServizi>
    <DatiPagamento> ... </DatiPagamento>
  </FatturaElettronicaBody>
</p:FatturaElettronica>

A file with several bodies is a batch of invoices (a "lotto"). The header is common to the whole batch and each body is one invoice, as SdI's specification describes in its section on file naming.

What is in the header?

Six blocks, three of them required. The order in the schema is fixed:

1. DatiTrasmissione, required. The sender's tax identifier (IdTrasmittente), a file progressive (ProgressivoInvio), the format code, the recipient code (CodiceDestinatario), optional sender contacts and an optional certified email address for the recipient (PECDestinatario).
2. CedentePrestatore, required. The seller: tax identifier, name, registered address, tax regime.
3. RappresentanteFiscale, optional. The seller's fiscal representative.
4. CessionarioCommittente, required. The buyer: tax identifier or fiscal code, name, address.
5. TerzoIntermediarioOSoggettoEmittente, optional. A third-party intermediary issuing on the seller's behalf.
6. SoggettoEmittente, optional. Who issued the document, CC for the buyer or TZ for a third party.

The recipient code is the field that decides delivery, and its rules are in the specification itself. The code is six characters for a public administration and seven for anyone else. 0000000 means the recipient takes invoices by certified email, and the address then goes in PECDestinatario, or that the channel is not known. XXXXXXX is for invoices to customers who are not resident, established or identified in Italy. The companion page What Is an SDI Code? takes the code on its own.

What is in a body?

Five blocks, one per kind of data. The specification's table of contents lists them in order:

• DatiGenerali, whose main element DatiGeneraliDocumento carries the document type (TipoDocumento), currency (Divisa), date, number and optional withholding, stamp duty, pension fund contribution and discount data. The same block carries references to purchase orders, contracts, delivery notes and a related invoice. The codes for TipoDocumento are the subject of FatturaPA Document Types: The TD Codes.
• DatiBeniServizi. The invoice lines (DettaglioLinee) and the tax summary (DatiRiepilogo), which must agree with each other.
• DatiVeicoli, optional. Data on vehicles, for intra-Community sales of new transport.
• DatiPagamento, optional. Payment terms and method, from a coded list that runs from MP01, cash, to MP23, PagoPA.
• Allegati, optional. Attachments.

The tax lines are where most files go wrong, so they are worth a closer look. Each line carries a rate (AliquotaIVA), and when the rate is zero the line must carry a nature code (Natura) saying why. The nature codes are a closed list in schema 1.2.3: N1, N2, N2.1, N2.2, N3, N3.1 to N3.6, N4, N5, N6, N6.1 to N6.9 and N7. The schema still lists the bare N2, N3 and N6, but SdI no longer accepts them (error 00445, below). Use the sub-codes.

How is the file named?

Country code, sender identifier, underscore, progressive, extension. SdI's technical specification, version 1.8.4, section 2.2, sets the rule:

• The country code is the ISO 3166-1 two-letter code of the sender.
• The sender's identifier is its tax identifier: 11 to 16 characters for code IT, and 2 to 28 characters for any other country.
• The progressive is up to five characters from a-z, A-Z and 0-9. It only has to make the name different from the sender's other files. It does not have to run in strict sequence.
• The extension is .xml for a file with an XAdES signature and .xml.p7m for CAdES.
• A .zip file can carry several files, in which case each file inside is signed and the archive is not.

Examples from the specification are ITAAABBB99T99X999W_00001.xml and IT99999999999_00002.xml.p7m. The Agency's published sample invoices use IT01234567890_FPA01.xml for a public-sector invoice and IT01234567890_FPR01.xml for a private one. Every file must have a name different from any file sent before. A name that breaks the rule is rejected with error 00001, and a name already used with error 00002.

How is it signed?

Qualified signature or the Agency's seal, depending on the recipient. Section 2.1 of the same specification says what SdI accepts:

• An invoice to a public administration carries a time reference and a qualified electronic signature. The accepted formats are CAdES Baseline B and XAdES Baseline B, and for XML only the enveloped form is accepted. The time reference is the "signing time" attribute inside the signature.
• An invoice to anyone else is signed in the same way, or carries an XAdES signature made with the certificate of the Agency's own certification authority. The FatturaPA specification calls this "sigillo" and permits it only for invoices to private parties.

SdI checks the signature. Error 00102 is a signature that is not valid, 00100 an expired certificate, 00101 a revoked one, and 00103 a missing time reference. Whether, in practice, your trading partners or your system's channel apply the signature for you is a question about the channel you use and not about the format, and this page does not describe it.

What does SdI check beyond the schema?

A list of business rules, published as a separate document. The Agency's list of checks, version 2.0 (dated 31 January 2025) gives every rejection code and the rule behind it. A file that fails the schema is rejected with 00200. A file that passes the schema can still be rejected. These are the ones integration teams meet first:

The duplicate rule has one exception that surprises people. A credit note shares a number with its invoice: two documents with the same seller, year and number are allowed when one of them is a TD04.

Two more limits belong with the format. SdI's web upload accepts files up to 5 megabytes. And a file whose size exceeds what its channel allows is rejected with 00003.

What is still open?

Three things, as of 31 October 2026.

• Schema 1.2.3 is the current version, and a newer one may follow. The Agency has changed the schema roughly every one to three years since 2017. Check its page before you build against a copy of the schema.
• The signature in practice. We have read the rule as the specification states it. We have not read the Agency's channel instructions, which say what a given channel adds or does for you.
• Limits on other channels. The 5 megabyte figure is the web upload only.

What to do next

1. Download the two Agency documents linked above and validate a sample invoice from your system against schema 1.2.3. Fix schema errors before business-rule errors.
2. Fix the file name rule in your integration: sender identifier, a progressive that never repeats, and the right extension.
3. Map your document types with the companion page, FatturaPA Document Types: The TD Codes, and your recipient codes with What Is an SDI Code?.
4. If you invoice from outside Italy, read Invoicing an Italian Customer From Outside Italy before you build anything.
5. To talk through e-invoicing across several countries, book a demo. The developer documentation and the tutorials show how the GoRoute API works.

Related reading

• E-invoicing in Italy, the country page.
• What Is an SDI Code? The Codice Destinatario Explained
• FatturaPA Document Types: The TD Codes
• Invoicing an Italian Customer From Outside Italy
• San Marino e-invoicing, the neighbour that sits behind Italy's system.
• E-invoicing mandates by country, 2026

Sources, all read on 31 October 2026: Agenzia delle Entrate, FatturaPA documentation page, specification version 1.4 (31 January 2025) and the schema files Schema_VFPR12_v1.2.3.xsd and Schema_VFPA12_V1.2.3.xsd; the Agency's Sistema di Interscambio documentation page, which lists the technical specification version 1.8.4 (dated 31 March 2026, valid from 15 May 2026) and the list of checks version 2.0, both read in full for the sections cited. Translations from the Italian are ours.