Blog

PDF/A-3 explicado: cómo comprobar que su archivo cumple de verdad

PDF/A-3 es el perfil PDF/A común que permite adjuntos legales: la base de la factura electrónica Factur-X / ZUGFeRD. Diferencias, puntos de control y validación con dos motores.

PDF/A es la variante archivística 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 contenedor archivístico.

Si trabaja con facturas, expedientes regulatorios o cualquier flujo “PDF + datos estructurados”, PDF/A-3 es la especificación que va 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 Parte ISO 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 contenedor 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 adjunta 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 metadatos XMP sobre ese archivo.

En otras palabras: PDF/A-3 dice “puede adjuntar cosas, pero tiene que declarar exactamente qué son y cómo se relacionan con lo que ve la persona”. Eso lo convirtió en el vehículo de la factura electrónica: 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 XML adjunto, como presentaciones ante la FDA o informes ESEF de emisores cotizados de la UE.

En todos estos casos el contenedor no es solo un recipiente. 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 factura electrónica necesita 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 de cuentas por pagar (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:

  1. veraPDF: referencia oficial para conformidad PDF/A-3.
  2. Motor Rust+WASM en el edge de gPdf: implementación independiente, segunda opinión.
  3. Mustang: Schematron CII EN 16931 para datos de factura electrónica embebidos.

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

Qué mirar en el reporte

Los fallos suelen agruparse así:

  • Faltan metadatos 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 sin subconjunto o no embebidas: PDF/A exige que todos los glifos usados estén embebidos. Incluso una referencia de fuente declarada pero no usada puede fallar.
  • Falta la intención de salida: PDF/A requiere una intención de color (sRGB u otro perfil ICC), aunque el documento sea texto negro sobre blanco.
  • Metadatos del documento incompletos: /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íjalo en la fuente; si genera con gPdf, la API se encarga de estas reglas y el validador queda como recibo público.

TL;DR

PDF/A-3 = PDF/A-2 + capacidad de embeber archivos arbitrarios legalmente. Esa capacidad hace viable la factura electrónica europea: factura visual + XML CII EN 16931 estructurado, en un único contenedor archivístico. La conformidad exige que pasen tanto el contenedor PDF/A-3 como el XML adjunto antes de enviar el documento.

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