PDF/A es el sabor archivístico de PDF: la promesa de que un documento se verá en 2050 igual que se ve en 2026. Hay cuatro perfiles principales (PDF/A-1, 2, 3, 4) y varios niveles de conformidad. De ellos, PDF/A-3 es el que sostiene silenciosamente la factura electrónica europea, y el único perfil de uso extendido que permite adjuntar archivos arbitrarios dentro del wrapper de archivo.

Si trabajas con facturas, expedientes regulatorios o cualquier flujo “PDF + datos estructurados”, PDF/A-3 es la especificación que vas a encontrar. Esta es la lectura práctica: qué es, en qué se diferencia y cómo verificar que un archivo cumple de verdad.

La familia PDF/A en un párrafo

Perfil	ISO part	Año	Rasgo que lo define
PDF/A-1	19005-1	2005	Primer perfil de archivo. Sin transparencia, sin JavaScript, fuentes embebidas.
PDF/A-2	19005-2	2011	Añade JPEG2000, transparencia y capas. Mejor fidelidad de impresión.
PDF/A-3	19005-3	2012	Añade adjuntos de archivo embebidos. El wrapper de Factur-X / ZUGFeRD.
PDF/A-4	19005-4	2020	Revisión moderna; modelo de conformidad más limpio, sin separación `b` vs `a`.

Los niveles importan:

b (basic): conserva la fidelidad visual. El documento se puede leer, pero no promete estructura semántica.
a (accessible): etiquetas estructurales y mapeo Unicode; los lectores de pantalla pueden extraer el texto en orden.
u (Unicode): mapeo Unicode sin estructura completa; punto medio.
e / f (solo PDF/A-4): contenido 3D de ingeniería y formularios completos.

Así que “PDF/A-3b” significa: perfil de archivo 3 (permite adjuntos), nivel básico (sin obligación de etiquetado de accesibilidad). Es la variante habitual en facturación.

Qué hace especial a PDF/A-3

PDF/A-1 y PDF/A-2 prohíben archivos embebidos arbitrarios. La razón es archivística: un PDF duradero debe ser autocontenido; si adjuntas data.xlsx, ese archivo puede envejecer de forma distinta al PDF y romper la garantía.

PDF/A-3 relaja esa regla con una condición estricta: cada adjunto debe declarar un atributo AFRelationship que explique su relación con el contenido visible. Los valores válidos son Source, Data, Alternative, Supplement, Unspecified. Además, el PDF debe listar el adjunto en el array /AF y emitir metadata XMP sobre ese archivo.

En otras palabras: PDF/A-3 dice “puedes adjuntar cosas, pero tienes que declarar qué son y cómo se relacionan con lo que ve la persona”. Eso lo convirtió en el vehículo de la e-factura: la factura legible va en el PDF, el XML CII EN 16931 va adjunto, y AFRelationship="Alternative" declara que ambos son dos representaciones de la misma factura.

Dónde aparece PDF/A-3 en producción

Factur-X (Francia, B2B obligatorio desde 2026 en adelante): PDF/A-3 + XML CII, con namespace XMP urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0#.
ZUGFeRD 2.x (Alemania, recepción obligatoria desde 2025): PDF/A-3 + XML CII, con namespace XMP urn:zugferd:pdfa:CrossIndustryDocument:invoice:2p0#.
Archivo CAD de ingeniería: PDF/A-3 con el archivo CAD nativo adjunto. El PDF es el render; el CAD es la fuente.
Presentaciones regulatorias: PDF/A-3 con payloads XML adjuntos, como FDA submissions o informes ESEF de emisores cotizados de la UE.

En todos estos casos el wrapper no es solo un contenedor. Es un contrato: el PDF y el archivo adjunto representan el mismo documento y ambos deben validar.

Cómo verificar un PDF/A-3

El verificador oficial es veraPDF (verapdf.org), mantenido por PDF Association. Implementa las reglas ISO 19005-3; si veraPDF dice “Pass — PDF/A-3b”, es la señal más fuerte que puede dar un solo motor.

Pero un “Pass” de un solo motor no es estándar de auditoría (Why two PDF/A validators are better than one explica por qué). El patrón serio es ejecutar dos motores independientes y tratar el archivo como conforme solo si ambos pasan.

Para una e-factura necesitas también otra capa: Mustang (mustangproject.org), el comprobador de facto para Factur-X / ZUGFeRD. Mustang valida el XML CII embebido contra Schematron EN 16931. Cumplir PDF/A-3 no basta; si el XML adjunto no cumple EN 16931, el sistema AP receptor rechazará la factura.

Muchos equipos instalan Java, veraPDF CLI y Mustang, y después escriben un script para unir las salidas. Funciona, pero pesa.

validator ejecuta los tres motores en el navegador:

veraPDF: referencia oficial para conformidad PDF/A-3.
gPdf Rust+WASM edge engine: implementación independiente, segunda opinión.
Mustang: Schematron CII EN 16931 para payloads de e-factura embebidos.

Arrastra el archivo, los tres se ejecutan en paralelo y los reportes vuelven lado a lado. Puedes descargar JSON para evidencia de QA. Sin login y sin cuota.

Qué mirar en el reporte

Los fallos suelen agruparse así:

Falta metadata del archivo embebido: no existe el array /AF, o el adjunto no aparece en él.
AFRelationship ausente o equivocado: para e-factura debe ser Alternative; muchas librerías PDF usan Source o Data por defecto.
Namespace XMP ausente o equivocado: Factur-X y ZUGFeRD tienen URIs concretas; un carácter mal falla.
Fuentes no subseteadas o no embebidas: PDF/A exige que todos los glyphs usados estén embebidos. Incluso una referencia de fuente declarada pero no usada puede fallar.
Falta output intent: PDF/A requiere una intención de color (sRGB u otro perfil ICC), aunque el documento sea texto negro sobre blanco.
Metadata del documento incompleta: /Title, /Producer y /CreationDate deben existir en el diccionario de información.

Cada error suele apuntar a una sección concreta de la especificación. Corrígelo en la fuente; si generas con gPdf, la API se encarga de estas reglas y el validator queda como recibo público.

TL;DR

PDF/A-3 = PDF/A-2 + capacidad de embeber archivos arbitrarios legalmente. Esa capacidad hace viable la e-factura europea: factura visual + XML CII EN 16931 estructurado, en un único wrapper archivístico. La conformidad exige que pasen el wrapper PDF/A-3 y el XML adjunto.

Genera con POST /api/v1/e-invoice/render. Verifica en validator. Tres motores (veraPDF + gPdf edge + Mustang), una subida, gratis.