XRechnung, ZUGFeRD e BIS Billing 3.0: que formatos de fatura eletrónica o seu software deve suportar

A EN 16931 descreve um modelo de dados semântico. Define que dados uma fatura contém e como se relacionam entre si, por exemplo o número da fatura como BT-1 ou a referência do comprador como BT-10. A norma em si não é um formato de ficheiro.

Para a representação técnica, admite duas sintaxes: UBL e UN/CEFACT CII. Ambas representam o mesmo modelo semântico, mas diferem nos nomes dos elementos e na estrutura. Um software que só lê UBL não consegue processar automaticamente uma fatura CII, mesmo que esta seja conforme à norma.

Para a implementação, isto determina o esforço de manutenção. Dois mapeamentos paralelos significam que cada alteração de regras tem de ser aplicada em dois locais. Quem, em vez disso, mapeia uma única vez para o modelo semântico da norma e gera a partir dele ambas as sintaxes, mexe apenas num local por alteração.

Na receção, o ficheiro recebido é, inversamente, mapeado primeiro para o modelo semântico e, a partir daí, transferido para o seu modelo de dados.

Acima da norma estão as variantes nacionais e específicas de rede, designadas na norma Core Invoice Usage Specification, abreviadamente CIUS. Uma CIUS restringe a norma. Torna obrigatórios campos opcionais, exclui outros e traz regras Schematron próprias. As variantes que vão além do âmbito da norma chamam-se Extension.

Independentemente da sintaxe e da variante, uma fatura eletrónica existe ou como ficheiro XML puro ou como PDF/A-3 com ficheiro XML incorporado. Para o segundo caso, consagrou-se a expressão formato híbrido.

A XRechnung é uma CIUS da EN 16931 e é mantida pelo Centro de Coordenação de Normas Informáticas (Koordinierungsstelle für IT-Standards), abreviadamente KoSIT. Existe em ambas as sintaxes. Não tem componente visual; o ficheiro é XML puro.

A XRechnung é obrigatória para as faturas dirigidas à administração federal alemã. A fatura é endereçada através do Leitweg-ID, indicado no registo de dados como referência do comprador.

O canal de entrega depende do destinatário. Entram em consideração os portais ZRE e OZG-RE ou um Peppol Access Point. No B2B, o Leitweg-ID não desempenha qualquer papel. Aí, a XRechnung é apenas um de vários perfis admitidos.

Atualmente aplica-se a versão 3.0.2. Para a XRechnung 4.0, a implementação da EN 16931 na versão de 2026, já existe uma versão preliminar. A versão final da XRechnung 4.0 deverá ser publicada na primavera de 2027.

O ZUGFeRD empacota um ficheiro XML segundo CII num PDF/A-3. As pessoas veem o PDF, enquanto o software lê o XML.

A especificação prevê vários perfis com diferente volume de dados, de MINIMUM a EXTENDED.

MINIMUM e BASIC WL não contêm uma fatura completa e não cumprem a norma. A partir do perfil EN 16931, designado COMFORT em versões mais antigas, a parte estruturada é conforme à norma. O seu software deve ler o perfil na importação e tratar separadamente os ficheiros com MINIMUM ou BASIC WL, por exemplo através de uma verificação manual.

O Factur-X é tecnicamente quase idêntico ao ZUGFeRD.

O ZUGFeRD faz sobretudo sentido quando os seus clientes faturam a destinatários que continuam a verificar as faturas visualmente. Neste caso, apenas o XML incorporado é juridicamente determinante. Se o PDF e o XML divergirem, prevalecem, segundo a circular do Ministério Federal das Finanças (BMF-Schreiben) de 15 de outubro de 2025, os dados da parte estruturada.

Um processo de aprovação que verifique apenas o PDF pode, por isso, aprovar uma fatura cujo conteúdo determinante é diferente.

No envio, o seu software deve gerar o PDF e o XML a partir do mesmo registo de dados, para que não divirjam. Na receção, deve construir para a verificação uma visualização própria a partir do XML, em vez de mostrar o PDF fornecido. O Ministério Federal das Finanças da Alemanha recomenda igualmente visualizar a própria parte XML.

O Peppol BIS Billing 3.0 é também uma CIUS da EN 16931, fixada em UBL 2.1. A OpenPeppol especificou-o como formato próprio para a troca de faturas e notas de crédito através da rede.

Para além das regras da norma, traz regras Schematron próprias. Um ficheiro pode passar na verificação face à EN 16931 e falhar numa regra Peppol. Frequentemente trata-se de listas de códigos ou de campos que a rede define de forma mais restrita do que a norma.

A especificação é desenvolvida de forma versionada. Quem valida internamente deve verificar se os seus conjuntos de regras correspondem ao estado atual.

A longo prazo, o Peppol evolui na direção do PINT, uma base harmonizada a nível internacional para perfis de fatura fora da Europa. Para a implementação na Alemanha, isto não altera nada de momento.

Para estas faturas, o seu software tem de conseguir gerar XRechnung. O Leitweg-ID do destinatário faz parte do registo de dados da fatura como campo obrigatório e é indicado na XRechnung como referência do comprador (BT-10). Se faltar ou estiver no campo errado, o portal de receção rejeita a fatura.

A lei exige uma fatura segundo a EN 16931 e deixa o formato em aberto. São admitidos XRechnung, ZUGFeRD a partir do perfil EN 16931 e também Peppol BIS Billing. O XML incorporado continua a ser juridicamente determinante. Se o PDF e o XML divergirem, o destinatário pode estar a verificar dados diferentes dos que são juridicamente válidos.

Desde 1 de janeiro de 2025, as empresas nacionais têm de conseguir receber faturas eletrónicas segundo a EN 16931. Para uma fatura eletrónica conforme à norma, o remetente não precisa, por isso, do consentimento do destinatário, mesmo que este prefira um determinado formato.

Ambas as partes só têm de acordar o canal de transmissão e os formatos fora da norma. Na prática, o canal acordado pertence, por isso, aos dados mestre de cada parceiro de negócio.

Para além do Peppol BIS Billing 3.0, é possível transmitir através da rede Peppol também XRechnung e, desde março de 2025, ZUGFeRD como ficheiro híbrido. Os tipos de documentos que um destinatário registou no serviço de diretório mostram que formatos aceita. Antes do envio, o seu software tem de consultar este registo e escolher o formato adequado. Para verificações pontuais, a Pesquisa de ID Peppol mostra-o sem registo.

Em funcionamento corrente, o seu software deve efetuar esta consulta automaticamente antes do envio, diretamente através dos serviços de diretório SML e SMP ou através da API do seu Peppol Access Point. Com base nisso, é determinado um formato suportado por ambas as partes e a fatura eletrónica é então gerada nesse formato.

As faturas recebidas chegam no formato escolhido pelo remetente. O seu software deve, por isso, conseguir ler ambas as sintaxes, UBL e CII, e assim também a XRechnung nas duas variantes. A isto juntam-se o ZUGFeRD e o Factur-X como ficheiros híbridos e, logo que os seus clientes recebam faturas do estrangeiro, os perfis aí habituais.

Cada ficheiro recebido contém um identificador da variante que utiliza. Em UBL está no elemento cbc:CustomizationID, em CII no parâmetro de contexto da diretriz. O seu software deve ler primeiro este identificador, porque dele depende que regras de validação se aplicam e como o ficheiro é transferido para o seu modelo de dados.

Alguns Peppol Access Points assumem este passo por si. Verificam o ficheiro recebido, extraem os dados da fatura e entregam-nos juntamente com o ficheiro original como registo de dados uniforme.

O seu software deve cobrir completamente a receção antes do envio, ou seja, ambas as sintaxes e os formatos híbridos, porque os seus clientes já hoje têm de conseguir receber faturas eletrónicas.

O envio torna-se obrigatório para os seus clientes em duas fases. A partir de 1 de janeiro de 2027, com um volume de negócios total superior a 800 000 euros no ano anterior, e a partir de 1 de janeiro de 2028 para todas as restantes operações B2B nacionais.

Quem começa pela sintaxe CII pode gerar com ela a XRechnung na variante CII e o ZUGFeRD. O UBL torna-se necessário logo que destinatários na rede Peppol esperem Peppol BIS Billing 3.0, porque este formato pressupõe UBL.

Todos os dados obrigatórios para efeitos de IVA têm de constar da parte estruturada da fatura eletrónica, de forma processável por máquina. Isto inclui também a descrição do serviço. Uma remissão para um anexo, uma guia de remessa ou um link não substitui um campo obrigatório. A base são as FAQ do Ministério Federal das Finanças da Alemanha sobre a fatura eletrónica e a circular do Ministério Federal das Finanças (BMF-Schreiben) de 15 de outubro de 2025.

A razão está na estrutura da fatura eletrónica. Nos formatos híbridos como o ZUGFeRD, os dados no XML são os determinantes e o PDF é apenas uma visualização. Um dado que só seja visível no PDF não conta, por isso.

Se faltar um dado obrigatório na parte estruturada, a fatura é considerada irregular e a dedução do IVA pelo destinatário pode ficar em risco. Os seus clientes dão por isso, o mais tardar, quando os parceiros de negócio devolvem faturas por esse motivo.

Muitos modelos de fatura transportam dados obrigatórios como blocos de texto que só aparecem no PDF. Frequentemente, isto diz respeito à descrição do serviço, por exemplo “de acordo com a proposta 2026-114”, ao período de prestação no rodapé da fatura e à menção da autoliquidação pelo destinatário do serviço.

No modelo de dados, cada um destes dados deve ter um campo próprio a partir do qual o XML é preenchido. O período de prestação pertence aos campos do período de faturação (BG-14) e a menção de autoliquidação (reverse charge) à categoria de imposto com motivo de isenção (BT-120 e BT-121).

A validação técnica verifica se os campos obrigatórios da norma estão presentes e formalmente bem preenchidos. Não deteta se uma descrição do serviço é suficiente para efeitos de IVA. Uma fatura pode, portanto, passar na verificação e, ainda assim, conter um dado obrigatório de forma insuficiente.

Guias de remessa, registos de horas e outros documentos de suporte à fatura podem ser incorporados como anexo na fatura eletrónica, na EN 16931 através do grupo dos documentos de suporte adicionais (BG-24). Isto substitui o envio separado e mantém a fatura e o comprovativo num único ficheiro.

Uma XRechnung é verificada face a dois conjuntos de regras, as regras da EN 16931 e as regras adicionais da KoSIT. Para o Peppol BIS Billing 3.0 aplica-se o mesmo com as regras da OpenPeppol. Uma verificação apenas face à norma diz, por isso, pouco sobre se o destinatário aceita o ficheiro. O seu software deve verificar face ao conjunto de regras da variante que o destinatário espera.

A KoSIT e a OpenPeppol publicam regularmente novas versões dos seus conjuntos de regras com listas de códigos e regras Schematron ajustadas. Se o seu software não mantiver os conjuntos de regras atualizados, podem ser rejeitadas faturas que até agora eram aceites. A rejeição vem então do destinatário, mas a causa está no próprio conjunto de regras desatualizado.

Para testes durante o desenvolvimento, é possível verificar ficheiros individuais face à EN 16931 e às regras Peppol com o validador de faturas eletrónicas gratuito. Para a verificação automática em produção, o InvoiceRails oferece a validação também através de uma API, face à EN 16931 e a perfis como XRechnung, ZUGFeRD e Peppol BIS Billing. O relatório de validação apresenta separadamente erros, avisos e notas.

Um mapeamento é construído uma vez; as regras de validação por trás dele podem mudar várias vezes por ano. A próxima grande transição já está à vista, com a XRechnung 4.0 e a EN 16931 na versão de 2026.

A versão de 2026 assenta no UBL 2.5. Em implementações conformes, o UBL 2.5 só pode ser utilizado depois de o CEN publicar um syntax binding atualizado. Até lá, aplicam-se os bindings existentes baseados em UBL 2.1. Os fornecedores podem, portanto, preparar a transição, mas ainda não implementá-la.

Quem constrói a ligação internamente assume esta manutenção de forma permanente. Isso inclui manter atualizados os mapeamentos para ambas as sintaxes, as listas de códigos e as regras Schematron e acompanhar os planos de versões da KoSIT, do FeRD, da OpenPeppol e do CEN. É exequível, mas consome tempo de desenvolvimento que faz falta ao próprio produto.

Em alternativa, a manutenção dos formatos pode ser externalizada para um Peppol Access Point. O InvoiceRails, o Access Point certificado pela OpenPeppol da fino data services, abrange através de uma API mais de 60 formatos, entre eles XRechnung, ZUGFeRD e Factur-X, e mantém continuamente atualizadas as regras de validação e os formatos.

Os fornecedores integram o envio e a receção uma única vez e disponibilizam a função a um número ilimitado dos seus clientes, se desejarem com marca própria. O mapeamento dos dados de faturação próprios para a interface continua a cargo do fornecedor, tal como os campos obrigatórios no seu próprio modelo de dados.

Como os fornecedores de software podem, em geral, integrar a faturação eletrónica no seu produto é explicado no artigo sobre faturação eletrónica para fornecedores de software.