Validar faturas eletrônicas: compreender ZUGFeRD, XRechnung, Peppol e EN 16931

Sexta-feira, 15h40: o recebimento de faturas está parado. Não completamente – mas o bastante para causar transtornos. Parte das faturas eletrônicas recebidas passa sem problemas, outra parte fica retida no fluxo de importação. A área de negócio diz: „No PDF tudo parece correto.“ A TI vê no log: „Perfil não permitido“ e „Regra de negócio violada“. A partir daí fica político: compras quer maior capacidade de processamento, a contabilidade quer segurança, e a TI não quer lógica especial por fornecedor.

Quem, nessa situação, deve verificar faturas eletrônicas percebe rapidamente: ZUGFeRD, XRechnung, Peppol e EN 16931 não são meras questões semânticas, mas sim uma ponderação. Dependendo do grau de rigor das verificações, mudam o esforço e o risco – e com isso também decisões de arquitetura (serviço de verificação central vs. plugin no ERP), questões operacionais (monitoramento, atualizações, fallback) e questões de rollout (grupos-piloto, comunicação com fornecedores, classes de erro).

Dois objetivos que, no cotidiano, puxam em direções opostas

Objetivo 1: Automação com alto volume de processamento. Muitas empresas querem estruturar o recebimento de faturas de modo que faturas estruturadas sejam integradas no ERP, no workflow e no arquivo sem rupturas de mídia. Isso reduz a captura manual e acelera aprovações – mas apenas se os dados forem confiáveis.

Objetivo 2: Segurança de verificação com comprovação rastreável. Ao mesmo tempo, deve ser possível demonstrar, em caso de dúvida, por que uma fatura foi aceita ou rejeitada: qual perfil, qual regra, qual versão. Isso torna-se relevante, no mínimo, quando fornecedores reclamam („vocês rejeitaram, mas com outros passou“) ou quando controles internos exigem uma cadeia documental íntegra.

Ambos os objetivos são legítimos. O conflito surge porque cada verificação adicional reduz riscos, mas também pode gerar mais casos especiais. Isso é especialmente válido quando fornecedores enviam perfis diferentes ou quando uma mudança de versão na especificação ainda não chegou a todos os pontos.

EN 16931: Por que gerir semântica em vez de „formato de ficheiro“ ao validar

EN 16931 é frequentemente referido no dia a dia dos projetos como „o formato XML“. Uma visão mais útil na prática é outra: EN 16931 é o modelo de dados semântico para os elementos centrais de uma fatura eletrónica — ou seja, o significado dos campos de dados e as regras de negócio (Business Rules) associadas para conformidade. A Comissão Europeia enquadra EN 16931 exatamente assim: como um modelo de dados semântico dos elementos centrais incluindo regras de conformidade.^[Fonte]

A consequência prática para TI e operação: „XML bem formado“ é apenas a porta de entrada. O decisivo é saber se uma fatura é consistente em termos de significado (lógica das somas, informações fiscais, campos obrigatórios, códigos). E se ela está no perfil correto — porque os perfis definem quais partes do padrão se aplicam e em que forma.

Também é importante que normas não sejam estáticas. Em catálogos de normas já consta uma edição atualizada como EN 16931‑1:2026.^[Fonte] Isso não significa que deve migrar imediatamente. Significa, porém: seu modelo de verificação e operação deve ser construído de modo que conjuntos de regras e validadores possam ser versionados e atualizados de forma controlada — sem que todo o processamento fique „no limite“ a cada atualização.

ZUGFeRD e XRechnung: Dois caminhos para concretizar a mesma obrigação

Na Alemanha, em muitas empresas, coexistem duas formas comuns:

• ZUGFeRD como formato híbrido: um ficheiro PDF/A‑3 que contém incorporados dados estruturados da fatura (XML). O FeRD descreve explicitamente o ZUGFeRD 2.2 como um modelo híbrido: documento legível mais XML legível por máquina dentro de um PDF/A‑3.^[Fonte]
• XRechnung como formato puramente estruturado: o foco está completamente nos dados processáveis por máquina, sem que um PDF venha incorporado.

A escolha é menos ideológica e mais operacional: o ZUGFeRD costuma ser mais aceito pelas áreas de negócio, porque existe um comprovante legível. Ao mesmo tempo, o PDF não pode servir de pretexto para negligenciar a validação do XML. A XRechnung é claramente orientada a dados e, portanto, adequada à automação, mas exige na prática quase sempre uma boa ferramenta de visualização e de verificação que apresente o conteúdo de forma compreensível.

Quadro legal: O que conta como „fatura eletrónica“ a partir de 2025

Para o planejamento de projeto, uma afirmação é particularmente eficaz: no contexto do imposto sobre o valor acrescentado, a partir de 01.01.2025 existirão faturas eletrônicas apenas se forem emitidas/transferidas/recebidas num formato eletrônico estruturado que permita o processamento eletrônico.^[Fonte] Um PDF puro sem dados estruturados, portanto, não entra na definição relevante aqui.

O BMF menciona também XRechnung e ZUGFeRD a partir da versão 2.0.1 (com exceções de perfil) como formatos que, em princípio, cumprem os requisitos de IVA.^[Fonte] Operativamente, isso não é uma „questão de religião do formato“, mas uma obrigação clara: Você deve reconhecer, verificar e documentar de forma auditável o perfil e a versão. Caso contrário, não é possível um gate confiável nem uma comprovação clara do porquê uma fatura foi tratada dessa forma.

Classificar corretamente o Peppol: transporte e interoperabilidade em vez de „mais um formato“

O Peppol é frequentemente tratado no dia a dia como outro formato de fatura. Isso leva a expectativas erradas. O Peppol é, antes de mais nada, um quadro de transporte e interoperabilidade para documentos comerciais estruturados. Para faturas, o Peppol BIS Billing 3.0 é o componente relevante.

Na documentação oficial do BIS Billing, a conformidade EN‑16931 é visível através do CustomizationID-Schema (ou seja, por meio de um identificador que descreve o perfil/o contexto de „Customization“). Isso é importante porque mostra: no universo Peppol, identificadores de perfil e conformidade são parte da análise automatizada e não apenas „nice to have“.^[Fonte]

O que disso decorre em operação é muito concreto: além da verificação do documento, surgem questões de transporte. Endereçamento, IDs de participantes, rejeições técnicas, comprovantes de entrega – tudo isso gera padrões de erro próprios. Se você não classificar esses erros separadamente, no fim tudo acaba chegando como „fatura quebrada“ ao Financeiro ou como „Peppol está com problemas“ à TI.

Leitweg-ID & Peppol-ID: Por que identificadores são críticos em produção

O guia para utilização do canal de entrada Peppol para a administração federal descreve, por exemplo, a formação da Peppol-ID a partir do prefixo 0204 e da Leitweg-ID para os órgãos federais conectados, e localiza a Peppol Authority Deutschland na KoSIT.^[Fonte] Esse é um contexto específico (Bund). A lição transferível para empresas é, no entanto, clara: identificadores não são um tema marginal. Eles pertencem a runbooks, casos de teste e configuração – porque „ID errada“ em produção bloqueia tanto quanto „perfil incorreto“.

Mapa de ponderação: estratégia de verificação segundo benefício, esforço e risco

Uma estratégia prática separa as verificações em níveis. Você decide conscientemente qual nível atuará como um gate rígido (rejeição) e qual nível apenas gerará um aviso (esclarecimento). O mapa seguinte ajuda a comparar opções típicas.

Verificação de e-faturas: um fluxo de validação que se mantém em operação

Se você formular o processo de verificação de forma que possa ser encontrado em logs, runbooks e sistemas de tickets, a perda por atrito posterior diminui. O caminho a seguir é deliberadamente „orientado à operação“ e independente de o recebimento ocorrer por e-mail, upload, API ou Peppol.

1. Registrar entrada: canal, carimbo de data/hora, IDs do remetente/recipiente, metadados técnicos. Essa é sua trilha de auditoria.
2. Detectar contêiner: XML puro? ZUGFeRD (PDF/A‑3 com XML embutido)? Outro? Em híbrido: extrair o XML e tratá‑lo como objeto de verificação separado.
3. Determinar perfil e versão: Qual variação está presente (ex.: perfil EN‑16931, versão XRechnung, Peppol BIS Billing com CustomizationID)? Sem essa informação, sua verificação fica sem base.
4. Validação de estrutura: verificação de esquema/perfil com versão do validador e estado do conjunto de regras registrados. O resultado deve ser reproduzível.
5. Regras semânticas: avaliar EN‑16931 Business Rules e verificações de consistência (somas/impostos/lógica obrigatória).
6. Regras de negócio internas: conferência de dados mestres, referência de pedido, verificação de duplicatas, regras de aprovação, requisitos de contabilização. Essas regras são específicas da empresa e costumam mudar com mais frequência que os padrões.
7. Controlar o resultado: encaminhar/contabilizar automaticamente, abrir para esclarecimento ou rejeitar – incluindo classe de erro, breve justificativa e referência ao log de verificação.

O limite desse caminho: ele não responde automaticamente qual regra deve ser “rígida” na sua organização. Isso é uma decisão de gestão entre rendimento do processo e risco — e deve ser documentada para que alterações possam ser rastreadas posteriormente.

Consequências de arquitetura: serviço central de validação ou validação no sistema de destino?

No projeto surge frequentemente uma questão aparentemente pequena: “Onde validamos?” Na prática, ela decide sobre manutenibilidade e custos operacionais.

Validação centralizada (serviço ou plataforma de integração)

A validação opera como um serviço central: regras uniformes, classes de erro uniformes, um lugar único para atualizações. Isso facilita o monitoramento (p.ex. taxa de rejeição por fornecedor/perfil) e simplifica auditorias, porque os resultados de verificação são armazenados de forma consistente.

O preço: você passa a operar um componente adicional. Alta disponibilidade, janelas de manutenção, versionamento e rollback para atualizações de regras tornam-se obrigatórios. Em troca, você ganha controle.

Validação descentralizada (ERP/DMS-Plugins, clientes)

Aqui a validação ocorre em vários sistemas. Isso pode parecer atraente a curto prazo (“o ERP já consegue fazer isso”), mas frequentemente leva à deriva: diferentes versões do validador, diferentes mensagens de erro, diferentes exceções. E isso é fatal para padronização e suporte.

Para a direção de TI, uma regra prática ajuda: se vários canais de entrada e vários sistemas-alvo estão em jogo, um serviço de verificação central costuma ser a decisão de longo prazo mais robusta. Se existir apenas um caminho claro (um ERP, uma entrada), a validação descentralizada pode ser aceitável — mas, mesmo assim, o versionamento deve ser bem definido.

O que realmente consome tempo em projetos ao validar

Tecnicamente, a leitura de XML raramente é o problema. Tempo e risco surgem nos pontos de contato:

• Diversidade de perfis e versões: Sem transparência sobre quais parceiros enviam quais perfis, cada release se transforma em voo às cegas. Telemetria (perfil/versão por entrada) portanto não é luxo, mas um instrumento de controle.

Rollout ohne Prozessbruch: Wellen, Fallback und messbare Kriterien

Um Rollout estável acontece quando não ativa tudo ao mesmo tempo. Uma lógica em ondas mostrou-se eficaz:

• Piloto: poucos fornecedores e tipos de documento, registo muito detalhado, revisão diária das classes de erro mais frequentes.
• Estabilização: aperfeiçoar regras, mas com janelas de mudança e comunicação clara. Erros-padrão recorrentes devem ser esclarecidos de forma direcionada com compras/fornecedores.
• Escalonamento: transferir o monitoramento para a operação regular (taxa de rejeição, duração de esclarecimentos, principais violações de regras, percentagem de processamento manual).

Planeje também o modo de contingência. Se uma atualização de regras bloquear repentinamente muitas faturas, precisa de um fallback controlado (p.ex. modo de aviso temporário em vez de rejeição rígida) – com decisão documentada e posterior reavaliação. Isso não é um „suavizador“, mas um freio operacional contra paralisações descontroladas.

Três equívocos típicos que deve dissipar cedo

1) „ZUGFeRD é, como antigamente, um PDF.“ No processo, o que conta é o XML incorporado. O PDF é útil para pessoas, mas não substitui a validação automática. Se PDF e XML divergem, deve ficar claro qual fonte prevalece no processo.

2) „Peppol torna automaticamente tudo conforme.“ O Peppol auxilia na troca e na interoperabilidade. A conformidade só surge a partir de conteúdos corretos e perfis adequados. A entrega não equivale à validação.

3) „Se o validador estiver verde, pode ser contabilizado.“ Conformidade com o padrão é uma base, não uma autorização completa do processo. Regras internas (obrigatoriedade de pedido, recepção de mercadorias, limites de autorização) permanecem e devem ser geridas como uma etapa separada, em vez de serem misturadas na lógica do validador.

Ponto final: Uma boa verificação alivia – quando é construída como processo operacional

Verificar faturas eletrónicas não é um fim em si. O valor surge quando a validação é concebida como um sistema operacional: versionado, observável, com classes de erro claras e um canal de retorno que não termina num engarrafamento de tickets. Assim, normas como EN 16931, perfis como XRechnung/ZUGFeRD e vias de transporte como Peppol deixam de ser um canteiro permanente e passam a ser blocos controláveis na sua cadeia de processos.

Para este tema também são importantes o Zugferd Prüfen e o Xrechnung Validieren. O artigo contextualiza esses aspetos de forma compreensível e mostra no que é preciso incidir na prática diária.

Discutir um projeto ou uma iniciativa de modernização com Net-Base.