PDF/A-3B y ZUGFeRD: ¿es realmente conforme el PDF de mi factura electrónica? (veraPDF)

ZUGFeRD es una factura híbrida: un PDF legible para personas más el XML legible por máquina en su interior. La parte PDF debe ser, además, una variante de archivo especial: PDF/A-3. Justo aquí surgen la mayoría de los malentendidos.

> Respuesta rápida: Para que un PDF sea realmente PDF/A-3(-B), deben estar, entre otras cosas, todas las fuentes incrustadas, presente un OutputIntent/perfil de color ICC y los metadatos PDF/A adecuados. Un validador como veraPDF lo comprueba, pero no repara nada. Si el PDF de origen no es conforme (p. ej. fuentes no incrustadas), solo ayuda una conversión real, o bien usar una XRechnung pura.

Qué exige PDF/A-3

PDF/A está diseñado para que un documento se represente de forma idéntica en cualquier equipo y dentro de muchos años. Para ello rigen reglas estrictas; las más importantes:

1. Todas las fuentes incrustadas – el archivo debe contener los datos de las fuentes por sí mismo y no puede depender de que el lector tenga instalada, p. ej., Arial.
2. OutputIntent / perfil de color ICC – el archivo debe definir cómo se reproducen los colores.
3. Metadatos XMP de PDF/A – la identificación como PDF/A-3.

El obstáculo frecuente: fuentes no incrustadas

Los sistemas de gestión comercial y de facturación más antiguos generan con frecuencia PDF que remiten a fuentes del sistema como Arial o Arial Bold, pero no las incrustan. Un archivo así ya no es conforme con PDF/A, y eso no se subsana añadiendo solo el XML de ZUGFeRD y los metadatos PDF/A.

Validar no es convertir

Un punto importante: veraPDF solo valida, no convierte. Un validador informa de «no conforme», pero no convierte un archivo no conforme en uno conforme. Para generar realmente PDF/A-3 se necesita un paso de conversión real que incruste las fuentes y añada un perfil de color (p. ej. con Ghostscript o la biblioteca de referencia de ZUGFeRD Mustangproject).

Lo que siempre es correcto: el XML

Con independencia del contenedor PDF, la parte decisiva y jurídicamente determinante es el XML estructurado. En TaxLayer, este se valida por completo frente al estándar de verificación de KoSIT y la EN 16931 (0 errores). Así, los datos de la factura en sí son correctos y conformes; la cuestión de PDF/A afecta solo a la envoltura exterior.

Cómo llegar con seguridad al objetivo

• Variante A – exportar PDF/A desde el sistema: si su sistema de gestión comercial puede emitir la factura como PDF/A (con fuentes incrustadas), el archivo ZUGFeRD generado a partir de ella es conforme.
• Variante B – usar una XRechnung pura: en la XRechnung (XML puro) no existe el contenedor PDF; la cuestión de la conformidad con PDF/A no se plantea.

Conclusión

PDF/A-3 es más que una etiqueta: exige fuentes incrustadas, un perfil de color y los metadatos correctos. Quien parte de un sistema más antiguo, lo mejor es exportar directamente PDF/A, o apostar por XRechnung, donde el contenedor PDF no desempeña ningún papel.

---

El XML de la factura electrónica en TaxLayer siempre está validado conforme a EN 16931 y KoSIT. ¿Preguntas sobre la conformidad con PDF/A? Escriba a info@landauer.de.