PDFMonkey peut générer des factures électroniques : des documents PDF qui embarquent une version XML de la facture, structurée et exploitable par les machines, en plus de la mise en page visuelle. La première spécification prise en charge est Factur-X (aussi connue sous le nom de ZUGFeRD en Allemagne), la norme franco-allemande de facturation électronique hybride au cœur de la réforme française de la facturation électronique.

Vous gardez le contrôle total de l’apparence de la facture — c’est un modèle PDFMonkey classique — pendant que PDFMonkey se charge de produire et d’embarquer le XML conforme, avec une validation à chaque étape.

Qu’est-ce que Factur-X ?

Factur-X est un format de facture hybride : un PDF que vous pouvez lire, imprimer et archiver, avec un fichier factur-x.xml embarqué que les logiciels comptables et les plateformes gouvernementales peuvent traiter automatiquement. Le résultat est un fichier PDF/A-3 unique qui convient aussi bien aux humains qu’aux machines.

Fonctionnement #

Vous appliquez une norme de conformité à votre modèle (par exemple Factur-X 1.08 EN 16931 (FR-CTC Flux 2)).
Lors de la génération d’un document, vous envoyez vos données de facturation dans le payload du document, en suivant la structure définie par la norme.
PDFMonkey valide vos données par rapport à la structure et aux règles métier de la norme (les totaux doivent être cohérents, la ventilation de TVA doit correspondre, etc.).
PDFMonkey génère le PDF à partir de votre modèle comme d’habitude, produit le XML à partir de votre payload et l’embarque dans le fichier PDF/A-3 final.
Le document généré est une facture hybride conforme, prête à être envoyée à vos clients ou à une plateforme de facturation électronique.

Aucune connaissance du XML n’est requise — vous ne manipulez que du JSON, comme pour n’importe quel document PDFMonkey.

Étape 1 : appliquer une norme de conformité à votre modèle #

Ouvrez votre modèle dans l’éditeur de modèles.
Ouvrez le panneau Réglages, disponible côté code comme côté Builder visuel.
Dans la section Norme de conformité, choisissez une norme dans la liste — par exemple Factur-X 1.08 EN 16931 (FR-CTC Flux 2).
Confirmez le changement.
Cliquez sur Publier. Les documents sont générés à partir de la version publiée du modèle : la norme ne s’applique donc aux nouveaux documents qu’une fois celui-ci publié.

Indisponible sur l’offre Free

La facturation électronique fonctionne sur toutes les offres sauf Free, l’essai de 30 jours compris. Sur l’offre Free, la génération des documents issus d’un modèle portant une norme de conformité échoue, avec le message d’erreur suivant : Generating Factur-X compliant documents requires a paid plan. Si la section Norme de conformité n’apparaît pas du tout, c’est que la facturation électronique n’est pas encore activée sur votre compte — contactez le support pour la faire activer.

Remplacement des données de test

Appliquer une norme de conformité remplace les Données de test actuelles de votre modèle par un exemple de payload conforme à la norme sélectionnée. Une fois le modèle publié, les anciennes données de test sont perdues : pensez à les copier au préalable si vous souhaitez les conserver. Avant publication, le bouton Annuler les restaure, mais annule aussi toutes les autres modifications non publiées.

L’exemple de payload présente la structure de données complète attendue par la norme : identification de la facture, informations vendeur et acheteur, lignes de facturation, ventilation de TVA et totaux. Servez-vous-en comme référence pour construire votre intégration.

Pour retirer une norme, cliquez sur Supprimer la norme dans la même section, puis publiez le modèle. Vos données de test personnalisées sont conservées.

Étape 2 : concevoir votre modèle #

Une fois la norme appliquée, concevez la partie visuelle de la facture comme pour n’importe quel modèle, en utilisant les champs des données de test dans votre code Liquid ou vos liaisons Builder.

Pour vérifier le XML qui sera embarqué, ouvrez le menu Debug dans la barre de navigation de l’éditeur de modèles et sélectionnez Inspecter le XML généré. Vous verrez le XML produit à partir de vos données de test actuelles — pratique pour valider le résultat avant la mise en production.

Étape 3 : générer des documents #

Générez vos documents exactement comme d’habitude — via l’API, le tableau de bord ou une intégration. La seule différence : votre payload doit suivre la structure de données de la norme de conformité.

Voici un payload Factur-X EN 16931 minimal :

{
  "invoiceNumber": "INV-2026-0042",
  "invoiceType": "invoice",
  "issueDate": "20260215",
  "currency": "EUR",
  "notes": [
    {
      "type": "recovery_fees",
      "content": "Indemnité forfaitaire pour frais de recouvrement : 40 EUR."
    },
    {
      "type": "late_payment_penalties",
      "content": "Pénalités de retard : 3 fois le taux d'intérêt légal."
    },
    {
      "type": "early_payment_discount",
      "content": "Pas d'escompte pour paiement anticipé."
    }
  ],
  "seller": {
    "name": "EvilMonkeys SAS",
    "legalId": "892456123",
    "legalIdScheme": "siren",
    "vatId": "FR12892456123",
    "email": "billing@evilmonkeys.io",
    "address": {
      "line1": "42 rue de la Documentation",
      "city": "Paris",
      "postCode": "75011",
      "country": "FR"
    }
  },
  "buyer": {
    "name": "TechCorp SARL",
    "email": "invoices@techcorp.fr",
    "address": {
      "line1": "8 avenue des Intégrations",
      "city": "Lyon",
      "postCode": "69002",
      "country": "FR"
    }
  },
  "lineItems": [
    {
      "lineNumber": "1",
      "name": "PDF Generation API - Enterprise Plan",
      "quantity": 1,
      "unitPrice": 2500.0,
      "vatCategory": "standard",
      "vatRate": 20,
      "total": 2500.0
    }
  ],
  "taxBreakdowns": [
    {
      "category": "standard",
      "rate": 20,
      "basisAmount": 2500.0,
      "taxAmount": 500.0
    }
  ],
  "paymentMeans": {
    "typeCode": "58",
    "iban": "FR7630006000011234567890189"
  },
  "paymentTerms": {
    "description": "Net 30",
    "dueDate": "20260317"
  },
  "totals": {
    "lineTotal": 2500.0,
    "taxBasisTotal": 2500.0,
    "taxTotal": 500.0,
    "grandTotal": 3000.0,
    "duePayable": 3000.0
  }
}

Presque tous les champs ci-dessus sont obligatoires : retirez-en un et le document est rejeté. Font exception seller.legalIdScheme, facultatif mais recommandé pour que le SIREN soit accompagné de son schéma, et paymentTerms, qui n’a besoin que de description ou de dueDate. Plusieurs des champs obligatoires sont là parce que le vendeur est français : un vendeur français doit indiquer son SIREN à 9 chiffres dans seller.legalId, une adresse électronique pour lui-même, une autre pour son acheteur, ainsi que les trois mentions légales obligatoires (pénalités de retard, frais de recouvrement, escompte pour paiement anticipé). Les vendeurs établis ailleurs ne sont pas soumis à ces règles et peuvent envoyer un payload plus court.

La structure complète — champs optionnels, énumérations, exigences conditionnelles — est documentée dans l’exemple de données de test appliqué à votre modèle lors de la sélection de la norme.

Un payload, deux sorties

Le même payload alimente à la fois le PDF visuel (via votre modèle) et le XML embarqué (via la norme de conformité). Vous envoyez vos données de facturation une seule fois ; PDFMonkey garantit la cohérence des deux représentations.

Validation #

PDFMonkey valide vos données en plusieurs couches, à deux moments distincts.

À la création du document, le payload est vérifié par rapport à la norme :

Structure — le payload doit contenir les champs requis avec les bons types et formats (dates, codes pays, codes devise, etc.).
Règles métier — les règles sémantiques de la spécification sont appliquées : les totaux de ligne doivent correspondre à la quantité × le prix unitaire, la ventilation de TVA doit être cohérente avec les totaux, les exonérations de TVA doivent être justifiées, etc. Pour les vendeurs français, les règles supplémentaires de la réforme française de la facturation électronique sont également vérifiées.

Si l’un de ces contrôles échoue, le document n’est pas créé : l’API répond 422 Unprocessable Entity et liste les problèmes sous errors.payload, en nommant le champ fautif ou, pour une règle métier, son code officiel. Corrigez le payload et renvoyez-le.

Pendant la génération, deux contrôles supplémentaires s’exécutent :

Conformité XML — le XML généré est vérifié par rapport au schéma officiel de la spécification.
Conformité de l’embarquement — après l’embarquement, le PDF final est vérifié pour garantir une facture hybride correcte (structure PDF/A-3, métadonnées de la pièce jointe).

Si l’un d’eux échoue, le document passe au statut failure, avec un failure_cause qui en explique la raison. Vous le récupérez comme n’importe quel échec de génération : dans le tableau de bord, via l’API ou via les webhooks d’échec.

Rien n’est passé sous silence : sauf si vous désactivez explicitement le contrôle final d’embarquement, un document généré avec succès est un document valide.

Consulter le résultat de la validation #

Après l’embarquement, PDFMonkey écrit le résultat du contrôle final de conformité dans les métadonnées du document, sous la clé _facturx_validation — que le contrôle ait réussi ou non. Vous pouvez le consulter via l’API ou dans l’onglet Meta-données de l’éditeur de documents :

{
  "_facturx_validation": {
    "conforms": true,
    "profile": "EN 16931",
    "failures": [],
    "verified_at": "2026-06-04T10:30:45Z"
  }
}

Champ	Type	Signification
`conforms`	Booléen	`true` lorsque tous les contrôles structurels ont réussi.
`profile`	Chaîne ou `null`	Profil détecté dans les métadonnées embarquées : `MINIMUM`, `BASIC WL`, `BASIC`, `EN 16931`, `EXTENDED` ou `XRECHNUNG`. `null` si les métadonnées n’ont pas pu être lues.
`failures`	Tableau	Vide lorsque `conforms` vaut `true`. Chaque entrée contient un `code` exploitable par les machines (par exemple `missing_attachment`), un `message` lisible et un objet `details`.
`verified_at`	Horodatage ISO 8601	Date et heure du contrôle.

Utilisez-le comme piste d’audit : chaque facture générée embarque la preuve de son propre contrôle de conformité.

Un contrôle d’embarquement en échec fait normalement échouer tout le document. Si vous voulez malgré tout récupérer le fichier (pour inspecter le résultat, ou parce que vous contestez le verdict), passez _facturx_ignore_invalid_embedding à true dans les métadonnées du document. Le contrôle s’exécute toujours et _facturx_validation enregistre toujours les échecs ; seule l’erreur bloquante est supprimée. Le fichier obtenu n’est pas une facture Factur-X conforme : ne l’envoyez pas à une plateforme de facturation électronique.

Résultat #

Le document généré est un fichier PDF/A-3 avec le XML de la facture embarqué sous le nom factur-x.xml. Il se comporte comme n’importe quel document PDFMonkey : même URL de téléchargement, mêmes webhooks, même prise en charge du nom de fichier personnalisé.

Les destinataires peuvent :

Le lire comme un PDF classique.
Le traiter automatiquement avec tout logiciel compatible Factur-X / ZUGFeRD, qui extrait le XML embarqué.

Normes prises en charge #

Format	Profil	Version
Factur-X	EN 16931	1.08 (compatible ZUGFeRD 2.4)

Factur-X est la première spécification prise en charge. La prise en charge d’autres formats et profils s’étoffera au fil du temps — le fonctionnement décrit sur cette page (appliquer une norme de conformité, envoyer un payload conforme) restera le même.

Questions fréquentes #

Dois-je écrire du XML ?

Non. Vous envoyez du JSON, comme pour tout document PDFMonkey. Le XML est généré et embarqué automatiquement selon la norme de conformité appliquée à votre modèle.

Puis-je utiliser un modèle existant ?

Oui. Appliquez-lui une norme de conformité dans les réglages de l’éditeur de modèles, puis publiez-le. Gardez à l’esprit que vos données de test seront remplacées par un exemple conforme à la norme, et que vos payloads de génération devront suivre la structure de la norme.

Que se passe-t-il si mes données de facturation sont invalides ?

Les problèmes de structure et de règles métier sont détectés à la création du document : l’API renvoie 422 Unprocessable Entity avec le champ fautif ou le code de la règle, et aucun document n’est créé. Les problèmes détectés plus tard, lors de la génération du XML ou de l’embarquement, font passer le document au statut failure. Dans les deux cas, corrigez le payload et renvoyez-le.

Le résultat est-il vraiment conforme ?

Oui. Le XML est validé par rapport au schéma officiel et aux règles métier de la spécification, et le PDF final est vérifié après embarquement pour garantir une facture hybride PDF/A-3 structurellement correcte.

Le contrôle de conformité s’exécute-t-il sur chaque document généré ?

Non. Il ne s’exécute que sur les documents qui embarquent effectivement une facture XML. Les PDF classiques l’ignorent entièrement, et aucune métadonnée _facturx_validation n’est écrite.

Est-ce compatible avec les formats de sortie image ?

Non. La facturation électronique nécessite une sortie PDF, puisque le XML est embarqué dans le fichier PDF lui-même.

Pages associées #

Générer des PDF via l’API — le flux de génération de bout en bout
Webhooks — être notifié du succès ou de l’échec d’une génération
Statuts des documents — comprendre le cycle de vie de la génération
Nom de fichier personnalisé — contrôler le nom du fichier généré

Générer des factures électroniques Factur-X