Verifactu Validator Spain
Vérifiez vos registres de facturation — et leur empreinte chaînée — avant de les envoyer à l’AEAT. Dans le navigateur, sans upload.
Qu’est-ce que Verifactu, et que valide cet outil ?
Verifactu est le mode de transmission à l’AEAT (l’administration fiscale espagnole) prévu pour les systèmes informatiques de facturation (SIF), encadrés par le décret royal 1007/2023 et l’arrêté HAC/1177/2024. Ce que l’AEAT reçoit n’est pas une facture au sens UBL, mais des registres de facturation : un RegistroAlta par facture émise, un RegistroAnulacion par annulation, regroupés dans un envoi RegFactuSistemaFacturacion. Chaque registre porte une huella : une empreinte SHA-256 chaînée, qui intègre la huella du registre précédent — la chaîne de factures devient ainsi infalsifiable sans que cela se voie. Ce validateur gratuit contrôle le fichier en deux couches : d’abord contre le XSD officiel de l’AEAT (SuministroLR.xsd et SuministroInformacion.xsd), puis contre les contrôles de rejet que l’AEAT publie elle-même dans « Validaciones y errores » (v1.2.2, 08/04/2026), en renvoyant le code officiel exact — 1108, 1130, 1142, 1152, 1177, 1189/1190, 1195/1196, 1223… — et il RECALCULE la huella de chaque registre, en reproduisant les trois vecteurs officiels de l’AEAT. Tout s’exécute dans votre navigateur : le registre ne quitte jamais votre machine.
Validateur Verifactu : contrôlez vos registres de facturation — et leur huella — avant que l’AEAT ne les voie
Les systèmes informatiques de facturation espagnols (SIF), encadrés par le décret royal 1007/2023 et l’arrêté HAC/1177/2024, n’envoient pas des factures à l’AEAT : ils envoient des registres de facturation. Un RegistroAlta par facture émise, un RegistroAnulacion par annulation, regroupés dans un envoi RegFactuSistemaFacturacion. L’AEAT les valide un à un et répond par un code : accepté, accepté avec erreurs, ou rejeté.
L’outil travaille en deux couches. D’abord le XSD officiel de l’AEAT (SuministroLR.xsd et SuministroInformacion.xsd) : structure, types, cardinalités et énumérations fermées. Ensuite les contrôles de rejet que l’AEAT publie elle-même dans « Validaciones y errores » (v1.2.2, 08/04/2026), avec leur code exact : 1108 (le NIF de l’émetteur diffère de celui de l’obligé), 1114/1115, 1116/1117 et 1118/1119 (cohérence des factures rectificatives et remplacées), 1130 (caractères interdits dans NumSerieFactura), 1138/1139 (macrodato), 1142 (CuotaRepercutida face à la base et au taux), 1152, 1177 (IdSistemaInformatico), 1189/1190 (le bloc Destinatarios, commandé par le TipoFactura), 1195/1196 (OperacionExenta et CalificacionOperacion sont exclusifs) et 1223.
Et il fait ce que presque personne ne fait : il RECALCULE la huella. Chaque registre porte une empreinte SHA-256 qui intègre la huella du registre précédent — d’où le « hachage chaîné » — et nul ne peut la vérifier sans refaire le calcul, caractère par caractère. Notre implémentation reproduit les trois vecteurs officiels du document de l’AEAT « Especificaciones técnicas para generación de la huella o hash » (v0.1.2, 27/08/2024). Tout s’exécute dans votre navigateur : le registre n’est jamais transmis.
À retenir
- La huella est un SHA-256 CHAÎNÉ : chaque registre intègre la huella du précédent. C’est ce qui rend la chaîne de factures infalsifiable — et ce que personne ne vérifie sans refaire le calcul.
- Une huella fausse n’est PAS un rejet : c’est le code 2000, de la série 2xxx « accepté avec erreurs ». L’AEAT enregistre quand même le registre et demande sa correction. Notre taxonomie suit celle de l’AEAT, pas l’intuition.
- L’erreur 1142 est de l’arithmétique pure : CuotaRepercutida face à BaseImponibleOimporteNoSujeto et TipoImpositivo. Le XSD accepte ce registre sans broncher ; l’AEAT le rejette.
- Les codes 1189 et 1190 sont symétriques : si le TipoFactura vaut F1, F3, R1, R2, R3 ou R4, le bloc Destinatarios est obligatoire ; s’il vaut F2 ou R5, il est interdit.
- Environ la moitié des contrôles exige un registre de l’AEAT (le censo des NIF, l’historique des doublons, le certificat de signature). L’outil les affiche à l’écran au lieu de les cacher derrière un badge vert.
Questions fréquentes
Ce validateur envoie-t-il mon fichier à l’AEAT ?
Non. Le registre est lu et analysé intégralement dans votre navigateur : rien n’est transmis. Valider ici n’est pas déclarer, et ne remplace pas l’envoi par votre canal habituel.
Qu’est-ce que la huella, exactement, et pourquoi la recalculer ?
C’est l’empreinte du registre : une chaîne SHA-256 construite à partir de certains champs du registre ET de la huella du registre précédent. Chaînés ainsi, les registres forment une séquence qu’on ne peut plus modifier rétroactivement sans casser la chaîne. La vérifier suppose de refaire le calcul exact — ordre des champs, formatage, encodage — et c’est précisément ce que nous faisons : notre implémentation reproduit les trois vecteurs officiels de l’AEAT.
Une huella fausse fait-elle rejeter le registre ?
Non — et c’est contre-intuitif. Une huella fausse, c’est le code 2000, de la série 2xxx « accepté avec erreurs » : l’AEAT enregistre le registre et vous demande de le corriger. C’est pourquoi il apparaît ici en avertissement et non en rejet : nous suivons la taxonomie de l’AEAT.
Que signifie l’erreur 1142 ?
Que CuotaRepercutida ne concorde pas avec BaseImponibleOimporteNoSujeto et TipoImpositivo au sein d’une même ventilation. C’est un contrôle arithmétique que le XSD ne verra jamais, et l’une des causes de rejet les plus fréquentes.
Pourquoi un registre « valide » ici peut-il quand même être rejeté ?
Parce que certains contrôles exigent une base de données que nous ne pouvons pas atteindre sans envoyer votre fichier : le NIF existe-t-il au censo (1109/4107), le registre est-il un doublon dans l’historique de l’AEAT (3000), le certificat de signature habilite-t-il l’émetteur (4112). La marge de tolérance horaire (2004) est, elle aussi, non implémentable : le seuil chiffré n’est publié nulle part — le libellé officiel s’arrête littéralement sur « admitiéndose un margen de error de: ». L’outil les liste tous, plutôt que de laisser croire qu’ils ont été vérifiés.
D’où viennent les règles ?
De documents officiels uniquement : les schémas XSD de l’AEAT (SuministroLR.xsd, SuministroInformacion.xsd), la liste « Validaciones y errores » v1.2.2 (08/04/2026) et les « 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 (schémas téléchargés le 13/07/2026). ValidateFin est un outil indépendant, ni certifié ni parrainé par l’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.