Si es ingeniero y acaban de decirle “las facturas tienen que ser PDF/A-3 con Factur-X para el próximo trimestre”, pero su único contexto es que alguien de legal pronunció esas palabras, este artículo es para usted.

Vamos a recortar el tono de documento de estándares y explicar qué restringen realmente estos perfiles, por qué los gobiernos empezaron a exigirlos y cuál es la canalización práctica más pequeña para emitir un PDF conforme desde un renderizador de datos estructurados.

PDF/A en dos párrafos

PDF es un formato flexible. Demasiado flexible: la misma especificación PDF permite incrustar JavaScript, enlazar a recursos externos que quizá no existan dentro de 50 años, cifrar contenido con criptografía reversible, referenciar fuentes externas y cien cosas más que hacen que un documento no sea autocontenido.

PDF/A (“A” de Archival) es un perfil de PDF que prohíbe las partes que impedirían que el documento se renderizara de forma idéntica dentro de 50 años. Las reglas de alto nivel:

Todas las fuentes deben estar embebidas.
Sin JavaScript, sin enlaces externos, sin audio/video.
Sin cifrado.
Toda transparencia debe ser aplanada o soportada por la versión del perfil.
Los colores deben ser independientes del dispositivo (perfil ICC requerido).
Todo el contenido debe estar en el archivo — sin referencias que dependan de la red.

Hay varias versiones, cada una añadiendo tolerancia para funciones más nuevas:

Perfil	Año	Qué añade
PDF/A-1b	2005	Línea base original — el más estricto
PDF/A-2b	2011	Permite JPEG2000, transparencia, capas
PDF/A-3b	2012	Permite adjuntos de archivo arbitrarios (la fundación de Factur-X)
PDF/A-4	2020	Base ISO 32000-2 (PDF 2.0), niveles de conformidad simplificados

El sufijo “b” significa conformidad “basic” (fidelidad visual). También existen variantes “u” (mapeo Unicode) y “a” (etiquetado para accesibilidad). Para la mayoría de flujos de facturas y recibos, “b” es lo que necesita, porque el archivo fiscal se preocupa por reproducibilidad visual, no por semántica para lectores de pantalla.

Conclusión práctica: si su renderizador dice que soporta PDF/A-3b, debería ser una sola bandera de configuración ({ profile: "PDF/A-3b" } o equivalente). Si tiene que ejecutar una segunda herramienta (Ghostscript, qpdf, Acrobat) para convertir después, eso es una brecha de flujo que debe considerar en sus operaciones.

Por qué PDF/A-3 importa específicamente: es el portador de las facturas electrónicas

PDF/A-3 añadió una capacidad que resultó cambiando el mundo: adjuntos de archivo arbitrarios dentro del PDF.

Suena aburrido. No lo es. Es la base técnica completa de los mandatos de factura electrónica que se están desplegando ahora en Europa.

La arquitectura: un único archivo PDF que es tanto

Una factura legible por humanos (diseño visual, totales, marca): la parte que lee una persona.
Una factura XML legible por máquina: la parte que analiza el software de la autoridad fiscal.

Ambas dentro de un archivo, ambas representando la misma factura, y el contenedor PDF/A-3 garantiza que el archivo seguirá siendo analizable durante décadas.

Los dos formatos XML principales:

Factur-X (Francia) — perfil XML basado en UN/CEFACT Cross Industry Invoice
ZUGFeRD (Alemania) — sustancialmente idéntico a Factur-X (los dos estándares se fusionaron técnicamente en 2018)
EN 16931 — la norma europea que ambas implementaciones cumplen

Para la mayoría de flujos, “Factur-X” y “ZUGFeRD” son términos intercambiables: comparten esquema, comparten mecanismo de incrustación y un PDF conforme con uno generalmente es conforme con el otro.

Qué es obligatorio, dónde, cuándo

Una instantánea no exhaustiva para ingenieros planeando rollouts Q2/Q3 2026:

País	Estado	Formato requerido
Alemania	B2B obligatorio para recepción desde 2025-01-01; emisión desde 2027	EN 16931 (ZUGFeRD / Factur-X / XRechnung)
Francia	Emisión obligatoria para grandes empresas 2026-09; PYMES 2027-09	Factur-X vía Chorus Pro
Italia	B2B obligatorio desde 2019	FatturaPA vía SDI
Polonia	Obligatorio desde 2024-07	KSeF
España	Obligatorio desde 2026 (B2B)	Facturae vía FACe
Bélgica	Obligatorio desde 2026-01	Peppol BIS 3

El patrón: todos los estados miembros de la UE están implementando alguna variante de facturación electrónica conforme con EN 16931 en un calendario 2024-2027. Si sus clientes operan en cualquiera de estos mercados, su generador PDF tendrá que emitir XML adjunto junto a la factura visual.

La canalización práctica más pequeña

Olvide lo que prescriben los documentos de estándares. Esta es la vista de ingeniería:

   ┌─────────────────────┐
   │  Datos de su        │  (ya un objeto JSON en algún lugar)
   │      factura        │
   └─────────┬───────────┘
             │
             ▼
   ┌─────────────────────┐
   │ Construir XML       │  (mapeo determinístico; existen libs probadas)
   │     EN 16931        │
   └─────────┬───────────┘
             │
             ▼
   ┌─────────────────────┐
   │ Renderizar PDF/A-3b │
   │ + adjuntar XML      │  (una llamada API a gPdf, o dos pasos en otros sistemas)
   └─────────┬───────────┘
             │
             ▼
   ┌─────────────────────┐
   │  Entregar a         │
   │  Chorus Pro / SDI /│
   │  Peppol / etc      │
   └─────────────────────┘

Los dos pasos no triviales:

Paso 1: construir el XML

Esto es molesto pero mecánico. Mapea los datos de su factura (líneas, impuestos, totales, partes) a nombres de campo XML EN 16931. Varias bibliotecas Java/Node/Python lo hacen por usted; busque “factur-x library” en su lenguaje. No lo escriba desde cero salvo que disfrute de verdad las especificaciones de esquemas XML.

Paso 2: renderizar PDF/A-3 y adjuntar el XML

Aquí importa la elección del renderizador.

Sin soporte integrado: renderiza un PDF ordinario y luego lo posprocesa con una herramienta que convierte a PDF/A-3 y adjunta el XML como archivo incrustado. Pilas comunes: Ghostscript + qpdf, o una herramienta de pago como Aspose. Dos pasos extra, dos puntos de fallo extra, y tiene que asegurar que el posprocesamiento no altere el diseño visual.

Con soporte integrado (el enfoque de gPdf): una llamada.

curl -X POST https://api.gpdf.com/api/v1/e-invoice/render \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  --data '{
    "settings": {
      "profile": "pdfa-3b",
      "e_invoice": {
        "standard": "factur_x",
        "profile": "en16931",
        "document_type": "invoice",
        "xml": {
          "format": "cii",
          "encoding": "utf8",
          "content": "<?xml version=\"1.0\"?><rsm:CrossIndustryInvoice>...</rsm:CrossIndustryInvoice>"
        }
      }
    },
    "pages": [{ "size": "a4", "elements": [...] }]
  }' \
  --output invoice-with-einvoice.pdf

Eso es toda la canalización. El renderizador emite PDF/A-3b, adjunta su XML como factur-x.xml (o zugferd-invoice.xml, ambos reconocidos por todos los consumidores) y devuelve los bytes.

Trampas comunes

Algunas cosas que la gente aprende por las malas:

«PDF/A» y «con fuentes conformes a PDF/A» no son lo mismo

Un archivo PDF/A-3 requiere que todas las fuentes estén incrustadas con cobertura completa de los glifos usados. Si su factura tiene un nombre de cliente japonés y el renderizador cae a una fuente que no es completamente incrustable, las herramientas de validación lo rechazarán. Compruebe que su renderizador incrusta fuentes CJK en modo PDF/A: muchos no lo hacen por defecto.

Visual + XML deben coincidir

La factura XML y la factura visual deben representar la misma factura. Los auditores fiscales las compararán. Si su código emite XML con total: 119.00 y el PDF visual muestra Total: 120.00 (por un bug de redondeo o una plantilla obsoleta), tendrá una discrepancia fiscal archivada. Genere ambas desde la misma fuente de referencia, idealmente en la misma ruta de código.

Niveles de “perfil” en EN 16931

Factur-X tiene perfiles: MINIMUM, BASIC, EN 16931, EXTENDED. Difieren en cuántos datos contiene el XML. Use BASIC salvo que su cliente requiera específicamente más: cubre códigos fiscales, líneas, partes y totales, suficiente para ~95% de la facturación B2B. El perfil EN 16931 añade más detalle para casos límite.

Validación antes de envío

Valide siempre el PDF generado contra un validador PDF/A (veraPDF es el estándar open source) y valide el XML contra el esquema EN 16931 antes de enviarlo a la autoridad fiscal. Los envíos fallidos a Chorus Pro / SDI cuentan contra sus métricas de fiabilidad con el regulador.

TL;DR

PDF/A es un perfil de documento autocontenido. PDF/A-3 permite adjuntar archivos. Factur-X / ZUGFeRD es “un XML EN 16931 adjunto dentro de un PDF/A-3”. Los mandatos de factura electrónica en toda la UE convierten esta combinación en el formato B2B de facto entre 2025 y 2027.

Si su renderizador trata PDF/A-3 + Factur-X como una sola bandera de configuración, la migración es mecánica. Si no, está construyendo una canalización operativa de varios pasos. El /api/v1/e-invoice/render de gPdf es la versión de una sola bandera: la referencia API tiene el esquema completo, o puede probar un renderizado de muestra en el Playground.