Report de la réforme facture électronique et e-reporting

Je lis dans un certain nombre de posts et commentaires que la réforme est trop complexe, mais en réalité c’est la vie qui est complexe, et comme la réforme a pour ambition de traiter tous les cas d’usage, ceci introduit effectivement une complexité, qui est aussi une opportunité de mettre à plat un tas de pratiques « périphériques » maltraitées et maltraitantes pour les contreparties souvent fournisseurs, parfois acheteurs et presque toujours PME / TPE.

Cette réforme nécessite aussi de respecter la réglementation telle qu’elle existe depuis longtemps, mais qui n‘est pas toujours appliquée. Ceci se voit peu tant qu’on en reste à des déclarations périodiques de TVA, mais dès lors qu’on passe à un reporting plus régulier, pièce par pièce, basé sur les flux de facturation, ça ressort, ça dépasse, bref c’est la dette fonctionnelle qui remonte et se voit.

L’exemple des factures d’acompte est très instructif. Faire des factures d’acompte quand il y a paiement avant la livraison est une obligation du siècle dernier. Ne pas le faire ne se voit que lors de contrôles TVA, et il faut bien regarder. La réforme oblige à le faire vraiment et on voit que la plupart des systèmes d’information sont dans l’incapacité de gérer une facture d’acompte et une facture finale qui contient l’information nécessaire pour comptabiliser proprement la facture finale et reprendre l’acompte, ainsi que la TVA qui va avec. Cela nécessite soit d’ajouter des extensions à la Norme EN16931, ce qui est complexe car va pousser un grand nombre d’entreprises à passer au modèle de données étendu (puisque l’acompte est une pratique courante), soit de faire des reprises d’acompte en ligne de facture finale ce qui implique de comptabiliser à la ligne et plus en pied de facture comme ceci se pratique couramment encore.

La question qui se pose est « pourquoi ce sujet n’est il pas réglé puisque l’obligation a plus de 20 ans ». Dette fonctionnelle. Et une pratique courante par exemple dans le secteur des travaux (qui a fait appel à une entreprise pour rénover son habitat le voit bien), qui consiste à faire un devis, puis des factures d’acomptes qui ressemblent à des factures « d’avancement », et une facture de solde qui est « le reste » (une sorte de facture d’acompte de plus), ou bien pour les meilleurs, une vraie facture finale avec reprise de l’intégralité des travaux et toute la TVA et la reprise des versements d’acomptes en pied, chacun se débrouillant pour gérer sa TVA sans la compter 2 fois. On n’est assez loin de l’automatisation des traitements.

Et ce n’est là qu’un seul exemple.

En fait, cette réforme contient plusieurs volets qui ont des impacts très différents sur l’organisation des entreprises, et qui font appel à 2 types de compétences : 

• savoir gérer des flux documentaires avec des données structurées échangées avec un monde hétérogène, ce qui est le cœur de métier des opérateurs de flux de factures et documents de gestion (commande, devis, livraison, …), et déborde un peu sur a capacité des systèmes de facturation à gérer toutes les données des factures.
• savoir gérer des processus métier, incluant un cycle de vie mais aussi nécessitant des agrégations, des rapprochements, des workflow de validation, qui est le cœur de métier des systèmes de gestion (les ERP et leurs solutions périphériques).

Ces deux types de compétences n’ont pas la même maturité par rapport aux exigences de la réforme, ni la même agilité à évoluer (y compris du fait de la grande diversité des systèmes de gestion auxquels il faut inclure la bureautique, c’est-à-dire l’utilisation de word et excel pour schématiser).

Il me paraît donc important de bien distinguer les différents volets de cette réforme et d’en mesurer la complexité pour l’écosystème et la maturité à s’y confronter très vite.

1. Obligation de recevoir des factures électroniques.

Il s’agit d’obliger les entreprises à faire le choix d’un canal de réception de factures, sur un socle de formats restreint ET sachant que les PDP ou le PPF ont une obligation de production de présentation lisible des factures (par forcément très simple, mais ce sont des professionnels) permettant au destinataire de traiter ses factures « comme aujourd’hui ».

Il ne s’agit pas là d’une obligation très contraignante car la grande majorité des entreprises est déjà habituée à aller chercher ses factures sur des portails divers (et c’est d’ailleurs bien un problème). Il s’agit là d’en choisir un à soi plutôt que de se plier à ceux de ses grands fournisseurs, qui a vocation à devenir le canal très majoritaire.

Il s’agit néanmoins de la clé de voute de la réforme sur la partie e-invoicing, car sans cette obligation, l’obligation d’émission ne peut pas démarrer.

La seule raison d’un décalage sur cette obligation serait la non disponibilité du PPF et de PDP. S’agissant des PDP sur le périmètre e-invoicing, le sujet est plus sur le timing d’immatriculation que sur la capacité des acteurs à se positionner PDP sur le périmètre e-invoicing.

Celui-ci dépend directement de la disponibilité du PPF au plus tôt, du fait de l’obligation de démonstration d’interopérabilité des PDP avec le PPF (qui fait que le dossier d’immatriculation est complet), mais aussi parce que l’interopérabilité entre PDP dépend de la disponibilité de l’annuaire du PPF.

Par conséquent, le délai de report de la date de démarrage de l’obligation de réception dépend en premier lieu d’un éventuel retard du PPF a minima sur le périmètre e-invoicing (et donc annuaire, interopérabilité, puis traitement des factures e-invoicing, comme les PDP), sachant que le 1er juillet n’est pas forcément la plus opportune pour respecter une nouvelle obligation de ce type. 

2. Obligation de produire des statuts de cycle de vie.

En pratique, la difficulté porte essentiellement sur la gestion du statut “Refusée”. En effet, les statuts “Déposée” et “Rejetée” sont essentiellement fait par la Plateforme Émettrice, avec pour conséquence la transmission de la facture ou bien le rejet de la facture qui n’est donc pas transmise. Le Rejet en réception, qu’il faut bien prévoir, devrait normalement être de très faible occurrence puisque les contrôles sont censés être strictement les mêmes qu’à l’émission. Le débouclement consiste à annuler la facture dans le SI de l’émetteur, ce qui est normalement ce qui doit déjà se faire en cas de facture mal adressée par exemple. De plus, tout ceci est de la responsabilité des PDP et du PPF et assez clairement spécifié. 

Par contre, la gestion du statut “Refusée” doit tout d’abord être produit par l’entreprise destinataire, ce qui nécessite de transformer un processus de gestion interne, encore souvent manuel, en message électronique structuré de cycle de vie (qui vient juste d’être publié dans une version presque stabilisée).

Mais le statut « Refusée » a aussi un impact direct sur la pré-déclaration de TVA, avec anticipation de l’Avoir à venir par l’annulation de la TVA pour la DGFIP de la facture Refusée dès la survenance du statut « Refusé ». La nouveauté est donc qu’un statut de traitement vient impacter directement la comptabilisation et la déclaration de TVA.

De plus, ceci impose au fournisseur de produire un Avoir, et donc, de fait, d’accepter le Refus, sa seule option étant de refaire la même facture, mais avec une autre date de facturation et donc de paiement.

L’impact de cette mesure peut être important sur les délais de paiement. Il serait sage d’y réfléchir une seconde fois, soit en permettant de revenir sur un Refus, soit en donnant un délai de Refus, soit en obligeant que le Refus fasse toujours suite à une étape de “Litige” pour obliger une concertation (sauf en cas de Refus pour mauvais destinataire bien entendu).

D’ailleurs, si au lieu de Refuser, les Parties passent par une étape de “Litige”, une fois qu’elles sont d’accord, la production d’un Avoir, puis l’acceptation de l’Avoir et de la Facture par l’acheteur permet tout aussi bien de gérer la situation sans passer par un statut “Refusée”.

Le statut Encaissé nécessite un lettrage, ce qui n’est pas simple non plus, mais cette obligation relève du e-reporting sur lequel ce n’est pas la seule difficulté.

Les autres statuts fonctionnels sont très importants, mais peuvent être mis en œuvre dans un second temps si nécessaire. Ils ne sont donc pas contraints par le calendrier de la réforme.

3. Obligation d’émettre des factures électroniques en e-invoicing

Il s’agit là de savoir créer des factures électroniques avec des données structurées et conformes à la Norme EN16931. Ceci implique de s’assurer du respect des règles de gestion de la Norme, et de pouvoir positionner toutes les informations présentes dans ses factures dans le modèle EN16931 et ses extensions éventuelles. Ceci implique aussi de gérer de la bonne façon les remises et charges (sur Prix Unitaire, à la ligne, en pied de document), de fournir les bons motifs de remise et charge, de gérer tous les cas d’exonération avec les bons codes de raison, de calculer la TVA en pied et pas à la ligne, …

Heureusement, la réforme a prévu des niveaux d’exigences réduits : d’abord les données de niveau document (profil de flux 1 dit “Démarrage”), puis toutes les mentions obligatoires (profil flux 1 “Cible”). Ceci est rendu possible du fait du format mixte Factur-x, qui permet une association d’un lisible pdf complet et d’un fichier xml de données structurées partielles.

Pour bien enfoncer le clou, cette possibilité d’exigence progressive en données n’est pas ouverte pour l’UBL (ou le CII seul) qui oblige la présence de lignes de factures. Le choix de l’UBL oblige donc à fournir une facture structurée complète, conforme à EN16931 ou au profil Extended décrit dans les spécifications externes. Il peut y être associé une présentation lisible, mais celle-ci doit être le reflet stricte des données présentes dans l’UBL.

Grâce à cette tolérance, à laquelle s’ajoute celle de pouvoir créer une Factur-x à partir d’un dépôt PDF jusqu’en 2028, la création d’une facture électronique conforme devient nettement plus accessible rapidement.

L’entrée progressive de l’obligation permet de plus aux PME / TPE de pouvoir se préparer à passer de leurs outils bureautiques à des solutions de facturation conformes, avec pour valeur ajoutée significative le suivi du cycle de vie (bonne réception de la facture, acceptation / refus / litige / paiement), de façon universelle (donc sans avoir à se connecter à une multitude de portails acheteurs (ou P2P).

Il reste les différents cas de gestion qui ne sont que le reflet de la vraie vie qui conduisent à 2 conséquences:

• savoir traiter plus de données que la Norme EN16931 en contient en passant sur le profil “Extended”, sachant que ceci n’est nécessaire que pour des factures structurées (donc UBL / CII) et pas pour Factur-x qui garde sa souplesse sur les données à fournir.
• Savoir gérer des processus impliquant des tiers dans des cas d’usage qui sont déjà complexes et nécessitent une attention spécifique (qui peut toujours se faire simplement en choisissant la même PDP / PPF que le tiers), et l’autofacturation pour ceux qui le pratique (ceci étant soumis au calendrier d’entrée du fournisseur, souvent PME / TPE).

Là encore, si on peut comprendre de la nécessité d’un petit décalage de date d’entrée au plus tard dans cette obligation pour donner de l’air aux entreprises qui n’ont pas pris la mesure de la nécessaire préparation, la clé reste de ne pas décaler la capacité du PPF et des PDP à proposer leurs solutions, et donc à respecter la date de mise à disposition du PPF (e-invoicing, annuaire, immatriculation et interopérabilité).

Comme ceci s’est déjà observé pour le déploiement du B2G, on ne doute pas d’une certaine bienveillance en cas de retard d’entrée dans l’obligation de quelques mois.

Bref, donner un peu d’air et donc de délai tout en permettant à ceux qui sont prêts d’avancer dans le calendrier initial, ou presque.

4. Obligations de e-reporting

L’obligation de e-invoicing consiste à émettre ses factures sous forme électronique en s’appuyant sur le PPF ou une PDP.

L’obligation de e-reporting implique de reporter un détail des ventes à la journée (B2C), à la facture (B2B international), et aussi sur les acquisitions B2B internationales hors import de biens, avec un détail à la ligne dès 2026 pour des factures qui ne contiennent pas de lignes sous forme structurées, et qui peuvent être dans des langues très variées, voire avec des alphabets non latins.

Il est d’ailleurs assez étonnant que les retours des entreprises ou de leurs représentants n’aient pas mentionné plus ou plus fort cette « dinguerie » dans ce timing, ce qui démontre plus une méconnaissance de la réforme dans sa plénitude que l’acceptation tacite de cette obligation.

Rappelons en effet, que même à l’échelle Européenne, on peut espérer des factures électroniques avec détail de lignes sous forme structurée en 2028 au plus tôt (et ce, si la proposition de Directive ViDA est approuvée par les 27 sans décalage de la date 2028).

Les systèmes de gestion qui gèrent les lignes des factures d’achat le font en pratique par la gestion de bons de commande et le rapprochement d‘une facture avec la livraison dont elle est l’objet, en valorisant les lignes de commandes livrées et rapprochées (et donc pas en saisissant les lignes des factures).

L’obligation de e-reporting sur encaissement nécessite un rapprochement entre les encaissements et les factures, dans un monde où il existe des paiements groupés, voire des paiements partiels groupés. Il faut donc que les entreprises acceptent soit de payer unitairement leurs factures (et ce n’est pas un petit changement !), soit de fournir les avis de paiements qui sont les seuls permettant de lettrer convenablement (ce qui n’est pas une habitude très répandue, sauf pour quelques grandes entreprises). 

En pratique, Il s’agit là des obligations les plus impactantes pour les entreprises car elles doivent fournir un détail des déclarations de TVA avec des agrégats divers, dans des délais accélérés (tous les 10 jours pour des entreprises au régime normal mensuel).

Pour être plus précis, il y a 4 types d’obligations de e-reporting, qui sont autant de sujets de difficultés dans la production des données par les entreprises plus que dans leur regroupement en flux 10 confié aux PDP / PPF :

• Les cumuls de vente quotidiens B2C, qui nécessitent des évolutions significatives des systèmes d’information (logiciels de caisse) ou le développement de nouvelles applications de gestion des ventes B2C intégrant ces obligations (comme le Hackathon de Décembre 2022 l’a illustré). L’obligation d’une agrégation au niveau SIREN n’est pas non plus négligeable pour des entreprises utilisant des outils divers au sein de leurs établissements (en particulier certains grands distributeurs).
• Les données de factures de ventes B2B international : ceci paraît le plus accessible quand on a passé le cap de l’émission de factures B2B domestiques. Par contre, il faudrait que l’utilisation des flux 8 et 9 s’appuient bien sur des flux de factures émises et pas transformées pour répondre à des exigences spécifiques d’e-reporting (valeur de la BT-24 par exemple). L’obligation de regroupement et de conversion en flux 10.1 propriétaire constitue une complexité non négligeable pour les PDP. Il aurait été plus simple de permettre aussi la transmission de flux unitaires sous format UBL ou CII équivalent au flux 1 pour ces factures B2B internationales (on ne voit pas bien en effet ce qui diffère de la gestion de flux 1 unitaires pour le e-invoicing par le PPF de flux unitaires de flux 10.1 qui pourraient être en UBL ou CII). Il est probablement trop tard pour y revenir. Tant pis.
• Les données de factures d’achat internationales hors import de biens : déjà largement discuté ci-dessus. En rester plus longuement sur le périmètre  “Démarrage”, sans données de lignes, est un minimum (au plus tôt exiger les lignes en 2028, et si possible uniquement pour des factures qui sont électroniques avec les lignes en données structurées pour ne pas imposer une extraction / saisie à la ligne coûteuse).
• Les données d’encaissement sur factures ou ventes à l’encaissement : ceci paraît nécessaire, mais trouve sa source là encore au cœur des systèmes de gestion des entreprises (qui ne sont pas forcément des systèmes informatiques pour les PME / TPE, mais juste bureautique), avec une tâche de rapprochement accéléré facture / paiement (certes le fait que l’exigence ne soit que mensuelle sous 10 jours est mieux que tous les 10 jours sous 10 jours, mais ça reste une obligation difficile à gérer dans les temps, ne serait-ce que pour les encaissement de fin de mois (et on ne parle pas des périodes de congés annuels pour les PME).

A ceci, il convient d‘ajouter l’impact des cas d’usage, par exemple la gestion des frais des salariés, qui peuvent commencer en e-reporting pour le vendeur et finir en e-invoicing pour l’employeur, avec des enjeux sur la déductibilité de TVA sur ces frais.

… Et aussi le fait que les ateliers menés avec la DGFIP spécifiquement sur les impacts du e-reporting seront en septembre 2023, ce qui laisse penser qu’il y a encore pas mal de choses qui vont être comprises et découvertes dans les prochains mois.

Bref, tout ce volet est nettement moins mûr et maîtrisé par le plus grand nombre, et nécessite probablement un décalage de calendrier pour les dates d’entrée en obligation au plus tard.

De plus l’alignement à l’échelle européenne initié par la proposition de Directive ViDA fixe comme objectif 2028 comme cible d’alignement sur la partie e-reporting. Il y a donc matière aussi à mettre à profit les négociations internationales en cours pour coller au mieux au dispositif cible.

Ainsi, s’il fallait résumer :

• Le démarrage de la réforme commence avec la mise à disposition du PPF sur le périmètre e-invoicing, y compris l’annuaire et les preuves d’interopérabilité avec les PDP, et l’obligation de recevoir, et donc de choisir le PPF ou une PDP. C’est le point qui permet aux autres obligations de se mettre en place. La seule raison d’un report de la date de démarrage au delà de quelques mois pour passer l’été 2024 est un retard de livraison du PPF, dont on a du mal à croire qu’il aurait été connu fin juillet 2023. Le pilote est aussi dépendant probablement de ce report potentiel, mais aussi le processus d’immatriculation si la preuve d’interopérabilité ne peut être faite. On a quand même du mal à y croire.
• Le calendrier des obligations d’émettre est un calendrier “au plus tard”. Il peut être décalé pour donner un peu plus de temps, tant que ceux qui sont prêts peuvent l’anticiper. Une extension de la période de tolérance de données “Démarrage”, en pratique déjà poussée à fin 2027 pour le dépôt PDF à transformer en Factur-x, pourrait aussi laisser le temps aux entreprises d’apprendre à gérer toutes les données essentielles sous forme structurée.
• Le e-reporting nécessite certainement plus de travail d’étude et d‘appropriation des entreprises, avec un impact plus fort sur leurs systèmes d’informations et leurs processus de gestion. L’objectif d’alignement européen à 2028 laisse la possibilité de se donner du temps tout en restant en avance de phase sur la plupart des autres États Membres. D’ailleurs, on observe que l’Allemagne prévoit de commencer par l’e-invoicing et de passer au e-reporting en 2028.

Il y a donc probablement matière à recaler les calendriers de façon plus subtile et moins simpliste qu’un décalage de toutes les dates de X mois qui ne ferait que repousser la difficulté d’autant en perturbant ceux qui sont prêts, car il s’agit aussi pour les entreprises d’avancer progressivement, à leur rythme, en anticipant pour certaines, en dissociant e-invoicing et e-reporting pour d’autres, et en tirant profit d’un retour d’expérience en e-invoicing sur des flux domestiques pour aborder les flux B2B internationaux.

Cette réforme est aussi là pour lutter contre la fraude à la TVA. Il peut être alors important de confronter le calendrier aux objectifs de réduction de la fraude sur les différents volets : e-invoicing, e-reporting B2C, e-reporting B2B international, e-reporting sur paiement ? 

Il me paraît aussi important pour finir de saluer le travail des équipes en charge, tant à la DGFIP qu’à l’AIFE, devant un projet d’une envergure et d’un impact de transformation digitale des processus achat / vente des entreprises sans équivalent à l’échelle du pays. Les équipes sont loin d’être pléthoriques pour la partie gestion de projet et face aux enjeux annoncés tant de gains pour les entreprises que de réduction de la fraude à la TVA. Peut être un point d’attention pour la suite.

Enfin, il faut aussi que nous acceptions que tout ne sera pas défini et prévu avant de commencer. C’est par la pratique que de nouveaux cas vont se présenter. La Norme EN16931 n’a pas été conçue pour traiter tous les cas métiers, mais elle permet de les gérer au travers d’extensions. Et la pratique ne manquera pas de rendre nécessaire l’ajout de données dans le modèle, on le voit déjà. De même, tous les cas de gestion avec des tiers vont devoir s’expérimenter et s’affiner.

Il faut donc se lancer sans trop tarder et se préparer à entrer dans un mode d’amélioration continue maîtrisé et gouverné, ce qui implique aussi une certaine bienveillance des pouvoirs publics sur les cas qui n’auront pas été vus ou assez analysés et expérimentés.

Il reste un sujet non encore évoqué : l’exigence d’exploitation SecNumCloud en cas de sous-traitance d’hébergement (avec sa subtilité de PDP en marque blanche hébergée chez une autre PDP qui exploiterait avec ses propres moyens, et éviterait ainsi l’obligation SecNumCloud => à expliciter dans la documentation d’ailleurs). 

Il existe peu de solutions qualifiées SecNumCloud à ce jour et les offres d’hébergement SecNumCloud sur les technologies les plus avancées sont en cours de construction. Un report de cette exigence par exemple à 2026 serait aussi susceptible de desserrer les contraintes, cette fois pour les PDP.