Il convient de ne pas tenir compte de la qualification du logiciel (de caisse, comptable ou de gestion) en question, mais de retenir sa fonctionnalité de caisse. Ainsi, 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 (clients particuliers) doit être considéré comme un logiciel ou un système de caisse visé par le dispositif.
Ils sous entendent quoi par enregistrer des opérations?
Si je vends des produits numériques à des particuliers, que j’émets les factures en temps réel via API (avec un logiciel conforme à la loi) mais qu’en parallèle je fais un « +1 » dans ma table nombres de ventes de mes clients dans ma base de donnée je tombe sous le coup de la loi?
Si oui il me restera plus qu’à créer dans un autre pays
Dans une telle hypothèse, c’est non ; car vous n’enregistrez pas les règlements.
Par contre si vous ajoutez une colonne à votre table pour indiquer les sommes réglées par le client, oui, vous tombez sous le coup de la loi et si vous voulez allez dans un autre pays il faudra quitter l’UE.
Mais personne n’est obligé d’utiliser un logiciel de caisse ! Y a vraiment pas de quoi en faire tout un fromage…
Je sors mes factures, je saisis les entrées en compta à la mano épicétou.
Par contre si on veut automatiser le process, je vois vraiment pas en quoi c’est choquant d’imposer une certification vu les multiples scandales à la TVA qui ont impliqué des logiciels de caisse trafiqués…
Je suis quelqu’un de curieux, alors je me demande : pourquoi considère-t-on que la compta sur papier résout le problème de la fraude à la TVA ? D’après ce que j’ai compris, les commerçants qui fraudent utilisent un logiciel spécial pour effacer/modifier des recettes. Qu’est-ce qui empêche alors le commerçant qui fait sa compta sur papier d’écrire une recette inférieure voir de ne pas écrire du tout de recette sur papier ? Ça revient au même non ?
Sauf que si on fait sa compta sur papier ce sera si chronophage qu’on aura même plus le temps de faire autre chose. Du coup on n’encaisse plus de TVA et y a plus rien sur quoi frauder. C’est ballot.
Les seuls qui peuvent envisager sérieusement de tenir une compta papier sont des micro… non soumis à TVA.
Exact Bon j’ai mal compris cette phrase je pense :
« À la mano » veut dire « sans automatiser » ici c’est ça ? Et non pas « sur papier »… En quoi cela permet de ne plus considéré le logiciel comme logiciel de caisse ? Que le processus soit automatisé ou pas ça revient au même non ? Arf, j’ai du mal
Bon au passage cet article est intéressant, si j’ai bien compris : ventes au particuliers = besoin d’un logiciel certifié, ventes aux entreprises => pas besoin. Ça à l’air simple dit comme ça.
Faut voir qui est visé en fait. C’est pas le gérant qui fait 3 factures par jour réglées par virement. C’est le patron de bar, de restaurant, d’hôtel, de pharmacie etc. En gros tout ceux qui vendent beaucoup mais peu cher, et qui encaisse pas mal d’espèce.
La caisse enregistreuse permet de sortir chaque mois un ticket de tout ce qui a été vendu / offert, dans un format facilement traitable pour l’expert comptable. Pour un patron de bar j’ose même pas imaginer la taille du ticket qui doit compter des dizaines de milliers de lignes, donc pas possible de faire ça à la mano, il faut une caisse enregistreuse.
Le soucis c’est qu’un logiciel permettait facilement d’effacer toutes ou une partie des recettes encaissées en espèce. Laissant un ticket à fournir à l’expert comptable nickel et cohérent en un temps record. Par exemple 4 cafés peuvent être modifié en 3 cafés et 3 euros sortent ni vu ni connu, de façon indétectable pour l’administration.
Avec un logiciel normalisé il y a une sorte de boite noire chiffrée, donc impossible de la modifier (du moins pour l’instant…), qui liste toutes les opérations effectuées. Une tentative de fraude sera détectée immédiatement en cas de contrôle.
Les fraudes concernaient des caisses physiques qui avaient une option fraude intégrée. Là mon topic concerne les sites internet où tous les paiements se font par CB/virements: en gros il n’y a pas plus traçable et c’est impossible de cacher des sous. Elle est donc inutile pour le e-commerce.
Voici l’article qui est à l’origine de ce topic, d’après ce que je comprends de votre réponse les craintes de l’auteur sont totalement justifiées:
Leur loi revient à interdire d’écrire du code sur mesure (car non certifiable) et d’être obligé d’utiliser des solutions saas.
@Stephane_Persello Le gouvernement a dit et redit que les sites web sont autant concernés que les boutiques physiques même si on ne manipule aucune espèce.
Les règlements sur les cas de fraude se faisaient aussi par CB… et tous les règlements sur le web ne se font pas par CB. Et de toutes façons OSEF, soumettre les caisses physiques et pas les sites web à cette contrainte serait certainement une atteinte au principe constitutionnel d’égalité devant les charges fiscales.
Certainement pas. Une solution saas est d’ailleurs soumise à certification comme les autres.
J’ai lu l’article. Après, j’ai fait comme Desproges : j’ai repris deux fois des nouilles.
Si c’est une machine qui enregistre en compta, oui appli certifiée. Si vous entrez vous-même dans un logiciel de compta, non, pas de certification, car seule la fonction de caisse est soumise à cette obligation, pas le logiciel de compta.
Et entre pros, non, pas besoin de certification. Ce serait stupide : on récupère la TVA, quel serait l’intérêt d’en faire passer sous le tapis ?!
Je reprends mon 1er exemple car il était incomplet.
Je vends un produit numérique à un particulier, le processus de vente est:
1-a)Il paye via Stripe et l’argent va direct sur mon compte pro
1-b)J’émets automatiquement une facture pour le client que je lui envoie par mail.
1-c)Je rentre dans ma base de données le montant de la vente du client (informations stockées à but purement marketing et non pour le fisc)
2)Je rentre à la main la facture dans le logiciel de compta de l’Expert-Comptable
Le point 1-c) pose toujours problème ou pas?
Merci d’avance.
si le stockage dans la BDD est automatique, vous êtes soumis à agrément.
si en revanche vous alimentez votre BDD en saisissant les entrées manuellement, il n’y a pas de souci. Votre stockage en BDD est totalement extérieur à votre chaîne de facturation et de compta…
Je ne suis pas sûr de comprendre. Peu importe la finalité de la BDD, c’est le simple fait « d’automatiser » l’insertion des infos qui implique le besoin d’une certification ?
Dans l’exemple 1-c de @JohnReese, sa base (qui pourrait être une vraie base genre SQL, ou un simple Google Spreadsheets) n’est utilisée qu’à des fins marketing. A aucun moment l’administration ne sera au courant de son existence, et quand bien même elle le serait, je ne comprends pas en quoi cette base l’intéresserait, sachant que l’ensemble des transactions sont déjà enregistrées — et de manière fiable — dans son compte Stripe.
En admettant que le fait a) d’automatiser l’insertion d’infos de facturation, b) de manière visible (car j’imagine qu’il faut que l’administration aille vérifier ce qui est « automatisé » ?), j’en conclue 2 choses :
c’est débile. C’est la finalité de l’enregistrement qui devrait être un critère (le fichier / la base est-elle utilisée comme référence pour calculer ou justifier les taxes ?), pas le fait d’enregistrer dans X fichiers ou bases à des fins marketing ou de stats internes.
il est simple d’automatiser sans que cela ne soit visible. Scrapper des emails, webhooks, etc. Comment l’administration peut raisonnablement justifier qu’une base / fichier soit mis à jour manuellement ou automatiquement ?
Donc quoi ? C’est débile mais c’est comme ça ? Ou j’ai mal compris ?
Oui. La doc du Ministère est très claire sur ce point.
Prenez une balance. Oui, je sais c’est pas très geek alors j’esplique pour ceux qui ne savent pas que l’on peut manger autre chose que des pizzas et que l’on peut se procurer de la bouffe autrement qu’en appelant Foodora ou Deliveroo : c’est un ustensile qui permet de déterminer le poids des produits.
Si cette balance a une fonction de mémorisation des prix, même si c’est une simple balance comptoir qui n’est reliée à rien d’autre qu’à la prise de courant, elle doit être certifiée.
Non. Pasque si vous avez une fonction d’enregistrement, même dans une BDD SQL, croyez-moi c’est ça qui servira très vite en pratique de source pour alimenter la compta ! Les fraudeurs, ça ose tout c’est même à ça qu’on les reconnaît (et accessoirement j’ai fait assez de SQL dans une vie antérieure pour savoir que l’intégrité d’une telle base… vous m’avez compris).
Cela dit pour que la base ne soit pas soumise à agrément c’est très simple, il suffit :
si elle est alimentée automatiquement, qu’il n’y ait pas de colonne « encaissement » ;
ou qu’elle ne soit pas alimentée automatiquement et ne soit pas reliée à la compta. Elle sera totalement occulte et coupée de la chaîne factu/encaissements/compta. Et vous aurez votre outil stat/marketing.
Ca devrait le faire alors, je n’ai que faire des encaissements (Stripe & co me font déjà tout le boulot).
En appelant cette colonne « CA » et en faisant une somme auto des encaissements (du jour, de la semaine, du mois, etc.), ça passe ?
…j’aurais tendance - sous toutes réserves ! - à répondre oui si vous ne gardez en mémoire aucune trace de chaque règlement intervenu mais vous contentez à chaque nouveau règlement d’incrémenter le total de encaissements faits depuis le début de la période - semaine/mois. Vous n’aurez pas enregistré des opérations mais un CA global. Veillez à ce que les données ainsi enregistrées ne permettent pas de reconstituer ces opérations…
Notez qu’il y a un os : quid si durant la période vous n’avez eu qu’un seul règlement ? De facto, vous vous retrouvez alors avec un enregistrement de tous les versements effectués…
Il y aurait sans doute matière à contentieux mais j’en reste à ma réponse plutôt affirmative.
Bon j’ai mal compris cette phrase je pense :
