SERVICES
Développement sur mesure Backend & architecture Analyse de prestataire Recherche, analyse & investigationOUTILS GRATUITS
Générateur de devis Générateur de Factur-X Analyseur SEO Dependency Security Checker PDF Comparator PDF / XML ComparatorSERVICES
Développement sur mesure Backend & architecture Analyse de prestataire Recherche, analyse & investigationOUTILS GRATUITS
Générateur de devis Générateur de Factur-X Analyseur SEO Dependency Security Checker PDF Comparator PDF / XML ComparatorNote technique sur la conformité Factur-X EN16931, PDF/A-3, XSD et Schematron, les règles métier associées 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. Produire un PDF contenant un XML ne suffit pourtant pas à démontrer cette conformité.
La conformité d'un document Factur-X ne se résume pas à embarquer un fichier XML dans un PDF.
Elle repose d'abord sur plusieurs couches de validation qui doivent rester cohérentes entre elles.
Et cette conformité documentaire ne représente qu'une partie des contraintes imposées
à un système de facturation électronique.
Pour valider un document Factur-X, trois niveaux doivent notamment être vérifiés :
Passer ces contrôles ne signifie toutefois pas que l'ensemble du système de facturation est conforme à la réforme. Il reste notamment à appliquer correctement les règles métier, les données attendues selon les cas d'usage, les calculs, le cycle de vie de la facture et les échanges avec les plateformes agréées.
Générer un PDF et y embarquer un XML ne produit pas automatiquement un PDF/A-3 conforme.
PDF/A-3 impose des contraintes précises sur le document lui-même : polices embarquées, gestion des espaces colorimétriques, OutputIntent approprié et métadonnées XMP conformes.
Les bibliothèques de génération HTML-vers-PDF ne produisent pas nécessairement un PDF/A-3 conforme par défaut. Sans configuration adaptée, le document peut rester un PDF classique, même si le XML embarqué est parfaitement structuré.
Un validateur adapté peut alors détecter cette non-conformité. Mais même lorsqu'un fichier passe ces contrôles, le travail ne s'arrête pas là.
Une solution qui produit un XML valide mais l'embarque dans un PDF/A-3 non conforme ne produit pas un document Factur-X conforme. À l'inverse, un PDF/A-3 parfaitement constitué ne compense pas un XML invalide ou des règles métier incorrectement appliquées.
Ces contrôles valident le document et ses données structurées. Ils ne suffisent pas, à eux seuls, à valider l'ensemble de la logique métier et du parcours réglementaire dans lequel la facture sera ensuite utilisée.
La norme EN16931 et les règles françaises applicables ne définissent pas seulement une structure XML. Elles organisent les données de facture en Business Terms (BT) et Business Groups (BG), auxquels s'ajoutent des règles de gestion, des listes de codes et des contraintes dépendant du profil et du cas d'usage.
Plusieurs informations deviennent alors interdépendantes :
Ces informations ne sont pas de simples champs remplis indépendamment. Un BT peut devenir obligatoire, interdit ou conditionnel selon la valeur d'un autre BT, la présence d'un BG, le profil utilisé ou le cas d'usage traité. Une donnée absente, mal renseignée ou incompatible avec le contexte de la facture peut donc provoquer une erreur alors que la structure XML reste syntaxiquement correcte.
Le moteur de facturation doit déterminer le traitement applicable à partir des données du vendeur, du client et de l'opération, puis en déduire les mentions, les catégories de TVA, les taux, les montants, les références et les données XML correspondantes. Cette logique doit rester cohérente entre les données sources, la représentation lisible et les données structurées transmises.
La nature de l'opération est un bon exemple de donnée métier qui paraît simple en surface mais devient plus complexe lorsqu'elle doit être traduite dans les données structurées. Elle ne doit pas être traitée comme un simple choix d'affichage entre biens, services ou opération mixte.
Le traitement dépend du contexte réel de facturation, du profil utilisé, des données présentes dans la facture et du cas d'usage applicable. Les listes de codes et les règles de validation évoluant avec les spécifications, ces correspondances ne devraient pas être dispersées ou figées dans le moteur et l'interface utilisateur.
Le système doit conserver les données métier sources, déterminer les valeurs structurées appropriées au moment de générer la facture et permettre de faire évoluer ces mappings lorsque les spécifications changent. Une même opération commerciale peut ainsi produire des données structurées différentes selon son contexte de facturation.
Cette information ne doit pas non plus être confondue avec les mentions fiscales affichées sur la facture. La nature de l'opération, la catégorie de TVA, le motif d'exonération et les mentions légales répondent à des règles distinctes, même lorsqu'elles décrivent une même opération commerciale.
C'est l'une des principales difficultés d'un moteur conforme : une modification ne reste pas nécessairement limitée au champ qui l'a déclenchée.
Ajouter un acompte peut modifier les références, les montants, la TVA, le solde restant et les données structurées de la facture définitive. Ajouter une remise peut affecter la base taxable, les ventilations de TVA et plusieurs totaux. Modifier le régime fiscal ou le pays du client peut modifier les catégories de TVA, les mentions et certaines données attendues.
La difficulté n'est donc pas seulement de connaître les BT et les BG. Elle consiste à maintenir toutes les dépendances entre ces données et à garantir qu'une évolution réglementaire ou normative ne crée pas d'incohérence ailleurs dans la facture.
Une mention fiscale affichée sur une facture peut sembler être une simple valeur à sélectionner. En réalité, elle constitue souvent le résultat de plusieurs informations métier qui doivent être croisées par le système.
Pour déterminer le traitement TVA applicable, le moteur doit notamment connaître le régime TVA du vendeur, son pays, le pays du client, la localisation de ce dernier en France, dans l'Union européenne ou hors UE, la nature de l'opération et, selon le contexte, le statut B2B ainsi que les informations TVA du client.
Ce n'est qu'après avoir déterminé ce contexte que le système peut appliquer le traitement TVA correspondant, produire la mention appropriée, sélectionner la catégorie TVA adéquate et maintenir la cohérence entre la représentation lisible et les données structurées.
Une facture peut contenir des biens et des services, mais leur présence sur un même document ne signifie pas nécessairement qu'ils relèvent du même traitement fiscal ou des mêmes données structurées.
Dans certaines opérations intracommunautaires B2B ou hors Union européenne, les biens et les services peuvent relever de catégories TVA, de règles de territorialité et de mentions différentes. Une prestation de services intracommunautaire peut notamment relever de l'autoliquidation, tandis qu'une livraison de biens peut relever d'une exonération lorsque les conditions correspondantes sont réunies.
Le moteur doit donc être capable de déterminer le traitement applicable à chaque élément concerné, de ventiler correctement les bases et la TVA et de produire les données structurées correspondantes. Si l'architecture du logiciel ne sait appliquer qu'un traitement fiscal global à toute la facture, certains cas mixtes ne peuvent pas être traités correctement sans adaptation.
L'acompte illustre particulièrement bien la complexité prise par la logique métier. Il ne suffit plus d'enregistrer un montant versé puis de le soustraire du total de la facture définitive : l'acompte peut donner lieu à sa propre facture.
Une même opération commerciale peut donc désormais produire plusieurs documents : une facture d'acompte lors de l'appel ou de l'encaissement concerné, puis une facture définitive qui doit reprendre correctement cet acompte.
Cela signifie également plusieurs flux de facture à traiter. La facture d'acompte possède ses propres données structurées, ses montants, son traitement TVA, ses références et son propre parcours de transmission lorsqu'elle entre dans le champ de la facturation électronique. La facture définitive constitue ensuite un nouveau document, avec ses propres données et son propre flux.
Le moteur doit donc relier les deux documents sans les confondre : conserver les références, reprendre correctement les montants déjà facturés ou versés, recalculer les bases taxables, la TVA et le solde restant, puis maintenir la cohérence entre les données métier, la représentation lisible et les données structurées de chaque facture.
Une mauvaise gestion de l'acompte peut ainsi produire deux documents individuellement valides mais incohérents entre eux, provoquer un double comptage, fausser le reste à payer ou déclencher un mauvais traitement dans les étapes suivantes du cycle de vie.
Cette évolution a également une conséquence opérationnelle souvent oubliée : lorsqu'une Plateforme Agréée ou un prestataire facture selon le nombre de factures, de flux ou de transactions traités, une opération comprenant un acompte peut générer davantage d'échanges qu'une facturation réalisée en une seule fois. Le coût réel dépend alors du modèle tarifaire de la plateforme et de ce qu'elle inclut dans le cycle de vie.
Pour mieux comprendre la structure d'une facture Factur-X, vous pouvez également explorer le sujet à 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.
Une facture Factur-X contient deux représentations d'une même réalité métier : une représentation lisible par un humain et des données XML structurées, exploitables automatiquement par les systèmes.
Le fait que le PDF soit valide et que le XML passe ses propres contrôles ne suffit pas si les deux représentations ne décrivent pas la même opération et ne portent pas des résultats financiers cohérents.
Les lignes de facture, remises, frais, bases taxables, montants de TVA, acomptes, totaux et montant restant à payer doivent être calculés selon une logique métier unique, puis reportés correctement dans les différentes données structurées correspondantes.
Ces valeurs ne sont pas indépendantes. Dans les données structurées, plusieurs Business Terms représentent précisément les différents niveaux de totalisation de la facture. Une incohérence entre les lignes, les remises, les bases taxables, la TVA et les totaux peut donc déclencher une règle de validation même lorsque chacune des valeurs paraît correcte prise isolément.
Une erreur sur une seule étape peut ainsi se propager dans toute la facture. Une remise mal appliquée modifie la base taxable, qui modifie la TVA, qui modifie le total TTC, puis éventuellement le montant restant à payer. Une somme déjà versée mal imputée peut à son tour produire un solde incorrect alors que le montant initial de la facture est juste.
C'est pourquoi le PDF et le XML ne devraient pas disposer de deux moteurs de calcul indépendants. Ils doivent être produits à partir du même résultat métier, afin d'éviter qu'une différence de logique, d'arrondi ou de traitement ne crée deux représentations contradictoires d'une même facture.
Les arrondis constituent l'une des difficultés les plus discrètes dans la génération d'une facture électronique. Quelques fractions de centime peuvent suffire à produire des totaux différents selon le niveau et l'ordre dans lesquels les calculs sont effectués.
Le problème apparaît notamment avec des quantités ou des prix unitaires comportant plusieurs décimales, des remises, des frais, plusieurs lignes de facture ou plusieurs catégories et taux de TVA.
Il ne suffit donc pas d'obtenir un résultat final visuellement correct. Le moteur doit définir précisément à quel niveau chaque valeur est calculée et arrondie, puis respecter les règles applicables aux différents totaux et ventilations attendus dans les données structurées.
Par exemple, effectuer un arrondi à un niveau intermédiaire puis réutiliser cette valeur dans plusieurs calculs peut produire un résultat différent d'un calcul effectué à partir des valeurs non arrondies. Ces différences deviennent visibles lorsque les totaux et sous-totaux sont ensuite contrôlés les uns par rapport aux autres.
Un écart d'un centime peut alors se propager entre une ligne, une base taxable, un montant de TVA, le total TTC et le montant restant à payer. Si la représentation lisible utilise une méthode et les données structurées une autre, les deux peuvent diverger alors qu'elles proviennent initialement des mêmes données métier.
La stratégie d'arrondi fait donc partie intégrante de la logique métier. Elle doit être déterministe, appliquée au niveau attendu et partagée par toutes les représentations et tous les calculs dépendants de la facture.
Produire aujourd'hui un document Factur-X conforme ne garantit pas que le générateur, ni le système qui l'entoure, resteront conformes dans le temps.
Les spécifications européennes et françaises évoluent, tout comme les règles de validation, les Business Terms, les Business Groups, les listes de codes, les profils, les statuts de cycle de vie et les cas d'usage pris en charge.
Le socle français ne repose d'ailleurs plus uniquement sur le format de la facture. Il comprend notamment les formats et profils des messages Facture et Statut, les API permettant d'interfacer les systèmes d'information avec les Plateformes Agréées, ainsi que les cas d'usage B2B.
Une évolution peut ajouter ou préciser une règle, modifier un contrôle, compléter un cas d'usage ou changer les données attendues dans certains échanges.
La conformité ne consiste donc pas uniquement à produire un XML valide une fois. Elle implique de maintenir le moteur de facturation, ses règles métier, ses mappings, ses validations et ses interfaces en phase avec l'évolution du dispositif.
Ces évolutions s'inscrivent dans le cadre plus large de la réforme de la facturation électronique , dont les obligations ne se limitent pas à la génération d'un document structuré.
La conformité PDF/A-3 nécessite une chaîne de génération capable de produire le document hybride attendu et de conserver la cohérence avec les données XML embarquées.
Dans l'architecture présentée ici, mPDF est utilisé pour produire le document PDF avec les paramètres nécessaires à l'archivage, puis la bibliothèque Python factur-x permet d'associer les données XML structurées au document afin de produire le Factur-X.
Le document obtenu peut alors être soumis aux contrôles XSD, Schematron et PDF/A-3.
Cette chaîne permet de traiter la conformité du document. Elle ne suffit cependant pas, à elle seule, à rendre conforme l'ensemble du système de facturation électronique.
Une fois la facture générée et validée, une autre partie de la logique métier commence : déterminer dans quel dispositif entre l'opération, quelles données doivent être transmises, par quel intermédiaire et quelles étapes devront ensuite être suivies.
Toutes les opérations ne suivent pas le même parcours. Selon le client, son lieu d'établissement, la nature de l'opération et son traitement fiscal, le système peut relever de la facturation électronique, du e-reporting de transaction et, dans certains cas, du e-reporting de paiement.
Une entreprise peut conserver son propre moteur de génération et l'interfacer avec une Plateforme Agréée. Mais la production locale du Factur-X ne supprime ni la plateforme ni les échanges réglementaires lorsqu'ils sont applicables.
L'intégration avec une Plateforme Agréée ne consiste pas nécessairement à appeler une API une seule fois pour envoyer un fichier.
Le système doit déterminer le destinataire et son adressage, transmettre les données attendues, interpréter les réponses de la plateforme, gérer les erreurs et conserver un état cohérent entre son propre système et les échanges effectués.
À cela s'ajoute le cycle de vie de la facture. Les formats normalisés couvrent non seulement les messages de facture, mais également les messages de statut associés à leur traitement.
Une action qui paraît locale dans un logiciel peut donc avoir des conséquences au-delà de son interface. Le changement d'état d'une facture peut nécessiter de déterminer si une information doit être conservée localement, transmise à la plateforme ou utilisée pour produire une donnée réglementaire supplémentaire.
Le statut « réglée » d'un logiciel ne doit pas être considéré comme une simple information d'affichage. Lorsque l'opération relève du e-reporting de paiement, l'encaissement devient une donnée réglementaire comprenant notamment une date et un montant encaissé, avec une ventilation par taux de TVA lorsqu'elle est applicable.
Lorsqu'une opération a donné lieu à une facture électronique, cette information peut venir compléter son cycle de vie par l'intermédiaire du statut « encaissée ». Dans les autres cas concernés, les données de paiement suivent le dispositif de e-reporting prévu à cet effet.
Le moteur doit donc distinguer le statut métier interne, l'état de la facture, la réalité de l'encaissement et l'éventuelle obligation de transmettre cette information. Un simple bouton « réglée » peut ainsi déclencher une logique différente selon le type d'opération et son régime de TVA.
La Plateforme Agréée assure les fonctions réglementaires qui lui sont attribuées : émission, transmission et réception des factures électroniques, extraction de certaines données de facture et transmission des données de transaction et de paiement à l'administration.
Elle ne dispense toutefois pas le logiciel en amont de produire et de lui transmettre des informations métier cohérentes. Une erreur de calcul, un mauvais traitement TVA, une référence incorrecte, un acompte mal imputé ou des données incohérentes entre la représentation lisible et les données structurées restent des problèmes à traiter dans la chaîne de facturation.
La conformité devient ainsi une responsabilité répartie entre le moteur métier, la génération du document, les données structurées, l'intégration avec la plateforme et le suivi du cycle de vie.
Séparer le moteur métier de la couche de transmission reste un principe d'architecture important. Les données sources, les calculs, les règles fiscales, la génération du document et la traçabilité interne ne devraient pas dépendre du fonctionnement particulier d'une plateforme.
La Plateforme Agréée intervient cependant bien au-delà d'un simple canal permettant de déposer un fichier. Elle participe aux échanges réglementaires, à la transmission des factures et des données attendues, au traitement des statuts de cycle de vie et, selon les opérations concernées, aux échanges liés au e-reporting de transaction ou de paiement.
Lorsqu'une API est utilisée, l'intégration doit donc gérer davantage qu'un simple envoi de Factur-X. Elle doit notamment transmettre les données attendues, interpréter les réponses et statuts, gérer les erreurs, éviter les doublons et maintenir la cohérence entre l'état connu par le logiciel et celui des échanges effectués avec la plateforme.
Une architecture découplée permet de limiter la dépendance à une Plateforme Agréée particulière. Changer de plateforme ne devrait pas nécessiter de reconstruire les calculs ou le moteur fiscal, mais la couche d'intégration peut néanmoins nécessiter des adaptations selon les API, les services proposés et les modalités techniques retenues par le nouveau prestataire.
Adapter un logiciel existant à Factur-X peut parfois être réalisé sans réécriture complète. Adapter un système de facturation à l'ensemble des obligations de la réforme est une question beaucoup plus large.
Lorsque les données métier sont déjà correctement structurées, une couche de génération XML et une chaîne de production PDF/A-3 peuvent être ajoutées au système existant. Mais cette approche atteint rapidement ses limites lorsque le logiciel ne possède pas les données, les états ou les règles nécessaires aux nouveaux traitements.
Le système métier peut alors devoir évoluer lui-même : nouvelles données, nouveaux Business Terms et Business Groups, nouvelles références, gestion des factures d'acompte, calculs supplémentaires, statuts de cycle de vie, données d'encaissement, règles de routage, gestion des erreurs et synchronisation avec une Plateforme Agréée.
Une modification apparemment limitée peut ainsi se propager dans plusieurs parties du logiciel. Ajouter une facture d'acompte ne consiste pas seulement à créer un nouveau modèle de document : il faut déterminer son traitement, ses calculs, ses références, son articulation avec la facture définitive, son parcours de transmission et les états dans lesquels elle doit ou ne doit pas intervenir.
Cette adaptation est facilitée lorsque les données et les différentes fonctions du système sont déjà séparées et accessibles via des API ou d'autres interfaces d'échange. Elle ne supprime cependant pas la nécessité de faire évoluer la logique métier elle-même lorsque les règles changent.
Le problème n'est donc plus uniquement de maintenir un générateur Factur-X. Il faut maintenir dans le temps l'ensemble de la chaîne : données métier, calculs, règles fiscales, mappings XML, validations, cas d'usage, statuts, intégration avec les plateformes et échanges réglementaires.
Une facture qui passe aujourd'hui les contrôles XSD, Schematron et PDF/A-3 peut être parfaitement conforme en tant que document sans que cela démontre que le logiciel qui l'a produite couvre correctement l'ensemble du dispositif.
À compter du 1er septembre 2026, toutes les entreprises assujetties à la TVA établies en France doivent être en capacité de recevoir des factures électroniques. L'obligation d'émission et de e-reporting s'applique à la même date aux grandes entreprises et aux entreprises de taille intermédiaire, puis à compter du 1er septembre 2027 aux PME et micro-entreprises.
Avant de choisir une Plateforme Agréée, il peut donc être utile d'examiner précisément ce que couvre son offre : tarification, factures et flux comptabilisés, accès API, statuts pris en charge, gestion du e-reporting, conditions d'intégration, limites techniques et éventuels coûts supplémentaires. Le service d'analyse de prestataire permet d'examiner ces éléments et les réponses fournies par la plateforme avant de vous engager.
Pour replacer cette évolution technique dans un contexte plus large, Palks Studio publie également une enquête sur les liens entre facturation électronique, données de transaction, Digital Product Passport, identité numérique et paiement.