Logiciel de caisse : ce que la loi exige vraiment, et comment le vérifier

Temps de lecture : 8 min

Logiciel de caisse : ce que la loi exige vraiment, et comment le vérifier

La loi anti-fraude à la TVA impose quatre conditions à tout logiciel de caisse. En cas de contrôle, c'est le commerçant qui répond, pas l'éditeur. Voici les questions à poser pour vérifier.

Caisse et point de vente

Un logiciel de caisse n'est pas seulement un outil de vente : c'est une pièce que l'administration fiscale peut demander à examiner. La loi ne dit pas qu'il doit être beau ou rapide. Elle dit qu'il doit être capable de prouver quatre choses. Voici lesquelles, et les questions à poser pour vérifier que le vôtre les tient.

La règle, et qui la paie

Le texte est l'article 286-I-3° bis du code général des impôts, issu de la loi anti-fraude à la TVA. Il impose que tout logiciel utilisé pour enregistrer des règlements de clients satisfasse quatre conditions, résumées par quatre lettres : inaltérabilité, sécurisation, conservation, archivage.

Le point le plus souvent ignoré est celui-ci : la sanction ne vise pas l'éditeur, elle vise le commerçant. En cas de contrôle, l'amende est de 7 500 € par système d'encaissement, et elle est due par celui qui exploite le logiciel. Un éditeur qui affirme sa conformité sans pouvoir la démontrer ne prendra aucun risque à votre place.

Ce qui a changé en février 2026

Pendant un an, l'attestation individuelle de l'éditeur avait été supprimée : seul un certificat délivré par un organisme accrédité faisait foi. La loi de finances 2026 l'a rétablie, avec effet au 21 février 2026.

Concrètement, deux preuves sont désormais acceptées, au choix :

  • une attestation individuelle délivrée par l'éditeur, nominative, au nom de votre société et de la version que vous utilisez ;
  • ou un certificat délivré par un organisme accrédité — la marque NF525 d'Infocert, ou son équivalent LNE.

L'obligation de certification par organisme, un temps annoncée pour le 1er septembre 2026, est annulée. La certification reste un choix commercial, utile face à certains grands comptes ou marchés publics, mais elle n'est plus la condition légale.

Ce qui n'a pas changé : il vous faut l'une ou l'autre, et l'attestation doit être nominative. Une plaquette commerciale, une mention sur un site ou une phrase dans un contrat ne sont pas des preuves.

Les quatre exigences, et la question à poser pour chacune

Inaltérabilité — une vente enregistrée ne se modifie plus

Une fois le règlement enregistré, plus rien ne doit pouvoir en changer le montant, la date ou le détail. Corriger une erreur est légitime, mais cela doit produire une nouvelle opération qui annule la première, jamais une retouche de l'ancienne.

La question à poser : « Que se passe-t-il si je me trompe sur un ticket déjà validé ? » La bonne réponse décrit une annulation qui laisse les deux traces. La mauvaise réponse est « on peut le modifier ».

Chez Adliss, un ticket validé est figé. L'annulation crée un contre-ticket relié à l'original ; les deux restent visibles et se neutralisent dans les totaux. La suppression est refusée par le logiciel lui-même sur toutes les tables qui portent des données de vente. Chaque ticket porte une empreinte calculée à partir du précédent : retirer ou modifier une ligne rompt la chaîne, et la rupture se voit.

Sécurisation — savoir qui a fait quoi

Le logiciel doit tracer les opérations sensibles et les rattacher à une personne : ouvertures et fermetures de caisse, annulations, corrections, remises exceptionnelles, changements de paramètres.

La question à poser : « Puis-je savoir qui a annulé cette vente, et quand ? »

Chez Adliss, un journal des événements enregistre chaque opération fiscale au fil de l'eau, sans possibilité de retour en arrière : on y ajoute, on n'y retire jamais. Chaque ticket porte le nom du vendeur — la vente ne se valide pas sans lui. Les droits sont séparés : encaisser, consulter le chiffre d'affaires et administrer les caisses ne sont pas la même autorisation.

Conservation — six ans, et retrouvables

Les données doivent rester disponibles pendant six ans, et rester lisibles. Un logiciel qui purge automatiquement au bout d'un an, ou dont l'export illisible sans son éditeur, ne satisfait pas cette exigence.

La question à poser : « Combien de temps gardez-vous mes données de caisse, et que se passe-t-il si je change de logiciel ? »

Chez Adliss, aucune purge automatique n'existe. Le logiciel sait produire, caisse par caisse, un état de ce qu'il conserve : période couverte, clôtures présentes, trous éventuels. C'est cet état qui se présente à un vérificateur, plutôt qu'une affirmation.

Archivage — figer, et pouvoir rejouer

À intervalles réguliers, les données doivent être figées dans un document qu'on peut représenter à l'identique des années plus tard. C'est le rôle de la clôture journalière — le fameux « Z ».

La question à poser : « Si l'administration me demande le Z du 14 mars de l'an dernier, vous me le sortez comment ? » La bonne réponse est « on le rejoue tel qu'il a été scellé ». La mauvaise est « on le recalcule ».

Chez Adliss, chaque clôture produit un Z scellé et une archive accompagnée de son empreinte. Un Z ancien est rejoué depuis les données scellées, jamais recalculé à partir de la base d'aujourd'hui — la différence est capitale, parce qu'un recalcul reflète l'état actuel des données, pas celui du jour concerné. Un cumul perpétuel, qui n'est jamais remis à zéro, permet de vérifier qu'aucune période ne manque.

Une caisse conforme n'est pas une caisse fermée

La conformité est souvent présentée comme une contrainte qui rigidifie le travail. C'est l'inverse quand elle est pensée dès la conception : parce que chaque opération est tracée, on peut se permettre d'être souple sur le reste. Un retour de marchandise, une remise exceptionnelle, une sortie d'espèces pour un achat urgent ne posent aucun problème — ils laissent simplement leur trace.

Ce qui pose problème, ce sont les logiciels où la conformité a été ajoutée après coup, par-dessus une base qui autorisait la modification. Ceux-là compensent par des interdictions : pas de correction possible, pas d'annulation après clôture, pas de retour hors délai.

La checklist à emporter

Avant de signer, ou pour vérifier votre installation actuelle :

  • Mon éditeur me remet une attestation nominative, au nom de ma société et de ma version — ou un certificat d'organisme accrédité.
  • Une vente validée ne peut pas être modifiée, seulement annulée par une opération inverse.
  • Je sais qui a annulé, remisé ou ouvert la caisse, et quand.
  • Mes données sont conservées six ans et je peux les récupérer si je change d'outil.
  • Une clôture ancienne se rejoue à l'identique, elle ne se recalcule pas.
  • Le logiciel refuse de vendre si la journée précédente n'a pas été clôturée.

Si une seule de ces cases reste vide, la question mérite d'être posée à votre fournisseur — par écrit.

Questions fréquentes

Mon logiciel de caisse doit-il être certifié NF525 ?

Non, ce n'est pas obligatoire. Depuis la loi de finances 2026, applicable au 21 février 2026, deux preuves sont acceptées au choix : une attestation individuelle délivrée par l'éditeur, ou un certificat d'un organisme accrédité comme NF525 ou LNE. La certification reste utile face à certains grands comptes et marchés publics, mais elle n'est plus la condition légale.

Qui paie l'amende si le logiciel n'est pas conforme ?

Le commerçant qui exploite le logiciel, pas l'éditeur. L'amende est de 7 500 € par système d'encaissement. C'est la raison pour laquelle une attestation nominative, au nom de votre société et de votre version, vaut mieux qu'une affirmation commerciale.

Puis-je encore corriger une erreur de caisse ?

Oui, mais pas en modifiant la vente d'origine. La correction doit créer une opération inverse — un contre-ticket — reliée à la vente initiale. Les deux restent visibles et se neutralisent dans les totaux. Un logiciel qui autorise la retouche d'un ticket validé ne satisfait pas l'exigence d'inaltérabilité.

Combien de temps faut-il conserver les données de caisse ?

Six ans. Les données doivent aussi rester lisibles et récupérables, y compris si vous changez de logiciel. Un outil qui purge automatiquement au bout d'un an, ou dont l'export n'est exploitable que par son éditeur, ne répond pas à cette exigence.

Quelle est la différence entre rejouer un Z et le recalculer ?

Rejouer un Z, c'est le reproduire à partir des données scellées le jour de la clôture. Le recalculer, c'est le reconstituer depuis la base d'aujourd'hui — donc refléter l'état actuel des données et non celui de la journée concernée. Seul le premier satisfait l'exigence d'archivage.

Sources