gPdf
Casos de uso · Facturación electrónica de la UE y finanzas

Facturas electrónicas de la UE: PDF/A-3 con Factur-X / ZUGFeRD integrado

Genere facturas electrónicas EN 16931 desde JSON: envoltorio PDF/A-3 con adjunto CII XML integrado, conforme con Factur-X o ZUGFeRD. Verifique ambas capas gratis en gpdf.com/validator/.

Trabajo a resolver

Emitir facturas electrónicas conformes con la UE desde un DocumentRequest JSON: un envoltorio PDF/A-3 que un equipo de cuentas por pagar pueda leer, con un adjunto CII XML integrado conforme con EN 16931 que una autoridad fiscal pueda procesar de forma automática. Una sola llamada API debe producir ambas capas, y ambas deben validarse contra motores de referencia, no solo contra el verificador del proveedor.

Por qué gPdf encaja aquí

  • POST /api/v1/e-invoice/render: un único endpoint que devuelve un PDF/A-3 Factur-X o ZUGFeRD en una sola ida y vuelta.
  • Envoltorio PDF/A-3b emitido automáticamente con el namespace XMP correcto, AFRelationship='Alternative' y metadatos de archivo integrado según la base Factur-X / ZUGFeRD.
  • CII XML EN 16931 adjunto como carga estructurada canónica, legible por herramientas de automatización de cuentas por pagar en toda la UE.
  • El modo de validación estricta ejecuta controles Schematron completos de forma asíncrona y devuelve un artefacto de informe junto al PDF.
  • Perfiles de residencia de datos (`eu` / `global` / `auto`) para que los equipos de AP/AR sujetos al GDPR puedan mantener los artefactos de factura electrónica dentro de regiones de la UE.
  • El validador público gratuito en gpdf.com/validator/ ejecuta veraPDF (capa PDF/A) Y Mustang (capa CII XML / EN 16931) en paralelo: verificación independiente antes de conectarlo a producción.

Solicitud de ejemplo

POST /api/v1/e-invoice/render: solicitud mínima Factur-X con CII XML integrado.

{
  "settings": {
    "profile": "pdfa-3b",
    "e_invoice": {
      "standard": "factur_x",
      "profile": "en16931",
      "document_type": "invoice",
      "xml": {
        "format": "cii",
        "encoding": "utf8",
        "content": "<?xml version=\"1.0\" encoding=\"UTF-8\"?><rsm:CrossIndustryInvoice>...</rsm:CrossIndustryInvoice>"
      }
    }
  },
  "pages": [
    { "size": "a4", "elements": [] }
  ]
}

Cumplimiento y conformidad

  • Factur-X 1.0: especificación francoalemana, obligatoria para facturas B2B francesas desde 2026, con despliegue por fases.
  • ZUGFeRD 2.x: especificación alemana conforme con EN 16931; obligatoria para la recepción de facturas B2B alemanas desde 2025.
  • EN 16931: modelo semántico paneuropeo para facturas electrónicas que encapsulan tanto Factur-X como ZUGFeRD.
  • PDF/A-3: formato de envoltorio de archivo necesario para contener legalmente un adjunto XML integrado (ISO 19005-3).
  • Validación: no confíe en la autocomprobación de un único proveedor. La verificación independiente con veraPDF (PDF/A) + Mustang (CII XML) es el patrón adecuado para pruebas de auditoría.

La forma de una factura electrónica de la UE, y por qué apila dos formatos

Una factura electrónica moderna en la UE contiene dos documentos dentro de un solo archivo:

  1. Un PDF/A-3 legible por una persona: número de factura, líneas, totales y marca del proveedor. La especificación PDF/A-3 (ISO 19005-3) es la única variante de PDF/A que permite adjuntos de archivo arbitrarios dentro del envoltorio de archivo.
  2. Un adjunto CII XML EN 16931 dentro de ese PDF: la misma factura expresada como datos estructurados que la automatización de cuentas por pagar, las importaciones ERP y los sistemas de autoridades fiscales pueden procesar sin OCR.

Factur-X (Francia) y ZUGFeRD (Alemania) son la misma idea con nombres nacionales distintos. Ambos adjuntan un XML Cross-Industry Invoice (CII) EN 16931 a un envoltorio PDF/A-3. ZUGFeRD es obligatorio para la recepción de facturas B2B alemanas desde 2025; Factur-X se está incorporando de forma gradual como formato obligatorio para la emisión B2B en Francia durante 2026-2027.

Si en 2026 envía facturas a clientes franceses o alemanes, uno de estos dos formatos deja de ser opcional.

Por qué generarlo desde cero duele, y por qué gPdf lo reduce a un endpoint

Montar todo esto desde cero implica:

  1. Generar los bytes PDF: composición, fuentes y maquetación.
  2. Generar por separado el CII XML, ajustado a EN 16931.
  3. Configurar correctamente el namespace XMP de PDF/A-3 (urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0# para Factur-X; el namespace de ZUGFeRD 2.x es distinto).
  4. Integrar el XML con AFRelationship="Alternative" según la especificación.
  5. Marcar correctamente el archivo integrado en el array /AF de PDF/A-3.
  6. Validar el resultado con veraPDF (capa PDF/A) Y Mustang (capa CII XML): ambos deben pasar.

Un equipo típico se equivoca dos veces antes de que el resultado pase en ambos motores. La API de gPdf concentra los seis pasos en una sola llamada POST /api/v1/e-invoice/render. Usted proporciona:

  • settings.e_invoice.standard: factur_x o zugferd
  • settings.e_invoice.xml.content: su CII XML
  • pages[]: la maquetación visible de la factura
  • todo lo demás se emite automáticamente con los metadatos PDF/A-3 correctos.

Consulte el §5 de la referencia de E-Invoice API para ver el esquema completo de la solicitud, los modos de validación (basic frente a strict) y el ciclo de vida asíncrono de los trabajos en validación estricta.

Verificar la salida: el patrón de auditoría

Que un proveedor diga “sí, nuestro PDF pasa PDF/A-3” no vale de mucho si el auditor utiliza los motores de referencia. El patrón con nivel de auditoría es:

  1. Genere la factura electrónica mediante POST /api/v1/e-invoice/render.
  2. Suba el PDF resultante al validator, que ejecuta:
    • veraPDF: la implementación oficial de referencia mantenida por la PDF Association. Conformidad PDF/A-3.
    • Mustang: proyecto alemán open source (mustangproject.org) usado de facto como verificador de referencia para Factur-X / ZUGFeRD; extrae el CII XML integrado, lo valida contra EN 16931 Schematron y reporta campo por campo.
  3. Ambos informes vuelven lado a lado en la misma interfaz. Ambos deben mostrar “Pass” antes de enviarlo a la automatización de cuentas por pagar en producción.

Este patrón importa porque:

  • Un PDF que pasa veraPDF pero falla Mustang significa que el envoltorio es conforme, pero el XML interno está mal formado: el sistema de cuentas por pagar rechaza la factura al recibirla.
  • Un PDF que pasa Mustang pero falla veraPDF significa que el XML está bien, pero el envoltorio de archivo no cumple PDF/A-3: el archivo a largo plazo lo rechaza.
  • Cualquiera de los dos fallos rompe el flujo de extremo a extremo. Ambos deben pasar.

El validador es gratuito, no requiere inicio de sesión y produce informes JSON que puede adjuntar a sus evidencias de QA. Es el mismo patrón de doble motor que utilizan internamente las grandes firmas de auditoría; gPdf simplemente lo aloja de forma pública.

Más allá de Factur-X / ZUGFeRD

Si también trabaja con:

  • FatturaPA (Italia, obligatorio desde 2019): ya está en la hoja de ruta del validador.
  • Peppol BIS 3.0 UBL (países nórdicos / Benelux / cada vez más transfronterizo): hoja de ruta.
  • KSeF (Polonia, obligatorio en 2026): hoja de ruta.

El endpoint de factura electrónica de gPdf ampliará la cobertura a medida que cada formato pase de “hoja de ruta temprana” a “disponible en el validador y el renderizador”. La forma se mantiene: una solicitud JSON, el namespace XMP correcto y AFRelationship gestionados internamente, y ambos motores verificando antes de enviar a producción.

TL;DR

  • Una llamada API → PDF/A-3 + CII XML EN 16931 integrado.
  • Elija Factur-X o ZUGFeRD mediante settings.e_invoice.standard.
  • Verifique con el validator: veraPDF + Mustang en paralelo, gratis.
  • Ambos motores deben pasar. La API de gPdf está diseñada para que lo hagan; el validador es el comprobante público.

Seguir leyendo