Un client paie un flat white dans un café de Munich. La tablette posée sur le comptoir envoie la vente à un service de signature, reçoit une signature en retour et l'imprime sur le ticket avant même que le lait ait fini de chauffer. Au comptoir, personne n'y pense, mais cette étape d'une seconde fait intervenir les quatre acteurs de la fiscalisation : le café, la société qui a conçu le logiciel de caisse de la tablette, le fournisseur du composant de sécurité qui a signé la vente et l'administration fiscale qui fait appliquer les règles ayant rendu cette signature nécessaire.
Chacun assume une part différente du travail, et la loi répartit ces parts différemment d'un pays à l'autre. Savoir qui est responsable de quoi compte surtout si vous développez un logiciel de caisse, car votre produit est le point de rencontre des trois autres.
En bref
L'entreprise enregistre la vente et reste légalement responsable de ses enregistrements, même lorsqu'elle achète chaque brique technique à l'extérieur. Le fournisseur EPOS ou MPOS livre le système et, sur plusieurs marchés, porte ses propres obligations légales. Le fournisseur du composant de sécurité signe chaque transaction pour qu'elle ne puisse pas être modifiée sans que cela se voie. L'administration fiscale reçoit les données soit par transmission (chaque jour en Italie, enregistrement par enregistrement en mode Verifactu en Espagne), soit sur demande lors d'un contrôle (Allemagne, Autriche, France, Suède).
Qui sont les acteurs de la fiscalisation ?
La fiscalisation compte quatre acteurs : l'entreprise qui enregistre les ventes, le fournisseur EPOS ou MPOS qui conçoit son système de caisse, le fournisseur du composant de sécurité dont la signature rend toute altération d'une vente détectable, et l'administration fiscale, qui fait appliquer les règles et reçoit les données. Les trois premiers sont liés par des contrats et des intégrations ; la loi impose directement des obligations à chacun d'eux.
Il est utile de se représenter un triangle. L'entreprise, le fournisseur de caisse et le fournisseur du composant de sécurité occupent les sommets, reliés par des licences et des appels d'API. L'administration fiscale se trouve au centre, car les règles qu'elle fait appliquer atteignent chaque sommet directement, au lieu de descendre le long de la chaîne.
Cette répartition a une raison : aucune partie ne peut, seule, rendre un enregistrement de vente digne de confiance. Un enregistrement que l'entreprise contrôle de bout en bout ne prouve pas grand-chose à un contrôleur, puisque c'est elle qui paie l'impôt correspondant. Le fournisseur écrit le logiciel, mais ne peut pas se porter garant de chaque vente réalisée avec ce logiciel. Le mécanisme de sécurité apporte la preuve qu'un enregistrement n'a pas été modifié depuis sa création : sur la plupart des marchés, une signature émise par un composant que l'entreprise ne contrôle pas.
L'entreprise : porte l'obligation et les enregistrements
La plupart des lois de fiscalisation s'adressent d'abord à l'entreprise. Le § 146a du Code fiscal allemand (Abgabenordnung, AO) dispose que quiconque enregistre des opérations commerciales au moyen d'un système électronique doit le protéger par une TSE (Technische Sicherheitseinrichtung, le dispositif de sécurité technique allemand) certifiée par le BSI et tenir les enregistrements à disposition des contrôles fiscaux. Le même article oblige cette entreprise à déclarer à son centre des impôts les systèmes qu'elle utilise. Les entreprises autrichiennes enregistrent leurs unités de signature auprès de FinanzOnline, et les entreprises suédoises déclarent leurs caisses enregistreuses à Skatteverket et signalent tout changement dans un délai de deux semaines.
En résumé : l'entreprise doit l'impôt, donc c'est à elle qu'appartient la preuve.
Cela reste vrai même lorsque chaque brique technique est achetée à l'extérieur. Un restaurant peut prendre la licence de sa caisse auprès d'une société et son service de signature auprès d'une autre, mais lorsqu'un contrôleur se présente et demande les données de transaction, la demande s'adresse au restaurant. Externaliser la technologie n'externalise pas l'obligation.
Cela détermine ce que l'entreprise attend des deux autres sommets. Il lui faut un système qui enregistre chaque vente comme l'exigent les règles. Et il faut que ce système lui fournisse tout ce qu'elle doit déclarer ou produire : données de déclaration, exports, tickets. Les guides de fiskaly sur la KassenSichV en Allemagne et la RKSV en Autriche détaillent ces obligations marché par marché.
Le fournisseur EPOS ou MPOS : conçoit le système auquel les autres se raccordent
Les fournisseurs conçoivent et livrent le système de caisse : un EPOS (point de vente électronique) sur une caisse fixe ou un serveur de back-office, ou un MPOS (point de vente mobile) sur un téléphone ou une tablette. C'est le sommet qui transforme une exigence légale en un bouton sur lequel appuie un caissier. C'est aussi là que se connectent les deux autres sommets, puisque l'entreprise travaille dans le système et que le composant de sécurité s'exécute à l'intérieur.
On suppose facilement que l'obligation s'arrête au commerçant. Sur plusieurs marchés, la loi dit le contraire :
- Allemagne : le § 146a, al. 1 AO interdit de promouvoir commercialement ou de mettre sur le marché des systèmes, logiciels ou TSE qui ne satisfont pas aux exigences.
- Espagne : en vertu de l'article 13 du décret royal 1007/2023, le producteur certifie chaque version de son logiciel de facturation dans une declaración responsable, une déclaration de conformité signée qu'il remet à ses clients. Les producteurs doivent proposer un logiciel adapté depuis le 29 juillet 2025. Les obligations propres aux entreprises devraient débuter en octobre 2028 ; la confirmation officielle était toujours en attente en octobre 2026.
- France : le logiciel de caisse lui-même doit prouver sa conformité, soit par une certification délivrée par un tiers, soit par une attestation en deux parties. L'éditeur signe la première partie et le commerçant la seconde. L'attestation n'est valable qu'avec les deux.
- Suède : la caisse enregistreuse elle-même fait l'objet d'une déclaration du fabricant au titre du SKVFS 2014:9, la réglementation de Skatteverket sur les exigences applicables aux caisses enregistreuses.
Les commerçants qui développent leur propre caisse occupent deux sommets à la fois, avec les obligations du commerçant et celles du fournisseur au sein de la même société. La France montre ce que cela peut impliquer : un éditeur qui vend à des tiers peut attester lui-même de sa conformité, mais un logiciel développé uniquement pour un usage interne doit être certifié par un tiers.
Le fournisseur du composant de sécurité : signe chaque transaction
Un composant de sécurité est la partie du système qui rend un enregistrement prouvable. Il signe chaque transaction au moment où elle est enregistrée et, sur plusieurs marchés, la relie à la précédente, de sorte qu'une modification ou une suppression ultérieure rompt la chaîne et apparaît lors d'un audit. Selon le marché, il s'agit d'un module matériel, d'une carte à puce ou d'un service cloud que la caisse appelle via une API.
L'Office fédéral allemand de la sécurité des technologies de l'information (BSI) décrit clairement la répartition des tâches : les fabricants de caisses intègrent généralement une TSE déjà certifiée au lieu d'en développer et d'en faire certifier une eux-mêmes, et la certification couvre uniquement la TSE, pas la caisse ni son logiciel. Lorsqu'un marché prévoit un composant distinct, le schéma se répète : la caisse l'intègre, et l'éventuel agrément exigé par le marché accompagne le composant, et non la caisse.
La nature de cet agrément varie davantage que ne le laisse penser le mot « certifié » : d'un certificat du BSI en Allemagne à aucune certification de produit en Autriche, et en Espagne comme en France, la loi ne prévoit pas de composant distinct. Le tableau plus bas compare six marchés.
Pour le fournisseur, cela signifie généralement un ensemble distinct d'exigences et de formalités sur chaque marché. Pour l'entreprise, cela signifie que le composant reste le plus souvent invisible : il apparaît sous forme de code ou de signature sur le ticket et, lorsque le système doit être déclaré, dans les informations transmises à l'administration fiscale.
L'administration fiscale : fait appliquer les règles et reçoit les données
Sur la plupart des marchés, le quatrième acteur est une administration fiscale nationale : le ministère autrichien des Finances via FinanzOnline, l'Agenzia delle Entrate (AdE) en Italie, l'AEAT en Espagne, la DGFiP en France et Skatteverket en Suède. L'Espagne connaît des exceptions régionales : les administrations fiscales provinciales basques (Haciendas Forales) gèrent TicketBAI, et la Hacienda Foral de Navarre gère NaTicket.
L'Allemagne divise davantage le rôle. Le ministère fédéral des Finances (BMF) édicte le règlement KassenSichV, le BSI fixe les exigences techniques en concertation avec lui (§ 5 KassenSichV), et les centres des impôts gérés par les Länder (Finanzämter) reçoivent la déclaration de chaque entreprise et effectuent les contrôles.
La façon dont les données parviennent à l'administration suit l'un de deux modèles. Dans le modèle de transmission, l'administration reçoit les données sans avoir à les demander. Les registratori telematici (RT) italiens envoient chaque jour à l'AdE les données de ventes de la journée. En Espagne, les logiciels fonctionnant en mode Verifactu envoient chaque enregistrement de facturation à l'AEAT, tandis que les systèmes qui n'utilisent pas ce mode conservent les enregistrements.
Dans le modèle sur demande, les données restent chez l'entreprise jusqu'à ce qu'un contrôleur les demande. En vertu de la RKSV autrichienne (§ 7 et § 19), l'entreprise exporte son journal de capture des données (DEP) pour la période demandée. L'Allemagne, la France et la Suède vérifient elles aussi les enregistrements lors des contrôles.
Les deux modèles ne placent pas le poids au même endroit. Sur demande, la signature porte tout, car l'administration voit les données des mois ou des années plus tard et compte sur elle pour prouver que rien n'a changé entre-temps. La transmission exige une connectivité et une gestion correcte des retransmissions.
Les quatre rôles sur six marchés
Les quatre rôles sont les mêmes partout ; ce qui change, c'est la forme du composant de sécurité, qui s'en porte garant et comment les données circulent.
| Marché | Composant de sécurité | Qui s'en porte garant | Comment l'administration fiscale obtient les données |
|---|---|---|---|
| Allemagne | Dispositif de sécurité technique (TSE), matériel ou cloud | Certification du BSI | Sur demande, lors des contrôles |
| Autriche | Unité de création de signature, carte à puce ou cloud | Certificat qualifié d'un prestataire de services de confiance eIDAS ; l'unité doit satisfaire aux exigences eIDAS, sans certification fiscale distincte | Sur demande, sous forme d'export DEP (§ 7, § 19 RKSV) |
| Italie | Registratore telematico (RT) | Modèle de RT approuvé par l'AdE | Transmission quotidienne à l'AdE |
| Espagne | Exigences intégrées au logiciel de facturation | Declaración responsable du producteur (art. 13, RD 1007/2023) | Chaque enregistrement en mode Verifactu ; sinon conservé en vue d'un contrôle (obligations des entreprises à partir de 2028) |
| France | Exigences intégrées au logiciel de caisse | Certification par un tiers (LNE ou InfoCert) ou auto-attestation de l'éditeur (rétablie depuis le 21 février 2026) | Sur demande, lors d'un contrôle de la DGFiP |
| Suède | Unité de contrôle (kontrollenhet, matériel) ou système de contrôle cloud (kontrollsystem) | Organisme de certification accrédité | Sur demande, lors des visites de contrôle de Skatteverket |
Si l'on parcourt la colonne du milieu, une chose saute aux yeux : l'administration fiscale approuve rarement elle-même le composant de sécurité. L'Italie est l'exemple le plus net : l'AdE y approuve les modèles de RT. Partout ailleurs, la garantie repose sur un organisme de certification, un prestataire de services de confiance ou la déclaration signée du producteur lui-même. Les guides de fiskaly sur la certification par un tiers face à l'auto-attestation et sur les composants matériels face au cloud approfondissent ces deux questions.
Ce que cela signifie si vous développez un logiciel de caisse
« La conformité, c'est l'affaire du commerçant, pas la nôtre. » Juridiquement, c'est en grande partie vrai : l'obligation pèse sur l'entreprise, et en Allemagne, en Autriche et en Suède, c'est l'entreprise qui déclare ses systèmes à l'administration fiscale.
Mais le commerçant ne peut remplir cette obligation qu'à travers le système que vous livrez, et trois décisions reviennent donc de votre côté du triangle :
- Quel composant de sécurité utiliser sur chaque marché, et si son agrément couvre la façon dont vous le déployez.
- Si chaque transaction passe par lui. Une vente qui saute l'étape de signature, à cause d'un chemin de code non testé ou d'une panne que le logiciel ne gère pas, laisse dans les enregistrements du commerçant un trou que celui-ci ne peut pas voir.
- Ce dont l'entreprise a besoin de votre part pour ses déclarations. Un commerçant autrichien qui s'enregistre auprès de FinanzOnline doit déclarer le numéro de série du certificat, le type d'unité de signature et les identifiants des caisses. Si votre système ne les fait pas apparaître, ou si votre fournisseur n'automatise pas l'enregistrement, le commerçant ne peut pas le finaliser.
Si vous éditez un logiciel de caisse, la conformité est à la fois l'obligation légale du commerçant et une fonctionnalité de votre produit.
Points clés à retenir
- L'obligation reste à l'entreprise. Acheter un logiciel de caisse et un service de signature déplace le travail technique, pas l'obligation légale ni les enregistrements.
- Les fournisseurs ont leurs propres obligations. Sur plusieurs marchés, la partie qui fabrique ou vend le système a des obligations légales, si bien que « c'est le commerçant qui est responsable » n'est jamais la réponse complète.
- « Certifié » demande une précision. Vérifiez qui se porte garant du composant de sécurité sur chaque marché avant de vous fier au mot.
- Le mode de transmission des données oriente les choix techniques. Là où les données sont transmises, prévoyez les pannes et les retransmissions ; là où elles attendent un contrôleur, la signature et l'export doivent tenir pendant des années.
La place de fiskaly
fiskaly est un fournisseur d'API cloud de fiscalisation et de conformité TVA : le sommet « composant de sécurité » du triangle. fiskaly ne vend pas de systèmes de caisse et ne traite pas de paiements.
En Allemagne, SIGN DE est la Cloud-TSE leader du marché, certifiée par le BSI. SIGN SE est un système de contrôle cloud (kontrollsystem) au titre du SKVFS 2020:9, certifié par un organisme de certification accrédité, et SIGN ES couvre Verifactu, TicketBAI et NaTicket via une seule API. SIGN AT signe les tickets, produit le DEP et automatise l'enregistrement auprès de FinanzOnline.
Les sommets restent les mêmes sur chaque marché ; ce sont les règles au centre qui changent.
