gPdf
Use cases · Facturation électronique UE et finance

Factures électroniques UE : PDF/A-3 avec Factur-X / ZUGFeRD intégré

Générez des factures électroniques EN 16931 depuis JSON : enveloppe PDF/A-3 avec XML CII intégré, conforme Factur-X ou ZUGFeRD. Vérifiez les deux couches gratuitement sur gpdf.com/validator/.

Job to be done

Émettre des factures électroniques conformes aux exigences UE depuis un DocumentRequest JSON : une enveloppe PDF/A-3 lisible par une équipe de comptabilité fournisseurs, avec une pièce jointe XML CII intégrée conforme à EN 16931 qu'une autorité fiscale peut traiter automatiquement. Un seul appel API doit produire les deux couches, et les deux doivent être validées par des moteurs de référence, pas seulement par le vérificateur du fournisseur.

Why gPdf for this

  • POST /api/v1/e-invoice/render : un point d'entrée unique qui renvoie un PDF/A-3 Factur-X ou ZUGFeRD en un aller-retour.
  • Enveloppe PDF/A-3b émise automatiquement avec le bon espace de noms XMP, AFRelationship='Alternative' et les métadonnées de fichier intégré attendues par le socle Factur-X / ZUGFeRD.
  • XML CII EN 16931 joint comme données structurées canoniques, lisibles par les outils d'automatisation comptabilité fournisseurs dans l'UE.
  • Le mode validation stricte exécute les contrôles Schematron complets de façon asynchrone et renvoie un artefact de rapport avec le PDF.
  • Profils de résidence des données (`eu` / `global` / `auto`) pour que les équipes comptabilité fournisseurs/clients soumises au RGPD puissent conserver les artefacts de facture électronique dans des régions UE.
  • Le validateur public gratuit sur gpdf.com/validator/ exécute veraPDF (côté PDF/A) ET Mustang (côté XML CII / EN 16931) en parallèle : une vérification indépendante avant le passage en production.

Sample request

POST /api/v1/e-invoice/render : requête Factur-X minimale avec XML CII intégré.

{
  "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": [] }
  ]
}

Compliance and conformance

  • Factur-X 1.0 : spécification franco-allemande, obligatoire pour les factures B2B françaises à partir de 2026, avec déploiement progressif.
  • ZUGFeRD 2.x : spécification allemande conforme à EN 16931 ; obligatoire pour la réception de factures B2B allemandes depuis 2025.
  • EN 16931 : modèle sémantique paneuropéen de facture électronique que Factur-X et ZUGFeRD encapsulent.
  • PDF/A-3 : format d'enveloppe d'archivage requis pour contenir légalement une pièce jointe XML intégrée (ISO 19005-3).
  • Validation : ne vous fiez pas à l'auto-contrôle d'un seul fournisseur. La vérification indépendante avec veraPDF (PDF/A) + Mustang (XML CII) est le modèle adapté aux preuves d'audit.

La forme d’une facture électronique UE, et pourquoi deux formats sont empilés

Une facture électronique UE moderne regroupe deux documents dans un seul fichier :

  1. Un PDF/A-3 lisible par un humain : numéro de facture, lignes, totaux, marque du fournisseur. La spécification PDF/A-3 (ISO 19005-3) est la seule variante PDF/A qui autorise des pièces jointes arbitraires dans l’enveloppe d’archivage.
  2. Une pièce jointe XML CII EN 16931 dans ce PDF : la même facture sous forme de données structurées, que l’automatisation comptabilité fournisseurs, les imports ERP et les systèmes d’autorités fiscales peuvent analyser sans OCR.

Factur-X (France) et ZUGFeRD (Allemagne) suivent la même idée, avec des libellés nationaux différents. Les deux attachent un XML Cross-Industry Invoice (CII) EN 16931 à une enveloppe PDF/A-3. ZUGFeRD est obligatoire pour la réception de factures B2B allemandes depuis 2025 ; Factur-X entre progressivement dans l’obligation d’émission B2B en France sur 2026-2027.

Si vous envoyez des factures à des clients français ou allemands en 2026, l’un de ces deux formats n’est plus optionnel.

Pourquoi le produire de zéro est pénible, et pourquoi gPdf en fait un point d’entrée

Assembler cela depuis zéro implique :

  1. Générer les octets PDF : composition, polices, mise en page.
  2. Générer séparément le XML CII, en respectant EN 16931.
  3. Définir correctement l’espace de noms XMP PDF/A-3 (urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0# pour Factur-X ; l’espace de noms ZUGFeRD 2.x diffère).
  4. Intégrer le XML avec AFRelationship="Alternative" conformément à la spécification.
  5. Marquer correctement le fichier intégré dans le tableau /AF de PDF/A-3.
  6. Valider le résultat avec veraPDF (côté PDF/A) ET Mustang (côté XML CII) : les deux doivent passer.

Une équipe type se trompe deux fois avant que les deux moteurs valident. L’API gPdf ramène ces six étapes à un seul appel POST /api/v1/e-invoice/render. Vous fournissez :

  • settings.e_invoice.standard : factur_x ou zugferd
  • settings.e_invoice.xml.content : votre XML CII
  • pages[] : la mise en page visible de la facture
  • le reste est émis automatiquement avec les bonnes métadonnées PDF/A-3.

Consultez le §5 de la référence E-Invoice API pour le schéma complet de requête, les modes de validation (basic vs strict) et le cycle de vie asynchrone des jobs en validation stricte.

Vérifier la sortie : le modèle de preuve d’audit

Un fournisseur qui dit “oui, notre PDF passe PDF/A-3” ne vaut rien si l’auditeur utilise les moteurs de référence. Le modèle adapté aux preuves d’audit est le suivant :

  1. Générez la facture électronique via POST /api/v1/e-invoice/render.
  2. Déposez le PDF obtenu dans le validator, qui exécute :
    • veraPDF : l’implémentation de référence officielle maintenue par la PDF Association, pour la conformité PDF/A-3.
    • Mustang : projet allemand open source (mustangproject.org) utilisé de facto comme vérificateur de référence Factur-X / ZUGFeRD ; il extrait le XML CII intégré, valide avec Schematron contre EN 16931 et remonte les résultats champ par champ.
  3. Les deux rapports reviennent côte à côte dans la même interface. Les deux doivent afficher “Pass” avant l’envoi en production vers l’automatisation comptabilité fournisseurs.

Ce modèle compte parce que :

  • Un PDF qui passe veraPDF mais échoue Mustang signifie que l’enveloppe est conforme, mais que le XML interne est mal formé : le système de comptabilité fournisseurs rejette la facture à la réception.
  • Un PDF qui passe Mustang mais échoue veraPDF signifie que le XML est correct, mais que l’enveloppe d’archivage ne satisfait pas PDF/A-3 : l’archivage long terme est rejeté.
  • L’un ou l’autre échec casse le flux de bout en bout. Les deux doivent passer.

Le validateur est gratuit, sans connexion, et produit des rapports JSON que vous pouvez joindre à vos preuves QA. C’est le même modèle à deux moteurs que les grands cabinets d’audit utilisent en interne ; gPdf l’héberge simplement publiquement.

Au-delà de Factur-X / ZUGFeRD

Si vous travaillez aussi avec :

  • FatturaPA (Italie, obligatoire depuis 2019) : déjà sur la feuille de route du validateur.
  • Peppol BIS 3.0 UBL (Nordiques / Benelux / de plus en plus transfrontalier) : feuille de route.
  • KSeF (Pologne, obligatoire en 2026) : feuille de route.

Le point d’entrée de facture électronique gPdf étendra sa couverture à mesure que chaque format passera de “phase initiale de feuille de route” à “disponible dans le validateur et le moteur de rendu”. La forme reste la même : une requête JSON, le bon espace de noms XMP et AFRelationship pris en charge en interne, puis les deux moteurs vérifient avant l’envoi.

TL;DR

  • Un appel API → PDF/A-3 + XML CII EN 16931 intégré.
  • Choisissez Factur-X ou ZUGFeRD via settings.e_invoice.standard.
  • Vérifiez avec le validator : veraPDF + Mustang en parallèle, gratuitement.
  • Les deux moteurs doivent passer. L’API gPdf est conçue pour cela ; le validateur en fournit le reçu public.

Keep reading