E-reporting : un enjeu majeur de la réforme de la facture électronique

Les enjeux du e-reporting

1-1

L’article 26 de la loi de finances rectificative pour 2022 prévoit de soumettre les échanges entre entreprises assujetties à la TVA et établies en France à une obligation de facturation électronique (e-invoicing).

Les webinaires, ateliers, articles et ouvrages commentant la réforme de la facture électronique se multiplient à l’approche de sa prochaine application en septembre 2026. Le site impôts.gouv.fr publie en ligne et actualise des FAQ, présentations, spécifications fonctionnelles externes. De plus le Forum National de la Facture Électronique (FNFE) coordonne des échanges entre l’Agence pour l’Informatique Financière de l’État (AIFE) et les futures Plateformes de Dématérialisation Partenaires (PDP). Depuis 2020, l’accent a été mis sur le « e-invoicing » (factures électroniques entre assujettis à la TVA).
Enfin, depuis juillet dernier, les PDP communiquent sur leur immatriculation par l’administration fiscale. Nul doute qu’elles vont déployer un marketing offensif pour promouvoir leurs solutions auprès des entreprises.

Pour le e-reporting, la nouveauté réside d’abord dans l’obligation de transmission systématique, par les assujettis, des données sur les opérations taxées à une fréquence plus rapprochée que celle de la déclaration de TVA. Ces informations, structurées de façon à les rendre exploitables par l’informatique, vont permettre le contrôle quasi-continu par l’État des ventes et achats soumis à TVA. Les objectifs affichés sont une connaissance en temps réel de l’activité des entreprises et une détection de la fraude plus efficace. À terme, les obligations déclaratives des entreprises en matière de TVA devraient s’en trouver simplifiées grâce à un pré-remplissage des déclarations par la DGFIP à partir des informations transmises.

La réforme française de la facture électronique et du e-reporting s’inscrit dans une tendance mondiale de contrôle continu préconisée notamment par l’OCDE. L’administration fiscale souhaite suivre en temps réel les flux des opérations réalisées. Les obligations de e-invoicing et de e-reporting devraient permettre une connaissance quasi exhaustive des opérations réalisées par les entreprises.

Ces objectifs ne seraient pas atteints si l’obligation de transmission d’informations ne visait pas les opérations réalisées avec des non assujettis (particuliers ou professionnels exonérés). Afin de permettre la collecte d’informations sur les flux de TVA collectée relatives aux opérations B2C, la réforme instaure donc une obligation de transmission des données de transaction. De même, pour permettre à l’administration de vérifier l’exigibilité de la TVA, est introduite une obligation de transmission des données de paiement des prestations de service (B2B et B2C) à l’administration fiscale.

De fait, ce volet de la réforme reste le parent pauvre des débats entre professionnels et administration. Or, il concerne une partie non négligeable de la réforme et pose des questions pratiques, pour certaines non encore résolues. Pour les examiner et recenser les cas d’usage à transmettre à la DGFIP et à l’AIFE, un groupe de travail s’est constitué en juin dernier, sous l’égide de l’Académie des techniques comptables et financières et du CNOEC, en lien avec le FNFE, qui réunit des experts-comptables, avocats fiscalistes, certificateurs, éditeurs de logiciel et systèmes de caisse et représentants des entreprises concernées.

La télédéclaration des opérations de tous les assujettis va mettre en évidence à une échelle nationale l’application plus ou moins correcte de ces dispositions. En effet, alors que les éventuelles non-conformités n’apparaissaient jusqu’ici qu’à l’occasion d’une demande d’information ou d’une vérification de comptabilité, l’administration sera en mesure de détecter des incohérences entre les données du e-reporting et les déclarations de TVA.

Présentation des obligations de reporting

L’obligation d’e-reporting

1-2

Le e-reporting peut se définir comme la transmission à l’administration de certaines informations relatives à des opérations commerciales qui ne sont pas concernées par la facturation électronique. L’obligation de e-reporting ne se confond pas avec l’obligation de e-invoicing. En effet, cette dernière concerne l’ensemble des opérations d’achats et de ventes de biens et/ou de prestations de service réalisées entre des entreprises établies en France qui sont assujetties à la TVA dès lors qu’il s’agit d’opérations dites domestiques, c’est-à-dire qu’elles concernent le territoire national.

Il existe deux obligations de e-reporting qui sont codifiées aux articles 290 et 290 A du CGI : celle relative aux données de transaction et celle relative aux données de paiement (voir « La facture électronique », RF 2024-1, §§ 1100 et s.).

Concernant la date d'entrée en vigueur des obligations de reporting, voir RF 2024-1, §§ 6 et s.

Le e-reporting des données de transaction

Entités et opérations concernées

1-3

Entrent dans le champ du e-reporting des données de transaction, toutes les entreprises assujetties à la TVA qui sont établies en France lorsqu’elles réalisent des opérations avec des non-assujettis y compris des particuliers (BtoC). Les opérations entrant dans le champ du e-reporting, c’est-à-dire devant donner lieu à la transmission de données, sont les transactions dans lesquelles intervient soit une personne non établie en France, soit une personne non assujettie à la TVA (CGI art. 290 ; voir RF 2024-1, §§ 1100 et s.).

Le e-invoicing et le e-reporting étant des obligations complémentaires, il est parfois difficile de déterminer l’obligation à respecter pour une opération. Pour déterminer si l’opération entre dans le champ de la facturation électronique ou de la transmission d’informations à l’administration, le raisonnement suivant doit être tenu :
-dans un premier temps, il convient de déterminer le lieu d’établissement des parties à la transaction ;
-dans un second temps, les règles de facturation applicables ainsi que la territorialité de l’opération à la TVA permettent de déterminer le dispositif applicable. La facturation électronique s’applique aux transactions entre assujettis établis en France qui entrent dans le champ de la TVA en France et pour lesquelles les règles de facturation françaises sont applicables. Le e-reporting s’applique aux opérations listées à l’article 290 du CGI.

Par ailleurs, les opérations réalisées et taxables dans un autre État, dans lequel un assujetti établi en France serait identifié à la TVA pour les besoins de ces opérations, n’entrent ni dans le champ de la facturation électronique (e-invoicing), ni dans le champ de la transmission des données de transaction (e-reporting).

À noter
Certains cas particuliers (associations, TVA sur marge, e-commerce, utilisation du guichet unique, etc.) doivent faire l'objet d'une analyse approfondie afin de s'assurer de l'éventuelle obligation de reporting (voir RF 2024-1 ainsi que la documentation publiée par l'administration fiscale).

Les données attendues

1-4

Les données des transactions devront être transmises à l’administration par l’entreprise qui réalise l’opération, par l’intermédiaire d’une PDP ou via le portail public de facturation (PPF). Les spécifications fonctionnelles donnent à ces plateformes un rôle de concentrateur, connecté au PPF, pour lui envoyer les fichiers qu’elles reçoivent de l’entreprise. Mais elles ne confèrent pas à ces plateformes un rôle de constitution desdits fichiers. Rien ne s’oppose cependant à ce qu’elles proposent cette fonctionnalité, non prévue dans le cahier des charges de la DGFIP et de l’AIFE… si ce n’est des considérations pratiques et techniques.

L’entreprise devra donc collecter les données requises, les contrôler, les mettre en forme, générer les fichiers de reporting dans le format attendu et les transmettre dans les délais via les bons canaux. Ces travaux, qui peuvent s’avérer complexes, sont réalisables par un opérateur de dématérialisation spécialisé (OD) qui se chargera de récupérer les données, les retraiter et les agréger afin de constituer les fichiers e-reporting. Alternativement à l’envoi via une PDP, cet OD peut transmettre ces fichiers directement au PPF.

Dans le cas des transactions avec une personne non assujettie, les assujettis auront la possibilité de saisir en ligne un état récapitulatif des transactions réalisées sur la période.
Si l’entreprise émet des factures à l’international (B2Bi) ou des « facturettes » (documents ayant l’apparence d’une facture, sans les mentions obligatoires d’identification d’un acheteur professionnel, tel que SIRET, numéro de TVA Intracommunautaire) à destination de ses clients particuliers, elle pourra les déposer directement sous format du socle (Factur-X, UBL ou CII) sur la plateforme de dématérialisation partenaire qu’elle aura choisie ou sur le portail public de facturation. L’un ou l’autre se chargera d’extraire les seules données utiles au e-reporting pour les besoins de l’administration fiscale.
A contrario, même si ce mode est possible, les spécifications fonctionnelles indiquent clairement une préférence de l’AIFE pour recevoir des fichiers de reporting agrégés plutôt que des factures unitaires. Cette solution permet de réduire le nombre de fichiers à traiter par le PPF, ce qui réduit le coût des traitements pour l’État.
Agréger des facturettes B2C dans un fichier de reporting (flux 10.3), plutôt que les envoyer unitairement (flux 9 ou 10.1) devrait permettre aussi aux entreprises de réduire les coûts de transmission, dans la mesure où le modèle économique de nombreuses PDP repose sur un prix à la facture.

Les données attendues dans le cadre du e-reporting de transaction diffèrent selon qu’il porte sur les transactions B2B international ou les transactions B2C.

Concernant les opérations B2B international, les données à transmettre seront identiques dans leur forme sémantique et syntaxique à celles transmises dans le cadre du e-invoicing, à l’exclusion du numéro unique d’identification (SIREN) de l’assujetti non établi en France. Le n° TVA intracommunautaire ou un numéro de registre étranger remplacera le cas échéant le SIREN.
Pour rappel, les mentions obligatoires d’une facture sont définies à l’article 242 nonies A de l’annexe II au CGI (voir RF 2024-1, §§ 200 et s.). Dans le cadre du e-invoicing, certaines de ces données obligatoires doivent être transmises à l’administration fiscale sous format structuré. Ces données sont définies à l’article 41 septies D de l’annexe IV au CGI. En entrée de dispositif (démarrage : première vague de déploiement), 24 mentions obligatoires au maximum (certaines données ne doivent être transmises que dans certains cas : par exemple, l’option à la TVA sur les débits, la mention « autoliquidation ») (données ou blocs de données), hors mentions spécifiques à l’assujetti unique, doivent être transmises à l’administration, auxquelles se rajouteront des données en cible (dernière vague de déploiement). Ces données sont détaillées dans les spécifications externes (dossier de spécifications externes de la facturation électronique, 16/06/2024, version 2.4, pages 22-24).

Les entreprises auront la possibilité, pendant une phase transitoire jusqu’au 31 décembre 2027, de déposer des factures au format PDF non structuré sur leur plateforme. Une transformation devra être effectuée par la plateforme d’émission pour transmettre au destinataire une facture électronique dans l’un des formats structurés réglementaires. Afin de limiter la charge liée à la saisie ou la reconnaissance automatique des caractères (océrisation) de ces documents, à titre dérogatoire, le nombre des données structurées pourra être limité durant cette phase transitoire.

Concernant les transactions « BtoC », l’assujetti peut avoir à transmettre jusqu’à vingt-sept données, consolidées quotidiennement en provenance des différents systèmes d’encaissement et logiciels de facturation. Certaines seront plus délicates à réunir, comme la catégorie des transactions (distinction livraisons de biens / prestations de service (cf.infra)) et le nombre de transactions.

Les fréquences et délais de transmission

1-5

Les données de transaction attendues par l’administration fiscale doivent être envoyées selon des fréquences et des délais bien définis (voir RF 2024-1, § 1109).

L’obligation de e-reporting des données de paiement

Quelles opérations sont visées ?

1-6

Concernant ce deuxième e-reporting, seules sont concernées les données relatives au paiement des prestations de service, à l’exception de celles pour lesquelles le preneur est redevable de la TVA (opérations autoliquidées) et dans la mesure où l’entreprise n’a pas opté pour la TVA sur les débits. Plus précisément, selon l’article 290 A du CGI, les données de paiement attendues concernent les opérations qui sont soumises soit à la facturation électronique soit au e-reporting et qui sont des prestations de service. Les données relatives au paiement des livraisons de biens sont exclues du champ d’application de ce e-reporting.

L’objectif de cette seconde obligation de transmission est le pré-remplissage des déclarations de TVA et de détermination de la TVA collectée. Les données de paiement sur les prestations de service sont utiles pour la détermination de la TVA collectée de l’entreprise fournisseur. Ainsi, on comprendra que l’obligation de transmission des données de paiement soit supportée par l’émetteur de la facture.

Pour faciliter le suivi des données de paiement et leur exigibilité au regard de ce e-reporting, une nouvelle mention sur les factures a été ajoutée permettant de déterminer la catégorie de l’opération (livraisons de biens ou prestations de service).
Concernant les entreprises étrangères, seules celles, non établies en France, qui entrent dans le champ d’application de l’obligation de transmission de leurs données de transaction et qui réalisent des prestations de service sont soumises à l’obligation de transmettre leurs données de paiement.
Pour les données à transmettre voir RF 2024-1, § 1201.

Les modalités pratiques

1-7

D’une part, il existe une première série de questions relative aux échéances liées à ce second e-reporting. Les réponses dépendent du régime d’imposition de TVA de l’entreprise (voir RF 2024-1, § 1204).

D’autre part, la seconde série de questions porte sur les problématiques liées aux difficultés de paiement et acomptes.

En cas de paiement partiel, seul le montant encaissé est à transmettre. La donnée de paiement sera enrichie à chaque nouvel encaissement de la date et de son montant. Les données de paiement sont à transmettre à la date d’encaissement du paiement de la transaction quelles que soient les modalités de paiement choisies, hormis dans les cas prévus dans la doctrine administrative, notamment en cas de réception d’un chèque bancaire (BOFiP-TVA-BASE-20-20-§ 40-07/11/2018 : la TVA est exigible à la remise du chèque).
En cas d’impayés, il convient de distinguer l’hypothèse d’une prestation de service et celle d’une livraison de biens. Pour des impayés relatifs à des prestations de service, si le fournisseur de la prestation n’a pas opté pour les débits, la situation n’a pas de conséquence sur la transmission des données de paiement. En l’absence de paiement effectif reçu, aucune donnée de paiement ne doit être transmise. Pour des impayés relatifs à des livraisons de biens, il n’y a pas de transmission des données de paiement. Les données relatives aux paiements de livraisons de biens ne sont pas concernées par ce second e-reporting (BOFiP-TVA-DED-40-10-20-05/04/2017 : l’entreprise devra procéder à une correction a posteriori de la TVA collectée).
S’agissant des acomptes, tout assujetti est tenu de délivrer une facture pour les acomptes qui lui sont versés avant qu’une opération ne soit effectuée (sauf exception expressément prévue) (CGI art. 289 c). Depuis le 1^er janvier 2023, en cas de versement préalable d'un acompte, la taxe devient exigible au moment de son encaissement, à concurrence du montant encaissé tant pour les livraisons de biens que pour les prestations de service (CGI art. 269, 2 a). En cas d’acompte versé par un assujetti, la facture d’acompte devra faire l’objet d’une facture électronique et la donnée de son encaissement sera transmise par le biais du statut « encaissée ». En cas d’acompte versé par un non assujetti, le montant d’acompte perçu sera transmis par le biais d’un flux dédié.

Enfin, s’agissant des modalités de transmission des données, si l’opération à laquelle se rattache le paiement a fait l’objet d’une facture électronique, quelle que soit la qualité du destinataire, assujetti ou non, les données de paiement seront transmises grâce au complètement d’un statut « Encaissée » rattaché à la facture, en renseignant la date d’encaissement et le montant encaissé réparti par taux de TVA associés pour la facture.

Si l’opération à laquelle se rattache le paiement a fait l’objet d’une transmission de données de transaction, les données de paiement seront alors transmises grâce à un flux dédié spécifique sous format xml en renseignant la date d’encaissement, le montant encaissé réparti par taux de TVA associés pour la facture, la devise et le numéro de facture le cas échéant (question 12 partie e-reporting des données de paiement de la FAQ – Facturation électronique, version du 5 janvier 2024).

L’impact sur le système d’information et l’organisation des entreprises et des cabinets

Le cas du reporting des données de transaction « BtoC »

1-8

Comme évoqué précédemment, il s’agit de collecter les ventes à des non assujettis soumises à TVA ainsi que les ventes ou achats auprès de personnes non établies en France, puis de les regrouper quotidiennement par SIREN ou SIRET, et enfin de les transmettre dans un fichier unique comprenant, en fonction du régime de TVA applicable, dix jours (décade) ou un mois ou encore deux mois (bimestriel) de transactions.

Le processus de constitution des fichiers de e-reporting de transaction

1-9

A minima, on peut décomposer ce processus en cinq étapes : collecte, contrôle et corrections éventuelles, agrégation, mise au format requis, transmission.

Par ailleurs, les systèmes d’information utilisés pour enregistrer les ventes et produire les notes, tickets, factures varient selon la taille et l’activité des entités concernées. Une analyse, voire une cartographie sera nécessaire pour mesurer l’impact de la réforme sur ces systèmes.

Le cas des livres de caisse papier

1-10

Certes, les entreprises devront se doter de logiciels de facturation capables de générer des factures dans un des formats du socle pour continuer à vendre aux professionnels (e-Invoicing B2B). Néanmoins, à ce jour, l’assujetti reste libre de remettre des notes ou reçus destinés aux non-assujettis en format papier (carnet à souche numéroté) et d’enregistrer de façon manuscrite ses recettes dans un livre de caisse papier (a contrario, s’il utilise un système de caisse qui mémorise les paiements de non-assujettis, il devra s’assurer que celui-ci est certifié ou fait l’objet d’une attestation par son éditeur).

En ce cas, il lui faudra agréger les recettes quotidiennes en y renseignant les informations nécessaires au e-reporting. Dans ce but, une saisie annuelle des données sera possible sur le portail public de facturation. De même, les PDP et/ou les OD pourront proposer des services complémentaires facilitant la transmission des données de transaction. Une telle opération s’avérera vite chronophage, puisqu’il devra réunir, vérifier et saisir 300 à 600 lignes par mois et par application de facturation ou système de caisse, ce qui lui nécessitera plusieurs heures (sans compter la correction d’éventuelles erreurs).
On ne peut que recommander aux petits commerçants et vendeurs saisonniers non équipés d’investir dans une caisse (quelques centaines d’euros pour les premiers modèles certifiés) du fait du retour sur investissement inférieur à l’année. Rappelons cependant qu’il ne suffit pas d’utiliser un logiciel ou un système de caisse pour être en conformité avec la réglementation fiscale. Encore faut-il que ce dernier soit certifié ou attesté.

Toutefois la certification ou l’attestation des systèmes d’encaissement n’est pas suffisante pour permettre aux assujettis de répondre aux exigences de l’obligation d’e-reporting. En effet, les données exigées ne sont pas nécessairement présentes dans les caisses. Celles-ci devront évoluer ou des solutions complémentaires devront être apportées afin notamment de surmonter la difficulté qu’est l’identification de la catégorie de la transaction.

La problématique de l’hétérogénéité des systèmes d’information

1-11

La variété des systèmes émetteurs

Dans la pratique, il existe une multiplicité de systèmes de facturation et de caisse, reflétant les différents modes de commercialisation. Ces différents systèmes sont fabriqués et entretenus par des fournisseurs différents et reposent sur des formats de données souvent propriétaires (propres à l’éditeur).

À titre indicatif, le LNE et INFOCERT / AFNOR ont émis des certificats pour un peu plus de 700 systèmes de caisse. Or, on estime qu’il existe plus de 4 000 systèmes de caisse exploités en France, sans compter les applications spécifiques développées en interne.
À cela, il faut ajouter les logiciels de facturation utilisés à la fois pour les ventes aux particuliers et aux professionnels, qui consistent en des applications de facturations, mais aussi des solutions de gestion commerciale (« CRM ») plus évoluées, voire des ERP complets avec un module facturation et parfois encaissement. Toutes les architectures informatiques se rencontrent : installées sur les ordinateurs personnels (« on premise »), des tablettes et smartphones, fonctionnant en mode en client-serveur ou comme Software as a Service (SaaS), localisées en France, en UE ou hors UE (ce qui peut impacter la langue, mais aussi l’encodage et le format des données).
Bien que les éditeurs fassent évoluer leurs solutions, nombre de ces applications ne sont pas encore capables de générer des factures dans un des formats du socle, impératif pour le e-invoicing. De plus, la capacité à générer de telles factures ne répond pas aux exigences du e-reporting de transaction, sauf si l’entreprise adresse individuellement à une PDP ou au PPF ses factures destinées à des non-assujettis. Il reste à les agréger pour constituer le fichier de e-reporting, ce que devrait faciliter la présence de fichiers structurés.
Applications, CRM, ERP et systèmes de caisse peuvent avoir fait l’objet d’un paramétrage spécifique à l’entreprise utilisatrice, soit autant de variantes.
Enfin, tous les systèmes ne sont pas connectés à l’internet et donc en mesure d’envoyer des données à une PDP ou un OD.
À titre d’exemple, un hypermarché (voire un supermarché) utilise des caisses enregistreuses, dont les données sont souvent centralisées ; des balances connectées à des caisses ; des systèmes de caisse automatiques (« Self Check Out ») ; des caisses éventuellement différentes pour certains rayons ; un site de e-commerce, avec en option « un drive » ; des distributeurs automatiques ; des pompes à essences ; un système de lavage de voiture et une laverie automatique.
Une analyse s’impose donc des systèmes d’information impliqués dans la chaîne de facturation / vente aux non assujettis : Quels flux sont enregistrés avec quels systèmes ? Les données requises pour le e-reporting sont-elles présentes ou reconstituables ? Comment seront-elles générées et collectées ? Comment le fichier de e-reporting sera constitué ? En combien de temps ? Le système est-il capable de constituer le fichier au rythme imposé ? Qui adressera ce fichier et à quelle fréquence ?

Beaucoup d’entreprises devront adapter leur SI ainsi que leurs flux d’achat et de vente pour permettre l’envoi de l’intégralité des données exigées par l’administration fiscale.

En ce qui concerne les systèmes de caisse, ce sera l’occasion de vérifier leur conformité à l’article 286, I, 3° bis du CGI (certification ou bien attestation par l’éditeur). En effet, dans la perspective d’éventuels contrôles fiscaux, il convient de s’assurer que les données de caisse qui serviront au e-reporting, sont enregistrées dans les systèmes en respectant les obligations d’inaltérabilité, de sécurisation, de conservation et d’archivage. Cela garantira que la constitution des fichiers de e-reporting se fait sur des bases incontestables.

À cet égard, il faut souligner que le champ d’application du e-reporting de transaction B2C est plus large que celui de la législation sur les systèmes de caisse : la doctrine de la DGFIP tolère que certains systèmes échappent aux obligations de certification ou d’attestation. C’est notamment le cas du e-commerce, qui sous certaines conditions (BOFiP-TVA-DECLA-30-10-30-§§ 35 et 37-19/05/2021), n’y est pas soumis. L’entrée en vigueur du e-reporting conduira les sites de vente en ligne à faire évoluer leurs sites pour les mettre en conformité. C’est aussi le cas des factures à destination des particuliers émises à partir d’outils de bureautique (tableurs, traitements de texte, etc..), à condition qu’aucune donnée ne soit mémorisée. Cette pratique, fréquente dans les TPE, sera remplacée par l’usage d’applications de facturation « comptoir » ou de caisses enregistreuses, afin de faciliter la constitution du fichier de e-reporting.

1-12

L‘existence des données requises dans les systèmes d’information

Reste à savoir si les données à transmettre sont bien présentes dans le système… ce qui n’est pas toujours le cas.

Les spécifications fonctionnelles (dossier de spécifications externes de la facturation électronique, 16/06/2024, version 2.3, page 78) indiquent que « Le récapitulatif journalier édité à partir des systèmes de caisse dit « ticket Z » ou « Z de caisse » totalise l’ensemble des recettes et ventes du jour et la TVA, et peut donc permettre d’obtenir les informations nécessaires à la création du flux de e-reporting (XML) correspondant, notamment le nombre de transactions quotidiennes correspondant au nombre de tickets de caisse. »

Or, contrairement à la facture électronique, la notion de « Z de caisse » n’a jamais fait l’objet d’une quelconque définition et encore moins d’une standardisation de son contenu et de son format de fichier. Il s’agit d’une consécration de la pratique des éditeurs de caisses enregistreuses. Le Z de caisse est un rapport généré à la fin de la journée de travail, qui clôture la caisse et remet les compteurs à zéro. Le terme « Z » est utilisé parce qu'il représente la première lettre du chiffre zéro, symbolisant la remise à zéro de la journée de vente.
Le Z permet de vérifier les montants encaissés, voire décaissés, en comparaison de ce qui est présent dans le tiroir de caisse. Il permet aussi de regrouper les ventes par taux de TVA. L’évolution des besoins des commerçants en a fait un outil de contrôle pour les retours de marchandise, les annulations, voire le détail du chiffre d’affaires par employé, et parfois le résultat par famille de produit.
Par conséquent, chaque éditeur a sa propre conception de la notion de « Z de caisse », qui ne correspond pas forcément avec celle de la réforme (voir § 1-4). Parce que non requises par les usages commerciaux ou les exigences de certification, les données suivantes ne sont que rarement gérées : le SIREN du déclarant, l’option pour les débits, la catégorie de transaction, le nombre de transactions de la période.
Plusieurs questions, liées à des cas d’usage, se posent :
-Faut-il inclure les tickets annulés dans le décompte du nombre de transaction ?
-Comment définir la période dans les cas où les impératifs d’exploitation imposent une clôture quotidienne à cheval sur deux journées (fréquent en restauration ou stations-service) ?
-Comment gérer les journées sans activité ?
C’est pourquoi le groupe de travail de l’Académie des sciences comptables recueille actuellement les cas d’usages pour les soumettre à la DGFIP et réfléchit à une proposition de définition du Z de caisse.

1-13

Les difficultés d’agrégation des données de transaction

Ainsi qu’évoqué ci-dessus, une entité redevable du e-reporting peut utiliser plusieurs solutions informatisées différentes, en fonction des flux et de ses besoins. Cette situation se rencontre aussi dans des petites entreprises. Par exemple, dans un bistrot, la caisse dédiée aux ventes au bar peut différer de celle utilisée pour le service en salle. La génération du Z reste le plus souvent une opération manuelle (de même que la génération des archives fiscales des systèmes de caisse), initiée par le client, qui appuie sur la fameuse touche Z.

Il faudra donc collecter les données de chaque système et les agréger en un fichier unique, manuellement, ou automatiquement (ce que peut réaliser un OD).

Cette agrégation devra se faire au niveau du SIREN, ou éventuellement du SIRET, charge alors aux PDP ou au PPF de faire l’agrégation au niveau SIREN. Ce dernier mode ne sera possible que si aucune correction des fichiers n’est nécessaire pour distinguer des ventes, les factures B2B relevant du e-invoicing mais enregistrées dans les caisses, car certains modèles peuvent émettre des factures en compte à destination des professionnels (voire du secteur public). Idem dans le cas où des opérations sont enregistrées entre différents SIRET.
À l’échelle de certains groupes intégrés comportant plusieurs établissements, la préparation du fichier de e-reporting nécessitera un travail conséquent de consolidation et de vérification des données issues de plusieurs types de caisse localisés dans différents SIRET. Encore faudra-t-il s’assurer que les données de transaction collectées correspondent à des ventes comptabilisées sous un même SIREN, ce qui suppose d’inventorier les systèmes de facturation et de caisse utilisés pour chaque SIREN.

Les difficultés propres au e-reporting des données de transaction « BtoBi »

1-14

La première difficulté réside dans l’identification des achats internationaux (hors importations) entrant dans le champ du e-reporting. La seconde difficulté est liée au niveau de détail exigé par l'administration fiscale, les informations n’étant pas forcément présentes sur la facture.

Les entreprises ne peuvent pas toujours savoir avec certitude si elles achètent un bien ou service à un opérateur étranger. La complexité atteint son paroxysme lorsque vient s’intercaler une plateforme de commerce électronique ou un intermédiaire. En effet, dans une telle situation, la réponse à la question de la substance juridique dudit intermédiaire (transparent ou opaque), est souvent source d’interrogations (manques d’information, schémas complexes, etc.). On ne peut donc que recommander aux entreprises de se rapprocher de leurs conseils afin de sécuriser leurs transactions et leurs futures déclarations de reporting.

Quant au niveau de détail, il faut souligner que les vendeurs établis à l’étranger n’ont aucune obligation de fournir des factures dans l’un des formats du socle de la réforme française (UBL, CII, Factur-X). Les envois peuvent donc s’effectuer sous format papier ou par PDF simple. Ces factures ne sont donc pas reçues par le PPF. Les données exigées par l’administration devront donc être extraites par les redevables de l’obligation d’e-reporting (envoi aux plateformes via le flux 10.1). Si l’OCR est envisageable (notamment pour les mentions obligatoires de niveau « document »), la solution ne sera pas sans complexité et coût additionnel s’agissant des données de lignes. Quant au taux de reconnaissance, il peut varier selon les langues et les solutions d’OCR. À ce titre, une harmonisation des pratiques avec, au niveau européen, l’arrivée de la directive ViDA serait la bienvenue.

Les difficultés liées au reporting de paiement

1-15

La principale source de problème vient du rapprochement des paiements avec les factures de prestation de service (B2B, B2Bi) ou les notes justifiant des services faits pour le compte de particuliers. Rappelons que ce rapprochement doit se faire mensuellement et être envoyé via une PDP ou au PPF avant le 10 du mois suivant celui durant lequel les règlements ont été effectués.

Dans le cas d’un mandat d’autofacturation par le client (émission de la facture pour le compte du vendeur), le fournisseur doit compléter le statut « encaissée » de la facture lors du paiement.
On pourra objecter que ce rapprochement est réalisé dans les logiciels comptables ou de pré comptabilité qui proposent des modules de lettrage automatique ou manuel. Les critères de rapprochement se fondent généralement sur les montants, les dates, les libellés d’opération, les références de facture ou de pièce, les numéros de chèque. L’expérience montre cependant qu’il reste difficile d’automatiser intégralement le lettrage et qu’une partie des opérations doit faire l'objet d’un contrôle par les entreprises.
La qualité des fichiers transmis par les banques est très variable. Ainsi, les informations additionnelles saisies lors des virements pour identifier les numéros ou références de factures payées sont parfois tronquées, ce qui complique la récupération de l’information.
Les délais dans lesquels faire ces rapprochements sont réduits puisqu’antérieurs d’au moins 10 jours à la déclaration de TVA mensuelle. Ils ne sont pas habituels pour les entreprises bénéficiant de la franchise en base de TVA, ce qui va conduire à adapter les procédures internes de ces redevables.
Dans le cas des règlements enregistrés dans des systèmes de caisse, les informations de paiement devront être soigneusement saisies. Le contrôle régulier des soldes de caisse sera déterminant.

Les conséquences de certaines dispositions fiscales sur les paramétrages des systèmes d’information

E-reporting de transaction : les spécificités de Monaco et des DOM/COM

1-16

Les systèmes devront tenir compte des questions de territorialité, si ce n’est pas le cas actuellement.

Au regard de la territorialité des règles de TVA, il convient de distinguer trois groupes de territoires : la « France », l’« Union Européenne » et les « Pays tiers ».

Le territoire sur lequel s'applique la TVA au niveau national comprend notamment le territoire de Monaco défini par la convention douanière signée à Paris le 18 mai 1963. Conformément à cette convention, les règles nationales relatives à la TVA sur les importations sont directement applicables sur ce territoire et les règles relatives à la TVA sur les autres opérations sont introduites par ordonnances princières et reproduisent les dispositions nationales sous réserve des adaptations nécessaires.

Dès lors les assujettis établis à Monaco n’étant pas considérés comme établis hors de France aux fins de la TVA, les opérations réalisées en France par ou avec un opérateur monégasque constituent des livraisons internes qui pourraient rentrer dans le champ de la facturation électronique au sens de l’article 289 bis du CGI.

Cependant, les opérateurs monégasques n’étant pas immatriculés au registre du commerce et des sociétés français (répertoire SIRENE), seuls les assujettis monégasques inscrits auprès du SIE de Menton pour leur activité sur le continent seront dans l’annuaire et, in fine, dans le champ du e-invoicing. Pour les transactions avec des opérateurs monégasques non-inscrits au SIE de Menton, les opérations entrent dans le champ du e-reporting des données de transaction de l’assujetti doté d’un numéro SIREN (celui établi sur le territoire continental français). Un assujetti monégasque qui voudrait entrer dans le champ de la facturation électronique (e-invoicing) le pourra. Dès lors, l’assujetti français pourra échanger en e-invoicing avec cet opérateur. Dans ce cas, pour éviter une double transmission par l’assujetti établi en France et celui situé à Monaco, l’assujetti français n’aura plus à transmettre les transactions avec Monaco en e-reporting.

Pour des tableaux résumant le traitement des opérations impliquant les DOM et COM, voir RF 2024-1, §§ 1002 et 1102.

La distinction entre prestations de services et livraisons de biens

1-17

Pour être imposable à la TVA, l’opération doit consister soit en une livraison d’un bien corporel soit en une prestation de services. Pour rappel, avec l’obligation d’e-reporting, les entreprises et leurs conseils devront être en mesure de distinguer ces concepts, notamment pour le reporting de paiement.

Aux termes du II de l'article 256 du CGI, est considéré comme livraison d'un bien le transfert du pouvoir de disposer d'un bien corporel comme un propriétaire. La notion de prestation de services correspond, quant à elle, à une catégorie résiduelle qui vise les opérations autres que les livraisons de biens.

Or, cette distinction est fréquemment ignorée par les commerçants. Quant aux systèmes de caisse, ils sont rarement paramétrés en discriminant les services et les biens vendus.

Ainsi, par exemple, un restaurateur pourra avoir bien du mal à distinguer les ventes à consommer sur place de produits alimentaires ou de boissons qui constituent des prestations de services, des ventes à emporter pour lesquelles les règles de TVA applicables sont celles relatives aux livraisons de biens.

Une autre difficulté réside dans la gestion des opérations « mixtes » ou « complexes uniques ». Conformément au II de l’article 257 ter du CGI, il s’agit des activités dont « les éléments sont si étroitement liés qu’ils forment, objectivement, une seule prestation économique indissociable dont la décomposition revêtirait un caractère artificiel. ». En e-reporting non adossé à une facture et hors flux 10.1 « transmission de données de facture », l’émetteur devra définir la catégorie de l’opération pour la transmission des données de transaction.

Ainsi, une boutique de vêtements propose indépendamment de la vente de ses produits, un service de retouche sur-mesure. Les transactions sont réalisées au comptant avec un encaissement immédiat. Elles sont enregistrées par l’intermédiaire d’un logiciel ou système de caisse. Les données de paiement doivent être transmises pour les opérations relevant de la catégorie des prestations de services afin de pouvoir déterminer l'assiette de la TVA. À la suite de la vente, si un produit doit être retouché, la retouche est considérée comme accessoire à la vente. Elle ne fera donc pas l’objet d’une déclaration e-reporting de paiement. En revanche, si un client souhaite faire retoucher un vêtement (acheté dans le cadre d’une autre transaction), alors cette retouche sera considérée comme principale et fera l’objet d’une déclaration e-reporting de paiement, si exigible, à hauteur des services facturés.
Attention, les entreprises ne devront pas confondre les opérations « mixtes » et les opérations « doubles » qui concernent une facture comprenant à la fois une livraison de bien et une prestation de service. Bien qu’une catégorie d’opérations doubles soit prévue parmi les données obligatoires à transmettre à l’administration pour tenir compte des pratiques des opérateurs, il est recommandé, autant que possible, d’établir des factures séparées pour les livraisons de biens et les prestations de services, compte tenu des règles d’exigibilité différentes, afin d’identifier à quelles opérations se rapporte le e-reporting de paiement.

Les « effets de bords » du e-reporting sur la comptabilisation et la justification des opérations

E-reporting de transaction et tolérance des écritures récapitulatives

1-18

Selon l’article R. 123-174 du code de commerce, « les mouvements affectant le patrimoine de l'entreprise sont enregistrés opération par opération et jour par jour pour le livre-journal. Tout enregistrement comptable précise l'origine, le contenu et l'imputation de chaque donnée ainsi que les références de la pièce justificative qui l'appuie. ». L’article 921-2 du Plan Comptable Général (PCG) va dans le même sens puisqu’il dispose que les mouvements affectant le patrimoine de l'entité sont enregistrés sur le livre-journal « jour par jour, opération par opération ».

S’agissant du Fichier des Écritures Comptables (FEC), l’organisation du système de traitement doit permettre de reconstituer, à partir des pièces justificatives, la permanence du chemin de révision comptable entre les écritures comptables et lesdites pièces justificatives (PCG art. 911-3). Les écritures de centralisation (une écriture de centralisation est une écriture de report mensuelle (ou d’une autre périodicité) des écritures détaillées des opérations jour par jour figurant dans les journaux auxiliaires) doivent, a priori, être écartées au bénéfice du détail ligne à ligne de chaque opération comptable enregistrée dans les différents journaux du système informatisé (BOFiP-CF-IOR-60-40-20-§ 60-07/06/2017).

La doctrine administrative ajoute qu’en application du I de l’article L. 47 A du LPF, le contribuable qui tient sa comptabilité au moyen de systèmes informatisés doit la présenter sous forme dématérialisée à l’administration fiscale, lors du contrôle sur place, en remettant, pour chaque exercice contrôlé, un fichier des écritures comptables conforme aux normes définies par l’article A. 47 A-1 du LPF. Ledit fichier doit comprendre toutes les écritures comptables hors écritures de centralisation (BOFiP-CF-IOR-60-40-20-§ 63-07/06/2017).

La combinaison des textes précités avec la position de l’administration fiscale pourrait laisser penser que les contribuables devraient comptablement enregistrer chaque opération et donc chaque ticket ou transaction de manière distincte. En pratique, pour des raisons de productivité comptable, la plupart du temps, seule une écriture de vente journalière ou mensuelle s’appuyant sur le « Z de caisse » est réalisée. Les contribuables justifient alors ces écritures par la production des bandes et tickets de caisse ou de données de caisses en cas de demande de traitement informatisé dans le cadre d’un contrôle fiscal.
Plusieurs aménagements légaux et doctrinaux ont entériné cette pratique consistant à n’enregistrer que des écritures récapitulatives agrégeant les ventes enregistrées dans les systèmes et logiciels de caisse. Les mouvements affectant le patrimoine de l’entité peuvent être enregistrés « par récapitulation au moins mensuelle des totaux des opérations, à la condition de conserver tous les documents permettant de vérifier ces opérations jour par jour, opération par opération. » (PCG art. 921-2). Selon l’article R. 123-174 précité, « les opérations de même nature, réalisées en un même lieu et au cours d'une même journée, peuvent être récapitulées sur une pièce justificative unique ».
Selon l’administration fiscale (BOFiP-CF-IOR-60-40-20-§ 65-07/06/2017), si le détail de certaines écritures comptables est contenu dans des applications métiers de l’entreprise et non dans des modules annexes au module de comptabilité générale, les écritures agrégées issues de ces applications sont acceptées (par exemple : montant agrégé des cotisations d’assurance émises, mouvements de consommation sur stock, etc.).
Le service du contrôle fiscal de la DGFiP a confirmé fin mai 2019 au Conseil supérieur de l'Ordre des experts-comptables qu’il qualifiait de « logiciels métier » les logiciels et systèmes de caisse. En effet, dans une lettre du bureau du contrôle fiscal adressée au CSOEC en date du 28 mai 2019, l’administration fiscale indique que le « Z de caisse » peut être utilisé pour enregistrer une écriture journalière ou mensuelle.
Si rien ne semble s’opposer au passage d’écritures récapitulatives journalières, les écritures récapitulatives mensuelles nécessitent une plus grande vigilance. Les écritures récapitulatives mensuelles sont autorisées dans la mesure où le contribuable conserve tous les documents, pièces et données de caisse de nature à justifier les opérations jour par jour et opération par opération
En outre, avec la future obligation d’e-reporting, les entreprises soumises au régime réel normal mensuel devront transmettre à l'administration leurs données de transaction (et notamment de caisse) par décade.
Pour faciliter l’identification des z enregistrés comptablement et leur concordance avec les fichiers de e-reporting transmis, il nous semble préférable d’enregistrer chaque Z quotidien, voire chaque décade. Afin de garantir le chemin de révision, nous suggérons d’utiliser comme référence de pièce le numéro SIRET de l'établissement où se trouve la caisse, suivi de l’indication de la période concernée, complété par le numéro de la caisse dans le cas de l’utilisation de plusieurs systèmes dans le même établissement.
Il faut de plus insister sur les obligations de conservation des données de caisse et de logiciels de facturation B2C aussi bien que B2B (LPF art. 102 B). La mise en œuvre d’une procédure d’archivage à valeur probante permettra la restitution des données de chaque décade ou mois en cas de contrôle fiscal. C’est pourquoi, on peut recommander de procéder à l’archivage de ces données parallèlement au reporting par décade ou mois. Ce d’autant qu’un contrôle TVA peut intervenir en cours d’exercice et porter sur les dernières déclarations adressées. Or la DGFIP pourra détecter certaines incohérences entre le reporting et la CA3.
À cet égard, il faut alerter les entreprises sur le fait que la plupart des systèmes de caisse ne génèrent pas automatiquement de fichier d’archive. Cette génération est initiée par l’utilisateur (parfois même sur demande par l’éditeur). Jusqu’ici, la doctrine de l’administration impose un archivage annuel ou à chaque changement ou purge de système.

Tolérance de validation des écritures comptables fondant les déclarations de TVA

1-19

Autre tolérance qui sera, sans aucun doute, source de discussions avec l’administration fiscale voire d’insécurité juridique : celle concernant la validation des écritures comptables fondant les déclarations de TVA. Aucun texte n’induit directement d’obligation de validation des écritures par décade. En revanche, cette validation est en principe obligatoire mensuellement puisque fondant une déclaration fiscale (CA3).

Dans des conditions strictes, la DGFiP autorise néanmoins les experts-comptables qui ont des missions de tenue de comptabilité de certains de leurs clients et établissent leurs déclarations de TVA à pouvoir valider les écritures comptables justifiant ces déclarations au plus tard seulement au moment de l'envoi de la liasse fiscale annuelle, et non pas au plus tard à la date du dépôt des déclarations de TVA trimestrielles ou mensuelles (lettre du Conseil supérieur de l'Ordre des experts comptables à ses membres, juin 2018). Cette date de validation, qui indique le caractère inaltérable des écritures (aucune modification de l’écriture n’est possible suite à sa validation), doit figurer dans le FEC.

Selon la lettre du Conseil supérieur de l'Ordre des experts comptables à ses membres :
« Dans le cas où le contribuable a confié la tenue de sa comptabilité à un professionnel de la comptabilité non salarié qui est également chargé d’établir ses déclarations de TVA, et si ces déclarations de TVA ne sont pas générées intégralement à partir des écritures de la comptabilité, il est admis, sous condition, que les écritures relatives à la période objet de la déclaration ne soient pas saisies ou validées au moment du dépôt de celle-ci.
Seuls sont concernés par cette tolérance les contribuables suivants :
-réalisant des recettes inférieures à 1 500 000 euros (ventes) et 600 000 euros (prestations de services) dans la catégorie des bénéfices industriels et commerciaux ou pour les entreprises soumises à l’IS ;
-réalisant des recettes inférieures à 600 000 euros dans la catégorie des bénéfices non commerciaux ;
-réalisant des recettes inférieures à 700 000 euros dans la catégorie des bénéfices agricoles.
Dans cette situation, le contribuable doit indiquer dans la notice explicative fournie avec le FEC toutes les circonstances de la tenue de sa comptabilité, ainsi que les modalités d’établissement et de dépôt de ses déclarations TVA. Il doit également transmettre, en même temps que le FEC et sa notice, un rapprochement entre les déclarations de TVA et la comptabilité. Enfin, les écritures comptables relatives à la TVA doivent en tout état de cause être validées à l’expiration du délai de dépôt de la liasse fiscale.
Il est rappelé qu’en cas d’extension de la vérification à la TVA ou à un autre impôt, le FEC remis au vérificateur doit contenir toutes les écritures validées dans un délai convenu avec ce dernier. En cas de difficulté, il convient de s’entretenir avec le vérificateur ».
Rappelons que les systèmes de caisse sont supposés garantir l’inaltérabilité et la sécurisation des données enregistrées. L’entreprise doit s’assurer que ces données concordent avec le fichier de e-reporting et les écritures comptables.
Par ailleurs, les spécifications fonctionnelles prévoient la possibilité de transmettre dans le fichier de reporting d’une période ultérieure des correctifs, en cas d’erreur. Il faudra s’interroger sur leur incidence éventuelle sur la comptabilisation des Z de caisse et les déclarations rectificatives, lorsque ces corrections sont transmises postérieurement à l’envoi de la CA3 de la période concernée par l’erreur. Ce point fait l’objet d’une analyse par le groupe de travail précité.

L’indispensable diagnostic du niveau de conformité de l’entité redevable

1-20

Les obligations de e-reporting et de facturation électronique sont un pas supplémentaire dans la digitalisation des entreprises. L’administration fiscale aura désormais la possibilité d’analyser en temps réel des données clés envoyées par les entreprises afin d’améliorer la détection de fraudes, au bénéfice des opérateurs économiques de bonne foi. Il reste que ces nouvelles obligations s’anticipent et les acteurs économiques se doivent d’être accompagnés sur ces sujets afin de maintenir leur conformité fiscalo-comptable.

À partir des codes NAF des entreprises susceptibles de vendre des biens ou services à des particuliers et de la base de données ESANE de l’INSEE, on peut estimer le nombre d’entités concernées par le e-reporting de transaction B2C à au moins 2,2 millions, dont la plupart sont assujetties à la TVA. Quant aux entreprises qui acquièrent des biens ou services à l’international, il est difficile à appréhender… rares sont celles qui n’ont pas acheté sur des sites de e-commerce. L’enjeu est donc très important.
Un état des lieux de chaque entreprise s’impose, dans le but de répondre aux questions suivantes : L’entité est-elle concernée par le reporting de transaction ? Par le reporting de paiement ? Si oui, quand ? Qu’en est-il de ses fournisseurs internationaux ? Peut-elle générer les fichiers nécessaires, avec les contenus adéquats, dans les formats requis et dans les délais prévus par les textes ? Faut-il adapter les systèmes d’information (facturation et systèmes de caisse) ? Comment télédéclarer les fichiers de e-reporting ? via une PDP, un OD et le PPF ?
Ce diagnostic doit aborder tant les aspects juridiques, comptables et fiscaux que les aspects techniques tels que l’évolution du SI, la sécurité des données, l’archivage à valeur probante ou encore la conformité des systèmes d’encaissement ce qui revient à construire une vision à 360 degrés du sujet. Si la réalisation « manuelle » de ce diagnostic est tout à fait possible, elle n'en demeure pas moins très coûteuse en temps (au moins une dizaine d’heures pour une TPE, avec plusieurs échanges avec le client). Compte tenu de la pluridisciplinarité et de la technicité exigées pour appréhender cette réforme, les acteurs auront tout intérêt à se tourner vers des solutions automatisées de diagnostic.
Par ailleurs, les entités concernées doivent se pencher sur le modèle économique des acteurs (PPF et/ou PDP et/ou OD) : gratuité des services ? coûts cachés ? etc.
La question de la réversibilité des données est essentielle. En effet, l'entreprise peut-elle changer simplement de PDP et/ou d'OD ? Comment et sous quel délai s'effectue la réversibilité ? Existe-t-il des coûts à la sortie ?
Les entreprises vont devoir comparer les offres des PDP et des OD, afin de trouver les solutions les plus adaptées à leurs process de facturation et de reporting.

La Commission européenne envisage déjà d’accentuer les obligations des redevables. Elle a proposé le 8 décembre 2022 différentes mesures dans le cadre de son projet de réforme du système de TVA via un nouveau projet de directive (« VAT in the digital age » ou « VIDA »). Ce projet « ViDA » vise à moderniser les règles de TVA pour répondre aux défis numériques en incluant notamment la modernisation des obligations déclaratives via la généralisation des obligations de e-reporting et de e-invoicing. À l’heure actuelle, les États membres de l’UE ne sont pas parvenus à un accord politique sur l’ensemble du projet de Directive ViDA. Il reste qu’un consensus a été trouvé sur le pilier relatif aux obligations d’e-invoicing et d’e-reporting.

La nouvelle obligation européenne de e-reporting (digital reporting requirement : DRR) sera à accomplir auprès de la DGFIP au moment de l'émission de la facture (cinq jours après l'émission de la facture en cas d’autofacturation, pour les achats soumis au mécanisme d'autoliquidation ainsi que pour les acquisitions intracommunautaires). Les États membres pourront (et c’est déjà le cas de la France) également mettre en œuvre des exigences de e-reporting pour les transactions B2B qui ne relèvent pas de l’obligation européenne (par exemple, les transactions nationales). La réforme de la facture électronique, dans son volet e-reporting, permet à la France d’anticiper cette évolution.

Les positions et opinions émises dans cette rubrique n'engagent que leur auteur.