Facture électronique ZUGFeRD à partir d'une liste SharePoint : Convertissez un fichier JSON en XML EN 16931 et en PDF/A-3 dans Power Automate avec PDF4me

PDF4me Create ZUGFeRD Invoice est une action Power Automate qui transforme les données de facturation en une facture électronique hybride PDF/A-3. Associée à une liste SharePoint, elle utilise le JSON généré par une action Compose à partir de chaque ligne, écrit le XML EN 16931, intègre la facture lisible dans le PDF de base, archive le document et l'envoie par e-mail à l'acheteur.
Recherchez ZUGFeRD et vous trouverez trois solutions : une explication du format, un validateur vérifiant la conformité d'un fichier existant, ou une bibliothèque PHP, Java ou C# pour les développeurs de logiciels de facturation. Ces trois solutions supposent que la facture existe déjà. Or, aucune ne répond à la question que se pose réellement une équipe financière : les données de facturation se trouvent dans une liste, un tableur ou tout autre système enregistrant les ventes, et doivent être converties en facture électronique conforme. Ce processus, en sept étapes et sans code, représente l'étape manquante.
Une entrée est ajoutée à une liste SharePoint avec le vendeur, l'acheteur, un article et les dates. Quatre secondes plus tard, une facture PDF/A-3 est disponible dans une bibliothèque de documents : une page lisible, intégrant le code XML EN 16931 pour le traitement par le logiciel de l'acheteur. Vous n'avez pas à écrire ce code XML. Vous décrivez la facture comme un court objet JSON et PDF4me génère le schéma. L'entrée reçoit son statut et un lien, et l'acheteur reçoit le fichier par e-mail.
Questions et réponses basées sur le pourquoi
Pourquoi conserver les données de facturation dans une liste SharePoint ? Parce que c’est le format sous lequel les données sont déjà enregistrées pour la plupart des petites équipes financières : une ligne par facture, renseignée par une personne. Les colonnes correspondent exactement aux champs requis par la norme, ce qui signifie que cette correspondance est visible par tous ceux qui consultent la liste. De plus, une nouvelle facture correspond à une nouvelle ligne et non à un nouveau fichier dans un dossier surveillé.
Pourquoi décrire la facture au format JSON plutôt qu'en XML ? Parce que la syntaxe Cross Industry Invoice est verbeuse et contraignante : espaces de noms imbriqués, noms d'éléments difficiles à retenir, codes devant être placés au bon endroit. L'objet JSON exprime la même information en beaucoup moins de lignes, avec des clés dont le sens correspond aux termes métier qu'elles représentent. PDF4me le convertit en schéma ; ainsi, la partie la plus sujette aux erreurs est celle que vous n'avez pas à gérer.
Pourquoi générer la facture sur un PDF ? Parce qu'un fichier ZUGFeRD comporte deux parties qui doivent être cohérentes. Le fichier XML est destiné au logiciel de l'acheteur, tandis que la page imprimée est destinée à la personne qui l'ouvre. L' Render Invoice on PDF intègre la facture à la page de base à partir des mêmes données qui ont généré le fichier XML. Ainsi, les deux ne peuvent jamais diverger, contrairement à ce qui se produit lorsque la mise en page est gérée séparément.
Pourquoi PDF/A-3 et non un PDF classique ? Parce que PDF/A-3 est un format d’archivage autorisé à inclure une pièce jointe, et le fichier XML intégré constitue cette pièce jointe. C’est également ce qui garantit la lisibilité de la facture des années plus tard : les polices et les profils colorimétriques sont conservés dans le fichier, ce qui est essentiel pour un document que la plupart des entreprises sont tenues de conserver pendant une dizaine d’années.
Ce que vous obtiendrez
Entrée : une ligne contenant le numéro de facture, les dates, la devise, le nom du vendeur, le nom de l’acheteur et un article. Sortie : une facture ZUGFeRD PDF/A-3 dans la bibliothèque ZUGFeRD Invoices, la ligne mise à jour avec son statut et un lien, et un courriel envoyé à l’acheteur avec la facture en pièce jointe.

Une ligne par facture. Chaque colonne de ce volet devient une clé dans le JSON généré par le flux.

Un fichier par numéro de facture, établi par le compte de flux.

La moitié lisible du même fichier, telle que l'acheteur la voit.
Ce dont vous avez besoin
- Power Automate. Ouvrez Power Automate. Un flux cloud automatisé sur des connecteurs standard. SharePoint, Office 365 Outlook et PDF4me ne nécessitent aucun abonnement premium.
- Clé API PDF4me. Obtenez votre clé API. Ce flux utilise une connexion PDF4me, PDF4me PDF.
- Une liste SharePoint pour les demandes. La liste capturée s'appelle ZUGFeRD Requests et contient les champs suivants : InvoiceNumber, InvoiceDate, DueDate, Currency, le bloc Seller (nom, rue, code postal, ville, pays, ID de TVA), le bloc Buyer, ItemDescription, Quantity, UnitPrice, VATRate, une colonne Email, une colonne Status et une colonne OutputLink dans laquelle le flux écrit.
- Un modèle de facture au format PDF. Le flux de travail enregistré conserve
BaseInvoice.pdfdans une bibliothèque appelée ZUGFeRD Templates. C'est sur cette page que la facture est établie ; votre en-tête doit donc y figurer. - Une bibliothèque pour les factures finalisées. Le flux capturé écrit dans ZUGFeRD Invoices.
- Vos informations de vendeur, y compris votre ID de TVA, sont saisies dans les colonnes de la liste, ce qui permet à un même processus d'émettre des factures pour plusieurs entités juridiques.
Aperçu du flux
- When an item is created (SharePoint) surveille la liste nommée
ZUGFeRD Requests. - Compose génère le JSON de la facture à partir de la ligne.
- Get file content using path d'accès
/ZUGFeRD Templates/BaseInvoice.pdf. - Create ZUGFeRD Invoice (PDF4me PDF) convertit le JSON en XML EN 16931 et renvoie le PDF hybride.
- Create file (SharePoint) l'enregistre sous le nom
ZUGFeRD_<invoice number>.pdf. - Update item (SharePoint) définit Status sur
Generatedet remplit OutputLink. - Send an email (V2) (Office 365 Outlook) envoie la facture à l'acheteur.
Aperçu complet du flux

Le processus complet prend environ quatre secondes, et la facture électronique elle-même environ une seconde. L'étape la plus lente est l'écriture du fichier par SharePoint.
Étape 1 : Comment déclencher l’émission d’une facture électronique lorsqu’une demande arrive ?
Déroulement jusqu'à présent : rien pour l'instant, ceci est le déclencheur.
L'ajout d'une ligne correspond à la manière dont une facture est demandée ; c'est donc le signal.
- Créez un Automated cloud flow et sélectionnez SharePoint > When an item is created.
- Configurer :
- Site Address:
PDF4me Support - https://ynoox1.sharepoint.com/sites/PDF4meSupport - List Name:
ZUGFeRD Requests
- Site Address:
When an item is created : configuration

Chaque colonne de la nouvelle ligne devient un jeton que les six actions suivantes peuvent utiliser.
Étape 2 : Comment construire le JSON de la facture à partir des colonnes de la liste ?
Déroulement jusqu'à présent : le déclencheur SharePoint.
Une seule action Compose suffit pour décrire la facture complète. C'est là que les noms de vos colonnes correspondent aux normes attendues, et le texte est suffisamment court pour être lu sur un seul écran.
- Ajouter Data Operation > Compose.
- Collez l'objet ci-dessous dans le champ Inputs et remplacez chaque valeur par le jeton correspondant.
{
"InvoiceId": "@{triggerBody()?['InvoiceNumber']}",
"TypeCode": "380",
"InvoiceType": "RECHNUNG",
"IssueDate": "@{triggerBody()?['InvoiceDate']}T00:00:00",
"DeliveryDate": "@{triggerBody()?['InvoiceDate']}T00:00:00",
"IsTest": false,
"Seller": {
"Name": "@{triggerBody()?['SellerName']}",
"VatId": "@{triggerBody()?['SellerVATID']}",
"Address": {
"Street": "@{triggerBody()?['SellerStreet']}",
"PostalCode": "@{triggerBody()?['SellerPostalCode']}",
"City": "@{triggerBody()?['SellerCity']}",
"Country": "@{triggerBody()?['SellerCountry']}"
}
},
"Buyer": {
"Name": "@{triggerBody()?['BuyerName']}",
"Address": {
"Street": "@{triggerBody()?['BuyerStreet']}",
"PostalCode": "@{triggerBody()?['BuyerPostalCode']}",
"City": "@{triggerBody()?['BuyerCity']}",
"Country": "@{triggerBody()?['BuyerCountry']}"
}
},
"LineItems": [
{
"ProductName": "@{triggerBody()?['ItemDescription']}",
"Quantity": @{triggerBody()?['Quantity']},
"UnitCode": "C62",
"UnitPrice": @{triggerBody()?['UnitPrice']},
"LineTotal": @{float(...)}
}
],
"Totals": {
"Currency": "@{triggerBody()?['Currency']?['Value']}",
"LineTotal": @{float(...)},
"TaxBasisTotal": @{float(...)},
"TaxPercent": @{triggerBody()?['VATRate']},
"TaxTotal": @{float(...)},
"GrandTotal": @{float(...)},
"ChargeTotal": 0,
"AllowanceTotal": 0
},
"Payment": {
"Currency": "@{triggerBody()?['Currency']?['Value']}",
"PaymentReference": "@{triggerBody()?['InvoiceNumber']}",
"DueDate": "@{triggerBody()?['DueDate']}T00:00:00"
}
}
Compose : configuration

Les valeurs textuelles sont des jetons entre guillemets. Les montants et les quantités sont des nombres bruts, c'est pourquoi ils sont convertis en nombres à virgule float.
D'où provient chaque partie de la facture
| Clé JSON | Ce qu'il contient | Source |
|---|---|---|
InvoiceId, TypeCode, InvoiceType | Numéro de facture, code de type de document 380 pour une facture commerciale et étiquette imprimée sur la page | InvoiceNumber, puis valeurs fixes |
IssueDate, DeliveryDate | Quand la facture a été émise et quand le service a été rendu | InvoiceDate, suffixée par T00:00:00 |
Seller | Nom, ID de TVA et bloc d'adresse complète | SellerName, SellerVATID, SellerStreet, SellerPostalCode, SellerCity, SellerCountry |
Buyer | Nom et adresse du client | BuyerName, BuyerStreet, BuyerPostalCode, BuyerCity, BuyerCountry |
LineItems | Description, quantité avec code unité C62, prix unitaire et total de la ligne | ItemDescription, Quantité, UnitPrice |
Totals | Devise, total net, base d'imposition, taux et montant de la TVA, total général | Devise, VATRate et montants calculés |
Payment | Devise, référence fournie par l'acheteur lors du paiement et date d'échéance | Devise, InvoiceNumber, DueDate |
Conseil : Seules les clés monétaires nécessitent des calculs, et elles doivent être converties en nombres simples, sans guillemets (c’est le rôle des expressions float). LineTotal correspond à la quantité multipliée par le prix unitaire, TaxBasisTotal à la somme des totaux de ligne, TaxTotal au produit de la base de taxe par le taux, divisé par 100, et GrandTotal à la somme de ces deux résultats. Pour la ligne affichée, ces valeurs sont : 1005, 1005, 190,95 et 1195,95. La valeur "1005" entre guillemets sera refusée, tandis que la valeur 1005 seule sera acceptée.
Étape 3 : D’où provient le PDF de base ?
Déroulement jusqu'à présent : le déclencheur plus Compose.
Les fichiers ZUGFeRD possèdent une page lisible, et c'est là que ça commence.
- Ajouter SharePoint > Get file content using path.
- Configurer :
- Site Address:
PDF4me Support - https://ynoox1.sharepoint.com/sites/PDF4meSupport - File Path:
/ZUGFeRD Templates/BaseInvoice.pdf - Infer content type (avancé) :
Yes
- Site Address:
Get file content using path : configuration

Conservez votre papier à en-tête dans ce dossier. Il est vérifié à chaque impression ; toute modification entraînera donc une modification de la facture suivante.
Étape 4 : Comment transformer le JSON en un PDF/A-3 ZUGFeRD ?
Déroulement jusqu'à présent : le déclencheur, Compose et Get file content using path.
Cette action génère la facture électronique. Elle lit le JSON, écrit le XML EN 16931 et renvoie un fichier unique contenant les deux parties.
- Ajouter Create ZUGFeRD Invoice à partir de la connexion PDF4me PDF.
- Configurer :
- ZUGFeRD version and Input Format:
2.0-JSON - Output Mode:
XmlWithPdf - Invoice JSON Data : l'expression
base64(outputs('Compose')) - Conformance Level:
EN16931 - Render Invoice on PDF:
Yes - File Content : une expression
base64()sur le contenu Get file content using path - File Name:
BaseInvoice.pdf
- ZUGFeRD version and Input Format:
Create ZUGFeRD Invoice : configuration

Le format d'entrée détermine le champ de données affiché. Sélectionnez 2.0-JSON et l'action demandera Invoice JSON Data, et non Invoice XML Data.
Ce que chaque paramètre détermine
| Champ | Valeur ici | Ce qu'il contrôle |
|---|---|---|
| ZUGFeRD version and Input Format | 2.0-JSON | La génération ZUGFeRD utilisée pour la sortie, et le format des données (JSON), déterminent l'affichage du champ Invoice JSON Data |
| Output Mode | XmlWithPdf | Renvoyer un seul fichier hybride, le PDF avec le XML intégré, plutôt que le XML seul |
| Invoice JSON Data | base64(outputs('Compose')) | L'objet facture, encodé base64 lors de son importation |
| Conformance Level | EN16931 | Le profil auquel la facture prétend correspondre, et donc les clés que le JSON doit fournir |
| Render Invoice on PDF | Yes | Dessinez la facture lisible sur le PDF de base au lieu de laisser la page telle quelle |
| File Content, File Name | Le PDF de base | La page sur laquelle la facture est établie et le nom du destinataire du rapport d'action |
Conseil : L’action affiche Invoice XML Data, Invoice JSON Data ou Invoice CSV Data selon le format sélectionné dans la liste déroulante. Ne renseignez que le format correspondant à votre choix. Le fait de renseigner deux champs de données simultanément est la cause la plus fréquente d’échec de validation.
Étape 5 : Où la facture est-elle classée ?
Flux jusqu'à présent : tout passe par Create ZUGFeRD Invoice.
Le numéro de facture permet d'identifier le fichier, ce qui rend la bibliothèque consultable.
- Ajouter SharePoint > Create file.
- Configurer :
- Site Address:
PDF4me Support - https://ynoox1.sharepoint.com/sites/PDF4meSupport - Folder Path:
/ZUGFeRD Invoices - File Name :
ZUGFeRD_suivi du numéro InvoiceNumber et de l’extension.pdf - File Content : le jeton Body de Create ZUGFeRD Invoice
- Site Address:
Create file : configuration

Pour RE-2026-0007 cela écrit ZUGFeRD_RE-2026-0007.pdf.
Étape 6 : Comment enregistrez-vous le résultat sur la requête ?
Déroulement jusqu'à présent : tout passe par Create file.
La ligne qui demandait la facture devait également indiquer ce qu'il était advenu de celle-ci.
- Ajouter SharePoint > Update item.
- Configurer :
- Site Address:
PDF4me Support - https://ynoox1.sharepoint.com/sites/PDF4meSupport - List Name:
ZUGFeRD Requests - Id : le jeton ID du déclencheur
- Title : le jeton Title du déclencheur
- Status Value (avancée) :
Generated - OutputLink (avancé) : l’URL de la bibliothèque suivie de
ZUGFeRD_, du jeton InvoiceNumber et de.pdf
- Site Address:
Update item : configuration

Le lien est assemblé à partir de l'URL de la bibliothèque et du même modèle de nom utilisé Create file, l'espace dans le nom de la bibliothèque étant déjà encodé en %20.
Étape 7 : Comment envoyez-vous la facture à l'acheteur ?
Flux jusqu'à présent : tout passe par Update item.
Une facture électronique qui reste dans une bibliothèque n'a pas été émise ; la dernière action permet donc de la délivrer.
- Ajouter Office 365 Outlook > Send an email (V2).
- Configurer :
- À : le jeton Email du déclencheur
- Objet :
Your ZUGFeRD e-invoicesuivie du numéro InvoiceNumber - Body : une ligne indiquant le nom de l’acheteur et la facture, et précisant que le fichier est un PDF/A-3 avec XML EN 16931 intégré
- Ouvrez Advanced parameters et ajoutez la pièce jointe :
- Nom Attachments - 1 :
ZUGFeRD_suivi du numéro InvoiceNumber.pdf - Contenu Attachments - 1 : le jeton File Content issu de Create ZUGFeRD Invoice
- Importance:
Normal
- Nom Attachments - 1 :
Send an email (V2) : configuration

La pièce jointe tire ses octets de l'action qui les a produits, SharePoint n'est donc jamais relu.
Exécutez le flux et vérifiez
- Save le flux.
- Ajoutez une ligne aux ZUGFeRD Requests avec un acheteur, un seul article, les deux dates et une adresse vérifiable.
- Ouvrez l'historique d'exécution. Les sept actions devraient être validées (niveau vert) et l'exécution complète devrait prendre quelques secondes.
- Ouvrez la bibliothèque ZUGFeRD Invoices et vérifiez que le fichier s'y trouve sous le numéro de facture.
- Retournez à la ligne : Status doit indiquer Generated et OutputLink doit ouvrir la facture.
- Ouvrez la pièce jointe du courriel et vérifiez les deux parties : la page doit afficher les montants corrects et le fichier doit contenir le code XML.
L'exécution de la commande a duré environ quatre secondes, la facture électronique étant générée en une seule seconde. Le fichier résultant, ZUGFeRD_RE-2026-0007.pdf, pèse environ 331 Ko et se présente comme une facture allemande : vendeur : Muster GmbH (Berlin, ID de TVA : DE123456789 ; client Test Kunde AG (Muenchen, type de document : 380 ; ligne : Consulting, TVA : 19 %, montant net : 1 005,00 EUR, TVA : 190,95 EUR, total : 1 195,95 EUR.
Qu'avez-vous concrètement mis en place ? Un système de facturation électronique qui s'appuie sur vos propres données. Ces données restent stockées par le service financier, la norme est respectée grâce au XML que vous n'avez pas eu à écrire, l'acheteur reçoit un fichier que son logiciel peut lire automatiquement et que son personnel peut consulter à l'écran, et la ligne de facturation indique que la facturation a bien été émise.
Variantes courantes que vous pouvez ajouter sans reconstruction
Comment cela se compare-t-il aux autres méthodes de production d'une facture ZUGFeRD
Chaque ligne décrit l'alternative. La dernière ligne correspond à ce flux.
| Comparaison | Qui le dirige ? | D'où proviennent les données ? | Ce que vous entretenez |
|---|---|---|---|
| Logiciel de facturation avec exportation ZUGFeRD comparé à ce flux | N'importe qui, à l'intérieur de ce produit | les propres enregistrements du produit | Un abonnement, et tout ce que le produit prend en charge |
| Plateforme de facturation électronique et ce flux | La finance, via un portail | Téléchargements ou intégration | Un contrat par document et un lien avec celui-ci |
| Bibliothèque de développement par rapport à ce flux | Un développeur, à l'intérieur d'une application | Votre base de données, via le code | Le code, les mises à jour du schéma et les versions |
| Ce flux | Toute personne pouvant ajouter une ligne de liste | Une liste SharePoint que l'équipe conserve | Un objet JSON et un PDF de base |
Questions fréquentes
Qu'est-ce qu'une facture ZUGFeRD ?
Une facture ZUGFeRD est un fichier unique à double usage. Il s'agit d'un PDF classique, lisible et contenant une pièce jointe XML avec les mêmes données structurées. Le système comptable de l'acheteur lit le fichier XML et enregistre la facture automatiquement, tandis que le service comptabilité fournisseurs conserve une version papier.
Ce format provient de FeRD, le forum allemand pour la facturation électronique, et son équivalent français est Factur-X, qui repose sur le même principe sous un autre nom.
Qu'est-ce que le format ZUGFeRD ?
Techniquement, il s'agit d'un conteneur PDF/A-3 avec un fichier XML intégré au format Cross Industry Invoice, et un profil indiquant le niveau de complétude des données. Le profil utilisé ici est EN16931, qui correspond à la norme sémantique européenne pour la facturation électronique : l'ensemble des champs définis par EN 16931 comme constituant le cœur d'une facture.
Concrètement, pour une automatisation, le résultat est évalué sur la base du XML, et non de la page. Fournissez les données demandées par le profil et le fichier est validé ; améliorez l’esthétique de la page et rien ne change.
Comment créer une facture ZUGFeRD ?
Vous avez besoin de trois choses : les données de la facture sous une forme structurée, une page pour la partie humaine et un outil qui écrit le XML dans le PDF en tant que pièce jointe PDF/A-3.
Dans ce flux, les données proviennent d'une ligne SharePoint convertie en JSON, la page est BaseInvoice.pdf, et Create ZUGFeRD Invoice effectue la troisième étape avec Output Mode XmlWithPdf. Si vos données existent déjà au format XML Cross Industry Invoice ou sous forme de ligne CSV, inversez le format d'entrée et utilisez ce format. Le reste du flux demeure inchangé.
Quelle est la différence entre ZUGFeRD et XRechnung ?
Les deux formats répondent à la même norme européenne ; la différence réside dans leur présentation. ZUGFeRD est un format hybride : un PDF lisible contenant le code XML, adapté aux factures envoyées à des clients susceptibles de les ouvrir manuellement. XRechnung est exclusivement au format XML et correspond au format exigé par les acheteurs du secteur public allemand.
Si vous envoyez des factures à des entreprises, le format hybride est généralement plus sûr, car il est lisible par tous. Si vous facturez une administration publique, vérifiez le format requis avant l'envoi.
Dépannage
Ouvrez le résultat Compose dans l'historique d'exécution et lisez-le au format JSON avant toute autre chose. Une colonne vide laisse une clé vide, et une valeur monétaire dont les guillemets sont conservés est affichée sous forme de texte alors qu'un nombre est attendu. Dans les deux cas, l'objet produit semble correct, mais la conversion échoue.
Conformance Level détermine les champs requis par le profil. Si vous déclarez être conforme à la norme EN16931 alors que le fichier JSON omet des clés attendues par le profil, la validation échoue, même si le fichier s'ouvre correctement. Vous devez soit fournir les clés manquantes, soit utiliser un niveau de conformité inférieur.
Render Invoice on PDF étant désactivée, le code XML a été intégré sans affichage. Le fichier reste une facture électronique valide, mais les informations manquantes correspondent au contenu du PDF d'origine.
Vérifiez le contenu de la pièce jointe dans l'étape Courriel et le File Content dans Create file. Les deux doivent provenir de Create ZUGFeRD Invoice. Joindre le PDF de base envoie une page qui semble correcte, mais qui ne contient aucune information exploitable par leur logiciel.
Prochaines étapes
Le même schéma en sept étapes (une ligne arrive, une facture est décrite comme des données, un fichier est produit, classé, enregistré et envoyé) est ce que chaque mandat de facturation électronique exige réellement, quel que soit le format dont vos acheteurs finissent par avoir besoin.