La DGFIP commente dans la partie « Éclairage sur les aspects techniques » de sa FAQ, les quatre conditions majeures que doivent respecter les fonctionnalités des caisses présentes dans les logiciels de Gestion commerciale et les systèmes enregistrant des paiements de clients : inaltérabilité des données, sécurisation, conservation et archivage des informations.

Logiciel de caisse et principe d’inaltérabilité des données

Un principe qui se base sur la validation des écritures comptables

Sauf à ce que le législateur n’impose une norme, aucune solution n’est écartée dès lors qu’elle empêche « l’accès de l’utilisateur à des fonctionnalités de modification des données validées et d’autre part de détecter tout accès/modification des données de règlement. Toute modification ou correction doit être détectable.

Le logiciel ou système de type SAGE, EBP, CEGID… doit fournir un système de preuve en démontrant l’absence de modification des données de règlement, mais aussi détecter et tracer d’éventuelles modifications (non autorisées) et les corrections (lesquelles ne sont acceptables que par des opérations de « plus » et de « moins », et non par modification directe des données initialement enregistrées.

Le principe de validation des écritures comptables qui ne peuvent être supprimées ou modifiées (sauf contrepassation et enregistrement de nouvelles écritures) est ainsi transposé à l’ensemble des données des opérations relatives aux règlements des clients.

L’exigence de l’inaltérabilité des données

L’administration introduit une nouvelle exigence dans sa FAQ : techniquement, l’inaltérabilité doit être garantie doublement :

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 du règlement. Ce moyen s’inscrit dans 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é dite 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 pouvant ne jamais être empêché, cette inaltérabilité est garantie par la preuve que la données élémentaire n’a pas été modifiée depuis sont enregistrement (empreinte numérique à clef privée, chaînage…).

Notons qu’il s’agit d’une évolution majeure de la part de l’administration par rapport à l’instruction du 3 août 2016.

Or, lorsqu’un logiciel utilise une base de données, il est théoriquement toujours possible d’accéder directement aux tables et d’en modifier des enregistrements, si l’on possède une autorisation d’administration étendue de base. D’où la difficulté notable des éditeurs à garantir l’inaltérabilité absolue des données, d’autant que la DGFIP se prévaut d’une obligation de résultat. Il suffirait dorénavant d’empêcher l’utilisateur de modifier la base de données utilisateur dont il faut tracer toutes les actions.

Comme pour la saisie des écritures de règlements de clients non assujettis en comptabilité, on peut cependant s’interroger sur la possibilité de continuer à utiliser des « brouillards de caisse ».

Quelles sont les données concernées ?

Pour la DGFIP, la traçabilité suppose que le logiciel de point de vente enregistre toutes les données d’origine relatives à la transaction de règlements (notes et tickets de caisse). Les « données d’origine » sont définies comme les données de l’opération concernée « de la prise de commande jusqu’à l’enregistrement du règlement ». Il ne suffit pas de rendre inaltérables les seules données de règlement, mais l’ensemble de la piste d’audit.

Il s’agit en fait de toutes les données qui concourent directement ou indirectement à la réalisation d’une transaction. L’usage de l’expression « qui concourent directement ou indirectement », directement empruntée à l’article L.13, IV du LPF, permet d’étendre le périmètre des données à toute donnée élémentaire justifiant la raison du règlement.

Le vérificateur devra pouvoir « accéder » aux données d’origine enregistrées initialement ». Jusqu’où remonter pour accéder à des données d’origine ?

Dans le cadre du contrôle fiscal de comptabilité informatisé (CFCI), un contribuable doit pouvoir justifier ses écritures comptables et déclarations fiscales en fournissant les données élémentaires nécessaires à la réalisation des traitements informatisés, quels que soient le parcours et le traitement de l’information à travers le système d’information ou les applications utilisées.

L’administration souhaite-t-elle transposer le même raisonnement « aux données d’origine relatives à la transaction des règlements » ? A première vue, il faudrait appliquer les quatre conditions éditées par l’article 286, I, 3° bis du Code Général des Impôts « de la prise de commande jusqu’à l’enregistrement du règlement ». On fera alors observer que bien souvent les données d’origine de la commande ne sont pas gérées par le système ou les fonctionnalités de caisse. En poursuivant le raisonnement jusqu’au bout, on pourrait considérer que les assujettis devraient demander à leurs éditeurs ou intégrateurs un certificat ou une attestation pour toutes les applications et systèmes se trouvant sur  la piste d’audit d’un règlement réalisé par ou pour un client non assujetti à la TVA. Cela dit les assujettis à la TVA sont susceptibles de faire l’objet d’un CFCI, à partir de l’instant où ils tiennent une comptabilité informatisée…

Le Conseil d’État a jugé que la seule utilisation d’une caisse enregistreuse, sans le recours à un logiciel de comptabilité, ne suffit pas à caractériser la tenue d’une comptabilité sur informatique.

Une clarification serait néanmoins la bienvenue : faut-il limiter le périmètre aux systèmes et application de caisse ou bien remonter au-delà dans les autres systèmes de gestion, dès lors que cela explique un règlement client ?

Logiciel de caisse et sécurisation des données

La sécurisation consiste à tracer les enregistrement des encaissements réalisés par toute personne qui accède au logiciel ou système, de même que les éventuelles modifications apportées à ces enregistrements initiaux. L’objectif est de protéger les données contre les modifications effectuées par des tiers, mais également contre des modifications non tracées effectuées par le propriétaire et détenteur des données lui-même.

Cette sécurisation porte sur « les données d’origine, les données de modifications enregistrées et les données permettant la production des pièces justificative émise ».

Elle peut être assurée « par tout procédé technique fiable, c’est-à-dire de nature à garantir la restitution des données de règlement dans l’état de leur enregistrement d’origine » (par exemple, chaînage des enregistrement ou signature électronique des données).

Logiciel de caisse et conservation des données

Il s’agit de conserver les données évoquées ci-dessus pendant 6 ans, conformément au délai fixé par l’article L. 102 B du LPF. Elles peuvent être conservées « en ligne », c’est-à-dire directement dans le système du logiciel, à condition de pouvoir les consulter et les exporter pour contrôle durant cette période.

Une purge des données est possible pour libérer l’espace de stockage à condition :

  • d’archiver (au sens fiscal) les données qui seront effacées,
  • de conserver au sein du système ou logiciel les données cumulatives et récapitulatives calculées par le système (cumul du grand total de la période et le total perpétuel pour la période comptable).

La DGFIP requiert toujours une procédure de clôture

Dans son instruction d’août 2016, elle exigeait que celle-ci intervienne journellement, mensuellement ou quotidiennement pour les systèmes de caisse, alors que les logiciel de comptabilité ou de gestion enregistrant que des règlements, pouvaient n’opérer que des clôtures annuelles ou par exercice. On peut s’étonner de ceci dans la mesure où l’administration utilise dorénavant la présence de fonctionnalités de caisse comme critère de qualification des logiciels ou systèmes , peu importe le fait qu’ils soient des caisses enregistreuses plus ou moins sophistiquées, des logiciels de gestion comptable ou de gestion.

Il faut souligner que l’introduction d’une obligation de clôture par année civile ou exercice fiscal des logiciels de facturation est une nouveauté, dont la mise en application pratique dans les applications concernées ne se fera pas sans d’importantes modifications et pourrait conduire à des pertes de production.