FatturaPA Validator Italy
Find out whether the SdI would reject your invoice — and with which code — before you send it. In your browser, nothing uploaded. Signed .xml.p7m too.
What is FatturaPA, and when does the SdI reject an invoice?
FatturaPA is the XML format mandatory for every Italian electronic invoice — B2B, B2C and to public administrations — since 2019. Every invoice passes through the Sistema di Interscambio (SdI), the Agenzia delle Entrate’s clearing house, which either forwards it or returns a "notifica di scarto" quoting a numbered rejection code. A rejected invoice is legally not issued and must be corrected and resent within 5 days. This free validator checks the file against the official XSD (schema v1.2.3, namespace http://ivaservizi.agenziaentrate.gov.it/docs/xsd/fatture/v1.2) and reproduces the checks published in the SdI’s "Elenco dei controlli" v2.0, returning the exact code (00421, 00422, 00427, 00445, 00471…) the SdI would send back. Everything runs in your browser: the invoice never leaves your machine.
FatturaPA validator: know whether the SdI will reject your invoice, before you send it
Since 2019 every Italian electronic invoice — B2B, B2C and to public administrations — passes through the Agenzia delle Entrate's Sistema di Interscambio. The SdI is not a postman: it runs a list of 63 numbered controls and, if one fails, returns a "notifica di scarto". A rejected invoice is legally not issued, and must be corrected and resent within 5 days.
Most free validators stop at the XSD check (code 00200). That is the least interesting one: the schema will happily accept an invoice whose VAT is miscalculated, whose Natura code was withdrawn in 2021, or whose CodiceDestinatario is the wrong length. This tool also runs the substantive controls — the ones the SdI publishes in its "Elenco dei controlli" v2.0 — and hands you the exact code you would get back.
Real invoices usually travel signed: the file is not fattura.xml but fattura.xml.p7m, a binary CAdES envelope. This tool opens it and validates the XML inside. The signature itself is not verified — that needs the trusted-CA list and an online revocation check (SdI controls 00100-00107) — and the tool says so rather than letting you believe otherwise.
Key takeaways
- A file that is valid against the XSD can still be rejected by the SdI: the schema checks neither the VAT arithmetic nor the rules attached to TipoDocumento.
- The tolerances are not uniform: one CENT on <Imposta> (00421) and on <PrezzoTotale> (00423), but one EURO on <ImponibileImporto> (00422).
- <ImportoTotaleDocumento> is checked by no SdI control at all: a mismatch is an advisory, not a rejection.
- The generic N2, N3 and N6 codes are still in the XSD but have been banned since 01/01/2021 (control 00445): only a sub-code is allowed.
- About half of the SdI's controls query a government database (Anagrafe Tributaria, IndicePA): they cannot run offline, and the tool lists them instead of hiding them.
Frequently asked questions
Does this validator send my invoice to the SdI?
No. Nothing is transmitted: the file is read and analysed entirely in your browser. Validating here is not submitting, and does not replace sending it through your channel (PEC, web, SdICoop).
Why could an invoice that is "valid" here still be rejected?
Because some SdI controls need a database we cannot reach without uploading your file: whether the partita IVA exists in the Anagrafe Tributaria, whether the CodiceDestinatario is in IndicePA, duplicates across the SdI's whole history, the validity of the signing certificate. The tool lists each of them rather than letting you believe they were checked.
Does it accept signed .p7m files?
Yes. The CAdES envelope is opened and the XML inside is validated normally. The signature itself is not verified: that would require the list of trusted certification authorities and an online revocation check.
What is the difference between FPA12, FPR12 and FSM10?
FPA12 is an invoice to a public administration (6-character CodiceDestinatario, the IPA office code), FPR12 one to a private party (7 characters). They share the same XML schema — the two XSD files the AdE publishes are byte-for-byte identical. FSM10 is the simplified invoice (art. 21-bis), which has a schema of its own.
Why do the Agenzia delle Entrate's own example invoices come out non-conformant?
Because they genuinely are. They carry a placeholder partita IVA (01234567890, whose check digit should be 7), and two of them declare an ImponibileImporto of €27.00 against lines summing to €25.00 — a €2 gap, twice the tolerance of control 00422. One of them, FPR02, does not even pass the AdE's own XSD: it puts <ContattiTrasmittente> after <PECDestinatario>, while the schema declares them the other way round. These files date from 2014 and predate the controls that now reject them: they are format illustrations, not submittable invoices.
Where do the rules come from?
From two official documents only: the XSD schema v1.2.3 and the "Elenco dei controlli effettuati sul file fattura del SdI" v2.0 (31/01/2025), both published on fatturapa.gov.it. The partita IVA and codice fiscale check digits come from the Ministerial Decree of 23 December 1976. No rule here was inferred from a third-party source.
ValidateFin is an independent tool, neither certified nor endorsed by the Agenzia delle Entrate or the Sistema di Interscambio. “Official” refers to the schema and the control list used — the XSD and the “Elenco dei controlli” published on fatturapa.gov.it — not to any accreditation of this tool. Roughly half of the SdI’s controls query a government registry (Anagrafe Tributaria, IndicePA) and cannot run in a browser; the tool lists them explicitly rather than passing them over in silence. Validating a file here does not transmit it to the SdI.