ValidateFin

Verifactu Validator Spain

Check your billing records — and their chained hash — before you send them to the AEAT. In your browser, nothing uploaded.

AEAT controlsOfficial AEAT XSDHuella recomputed100% local
100% Local

What is Verifactu, and what does this tool validate?

Verifactu is the reporting mode by which a Spanish invoicing system (SIF, governed by Royal Decree 1007/2023 and Order HAC/1177/2024) sends data to the AEAT, the Spanish tax agency. What the AEAT receives is not a UBL-style invoice but billing records: one RegistroAlta per invoice issued and one RegistroAnulacion per cancellation, grouped in a RegFactuSistemaFacturacion submission. Each record carries a huella: a chained SHA-256 fingerprint that folds in the previous record’s huella, so that the invoice chain cannot be altered unnoticed. This free validator checks the file in two layers: first against the official AEAT XSD (SuministroLR.xsd and SuministroInformacion.xsd), then against the rejection controls the AEAT itself publishes in “Validaciones y errores” (v1.2.2, 08/04/2026), returning the exact official code — 1108, 1130, 1142, 1152, 1177, 1189/1190, 1195/1196, 1223… — and it RECOMPUTES each record’s huella, reproducing the AEAT’s three official test vectors. Everything runs in your browser: the record never leaves your machine.

In brief

  • Official AEAT XSD (SuministroLR.xsd + SuministroInformacion.xsd)
  • The AEAT's own rejection controls, with their official codes: 1108, 1130, 1142, 1152, 1177, 1189/1190, 1223…
  • The huella recomputed: chained SHA-256, reproducing the AEAT's 3 official test vectors
  • RegistroAlta and RegistroAnulacion · voluntary (VERI*FACTU) or requerimiento submissions
  • Rejections told apart from "accepted with errors" (the 2xxx series), exactly as the AEAT does
  • 100% in your browser: the record is never uploaded

Verifactu validator: check your billing records — and their huella — before the AEAT sees them

Spanish invoicing systems (SIF) governed by Royal Decree 1007/2023 and Order HAC/1177/2024 do not send invoices to the AEAT: they send billing records. One RegistroAlta per invoice issued, one RegistroAnulacion per cancellation, grouped into a RegFactuSistemaFacturacion submission. The AEAT validates them one by one and answers with a code: accepted, accepted with errors, or rejected.

This tool works in two layers. First the official AEAT XSD (SuministroLR.xsd and SuministroInformacion.xsd): structure, types, cardinalities and closed enumerations. Then the rejection controls the AEAT itself publishes in "Validaciones y errores" (v1.2.2, 08/04/2026), with their exact code: 1108 (issuer NIF differs from the obligado), 1114/1115, 1116/1117 and 1118/1119 (consistency of corrective and substituted invoices), 1130 (illegal characters in NumSerieFactura), 1138/1139 (macrodato), 1142 (CuotaRepercutida against base and rate), 1152, 1177 (IdSistemaInformatico), 1189/1190 (the Destinatarios block, driven by TipoFactura), 1195/1196 (OperacionExenta and CalificacionOperacion are mutually exclusive) and 1223.

And it does what almost nothing else does: it RECOMPUTES the huella. Every record carries a SHA-256 fingerprint that folds in the previous record's huella — hence "chained hash" — and nobody can check it without redoing the arithmetic character by character. Our implementation reproduces the three official vectors from the AEAT's own paper, "Especificaciones técnicas para generación de la huella o hash" (v0.1.2, 27/08/2024). Everything runs in your browser: the record is never transmitted.

Key takeaways

  • The huella is a CHAINED SHA-256 hash: each record folds in the previous record's huella. That is what makes the invoice chain tamper-evident — and what nobody verifies without redoing the computation.
  • A wrong huella is NOT a rejection: it is code 2000, of the 2xxx "accepted with errors" series. The AEAT stores the record anyway and asks for a correction. Our taxonomy follows the AEAT's, not intuition.
  • Error 1142 is pure arithmetic: CuotaRepercutida against BaseImponibleOimporteNoSujeto and TipoImpositivo. The XSD accepts such a record without blinking; the AEAT rejects it.
  • Codes 1189 and 1190 are symmetrical: if TipoFactura is F1, F3, R1, R2, R3 or R4 the Destinatarios block is mandatory; if it is F2 or R5, it is forbidden.
  • About half of the controls need an AEAT registry (the NIF censo, the duplicate history, the signing certificate). The tool lists them on screen instead of hiding them behind a green badge.

Frequently asked questions

Does this validator send my file to the AEAT?

No. The record is read and analysed entirely in your browser: nothing is transmitted. Validating here is not filing, and does not replace sending it through your channel.

What exactly is the huella, and why do you recompute it?

It is the record's fingerprint: a SHA-256 string built from specific fields of the record AND from the previous record's huella. Chained that way, records form a sequence that cannot be altered retroactively without breaking the chain. Checking it means redoing the exact computation — field order, formatting, encoding — and that is precisely what we do: our implementation reproduces the AEAT's three official test vectors.

If the huella is wrong, is the record rejected?

No — and this is the counter-intuitive part. A wrong huella is code 2000, in the 2xxx "accepted with errors" series. The AEAT records it and asks you to fix it. That is why it shows up here as an advisory rather than a rejection: we follow the AEAT's taxonomy.

What does error 1142 mean?

That CuotaRepercutida does not match BaseImponibleOimporteNoSujeto and TipoImpositivo within the same breakdown. It is an arithmetic control the XSD can never see, and one of the most common causes of rejection.

Why could a record that is "valid" here still be rejected?

Because some controls need a database we cannot reach without uploading your file: whether the NIF exists in the censo (1109/4107), whether the record duplicates one already in the AEAT's history (3000), whether the signing certificate authorises the sender (4112). The timestamp tolerance (2004) cannot be implemented either: the numeric threshold is published nowhere — the official wording stops literally at "admitiéndose un margen de error de:". The tool lists all of these rather than letting you believe they were checked.

Where do the rules come from?

From official documents only: the AEAT's XSD schemas (SuministroLR.xsd, SuministroInformacion.xsd), the "Validaciones y errores" control list v1.2.2 (08/04/2026), and the "Especificaciones técnicas para generación de la huella o hash" v0.1.2 (27/08/2024). Origen de los datos: Agencia Estatal de Administración Tributaria (schemas retrieved on 13/07/2026). ValidateFin is an independent tool, neither certified nor endorsed by the AEAT.

ValidateFin is an independent tool. It is not certified, approved, affiliated with or endorsed by the Agencia Estatal de Administración Tributaria (AEAT), and nothing here should be read as suggesting otherwise. “Official” refers only to the artefacts used — the AEAT’s XSD schemas (SuministroLR.xsd, SuministroInformacion.xsd), its “Validaciones y errores” control list (v1.2.2, 08/04/2026) and its hash specification (“Especificaciones técnicas para generación de la huella o hash”, v0.1.2, 27/08/2024) — not to any accreditation of this tool. Origen de los datos: Agencia Estatal de Administración Tributaria — schemas and control lists retrieved on 13 July 2026. About half of the AEAT’s controls query a government registry (the censo for NIF checks, the duplicate history, the signing certificate) and cannot run in a browser; the tool lists them on screen rather than hiding them behind a green badge. Validating a file here does not submit it to the AEAT.