PDF/A é a versão arquivística do PDF: a promessa de que um documento será renderizado em 2050 da mesma forma que em 2026. Existem quatro perfis principais (PDF/A-1, 2, 3, 4), cada um com níveis de conformidade. Entre eles, PDF/A-3 é o perfil que sustenta a e-invoicing europeia, e o único perfil amplamente usado que permite anexos arbitrários dentro do wrapper de arquivo.

Se você lida com faturas, submissões regulatórias ou qualquer fluxo “PDF + dados estruturados”, PDF/A-3 é a especificação que aparece. Aqui está o que ele significa, como difere dos demais e como verificar a conformidade real.

A família PDF/A em uma tabela

Perfil	ISO part	Ano	Característica principal
PDF/A-1	19005-1	2005	Primeiro perfil de arquivo. Sem transparência, sem JavaScript, fontes embutidas.
PDF/A-2	19005-2	2011	Adiciona JPEG2000, transparência e camadas. Melhor fidelidade de impressão.
PDF/A-3	19005-3	2012	Adiciona anexos de arquivo embutidos. Wrapper de Factur-X / ZUGFeRD.
PDF/A-4	19005-4	2020	Revisão moderna; modelo de conformidade mais limpo, sem divisão `b` vs `a`.

Os subníveis:

b (basic): preserva fidelidade visual, sem garantia de estrutura semântica.
a (accessible): tagging estrutural e mapeamento Unicode para leitores de tela.
u (Unicode): mapeamento Unicode sem estrutura completa.
e / f (somente PDF/A-4): conteúdo 3D de engenharia e formulários completos.

“PDF/A-3b” significa: perfil de arquivo 3, com anexos permitidos, em nível básico. É a variante mais comum para faturamento.

O que torna o PDF/A-3 especial

PDF/A-1 e PDF/A-2 proíbem arquivos embutidos arbitrários. A lógica é simples: um PDF de arquivo precisa ser autocontido; se ele carrega data.xlsx, esse anexo pode envelhecer de forma diferente do PDF e quebrar a garantia arquivística.

PDF/A-3 relaxa essa regra sob uma condição estrita: cada arquivo embutido precisa declarar AFRelationship, dizendo como ele se relaciona com o conteúdo visível do PDF. Valores válidos: Source, Data, Alternative, Supplement, Unspecified. O PDF também deve listar o anexo no array /AF e emitir metadata XMP sobre o arquivo anexado.

Em outras palavras: PDF/A-3 permite anexos, mas exige que você declare exatamente o que eles são e como se conectam ao que o humano vê. Isso virou a base da e-invoicing: a fatura legível fica no PDF, o XML CII EN 16931 fica no anexo, e AFRelationship="Alternative" declara que ambos representam a mesma fatura.

Onde PDF/A-3 aparece em produção

Factur-X (França, B2B obrigatório a partir de 2026): PDF/A-3 + CII XML, com namespace XMP urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0#.
ZUGFeRD 2.x (Alemanha, recebimento obrigatório desde 2025): PDF/A-3 + CII XML, com namespace XMP urn:zugferd:pdfa:CrossIndustryDocument:invoice:2p0#.
Arquivo CAD de engenharia: PDF/A-3 com arquivo CAD nativo anexado. O PDF é a renderização; o CAD é a fonte.
Submissões regulatórias: PDF/A-3 com payloads XML anexados, como FDA submissions e relatórios ESEF de empresas listadas na UE.

Nesses casos, o wrapper não é só um contêiner. É um contrato: este PDF e este arquivo anexado são o mesmo documento, e ambos precisam validar.

Como verificar se um PDF/A-3 está conforme

O checker oficial é veraPDF (verapdf.org), mantido pela PDF Association. Ele implementa o conjunto de regras ISO 19005-3; se o veraPDF retorna “Pass — PDF/A-3b”, é o sinal mais forte que um único motor pode dar.

Mas um “Pass” de motor único não é padrão de auditoria (Why two PDF/A validators are better than one explica o motivo). O padrão auditável é rodar dois motores independentes e aceitar o arquivo apenas quando ambos passam.

Para e-invoice há uma segunda camada: Mustang (mustangproject.org), o checker de fato para Factur-X / ZUGFeRD. Ele valida o CII XML embutido contra EN 16931 Schematron. Conformidade PDF/A-3 sozinha não basta; o XML anexado também precisa ser EN 16931 válido, ou o sistema AP do recebedor rejeita a fatura.

Muitas equipes instalam Java, veraPDF CLI e Mustang, depois escrevem scripts para juntar os relatórios. Funciona, mas adiciona atrito.

validator roda os três no navegador:

veraPDF: referência oficial de conformidade PDF/A-3.
gPdf Rust+WASM edge engine: implementação independente, segunda opinião.
Mustang: EN 16931 CII XML Schematron para payloads de e-invoice embutidos.

Solte o arquivo, os três rodam em paralelo e os relatórios aparecem lado a lado. JSON para evidência de QA pode ser baixado. Sem login, sem quota.

O que procurar no relatório

Falhas costumam cair nestas áreas:

Metadata do arquivo embutido ausente: array /AF inexistente, ou anexo não listado nele.
AFRelationship ausente ou errado: para e-invoice deve ser Alternative; muitas bibliotecas PDF usam Source ou Data por padrão.
Namespace XMP ausente ou errado: Factur-X e ZUGFeRD têm URIs específicas; um caractere errado já falha.
Fontes não subsetadas ou não embutidas: PDF/A exige que todos os glyphs usados estejam embutidos com a fonte.
Output intent ausente: PDF/A exige intenção de cor (sRGB ou outro perfil ICC), mesmo em texto preto e branco.
Metadata do documento incompleta: /Title, /Producer e /CreationDate devem existir no dicionário de informações.

O relatório normalmente aponta a seção específica da especificação. Corrija na origem; se você gera com gPdf, a API cuida dessas regras e o validator é seu recibo público.

TL;DR

PDF/A-3 = PDF/A-2 + capacidade de embutir arquivos arbitrários legalmente. É isso que torna a e-invoicing europeia viável: fatura legível + XML CII EN 16931 estruturado, em um único wrapper arquivístico. O wrapper PDF/A-3 e o XML anexado precisam passar.

Gere com POST /api/v1/e-invoice/render. Verifique em validator. Três motores (veraPDF + gPdf edge + Mustang), um upload, grátis.