1

En application du 3° bis du I de l'article 286 du code général des impôts (CGI), modifié par l'article 105 de la loi n° 2017-1837du 30 décembre 2017 de finances pour 2018, depuis le 1^er janvier 2018, toute personne assujettie à la taxe sur la valeur ajoutée (TVA) qui effectue des livraisons de biens et des prestations de services à destination de clients particuliers et qui enregistre les règlements reçus en contrepartie au moyen d’un logiciel ou d'un système de caisse, est tenue d'utiliser un logiciel ou un système qui satisfasse aux conditions d'inaltérabilité, de sécurisation, de conservation et d'archivage des données en vue du contrôle de l'administration fiscale.

L'obligation prévue au 3° bis du I de l'article 286 du CGI s'applique à tous les logiciels et systèmes de caisse utilisés par un assujetti à la TVA à compter du 1^er janvier 2018 pour enregistrer les règlements de ses clients particuliers reçus en contrepartie des livraisons de biens et des prestations de services effectuées.

Pour plus de détails sur la définition du logiciel ou système de caisse, il convient de se reporter au I-B § 30.

En revanche, cette disposition ne crée pas d'obligation de s'équiper d'un logiciel ou système de caisse. Le choix de l'utilisation d'un logiciel ou système de caisse appartient à chaque assujetti.

Ainsi, n'est pas soumis à cette obligation tout assujetti qui suit ses encaissements uniquement à l'aide d'un facturier ou d’un journal de caisse papier ou bien d'un logiciel de bureautique (tableur, traitement de texte etc.) utilisé seulement pour rédiger des factures sans mémoriser les données.

Le respect des conditions d'inaltérabilité, de sécurisation, de conservation et d'archivage des données peut être justifié par un certificat délivré par un organisme accrédité ou par une attestation individuelle de l'éditeur.

L'administration fiscale s'assure de la détention par les assujettis contrôlés de l'attestation individuelle ou du certificat précités. Pour plus de détails sur cette procédure, il convient de se reporter au BOI-CF-COM-20-60.

I. Champ d'application

A. Assujettis à la TVA concernés

10

Sont soumis à l'obligation prévue au 3° bis du I de l'article 286 du CGI, les assujettis à la TVA, personnes physiques ou morales, de droit privé ou de droit public, qui effectuent des livraisons de biens et des prestations de services ne donnant pas lieu à facturation conformément à l'article 289 du CGI (BOI-TVA-DECLA-30-20-30), quel que soit le secteur d'activité, dès lors qu’ils utilisent un logiciel ou système de caisse.

En conséquence, les assujettis qui réalisent l'intégralité de leur chiffre d'affaires avec un ou des professionnels sont exclus du dispositif, puisque les opérations réalisées entre professionnels uniquement (B to B) font obligatoirement l'objet d'une facturation.

En revanche, les assujettis qui réalisent à la fois des opérations avec des clients assujettis à la TVA (clients professionnels) et des non assujettis (clients particuliers) relèvent du champ d'application du dispositif.

Un assujetti qui décide de délivrer des factures à un particulier sans que la réglementation fiscale ne l'y oblige ne s’exonère pas, par cette délivrance de facture du respect de l'obligation de sécurisation de son logiciel ou système de caisse.

Un particulier qui réalise des ventes de biens ou prestations de services, notamment sur une plate-forme qui met en relation à distance, par voie électronique, des personnes en vue de la vente d'un bien, de la fourniture d'un service ou de l'échange ou du partage d'un bien ou d'un service, est soumis à l'obligation de sécurisation des logiciel ou système de caisse, lorsqu'il peut être qualifié d'assujetti à la TVA. Sur la qualité d'assujetti, il convient de se reporter au BOI-TVA-CHAMP-10-10-20.

Les sociétés mandatées pour la gestion des règlements des clients à l’aide de logiciels ou systèmes de caisse pour le compte d'un autre assujetti, doivent utiliser un logiciel ou un système de caisse conforme aux conditions d'inaltérabilité, de sécurisation, de conservation et d'archivage des données en vue du contrôle de l'administration fiscale.

20

Les succursales et filiales de sociétés étrangères sont dans le champ d'application de l'obligation de détenir un logiciel et système sécurisé. Cela étant, par mesure de tolérance administrative, les entreprises étrangères immatriculées à la TVA non établies en France sont hors champ du dispositif.

25

Conformément au 2 du II de l'article 286 du CGI, ne sont pas soumis à l'obligation d'utiliser un logiciel ou système de caisse certifié :

- les assujettis à la TVA bénéficiant du régime de la franchise en base mentionnée à l'article 293 B du CGI ;

- les assujettis soumis au régime du remboursement forfaitaire de TVA agricole prévu aux articles 298 quater du CGI et 298 quinquies du CGI ;

- les assujettis effectuant exclusivement des opérations et prestations exonérées de TVA.

B. Logiciels ou systèmes de caisse concernés

30

Un logiciel ou système de caisse est un système informatique doté d'une fonctionnalité de caisse, laquelle consiste à mémoriser et à enregistrer extra-comptablement des paiements reçus en contrepartie d'une vente de marchandises ou de prestations de services c'est-à-dire que le paiement enregistré ne génère pas concomitamment, automatiquement et obligatoirement la passation d'une écriture comptable.

Ne sont pas considérés comme enregistrés extra-comptablement, quel que soit le mode de paiement, les paiements pour lesquels le logiciel ou système déclenche obligatoirement, instantanément et automatiquement, sans intervention humaine, une écriture dans le système d’information comptable.

Sont visés tous les logiciels ou systèmes de caisse permettant l'enregistrement des règlements de leurs clients quel que soit le mode de règlement (espèces, chèques, CB, virements, prélèvements...).

Cette obligation s'applique y compris en cas d'enregistrement sur un logiciel ou système accessible en ligne.

Sans que cette liste ne soit limitative, sont concernés par l'obligation les instruments de mesures réglementés, comme les balances, mais également les rampes de boissons automatisées, les automates de paiement ou encore les distributeurs automatiques de marchandises (boissons, gâteaux…) qui disposent d'une fonctionnalité de caisse.

Seule cette fonctionnalité de caisse, et non les autres fonctions telles que celles relatives à la pesée, doivent être certifiées.

 Les instruments de mesure réglementés, munis d’un dispositif de mémorisation des règlements, qui sont utilisés à la fois pour déterminer le prix à payer des articles en fonction de la grandeur mesurée et pour enregistrer le règlement doivent être certifiés. Il en est de même si plusieurs instruments de mesure réglementés sont interconnectés ou fonctionnent en réseau, chacun d'entre eux devant être certifié

Exemple 1 : Un commerçant dispose d'une balance pour peser la marchandise qu'il vend au poids. Cette balance n’a pas de fonction de mémorisation des opérations relatives aux règlements de ses clients, elle n'a pas à être certifiée.

Exemple 2 : Une balance, munie d’un dispositif de mémorisation des règlements, dispose donc d'une d'une fonctionnalité de caisse, et doit être certifiée. Il en est de même des balances connectées à un terminal point de vente ou des balances tactiles intégrées ou terminaux point de vente, qui intègrent à la fois une solution de pesage et d'encaissement.

Exemple 3 : Un commerçant disposant d'une balance dotée de mémorisation, enregistre les encaissements de ses clients dans une caisse enregistreuse non connectée à la balance, seule la caisse doit être certifiée.

Exemple 4 : Un commerçant qui dispose d'une balance, mais qui note sur un cahier les encaissements de ses clients sans dispositif de caisse, n'entre pas dans le dispositif. Ce commerçant n'a pas, par ailleurs, d'obligation de s'équiper d'un logiciel ou système de caisse.

Les terminaux de paiements seuls ou les prestataires de services de paiement sont exclus du dispositif.

35

Toutefois, par tolérance administrative, lorsque tous les paiements reçus en contrepartie d'une vente ou d'une prestation de services sont réalisés avec l'intermédiation directe d’un établissement de crédit régi par les dispositions du titre I^er du livre V du code monétaire et financier (CoMoFi, art. L. 511-1) auprès duquel l’administration peut exercer son droit de communication, l'assujetti est dispensé de l'obligation d'utiliser un logiciel ou système de caisse certifié.

Il en est de même, lorsque tous les paiements reçus en contrepartie d'une vente ou d'une prestation de services sont réalisés avec l'intermédiation directe d’un établissement bancaire établi au sein d'un pays de l'Union européenne soumis à l'obligation d'échange automatique d'informations en application de la directive 2011/16/UE du Conseil du 15 février 2011 relative à la coopération administrative dans le domaine fiscal.

Exemple 1 : un gérant d'un site de e-commerce sur lequel il effectue des ventes de biens à des particuliers et qui propose exclusivement comme mode de paiement la carte bancaire ou le virement via un établissement bancaire auprès duquel l’administration peut exercer son droit de communication et obtenir des informations, est dispensé, par tolérance administrative de l'obligation de faire certifier son système informatique comme l'impose le 3° bis du I de l'article 286 du CGI.

Exemple 2 : les automates tels que, par exemple, les distributeurs d'essence ou matériels de gestion des péages autoroutiers, dès lors qu'ils ne permettent que le paiement par carte bancaire ou virement via un établissement bancaire auprès duquel l’administration peut exercer son droit de communication et obtenir des informations, sont dispensés, par tolérance administrative, de l'obligation de sécurisation prévue au 3° bis du I de l'article 286 du CGI.

40

Un logiciel, quelle que soit sa qualification (de caisse, comptable ou de gestion), qui dispose d'une fonctionnalité de caisse doit satisfaire aux conditions d'inaltérabilité, de sécurisation, de conservation et d'archivage des données en vue du contrôle de l'administration fiscale.

Ainsi, un logiciel de gestion qui permet de suivre les encaissements perçus en contrepartie des opérations de ventes ou de prestations de services qui concernent les non assujettis à la TVA (clients particuliers) doit être sécurisé.

Dans le cas de logiciels multi-fonctions (comptabilité/gestion/caisse), seule la fonctionnalité de caisse enregistreuse / encaissement, et non l'ensemble du logiciel, doit être certifiée.

Les logiciels ou systèmes de caisse dits "libres" ou développés en interne sont également concernés par l’obligation.

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 propriétaire, au contraire, ne permet ni légalement ni techniquement d'exercer ces quatre libertés, qui permettent aux utilisateurs d'adapter le logiciel à leurs besoins spécifiques.

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.

Les modifications que les utilisateurs peuvent apporter à un logiciel libre ou développé en interne ne doivent avoir ni pour objet ni pour effet d'altérer le respect des conditions d'inaltérabilité, de sécurisation, de conservation et d'archivage des fonctionnalités de caisse.

C. Données concernées

50

Sans préjudice d'autres dispositions spécifiques de facturation telle que l'obligation de remettre une note aux clients d'une prestation de services qui ne relèvent pas de la réglementation fiscale, les données concernées sont toutes les données de règlement liées à la réalisation d'une transaction, qu'il s'agisse d'une opération de vente d'un bien ou d'une prestation de services et qui peut conduire à l'émission, qu'elle soit antérieure, simultanée ou consécutive au règlement, d'un justificatif (note, ticket, facture etc.) ainsi que de toutes les données liées à la réception (immédiate ou attendue) du paiement en contrepartie.

Sont ainsi visées les données de détail d'une transaction de règlement, qui doivent être enregistrées ligne par ligne, qui comprennent :

- le numéro du justificatif ;

- la date (année-mois-jour-heure-minute) ;

- le numéro de la caisse ;

- le montant total TTC ;

- le détail des articles ou prestations (libellé, quantité, prix unitaire, total HT de la ligne, taux de TVA associé) ;

- toutes les données liées à la réception (immédiate ou attendue) du paiement en contrepartie (mode de règlement notamment) ;

- les traces de modifications et corrections apportées.

Est également concerné l'ensemble des données permettant d'assurer la traçabilité et de garantir l’intégrité des données concourant à la réalisation de la transaction.

Sont également concernées les données permettant de générer des données d'archives, selon un procédé fiable (cf. II-D § 220 et suivants).

Lorsque la transaction n'est que simulée au moyen d'un module de type « école » ou « test », les données sont également concernées.

Pour plus de précisions, il convient de se reporter au BOI-BIC-DECLA-30-10-20-40 qui précise que les contribuables qui tiennent une comptabilité informatisée sont soumis aux obligations de conservation des données (LPF, art. L. 102 B).

II.  Nature des conditions à respecter

55

Pour les II § 60 à 260, la mention « logiciel ou système de caisse » fait référence, selon le cas, aux logiciels et systèmes de caisse et, pour les logiciels multi-fonctions (comptabilité/gestion/caisse), à la seule fonctionnalité de caisse à certifier.

60

Les conditions d'inaltérabilité, de sécurisation, de conservation et d'archivage des données du logiciel ou du système de caisse doivent permettre à l'administration fiscale de contrôler les données enregistrées. Le logiciel ou le système doit donc prévoir un accès de l'administration fiscale à l'ensemble des données enregistrées.

Le législateur n'a pas défini de cahier des charges, ni de solution technique.

L'élaboration de référentiels ou de solutions techniques est donc du ressort des seuls acteurs privés et doit permettre le respect des quatre conditions exigées par la loi : inaltérabilité, sécurisation, conservation et archivage.

Les référentiels ou les solutions techniques évoluent en cohérence avec la loi et les instructions administratives.

70

Il est rappelé que tout logiciel ou système de comptabilité qui contient une fonctionnalité de caisse, est en outre soumis aux obligations comptables et notamment au principe de caractère intangibles des écritures comptables assuré par le processus de validation des écritures (BOI-BIC-DECLA-30-10-20-40) et doit respecter, en application du I de l'article L. 47 A du LPF, les normes fixées par arrêté du ministre chargé du budget pour la remise des fichiers des écritures comptables. Pour plus de précisions, se reporter au BOI-CF-IOR-60-40.

75

Le logiciel ou le système de caisse doit enregistrer toutes les données d'origine relatives aux règlements, les rendre inaltérables, les conserver de manière sécurisée et en permettre l'archivage.

A.  Condition d'inaltérabilité

80

Toutes les données mentionnées au I-C § 50 doivent être inaltérables.

90

Si des corrections sont apportées à ces données, que ce soit au moyen du logiciel ou système lui-même ou d'un dispositif externe au logiciel ou système, ces corrections (modifications ou annulations) s'effectuent par des opérations de « plus » et de « moins » et non par modification directe des données d'origine enregistrées. Ces opérations de correction donnent également lieu à un enregistrement et leur inaltérabilité doit également être garantie.

Autrement dit, l'inaltérabilité des données vise à s'assurer que les données enregistrées ne puissent plus être modifiées sans trace. Il ne s'agit pas seulement de protéger les données contre les modifications par des tiers, ce qui constitue un délit en application de l'article 323-1 du code pénal à l'article 323-3 du code pénal, mais aussi contre des modifications non tracées effectuées par le propriétaire et détenteur des données lui-même.

100

Cette inaltérabilité est garantie par :

- une inaltérabilité logique de haut niveau, en privant l'utilisateur de toute fonctionnalité du logiciel ou système lui permettant de modifier les données mentionnées au I-C § 50 . 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 ou au système 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 par un homme de l'art ne pouvant jamais être empêché, cette inaltérabilité est garantie par la preuve que la donnée n'a pas été modifiée depuis son enregistrement (empreinte numérique à clé privée, chaînage etc.).

Techniquement, la solution doit garantir l'inaltérabilité de toutes les données (enregistrement initial comme correction(s)) et fournir une fonctionnalité de suivi des modifications.

Autrement dit, le logiciel ou le système de caisse doit prévoir que l'administration fiscale puisse accéder aux données d'origine enregistrées initialement ainsi qu'au détail daté (année, mois, jour, heure, minute) des opérations et des corrections apportées lorsque ces données ont fait l'objet de corrections.

(110)

120

Pour respecter 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.

La garantie d'inaltérabilité peut être obtenue par toute technique permettant :

- d'empêcher l'accès de l'utilisateur à des fonctionnalités de modification des données validées ;

- de détecter tout accès/modification des données mentionnées au I-C § 50 et de tracer toute éventuelle modification ;

- de démontrer que ces données de règlement n'ont pas été modifiées depuis leur enregistrement initial ;

- de fournir un système de preuve en ce sens.

B. Condition de sécurisation

130

Le logiciel ou le système de caisse doit sécuriser les données mentionnées au I-C § 50, les données de modifications enregistrées et les données permettant la production des pièces justificatives émises. C’est-à-dire empêcher leur suppression ou modification sans laisser de trace.

La condition de sécurisation ne vise pas à limiter les droits d'accès au logiciel ou système de caisse mais à assurer que les enregistrements des règlements réalisés par toute personne qui accède au logiciel ou système soient mémorisés, de même que les éventuelles modifications apportées à ces enregistrements initiaux.

140

Cette sécurisation peut être assurée par tout procédé technique fiable, c'est-à-dire de nature à garantir la restitution des données dans l'état de leur enregistrement d'origine. Il peut notamment s'agir d'une technique de chaînage des enregistrements ou de signature électronique des données.

150

L'emploi d'une fonction « école » ou « test » destinée à l'enregistrement d'opérations de règlement fictives aux fins de formation du personnel doit être sécurisé, par une identification très claire des données de règlement, des pièces justificatives (par exemple en apposant la mention « factice » ou « simulation » en trame de fond de ces documents) et de toutes les opérations enregistrées lors de l'utilisation de cette fonction, ainsi que par l'identification de l'opérateur sous la responsabilité duquel le personnel en formation enregistre les données.

C.  Condition de conservation

155

La conservation des données mentionnées au I-C § 50 doit être assurée « en ligne » dans le logiciel ou système de caisse. S’il est nécessaire de libérer de l’espace sur le disque dur ou d'améliorer la performance, ces données peuvent faire l'objet de purge, ce qui consiste à les sortir du logiciel ou système de caisse et à les stocker sur un support externe d'archivage (clé USB, disque optique ou disque dur externe, par exemple) dans les conditions prévues au II-D § 220 à 260.

L'ensemble des données doit être conservé (dans le logiciel ou système de caisse) ou archivé (sur support externe). Les preuves de leur inaltérabilité et de leur traçabilité étant des données servant à l'établissement de la comptabilité de l'entreprise, elles doivent également être conservées pendant le délai de six ans prévu au premier alinéa de l'article L. 102 B du LPF. Elles ne nécessitent pas d'impression papier.  Il convient de se reporter au BOI-BIC-DECLA-30-10-20-40 pour plus de précisions.

(160)

170

Les logiciels ou systèmes de caisse ou seule la fonction de caisse des logiciels multi-fonctions, doivent prévoir obligatoirement une clôture journalière et une clôture mensuelle et annuelle (ou par exercice lorsque l'exercice ne coïncide pas avec l'année civile). Ces trois échéances sont cumulatives et impératives. Pour chaque clôture, des données cumulatives et récapitulatives, intègres et inaltérables, doivent être calculées par le logiciel ou système de caisse, comme le cumul du grand total de la période et le total perpétuel pour la période comptable.

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.

On entend par « total perpétuel » le cumul de chiffre d'affaires décompté depuis le début de l'utilisation du logiciel ou système.

Le total perpétuel est en effet un compteur qui cumule le chiffre d'affaires total enregistré depuis le début de l'utilisation du logiciel ou 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.

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.

Les totaux de contrôles produits par les procédures de clôture 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.

180

Toutes les données mentionnées au I-C § 50 doivent être conservées. Cette obligation de conservation porte sur toutes les données enregistrées ligne par ligne non pas seulement le Z de caisse, ainsi que, sur les données cumulatives et récapitulatives calculées par le logiciel ou système (cumul du grand total de la période et total perpétuel) (cf. II-C § 170).

Un assujetti qui ne conserve que les Z ne respecte pas les obligations de conservation prévues à l'article L. 102 B du LPF. Cette définition répond à la nécessité légale de justifier les résultats produits par un système informatisé avec les données élémentaires ayant servi à leur élaboration, prises en compte dès leur origine, et non par des données agrégées résultant de traitements automatisés.

(190 - 200)

210

Lorsque l'assujetti utilise un logiciel ou système de caisse centralisé avec remontée des données mentionnées au I-C § 50  depuis des points de vente vers un logiciel ou système centralisateur, la conservation des données enregistrées ligne par ligne et la conservation des données cumulées peut être réalisée au niveau du logiciel ou système centralisateur, à condition qu'une traçabilité de la remontée des données des points de vente vers le logiciel ou système centralisateur soit prévue. Cette traçabilité doit permettre à l'administration de vérifier l'exhaustivité du flux des données transférées.

D.  Condition d’archivage

220

Le logiciel ou le système de caisse doit permettre d'archiver les données enregistrées selon une périodicité choisie, au maximum annuelle ou par exercice. La procédure d'archivage a pour objet de figer les données et de donner date certaine aux données archivées.

Elle doit prévoir un dispositif technique garantissant l'intégrité dans le temps des archives produites et leur conformité aux données initiales à partir desquelles elles sont créées. Les archives peuvent être conservées dans le logiciel ou système lui-même ou en dehors du logiciel ou système lorsqu'il existe une procédure de purge.

L'obligation d'archivage ne doit pas être confondue avec une solution de sauvegarde des données présentes dans le logiciel ou système de caisse. Ces sauvegardes sont entendues comme une copie des données toujours présentes sur la caisse pour permettre la reprise technique en cas de panne de la caisse

230

Les archives doivent pouvoir être lues aisément par l'administration en cas de contrôle, y compris lorsque l'entreprise a changé de logiciel ou de système de caisse. A cette fin, les données d'archivage doivent être enregistrées dans un format ouvert.

240

Le logiciel ou système doit prévoir une traçabilité de la génération des données d'archives, selon un procédé fiable. Les données de traçabilité de la procédure de purge et d'archivage doivent être conservées.

250

Au-delà de la périodicité choisie et au maximum annuelle ou par exercice, le logiciel ou le système de caisse peut prévoir une procédure de purge des données. Avant la mise en œuvre d'une procédure de purge, le logiciel ou le système doit garantir la production d'un fichier d'archive complète des données mentionnées au I-C § 50, sur un support physique sécurisé externe au logiciel ou système de caisse.

Il est possible de citer comme support physique externe : une clé USB, un disque optique ou un disque dur externe. Ce support physique externe doit être sécurisé. Aucune solution technique n'est imposée pour assurer cette sécurisation.

L’assujetti peut également recourir à un tiers archiveur, qui se charge pour le compte de tiers d'assurer la conservation de ses archives.

La sécurisation du support d'archivage doit permettre de garantir l'intégrité des données archivées et leur disponibilité en cas de contrôle.

Les éditeurs doivent prévoir obligatoirement une fonction permettant de générer des fichiers d'archive pour les utilisateurs. Pour plus de sécurité plusieurs supports de stockage différents pour une même archive peuvent être proposés. Les utilisateurs ont en effet l'obligation de conserver les données archivées pendant six ans (LPF, art. L. 102 B).

260

La décision de purger les données est liée à une contrainte (exemples non exhaustifs : libérer de l'espace sur le disque dur, améliorer la performance...). La purge n'est que partielle : le logiciel ou système doit conserver dans un état sécurisé « en ligne », c'est-à-dire dans le logiciel ou système lui-même, les données cumulatives et récapitulatives contenues dans le grand total de la période et le total perpétuel pour la période dont les données ont été purgées.

III.  Modalités de justification du respect de ces conditions

270

En application du 3° bis du I de l'article 286 du CGI, le respect des conditions d'inaltérabilité, de sécurisation, de conservation et d'archivage des données peut être justifié :

- soit par un certificat délivré par un organisme accrédité dans les conditions prévues à l'article L. 433-4 du code de la consommation ;

- soit par une attestation individuelle de l'éditeur du logiciel de comptabilité ou de gestion ou du système de caisse concerné, conforme à un modèle fixé par l'administration.

Il s'agit d'un mode de preuve alternatif : un seul de ces deux documents (certificat ou attestation individuelle) suffit à justifier du respect des conditions susvisées.

280

Lorsqu'une entreprise détient plusieurs logiciels ou systèmes de caisse dans lesquels elle enregistre les règlements de ses clients, elle doit présenter un certificat ou une attestation pour chacun de ces produits.

Par tolérance administrative, 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.

290

Qu'il s'agisse du certificat ou de l'attestation individuelle, c'est l'éditeur du logiciel ou système de caisse qui fait produire le certificat demandé à un organisme certificateur accrédité ou qui produit le document (attestation individuelle). Ce n'est pas l'assujetti qui demande la certification du logiciel ou système de caisse qu'il détient à l'autorité certifiante.

En pratique, l'éditeur remet ce document (le certificat, sa copie ou l'attestation individuelle) à l'assujetti soumis à l'obligation prévue au 3° bis du I de l'article 286 du CGI, lors de l'achat ou du téléchargement du logiciel ou système de caisse. A défaut (notamment lorsque le logiciel ou système a été acquis ou téléchargé avant l'adoption du 3° bis du I de l'article 286 du CGI), l'assujetti peut demander à l'éditeur qu'il lui remette un certificat ou une attestation individuelle pour le logiciel ou système en cause.

L'assujetti doit en effet s'assurer qu'il dispose du certificat, de sa copie ou de l'attestation individuelle correspondant à la version du logiciel ou système de caisse qu'il utilise. Par exemple s'il se procure librement et gratuitement un logiciel en ligne, il lui appartient de se faire produire une attestation individuelle ou d'obtenir une copie du certificat.

L'assujetti doit veiller à utiliser un logiciel ou système de caisse dont les fonctions afférentes aux conditions d'inaltérabilité, de sécurisation, de conservation et d'archivage sont à jour et d'avoir un certificat, sa copie ou une attestation individuelle correspondante (notamment lorsque le logiciel ou système a été acquis avant l'adoption du 3° bis du I de l'article 286 du CGI).

300

On entend par « éditeur » du logiciel ou du système de caisse la personne qui détient le code source du logiciel ou système et qui a la maîtrise de la modification des paramètres de ce produit.

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 sont pas modifiés par un tiers.

310

Lorsque le logiciel ou système est conçu de manière ouverte pour permettre son adaptation aux besoins spécifiques des clients, on entend par « éditeur » qui peut valablement demander la certification ou fournir l'attestation individuelle :

- soit le concepteur d'origine du logiciel ou système lorsque les conditions d'inaltérabilité, de sécurisation, de conservation et d'archivage des données sont respectées par le logiciel ou système conçu à l'origine par cette personne et qu'aucun des paramètres permettant le respect de ces conditions ne peut être modifié par d'autres intervenants que ce concepteur ;

- soit le dernier intervenant ayant paramétré le logiciel ou système lorsque son intervention a eu pour objet ou effet de modifier un ou des paramètres permettant le respect des conditions d'inaltérabilité, de sécurisation, de conservation et d'archivage des données (cf. III-B § 375 pour le cas spécifique de l'éditeur qui a également la qualité d'assujetti soumis à l'obligation prévue au 3° bis du I de l'article 286 du CGI).

315

Un intervenant, quel qu'il soit, modifiant le fonctionnement du logiciel ou du système (par modification du code source, patch logiciel, paramétrage ou autre) à un point tel que les fonctionnalités techniques garantissant la sécurisation, l'inaltérabilité, la conservation ou l'archivage des données d'encaissement se trouvent modifiées, invalide le certificat ou l'attestation et se trouve soumis à l'obligation de certification ou d'attestation de la nouvelle version du logiciel ou du système.

Exemple 1 : Logiciel standard d'un éditeur fourni sous forme d'un exécutable et de ses bibliothèques logicielles non modifiables et dont le paramétrage est possible mais ne concerne pas les fonctions assurant la sécurisation, l'inaltérabilité, la conservation et l'archivage des données d'encaissement. 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 lui-même.

Exemple 2 : Logiciel hautement paramétrable, nécessitant une intégration et des développements pour être mis en service. L'éditeur fournissant le logiciel 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 la sécurisation, l'inaltérabilité, la conservation et l'archivage des données d'encaissement. 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 » (cf. III § 310). 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.

Exemple 3 : Logiciel développé en interne par une entreprise. L'entreprise est considérée comme étant « l'éditeur » (cf. III § 310). 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.

Exemple 4 : Logiciel libre dont le code source est fourni par la communauté de développeurs contribuant à sa programmation. Le code source permet de modifier et de recompiler à volonté le logiciel qui évolue rapidement 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 comme « 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 ou d'une nouvelle attestation.

Par tolérance administrative, dans le cas d’une chaîne complexe d’intervenants, il est possible de faire certifier ou d’attester chaque « brique » ou module du système d’encaissement, à charge pour l’assujetti de réunir tous les documents (certificats et/ou attestations individuelles) et de pouvoir justifier que le système constitué par l'ensemble de ces « briques » ou modules soit lui-même conforme aux exigences prévues au 3° bis du I de l'article 286 du CGI.

Pour cela, l'intégrateur doit recourir, en plus de la certification ou de l'attestation de chaque « brique » ou module, à une certification de services délivrée par un organisme accrédité par le COFRAC, instance nationale d'accréditation, dans les conditions prévues à l'article L. 433-4 du code de la consommation.

A. Certificat délivré par un organisme accrédité

320

Tout assujetti à la TVA soumis à l'obligation prévue au 3° bis du I de l'article 286 du CGI peut justifier que le logiciel de comptabilité ou de gestion ou le système de caisse qu'il utilise pour enregistrer les règlements de ses clients satisfait à cette obligation par la production d'un certificat délivré par un organisme accrédité dans les conditions prévues à l'article L. 433-4 du code de la consommation.

Il est rappelé que ces dispositions prévoient que les organismes 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 l'Union européenne, 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'Union européenne autre que la France peut donc obtenir, dans les conditions précitées, un certificat auprès d'un organisme accrédité dans son État de siège.

330

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 au 3° bis du I de l'article 286 du CGI, telles qu'explicitées au II § 60 à 260.

Le certificat doit porter sur la version du logiciel ou système détenue par l'assujetti à la TVA ou, à défaut, sur la version majeure de ce logiciel ou système à condition, dans ce cas, que l'organisme accrédité assure un audit régulier du produit permettant de s'assurer que les versions ultérieures et non majeures de ce logiciel ou système continuent de répondre aux conditions d'inaltérabilité, de sécurisation, de conservation et d'archivage des données.

Le renouvellement du certificat est fondé sur les notions d'évolutions mineures ou majeures du logiciel ou du système, et non sur une durée calendaire. Dans les faits, le certificat n'a pas à être renouvelé annuellement, mais il le sera en fonction des changements mineurs ou majeurs apportés au logiciel ou au système de caisse.

Il est admis que le certificat demeure valable pour attester du respect des conditions d'inaltérabilité, de sécurisation, de conservation et d'archivage des données par les versions mineures ultérieures du logiciel ou système.

340

On entend par version majeure d'un logiciel ou système toute nouvelle version de ce logiciel ou système obtenue en ayant modifié, dans la précédente version de ce logiciel ou système, un ou plusieurs paramètres impactant le respect des conditions d'inaltérabilité, de sécurisation, de conservation et d'archivage des données.

A l'inverse, on entend par version mineure toute version de ce logiciel ou système obtenue sans que les paramètres impactant le respect des conditions précitées aient été modifiés par rapport à la précédente version de ce logiciel ou système.

(350)

B.  Attestation individuelle de l'éditeur ou système de caisse

360

Tout assujetti à la TVA soumis à l'obligation prévue au 3° bis du I de l'article 286 du CGI peut justifier que le logiciel ou le système de caisse qu'il utilise, satisfait à cette obligation par la production d'une attestation.

365

Cette attestation est délivrée à l'assujetti, spontanément ou à sa demande, par l'éditeur du logiciel ou système de caisse au titre de la version vendue ou fournie. L'attestation peut être délivrée par un éditeur établi à l'étranger à condition d'être, soit rédigée en français, soit rédigée en langue étrangère et accompagnée d'une traduction en français certifiée.

370

L'attestation doit être individuelle, c'est-à-dire délivrée nominativement à l'assujetti à la TVA qui la produit. 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 administrative, 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, est admis.

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é.

375

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 est une activité d'édition de logiciels ou de systèmes de caisse. En dehors de cette exception, lorsque le logiciel ou système est développé par l'assujetti lui-même pour ses besoins propres, ce dernier ne pourra justifier que son logiciel ou système satisfait à l'obligation prévue au 3° bis du I de l'article 286 du CGI que par la production d'un certificat délivré par un organisme accrédité dans les conditions précisées au III-A § 320 à 340.

L'activité d'éditeur de logiciel devra être réelle et corroborée. Les codes NAF et NACE renseignées dans les déclarations fiscales peuvent constituer une présomption simple mais ne peuvent à eux seuls être un mode de preuve de l'activité de l'assujetti et ne dispensent pas d'office de la certification par un organisme certificateur.

L'attestation 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 au 3° bis du I de l'article 286 du CGI, telles qu'explicitées au II § 60 à 260. Elle doit indiquer précisément le nom et les références de ce système ou de ce logiciel (y compris la version du logiciel concernée et le numéro de licence quand il en existe un) ainsi que la date à laquelle le logiciel ou système a été acquis par l'assujetti à la TVA.

380

Il sera admis que l'attestation demeure valable pour attester du respect des conditions d'inaltérabilité, de sécurisation, de conservation et d'archivage des données par les versions mineures ultérieures du logiciel ou système (cf. III-A § 340 pour la définition d'une version majeure et d'une version mineure)  :

- si cette attestation identifie clairement la racine de la dernière version majeure à la date d'émission de l'attestation et les subdivisions de cette racine qui sont ou seront utilisées pour l'identification des versions mineures ultérieures ;

- et si l'éditeur s'engage à n'utiliser ces subdivisions que pour l'identification des versions mineures ultérieures, à l'exclusion de toute version majeure.

Toute nouvelle version majeure du logiciel ou système doit donner lieu à l'établissement d'une nouvelle attestation visant expressément cette version.

390

L'attestation peut être délivrée sur un support physique (par exemple, par la remise d'un document lors de l'achat du logiciel ou système à compléter par l'assujetti de son identité complète et de la date de son achat) 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).

L'attestation doit être conforme au modèle fourni en BOI-LETTRE-000242.

C. Conséquences en cas de production d'un faux certificat ou d'une fausse attestation individuelle

400

Il est rappelé que l'établissement d'un faux document est un délit pénal passible de trois ans d'emprisonnement et de 45 000 € d'amende en application de l'article 441-1 du code pénal. Ces peines s'appliquent également aux éditeurs étrangers qui délivreraient de fausses attestations ou de fausses copies de certificat à des assujettis à la TVA en France. Elles s'appliquent aussi aux assujettis à la TVA qui présentent à l'administration une fausse copie de certificat ou une fausse attestation individuelle tout en connaissant son caractère frauduleux.

410

En cas de doute, l'administration peut demander une copie du certificat ou de l'attestation individuelle qui lui a été présentée par l'assujetti, notamment dans le cadre de l'exercice d'un droit de communication réalisé auprès de l'organisme accrédité qui a émis le certificat ou auprès de l'éditeur qui a remis l'attestation à l'assujetti.

Si cette procédure révèle que le document n'a pas été émis ou n'a pas été remis à l'assujetti par la personne supposée l'avoir émis ou remis, l'assujetti est passible des peines applicables en cas d'établissement de faux document.

(420)