SERVICES
Développement sur mesure Backend & architecture Facturation batch Factur-X Intégration Factur-XSERVICES
Développement sur mesure Backend & architecture Facturation batch Factur-X Intégration Factur-XNote technique sur la conformité Factur-X EN16931, PDF/A-3, XSD et Schematron, et les erreurs les plus courantes dans les solutions de facturation électronique.
La réforme de la facturation électronique impose des échéances précises. Beaucoup de solutions se disent conformes Factur-X. Peu le sont réellement.
La conformité Factur-X ne se résume pas à embarquer un fichier XML dans un PDF.
Elle repose sur trois niveaux distincts, indépendants, et tous obligatoires.
Les mécanismes techniques permettant de produire un document Factur-X sont détaillés dans l'intégration Factur-X .
Une facture Factur-X est considérée conforme uniquement si elle satisfait simultanément ces trois exigences :
La plupart des solutions ne valident qu'un ou deux de ces niveaux. Le PDF/A-3 est systématiquement la partie la plus problématique.
Générer un PDF et y embarquer un XML ne produit pas un PDF/A-3 conforme.
PDF/A-3 impose des contraintes strictes sur le document lui-même : polices intégralement embarquées, espaces colorimétriques déclarés, OutputIntent ICC présent, métadonnées XMP conformes.
La plupart des bibliothèques de génération PDF HTML-vers-PDF ne produisent pas de PDF/A valide par défaut. Sans configuration explicite, espace colorimétrique déclaré, OutputIntent ICC associé, le document reste un PDF classique, invalide au regard de la norme, même si le XML embarqué est parfaitement structuré.
Le validateur Factur-X le détecte immédiatement. La facture est rejetée.
Le validateur Factur-X de référence effectue trois passes distinctes :
Une solution qui passe XSD et Schematron mais échoue sur PDF/A-3 n'est pas conforme Factur-X. Elle génère un XML correct dans un PDF non archivable.
Le Schematron français impose des champs et mentions au-delà de la structure EN16931 de base. Plusieurs points reviennent systématiquement dans les factures rejetées.
BT-34 et BT-49 ne correspondent pas à de simples adresses e-mail de contact. Ils désignent des identifiants de routage électronique (SIREN, adresse électronique ou autre identifiant EAS selon le contexte) utilisés pour les échanges entre plateformes agréées. Leur absence peut faire échouer la validation Schematron même lorsque le XML est par ailleurs parfaitement structuré.
Le BT-23 suit la même logique. Il précise la nature de l'opération (livraison de biens, prestation de services ou opération mixte). Les dernières évolutions des règles françaises contrôlent désormais également cette information, qui était souvent absente des anciens générateurs Factur-X.
Les mentions d'escompte et de pénalités relèvent du même problème : elles sont rarement codées en dur dans les générateurs existants, parce qu'elles ne figurent dans aucune obligation comptable classique. EN16931 les attend par défaut, qu'elles s'appliquent ou non au cas réel de la facture.
La mention légale liée à la TVA suit la même logique de défaut manqué : beaucoup de générateurs ne l'affichent que lorsque le taux de TVA est nul, en oubliant qu'une mention différente (autoliquidation, exonération, export) reste obligatoire dès qu'un régime particulier s'applique, même à taux non-nul.
Pour mieux comprendre la structure d'une facture Factur-X, vous pouvez également explorer le sujet de deux façons, à travers une expérience interactive ou une visualisation animée, afin de voir comment les données métier, le PDF et le XML participent à la construction d'une même facture électronique.
Contrairement à une idée répandue, produire un Factur-X conforme une fois ne garantit pas que le générateur restera conforme dans le temps. Les spécifications EN16931, les règles Schematron françaises et les Business Terms évoluent régulièrement.
De nouveaux contrôles peuvent apparaître lors des mises à jour des validateurs. Des informations auparavant tolérées, comme certains Business Terms ou la nature de l'opération, deviennent progressivement obligatoires lors de la validation du XML.
La conformité ne consiste donc pas uniquement à produire un XML valide une fois, mais à maintenir son générateur en phase avec l'évolution des spécifications européennes et françaises.
Ces évolutions s'inscrivent dans le cadre plus large de la réforme de la facturation électronique , qui fera progressivement évoluer les exigences applicables aux factures électroniques.
La conformité PDF/A-3 nécessite une bibliothèque de génération PDF capable de produire nativement un document archivable.
mPDF génère du PDF/A-1b propre, avec OutputIntent ICC intégré, polices embarquées et métadonnées XMP conformes. La bibliothèque Python factur-x injecte ensuite le XML EN16931 et convertit le document en PDF/A-3.
Le résultat passe les trois niveaux de validation : XSD, Schematron, PDF/A-3.
À condition, bien entendu, que les données métier injectées respectent également les dernières règles de validation françaises.
Une solution de facturation existante peut être rendue conforme Factur-X sans réécriture complète.
Le moteur XML s'adapte à la structure de données existante. L'injection PDF/A-3 s'ajoute en sortie du générateur PDF actuel. Le système métier existant n'est pas remis en cause.
Cette adaptation est également facilitée lorsque les données sont déjà structurées via des API ou d'autres interfaces d'échange.
En revanche, le générateur Factur-X doit évoluer au rythme des nouvelles règles de validation afin de garantir une conformité durable.
Ce qui change : le document produit est désormais valide, archivable, et interopérable avec les plateformes de dématérialisation.
L'échéance de septembre 2026 pour la réception des factures électroniques en B2B ne laisse pas de marge pour des solutions partielles.
Cette approche est mise en œuvre dans le service Intégration Factur-X , qui permet d'ajouter une génération conforme Factur-X à une solution de facturation existante.