CRATEAPI

Italy's FatturaPA: what makes an invoice valid (TD01/TD04, Natura, SDI)

Italy3 min read

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:

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 categoryNaturaMeaning
EXEMPTN4VAT-exempt
INTRA_COMMUNITYN3.2Intra-EU supply
EXPORTN3.1Export outside the EU
REVERSE_CHARGEN6.9Reverse charge
OUT_OF_SCOPEN2.2Outside 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:

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.