Dossier de consultation / DAF et DSI
Factur-X, UBL et CII : choisir le format ERP
Comparez Factur-X, UBL et CII par profil, données et validation pour choisir le format adapté au raccordement de votre ERP.
Mis à jour le .
Formats et profils admis
Selon la DGFiP, une facture électronique n’est pas un PDF envoyé par e-mail : c’est une facture émise, transmise et reçue sous forme dématérialisée, qui contient des données structurées exploitables par un logiciel. L’arrêté du 27 juillet 2026 (article 41 septies C de l’annexe IV du CGI) liste les formats et profils admis : le profil EN16931 de la norme européenne et le profil EXTENDED-CTC-FR, extension française de cette norme, chacun en syntaxe CII ou en syntaxe UBL, et un format mixte qui associe un fichier XML CII (profil EN16931 ou EXTENDED-CTC-FR) et un PDF/A-3 lisible, c’est-à-dire le format Factur-X. La plateforme met un lisible de la facture à disposition du client.
Ces formats et profils sont décrits par la norme XP Z12-012 et par les spécifications externes de la DGFiP, dont la version 3.2 date du 30 avril 2026. Le projet doit citer les versions qu’il applique et conserver les résultats de validation.
Les mentions à prévoir dans l’ERP
La facture électronique compte quatre mentions nouvelles par rapport à la facture actuelle, selon la DGFiP : le numéro SIREN du client, indispensable à l’adressage dans l’annuaire ; la catégorie de l’opération (livraison de biens, prestation de services ou opération mixte), utile au pré-remplissage des déclarations de TVA ; l’option pour le paiement de la TVA d’après les débits ; l’adresse de livraison du bien, y compris le pays, si elle diffère de celle du client. À ces données s’ajoutent le SIREN de l’émetteur, la date d’émission, le numéro unique de la facture, le total hors taxe par taux et les taux de TVA.
Listez ce que l’ERP produit déjà et ce qu’il faut enrichir, champ par champ, avant de choisir un profil. Le choix du format ne dispense pas de trouver la bonne donnée comptable.
Vérifier la cohérence entre rendu et données
Dans un format hybride comme Factur-X, le PDF lu par le comptable et le XML traité par les machines doivent décrire la même opération. Faites contrôler les totaux, les références et les lignes entre les deux représentations : un rendu lisible avec des données incomplètes masque une anomalie qui n’apparaîtra que chez le destinataire. Pour une syntaxe sans rendu, vérifiez qu’une vue lisible reste disponible pour les utilisateurs et que les pièces jointes nécessaires restent associées au document.
Plusieurs niveaux de validation
Une validation de structure vérifie que le fichier respecte le schéma attendu. Des règles métier contrôlent ensuite les relations entre données, par exemple la cohérence des totaux ou la présence d’une référence obligatoire. La plateforme applique enfin ses propres contrôles à l’entrée, qui peuvent conduire à un rejet. Ne réduisez pas ces niveaux à un voyant unique « XML valide » : demandez l’origine et la signification de chaque erreur, un exemple d’erreur affiché dans l’ERP et un exemple conservé dans le journal, avec la version de règle utilisée.
Cas qui dépassent la facture standard
Avoirs, acomptes, remises, factures rectificatives : intégrez-les au jeu de recette s’ils sont pratiqués, avec la référence du document d’origine. Une syntaxe qui accepte des champs supplémentaires ne couvre pas automatiquement toutes vos variantes, car le profil limite ce qui est utilisable. Si la plateforme convertit votre fichier dans un autre format, faites comparer le message avant et après transformation, et inscrivez toute information non transmise comme exclusion.
Entrant et sortant
Un ERP capable d’exporter un format n’est pas nécessairement capable de l’importer dans son circuit fournisseurs. Demandez quels champs seront repris automatiquement dans les achats et quels contrôles resteront manuels. La DSI évalue la production du format et la maintenance, la DAF les informations de facture et le rapprochement, les achats les références indispensables aux fournisseurs : le choix ne doit pas dépendre du seul connecteur disponible.
Versionner le dossier technique
Conservez profils, schémas de validation et règles avec le mapping, et gardez des factures d’exemple pour rejouer les tests. Une mise à jour de l’ERP ou de la plateforme peut modifier les données produites même si le format porte le même nom. Prévoyez une procédure de retour arrière et l’identification de celui qui diagnostique un écart entre la validation locale et la réponse de la plateforme.
Grille à joindre à la consultation
| Point | Preuve à demander |
|---|---|
| Format | Syntaxe et profil explicités avec la version utilisée, plutôt qu’une mention générale de compatibilité. |
| Données | Comparaison des lignes et totaux avec le document comptabilisé avant puis après transformation. |
| Validation | Structure, règles métier et contrôles de la plateforme distingués dans les messages de diagnostic. |
| Réception | Import fournisseur et vue lisible éprouvés, avec limites des informations reprises dans l’ERP. |
| Évolution | Jeux de régression, versions et responsable du changement conservés dans le dossier de maintenance. |
Livrable attendu
La décision de format s’appuie sur un fichier produit par votre environnement de test et sur les réponses obtenues. Faites consigner les profils couverts, les conversions prévues et les cas exclus. Ajoutez le dictionnaire des données et les contrôles de cohérence avec la comptabilité. Exigez une documentation qui permet à l’équipe de vérifier une facture sans dépendre d’une démonstration commerciale. Si plusieurs formats sont nécessaires, le contrat doit préciser leur périmètre et leur maintenance respective.