ValidateFin

Verifactu Validator Spain

Sprawdź swoje rekordy fakturowe — i ich łańcuchowy skrót — zanim wyślesz je do AEAT. W przeglądarce, bez przesyłania.

AEAT controlsOfficial AEAT XSDHuella recomputed100% local
100% Lokalnie

Czym jest Verifactu i co waliduje to narzędzie?

Verifactu to tryb przekazywania danych do AEAT (hiszpańskiej administracji podatkowej) przewidziany dla systemów fakturowania (SIF), uregulowanych dekretem królewskim 1007/2023 i rozporządzeniem HAC/1177/2024. AEAT nie otrzymuje faktury w rozumieniu UBL, lecz rekordy fakturowe: jeden RegistroAlta na każdą wystawioną fakturę i jeden RegistroAnulacion na każde anulowanie, zgrupowane w przesyłce RegFactuSistemaFacturacion. Każdy rekord zawiera huellę: łańcuchowy skrót SHA-256, który obejmuje huellę poprzedniego rekordu — dzięki temu łańcucha faktur nie da się zmienić niezauważenie. Ten darmowy walidator sprawdza plik w dwóch warstwach: najpierw względem oficjalnego XSD AEAT (SuministroLR.xsd i SuministroInformacion.xsd), następnie względem kontroli odrzucenia publikowanych przez samą AEAT w «Validaciones y errores» (v1.2.2, 08.04.2026), zwracając dokładny kod oficjalny — 1108, 1130, 1142, 1152, 1177, 1189/1190, 1195/1196, 1223… — i PRZELICZA huellę każdego rekordu, odtwarzając trzy oficjalne wektory testowe AEAT. Wszystko działa w przeglądarce: rekord nigdy nie opuszcza Twojego urządzenia.

W skrócie

  • Oficjalny XSD AEAT (SuministroLR.xsd + SuministroInformacion.xsd)
  • Kontrole odrzucenia AEAT z ich oficjalnym kodem: 1108, 1130, 1142, 1152, 1177, 1189/1190, 1223…
  • Przeliczona huella: łańcuchowy SHA-256, z odtworzeniem 3 oficjalnych wektorów AEAT
  • RegistroAlta i RegistroAnulacion · przekazanie dobrowolne (VERI*FACTU) lub na żądanie
  • Odrzucenie odróżnione od «przyjęte z błędami» (seria 2xxx), dokładnie tak jak robi to AEAT
  • 100% w przeglądarce: rekord nigdy nie jest wysyłany

Walidator Verifactu: sprawdź swoje rekordy fakturowe — i ich huellę — zanim zobaczy je AEAT

Hiszpańskie systemy fakturowania (SIF), uregulowane dekretem królewskim 1007/2023 i rozporządzeniem HAC/1177/2024, nie wysyłają do AEAT faktur, lecz rekordy fakturowe: jeden RegistroAlta na każdą wystawioną fakturę i jeden RegistroAnulacion na każde anulowanie, zgrupowane w przesyłce RegFactuSistemaFacturacion. AEAT waliduje je pojedynczo i odpowiada kodem: przyjęte, przyjęte z błędami albo odrzucone.

Narzędzie działa w dwóch warstwach. Najpierw oficjalny XSD AEAT (SuministroLR.xsd i SuministroInformacion.xsd): struktura, typy, liczności i zamknięte wyliczenia. Następnie kontrole odrzucenia, które sama AEAT publikuje w «Validaciones y errores» (v1.2.2, 08.04.2026), wraz z ich dokładnym kodem: 1108 (NIF wystawcy różny od podmiotu zobowiązanego), 1114/1115, 1116/1117 i 1118/1119 (spójność faktur korygujących i zastąpionych), 1130 (niedozwolone znaki w NumSerieFactura), 1138/1139 (macrodato), 1142 (CuotaRepercutida wobec podstawy i stawki), 1152, 1177 (IdSistemaInformatico), 1189/1190 (blok Destinatarios zależny od TipoFactura), 1195/1196 (OperacionExenta i CalificacionOperacion wykluczają się wzajemnie) oraz 1223.

I robi to, czego prawie nikt nie robi: PRZELICZA huellę. Każdy rekord zawiera skrót SHA-256, który obejmuje huellę poprzedniego rekordu — stąd «skrót łańcuchowy» — i nikt nie sprawdzi go bez powtórzenia obliczenia, znak po znaku. Nasza implementacja odtwarza trzy oficjalne wektory z dokumentu AEAT «Especificaciones técnicas para generación de la huella o hash» (v0.1.2, 27.08.2024). Wszystko działa w przeglądarce: rekord nigdy nie jest przesyłany.

Najważniejsze

  • Huella to ŁAŃCUCHOWY skrót SHA-256: każdy rekord obejmuje huellę poprzedniego. To właśnie czyni łańcuch faktur odpornym na manipulacje — i tego nikt nie sprawdza bez ponownego przeliczenia.
  • Błędna huella to NIE odrzucenie: to kod 2000 z serii 2xxx «przyjęte z błędami». AEAT i tak zapisuje rekord i żąda poprawy. Nasza taksonomia idzie za AEAT, a nie za intuicją.
  • Błąd 1142 to czysta arytmetyka: CuotaRepercutida wobec BaseImponibleOimporteNoSujeto i TipoImpositivo. XSD przyjmuje taki rekord bez mrugnięcia okiem; AEAT go odrzuca.
  • Kody 1189 i 1190 są symetryczne: jeśli TipoFactura to F1, F3, R1, R2, R3 lub R4, blok Destinatarios jest obowiązkowy; jeśli F2 lub R5 — jest zabroniony.
  • Około połowa kontroli wymaga rejestru AEAT (censo NIF, historia duplikatów, certyfikat podpisu). Narzędzie wypisuje je na ekranie, zamiast chować za zieloną pieczątką.

Najczęstsze pytania

Czy ten walidator wysyła mój plik do AEAT?

Nie. Rekord jest wczytywany i analizowany w całości w Twojej przeglądarce: nic nie jest przesyłane. Walidacja tutaj nie jest złożeniem dokumentu i nie zastępuje wysyłki własnym kanałem.

Czym dokładnie jest huella i dlaczego ją przeliczacie?

To odcisk rekordu: ciąg SHA-256 zbudowany z określonych pól rekordu ORAZ z huelli poprzedniego rekordu. Tak połączone rekordy tworzą sekwencję, której nie da się zmienić wstecz bez rozerwania łańcucha. Sprawdzenie jej wymaga powtórzenia dokładnego obliczenia — kolejności pól, formatu, kodowania — i właśnie to robimy: nasza implementacja odtwarza trzy oficjalne wektory testowe AEAT.

Czy błędna huella powoduje odrzucenie rekordu?

Nie — i to jest wbrew intuicji. Błędna huella to kod 2000 z serii 2xxx «przyjęte z błędami»: AEAT zapisuje rekord i prosi o poprawę. Dlatego pojawia się tu jako ostrzeżenie, a nie odrzucenie: idziemy za taksonomią AEAT.

Co oznacza błąd 1142?

Że CuotaRepercutida nie zgadza się z BaseImponibleOimporteNoSujeto i TipoImpositivo w tym samym rozbiciu. To kontrola arytmetyczna, której XSD nigdy nie zobaczy, i jedna z najczęstszych przyczyn odrzucenia.

Dlaczego rekord «poprawny» tutaj może mimo to zostać odrzucony?

Bo część kontroli wymaga bazy danych, do której nie dotrzemy bez wysłania Twojego pliku: czy NIF istnieje w censo (1109/4107), czy rekord jest duplikatem w historii AEAT (3000), czy certyfikat podpisu upoważnia nadawcę (4112). Nie da się też zaimplementować marginesu czasowego (2004): próg liczbowy nie został nigdzie opublikowany — oficjalny tekst urywa się dosłownie na «admitiéndose un margen de error de:». Narzędzie wypisuje je wszystkie, zamiast pozwalać wierzyć, że zostały sprawdzone.

Skąd pochodzą reguły?

Wyłącznie z dokumentów oficjalnych: schematów XSD AEAT (SuministroLR.xsd, SuministroInformacion.xsd), listy kontroli «Validaciones y errores» v1.2.2 (08.04.2026) oraz «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 (schematy pobrane 13.07.2026). ValidateFin jest narzędziem niezależnym, nie posiada certyfikatu AEAT ani jej patronatu.

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.