ValidateFin

Verifactu Validator Spain

Verifique os seus registos de faturação — e a sua impressão encadeada — antes de os enviar à AEAT. No navegador, sem envio.

AEAT controlsOfficial AEAT XSDHuella recomputed100% local
100% Local

O que é o Verifactu e o que valida esta ferramenta?

O Verifactu é o modo de envio pelo qual um sistema informático de faturação espanhol (SIF, regulado pelo Real Decreto 1007/2023 e pela Ordem HAC/1177/2024) transmite dados à AEAT, a autoridade fiscal espanhola. A AEAT não recebe uma fatura no sentido UBL, mas registos de faturação: um RegistroAlta por cada fatura emitida e um RegistroAnulacion por cada anulação, agrupados num envio RegFactuSistemaFacturacion. Cada registo tem uma huella: uma impressão SHA-256 encadeada que incorpora a huella do registo anterior, de modo a que a cadeia de faturas não possa ser alterada sem que isso se note. Este validador gratuito verifica o ficheiro em duas camadas: primeiro com o XSD oficial da AEAT (SuministroLR.xsd e SuministroInformacion.xsd) e depois com os controlos de rejeição que a própria AEAT publica em «Validaciones y errores» (v1.2.2, 08/04/2026), devolvendo o código oficial exato — 1108, 1130, 1142, 1152, 1177, 1189/1190, 1195/1196, 1223… — e RECALCULA a huella de cada registo, reproduzindo os três vetores oficiais da AEAT. Tudo corre no seu navegador: o registo nunca sai do seu dispositivo.

Em resumo

  • XSD oficial da AEAT (SuministroLR.xsd + SuministroInformacion.xsd)
  • Os controlos de rejeição da AEAT, com o seu código oficial: 1108, 1130, 1142, 1152, 1177, 1189/1190, 1223…
  • A huella recalculada: SHA-256 encadeado, reproduzindo os 3 vetores oficiais da AEAT
  • RegistroAlta e RegistroAnulacion · envio voluntário (VERI*FACTU) ou por requerimiento
  • A rejeição distinguida do «aceite com erros» (série 2xxx), tal como faz a AEAT
  • 100% no navegador: o registo nunca é enviado

Validador Verifactu: verifique os seus registos de faturação — e a sua huella — antes de a AEAT os ver

Os sistemas informáticos de faturação espanhóis (SIF), regulados pelo Real Decreto 1007/2023 e pela Ordem HAC/1177/2024, não enviam faturas à AEAT: enviam registos de faturação. Um RegistroAlta por cada fatura emitida, um RegistroAnulacion por cada anulação, agrupados num envio RegFactuSistemaFacturacion. A AEAT valida-os um a um e responde com um código: aceite, aceite com erros ou rejeitado.

A ferramenta trabalha em duas camadas. Primeiro o XSD oficial da AEAT (SuministroLR.xsd e SuministroInformacion.xsd): estrutura, tipos, cardinalidades e enumerações fechadas. Depois os controlos de rejeição que a própria AEAT publica em «Validaciones y errores» (v1.2.2, 08/04/2026), com o seu código exato: 1108 (o NIF do emitente difere do obrigado), 1114/1115, 1116/1117 e 1118/1119 (coerência das faturas retificativas e substituídas), 1130 (carateres não permitidos em NumSerieFactura), 1138/1139 (macrodato), 1142 (CuotaRepercutida face à base e à taxa), 1152, 1177 (IdSistemaInformatico), 1189/1190 (o bloco Destinatarios, determinado pelo TipoFactura), 1195/1196 (OperacionExenta e CalificacionOperacion excluem-se mutuamente) e 1223.

E faz o que quase ninguém faz: RECALCULA a huella. Cada registo tem uma impressão SHA-256 que incorpora a huella do registo anterior — daí o «hash encadeado» — e ninguém a pode verificar sem refazer o cálculo, carácter a carácter. A nossa implementação reproduz os três vetores oficiais do documento da AEAT «Especificaciones técnicas para generación de la huella o hash» (v0.1.2, 27/08/2024). Tudo corre no seu navegador: o registo nunca é transmitido.

Pontos essenciais

  • A huella é um SHA-256 ENCADEADO: cada registo incorpora a huella do anterior. É o que torna a cadeia de faturas inviolável — e o que ninguém verifica sem refazer o cálculo.
  • Uma huella errada NÃO é uma rejeição: é o código 2000, da série 2xxx «aceite com erros». A AEAT regista-o na mesma e pede a correção. A nossa taxonomia segue a da AEAT, não a intuição.
  • O erro 1142 é aritmética pura: CuotaRepercutida face a BaseImponibleOimporteNoSujeto e TipoImpositivo. O XSD aceita esse registo sem hesitar; a AEAT rejeita-o.
  • Os códigos 1189 e 1190 são simétricos: se o TipoFactura for F1, F3, R1, R2, R3 ou R4, o bloco Destinatarios é obrigatório; se for F2 ou R5, é proibido.
  • Cerca de metade dos controlos exige um registo da AEAT (o censo de NIF, o histórico de duplicados, o certificado de assinatura). A ferramenta enumera-os no ecrã em vez de os esconder atrás de um selo verde.

Perguntas frequentes

Este validador envia o meu ficheiro à AEAT?

Não. O registo é lido e analisado integralmente no seu navegador: nada é transmitido. Validar aqui não é submeter, e não substitui o envio pelo seu canal.

O que é exatamente a huella e porque a recalculam?

É a impressão digital do registo: uma cadeia SHA-256 construída a partir de campos específicos do registo E da huella do registo anterior. Encadeados assim, os registos formam uma sequência que não pode ser alterada retroativamente sem quebrar a cadeia. Verificá-la exige refazer o cálculo exato — ordem dos campos, formatação, codificação — e é exatamente o que fazemos: a nossa implementação reproduz os três vetores oficiais da AEAT.

Uma huella errada faz rejeitar o registo?

Não — e é contraintuitivo. Uma huella errada é o código 2000, da série 2xxx «aceite com erros»: a AEAT regista-o e pede-lhe que o corrija. Por isso aparece aqui como aviso e não como rejeição: seguimos a taxonomia da AEAT.

O que significa o erro 1142?

Que CuotaRepercutida não bate certo com BaseImponibleOimporteNoSujeto e TipoImpositivo dentro do mesmo desdobramento. É um controlo aritmético que o XSD nunca poderá ver, e uma das causas de rejeição mais comuns.

Porque é que um registo «válido» aqui pode ainda assim ser rejeitado?

Porque alguns controlos precisam de uma base de dados que não podemos alcançar sem enviar o seu ficheiro: se o NIF existe no censo (1109/4107), se o registo está duplicado no histórico da AEAT (3000), se o certificado de assinatura habilita o remetente (4112). Também a margem de tolerância horária (2004) não é implementável: o limiar numérico não está publicado em lado nenhum — o texto oficial interrompe-se literalmente em «admitiéndose un margen de error de:». A ferramenta enumera todos estes casos em vez de o deixar crer que foram verificados.

De onde vêm as regras?

Apenas de documentos oficiais: os esquemas XSD da AEAT (SuministroLR.xsd, SuministroInformacion.xsd), a lista «Validaciones y errores» v1.2.2 (08/04/2026) e as «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 (esquemas obtidos a 13/07/2026). O ValidateFin é uma ferramenta independente, nem certificada nem patrocinada pela 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.