Un PDF cumple PDF/A-3 o no lo cumple. Entonces, ¿por qué pasar el mismo archivo por dos validadores?

Porque en la práctica la especificación es lo bastante grande como para que dos implementaciones correctas discrepen en los bordes. En un flujo que debe aguantar auditoría, un “Pass” de un solo motor es una luz amarilla, no verde.

PDF/A no es un algoritmo único

PDF/A se reparte entre varias partes de ISO 19005: PDF/A-1, PDF/A-2, PDF/A-3 y PDF/A-4, con niveles b, a, u, e y f. Todo eso se apoya además en la especificación PDF base, ISO 32000. La superficie normativa suma miles de páginas.

Ahí aparecen diferencias reales:

Transparencia en PDF/A-2/3: permitida bajo condiciones concretas, pero no todos los validadores interpretan igual el borde.
Perfiles ICC: un perfil puede considerarse obligatorio, recomendado o insuficiente según la lectura del motor.
Metadatos de archivos embebidos en PDF/A-3: AFRelationship, referencias /AF y XMP deben encajar con mucha precisión.
Subconjuntos de fuentes: las fuentes CID con subsets parciales han sido una fuente clásica de discrepancias.

No siempre son bugs. A menudo es la consecuencia normal de una norma compleja implementada por equipos independientes. En sectores regulados, la postura conservadora es pedir confirmación independiente.

El motor de referencia y una segunda opinión

veraPDF es la implementación de referencia mantenida por la PDF Association. Si veraPDF dice “Pass”, tienes la señal individual más fuerte disponible para PDF/A.

Pero “la mejor señal individual” no equivale a “evidencia suficiente para auditoría”. Bancos, archivos sanitarios, administraciones y sistemas de conservación a largo plazo suelen pedir un segundo motor porque:

El receptor puede usar otro validador y rechazar un archivo que tu único motor aceptó.
Un bug en un motor no se detecta ejecutando el mismo motor dos veces.
El principio de doble confirmación es habitual en compliance y encaja de forma natural con PDF/A.

En gPdf combinamos veraPDF con nuestro propio motor escrito en Rust + WebAssembly. Es una implementación independiente de la misma especificación. Si ambos pasan, la conclusión es mucho más fuerte; si discrepan, tienes una pista clara para investigar.

Dos informes en una sola URL

El flujo está disponible gratis en gpdf.com/validator/. No necesitas cuenta: subes el archivo, se ejecutan veraPDF y el motor edge de gPdf en paralelo, y recibes dos informes lado a lado.

Casos típicos:

Antes de enviar un PDF/A: sube el archivo, comprueba doble “Pass” y guarda los JSON como evidencia de QA.
Un motor falla y otro pasa: compara informes; suele ser un XMP mal alineado, una referencia /AF o metadata de adjunto.
Ambos fallan: el archivo está roto y debe corregirse en origen.
Muestreo de un lote archivado: valida muestras y adjunta los resultados al papel de trabajo.

El archivo no se persiste. Se procesa en memoria sobre Cloudflare Workers y se descarta al terminar el informe.

También aplica a e-invoicing

La misma lógica se extiende a Factur-X / ZUGFeRD. Además de PDF/A-3, hay que validar el XML CII EN 16931 embebido. gPdf usa Mustang para esa parte y muestra el resultado junto a la validación PDF/A.

No se trata de desconfiar de una herramienta concreta; se trata de construir evidencia con dos implementaciones independientes.

TL;DR

Un “Pass” de un solo motor es luz amarilla. Dos “Pass” independientes son una señal mucho más fuerte. Usa validator, descarga los informes y adjúntalos a QA o auditoría. Si el PDF salió de gPdf, el validador es el recibo público de que la promesa de conformidad se cumplió.