Italy's FatturaPA: what makes an invoice valid (TD01/TD04, Natura, SDI)
Italy's e-invoicing didn't wait for the EU-wide EN 16931 push — it's been mandatory for domestic B2B and B2C invoicing since 2019, running on its own national XML vocabulary: FatturaPA. If you're integrating with an Italian counterparty or building for the Italian market, here's what the format actually asks of you.
Not a UBL/CII profile
FatturaPA is a proprietary XML schema, not an EN 16931 syntax. It bundles what other formats keep separate — transmission-envelope metadata (who's sending, to what recipient code) and invoice content — into one document. That's a structural difference worth internalizing before you start mapping fields: there is no "convert UBL to FatturaPA" the way there is UBL↔CII, because the models aren't a superset/subset of each other.
TipoDocumento: what kind of document this is
The TipoDocumento code says what the document is. The two
you'll use almost always:
- TD01 — standard invoice (fattura).
- TD04 — credit note (nota di credito).
- TD05 — debit note (nota di debito) also exists, but it has no automatic mapping from a generic invoice type code; it has to be requested explicitly.
Anything past these three (advance invoices, self-invoices, fee notes and more) is a different animal with its own rules — worth rejecting explicitly rather than approximating if your engine doesn't fully support it.
Natura: why a line has no VAT rate
Natura codes explain why a line is VAT-exempt,
excluded, or reverse-charged — Italian VAT law requires the reason, not
just a zero rate. Common mappings from a generic invoice model's VAT
category:
| Generic category | Natura | Meaning |
|---|---|---|
| EXEMPT | N4 | VAT-exempt |
| INTRA_COMMUNITY | N3.2 | Intra-EU supply |
| EXPORT | N3.1 | Export outside the EU |
| REVERSE_CHARGE | N6.9 | Reverse charge |
| OUT_OF_SCOPE | N2.2 | Outside VAT scope |
The N2.2 mapping is the one that matters most for small
Italian businesses: it's what unlocks invoices for the popular
regime forfettario flat-rate scheme, where lines carry no VAT at
all.
The Italy-only fiscal extras
A handful of fields exist only in the Italian fiscal system, with no home in a generic cross-border invoice model:
- ritenuta d'acconto — withholding tax, common for professional services invoices.
- bollo — a revenue stamp, required on certain VAT-exempt invoices above a threshold.
- cassa previdenziale — a professional pension fund
contribution, added on top of the fee for regulated professions
(lawyers, engineers, accountants each have their own fund code,
TC01throughTC18).
These are typically modeled as extras alongside a canonical invoice rather than bolted onto the core model — Italy-specific line items that don't mean anything outside Italian tax law.
How it actually reaches the buyer: SDI
FatturaPA invoices don't go directly to the buyer. They're submitted to
SDI (Sistema di Interscambio), a government clearance system, using
either a 7-character recipient code (codice_destinatario) or
the buyer's certified email (PEC). SDI validates, routes and only then
delivers. formato_trasmissione distinguishes private
recipients (FPR12) from public administration
(FPA12).
What structural validation does and doesn't catch. Unlike EN 16931/Peppol/XRechnung/BR-FR, there's no public Schematron-equivalent business-rule artefact to check FatturaPA against — only the XSD is published. XSD-structural validation catches malformed documents and wrong types, not the roughly 200 business checks SDI itself runs at submission time. Structural validity is necessary, not sufficient.
curl -X POST "$BASE/v1/validate/facturapa" \ -H "Content-Type: application/xml" --data-binary @fattura.xml
A sample TD01 invoice and TD04 credit note, already validated, are available on our samples page — and the full field-by-field reference (including all optional fiscal extras) lives on the FatturaPA landing page.
Keep reading
Want to try this against a real invoice?
Every example above calls the same API you can call today — validate for free, or read the full reference.