O PDF Deixa de Servir a 31 de Dezembro: o que Muda na Faturação
A fatura em PDF vale até 31 de dezembro de 2026. A partir de 1 de janeiro de 2027 é preciso XML estruturado com assinatura qualificada. O que fazer nos próximos meses.
O que muda exactamente, e quando
Há duas datas a separar, e confundi-las custa dinheiro. Em Portugal, a fatura em PDF simples enviada por email continua a ser aceite como fatura eletrónica até 31 de dezembro de 2026, por força do Orçamento do Estado para 2026. A partir de 1 de janeiro de 2027, a fatura eletrónica tem de ser um ficheiro estruturado em XML no formato CIUS-PT, com assinatura digital qualificada. Não é o mesmo documento noutro invólucro: é outro documento. A diferença prática é esta. Um PDF é uma imagem de uma fatura, feita para um humano ler. Um XML estruturado é um conjunto de campos que o software do cliente lê sem intervenção de ninguém: NIF, linhas, taxas de IVA, totais, referências. O primeiro exige que alguém do outro lado copie os valores para o sistema. O segundo entra sozinho. Se emite faturas por PDF e nada mais, tem cerca de três meses para resolver isto. Se emite através de software certificado que já gera XML, provavelmente não tem nada a fazer além de confirmar com o fornecedor.
O que já é obrigatório e muita gente não cumpre
Antes de olhar para 2027, vale confirmar 2023. O ATCUD, o código único de documento introduzido pelo Decreto-Lei n.º 28/2019, é obrigatório desde janeiro de 2023 depois de vários adiamentos. Qualquer documento fiscalmente relevante emitido sem ATCUD é irregular perante a Autoridade Tributária. Junto com o ATCUD vai o código QR. Ambos têm de estar impressos e perfeitamente legíveis em todas as faturas, notas de crédito e restantes documentos fiscalmente relevantes. Não é uma questão de estética: um QR ilegível numa fatura fotografada por um inspetor é uma irregularidade. Encontramos isto com regularidade em empresas que mudaram de software há anos e nunca reviram os modelos de impressão. O ATCUD está no ficheiro, mas o template de PDF corta-o, ou o QR sai com resolução insuficiente para ser lido. O sistema cumpre; o papel que sai dele não.
SAF-T: dois ficheiros, dois calendários
O SAF-T é outro ponto onde as empresas assumem que estão em dia porque ouviram a sigla. Há dois ficheiros distintos e só um deles é mensal. O SAF-T da faturação é entregue mensalmente à Autoridade Tributária por todas as empresas com contabilidade organizada, até ao dia 5 do mês seguinte ao período de referência. É este que alimenta o e-fatura e que, na prática, torna cada fatura visível à AT poucos dias depois de emitida. O SAF-T da contabilidade é outra coisa e tem outro calendário: a obrigatoriedade de submissão foi adiada para 2028, referente ao exercício de 2027. A consequência de confundir os dois é comum: empresas que acreditam ter uma obrigação anual quando têm uma mensal, e que só descobrem o atraso quando acumulam meses.
| Obrigação | Portugal | Espanha |
|---|---|---|
| Código único no documento | ATCUD + QR, desde jan. 2023 | Sem equivalente directo |
| Registo inalterável no software | Software certificado pela AT | Veri*factu (RD 1007/2023) |
| Fim do PDF simples | 31 dez. 2026 | Regulado pela Lei Crea y Crece |
| XML estruturado obrigatório | 1 jan. 2027 (CIUS-PT) | Calendário Crea y Crece |
| Entrada em vigor para sociedades | 1 jan. 2027 | 1 jan. 2027 (Veri*factu) |
| Entrada em vigor para independentes | 1 jan. 2027 | 1 jul. 2027 (Veri*factu) |
Espanha: Veri*factu foi adiado, não cancelado
Quem fatura nos dois mercados tem de seguir dois calendários. Em Espanha, o Veri*factu obriga o software de faturação a gerar um registo encadeado e inalterável de cada fatura, com possibilidade de remessa à Agência Tributária. O Real Decreto 1007/2023 é a base. As datas foram adiadas um ano: 1 de janeiro de 2027 para os contribuintes do Impuesto sobre Sociedades e 1 de julho de 2027 para trabalhadores independentes e restantes obrigados. O adiamento tem um efeito perverso. Empresas que já tinham orçamentado a mudança para 2025 pararam. As que não tinham feito nada continuaram a não fazer. O resultado previsível é toda a gente a mudar de software ao mesmo tempo, no último trimestre de 2026, quando os fornecedores estão saturados e as migrações são feitas à pressa.
O que fazer nos próximos três meses
A sequência que usamos quando alguém nos chama para isto é sempre a mesma, e a primeira parte não tem software nenhum. Primeiro: confirme quem emite faturas na empresa e com quê. É mais comum do que parece haver um segundo canal — alguém que emite recibos de um Excel, um sistema de reservas que gera documentos próprios, uma loja online com o seu módulo. Cada canal é uma obrigação separada. Segundo: pergunte por escrito ao fornecedor do software se o produto vai emitir CIUS-PT com assinatura qualificada a partir de 1 de janeiro de 2027, e se isso está incluído no contrato ou é um módulo pago. A resposta por escrito é o que interessa. Já vimos respostas comerciais optimistas que não sobreviveram a uma pergunta directa sobre datas. Terceiro: teste um ficheiro real antes de dezembro. Um XML que valida contra o esquema é diferente de um XML que o cliente consegue importar. Se o destinatário é uma entidade pública ou uma empresa grande, peça-lhes um documento de exemplo e faça o percurso completo uma vez. Quarto: reveja os modelos de impressão. Se o ATCUD ou o QR estão cortados, isso é uma irregularidade que já existe hoje e que não tem nada a ver com 2027.
Quando não vale a pena mudar de software
Vale a pena dizer isto porque o mercado inteiro vai passar os próximos meses a dizer o contrário. Se o seu software actual é certificado, o fornecedor confirmou por escrito que emite CIUS-PT assinado a partir de janeiro de 2027, e a empresa tem menos de umas centenas de faturas por mês, não há nada a fazer além de aguardar a actualização. Mudar de programa nesse cenário é trocar um risco conhecido por um desconhecido, com migração de dados pelo meio. Mudar faz sentido quando há um segundo canal que não está coberto, quando o fornecedor não dá resposta clara sobre datas, quando a faturação está a ser feita em parte à mão, ou quando o custo do módulo de conformidade se aproxima do custo de um produto que já o inclui. O nosso trabalho aqui costuma ser menos glamoroso do que parece: ligar o que já existe em vez de substituir. Um sistema de reservas que já tem os dados todos raramente precisa de ser trocado — precisa de passar a emitir através do software de faturação em vez de emitir por conta própria.
O lado de quem recebe, que ninguém prepara
Toda a conversa sobre faturação eletrónica é conduzida do ponto de vista de quem emite. Metade do problema está do outro lado. A partir do momento em que os seus fornecedores começam a enviar XML estruturado em vez de PDF, alguém na sua empresa tem de os receber, validar e arquivar. Se o processo actual é imprimir o PDF anexado ao email e entregá-lo à contabilidade, esse processo deixa de funcionar: um XML não se lê em papel e não faz sentido imprimi-lo. Há aqui uma oportunidade que quase ninguém aproveita, e é a razão pela qual vale a pena tratar isto como projecto e não como obrigação. Uma fatura estruturada que chega tem todos os campos já separados: fornecedor, NIF, linhas, taxas, totais, datas de vencimento. Entrar com esses dados na contabilidade sem ninguém os digitar deixa de ser um exercício de leitura automática com margem de erro e passa a ser uma importação directa. Dito de outra forma: a mesma obrigação que custa dinheiro do lado da emissão pode poupar horas do lado da recepção, se alguém se der ao trabalho de ligar as duas pontas. Quem trata o XML recebido como um anexo chato a converter em PDF está a pagar o custo da mudança sem receber o benefício. O arquivo é a outra metade. Os prazos de conservação de documentos fiscais não mudaram, e um ficheiro estruturado tem de ser guardado de forma a continuar legível e íntegro durante esses anos, com a assinatura verificável. Guardar o XML numa pasta partilhada sem controlo de versões nem cópias de segurança não é arquivo.
Perguntas Frequentes (FAQ)
Posso continuar a enviar faturas em PDF depois de 2026?
Em Portugal, o PDF simples é equivalente a fatura eletrónica até 31 de dezembro de 2026. A partir de 1 de janeiro de 2027 a fatura eletrónica tem de ser XML estruturado em CIUS-PT com assinatura digital qualificada. Nada impede que continue a enviar também um PDF ao cliente para leitura humana; o que muda é que o PDF deixa de ser, por si só, a fatura.
O adiamento do Veri*factu significa que posso esperar?
Significa que a data passou para 1 de janeiro de 2027 para sociedades e 1 de julho de 2027 para independentes. Não significa que o trabalho desapareceu. Se o software actual não cumpre, a migração tem de acontecer algures antes dessa data, e fazê-la ao mesmo tempo que todo o mercado é a pior altura possível.
Veri*factu e a Lei Crea y Crece são a mesma obrigação?
Não. O Veri*factu regula o registo interno das faturas dentro do software, para impedir alterações posteriores. A Lei Crea y Crece regula o intercâmbio eletrónico do documento entre empresas e profissionais, em formato estruturado. Um programa pode cumprir o primeiro e continuar a enviar PDF por email, e nesse caso não cumprirá o segundo.
Com que frequência tenho de entregar o SAF-T?
O SAF-T da faturação é mensal, até ao dia 5 do mês seguinte ao período de referência, para empresas com contabilidade organizada. O SAF-T da contabilidade é um ficheiro diferente, com a obrigatoriedade de submissão adiada para 2028 relativamente ao exercício de 2027. Confundir os dois leva a atrasos que só se descobrem ao fim de vários meses.
A minha empresa fatura nos dois países. Preciso de dois sistemas?
Não necessariamente, mas precisa de um que trate as duas jurisdições como distintas em vez de traduzir uma na outra. As regras não se sobrepõem: o ATCUD português não tem equivalente espanhol e o registo encadeado do Veri*factu não tem equivalente português. Um produto que cubra só um dos mercados obriga a um segundo canal, e cada canal extra é uma obrigação extra.