PDF/A-3B e ZUGFeRD: o meu PDF de fatura eletrónica é realmente conforme? (veraPDF)

O ZUGFeRD é uma fatura híbrida: um PDF legível para pessoas mais o XML legível por máquina no seu interior. A parte PDF tem de ser, para o efeito, uma variante de arquivo especial – PDF/A-3. É exatamente aqui que surgem a maioria dos mal-entendidos.

> Resposta rápida: Para que um PDF seja realmente PDF/A-3(-B), têm de estar, entre outros, todos os tipos de letra incorporados, presente um OutputIntent/perfil de cor ICC e os metadados PDF/A adequados. Um validador como o veraPDF verifica isso, mas não repara nada. Se o PDF de origem não for conforme (por exemplo, tipos de letra não incorporados), só ajuda uma verdadeira conversão – ou usa uma XRechnung pura.

O que exige o PDF/A-3

O PDF/A foi concebido para que um documento seja apresentado de forma idêntica em qualquer computador e daqui a muitos anos. Para isso aplicam-se regras rigorosas; as mais importantes:

1. Todos os tipos de letra incorporados – o ficheiro tem de conter os próprios dados dos tipos de letra e não pode confiar em que o leitor tenha, por exemplo, o Arial instalado.
2. OutputIntent / perfil de cor ICC – o ficheiro tem de definir como as cores são reproduzidas.
3. Metadados PDF/A-XMP – a identificação como PDF/A-3.

O obstáculo frequente: tipos de letra não incorporados

Sistemas de gestão de mercadorias e de faturação mais antigos geram frequentemente PDFs que remetem para tipos de letra do sistema, como Arial ou Arial Bold, mas não os incorporam. Um ficheiro desses já não é conforme com PDF/A – e isso não se sana apenas acrescentando o XML do ZUGFeRD e os metadados PDF/A.

Validar não é converter

Um ponto importante: o veraPDF apenas valida, não converte. Um validador assinala «não conforme», mas não transforma um ficheiro não conforme num ficheiro conforme. Para gerar realmente PDF/A-3 é necessário um verdadeiro passo de conversão que incorpore os tipos de letra e acrescente um perfil de cor (por exemplo, com o Ghostscript ou a biblioteca de referência do ZUGFeRD Mustangproject).

O que está sempre correto: o XML

Independentemente do contentor PDF, a parte decisiva e juridicamente relevante é o XML estruturado. No TaxLayer, este é integralmente validado face ao padrão de verificação KoSIT e à EN 16931 (0 erros). Os próprios dados da fatura estão, assim, corretos e conformes – a questão do PDF/A diz respeito apenas ao invólucro exterior.

Como chegar ao objetivo com segurança

• Variante A – exportar PDF/A a partir do sistema: Se o seu sistema de gestão de mercadorias conseguir exportar a fatura como PDF/A (com tipos de letra incorporados), o ficheiro ZUGFeRD daí gerado é conforme.
• Variante B – usar XRechnung pura: Na XRechnung (XML puro) não existe de todo o contentor PDF; a questão da conformidade PDF/A nem se coloca.

Conclusão

O PDF/A-3 é mais do que uma etiqueta: exige tipos de letra incorporados, um perfil de cor e os metadados corretos. Quem parte de um sistema mais antigo faz melhor em exportar diretamente PDF/A – ou aposta na XRechnung, onde o contentor PDF não desempenha qualquer papel.

---

O XML da fatura eletrónica no TaxLayer está sempre validado segundo a EN 16931 e o KoSIT. Questões sobre a conformidade PDF/A? Escreva para info@landauer.de.