I            Parce que ça doit rester simple

La réforme fait référence à des Formats de Facture du « socle minimum », que le PPF et les PDP doivent tous accepter. On parle du Flux 2. Ces formats de factures doivent être conformes à la Norme sémantique Européenne EN16931, et ils sont énumérés au nombre de 3 : XML UBL, XML UN/CEFACT CII et Factur-X. Leurs structures sont définies en annexe 1 des spécifications externes, qu’il faut comprendre comme 2 profils sémantiques distincts applicable sur les syntaxes UBL et UN/CEFACT CII (utilisée aussi dans Factur-X) :

• Profil EN16931 : conforme à la Norme EN16931, augmentée de quelques règles de gestion additionnelles listées en annexe 7 des spécifications externes.
• Profil EXTENDED-CTC-FR : qui est une EXTENSION au sens de la Norme EN16931, venant ajouter des données nécessaires pour adresser les différents cas d’usage, modifier quelques cardinalité (rendre multiple certaines données qui sont d’occurrence unique dans la Norme), et modifier quelques règles de gestion, notamment celles relatives aux calculs de totaux et de TVA, en introduisant une tolérance de 1 centime par ligne dans ces calculs de totaux ou de base TVA.

S’agissant de Factur-X, il existe déjà des profils différents d’abord pour permettre des factures électroniques ne disposant pas de toutes les mentions obligatoires sous forme structurée (nécessaire au démarrage de la réforme avec le profil BASIC WL, voire plus durablement pour les factures B2C), puis des profils BASIC et EN16931 conformes à la Norme EN16931 et un profil EXTENDED qui contient le profil EXTENDED-CTC-FR.

En fonction de leurs besoins, les entreprises devront donc aligner leur modèle de gestion des factures émises sur le modèle sémantique EN16931, le cas échéant augmenté avec le profil EXTENDED-CTC-FR, de façon à être en capacité de créer des factures conformes.

Ceci nécessite a minima une analyse de la chaine de gestion et de création des factures, y compris de la façon dont elles sont calculées (TVA et totaux, voire lignes), avec une analyse des écarts à adresser pour se rendre conforme à la réforme. Normalement, les factures électroniques structurées déjà en place et qui ont vocation à perdurer dans leur format, si échangées entre PDP (le flux 3), devraient être très proches de la cible, à l’exception des quelques nouvelles mentions obligatoires.

En réception, les entreprises disposeront de factures électroniques avec a minima l’ensemble des mentions obligatoires sous forme structurée, ce qui est déjà beaucoup, ainsi qu’une représentation lisible fournie soit par l’émetteur (en pièce jointe ou nativement dans le format Factur-X), soit à créer par la PDP / PPF destinataire. Charge à elles de les utiliser pour automatiser leurs intégrations et traitements.

Comme l’émetteur est libre de choisir le format et le profil qu’il souhaite pour ses factures dès lors qu’il est dans le « socle minimum », le PPF proposera des conversions entre formats du socle minimum pour permettre au destinataire de disposer du format qu’il souhaite. Toutefois cette conversion aura les limites que les données imposent (pas d’un profil EXTENDED-CTC-FR vers un profil EN16931 plus petit, pas d’un profil Factur-X sans lignes (BASIC WL) vers un profil complet EN16931). Les PDP pourront offrir le même service.

Le PPF n’acceptera que des factures dans un des profils décrits en annexe 1 des spécifications externes. Par conséquent, des factures UBL ou UN/CEFACT CII disposant de données d’extension absentes de l’annexe 1 seront rejetées, même si ces données pourraient juste être ignorées (du fait de l’obligation d’en produire une présentation lisible qui nécessite de les connaître a priori).

S’agissant des factures relevant du e-reporting (B2B internationales et B2C), les entreprises sont libres de les transmettre dans le format qu’elles souhaitent, y compris en papier ou pdf simple. Toutefois, du fait de l’alignement international en cours (et notamment le projet de Directive ViDA), il est raisonnable de prévoir d’utiliser les mêmes formats pour ces factures, que le PPF ne transmettra pas. Par contre, il proposera que des flux de données de facture lui soient transmis pour en extraire les données requises (flux 8 et 9). Toutefois, il peut être plus efficace de prévoir d’intégrer dans le système de création et de transmission de ces factures de créer directement les données requises par l’administration (le flux 10.1).

Ceci étant dit, il est nécessaire de rentrer un peu plus dans le détail pour à la fois comprendre ce qu’implique de passer à des factures électroniques structurées, mais aussi à se préparer en se posant les bonnes questions.

 

II          La Norme Sémantique EN16931

La Norme Sémantique Européenne de facture EN16931 a été créé suite à la Directive 2014-55-EU qui vise à imposer la facture électronique en réception par toutes les entités publiques en UE, ce qui est effectif depuis avril 2020. Il s’agit d’obligation de réception, qui a conduit l’ensemble des pays Membres de l’UE à mettre leurs entités publiques en capacité d’accepter des factures électroniques structurées sous cette forme, et un certain nombre d’entre elles, dont la France, à obliger aussi l’émission de factures électroniques vers le secteur public (B2G avec ChorusPro en France).

Cette Norme est aussi la base de l’alignement des réformes CTC en UE en cours de validation au travers de la Directive ViDA. Elle sert aussi de base à la gouvernance PEPPOL au travers de son implémentation dans le message PEPPOLBIS INVOICE 3.0.

Il est donc d’abord important de maîtriser cette norme, les contraintes qu’elle impose et ses limites, puisqu’il faut que les factures électroniques s’y plient, a minima en ce qui concerne les mentions obligatoires requises par les administrations fiscales.

Ensuite, cette Norme Sémantique se décline en messages électroniques, c’est-à-dire en Syntaxes de représentation, qui ont leur propre structure sémantique (organisation des données et des groupes de données), qui n’est pas totalement alignée avec la Norme Sémantique EN16931 d’ailleurs (UBL, UN/CEFACT CII, EDIFACT, …).

Ainsi, la Norme EN16931 est une Norme Sémantique de facture, dont l’objet est de définir un ensemble de termes métiers les plus courants et utiles, organisé par groupes, pour à la fois permettre à la plupart des factures de s’y retrouver, et permettre une automatisation des traitements. L’ensemble de ses données de facturation sont identifiées par un code qui commence par BT (pour Business Term) ou BG (pour Business Group).

Cette norme a été construite à partir d’un existant de plus de 30 ans, extrêmement riche en données car le résultat d’ajouts continus à chaque fois qu’un besoin nouveau a été identifié, auquel s’ajoute de nombreuses listes de codes (métadonnées pour codifier de façon normative certaines valeurs de données : les types de factures, les différents moyens de paiement, les catégories TVA, les raisons de remise ou charge) et qui a donné lieu à 2 grandes familles de syntaxes, qui comportent plusieurs dizaines de milliers de données possibles :

• UN/CEFACT (United Nation Trade Facilitation and E-Business), qui normalise à l’échelle mondiale l’ensemble des messages métiers au niveau sémantique, décliné notamment dans la syntaxe EDIFACT (puis ebXML) et dans la syntaxe XML UN/CEFACT SCRDM CII, qui est un modèle plus large de l’ensemble des données de la supply chain (SCRDM : Supply Chain Reference Data Model), restreint à la facture (CII : Cross Industry Invoice).
• UBL (Universal Business Language), qui s’appuie sur le même modèle sémantique de données et de listes de codes, mais implémenté suivant une syntaxe XML différente, maintenue par OASIS OPEN, association créée à l’origine (en 2000) par des offreurs de solutions. UBL décline de nombreux messages relatifs à la supply chain. En particulier, il existe un message pour la facture et un autre, proche mais pas identique, pour les Avoirs (Credit Note).

La Norme Sémantique EN16931 est un sous-ensemble de données essentielles et communes à la plupart des factures, avec pour vocation initiale de contenir l’univers des possibles en réception pour les secteurs publics de l’UE. En clair, toutes les entités publiques de l’UE s’engagent à les accepter, mais ceci ne préjuge pas de la capacité des vendeurs à les utiliser, en particulier pour certaines spécificités sectorielles pour lesquelles la Norme EN16931 n’est pas suffisante.

 

1        Le modèle de données EN16931

Ainsi, ce modèle est un ensemble de 164 données de factures, qui ont chacune une définition claire et non équivoque, réparties en 32 groupes, qu’on peut résumer de la façon suivante :

• Des données identifiant la facture et le processus auquel elle s’applique : un numéro de facture (BT-1), une date de facture (BT-3), un type (BT-3 : facture, avoir, facture rectificative, …), une devise (BT-5), un cadre de facturation (BT-23), …
• Les Parties : Vendeur (BG-4) et Acheteur (BG-7) disposant chacun d’un Identifiant légal, un identifiant privé (ou complémentaire), un identifiant fiscal (TVA intracommunautaire), une dénomination sociale, une adresse postale (un groupe de 7 données avec 3 lignes, un code postal, une ville, une région, un pays), un contact (un groupe avec un nom, un numéro de téléphone, une adresse électronique) et une adresse électronique. Puis il existe aussi un Bénéficiaire du Paiement (si différent du Vendeur), et un représentant fiscal du Vendeur (quand il existe).
• Des références diverses : un n° de Bon de Commande créé par l’acheteur (BT-13), à distinguer du n° de Bon de Vente (BT-14), créé par le Vendeur, une Référence Acheteur (BT-10) qui souvent permet d’identifier un service ou une unité de gestion chez l’acheteur (équivalent naturel d’un Code Service), un n° de Contrat (BT-12), un n° de Bon de Livraison (BT-16), un n° de Bon de Réception (BT-15) …
  Ces références sont clés pour permettre un traitement automatisé, les Bons de Commande ou de Vente pour raccrocher au processus initial de commande, où les prix et quantités commandées sont définies, les Bons de Livraison ou de Réception pour raccrocher avec la réception effective des biens ou services (les quantités facturées), le n° de contrat pour les prestations ou livraison sans commande, la Référence Acheteur pour identifier le processus de traitement ou le workflow de validation.
  On verra qu’il en résulte un alignement des solutions de gestion sur ces concepts et données, qui aujourd’hui sont souvent traitées dans du texte libre au gré des exigences des acheteurs et de la bonne volonté des vendeurs.
• Des informations de livraison : une adresse de livraison (en pratique, il s’agit d’une Partie « Livrée à ») et une date de livraison ou bien une période de facturation.
• Des instructions de paiement et des références bancaires, des notes permettant de fournir des informations diverses en texte libre, …
• Des lignes de facturation, avec nom d’article, détail, Prix Unitaire (brut, rabais, net), Quantité Facturée, Remises et Charges de ligne, information de TVA, et différentes caractéristiques produits, …
• Des charges et remises de niveau document.
• Un détail TVA (notamment lorsqu’il y a plusieurs TVA applicables, ou des exonérations),
• et des Totaux HT, TVA, TTC, Net à payer, …

Chacune de ces données métiers ou de ces groupes de données peut être définie comme obligatoire ou facultative, répétable ou pas. Ceci se codifie au travers d’une cardinalité représenté par 2 chiffres séparés par 2 points, le premier donnant le nombre minimum d’occurrence et le second le nombre maximum d’occurrence (et « n » signifiant plusieurs). Ainsi « 0..1 » signifie facultatif et une occurrence, « 1..1 » signifie obligatoire et une occurrence, « 1..n » Obligatoire et Répétable, « 0..2 » facultatif et 2 occurrences maximum, …

Le résultat est un arbre de données structurées, les branches correspondants aux Groupes (BG) et les feuilles aux données de facturation (les BT), chaque branche ou feuille étant facultative ou obligatoire, répétable ou pas.

 

2        Les listes de codes (Metadonnées)

Une facture électronique structurée signifie aussi de codifier les valeurs de certaines données de facture de façon à aligner des significations et des traitements. Ces listes sont gérées par UN/EDIFACT (Electronic Data Interchange for Administration, Commerce and Transport). Par exemple, il existe :

• une liste de moyens de paiement possible, qu’il est donc possible de définir et maintenir.
• différentes devises codifiées sur 3 caractères (EUR, USD, …),
• différents types de facture (380 pour une facture commerciale, 381 pour un avoir commercial, 384 pour une facture d’acompte, …),
• des codes pays (FR, DE, GB, SP, …),
• mais aussi des listes de raisons de remise, de raisons de charges, de raisons d’exemption de TVA (les codes VATEX),
• des listes de référentiel d‘identifiants (0088 pour des GLN, 0002 pour un SIREN, 0009 pour un SIRET, 0224 pour un CODE_ROUTAGE, 0225 pour une adresse électronique attachée à un SIREN, EM pour une adresse électronique SMTP, …),
• une liste d’objets de Note pour en qualifier le sujet,
• une liste pour l’ensemble des unités de mesures nécessaires pour qualifier les quantités (sont-ce des unités, des litres, des kilogrammes, des Kwh, des jours, …),
• …

Ces listes sont assez pléthoriques et la Norme EN16931 en a parfois limité la liste des valeurs possibles. Par exemple, le code de type de document se codifie par une liste de tous les types de documents répertoriés, qui a été restreinte à une sous-liste de documents de type facture, avoir ou facture rectificative. On verra d’ailleurs que la réforme en France a réduit cette liste à un périmètre encore plus restreint, tout en demandant que de nouveaux codes soient ajoutés.

 

3        Les types de données

Chacune des données (BT) a un type, qui encadre la façon dont il peut s’exprimer. Par exemple un type code quand la valeur est à prendre dans une liste de codes, un type date, un type complexe d’objet binaire attaché (constitué du document et de données d’identification, de nommage et de description du document), le type « texte », et en particulier des types représentés par des nombres, dont le type indique les décimales possibles, voire le signe :

• Les Prix Unitaires sont donc des nombres décimaux, sans limite de décimales exprimées (l’informatique en pose néanmoins). Les Prix Unitaires sont positifs.
• Les Quantités sont aussi des nombres décimaux, sans limite de décimales, positifs ou négatifs.
• Les Pourcentages sont des nombres décimaux, et représentent le pourcentage (et pas la valeur après application du pourcent) : 20.00 signifie 20%.
• Les Montants (base TVA, total de ligne, montant de remise ou charge, totaux) sont des nombres décimaux à 2 décimales.

 

4        Les règles de gestion

La Norme Sémantique comprend aussi un grand nombre de règles de gestion, identifiée par un code de type BR-XX-ZZ, qu’on peut séparer en catégories :

• Des règles relatives à la TVA, qui, en fonction des catégories de TVA (Standard : BR-S-01 à 10, à taux 0 : BR-Z-01 à 10, Exempté : BR-E-01 à 10, Livraison Intracommunautaire : BR-IC-01 à 12, Autoliquidation de TVA : BR-AE-01 à 10, Export : BR-G-01 à 10, Hors scope : BR-O-01 à 14), indiquent comment la TVA est calculée et quelles sont les mentions obligatoires à renseigner (par exemple un code VATEX de raison d’exemption sauf pour les Catégories Standard et Taux 0 de TVA).
  Pour rappel, la Norme EN16931 oblige un calcul de TVA en pied, c’est-à-dire de sommer tous les montants hors taxe de ligne (BT-131), de Charges de niveau document (BT-99) et de déduire les Remises (BT-92) de niveau document, par catégorie et taux de TVA, à 2 décimales, puis d’appliquer le taux de TVA sur cette base (et donc pas de sommer des montants de TVA calculés à la ligne).
• Des règles de présence de certaines données (les mentions obligatoires) ou de cohérence entre plusieurs données, 59 règles entre BR-01 à BR-66.
• Des Règles Conditionnelles (BR-CO-03 à 26), de présences conditionnelles de certaines données, mais aussi de calcul (par exemple BR-CO-15 : HT + TVA = TTC).
• Des règles venant préciser le nombre de décimales : 21 règles entre BR-DEC-01 à 28.
• Des règles sur l’utilisation des listes de codes pour certaines données : 23 entre BR-CL-01 à 26.

En particulier, la Norme EN16931 oblige la façon dont la facture doit être calculée, y compris les règles d’arrondis. Il existe par exemple 3 niveaux d’application de remises : sur le Prix Unitaire (le rabais), à la ligne, dès lors que les mêmes conditions TVA s’appliquent, et au niveau Document, ce qui implique qu’il y a une information TVA pour chaque ligne de remise « globale ». Ainsi, si l’on souhaite formuler en pied de facture une remise de 10%, et si la facture comporte plusieurs taux de TVA, il faudra autant de lignes de Remises de niveau Document que de taux de TVA, avec comme base la somme des montants sous remise sur lesquels s’applique le taux de TVA, puis le montant de remise correspondant à 10% de cette base.

Ceci étant dit le calcul se passe ensuite de la façon suivante :

• En ligne, le Montant total de ligne est HT (BT-131). Les règles explicitant comment il est calculé ont été supprimées dans la Norme EN16931 car trop de diversités existent dans les systèmes. Néanmoins, la bonne pratique est la suivante (aux erreurs d’arrondis près) :
• D’abord, que le Prix Unitaire Net (BT-146) soit égal au Prix Unitaire Brut (BT-148) diminué du rabais (BT-147), et qu’il soit défini pour une quantité (BT-149) et une unité de mesure données.
• Ensuite il est possible d’ajouter une ou plusieurs charges de lignes, dès lors que la même règle TVA est appliquée (par exemple des frais de consigne).
• De même, on peut ajouter des remises de ligne, en complément du rabais sur Prix Brut pour avoir un Prix Unitaire Net.
• Enfin, le Montant total HT de ligne est égal au Prix Unitaire NET (BT-146), divisé par la Quantité du Prix Unitaire, multiplié par la Quantité facturée, auquel est ajouté la somme des montants HT de charges de ligne et retranché la somme des montants HT de remise de ligne, l’ensemble étant ensuite arrondi à 2 décimales.
• Le total en pied se calcule :
• D’abord dans un bloc de détail TVA, où, par Catégorie de TVA et par taux de TVA applicable, un montant de base est calculé en sommant tous les Montants HT de ligne (BT-131), augmentés des montants HT de charges de Document (BT-99) et diminué des montants de remises de Document (BT-92, qui sont donc positifs dans la facture). Ceci donne une base HT pour chaque catégorie et taux de TVA, sur laquelle est appliquée ensuite le taux de TVA, puis un arrondi à 2 décimales pour obtenir un Montant de TVA pour chaque ligne de détail TVA. La TVA se calcule donc en pied et pas à la ligne.
• Ensuite, le Total HT (BT-109) est égal à la somme des montants HT de ligne (BT-131) augmentés des montants HT de charges de Document (BT-99) et diminué des montants de remises de Document (BT-92), ce qui est aussi égal à la somme des Bases HT du détail TVA (et en pratique, il y a des totaux intermédiaires des lignes (BT-106), des charges de Documents et (BT-99) et des Remises de Documents (BT-92)).
• Puis, le Total TVA (BT-110) est égal à la somme des montants de TVA calculé en détail TVA.
• Puis le Total TTC (BT-112) est égal au Total HT (BT-109) + le Total TVA (BT-110).
• Et il reste à déterminer le Net à Payer, car il peut être nécessaire de prendre en compte des acomptes, voire des arrondis (par exemple pour arrondir le Net à payer à l’euro le plus proche), ce qui donne que le Net à Payer (BT-115) est égal au TTC (BT-112) diminué du Montant déjà payé (BT-113) et augmenté du Montant arrondi (BT-114).

Ceci est très important pour les entreprises, et donc pour leurs solutions de gestion de facture, y compris les outils de saisie en ligne d’OD ou de PDP, car elles doivent s’assurer que leurs factures respectent bien ces règles. A défaut les factures seront Rejetées à l’émission et non transmises.

 

5        Les profils, CIUS et Extensions

Dans la vraie vie, les choses peuvent être un peu différentes. Tout d’abord, il peut arriver qu’il soit nécessaire d’ajouter des règles qui restreignent un peu plus ce que prévoit la Norme EN16931. Par exemple, les spécifications externes indiquent des tailles maximums sur certains champs, comme le numéro de facture qui doit faire moins de 20 caractères, les nombres qui sont sur 19 chiffres (sans compter le séparateur de décimal), qui correspondent à certaines des règles de gestion spécifiques de l’annexe 7.

Dans ce cas on parle d’un profil CIUS (Core Invoice Usage Specification), c’est-à-dire d’une Spécification d’Usage. Autre exemple : le profil BASIC de Factur-X a supprimé quelques données de la Norme EN16931 tout en conservant l’intégralité des règles de gestion. C’est aussi un profil CIUS.

La Norme est aussi limitée et ne permet pas d’adresser tous les cas d’usage et les besoins des entreprises. Déjà, une hypothèse forte est que la Norme EN16931 n’adresse que des factures mono-commande et mono-livraison. Mais la vraie vie a aussi des factures multi-commande ou multi-livraison.

De même, la Norme EN16931 n’autorise qu’une seule occurrence à l’identifiant privé d’acheteur (BT-46), là où les spécifications externes prévoient d’y renseigner à la fois le SIRET et le CODE_ROUTAGE.

Enfin l’analyse des cas d’usage montre qu’il est nécessaire de prévoir des acteurs complémentaires, des données additionnelles.

Il est ainsi prévu de pouvoir modifier « à la hausse » la norme EN16931, par exemple en augmentant la cardinalité de certains termes métiers, en ajoutant des données, et modifiant certaines règles de gestion.

Ceci conduit à un profil ETENDU (EXTENDED), qui doit être bien identifié car les factures qui s’y conforment ne sont plus conformes au profil de la Norme EN16931.

C’est le cas du profil EXTENDED-CTC-FR, qu’on devine dans l’annexe 1 des spécifications externes, qui en pratique décrivent 2 profils :

• Le profil EN16931 avec les règles de l’annexe 7 (qui en pratique est une CIUS),
• et le profil EXTENDED-CTC-FR, qui contient toutes les données et groupes additionnels dont le code est sous la forme « EXT-FR-FR-XXXX », et avec une cardinalité qui est décrite spécifiquement.

S’agissant de Factur-X, il existe déjà plusieurs profils de données suivant cette logique, à savoir :

• Un profil EN16931 : la Norme, rien que la Norme, toute la Norme.
• Un profil BASIC : une CIUS, avec juste quelques données qui ont été retirées car jugées moins essentielles. En pratique, le profil BASIC a été fait pour aider les entreprises à prioriser leurs développements pour disposer des informations de factures obligatoires ou les plus utiles sous forme structurée. Mais une Factur-X créée en se restreignant au profil BASIC peut tout à fait se déclarer du profil EN16931 (et c’est même recommandé).
• Un profil BASIC WL : qui est le profil BASIC SANS LIGNES. Il n’est donc plus conforme à la Norme EN16931 (qui oblige les lignes), mais sera toléré au démarrage de la réforme.
• Un profil MINIMUM, avec un nombre faible de données (le minimum requis par ChorusPro aujourd’hui), qui a vocation à ne plus être accepté dans la réforme.
• Un profil EXTENDED, beaucoup plus large que le profil EXTENDED-CTC-FR, mais qui le contient, si bien que le profil EXTENDED-CTC-FR peut être vu comme une restriction du profil EXTENDED de Factur-x.

En particulier les profils EXTENDED-CTC-FR et EXTENDED de Factur-X ont assoupli les règles de calcul de la facture en introduisant des tolérances de 1 centime fois le nombre de lignes et de remises et charges de niveau document dans les totaux pour permettre aux factures se calculant sur la base de prix unitaires bruts ou de TVA calculées à la ligne, de ne pas être rejetées. Par contre, pour ce faire, ces factures devront revendiquer le profil EXTENDED-CTC-FR ou EXTENDED, et du coup disposer du détail de lignes sous forme structurée (car c’est le cas de ces profils).

A ce stade, le profil EXTENDED-CTC-FR a retenu :

• L’ajout de certaines Parties : Agent d’Acheteur, Agent de Vendeur, Payeur, Facturant, Adressé À (Facturé À), et a complété le Bénéficiaire pour qu’il soit comme les autres parties.
• L’ajout de données pour permettre des factures multi-commandes, multi-livraison et plus généralement permettre à toutes les références d’être renseignées à la ligne.
• L’ajout de quelques données pour certains cas d’usage (par exemple un type de facture antérieure pour distinguer les références à des factures pour des avoirs, des références à des factures d’acomptes pour des factures finales).
• La modification de quelques cardinalités, et notamment la BT-46 pour permettre de renseigner à la fois un SIRET et un CODE_ROUTAGE.

Pour finir, certaines de ces EXTENSIONS pourront être intégrées dans le périmètre de la Norme EN16931 dans le cadre des travaux de maintenance. Mais ceci se passe à l’échelle Européenne, et a priori au-delà de 2026/ 2027.

Ces profils ETENDUS restent aussi conformes avec les exigences de la DGFIP en matière d’extraction de données à transmettre (le flux 1).

Il résulte de tout ceci que les factures doivent déclarer de quel profil elles relèvent, ce qui se fait dans une des données de la facture (BT-24), au travers d’une codification bien précise.

Enfin, il faut aussi noter que si les flux 8 et 9 sont censés être des factures transmises aux destinataires, elles doivent être aussi conformes à ces profils qui peuvent être acceptés à l’échelle internationale (notamment pour les flux 8 qui sont normalement pour les factures B2B internationales). C’est un point d‘attention qui nécessite quelques corrections dans les annexes des spécifications externes.

 

III         Quels impacts pour les entreprises – Comment se préparer

Toutes les factures devront être conformes à la Norme EN16931, ou bien sur le profil EXTENDED-CTC-FR (ou EXTENDED de Factur-X). Ceci implique déjà qu’en réception, les entreprises vont bénéficier de toutes les données requises et qu’il faudra donc que leurs systèmes de gestion s’alignent avec le modèle sémantique pour bien aller chercher les données nécessaires au traitement au bon endroit dans les factures. Par exemple, bien distinguer N° de Bon de Commande et N° de Bon de Vente, et utiliser les données disponibles pour définir les différents schémas d’enregistrement comptables.

La présence de certaines Parties du profil EXTENDED-CTC-FR peut aussi avoir des impacts sur le processus de gestion (par exemple en cas de présence d’Agent d’Acheteur, de Payeur, de Adressé À). L’adresse électronique de réception (BT-49) peut aussi servir à sélectionner des processus de traitement spécifiques (cf cas d’usage).

Mais l’impact est surtout coté émission. Il va falloir créer des factures électroniques conformes, ce qui implique d’abord de vérifier que les outils de génération de factures sont bien alignés avec la Norme EN16931. Et la réponse est en général NON. Il y a toujours des écarts et donc des modifications à apporter.

Le meilleur exercice pour prendre conscience de tout ceci est le suivant :

• Sélectionner quelques factures fournisseurs papier ou PDF, et pour chacun d’entre elles, essayer de trouver à quelles données du modèle sémantique correspond chaque élément d‘information trouvé dans la facture.
• Faire ensuite le même exercice sur les factures et avoirs transmises aux clients.
• Pour que l’exercice fonctionne, il faut qu’il soit fait par plusieurs personnes différentes sur les mêmes factures pour voir si elles arrivent au même résultat, de façon à prendre conscience qu’il peut y avoir interprétation sur le sens sémantique de certaines informations.
• Enfin, une fois l’exercice fait, vérifier que toutes les mentions obligatoires ont bien été trouvées et placées.

Ceci permet de constater que certaines informations présentes dans les factures n’ont pas de place naturelle et évidente dans le modèle sémantique. De la même façon, on peut ainsi constater aussi que le système de gestion ne dispose pas forcément d’autant de références distinctes que la Norme impose. Par exemple, il arrive souvent que certains logiciels ne gèrent qu’une référence acheteur, dans laquelle on écrit un numéro de Bon de commande parfois, ou une autre information exigée par l’acheteur (un numéro de Business Unit, un numéro de contrat, voire un identifiant de fournisseur chez l’acheteur). Il arrive aussi souvent qu’on utilise des zones en texte libre pour y loger un tas d’informations additionnelles exigées par l’acheteur. Tout ceci ne sera plus possible, car chaque donnée à une place stricte pour être utilisée par le destinataire. Elle doit donc avoir une place stricte dans le référentiel de facturation.

L’étape suivante consiste à étudier d’où viennent les données des factures et comment elles sont calculées, avec un focus particulier sur la gestion des remises. Normalement, pour chaque article, il y a un Prix Unitaire Brut générique (pour tout le monde), puis des Prix Unitaires Net pouvant être différents du fait de situations particulières ou de négociations avec les clients. Il est ensuite possible d’ajouter des remises promotionnelles, qui s‘appliquent sur certains articles (et donc à la ligne), ou en général (remises de niveau Document, qui doivent se décliner au prorata de la structure TVA normalement). Enfin, il est possible d’avoir plusieurs remises qui s’enchainent à chaque niveau, où il faudra déterminer si la remise secondaire s’applique sur la base avant ou après prise en compte de la remise précédente. N’oublions pas aussi que toute remise doit avoir une raison de remise. Et tout ceci peut parfaitement se codifier dans la Norme EN16931, mais n’est pas forcément construit de cette façon dans les systèmes de gestion.

Il est aussi possible que les systèmes de gestion de factures soient basés sur des prix unitaires TTC, en particulier pour des ventes a priori B2C (et pour lesquelles des factures B2B peuvent toujours être demandées). Dans ce cas, il faudra probablement utiliser uniquement le profil EXTENDED-CTC-FR, et comprendre la façon dont les arrondis sont gérés pour s’assurer que les factures resteront bien dans les tolérances du profil EXTENDED-CTC-FR. En particulier, il faudra établir une règle de retro-calcul des montants HT à partir des montants TTC, car les prix unitaires et montants HT restent obligatoires dans les factures électroniques.

La source des données et références est aussi importante. Par exemple, est ce qu’un numéro de SIRET ou de CODE_ROUTAGE ou une adresse électronique de réception de factures proviennent d’un référentiel Client, ce qui impose qu’ils soient communs à toutes les transactions, ou bien faut-il pouvoir les différencier à la transaction (et si c’est le cas, comment ceci est-il tracé). De même, comment les clients sont-ils gérés ? à la maille SIREN, quitte à ce que pour chaque client, une liste de SIRET adressables soit prévue, ou bien à la maille SIRET, chaque SIRET étant considéré comme un client différent.

Si l’acheteur demande d’adresser la facture à un tiers (un « Adressé À »), le système de gestion peut-il le faire ? De même, le système sait il gérer des tiers à renseigner le cas échéant (PAYEUR, AGENT DE VENDEUR), et à quelle niveau (base client ou à la transaction) ?

Une attention particulière doit aussi est portée sur la gestion des Avoirs (y compris la notion d’Avoir Interne, non transmis), voire des factures rectificatives.

Enfin, certains cas d’usage peuvent avoir un impact structurant, comme la gestion des factures d’acompte et surtout les factures finales après acompte. Il en est de même en cas de pratique de l’autofacturation. Il sera aussi nécessaire d’être plus précis sur la distinction du bloc de paiement, avec le montant déjà payé présent dans la facture quand c’est le cas, et un Net à Payer (mention obligatoire dans la facture structurée conforme EN16931) effectivement égal au TTC diminué du montant déjà payé.

Tout ceci va conditionner l’adaptabilité du système de génération de factures, et sa capacité à être prêt à produire des factures électroniques structurées conformes.

 

IV        Les Formats de facture, ou données de factures

1        Les formats du socle minimal (le flux 2)

Jusqu’ici, je n’ai parlé que de modèle sémantique, car c’est le cœur du sujet pour aligner les systèmes de gestion sur un modèle commun.

La réforme oblige toutes les PDP et le PPF à être en mesure d’accepter les formats dits « du socle minimal ». En réalité il faut parler de profils implémentés dans les syntaxes UBL et UN/CEFACT CII (qui est aussi celle utilisée dans Factur-X), qui sont donc les suivants :

• 2 Profils UBL (EN16931 et EXTENDED-CTC-FR), qui sont identifiés au travers d’un champ de la facture (BT-24).
• 2 Profils UN/CEFACT CII (EN16931 et EXTENDED-CTC-FR), qui sont identifiés au travers du même champ de la facture (BT-24), avec la même valeur que pour l’UBL.
• Pour Factur-X, il s’agit d’une représentation lisible PDF à laquelle un fichier de données de facture structurées est attaché, dénommé factur-x.xml sous syntaxe UN/CEFACT CII avec les profils suivants possibles :
• EN16931, et le cas échéant BASIC, même si toute facture conforme au profil BASIC peut se revendiquer du profil EN16931.
• EXTENDED, plus large que le profil EXTENDED-CTC-FR, mais totalement conforme.
• BASIC WL, qui ne contient pas de données de lignes dans le fichier factur-x.xml. Il n’est autorisé qu’au démarrage de la Réforme.
• A ceci sera ajouté un profil dit « Key » (à confirmer), dédié à la capacité à construire une facture électronique autorisée au démarrage de la Réforme, issue d’un dépôt PDF simple, puis d’un processus d’extraction et validation de données minimum à transmettre à l’administration fiscale (l’équivalent du flux 1).

L’annexe 1 des spécifications externes décrit en même temps le profil EN16931 et le profil EXTENDED-CTC-FR. Pour plus de clarté, il sera utile de décrire chaque profil, directement dans la syntaxe qui l’implémente.

Les émetteurs sont libres de choisir le profil et le format qu’ils souhaitent. Pour que les destinataires puissent aussi disposer de leur format préféré, le PPF proposera une conversion entre les formats d’un même profil. Les PDP feront de même ou pourront proposer de faire de même. Par exemple, si l’émetteur transmet une facture UBL au profil EN16931, la plateforme du destinataire pourra la convertir en Factur-X EN16931.

Par contre, la conversion de Factur-X BASIC WL, voire « Key » en UBL ou en UN/CEFACT CII posera des difficultés puisque toutes les mentions obligatoires de facture ne sont pas sous forme structurée au démarrage. Il sera possible de créer un fichier de données de factures avec les données disponibles, mais l’obligation d’intégrité obligera à considérer que la Facture reste la facture sous format Factur-X reçue dans ce cas.

 

2        Les formats tiers (flux 3)

Les entreprises peuvent utiliser des formats tiers, qui ne peuvent s’échanger qu’entre PDP, sous réserve que la PDP émettrice et la PDP destinataire soient en capacité de les opérer et que leurs clients respectifs (Vendeur et Acheteur) acceptent de les utiliser. Ces formats tiers doivent aussi être suffisamment structurés pour permettre aux PDP d’effectuer tous les contrôles obligatoires de la Réforme et de garantir l’extraction de toutes les données requises par l‘Administration fiscale (le flux 1).

Ceci implique un alignement de ses formats tiers sur les formats du socle, pour ce qui est des mentions obligatoires et des règles de gestion de l’annexe 7 des spécifications externes. En pratique, il s’agit de formats existants, déjà déployés et proposant souvent une plus grande richesse de données, y compris des extensions allant au-delà de ce qui est décrit en annexe 1 des spécifications externes.

Les PDP qui les mettent à leur catalogue doivent être en capacité d’en produire une représentation lisible intégrale, comme c’est l’obligation des entreprises pour l’utilisation de factures électroniques structurées depuis plus de 30 ans.

 

3        La gestion du LISIBLE

La réglementation fiscale impose aux entreprises et aux PDP d’être en capacité de produire une représentation lisible des factures électroniques émises ou reçues.

Pour Factur-X, cette obligation est respectée nativement puisque ce format contient le lisible de la facture (le PDF qui sert d’enveloppe au fichier structuré de données au format UN/CEFACT CII).

Pour les formats UBL et CII, il sera possible pour l’émetteur de joindre une représentation lisible, qualifiée comme telle (LISIBLE), qui devra donc contenir TOUTES les informations présentes dans le fichier structuré de facture. Le destinataire pourra utiliser cette représentation LISIBLE pour remplir son obligation de lisibilité.

En cas d’absence, les PDP ou le PPF devront pouvoir générer des présentations lisibles intégrales et intègres des factures structurées échangées. Ceci constitue une obligation qui n’est pas simple puisqu’elle nécessite de maîtriser l’intégralité des formats structurés et de pouvoir en constituer une représentation semblable aux factures papier ou pdf dont tous les utilisateurs ont l’habitude.

Pour rappel, le modèle EN16931 contient 164 champs, dont 36 pour les lignes, et le profil EXTENDED-CTC-FR en contient environ 180 de plus, sans compter les éventuelles extensions additionnelles qui pourraient s‘avérer nécessaire pour répondre aux besoins de certains secteurs ou de certains cas d’usage (à titre d’illustration le profil EXTENDED de Factur‑X, issu des pratiques industrielles en place et des travaux de normalisation internationaux, comporte plus de 700 champs de données, le lisible étant généré par le vendeur qui sait quelles sont les données qu’il utilise dans sa facture).

Bien que l’ensemble de ces données aillent bien au-delà des mentions obligatoires, La DGFIP a confirmé l’obligation de produire une représentation lisible complète d’une facture électronique sous format structurée. En conséquence, le PPF n’acceptera de traiter que des factures structurées qui sont dans l’un des 2 profils décrits en annexe 1 (EN16931 et EXTENDED-CTC-FR), ainsi que Factur-X. Toute facture structurée en UBL ou UN/CEFACT CII qui contiendrait des données additionnelles devraient être rejetées par le PPF, et considérées comme des factures relevant de formats tiers, uniquement autorisés entre PDP qui acceptent de les traiter.

 

4        Les autres messages de données de facture (flux 1, 8 et 9, 10.1).

Dans les spécifications externes, il existe d’autres messages représentatifs de factures ou données de factures.

Il y a d’abord les flux d’informations de facture exigés par l’administration fiscale, à savoir le flux 1 pour les factures relevant du e-invoicing. Ce flux 1 n’est pas conforme à EN16931 puisque certaines données obligatoires dans la Norme EN16931 ne sont pas requises (notamment le Montant total TTC, le Net à Payer). C’est pourquoi il existe une description spécifique de ce flux 1 en annexe 1, sous syntaxes UBL et UN/CEFACT CII uniquement, avec 3 profils :

• Full : correspond à toutes les données exigées en cible
• Base : correspond aux données exigées en démarrage (pas les lignes ni remises et charges de niveau document), jusqu’à une date qui reste à préciser (septembre 2027 au plus tôt).
• Key : correspond aux données exigées dans le cas d’un dépôt PDF simple pour création d’une Factur-X. Il s’agit du profil Base avec quelques données en moins.

Ces flux 1 seront créés par les PDP ou le PPF uniquement.

Il existe ensuite un équivalent du flux 1 pour les factures relevant du e-reporting (B2B internationales ou B2C), à savoir le flux 10.1. Il est donc quasiment identique au flux 1 en termes de données à renseigner, mais dans un format propriétaire inventé à l’occasion de la Réforme par l’équipe projet DGFIP / AIFE.

Il y a enfin les flux 8 et 9 qui sont sensés correspondre respectivement aux factures émises ou reçues pour des transactions B2B internationales (Flux 8) et aux factures émises à destination de non assujettis (B2C).

Le PPF propose d’utiliser ces factures (structurées en UBL, UN/CEFACT CII, ou Factur-X) échangées par ailleurs, puisque le PPF ne les transmet pas, pour en extraire les données requises par l’administration dans le cadre du e-reporting.

Le flux 8 est en pratique extrêmement proche du flux 2 (socle minimal), à part l’obligation de fournir un SIREN de l’acheteur, tout en respectant l’ensemble des règles de gestion de la Norme EN16931 ou de l’extension EXTENDED-CTC-FR. Toutefois, sauf correction demandée à venir, la description de l’annexe 4 n’est pas strictement conforme à la Norme EN16931, et ne peut donc pas constituer la facture émise au destinataire, ce qui obligerait à modifier la facture émise ou reçue pour en faire un flux 8 tel qu’attendu par le PPF. Les PDP devront de toute façon créer un flux 10.1 à partir des factures internationales émises ou reçues conforme à la Norme EN16931, voire dans des formats tiers, de la même façon qu’elles extraient un flux 1 des factures relevant du périmètre e-invoicing. Dès lors, les entreprises utilisant le PPF peuvent s‘interroger sur le fait de produire directement (ou au travers de leur OD) des flux 10.1 pour reporter de leurs ventes ou achat B2B international.

Le sujet est à peu près le même pour le flux 9, s’agissant de factures B2C. Même si tout est envisageable, on imagine que des factures B2C électroniques structurées seront conformes EN16931 et intègrerons une représentation lisible. Il est probable que le format Factur-X sera largement utilisé pour ces flux. Les factures B2C n’ont pas d’obligation à être structurées. Elles peuvent donc rester papier ou simple PDF. Par contre, les données à reporter in fine en flux 10.1 dans ce cas sont beaucoup plus limitées (cf annexe 6, colonne « Données présentes en B2C ») et il peut être beaucoup plus simple de créer directement (ou au travers de son OD) le flux 10.1 adapté. De plus, lorsqu’il y a beaucoup de ventes B2C, il sera largement préconisé de passer en cumul de ventes B2C quotidien (flux 10.3).