Se você é engenheiro a quem acabaram de dizer «as faturas precisam ser PDF/A-3 com Factur-X até o próximo trimestre», e seu único contexto é que alguém do jurídico pronunciou essas palavras, este post é para você.

Cortamos o tom dos documentos de padronização e explicamos o que esses perfis realmente restringem, por que governos começaram a obrigá-los e a menor pipeline prática para emitir um PDF conforme a partir de um renderizador de dados estruturados.

PDF/A em dois parágrafos

PDF é um formato flexível. Flexível demais — a mesma especificação PDF permite embutir JavaScript, vincular recursos externos que talvez não existam em 50 anos, criptografar conteúdo com criptografia reversível, referenciar fontes externas e fazer uma centena de outras coisas que tornam um documento não autocontido.

PDF/A («A» de Archival) é um perfil de PDF que proíbe as partes que impediriam o documento de renderizar identicamente em 50 anos. As regras de alto nível:

Todas as fontes devem estar embutidas.
Sem JavaScript, sem links externos, sem áudio/vídeo.
Sem criptografia.
Toda transparência deve ser achatada ou suportada pela versão do perfil.
Cores devem ser independentes do dispositivo (perfil ICC necessário).
Todo conteúdo deve estar dentro do arquivo — sem referências que dependem da rede.

Existem várias versões, cada uma adicionando tolerância a recursos mais recentes:

Perfil	Ano	O que adiciona
PDF/A-1b	2005	Baseline original — o mais rígido
PDF/A-2b	2011	Permite JPEG2000, transparência, camadas
PDF/A-3b	2012	Permite anexos arbitrários de arquivo (a fundação do Factur-X)
PDF/A-4	2020	Base ISO 32000-2 (PDF 2.0), níveis de conformidade simplificados

O sufixo “b” significa conformidade “basic” (fidelidade visual). Também existem variantes “u” (unicode-mapped) e “a” (accessibility-tagged) — para a maioria dos fluxos de fatura/recibo, “b” é o que você quer, porque arquivo fiscal se preocupa com reprodutibilidade visual, não com semântica de leitor de tela.

Conclusão prática: se o seu renderizador diz suportar PDF/A-3b, isso deve ser uma única flag de configuração ({ profile: "PDF/A-3b" } ou equivalente). Se você precisa rodar uma segunda ferramenta (Ghostscript, qpdf, Acrobat) para converter depois, isso é uma lacuna de fluxo que precisa entrar na conta operacional.

Por que PDF/A-3 importa especificamente: ele é o portador de e-invoices

PDF/A-3 adicionou uma capacidade que se mostrou mudança-de-mundo: anexos de arquivo arbitrários dentro do PDF.

Soa entediante. Não é. É a fundação técnica inteira dos mandatos de fatura eletrônica rolando pela Europa neste momento.

A arquitetura: um único arquivo PDF que é ao mesmo tempo

Uma fatura legível por humanos (layout visual, totais, marca) — a parte que a pessoa lê.
Uma fatura XML legível por máquina — a parte que o software da autoridade fiscal interpreta.

Ambos dentro de um arquivo, ambos representando a mesma fatura, e o wrapper PDF/A-3 garante que o arquivo permanecerá parseable por décadas.

Os dois principais formatos XML:

Factur-X (França) — perfil XML baseado em UN/CEFACT Cross Industry Invoice
ZUGFeRD (Alemanha) — substancialmente idêntico ao Factur-X (os dois padrões se fundiram tecnicamente em 2018)
EN 16931 — a norma europeia à qual ambas as implementações obedecem

Para a maioria dos fluxos, “Factur-X” e “ZUGFeRD” são termos intercambiáveis — compartilham um schema, compartilham o mecanismo de embedding, e um único PDF conforme com um geralmente é conforme com o outro.

O que é obrigatório, onde, quando

Snapshot não exaustivo para engenheiros planejando rollouts em Q2/Q3 de 2026:

País	Status	Formato requerido
Alemanha	B2B obrigatório para recepção desde 2025-01-01; emissão a partir de 2027	EN 16931 (ZUGFeRD / Factur-X / XRechnung)
França	Emissão obrigatória para grandes empresas 2026-09; PMEs 2027-09	Factur-X via Chorus Pro
Itália	B2B obrigatório desde 2019	FatturaPA via SDI
Polônia	Obrigatório desde 2024-07	KSeF
Espanha	Obrigatório a partir de 2026 (B2B)	Facturae via FACe
Bélgica	Obrigatório a partir de 2026-01	Peppol BIS 3

O padrão: cada estado-membro da UE está implementando alguma variação de e-invoicing conforme à EN 16931 em uma linha do tempo de 2024-2027. Se seus clientes operam em qualquer um desses mercados, seu gerador de PDF precisará emitir XML anexado junto da fatura visual.

A menor pipeline prática

Esqueça o que documentos de padronização prescrevem. Aqui a visão de engenheiro:

   ┌─────────────────────┐
   │  Dados da sua       │  (já um objeto JSON em algum lugar)
   │      fatura         │
   └─────────┬───────────┘
             │
             ▼
   ┌─────────────────────┐
   │ Construir XML       │  (mapeamento determinístico; libs testadas existem)
   │     EN 16931        │
   └─────────┬───────────┘
             │
             ▼
   ┌─────────────────────┐
   │ Render PDF/A-3b +   │
   │ attach the XML      │  (single API call to gPdf — or two-step elsewhere)
   └─────────┬───────────┘
             │
             ▼
   ┌─────────────────────┐
   │  Entregar a         │
   │  Chorus Pro / SDI / │
   │  Peppol / etc       │
   └─────────────────────┘

Os dois passos não-triviais:

Passo 1: construir o XML

Isso é chato, mas mecânico. Você mapeia seus dados de fatura (linhas, impostos, totais, partes) para nomes de campo XML EN 16931. Várias bibliotecas Java/Node/Python fazem isso para você — busque por “factur-x library” na sua linguagem. Não escreva do zero a menos que você genuinamente goste de especificações de schema XML.

Passo 2: renderizar PDF/A-3 e anexar o XML

Aqui a escolha do renderizador importa.

Sem suporte embutido: você renderiza um PDF comum, depois pós-processa com uma ferramenta que converte para PDF/A-3 e anexa o XML como arquivo embutido. Stacks comuns: Ghostscript + qpdf, ou uma ferramenta paga como Aspose. Dois passos extras, dois pontos de falha extras, e você precisa garantir que o pós-processamento não desvie o layout visual.

Com suporte embutido (a abordagem do gPdf): uma chamada.

curl -X POST https://api.gpdf.com/api/v1/e-invoice/render \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  --data '{
    "settings": {
      "profile": "pdfa-3b",
      "e_invoice": {
        "standard": "factur_x",
        "profile": "en16931",
        "document_type": "invoice",
        "xml": {
          "format": "cii",
          "encoding": "utf8",
          "content": "<?xml version=\"1.0\"?><rsm:CrossIndustryInvoice>...</rsm:CrossIndustryInvoice>"
        }
      }
    },
    "pages": [{ "size": "a4", "elements": [...] }]
  }' \
  --output invoice-with-einvoice.pdf

Essa é a pipeline inteira. O renderizador emite PDF/A-3b, anexa seu XML como factur-x.xml (ou zugferd-invoice.xml, ambos reconhecidos por todos os consumidores) e retorna os bytes.

Pegadinhas comuns

Algumas coisas que pessoas aprendem do jeito difícil:

“PDF/A” e “com fontes compatíveis com PDF/A” não são a mesma coisa

Um arquivo PDF/A-3 exige que todas as fontes estejam embutidas com cobertura completa dos glifos usados. Se sua fatura tem um nome de cliente japonês e o renderizador cai para uma fonte que não é totalmente embutível, ferramentas de validação vão rejeitar o arquivo. Verifique se seu renderizador embute fontes CJK no modo PDF/A — muitos não fazem isso por padrão.

Visual + XML devem coincidir

A fatura XML e a fatura visual devem representar a mesma fatura. Auditores fiscais vão compará-las. Se seu código emite XML com total: 119.00 e o PDF visual mostra Total: 120.00 (por causa de um bug de arredondamento ou template antigo), você tem uma discrepância fiscal em arquivo. Gere ambos da mesma fonte autoritativa, idealmente no mesmo caminho de código.

Níveis de «perfil» em EN 16931

Factur-X tem perfis: MINIMUM, BASIC, EN 16931, EXTENDED. Eles diferem em quanta informação vai no XML. Use BASIC a menos que seu cliente exija especificamente mais — ele cobre códigos fiscais, itens de linha, partes e totais, o suficiente para ~95% de faturamento B2B. O perfil EN 16931 adiciona mais detalhes para casos de borda.

Validação antes de submissão

Sempre valide o PDF gerado contra um validador PDF/A (veraPDF é o padrão open-source) e valide o XML contra o schema EN 16931 antes de enviar à autoridade fiscal. Submissões falhas para Chorus Pro / SDI contam contra suas métricas de confiabilidade com o regulador.

TL;DR

PDF/A é um perfil de documento autocontido. PDF/A-3 permite anexar arquivos. Factur-X / ZUGFeRD é “um XML EN 16931 anexado dentro de um PDF/A-3”. Mandatos de e-invoice em toda a UE tornam essa combinação o formato B2B de fato de 2025-2027.

Se seu renderizador trata PDF/A-3 + Factur-X como uma única flag de configuração, a migração é mecânica. Se não, você está construindo uma pipeline operacional de várias etapas. O /api/v1/e-invoice/render do gPdf é a versão de flag única — a referência da API tem o schema completo, ou teste uma renderização de exemplo no Playground.