Source: https://uzan-avocat.fr/l-obligation-d-utiliser-des-logiciels-et-des-systemes-de-caisse-securises
Timestamp: 2020-07-10 19:04:47+00:00
Document Index: 201560813

Matched Legal Cases: ["l'article 88", "l'article 286", 'art. 293', '§ 10', '§ 40', 'art. 286', '§ 120', '§ 50', '§ 90', '§ 90', '§ 250', '§ 160', '§ 220', '§ 170', '§ 250', '§ 550', '§ 300', '§ 310', '§ 360', '§ 570', "l'article 57"]

Rédigé par Marc Uzan - 31 octobre 2019 - Aucun commentaire
Dans le cadre de la lutte contre les fraudes à la TVA, l'article 88 de la loi de finances pour 2016 a prévu que, à compter du 1er janvier 2018, les assujettis à la TVA qui enregistrent les règlements de leurs clients au moyen d'un logiciel de comptabilité ou de gestion ou d'un système de caisse ont l'obligation d'utiliser des logiciels ou des systèmes remplissant des conditions d'inaltérabilité, de sécurisation, de conservation et d'archivage des données. Ces conditions doivent être attestées par un certificat délivré par un organisme accrédité ou par une attestation individuelle de l'éditeur.
Le 15 juin 2017, le ministre de l’action et des comptes publics a décidé de réduire le champ d’application de cette obligation. Seuls les logiciels et systèmes de caisse, principaux vecteurs des fraudes constatées à la TVA, seront en définitive concernés par les mesures de sécurisation. Le projet de loi de finances pour 2018 modifie en ce sens l'article 286, I.3° bis du CGI.
L'administration a commenté cette mesure dès 2016.
Dans l'attente du vote définitif de la loi de finances pour 2018 et compte tenu de l'entrée en vigueur du dispositif maintenu au 1er janvier 2018, l’administration a publié sur Internet une foire aux questions (ci-après dénommée FAQ) dans laquelle elle donne des indications pratiques sur la mise en œuvre du dispositif compte tenu de la réforme envisagée (https://www.economie.gouv.fr/files/files/directions_services/dgfip/controle_fiscal/actualites_reponses/logiciels_de_caisse.pdf).
Les précisions données dans ce document ne constituent en aucune façon une doctrine opposable à l’administration. Ils sont un simple descriptif réalisé par votre avocat fiscaliste.
Selon le projet de loi de finances pour 2018, l'obligation s’appliquerait aux assujettis qui effectuent des livraisons de biens et des prestations de services ne donnant pas lieu à facturation et enregistrent ces opérations au moyen d’un logiciel ou d'un système de caisse. Les opérations entre assujettis à la TVA (B to B), qui doivent obligatoirement faire l’objet d’une facturation, seraient donc exclues.
Les assujettis bénéficiant d’une franchise en base de TVA (CGI art. 293 B) et ceux effectuant exclusivement des opérations ou des prestations exonérées de taxe seraient dispensés de cette obligation, consultez un avocat fiscaliste pour plus de précisions.
Le dispositif s’applique quel que soit le mode de règlement du client, espèces, chèques ou carte de crédit (FAQ, question 11)
Les succursales et filiales de sociétés étrangères sont dans le champ d’application de l’obligation de détenir un logiciel ou un système sécurisé (FAQ, question 6). Par mesure de tolérance, les entreprises étrangères immatriculées à la TVA non établies en France sont hors champ d’application du dispositif (FAQ, question 7).
Pour les sociétés relevant du e-commerce (FAQ, question 9), les situations suivantes sont susceptibles de se présenter. Les sociétés soumises à facturation du fait que leurs clients sont assujettis à la TVA (B to B) ne relèvent pas du champ d’application du dispositif. Sont en revanche concernées les sociétés du e-commerce :
-non soumises à facturation du fait que leurs clients ne sont pas assujettis à la TVA (B to C) ;
-s’adressant à la fois aux clients assujettis à la TVA (B to B) et aux non assujettis (B to C).
L’obligation de détention du certificat ou de l’attestation ne concerne que les assujettis qui enregistrent eux-mêmes les règlements de leurs clients (BOFiP-TVA-DECLA-30-10-30-§ 10-03/08/2016).
Les solutions techniques permettant de réaliser par une plate-forme sécurisée de paiement (PSP) la prestation d’intermédiaire de paiement entre le client et le commerçant en ligne ne sont pas dans le périmètre de la certification (FAQ, question 36). Le particulier qui fait du e-commerce reste en dehors du champ d’application de l’obligation tant qu’il est non assujetti à la TVA (FAQ, question 8).
LOGICIELS ET SYSTÈMES CONCERNÉS
La fonctionnalité de caisse du logiciel constitue un critère prédominant
Un logiciel ou un système de caisse est un système informatisé dans lequel un assujetti enregistre les livraisons de biens et les prestations de services ne donnant pas lieu à facturation (BOFiP-TVA-DECLA-30-20-10-13/01/2014). Il s'agit donc d'un logiciel ou d'un système dans lequel un assujetti enregistre les opérations effectuées avec ses clients non assujettis (FAQ, question 1). En conséquence, les logiciels ou systèmes de caisse dans lesquels sont enregistrées les opérations effectuées avec des clients assujettis à la TVA (B to B) ne sont pas concernés par ce dispositif. En revanche, doivent satisfaire aux conditions de sécurisation posées par ce dispositif :
-les logiciels ou systèmes de caisse dans lesquels sont enregistrées les opérations effectuées avec des clients qui ne sont pas assujettis à la TVA (B to C) ;
-les logiciels ou systèmes de caisse dans lesquels sont enregistrées à la fois les opérations effectuées avec des clients assujettis à la TVA (B to B) et des non assujettis (B to C).
En d’autres termes, ce n’est pas tant la qualification du logiciel qui importe (de caisse, comptable ou de gestion), mais plutôt sa fonctionnalité de caisse. Par conséquent, un logiciel de gestion qui permet l’enregistrement des opérations de ventes ou de prestations de services qui concernent les non assujettis à la TVA (B to C) est un logiciel ou un système de caisse qui doit satisfaire aux conditions de sécurisation.
Remarques. Concernant les logiciels multi fonctions (comptabilité/gestion/caisse), seules les fonctions caisse enregistreuse/encaissement, et non l’ensemble du logiciel, devront être certifiées (FAQ, question 2), ce qui peut générer des questions au cas par cas à traiter avec un avocat fiscaliste.
Les logiciels monétiques, ou terminaux de paiement électroniques, sont des appareils électroniques capables de lire les données d’une carte bancaire, d’enregistrer une transaction, et de communiquer avec un serveur d’authentification à distance, Par conséquent, les stricts terminaux de paiement sont exclus du champ d’application du dispositif (FAQ, question 10).
Pas d’obligation d’acquérir un logiciel de caisse sécurisé
Le choix de l’utilisation d’un logiciel sécurisé appartient à chaque assujetti. En conséquence, les nouvelles dispositions ne créent pas d’obligation de s’équiper d’un tel logiciel ou d’un système de caisse (FAQ, question 15). Cependant, si l’assujetti décide d’avoir recours à un logiciel disposant de fonctionnalités de caisse pour enregistrer les règlements de ses clients, il entre dans le champ d’application du dispositif. Dans ce cas, il est tenu d’utiliser un logiciel répondant aux conditions d’inaltérabilité, de sécurisation, de conservation et d’archivage des données.
L’assujetti est libre d’utiliser deux modes d’enregistrement des règlements de ses clients, l’un informatisé et l’autre papier. Cependant, dès que l’assujetti a recours à un logiciel disposant de fonctionnalités de caisse, il entre dans le champ d’application de l’obligation de détenir un logiciel de caisse sécurisé. Il devra alors présenter le certificat délivré par un organisme accrédité ou l’attestation individuelle de l’éditeur pour le logiciel de caisse utilisé (FAQ, question 16).
Logiciels libres, propriétaire ou développé en interne
Les logiciels dits libres ou développés en interne permettent aux utilisateurs d’adapter le logiciel à leurs besoins spécifiques. Les modifications que les utilisateurs peuvent apporter à ces logiciels ne doivent pas avoir pour objet ou pour effet d’altérer le respect des conditions d’inaltérabilité, de sécurisation, de conservation et d’archivage des données en vue d’un contrôle de l’administration fiscale (FAQ, question 12). Un logiciel libre est un logiciel dont les utilisateurs ont un libre usage, une libre étude, une libre modification et une libre distribution. Un logiciel développé en interne est un logiciel développé par l’assujetti lui-même ou par une société membre du groupe ou par un intégrateur externe (BOFiP-TVA-DECLA-30-10-30-§ 40-03/08/2016). Ces logiciels sont distingués des logiciels propriétaires, qui ne permettent pas légalement et techniquement d’exercer les quatre libertés évoquées ci-dessus (FAQ, question 12).
Incidence sur les systèmes de pesage utilisés par l’entreprise
Si le système de pesage et d’encaissement du commerçant ne peut pas être certifié ou faire l’objet d’une attestation, celui-ci doit alors s’équiper d’un nouveau matériel répondant aux quatre conditions de sécurisation posée par les textes (FAQ, question 14). Un raisonnement analogue doit être tenu pour les rampes de boissons automatisées, lesquelles doivent dès lors être certifiées.
Il est précisé qu'il convient de distinguer les balances qui permettent de mémoriser des opérations d’encaissement de celles qui ne permettent pas une telle mémorisation. Seules les balances qui ont une fonction de mémorisation des opérations d’encaissement entrent dans le champ d’application de la mesure. Ainsi, tout assujetti à la TVA qui détiendra ce type de matériel devra donc être en mesure produire le certificat ou l'attestation. En revanche, les balances qui n’ont pas une telle fonction ne sont pas visées.
En pratique, trois situations peuvent se présenter (FAQ, question 13) :
-en cas d’utilisation d’une balance comptoir poids / prix, la balance doit être certifiée ;
-en cas d’utilisation d’une balance comptoir poids / prix avec une solution de connexion à une caisse certifiée, la balance et la caisse doivent être toutes les deux certifiées ;
-en cas d’utilisation d’une balance tactile intégrée ou terminal point de vente, qui intègre à la fois une solution de pesage et d’encaissement, certifié, l’ensemble de la solution doit être certifié.
CONDITIONS À RESPECTER PAR LE LOGICIEL OU LE SYSTÈME
Quatre critères de conformité
Pas de référentiel technique
Pour garantir la préservation des données en vue du contrôle de l’administration fiscale, les logiciels et systèmes de caisse doivent satisfaire à des conditions d’inaltérabilité, de sécurisation, de conservation et d’archivage (CGI art. 286, I.3° bis). Le respect de ces conditions peut être établi, soit par la présentation d’un certificat délivré par un organisme accrédité, soit par une attestation délivrée par l’éditeur.
La loi instaure une obligation de résultat et non de moyen. Elle ne définit pas de cahier des charges, ni de solution technique, contrairement à d’autres dispositifs fiscaux. L’élaboration de référentiels est du ressort des seuls acteurs privés (FAQ, question 18).
L’administration fait référence au fichier des écritures comptables (FEC) ou encore aux copies des fichiers de données sur lesquels peuvent être réalisés des traitements dans le cadre d’une vérification de comptabilité. Ces fichiers doivent respecter les normes prévues par arrêté (LPF art. A 47 A-1 et A 47 A-2 ; BOFiP-CF-IOR-60-40-13/12/2013).
Par exemple, concernant la condition d’inaltérabilité, l’intégrité des données enregistrées doit être garantie dans le temps par tout procédé technique fiable (BOFiP-TVA-DECLA-30-10-30-§ 120-03/08/2016). Aucune solution technique n’est imposée (empreinte électronique, chaînage des opérations…), dès lors qu’aucune norme fiscale n’a été prévue par le législateur (FAQ, question 19).
Les données concernées sont celles qui concourent directement ou indirectement à la réalisation d’une transaction participant à la formation des résultats comptables et fiscaux (émission d’une note, d’un ticket, d’une facture), ainsi que de toutes les données liées à la réception, immédiate ou attendue, du paiement en contrepartie (BOFiP-TVA-DECLA-30-10-30-§ 50-03/08/2016).
Est également concerné l’ensemble des données permettant d’assurer la traçabilité de ces données concourant à la réalisation de la transaction et de garantir l’intégrité de celles-ci.
Principe de la garantie d’inaltérabilité
La garantie d’inaltérabilité des systèmes de caisse est satisfaite si techniquement, le système (FAQ, question 19) :
-empêche l’accès de l’utilisateur à des fonctionnalités de modification des données validées ;
-et détecte tout accès/modification des données de règlement. Toute modification ou correction doit être détectable.
La certification du système est associée à la capacité de pouvoir démontrer que les données de règlement n’ont pas été modifiées depuis leur enregistrement initial et doit fournir un système de preuve en ce sens (FAQ, question 19).
Traçabilité des données d’origine, de la commande au règlement
Le logiciel de caisse doit enregistrer toutes « les données d’origine relatives à la transaction de règlements (notes et tickets de caisse) » (FAQ, question 20).
Les données de l’opération doivent être inaltérables de la prise de commande jusqu’à l’enregistrement du règlement (FAQ, question 22).
-l’absence de fonctionnalité logicielle permettant une modification/suppression de la transaction et la preuve que le système n’a pas été contourné ;
-une preuve numérique permettant de détecter si la donnée élémentaire a été modifiée depuis son enregistrement.
La foire aux questions (FAQ, question 20) reprend les termes de la doctrine fiscale (BOFiP-TVA-DECLA-30-10-30-§ 90-03/08/2016), notamment sur la nécessité d’effectuer les corrections par l’enregistrement de nouvelles opérations de « plus » et de « moins », et non par modification directe des données d’origine enregistrées, et d’enregistrer les opérations de correction.
Techniquement, la solution doit donc garantir l’inaltérabilité de toutes les données élémentaires (enregistrement initial et corrections) et fournir une fonctionnalité de suivi des modifications (FAQ, question 20).
À NOTER. Il ressort des réponses apportées par l’administration dans la FAQ que les pièces à rendre inaltérables avec une intégrité des données concernent toutes les données qui concourent directement ou indirectement à la réalisation d’une transaction (bon de commande, bon de livraison, factures, tickets de caisse, règlement…).
Moyens techniques de conservation des données de façon inaltérable
Il est précisé que la condition d’inaltérabilité des enregistrements de règlement (quantité, montant, TVA, mode de règlement…) s’obtient par plusieurs moyens techniques garantissant (FAQ, question 21) :
-une inaltérabilité logique de haut niveau, en privant l’utilisateur de toute fonctionnalité du logiciel lui permettant de modifier les données élémentaires de règlement. Ce moyen s’assortit d’une solution technique permettant de détecter et démontrer que l’utilisateur n’a pas contourné cette impossibilité fonctionnelle intégrée au logiciel de l’éditeur ;
-une inaltérabilité de bas niveau qui garantit l’intégrité des données enregistrées sur le disque sous forme de fichier ou de base de données. L’accès à une donnée élémentaire par un homme de l’art ne pouvant jamais être empêché, cette inaltérabilité est garantie par la preuve que la donnée élémentaire n’a pas été modifiée depuis son enregistrement (empreinte numérique à clé privée, chaînage...).
Selon l’administration, ce critère est respecté si le système garantit la restitution des données de règlement dans l’état de leur enregistrement d’origine. Cette sécurisation peut être assurée par tout procédé technique fiable, notamment une technique de chaînage des enregistrements ou de signature électronique des données (BOFiP-TVA-DECLA-30-10-30-§ 90-03/08/2016).
La condition de sécurisation ne vise pas à limiter les droits d’accès au système, mais à assurer que les enregistrements des encaissements réalisés par toute personne qui accède au logiciel ou système sont tracés, de même que les éventuelles modifications apportées à ces enregistrements initiaux. En cas d’emploi d’une fonction « école » ou « test », l’identification de l’opérateur sous la responsabilité duquel le personnel en formation enregistre les données doit toutefois être prévue, ce qui peut être mis en place notamment avec un avocat fiscaliste.
La sécurisation des données vise à s’assurer que les données enregistrées ne peuvent plus être modifiables, sans traces. Il ne s’agit pas seulement de protéger les données contre les modifications par des tiers, mais aussi contre des modifications non tracées effectuées par le propriétaire et détenteur des données lui-même (FAQ, question 23).
Distinction entre conservation et archivage : système de purge
Sur les modalités de conservation et d’archivage, la FAQ explicite les commentaires publiés au BOFiP.
Il est opéré une distinction claire entre les données de transaction qui doivent être conservées « en ligne » dans le système de caisse et les données qui peuvent être « sorties » du système et archivées sur un support externe (clé USB, disque optique ou disque dur externe… aucun support technique n’étant imposé).
L’opération qui consiste à sortir les données du système pour les archiver est qualifiée de « purge » du système. Les données doivent être archivées avant le processus de purge (FAQ, question 24).
Le support externe sécurisé n’est exigé qu’en présence de purge (BOFiP-TVA-DECLA-30-10-30-§ 250-03/08/2016). Pour les systèmes de caisse, la purge des éléments archivés n’est pas totale. Certaines informations doivent rester dans le système.
Il est rappelé que l’ensemble des données doit être conservé (dans le système de caisse) et archivées (sur support externe) et leur inaltérabilité et leur traçabilité doivent être garanties pendant six ans (CGI art. L. 102 B).
Quelles sont les échéances de clôture des systèmes de caisse ?
Pour la conservation des données, les systèmes de caisse doivent prévoir obligatoirement une clôture journalière, une clôture mensuelle et une clôture annuelle (ou par exercice lorsque l’exercice n’est pas calé sur l’année civile) (BOFiP-TVA-DECLA-30-10-30-§§ 160 et 170-03/08/2016). Ces trois échéances de clôtures sont cumulatives et impératives (FAQ, question 30).
S’agissant du respect de la condition d’archivage, les systèmes de caisse doivent permettre d’archiver les données enregistrées selon une périodicité au maximum annuelle ou par exercice (BOFiP-TVA-DECLA-30-10-30-§ 220-03/08/2016). Cette périodicité est donc la même que la périodicité annuelle ou par exercice prévue pour le respect de la condition de conservation (FAQ, question 30).
Remarque. L’obligation d’archivage ne doit pas être confondue avec une solution de sauvegarde des données présentes dans le système de caisse. Ces sauvegardes sont entendues comme une copie des données toujours présentes sur la caisse. Les sauvegardes permettent la reprise technique des données en cas de panne de la caisse et constituent une solution, parmi d’autres, de sécurisation des données justificatives de règlement (FAQ, question 27), et semblent fortement recommandées par votre avocat fiscaliste.
Données à conserver à chaque échéance
Pour chaque clôture journalière, mensuelle et annuelle (ou par exercice), des données cumulatives et récapitulatives, intègres et inaltérables, doivent être calculées par le système de caisse (BOFiP-TVA-DECLA-30-10-30-§ 170-03/08/2016). Il est précisé que, parmi ces données figurent le grand total pour la période comptable, le total période et le total perpétuel. La clôture mensuelle permet aussi la totalisation du chiffre d’affaires ventilé par taux de TVA (FAQ, question 29).
Les données cumulatives et récapitulatives calculées par le système sont soumises à l’obligation de conservation.
On entend par « cumul du grand total de la période » le cumul de chiffre d’affaires décompté depuis l’ouverture de la période comptable en cours (FAQ, question 28).
On entend par « total perpétuel » le cumul de chiffre d’affaires décompté depuis le début de l’utilisation du système (FAQ, question 28). Ce « total perpétuel » est un compteur qui cumule le chiffre d’affaires total enregistré depuis le début de l’utilisation du système et ne se remettant jamais à zéro. Il n’est pas lié à une période contrairement au « grand total » qui lui est le compteur qui cumule le chiffre d’affaires total pour la période comptable.
À NOTER. En cas de changement de matériel ou de logiciel, tous les compteurs repartent de zéro. Les compteurs de l’ancien matériel ou logiciel doivent être archivés et sécurisés. Dans le cas d’un simple changement de version d’un logiciel, tous les compteurs doivent continuer à être incrémentés sans être remis à zéro.
Détail des données de caisse à conserver
Toutes les données élémentaires doivent être conservées par le logiciel ou le système de caisse et non pas seulement les cumuls périodiques et les données agrégées résultant de traitements automatisés (dénommés « les Z »).
Un assujetti qui ne conserve que « les Z » ne respecte pas ses obligations de conservation (LPF art. L. 102 B).
Sur ce point, plusieurs précisions détaillées ci-après sont apportées (FAQ, question 25).
Les données de détail d’une transaction de règlement comprennent le numéro du ticket, la date (heure-minute-seconde), le numéro de la caisse, le total TTC, les totaux HT par taux de TVA, le détail des articles ou prestations (libellé, quantité, prix unitaire, total HT de la ligne, taux de TVA associé) et les traces de modifications et corrections apportées.
Avant la purge des données élémentaires conservées dans le système de caisse, l’ensemble des données précitées et enregistrées depuis la dernière opération d’archivage doivent être conservées.
Après la purge, seuls les totaux de contrôles produits par les procédures de clôtures (soit les grands totaux journaliers, mensuels, annuels et de l’exercice et le total perpétuel) doivent être conservés dans le logiciel de caisse et continuer d’être protégés par la garantie d’inaltérabilité. Les données de traçabilité de la procédure de purge/archivage doivent être conservées.
Où conserver les données ?
Les données sont archivées au moins une fois à la fin de chaque exercice comptable au moyen d’un processus obligatoirement prévu par le logiciel. Elles sont toujours archivées avant un processus de purge.
Les données de détail de règlement sont enregistrées sur un support externe et effacées de la sauvegarde « en ligne » présente dans le logiciel de caisse. En revanche, les totaux de contrôles produits par les procédures de clôtures doivent être conservés dans le logiciel de caisse et continuer d’être protégés par la garantie d’inaltérabilité. La solution logicielle doit permettre de maintenir la traçabilité des procédures d’archivage et de garantir l’inaltérabilité des données archivées (FAQ, question 26)
Production d’une archive complète avant chaque purge
Avant la mise en œuvre de la procédure de purge, le logiciel ou le système doit garantir la production d’une archive complète des données de règlement (données d’origine et éventuelles modifications), avec la date de l’opération de règlement (année – mois – jour), sur un support physique externe sécurisé (BOFiP-TVA-DECLA-30-10-30-§ 250-30-10-30-03/08/2016).
La décision de purger les données est liée à la nécessité de libérer de l’espace sur le disque dur. L’archivage des données est donc dans ce cas logiquement réalisé en dehors du système de caisse. La sécurisation du support d’archivage doit permettre de garantir l’intégrité des données archivées et leur disponibilité effective en cas de contrôle (FAQ, question 27).
Les éditeurs doivent prévoir des procédures d’archivage obligatoires pour les utilisateurs. Pour plus de sécurité, plusieurs supports de stockage différents pour une même archive peuvent être proposés, comme le prévoit la norme Z 42 013.
Les archives doivent pouvoir être lues aisément par l’administration. Aucun format d’archive n’est toutefois imposé. De la même manière, en cas de cryptage de l’archive, aucun format de cryptage n’est imposé.
Les archives sont considérées comme pouvant être aisément lues par l’administration si, en en cas de contrôle, l’assujetti à la TVA présente à l’administration des archives décryptées (données numériques apparaissant en clair et non sous forme codée) (FAQ, question 35).
À titre d’exemple, les formats de fichiers de type TXT ou CSV peuvent être utilisés pour l’archivage (BOFiP-BIC-DECLA-30-10-20-40-§ 550-13/12/2013).
RESPONSABLE DE L'ÉMISSION DES JUSTIFICATIFS
L’éditeur du logiciel responsable
Le responsable de l’émission des documents de conformité est l’éditeur du logiciel ou du système de caisse. L’éditeur est la personne qui détient le code source du logiciel ou du système et qui a la maîtrise de la modification des paramètres de ce produit (BOFiP-TVA-DECLA-30-10-30-§ 300-03/08/2016). Le dernier intervenant est considéré comme éditeur et, à ce titre, il peut attester des caractéristiques du logiciel ou du système ou s’engager dans une certification (BOFiP-TVA-DECLA-30-10-30-§ 310-03/08/2016).
Une attestation délivrée par un éditeur engage sa responsabilité sous réserve que les dispositifs techniques garantissant sécurisation, inaltérabilité, conservation et archivage ne soient pas modifiés (FAQ, question 31).
À NOTER. Tout logiciel en cours d’utilisation au 1er janvier 2018 entre dans le champ d’application de l’obligation de conformité (FAQ, question 33).
Qui est l’éditeur en cas de modification du logiciel ?
Analyse de la nouvelle version du logiciel
Un intervenant, quel qu’il soit, modifiant le fonctionnement du logiciel (par modification du code source, patch logiciel, paramétrage ou autre) à un point tel que les fonctionnalités techniques garantissant sécurisation, inaltérabilité, conservation et archivage des données se trouvent modifiées, invalide le certificat ou l’attestation et se trouve soumis à l’obligation de sécurisation (avec attestation ou certificat) de la nouvelle version du logiciel.
Dans le cas où les fonctionnalités techniques du certificat ne sont pas modifiées par une nouvelle version du logiciel, cette version dite mineure ne fait pas naître une nouvelle obligation de certification.
Dans le cas où la modification du logiciel est telle que les fonctionnalités techniques assurant la sécurisation, l’inaltérabilité, la sauvegarde et l’archivage des données sont altérées, cette version majeure doit faire l’objet d’une nouvelle certification. L’administration illustre ces principes par plusieurs exemples (FAQ, questions 32 et 34).
Le logiciel standard est celui fourni par un éditeur sous forme d’un exécutable et de ses bibliothèques logicielles non modifiables et dont un éventuel paramétrage ne concerne pas les fonctions assurant la sécurisation, l’inaltérabilité, la conservation et l’archivage. L’éditeur de ce logiciel est soumis à une obligation de sécurisation justifiée par un certificat délivré par un organisme accrédité ou une attestation établie par l’éditeur lui-même.
L’éditeur fournissant un logiciel hautement paramétrable, nécessitant une intégration et des développements pour être mis en service est soumis à une obligation de sécurisation, sous réserve que les développements et paramétrages de la société de service informatique procédant à l’intégration n’altèrent pas les fonctionnalités assurant les critères de conformité.
Si les modifications réalisées par l’intégrateur altèrent les dispositifs techniques de sécurisation mis en place par l’éditeur, l’intégrateur devient « éditeur ». Le logiciel modifié et installé doit faire l’objet d’une nouvelle procédure de sécurisation aboutissant à la délivrance d’une certification par un organisme accrédité ou d’une attestation établie par l’intégrateur « éditeur » lui-même.
Si un logiciel est assez ouvert pour permettre à un intégrateur de paramétrer l’inaltérabilité, la sécurisation, la conservation ou l’archivage, c’est cet intégrateur en tant que dernier intervenant qui est qualifié d’éditeur. En tant que tel, c’est à lui de fournir une attestation ou d’obtenir une certification par un organisme accrédité, ce qu'un avocat fiscaliste - notamment - peut se charger de demander.
Lorsque le logiciel est développé en interne dans une entreprise, celle-ci est considérée comme étant « l’éditeur ». Elle doit faire certifier la version du logiciel en service. Toute modification du logiciel altérant les dispositifs de sécurisation des données invalide le certificat et nécessite l’établissement d’un nouveau certificat.
Logiciel libre dont le code source est fourni par la communauté de développeurs
Le code source permet de modifier et de recompiler à volonté le logiciel qui devient éminemment instable du fait de mises à jour au fil de l’eau par la communauté de développeurs, mais également de modifications en interne par l’entreprise. L’entreprise utilisatrice est donc considérée « l’éditeur » soumis à obligation de certification de la version actuellement en service. Toute modification par la communauté ou par l’entreprise altérant le dispositif technique de sécurisation invalide le certificat et la nouvelle version doit faire l’objet d’un nouveau certificat.
Un code NACE d’éditeur de logiciel dispense-t-il de l’accréditation ?
L’éditeur du logiciel ou système qui fournit l’attestation individuelle ne peut pas être l’assujetti à la TVA au nom duquel est établie l’attestation, sauf si l’activité déclarée par cet assujetti (code NACE) est une activité d’édition de logiciels ou de systèmes de caisse.
L’activité d’éditeur de logiciel doit être réelle et corroborée par le code NAF. Cependant, le code NAF ne peut à lui seul être un mode de preuve de l’activité de l’assujetti. Certains éditeurs ont des codes NACE variables et qui ne correspondent pas forcément au code 5829 C « édition de logiciels » (changement d’activité, multiples activités…).
Le code NACE est donc une présomption simple et ne dispense pas d’office de l’accréditation par un organisme certificateur (FAQ, question 41).
Organismes certificateurs français
Deux organismes sont accrédités par le COFRAC, instance nationale d’accréditation, à la date du 30 mai 2017 :
-Laboratoire National de Métrologie et d’Essais (LNE), accréditation n° 5-0012 (portées disponibles sur « www.cofrac.fr »), pour le référentiel « Référentiel de certification des systèmes de caisse ».
Il appartient à chaque éditeur de logiciel de prendre leur attache, s’agissant d’organismes indépendants de l’administration fiscale COFRAC (FAQ, question 38).
À NOTER. L’administration, ainsi que l’expert-comptable, ne peuvent pas certifier le logiciel ou système de caisse de l’assujetti, car ils ne sont pas accrédités par le COFRAC (FAQ, question 37). La liste des logiciels et systèmes de caisse certifiés est consultable sur le site Internet de chaque organisme accrédité.
Les organismes accrédités peuvent bénéficier d’une accréditation délivrée par une instance nationale d’accréditation située en France ou dans un autre État membre de UE, membre de la coopération européenne pour l’accréditation et ayant signé les accords de reconnaissance mutuelle multilatéraux couvrant la certification considérée. Un éditeur qui a son siège social dans un État de l’UE autre que la France peut donc obtenir un certificat auprès d’un organisme accrédité dans son État de siège. Le certificat doit explicitement mentionner que le logiciel ou le système de caisse respecte les conditions d’inaltérabilité, de sécurisation, de conservation et d’archivage des données prévues par la législation française, pour plus de précisions sur ce point, consulter un avocat fiscaliste (FAQ, question 40).
ATTESTATION DÉLIVRÉE PAR L'ÉDITEUR
Formalisme de l’attestation
L’attestation doit satisfaire aux conditions suivantes (FAQ, question 42) :
-elle doit être individuelle, c’est-à-dire délivrée nominativement à l’assujetti à la TVA qui la produit ;
-elle doit être établie par l’éditeur du logiciel ou du système de caisse ou par son représentant légal lorsqu’il s’agit d’une société ;
-elle doit explicitement mentionner que le logiciel ou le système de caisse respecte les conditions d’inaltérabilité, de sécurisation, de conservation et d’archivage des données ;
-elle doit indiquer précisément :
-la date d’acquisition du logiciel ou du système par l’assujetti à la TVA,
-le nom et les références de ce logiciel (y compris la version du logiciel concernée et le numéro de licence quand il existe une licence) ou de ce système.
L’attestation peut être délivrée sur un support physique ou de manière dématérialisée (par exemple, par téléchargement en ligne d’une attestation à compléter par l’assujetti pour y mentionner notamment son identité complète).
Ces précisions reprennent celles qui figurent déjà dans la doctrine administrative (BOFiP-TVA-DECLA-30-10-30-§§ 360 à 390-03/08/2016). L’attestation doit être conforme au modèle fourni par l’administration (BOFiP-LETTRE-000242-03/08/2016).
La loi n’impose pas aux éditeurs la délivrance spontanée de l’attestation.
Si l’éditeur n’adresse pas d’attestation à l’utilisateur, il appartient à ce dernier de la lui réclamer (FAQ, question 44).
Les agents de l’administration fiscale devront prendre en compte les circonstances particulières lorsque l’assujetti apporte la preuve des diligences mises en œuvre pour obtenir cette attestation.
L’éditeur peut-il se limiter à renvoyer aux conditions générales de vente ?
Une simple mention dans les conditions générales ou particulières de vente du logiciel ou système, même acceptée par l’assujetti, ne vaut pas attestation individuelle.
Toutefois, par tolérance, l’administration admet un document qui serait pré-rempli, sous forme papier ou dématérialisée, par l’éditeur et comportant toutes les mentions exigées, y compris la signature du représentant légal de la société éditrice, puis remis lors de l’achat physique du logiciel, sous réserve de complément par l’assujetti concernant son identification, la date d’achat et la preuve d’achat (FAQ, question 43).
Entreprises habilitées à délivrer des attestations
L’attestation doit être établie par l’éditeur du logiciel ou du système de caisse ou par son représentant légal lorsqu’il s’agit d’une société.
Pour délivrer une attestation valable dans le cadre de la mesure de certification des logiciels de caisse, une filiale en charge de l’informatique doit être l’éditeur du logiciel ou du système de caisse utilisé par d’autres entités du groupe.
L’administration pourra s’en assurer dans le cadre de son droit de communication (LPF art. L. 96 J).
L’éditeur du logiciel ou du système de caisse qui fournit l’attestation individuelle ne peut pas être l’assujetti à la TVA au nom duquel est établie l’attestation, sauf si l’activité déclarée par cet assujetti est une activité d’édition de logiciels ou de systèmes de caisse.
Une filiale, éditeur d’un logiciel ou d’un système de caisse, peut utiliser ce même logiciel pour sa propre activité sur la foi de l’attestation qu’elle aura elle-même délivrée. Cela étant, dans la pratique cette situation devrait, selon votre avocat fiscaliste, être exceptionnelle (FAQ, question 45).
Commerces franchisés
Les commerces franchisés constituant des entreprises avec une personnalité juridique propre, chaque franchise doit présenter un certificat ou une attestation pour le logiciel ou le système de caisse qu’elle utilise (FAQ, question 46).
Le renouvellement de l’attestation est fondé sur les notions d’évolutions mineures ou majeures du logiciel , et non sur une durée calendaire.
Par conséquent, en pratique, l’attestation n’a pas à être renouvelée annuellement, mais elle le sera en fonction des changements mineurs ou majeurs apportés au logiciel (FAQ, question 47).
L’attestation demeure valable pour les versions mineures ultérieures du logiciel ou du système de caisse. Toute nouvelle version majeure du logiciel ou du système de caisse doit donner lieu à l’établissement d’une nouvelle attestation visant expressément cette dernière version.
Centralisation de l’attestation en cas de pluralité de points de vente
Dans les cas où les systèmes de caisse déployés pour l’ensemble de points de vente d’une même entité juridique sont absolument identiques en tout point, une seule attestation produite au nom de la personnalité juridique de cette entité est admise (FAQ, question 48).
AMENDE PRÉVUE EN CAS DE NON-RESPECT DE L'OBLIGATION DE CONFORMITÉ
Le fait de ne pas pouvoir produire l'attestation ou le certificat permettant de justifier de la conformité du logiciel ou du système est sanctionné par une amende de 7500 € par logiciel (BOFiP-CF-INF-20-10-20-§ 570-08/03/2017) ou système de caisse concerné.
Lorsqu’un assujetti détient plusieurs logiciels ou systèmes de caisse différents, l’amende est due pour chaque logiciel ou système de caisse différent pour lequel l’assujetti ne justifie pas, par la production d’un certificat ou d’une attestation individuelle, qu’il respecte les conditions fixées par les textes (FAQ, question 49).
Cette amende peut être cumulée avec les rappels d'impôt et pénalités qui seraient dus à la suite d'un contrôle de la comptabilité de l’entreprise, au titre des recettes que le logiciel frauduleux aurait permis de dissimuler, procédure dans laquelle vous pouvez recourir à l'assistance d'un avocat fiscaliste.
Lorsqu'il est fait application de cette amende, l'assujetti dispose d'un délai de 60 jours pour se mettre en conformité. Ce délai court, selon le cas, à compter de la remise de la réception du procès-verbal mentionné à l'article L. 80 O du LPF, de la proposition de rectification prévue à l'article 57 du LPF ou de la notification mentionnée à l'article L. 76 du même livre.
Passé ce délai, l'assujetti qui ne s'est pas mis en conformité est passible à nouveau de l'amende de 7 500 €.
INTERVENTION INOPINÉE DE L'ADMINISTRATION FISCALE
L'administration fiscale peut intervenir de manière inopinée dans les locaux d'un assujetti pour vérifier que celui-ci détient l'attestation ou le certificat de conformité pour chacun des logiciels ou systèmes qu'il détient (LPF art. L. 80 O).
Les agents des impôts peuvent intervenir de manière inopinée dans les locaux professionnels de l'assujetti, à l'exclusion des locaux affectés au domicile privé, et ceci entre 8 heures et 20 heures, ou, en dehors de ces heures, durant les heures d'activité professionnelle.
Si l'assujetti (ou son représentant) refuse l'intervention des agents de l'administration, l'amende de 7 500 € est immédiatement appliquée.
L'intervention doit débuter par la remise d'un avis à l'assujetti ou à son représentant et se terminer par l'établissement d'un procès-verbal.
Ce procès-verbal consigne les références du ou des logiciels ou systèmes de caisse détenus par l'entreprise, ainsi que les éventuels manquements à l'obligation de détention d'une attestation ou d'un certificat de conformité pour chaque logiciel ou système.
Le procès-verbal est signé par les agents d'administration et par l'assujetti ou son représentant. En cas de refus de signer, mention en est fait au procès-verbal. Une copie du procès-verbal est remise à l'assujetti ou à son représentant.
En cas de manquement, l'assujetti dispose d'un délai de 30 jours pour formuler ses observations. Ces observations sont annexées au procès-verbal. Il peut également, le cas échéant, fournir l'attestation ou le certificat de conformité.
Si l'intéressé apporte les justificatifs qui lui sont demandés dans le délai de 30 jours, l'amende de 7 500 € n'est pas appliquée.
On notera que cette procédure d'intervention spécifique ne relève pas des procédures de contrôle de l'impôt régies par les articles L. 10 à L. 54 à du LPF et, bien entendu, ne les empêche pas.
Evaluer cet article : Select a rating 5 4 3 2 1 Note moyenne : 4.3 (4 votes)
Vérification anti-spam Quelle est la deuxième lettre du mot rflft ? :