Flujos de procesamiento documental: de DOCX a PDF/A-3 y archivo firmado en una sola llamada a la API
Un flujo de procesamiento documental que convierte documentos de entrada en salida de archivo conforme parece un problema resuelto. En la práctica, produce fallos silenciosos en cada paso: fuentes que aparecen correctas en pantalla pero fallan en la validación de PDF/A, capas de texto que se destruyen durante la conversión, metadatos que están presentes pero son técnicamente incorrectos, y sellos de tiempo aplicados a documentos que aún no están en su forma definitiva.
Este artículo detalla la cadena de conversión completa, qué falla en cada etapa y cómo es un flujo fiable.
La cadena completa
Source document (DOCX / HTML / existing PDF)
↓ conversion
PDF (rendered with correct fonts and layout)
↓ PDF/A-3 conformance
PDF/A-3 (embedded fonts, color profiles, XMP metadata, no external references)
↓ structured attachment (for hybrid invoices)
PDF/A-3 with embedded XML (Factur-X, ZUGFeRD, XRechnung attachment)
↓ digital signature
Signed PDF/A-3 (PAdES signature, LTV information embedded)
↓ RFC 3161 timestamp
Timestamped PDF/A-3 (RFC 3161 token from qualified EU TSA)
↓ archive + audit trail
Final archive (WORM storage + hash-chained audit trail + evidence pack)Cada flecha es un paso que puede introducir no conformidad. Cada paso debe incluir validación antes de que se ejecute el siguiente.
Paso 1: origen a PDF
La ruta de conversión más común es de DOCX a PDF. El riesgo aquí es la sustitución de fuentes: si una fuente utilizada en el DOCX no está disponible en el servidor de conversión, el renderizador sustituye por otra diferente. El resultado parece similar en pantalla pero contiene una fuente diferente de la especificada. Cuando más tarde se ejecuta la validación de PDF/A, puede detectar la fuente incorrecta o fallar porque la fuente incrustada no coincide con la referenciada en el documento.
La mitigación: asegurarse de que el entorno de conversión tiene todas las fuentes necesarias instaladas, o usar un enfoque de conversión que incruste fuentes en el momento de la conversión. LibreOffice headless y Gotenberg (un envoltorio de LibreOffice basado en Docker) son opciones de código abierto fiables para la conversión de DOCX a PDF. Gotenberg en particular proporciona un entorno aislado predecible.
No conviertas DOCX a PDF imprimiendo en un controlador de PDF. Los controladores de impresión suelen rasterizar el texto, lo que destruye la capa de texto y produce un documento visualmente idéntico pero que ya no es legible ni buscable por máquina. Un PDF rasterizado no puede convertirse en un PDF/A-3 válido sin re-OCR, lo que introduce error adicional.
Para HTML a PDF, el renderizado con navegador sin cabeza (usando motores de renderizado de navegador) es generalmente más fiable para la fidelidad de maquetación que wkhtmltopdf. Los motores de navegador modernos gestionan correctamente el CSS. Comprueba que la fuente HTML tenga todas las fuentes incrustadas o especificadas como fuentes web seguras.
Paso 2: de PDF a PDF/A-3
La conformidad con PDF/A-3 no se consigue automáticamente generando un PDF desde una biblioteca compatible con PDF/A-3. Varias cosas pueden fallar:
Metadatos XMP incorrectos o ausentes: PDF/A requiere un bloque XMP autodescriptivo que identifique el nivel de conformidad. Los campos requeridos:
<rdf:Description rdf:about="" xmlns:pdfaid="http://www.aiim.org/pdfa/ns/id/">
<pdfaid:part>3</pdfaid:part>
<pdfaid:conformance>B</pdfaid:conformance>
</rdf:Description>Sin este bloque, un documento no es técnicamente PDF/A-3 independientemente de su estructura. Muchos conversores producen salidas de aspecto PDF/A pero omiten o configuran incorrectamente el bloque XMP.
Fuentes no incrustadas: aunque la conversión haya incrustado fuentes, algunos conversores dejan las fuentes Type1 o TrueType parcialmente incrustadas (solo métricas, no los datos completos de glifos). PDF/A requiere incrustación completa.
Espacios de color no admitidos: las imágenes del documento deben usar espacios de color con perfiles ICC incrustados. Una imagen RGB sin perfil ICC falla la validación PDF/A. Convierte las imágenes a sRGB con un perfil incrustado antes de incluirlas en el documento.
Transparencia: PDF/A-1 prohíbe la transparencia. PDF/A-2 y PDF/A-3 la permiten pero requieren un manejo específico. Muchos documentos fuente usan sombras suaves o superposiciones translúcidas que deben aplanarse antes de la salida PDF/A-1.
Cifrado: PDF/A prohíbe el cifrado. Un PDF con contraseña de usuario o propietario no es conforme con PDF/A independientemente de otras propiedades.
Ejecuta VeraPDF después de este paso para confirmar la conformidad antes de continuar. VeraPDF es el validador de referencia, utilizado por archivos nacionales y reguladores de toda Europa. Es de código abierto y puede ejecutarse en un flujo de procesamiento sin cabeza.
Paso 3: incrustación de XML estructurado (documentos híbridos)
Para facturas (Factur-X, ZUGFeRD, XRechnung), el PDF/A-3 debe contener el XML de la factura como adjunto con metadatos específicos.
La relación del adjunto debe ser Alternative para Factur-X, no Data ni Unspecified. Esto está definido en la especificación Factur-X y es uno de los fallos de conformidad más comunes en los generadores de facturas PDF/A-3.
El esquema de extensión XMP requerido para el adjunto Factur-X:
<fx:ConformanceLevel>EN 16931</fx:ConformanceLevel>
<fx:DocumentFileName>factur-x.xml</fx:DocumentFileName>
<fx:DocumentType>INVOICE</fx:DocumentType>
<fx:Version>1.0</fx:Version>El nombre de fichero debe ser exactamente factur-x.xml para Factur-X, y los metadatos XMP deben hacer referencia a este nombre de fichero. Los validadores que comprueban la conformidad con Factur-X (no solo PDF/A-3) rechazarán documentos donde el nombre de fichero o la referencia XMP sean incorrectos.
Paso 4: firma digital
Aplica una firma PAdES (PDF Advanced Electronic Signatures), no una firma PDF básica. PAdES está definido en ETSI EN 319 132 y admite incrustación LTV.
En el momento de la firma, incrusta la cadena de certificados completa y la respuesta OCSP o la instantánea CRL que prueba que el certificado de firma era válido en el momento de la firma. Esta es la información LTV tratada en validación de PDF a largo plazo. Sin ella, la firma puede volverse inverificable cuando expire el certificado de firma.
No selelles con marca de tiempo antes de firmar. El orden correcto es: primero firmar, luego sellar la firma con marca de tiempo. Sellar el documento con marca de tiempo antes de firmar cambia el hash del documento, lo que invalida la firma.
Paso 5: sello de tiempo RFC 3161
Solicita el sello de tiempo inmediatamente después de la firma, mientras el certificado de firma sigue siendo verificable en línea. El sello de tiempo se aplica al hash del documento firmado y cubre tanto el contenido del documento como la firma.
Almacena el token de sello de tiempo dentro del PDF (en el diccionario DSS del documento) y también en el Paquete de Evidencia Legal como fichero independiente para verificación independiente.
Paso 6: archivo y pista de auditoría
Escribe el documento final en almacenamiento WORM con el período de retención bloqueado. Añade el evento de archivo a la pista de auditoría con cadena de hashes.
La entrada de la pista de auditoría para el paso de archivo debe incluir: el hash del documento, la ubicación de almacenamiento, el período de retención, el sello de tiempo del evento de archivo y el hash de la entrada de auditoría anterior. Esto produce un registro resistente a manipulaciones de que el documento fue archivado en esta forma exacta en este momento exacto.
Validación en cada paso
El modo de fallo que hay que evitar es la no conformidad silenciosa: un documento que pasa por los seis pasos y produce un fichero que parece correcto pero falla la validación cuando se presenta a un auditor.
Valida en los pasos 2, 3 y 5:
- Después de la conversión a PDF/A-3: VeraPDF para la conformidad con PDF/A-3
- Después de la incrustación XML (si procede): validador del perfil Factur-X o ZUGFeRD
- Después del sellado de tiempo: verificador PAdES (DSS o equivalente) para la validez de la firma y el sello de tiempo
Si la validación falla en cualquier paso, detén el flujo y devuelve un error estructurado. No procedas al archivo con un documento no conforme.
SealDoc como flujo de procesamiento documental
La API de SealDoc implementa la cadena completa descrita anteriormente como un único endpoint. Envías el documento fuente (DOCX, HTML o PDF existente) junto con los metadatos estructurados (datos de factura, información de partes, categoría de retención). La API ejecuta la conversión, la validación de PDF/A-3, la incrustación XML, la firma, el sellado de tiempo y el archivo, devolviendo el paquete de evidencia al completarse con éxito o un error de validación estructurado al fallar.
Cada paso del flujo está implementado para fallar rápido: si VeraPDF devuelve un error de conformidad, el flujo se detiene y devuelve la cláusula específica que fue violada en lugar de continuar al siguiente paso con un documento no conforme. El paquete de evidencia solo se genera cuando todos los pasos de validación han pasado.
Para organizaciones que necesitan integrar el archivo documental en flujos de trabajo existentes, la API acepta webhooks que notifican al completarse o fallar, y el paquete de evidencia es recuperable como un ZIP que contiene todos los componentes en formatos abiertos e independientemente verificables.