XRechnung, ZUGFeRD e BIS Billing 3.0: que formatos de faturação 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 apenas lê UBL não consegue processar automaticamente uma fatura em CII, mesmo que esta esteja em conformidade com a norma.

Para a implementação, isto determina o esforço de manutenção. Dois mapeamentos paralelos significam que cada alteração das 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, só precisa de alterar um local a cada mudança.

Na receção, o ficheiro recebido é, no sentido inverso, 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 sob a forma de um ficheiro XML puro ou de um PDF/A-3 com um 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. Está disponível 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. São possíveis os portais ZRE e OZG-RE ou um Peppol Access Point. No B2B, o Leitweg-ID não desempenha qualquer papel. Nesse contexto, 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 a sintaxe CII num PDF/A-3. As pessoas veem o PDF, enquanto o software lê o XML.

A especificação prevê vários perfis com diferentes volumes 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 nas versões mais antigas, a parte estruturada está em conformidade com a norma. O seu software deve identificar o perfil na importação e tratar separadamente os ficheiros com os perfis 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 validaçã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 à versão atualmente em vigor.

A longo prazo, o Peppol evolui no sentido 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 incorreto, o portal de receção rejeita a fatura.

A lei exige uma fatura em conformidade com a EN 16931 e deixa o formato em aberto. São admitidos a XRechnung, o ZUGFeRD a partir do perfil EN 16931 e também o 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 daqueles que são juridicamente válidos.

Desde 1 de janeiro de 2025, as empresas nacionais têm de conseguir receber faturas eletrónicas em conformidade com a EN 16931. Para uma fatura eletrónica em conformidade com a 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 que não estejam abrangidos pela 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 a XRechnung e, desde março de 2025, o ZUGFeRD como ficheiro híbrido. Os tipos de documento que um destinatário registou no serviço de diretório indicam quais os formatos que 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 esta informação sem necessidade de 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 formatos 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, encontra-se no elemento cbc:CustomizationID; em CII, no parâmetro de contexto da diretriz. O seu software deve ler primeiro este identificador, porque dele dependem as regras de validação que se aplicam e a forma 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, sob a forma de um registo de dados uniforme.

O seu software deve assegurar integralmente a receção antes do envio, ou seja, deve suportar ambas as sintaxes e os formatos híbridos, porque os seus clientes já 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, para empresas 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. A sintaxe UBL torna-se necessária logo que os destinatários na rede Peppol esperem o Peppol BIS Billing 3.0, porque este formato pressupõe a utilização de 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 anexos 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 validar o ficheiro de acordo com o 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 validar ficheiros individuais face à EN 16931 e às regras Peppol com o validador de faturas eletrónicas gratuito. Para a validação automática em produção, o InvoiceRails oferece também uma API que permite validar ficheiros 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 baseia-se 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, disponibiliza 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 de 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.