Outil · Bureau

Convertir une facture électronique

Factur-X, UBL ou CII : l’outil lit votre facture électronique, l’écrit dans le format voulu, demande ce qui manque éventuellement et valide le résultat avec les règles officielles. Ce qui ne peut pas être repris, il vous le dit point par point. Votre facture ne quitte pas votre navigateur.

Quand une conversion est utile

Les trois formats du socle de la réforme française – UBL, CII et Factur-X – décrivent la même facture selon la norme européenne EN 16931, avec deux syntaxes XML : UBL (OASIS) et CII (UN/CEFACT). Factur-X est un PDF dans lequel est intégré un XML CII. Chaque logiciel ou plateforme n’accepte pas forcément les trois. Cas typiques :

Vous avez un factur-x.xml mais pas de PDF, par exemple exporté d’un logiciel ou extrait d’une facture. L’outil en fait un PDF Factur-X complet, avec une présentation lisible.
Votre logiciel produit du CII, un destinataire veut de l’UBL – ou l’inverse. Le contenu est le même, seule l’écriture change.
Vous recevez une facture UBL et voulez une Factur-X pour l’archiver ou la lire avec un logiciel qui n’accepte que Factur-X.
Un client allemand exige une XRechnung, le format des administrations allemandes. L’outil demande alors les données que XRechnung impose en plus.

Pour simplement lire ou valider une facture, la visionneuse Factur-X suffit.

Comment ça marche

Déposer le fichier : XML ou PDF Factur-X. L’outil affiche ce qu’il a lu : format, numéro, date, vendeur, acheteur, net à payer.
Choisir le format cible : Factur-X profil EN 16931 (PDF ou XML seul), UBL selon EN 16931, ou XRechnung 3.0 en UBL ou en CII.
Compléter si nécessaire. Seule XRechnung exige des données supplémentaires. L’outil ne remplit jamais de lui-même une donnée qui n’est pas dans la facture.
Convertir et valider. Le nouveau fichier passe le schéma XML puis les règles de gestion. Vous ne pouvez l’enregistrer que s’il ne reste aucune erreur.

Ce qui se passe pendant la conversion

La norme EN 16931 décrit une facture comme une liste de termes fixes : BT-1 est le numéro de facture, BT-112 le montant TTC, BG-25 une ligne de facture. Pour UBL et pour CII, la norme indique à quel endroit du XML se trouve chaque terme. L’outil lit votre facture terme par terme dans ce modèle commun, puis l’écrit dans l’autre syntaxe. Montants, quantités et textes sont repris caractère par caractère ; rien n’est recalculé.

L’outil garde la trace de chaque élément lu. S’il en reste un, c’est qu’il ne fait pas partie de la norme EN 16931 – et aucun format cible ne peut le reprendre. Ces données sont listées une par une au lieu d’être supprimées en silence. C’est typiquement le cas d’éléments du profil Factur-X EXTENDED.

Les deux syntaxes diffèrent à quelques endroits, et l’outil vous le signale :

CII n’accepte qu’une référence à une facture antérieure (BT-25), UBL plusieurs.
UBL exige le montant total de la TVA (BT-110) et, quand un prix brut est indiqué, la remise sur le prix (BT-147). S’ils manquent dans une facture CII, l’outil les déduit des montants de TVA ou du prix brut moins le prix net, et l’indique dans la liste des changements.
En UBL, la référence de paiement et le mandat de prélèvement sont rattachés au moyen de paiement. Sans moyen de paiement, ils ne sont pas repris.
Les frais logistiques du profil EXTENDED y comptent parmi les frais au niveau du document. L’outil les reprend comme tels (BG-21) et vous le dit.

Convertir, c’est réécrire : chaque donnée est lue comme terme de la norme EN 16931 puis écrite à l’endroit prévu par le format cible. Montants de l’exemple ci-dessous. Illustration personnelle.

Le PDF Factur-X à partir d’un XML

Un XML seul n’a rien à montrer. Pour un PDF Factur-X, l’outil dessine donc une présentation à partir des données de la facture, construite comme la page de la visionneuse : vendeur, adresse, références, lignes, totaux, paiement et pied de page, sur plusieurs pages pour les longues factures. Elle ne montre que ce qui figure dans le XML. En bas de chaque page, il est indiqué que la présentation est tirée du XML et que le XML fait référence.

Le XML validé est joint au PDF sous le nom factur-x.xml ; l’ensemble est marqué PDF/A-3, avec la police (DejaVu Sans) et le profil de couleurs intégrés. Après la création, l’outil relit le XML dans le nouveau PDF et le compare au XML validé. Les tests automatiques contrôlent en plus les PDF produits avec veraPDF, le validateur PDF/A libre.

Vers XRechnung, pour un client allemand

XRechnung est la variante allemande de la norme EN 16931, exigée par les administrations allemandes. Elle rend obligatoires certaines données facultatives dans la norme. S’il en manque, l’outil les demande, avec à côté la règle qui se déclencherait sinon : la référence acheteur (BT-10, règle BR-DE-15 – pour une administration, la « Leitweg-ID » qu’elle vous communique), un contact chez le vendeur avec téléphone et e-mail (BR-DE-5 à 7), les adresses électroniques du vendeur et de l’acheteur, et un moyen de paiement (BR-DE-1) : si vous saisissez un IBAN, l’outil ajoute un virement SEPA.

Exemple : la facture d’un artisan électricien

L’exemple de l’outil est la Factur-X fictive de la visionneuse, en XML seul : facture FA-2026-0117 du 03/11/2026, profil EN 16931, trois lignes à 20 % de TVA – 95,00 € de câble, 165,00 € de main-d’œuvre et 38,00 € pour un interrupteur différentiel. Total HT 298,00 €, TVA 59,60 €, net à payer 357,60 €.

Vers UBL selon EN 16931 : l’outil ne demande rien et indique « Toutes les données reprises sans changement ». Numéro, dates, montants et textes figurent caractère par caractère dans le fichier UBL, à d’autres endroits. La validation selon le schéma UBL 2.1 et les règles EN 16931 ne signale aucune erreur.
Vers le PDF Factur-X : le XML reste identique, l’outil dessine la présentation et joint le XML. Le PDF montre « Facture FA-2026-0117 », les lignes, « Total TTC » et « Net à payer 357,60 € ».
Vers XRechnung : l’outil demande notamment la référence acheteur et un contact chez le vendeur, qui manquent dans l’exemple.

Les tests automatiques de l’outil rejouent ces trois cas à chaque modification, en plus de 98 factures des collections de test de la KoSIT et du projet ZUGFeRD Mustang pour la conversion elle-même.

Ce que l’outil ne fait pas

Il ne transmet rien. Entre entreprises françaises, une facture électronique doit passer par une plateforme agréée ; un fichier envoyé par e-mail ne remplit pas cette obligation (impots.gouv.fr, voir les sources). Cet outil n’est pas une plateforme agréée.
Il ne vérifie pas les règles françaises de la réforme (règles de gestion de la DGFiP, comme le cadre de facturation ou le SIREN dans l’annuaire). La validation est celle de la norme EN 16931 et de Factur-X. Détails dans la visionneuse.
La présentation du PDF est simple et toujours construite de la même façon, sans logo ni mise en page personnelle. Depuis un PDF Factur-X, seul le XML intégré est converti ; la présentation de l’ancien PDF n’est pas reprise.
Les profils MINIMUM et BASIC WL n’ont pas de lignes et ne sont pas des factures complètes : on ne peut pas en faire une sans inventer de données.
Les données hors norme EN 16931 ne sont pas reprises (voir plus haut). Si la validité en dépend, la validation échoue et le résultat ne peut pas être enregistré.
Si la facture d’origine contient des erreurs, le résultat les contient aussi. L’outil ne corrige pas le contenu.
Les caractères absents de la police DejaVu Sans (par exemple les idéogrammes chinois) apparaissent comme des carrés dans la présentation ; dans le XML, ils sont corrects.
Fichiers jusqu’à 50 Mo, pas de PDF chiffrés.

La conversion change le format, pas le contenu. L’émetteur reste responsable de la facture ; avant l’enregistrement, vous confirmez en avoir conscience.

Comment votre facture est protégée

Lecture, conversion et validation ont lieu entièrement dans votre navigateur. Il n’y a pas de téléversement, et rien n’est enregistré chez xmoo.app. Le traitement se fait dans un cadre isolé, avec sa propre origine cloisonnée : cette page affiche de la publicité, mais ses scripts n’ont pas accès à la facture, et ni publicité ni statistiques ne tournent dans le cadre. Une règle de sécurité interdit au cadre d’envoyer quoi que ce soit sur le réseau. Il ne charge que des fichiers fixes de xmoo.app, comme les règles de validation.

Questions fréquentes

Comment transformer un fichier factur-x.xml en PDF Factur-X ?

Déposez le XML dans le cadre, choisissez « Factur-X / ZUGFeRD, profil EN 16931 (CII) – créer le PDF à partir du XML », cliquez sur « Convertir et valider », puis enregistrez le PDF Factur-X. Le XML n’est pas modifié.

Quelle différence entre UBL et CII ?

Ce sont deux langages XML pour le même contenu : UBL vient d’OASIS, CII d’UN/CEFACT. La norme EN 16931 admet les deux, Factur-X utilise toujours CII.

Perd-on des données en convertissant ?

Pas celles de la norme EN 16931 : les tests le montrent avec toutes les factures de la collection de test de la KoSIT, converties aller et retour. Les données hors norme ne peuvent être reprises par aucun format cible ; l’outil les liste avant la conversion.

Ma facture est-elle téléversée ?

Non. Tout se passe dans votre navigateur (voir plus haut).

Sources

Modèle sémantique et syntaxes : EN 16931-1:2017 (termes BT/BG) et CEN/TS 16931-3-2 (UBL) et -3-3 (CII) ; la correspondance est celle des EN 16931 Validation Artefacts 1.3.17 de la Commission européenne
Factur-X 1.09.2 (ZUGFeRD 2.5.2) : paquet d’information du FeRD ; structure du PDF (pièce jointe, métadonnées PDF/A-3) selon la bibliothèque de référence factur-x 7.7 ; contrôle PDF/A dans les tests avec veraPDF 1.30.3
Formats du socle de la réforme (UBL, CII, Factur-X) : fiche DGFiP 1-f ; transmission par plateforme agréée : impots.gouv.fr, Je découvre la facturation électronique (modifiée le 26/05/2026) ; consultées le 12/11/2026
XRechnung 3.0 : spécification de la KoSIT et XRechnung-Schematron 2.6.0 (règles nationales BR-DE)
Schémas : OASIS UBL 2.1 et UN/CEFACT CII D16B, comme dans la configuration du validateur XRechnung de la KoSIT
Factures de test : XRechnung-Testsuite de la KoSIT (Apache 2.0) et projet Mustang (Apache 2.0)

Logiciels utilisés et licences

Lecture, conversion, écriture et présentation du PDF sont du code propre à xmoo.app.
pdf-lib 1.17.1 construit le PDF Factur-X. Copyright Andrew Dillon, licence MIT. fontkit 1.1.1 (version pour pdf-lib) intègre la police, copyright Devon Govett et Andrew Dillon, licence MIT.
DejaVu Sans 2.37, copyright Bitstream (Bitstream Vera), modifications du projet DejaVu dans le domaine public, licence. Seul un extrait avec les caractères utilisés est intégré au PDF.
Le profil de couleurs sRGB est calculé par xmoo.app et libre.
SaxonJS 2.7 exécute les règles de validation. Copyright Saxonica Ltd, distribué sans modification selon la licence SaxonJS (qui contient aussi l’exclusion de responsabilité). Contient big.js, copyright Michael Mclaughlin, licence MIT.
EN 16931 Validation Artefacts 1.3.17, © Union européenne, sous EUPL 1.2 ; XRechnung-Schematron 2.6.0 de la KoSIT et Factur-X 1.09.2 / ZUGFeRD 2.5.2 du FeRD et du FNFE-MPE sous Apache License 2.0, ici en version compilée (SEF) ; ces derniers tirés de factur-x d’Alexis de Lattre (Akretion), licence BSD.
Schémas XML UBL 2.1 (copyright OASIS Open, avec le schéma de signature XML, copyright The Internet Society et W3C) et UN/CEFACT CII D16B (copyright UN/CEFACT), distribués sans modification avec leur mention de copyright. xmllint-wasm 5.3.0 valide le schéma XML : libxml2 en WebAssembly, licence MIT.