VERI*FACTU e software de faturação à medida: o prazo de 2027 e o adiamento anunciado para 2028

Antes de 1 de janeiro de 2027, todas as empresas em Espanha que entregam o imposto sobre o rendimento das pessoas coletivas (Impuesto sobre Sociedades) e faturam a partir de software têm de estar a usar software adaptado ao Real Decreto 1007/2023. Cada fatura passa a ter um registo com hash encadeado ao anterior e um código QR que o cliente pode verificar junto da administração fiscal. Todos os outros abrangidos, sobretudo trabalhadores independentes, têm até 1 de julho de 2027. A 5 de outubro de 2026, o Ministério das Finanças espanhol anunciou que vai adiar estas obrigações para outubro de 2028. A 16 de outubro, ainda não foi publicada nenhuma norma que o faça, por isso as datas de 2027 continuam a vincular.

Se as suas faturas saem de um pacote comercial, isto é em grande parte trabalho do seu fornecedor. Se saem de software que alguém escreveu para si, ou que a sua própria equipa escreveu, o trabalho é seu. É a sua empresa que altera o código e assina a declaração de que ele cumpre.

As datas e os dois adiamentos

Este é o terceiro conjunto de datas, por isso algum ceticismo é legítimo.

• O Real Decreto 1007/2023 dava inicialmente às empresas até 1 de julho de 2025.
• O Real Decreto 254/2025, de 1 de abril de 2025, passou essa data para 1 de janeiro de 2026 no caso de quem entrega o imposto sobre sociedades e para 1 de julho de 2026 no dos restantes. A razão era concreta: a portaria técnica, a Orden HAC/1177/2024, só foi publicada a 28 de outubro de 2024.
• O Real Decreto-ley 15/2025, de 2 de dezembro de 2025, adiou as duas datas um ano. O texto está no BOE, e o Congresso convalidou-o no mesmo mês.

A nota da AEAT sobre a prorrogação, atualizada pela última vez a 13 de outubro de 2026, não deixa margem para dúvidas: «las entidades que presenten el Impuesto sobre Sociedades deberán tener adaptados sus SIF antes del 1 de enero de 2027. El resto de obligados tributarios, antes del 1 de julio de 2027.»

Pode voltar a mudar? O Ministério das Finanças diz que sim. A sua nota informativa de 5 de outubro de 2026 anuncia que as obrigações do RD 1007/2023 ainda pendentes serão adiadas «hasta octubre de 2028», para coincidirem com a faturação eletrónica obrigatória das empresas com volume de negócios anual até 8 milhões de euros. É um anúncio, não uma alteração da lei. A nota indica um mês, mas não um dia, não diz que instrumento fará a alteração e não distingue entre empresas e trabalhadores independentes. A 16 de outubro de 2026, nada apareceu ainda no BOE, e as páginas da AEAT continuam a indicar as datas de 2027. Uma norma de última hora não seria invulgar: o Real Decreto-ley 15/2025 foi publicado a 3 de dezembro de 2025, quatro semanas antes da data que adiou. A nota diz também que os requisitos de integridade, rastreabilidade e inalterabilidade se manterão «en términos sustancialmente equivalentes», e que o âmbito e alguns pontos técnicos serão revistos mais tarde para convergirem com a faturação eletrónica e o ViDA.

Qual é a sua data? Uma SL ou uma SA entrega o Impuesto sobre Sociedades, por isso uma empresa com o seu próprio ERP está quase de certeza na data de 1 de janeiro de 2027. Enquanto uma norma publicada no BOE não disser o contrário, é essa a data que vincula, e faltam menos de doze semanas. A data de julho é para os trabalhadores independentes e os restantes contribuintes abrangidos.

O outubro de 2028 da nota vem de um regulamento diferente, cujo relógio já está a contar. A Orden HAC/1028/2026, publicada no BOE a 5 de outubro de 2026 e em vigor desde 6 de outubro, regula a solução pública de faturação eletrónica da AEAT e dá início aos prazos do Real Decreto 238/2026, a obrigação de faturação eletrónica entre empresas: doze meses para as empresas cujo volume de negócios ultrapassou 8 milhões de euros no ano anterior, vinte e quatro meses para as restantes. As faturas eletrónicas estruturadas entre empresas passam, assim, a ser obrigatórias em outubro de 2027 e em outubro de 2028. Um sistema à medida que fatura a outras empresas tem esse projeto pela frente, aconteça o que acontecer ao VERI*FACTU. Tratamos essa obrigação no nosso guia sobre a faturação eletrónica B2B em Espanha.

Quem está abrangido, e quem não está

As perguntas frequentes da AEAT sobre o âmbito reduzem-no a quatro negativas. Está abrangido se não fatura exclusivamente à mão, não está no SII (por obrigação ou por opção), não tem domicílio fiscal no País Basco nem em Navarra e não tem nenhuma decisão de isenção.

As exclusões, na prática:

• Quem está no SII. O Suministro Inmediato de Información é obrigatório para empresas com volume de negócios acima de 6 milhões de euros, grupos de IVA e empresas inscritas no registo de reembolso mensal do IVA (REDEME), e as outras podem aderir voluntariamente. A AEAT di-lo sem rodeios: «El ámbito subjetivo de ambos proyectos es excluyente.» Se passar para o SII, deixa de enviar registos VERI*FACTU e deixa de imprimir o código QR.
• O País Basco e Navarra. As empresas com domicílio fiscal nestas regiões respondem perante as fazendas forais e as suas próprias regras, não perante o RD 1007/2023.
• Faturação exclusivamente manual. Um livro de faturas em papel está fora do âmbito. O mesmo vale para uma folha de cálculo usada apenas para escrever, imprimir e guardar faturas; uma que também produza os seus livros de IVA já não está.

As empresas estrangeiras estão abrangidas quando têm um estabelecimento estável em Espanha.

Se fatura a partir de um pacote comercial (A3, Sage, Holded e semelhantes), o fornecedor é o produtor e tem de disponibilizar uma versão adaptada com a sua própria declaração. Atualize-o, confirme que a declaração lá está e pode parar de ler.

Este artigo é para os restantes casos: um ERP à medida, um programa em Access, Delphi ou FileMaker escrito há quinze anos, ou um módulo de faturação dentro da sua própria plataforma web.

A sua empresa é o produtor

O artigo 13.1 do regulamento atribui a certificação a quem produz o sistema, através de uma declaración responsable. As perguntas frequentes da AEAT sobre certificação respondem diretamente ao caso do desenvolvimento interno: «Cada sistema en operación debe disponer de una Certificación emitida mediante declaración responsable de su productor (artículo 13.1 RRSIF). Si el software hubiera sido desarrollado por la propia empresa, será esta la que deba certificarlo.»

O que isto significa na prática:

• Não há auditoria externa. A AEAT chama-lhe uma «auto-certificación» do produtor. Ninguém aprova o seu sistema antecipadamente. Assina, e responde por isso.
• Um prestador que desenvolva para si uma extensão como produto certifica essa extensão. Se foi a sua empresa a desenvolvê-la, é ela que a certifica.
• A declaração tem de estar visível dentro do sistema, em todas as versões, e também acessível fora dele, de forma independente do produto.
• O seu conteúdo está definido no artigo 15 da Orden HAC/1177/2024: entre outros elementos, o nome do sistema, o identificador e a versão, os componentes, se funciona apenas em modo VERI*FACTU, o nome, o NIF e a morada do produtor, e a data e o local da assinatura.

O caso mais delicado é o do programa cujo autor saiu há anos. Alguém tem de produzir a versão adaptada e assinar por ela. Decida quem, por escrito, antes de o trabalho começar.

A personalização de um produto comercial certificado só exige uma declaração própria se a alteração mexer na forma como os requisitos do regulamento estão implementados. Uma modificação feita fora do controlo do produtor que os possa alterar não cumpre.

O que está em jogo é definido pelo artigo 201 bis da Ley General Tributaria: uma coima fixa de 150 000 € por exercício e por tipo de sistema por produzir sistemas que não cumpram os requisitos, e de 50 000 € por exercício por ter um sistema que devia estar certificado e não está, ou que foi alterado. Qual destas se aplicaria a um sistema desenvolvido internamente é uma questão para o seu consultor fiscal. Nenhum dos valores é pequeno.

O que o software tem de fazer

Um registo por cada fatura, no momento da emissão

O artigo 9.1 exige que o sistema gere um registro de facturación de alta «de forma simultánea o inmediatamente anterior a la expedición de cada factura». Uma fatura anulada dá origem a um registo de anulação (registro de anulación).

O artigo 10 enumera o que o registo contém: NIF e nome do emitente, o destinatário quando exigido, série e número, datas de emissão e da operação, tipo de fatura, dados de qualquer fatura que retifique, uma descrição, o total, o regime de IVA, a base tributável, as taxas e os montantes, os motivos de isenção ou de não sujeição, a identificação do sistema e do seu produtor e um carimbo temporal ao segundo.

Nos sistemas mais antigos, é aqui que o trabalho se esconde:

• A discriminação do IVA é muitas vezes calculada no momento da impressão e nunca guardada. Tem de existir como dado no momento da emissão.
• «Emitir» é muitas vezes apenas imprimir um relatório. Tem de haver um momento explícito em que um rascunho passa a fatura, e é aí que o registo é criado.
• Acabou a reutilização de números. Apagar uma fatura e reutilizar o número, um hábito em muitos sistemas pequenos, passa a falhar: a AEAT rejeita o segundo registo com «Registro de facturación duplicado.» As faturas de teste emitidas em produção são faturas reais e têm de ser anuladas.
• Ninguém edita registos. As perguntas frequentes da AEAT dizem que as alterações diretas à base de dados dos registos emitidos não podem ser uma operação permitida. Se hoje a equipa corrige faturas com SQL, isso acaba. As correções fazem-se através de faturas retificativas.

A cadeia de hashes

Cada registo inclui a série, o número e a data do registo anterior e parte do seu hash (huella). O algoritmo é o SHA-256, e os campos exatos e a forma de concatenação estão na documentação técnica da AEAT, juntamente com os desenhos de registo, os esquemas XSD, o WSDL e o catálogo de validações e erros.

Antes de gerar um novo registo, o sistema tem de verificar que o último está corretamente encadeado e que o seu carimbo temporal não é mais de um minuto posterior à hora atual. Os registos são gerados pela ordem em que as faturas são emitidas.

Isto tem uma consequência na arquitetura. Cada instalação precisa de um ponto único e serializado onde os registos são criados. Dois servidores web a acrescentar registos à mesma cadeia sem coordenação vão parti-la. A AEAT aceita configurações mistas, como terminais de ponto de venda que recebem o registo de um back office central, mas a cadeia propriamente dita vive num só sítio.

Cada sistema é identificado pelo NIF do contribuinte, por um ID de sistema de dois caracteres e por um número de instalação que nunca se pode repetir, mesmo quando o mesmo software é reinstalado na mesma máquina.

O código QR na fatura

Todas as faturas levam um código QR conforme à norma ISO/IEC 18004, entre 30x30 e 40x40 mm, com nível de correção de erros M. Codifica um URL com o NIF do emitente, a série e o número, a data de emissão e o total, que o cliente pode verificar junto da AEAT. Em modo VERI*FACTU, a fatura indica ainda «VERI*FACTU» ou «Factura verificable en la sede electrónica de la AEAT».

Para o software legado, isto significa refazer o modelo da fatura (um relatório em Access, um layout em FileMaker, um gerador de PDF) e acrescentar uma biblioteca de QR a uma pilha tecnológica que nunca teve nenhuma.

Dois modos: VERI*FACTU ou não

Modo VERI*FACTU. O sistema envia automaticamente cada registo à AEAT, à medida que é gerado. Em contrapartida, os registos precisam de hash mas não de assinatura eletrónica, a AEAT guarda-os, e um sistema que só funcione neste modo dispensa o registo de eventos. Precisa de um cliente SOAP para os serviços publicados pela AEAT, de um certificado eletrónico qualificado e de uma fila de espera para quando a ligação falha. As perguntas frequentes da AEAT para programadores tratam uma falha de ligação como um incidente: os registos ficam na fila e são reenviados, e a faturação continua.

Modo não VERI*FACTU. Os registos ficam do seu lado, e cada um tem de ser assinado (XAdES Enveloped, ETSI EN 319 132) com um certificado qualificado. O sistema tem também de manter um registo de eventos assinado que cubra o arranque e a paragem neste modo, as verificações de anomalias e o que encontram, as restaurações de cópias de segurança e as exportações, com um evento de resumo pelo menos a cada seis horas de funcionamento, e tem de entregar os registos quando a AEAT os pedir.

Para um sistema à medida, o modo exclusivamente VERI*FACTU é normalmente o desenvolvimento mais pequeno. Sem infraestrutura de assinatura, sem registo de eventos, sem ferramentas de deteção de anomalias. Um sistema que ofereça os dois modos tem de implementar tudo.

Um plano enquanto a data está em dúvida

Planeie para a data legal, não para a anunciada. A partir de meados de outubro, quem entrega o imposto sobre sociedades tem cerca de onze semanas, o que é apertado para o que se segue. Os passos 1 a 6 são o mesmo trabalho seja qual for a data que acabe por se aplicar, já que o Ministério diz que os requisitos essenciais se manterão substancialmente equivalentes. O que um adiamento mudaria é o passo 7.

1. Semana 1: levantamento. Liste todos os sistemas que emitem faturas: o ERP, o módulo de faturação da loja online, o script de subscrições, o terminal do balcão. Confirme que não está no SII nem sujeito a regras forais.
2. Semanas 1 a 2: decida quem assina e qual o modo. Identifique o produtor de cada sistema. Escolha o modo exclusivamente VERI*FACTU, a não ser que tenha uma razão para não o fazer. Garanta que o certificado qualificado da empresa existe e que alguém é responsável por ele, porque as perguntas frequentes da AEAT para programadores notam que o sistema não pode funcionar sem ele.
3. Semanas 2 a 4: análise das lacunas nos dados. Compare o que o seu sistema guarda com o artigo 10 e com o desenho de registo da AEAT. É aqui que aparecem as discriminações de IVA, os códigos de tipo de fatura e as referências de retificação em falta.
4. Semanas 3 a 8: desenvolvimento. Geração do registo na emissão, a cadeia e as suas verificações, armazenamento inalterável, anulação, o QR em todos os modelos e o cliente de envio com a sua fila de reenvio. Elimine as edições diretas aos registos emitidos.
5. Semanas 6 a 10: testes. Comece no ambiente de testes da AEAT e, depois, envie registos reais. A AEAT trata o período anterior ao seu prazo como período de testes, durante o qual pode deixar de enviar e voltar a outro sistema. Leia as perguntas frequentes para programadores antes de escrever os fluxos de anulação e retificação: cobrem a maior parte dos casos-limite.
6. Semanas 9 a 12: declaração e formação. Redija a declaración responsable, mostre-a na aplicação e fora dela e registe a versão. Explique à área financeira que os números nunca se reutilizam e que os erros se corrigem com faturas retificativas.
7. Meados de dezembro: entrada em produção. Um prazo que diz «antes del 1 de enero» não é uma data de arranque. Entre em produção duas semanas antes, para que os primeiros problemas apareçam enquanto ainda há tempo. Se até lá estiver no BOE uma norma que adie a data, este é o passo a adiar.

Para a data de 1 de julho de 2027, aplica-se o mesmo plano com mais folga. Comece em janeiro, não em maio.

Há duas alternativas à reconstrução que vale a pena pesar com franqueza. A AEAT aceita arquiteturas mistas, por isso o seu ERP pode continuar a preparar os dados das faturas enquanto um componente separado, comprado ou desenvolvido, gera os registos, o QR e o envio, desde que as declarações cubram a forma como as partes se articulam. E se o programa antigo emite meia dúzia de faturas por mês, a aplicação gratuita de faturação da AEAT para pequenas empresas, ou um pacote standard, pode sair mais barato do que adaptá-lo.

Onde obter ajuda

Alteramos o código de faturação que as empresas já têm em funcionamento, incluindo pilhas tecnológicas mais antigas: geração de registos, a cadeia de hashes, o QR nos seus modelos e o cliente de envio para a AEAT, deixando os testes feitos. O nosso serviço de integração de faturação eletrónica cobre o desenvolvimento, e a manutenção de sistemas legados é por onde se começa quando já não resta ninguém que saiba como funciona o programa antigo.

Se tem uma data de 1 de janeiro de 2027 e um sistema à medida, escreva para office@c9group.dev. Somos engenheiros, não consultores fiscais: as questões de âmbito e de responsabilidade são para os seus, e nós desenvolvemos de acordo com a resposta que eles derem.