A obrigação da E-Rechnung na Alemanha: emitir faturas estruturadas a partir dos seus próprios sistemas até 1 de janeiro de 2027

A partir de 1 de janeiro de 2027, uma empresa alemã cujo volume de negócios em 2026 tenha sido superior a 800 000 € deixa de poder enviar uma fatura em papel ou em PDF a outra empresa alemã. A fatura tem de ser uma fatura eletrónica estruturada: um ficheiro de dados construído segundo a norma europeia EN 16931. A partir de 1 de janeiro de 2028, o limiar desaparece e a regra aplica-se a todas as empresas, salvo algumas exceções muito restritas.

Para uma pequena empresa, isto chega sob a forma de uma atualização de software. Para uma empresa cujas faturas saem do seu próprio sistema de faturação, de um pacote setorial ou de um ERP personalizado ao longo de quinze anos, é um projeto de software, e restam cerca de treze semanas. Este artigo é para o segundo grupo.

O que diz a lei

A definição está no § 14 UStG: uma fatura «die in einem strukturierten elektronischen Format ausgestellt, übermittelt und empfangen wird und eine elektronische Verarbeitung ermöglicht», ou seja, emitida, transmitida e recebida num formato eletrónico estruturado que permita o seu tratamento eletrónico. O formato tem de estar conforme à norma europeia prevista na Diretiva 2014/55/UE (na prática, a EN 16931) ou ser acordado entre as partes, desde que os dados exigidos possam ser extraídos de forma correta e completa para um formato compatível com essa norma. Um PDF não serve, por mais arrumado que pareça.

A obrigação abrange as transmissões de bens e prestações de serviços a outra empresa quando ambas as partes estão estabelecidas na Alemanha. O regime transitório está no § 27 Abs. 38 UStG:

• As operações realizadas em 2025 e 2026 ainda podem ser faturadas em papel, ou noutro formato eletrónico se o cliente concordar, desde que a fatura seja enviada até 31 de dezembro de 2026.
• As operações realizadas em 2027 têm a mesma tolerância até 31 de dezembro de 2027, mas apenas se o volume de negócios total do emitente no ano civil anterior não tiver ultrapassado 800 000 €.
• O EDI que não cumpra a norma pode continuar a ser usado para operações realizadas em 2027, com o acordo do cliente, seja qual for a dimensão da empresa.

Há três pormenores que pesam mais do que parece.

O limiar mede-se pelo volume de negócios do ano anterior. A sua situação em 2027 depende do valor de 2026, que ninguém vai saber ao certo antes do fecho de contas. Se estiver perto dos 800 000 €, construa como se estivesse acima.

A tolerância termina numa data de envio. Lida à letra, a primeira regra transitória deixa de cobrir o papel e o PDF a 31 de dezembro de 2026, mesmo para trabalho feito em 2026. Se está acima do limiar e fatura depois de prestar o serviço, a fatura que envia na primeira semana de janeiro pelo trabalho de dezembro já tem de ser estruturada. Confirme-o com o seu consultor fiscal, mas não planeie o arranque para meados de janeiro.

Algumas faturas ficam fora do âmbito: faturas a consumidores, faturas transfronteiriças, faturas de pequeno montante até 250 € brutos, bilhetes que valem como fatura, faturas de Kleinunternehmer (pequenas empresas no regime de isenção) e operações isentas ao abrigo do § 4 Nr. 8 a 29 UStG.

Não temos conhecimento de nenhuma proposta de lei para alterar estas datas. Planeie como se se mantivessem.

Receber é obrigatório desde 2025. Emitir é a parte nova.

Desde 1 de janeiro de 2025, todas as empresas alemãs têm de conseguir receber faturas eletrónicas. As perguntas frequentes sobre a fatura eletrónica do Ministério Federal das Finanças são claras quanto ao que isso exige: «Für den Empfang einer elektronischen Rechnung genügt bereits ein E-Mail-Postfach.» Basta uma caixa de correio eletrónico.

Repare numa frase do próprio § 14: quando se aplica a obrigação da fatura eletrónica, não é necessário o consentimento do destinatário. Um cliente empresarial alemão não pode recusar a sua fatura estruturada.

Emitir é outro problema. Quando recebe, uma ferramenta lê o ficheiro de outra pessoa. Quando emite, o autor é o seu sistema: se os dados estiverem errados na origem, ninguém mais à frente na cadeia os consegue corrigir, e uma fatura que falha na validação do seu cliente fica por pagar.

Quem resolve isto com uma atualização

Sem rodeios: se é uma pequena empresa que fatura a partir do DATEV, do lexoffice, do sevDesk ou de um pacote semelhante, o seu fornecedor disponibiliza o formato. Verifique os dados mestre (número de IVA, moradas dos clientes, dados bancários), ative a funcionalidade e envie uma fatura de teste. Não precisa de um projeto nem de uma empresa de software.

O mesmo vale, em grande medida, para um ERP comum que se mantenha próximo do standard: o fornecedor ou o seu parceiro fornece o formato de saída, e o trabalho é de configuração e de testes.

O resto deste artigo é para empresas cujas faturas saem de código que lhes pertence, ou de código que já ninguém mantém:

• motores de faturação em plataformas de subscrição, marketplaces e empresas de serviços públicos, que emitem faturas de forma programática e em grande volume;
• software setorial para comércio grossista, construção, logística ou assistência técnica no terreno, cujo fornecedor é pequeno, lento ou já desapareceu;
• ERP cuja emissão de faturas foi reescrita há anos como programas de impressão à medida, modelos de relatório ou uma fusão de correspondência no fim do mês.

Os formatos: EN 16931, XRechnung e ZUGFeRD

A EN 16931 é a norma europeia. Define o modelo semântico de uma fatura (os campos, o seu significado, quais são obrigatórios e as regras de negócio entre eles) e associa-o a duas sintaxes XML, UBL 2.1 e UN/CEFACT CII.

A XRechnung é a especificação alemã assente na EN 16931, mantida pela KoSIT: XML puro, em qualquer das duas sintaxes, exigido pelas entidades públicas e igualmente válido entre empresas. Segundo a página da XRechnung da KoSIT, a versão 3.0 está em vigor desde 1 de fevereiro de 2024 e mantém-se pelo menos até 31 de julho de 2027. Uma versão preliminar da 4.0 foi publicada em setembro de 2026, com a versão final prevista para a primavera de 2027. Vai arrancar com a 3.0 e atualizar no primeiro ano.

O ZUGFeRD é um formato híbrido: um ficheiro PDF/A-3 com XML CII embebido. As pessoas leem o PDF; as máquinas leem o XML. Em França, o mesmo formato chama-se Factur-X, e os dois são tecnicamente idênticos. A FeRD publicou a versão 2.5.2 a 4 de agosto de 2026. O ZUGFeRD existe em perfis (MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED), e as perguntas frequentes do ministério aceitam o ZUGFeRD a partir da versão 2.0.1 «mit Ausnahme der Profile MINIMUM und BASIC-WL», isto é, com exceção dos perfis MINIMUM e BASIC-WL.

Numa fatura híbrida, o que conta é o XML. As perguntas frequentes chamam à parte estruturada o «führender Teil», a parte principal. Se o PDF e o XML não coincidirem, o PDF é que está errado.

Para a maioria dos emitentes B2B alemães, a opção sensata por defeito é o ZUGFeRD no perfil EN 16931, para que os clientes que ainda leem as faturas a olho possam continuar a fazê-lo, mais a XRechnung para as entidades públicas e para quem a pedir. Ambos devem sair de um único objeto interno de fatura, e não de dois caminhos de código.

O que tem de mudar no seu sistema

A fatura passa a ser dados, não um layout

Muitos sistemas antigos constroem a fatura no momento da impressão: texto concatenado num modelo, totais somados dentro do relatório, a menção do IVA como um parágrafo escrito no código. Nada disso sobrevive à EN 16931. Precisa de um objeto de fatura guardado, com todos os campos, a partir do qual se geram tanto o XML como o PDF.

Os campos que costumam faltar ou estar errados:

• Dados das partes. Moradas estruturadas com códigos de país ISO e um número de IVA ou número fiscal. Os blocos de morada em texto livre têm de ser divididos.
• Data da operação ou período do serviço, guardada como dado e não como uma frase no cabeçalho.
• Unidades. Cada quantidade precisa de um código da Recomendação n.º 20 da UN/ECE (H87 para peça, KGM para quilograma, DAY para dia). «Stk.» e «pauschal» têm de ser mapeados.
• IVA. Cada linha leva uma categoria e uma taxa de IVA. A fatura leva um quadro-resumo do IVA por cada combinação de categoria e taxa, e os totais têm de bater certo ao cêntimo, com duas casas decimais. Os sistemas que arredondam o IVA linha a linha falham aqui.
• Menções de isenção e de autoliquidação. A frase no fundo do PDF passa a ser um código de categoria de IVA mais um motivo de isenção.
• Pagamento. Meio de pagamento, IBAN e condições em forma estruturada.
• Referências. O número da encomenda ou a referência do comprador que os serviços de contas a pagar do seu cliente usam para conferir. Se nunca a guardou, comece a recolhê-la já.

As linhas só com texto («entrega conforme acordado») são um tropeço frequente. Numa fatura estruturada, uma linha é uma linha faturável, por isso esse texto pertence a uma nota.

Retificações, notas de crédito e autofaturação

As perguntas frequentes são explícitas: quando se aplica a obrigação da fatura eletrónica, uma retificação também tem de ser uma fatura eletrónica, com o tipo de fatura próprio das retificações. Na EN 16931, remete para a fatura anterior através do número e da data de emissão, por isso o seu sistema tem de guardar essa ligação como dado.

Atenção ao vocabulário. No direito alemão do IVA, uma «Gutschrift» é uma autofatura, emitida pelo cliente mediante acordo prévio (§ 14 Abs. 2 UStG). Aquilo a que em português se chama nota de crédito (uma redução de preço ou uma anulação) é, para a lei alemã, uma retificação. Muitos sistemas usam um único tipo de documento para as duas coisas. Separe-as antes de as mapear e, se faz autofaturação aos seus fornecedores, trate esses documentos como faturas emitidas pelo seu sistema.

Uma fatura final pode listar os pagamentos parciais anteriores num anexo, desde que a parte estruturada o refira; as perguntas frequentes confirmam que isto continua depois de 2027.

Validação antes de qualquer envio

A KoSIT publica um validador open source que verifica o XML face aos esquemas e às regras Schematron, com uma configuração pública para a XRechnung. Corre na linha de comandos, como daemon HTTP ou como biblioteca. Coloque-o no circuito de envio: todas as faturas são validadas antes de sair, e uma falha vai parar a uma fila com um responsável identificado, indicando que campo violou que regra.

No ZUGFeRD, valide o XML embebido face às regras do seu perfil, verifique em separado o contentor PDF/A-3 e confirme que o PDF mostra os mesmos totais que o XML.

Transmissão

A lei, dizem as perguntas frequentes, «sieht keinen bestimmten Weg vor»: não impõe nenhum canal. O e-mail com o ficheiro em anexo serve. Também serve uma API, um portal de descarga, um armazenamento partilhado dentro de um grupo ou (o exemplo do próprio ministério) uma pen USB. O Peppol não é obrigatório no B2B nacional alemão.

O trabalho de engenharia é por cliente: um endereço de faturação, um formato preferido e um registo do que foi enviado para onde. Uma nova tentativa depois de um envio falhado leva o mesmo documento com o mesmo número de fatura. Dois números para a mesma operação é um problema fiscal, não um problema de software.

Arquivo

Pelo menos a parte estruturada tem de ser guardada «unversehrt in seiner ursprünglichen Form», intacta na sua forma original, e o § 14b UStG fixa a conservação em oito anos a contar do fim do ano de emissão. Guarde exatamente os bytes que enviou, com um hash. Não conte em regenerar as faturas mais tarde a partir da base de dados: nessa altura, os dados e o código já terão mudado. O mesmo se aplica às faturas eletrónicas que recebe.

Um plano para outubro a dezembro de 2026

Treze semanas chegam para um desenvolvimento focado, se os dados de origem estiverem num estado razoável. Não chegam para substituir o sistema de faturação.

Semanas 1 e 2: levantamento e decisões. Liste todos os sítios onde se produz uma fatura, incluindo as notas de crédito manuais, as faturas finais de projetos e a folha de cálculo daquele cliente grande. Compare o volume de negócios de 2026 com o limiar. Escolha o formato por defeito e decida se constrói o gerador ou se envia os dados das faturas para a API de um fornecedor de faturação eletrónica.

Semanas 2 a 4: análise das lacunas nos dados. Mapeie três meses de faturas reais, campo a campo, para a EN 16931. Assinale o que falta, o que tem de passar a ser um código e o que é calculado de forma diferente. É aqui que se vê o verdadeiro tamanho do projeto.

Semanas 4 a 9: desenvolvimento. O objeto de fatura, o mapeamento, a geração do XML e do PDF/A-3, o validador no circuito de envio, a fila de falhas e o arquivo. Em paralelo, alguém limpa os dados mestre e recolhe junto dos clientes os endereços de faturação.

Semanas 9 a 11: reprocessamento e piloto. Faça passar os últimos três meses de faturas pelo novo gerador e valide-as todas. Depois, faça um piloto com alguns clientes disponíveis e pergunte-lhes se os seus sistemas leem os ficheiros.

Semanas 11 a 13: congelamento e manual de operação. Congele as alterações em dezembro. Deixe por escrito quem é responsável pela fila de falhas, como se emite uma retificação e o que acontece quando um cliente recusa uma fatura. As faturas de janeiro pelo trabalho de dezembro já estão abrangidas.

Janeiro de 2027. Arranque, e acompanhe a fila todos os dias até ao primeiro fecho do mês e à primeira declaração de IVA.

Ao longo de 2027. Planeie a atualização para a XRechnung 4.0 antes de a 3.0 deixar de ser válida e passe para o novo formato as empresas do grupo abaixo do limiar antes de 1 de janeiro de 2028.

Se começar tarde, corte na automação, não na validade do que sai: automatize primeiro os tipos de fatura de grande volume e envie os documentos raros à mão, através de uma ferramenta de faturação eletrónica, durante algumas semanas.

Onde obter ajuda

Construímos a ligação entre o sistema que produz as suas faturas e o formato que a lei exige: alterações ao modelo de dados, mapeamento, validação, transmissão e arquivo, no seu código e ao lado da sua equipa. O nosso serviço de integração de faturação eletrónica descreve como correm esses projetos; se a obrigação chegar a meio de uma mudança de ERP, veja a modernização de ERP. O calendário mais geral está no nosso guia de conformidade digital na UE em 2026.

Somos engenheiros, não consultores fiscais: as questões de âmbito ficam com o seu Steuerberater, e nós construímos de acordo com a resposta dele. Diga-nos o que produz hoje as suas faturas e quantas saem, mais ou menos, por mês: escreva para office@c9group.dev.