INSTALLATION
Système de facturation autonome Système de recrutement autonome Système de collecte de données autonome Intégration Factur-XRESSOURCES
Chatbot Flask Pack VS Code Framework documentation Static site Tamponneur de factures PDFINSTALLATION
Système de facturation autonome Système de recrutement autonome Système de collecte de données autonome Intégration Factur-XRESSOURCES
Chatbot Flask Pack VS Code Framework documentation Static site Tamponneur de factures PDFNote 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.
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. Quatre points reviennent systématiquement dans les factures rejetées.
BT-34 et BT-49 ne sont pas des champs de contact informels. Ce sont des identifiants de routage électronique, exigés indépendamment de l'adresse postale du vendeur ou de l'acheteur. Leur absence fait échouer la validation Schematron, même quand le XML est par ailleurs structurellement correct.
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.
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.
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 existant n'est pas modifié en profondeur.
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.