O que deve cumprir o seu software para o VeriFactu: os requisitos, um a um

De onde saem os requisitos

De duas normas que é preciso ler em conjunto. O Real Decreto 1007/2023 aprova o Regulamento e diz o que é preciso garantir; a Orden HAC/1177/2024 desce ao pormenor e diz como: formatos, algoritmos, milímetros. Tudo o que se segue sai daí.

1. Os seis adjetivos do artigo 8.º

O artigo 8.º é a espinha dorsal. Exige que o sistema garanta a integridade, conservação, acessibilidade, legibilidade, rastreabilidade e inalterabilidade dos registos de faturação. Soa a declaração de intenções, mas o n.º 2 concretiza-o e é aí que morde:

• 8.2.a) — uma vez gerados e registados, os dados não podem ser alterados sem que o sistema o detete. Considera-se alteração tanto ocultar ou eliminar um registo como modificar os seus dados. Qualquer correção faz-se com um registo posterior adicional, conservando o original.
• 8.2.b) — os registos devem estar encadeados, de modo a poder verificar-se o seu rasto seguindo a sequência de criação desde o primeiro até ao último.

Como se verifica: peça uma demonstração do que acontece ao tentar corrigir uma fatura já emitida. Se o programa deixar editá-la e guardar, não cumpre. Deve levá-lo a uma retificativa ou a uma anulação.

2. O registo de alta: quando nasce e o que leva

O artigo 9.º fixa o momento: o registo de faturação de alta é gerado de forma simultânea ou imediatamente anterior à emissão de cada fatura. Não é um processo noturno nem um botão que alguém prime no fim do mês.

O artigo 10.º enumera o seu conteúdo: identificação fiscal do emitente e do destinatário, número e série, datas, tipo de fatura, discriminação de bases e quotas, o hash do registo anterior, a identificação do sistema informático que o gera e a marca temporal, entre outros. São dezassete elementos.

Como se verifica: pergunte se o registo é criado dentro da mesma transação que a fatura. Se a fatura puder ficar emitida e o registo falhar em separado, tem uma brecha: duas verdades diferentes sobre o mesmo documento.

3. O hash (huella): SHA-256 e cadeia

O artigo 12.º do Regulamento exige acrescentar uma impressão digital ou hash (a «huella») aos registos de alta e de anulação. A Orden HAC/1177/2024, no seu artigo 13.º, concretiza o algoritmo —SHA-256— e que campos exatos entram no cálculo consoante o tipo de registo.

Cada registo incorpora parte do hash do anterior. Isso constrói uma cadeia: se alguém manipulasse um registo intermédio, todos os hashes posteriores deixariam de bater certo. É o mecanismo que torna verificável a inalterabilidade do artigo 8.º.

Como se verifica: pergunte se o sistema tem uma função para verificar a integridade da cadeia completa e o que faz se detetar uma rutura. Um programa que calcula hashes mas nunca os revê dar-lhe-á a má notícia no dia da inspeção, não antes.

4. O registo de anulação

O artigo 11.º regula o registo de faturação de anulação, que se gera quando uma fatura foi emitida por erro. É importante perceber o que não é: não apaga nada. Acrescenta um registo que deixa constância da anulação, e o original permanece.

Como se verifica: veja se o programa distingue entre anular (a fatura não devia ter existido) e retificar (o valor ou os dados eram outros). Não são a mesma coisa e não se resolvem da mesma forma.

5. O registo de eventos

Menos conhecido e muito citado pela metade. O artigo 8.3 exige que o sistema disponha de um registo de eventos que recolha automaticamente determinadas interações e operações, sem que o utilizador possa intervir. A ideia é deixar rasto do que se passa em torno dos registos de faturação —arranques, alterações de configuração, incidências—, e não apenas das faturas.

Como se verifica: peça para ver esse registo. Deve existir como tal dentro do sistema e não ser o log técnico do servidor que o fornecedor consulta quando lhe apetece.

6. As duas modalidades: remitir ou assinar

O artigo 15.º abre a porta à remessa voluntária dos registos e o artigo 16.º define o que é um sistema VERI*FACTU: aquele que os remete «de forma continuada, segura, correta, íntegra, automática, consecutiva, instantânea e fidedigna». A escolha tem consequências:

Para a maioria das PME, o VERI*FACTU sai mais barato em complexidade: troca-se o encargo de assinar e custodiar pelo de estar ligado.

7. O QR e a menção na fatura

A Orden chega ao milímetro. O seu artigo 21.º exige um código QR de entre 30 e 40 milímetros de lado, conforme à norma ISO/IEC 18004, que contém o NIF do emitente, o número da fatura, a data e o valor. E a fatura deve levar a menção que corresponda à modalidade.

Como se verifica: emita uma fatura de teste e leia o QR com o telemóvel. Deve levá-lo ao serviço de verificação da Agencia Tributaria (AEAT). E atenção a um pormenor que escapa: se o sistema estiver a trabalhar no ambiente de testes, o QR tem de apontar para o ambiente de testes, não para a sede real, onde essa fatura não existe.

8. A declaração responsável

O artigo 13.º do Regulamento obriga o produtor do software a emitir uma declaração responsável certificando que o sistema cumpre o disposto no artigo 29.2.j) da Ley General Tributaria (Lei Geral Tributária espanhola) e no próprio Regulamento. Tem de constar por escrito e de modo visível no próprio sistema informático, em cada uma das suas versões, e ser entregue a clientes e comercializadores.

Duas consequências práticas que quase ninguém menciona:

• É por versão. Um fornecedor com implementação contínua precisa de uma política de versionamento e de conservar a declaração de todas as versões que tenha produzido.
• Vai dentro do programa. Não é um PDF na gaveta comercial: deve poder consultar-se a partir do próprio sistema.

O que a norma não diz e se nota em produção

Até aqui, a letra. Estes quatro pontos não saem do BOE, saem de ter o sistema a funcionar:

1. Reenvio de remessas. A sede da Agencia Tributaria tem quedas e janelas de manutenção. Se uma falha de rede paralisar a sua faturação, o problema é de conceção, não da AEAT. O registo já está gerado e encadeado; o envio deve repetir-se sozinho, com o estado visível de cada um.
2. A modalidade fica congelada na fatura. O que importa é como o documento foi emitido, não como o sistema esteja configurado no dia em que alguém o reimprime. Se a menção do PDF se calcular na hora, uma reimpressão futura pode contradizer a fatura original.
3. Ambiente de testes a sério. Antes de faturar a sério é preciso poder ensaiar contra o ambiente de testes da AEAT, com o seu próprio URL de verificação.
4. Várias sociedades, várias cadeias. Se emitir a partir de mais de uma empresa, cada uma precisa da sua numeração, do seu certificado e da sua cadeia de hashes, sem se misturarem. Tratamos disto em VeriFactu numa empresa de transporte.

Dez perguntas para o seu fornecedor

1. Mostra-me a declaração responsável da versão que tenho contratada?
2. Em que modalidade trabalha o sistema, VERI*FACTU ou não verificável?
3. O registo de alta é gerado na mesma transação que a fatura?
4. Posso verificar a cadeia de hashes a partir do próprio programa?
5. O que acontece exatamente se eu tentar modificar uma fatura já emitida?
6. Distingue anulação de retificativa?
7. Onde vejo o registo de eventos?
8. O que acontece se a AEAT não responder? Repete o envio sozinho? Consigo vê-lo?
9. Se eu faturar a partir de duas sociedades, cada uma tem a sua série e o seu certificado?
10. Se no próximo ano entrar no SII (Suministro Inmediato de Información, o sistema espanhol de comunicação imediata de IVA), o que tenho de mudar?