Qué es PDF/A-3 y por qué importa para la facturación electrónica

Si se ha trabajado cerca de la facturación electrónica europea en los últimos dos años, probablemente se ha visto el término PDF/A-3 como si todo el mundo ya supiera lo que significa. La mayoría de los artículos asumen que el lector conoce la diferencia entre PDF, PDF/A y PDF/A-3, y siguen adelante. Las diferencias no son académicas. Determinan si una factura enviada hoy seguirá siendo abrible, verificable y legalmente válida en 2036.

Aquí está la versión que ojalá alguien hubiera escrito antes.

PDF, PDF/A, PDF/A-3: tres cosas distintas

Un PDF normal es un formato de presentación. Puede contener lo que un diseñador quiera: referencias a fuentes externas, JavaScript, vídeo incrustado, vínculos a recursos remotos. Esa flexibilidad es estupenda para folletos de marketing y terrible para archivos. Un PDF creado en 2005 puede ya renderizarse de forma diferente en un visor de 2025 porque se sustituyó una fuente, un recurso externo dio 404 o una extensión del proveedor quedó obsoleta.

PDF/A (ISO 19005) es un subconjunto estricto de PDF diseñado para renderizarse de forma idéntica para siempre. Prohíbe las funciones dinámicas. Todas las fuentes deben estar incrustadas. Todos los perfiles de color deben ser autocontenidos. Sin JavaScript, sin contenido externo, sin cifrado. El resultado es un archivo que se garantiza que será abrible y visualmente idéntico décadas después.

PDF/A-3 es la tercera revisión de ese estándar, publicada en 2012. Cambió exactamente una cosa: permite incrustar adjuntos arbitrarios dentro del PDF. Las versiones anteriores (PDF/A-1, PDF/A-2) solo permitían adjuntos que fueran a su vez conformes con PDF/A. PDF/A-3 eliminó esa restricción. Ahora se puede incrustar un archivo XML, un CSV, un documento JSON o cualquier otra cosa como adjunto estructurado.

Ese único cambio fue lo que hizo posible la facturación electrónica moderna.

Por qué la facturación electrónica necesitaba exactamente esto

Una factura electrónica europea conforme debe ser dos cosas a la vez:

1. Legible para máquinas. El sistema contable del comprador necesita ingerir artículos de línea, tipos de IVA y condiciones de pago sin intervención humana.
2. Legible para humanos, durante años. La ley fiscal de la mayoría de los países de la UE exige que la factura se archive en una forma que un auditor humano pueda abrir y leer, durante períodos de entre 7 y 10 años.

Un archivo XML UBL puro satisface el primer requisito pero falla en el segundo. Un PDF puro satisface el segundo pero no el primero. Un PDF/A-3 con UBL incrustado satisface ambos, en un único contenedor a prueba de manipulaciones, y la capa visual es bit a bit idéntica a la capa estructurada.

Esta es la arquitectura detrás de Factur-X (el estándar de factura híbrida francogermano) y ZUGFeRD (su predecesor alemán). Ambos son PDF/A-3 con un adjunto XML específico en una ubicación específica con un nombre de archivo específico. Quitando los nombres de marketing, lo que realmente son es “PDF/A-3, más un contrato sobre qué XML se pone dentro”.

Qué no proporciona PDF/A-3

PDF/A-3 es un formato de archivo. No es un certificado de cumplimiento, ni una firma. Tres cosas que específicamente no hace:

• No valida el XML incrustado. Se puede poner un UBL malformado dentro de un PDF/A-3 y el archivo seguirá superando la validación PDF/A-3. El formato solo garantiza el contenedor, no el contenido.
• No prueba cuándo se creó el archivo. Un archivo PDF/A-3 puede ser guardado de nuevo, con nueva marca de tiempo y reenviado sin dejar ninguna huella. Si hay que demostrar que “esta factura existía en esta fecha”, se necesita un sello de tiempo RFC 3161 por encima.
• No garantiza la entrega. La conformidad con el formato y la conformidad con un mandato nacional (Peppol, KSeF, Chorus Pro) son problemas distintos. PDF/A-3 es necesario pero no suficiente.

Por eso el proceso de SealDoc emite un PDF/A-3 más un sello de tiempo RFC 3161 más un paquete de evidencia con hashes de manifiesto. Cada capa responde a una pregunta diferente, y una auditoría real querrá las tres.

Errores habituales en los procesos con PDF/A-3

Se ven los mismos cinco errores en los procesos de los clientes:

1. PDFs convertidos a medias. Una biblioteca afirma que “genera PDF/A-3” pero omite la incrustación de fuentes para las fuentes del sistema, que luego se resuelven de forma diferente en el ordenador del auditor.
2. Relación de adjunto incorrecta. PDF/A-3 distingue entre Source, Data, Alternative, Supplement y Unspecified. Factur-X exige Alternative. Muchos sistemas de incrustación usan por defecto Unspecified y el archivo falla la validación estricta.
3. Metadatos XMP ausentes. PDF/A requiere metadatos autodescriptivos en XMP. Un archivo sin las claves requeridas pdfaid:part y pdfaid:conformance no es técnicamente PDF/A-3, independientemente de su estructura.
4. Desviación del perfil de color. Un PDF/A-3 debe declarar todos los espacios de color que usa. Los procesos que pasan imágenes RGB arbitrarias sin un perfil incrustado producen silenciosamente archivos no conformes.
5. Rerenderizado de un PDF existente. Algunos procesos rasterizan el PDF de entrada antes de reincrustarlo en XML. Esto funciona visualmente pero destruye la capa de texto buscable y rompe la accesibilidad.

Se puede comprobar cualquiera de los anteriores con nuestro validador público en /check. Se sube un archivo y se obtiene un veredicto en segundos, sin necesidad de registro. Si el archivo falla, el informe indica exactamente qué cláusula de qué especificación fue violada.

Cuándo PDF/A-3 es la elección correcta (y cuándo no)

PDF/A-3 es la elección correcta cuando hay que conservar una copia legible de un documento estructurado durante años y se quieren ambas capas en un solo contenedor. Eso cubre la facturación electrónica, los recibos electrónicos, los contratos estructurados y, cada vez más, los billetes electrónicos y los documentos aduaneros.

Es la elección incorrecta para documentos efímeros (un albarán que caduca en una semana), para documentos donde el contenido estructurado es lo único que importa (EDI puro) o donde la capa legible es puramente decorativa y nunca se auditará.

Para todos los demás en el B2B europeo en 2026, PDF/A-3 es el formato. Los detalles técnicos anteriores son la razón por la que funciona, y la razón por la que una implementación incorrecta producirá silenciosamente archivos que superan el control de calidad interno y fallan en la mesa del auditor tres años después.