Ce que le contrôleur extrait vraiment de votre caisse

La plupart des exploitants ne voient jamais le DSFinV-K. Ce n'est ni un ticket, ni un état, et on ne le dépose nulle part à échéance régulière. Il n'apparaît qu'en une occasion : quand quelqu'un du Finanzamt se tient à votre comptoir, ou s'installe dans votre bureau pour une Betriebsprüfung, et demande « l'export » à votre caisse.

Depuis le 1er juillet 2022, cet export doit suivre la version 2.3 de la norme. La période transitoire de 2022 pour les caisses anciennes non évolutives s'achève par ailleurs le 31 décembre de cette année — à partir de 2023, il n'existera donc plus de caisse électronique allemande sans TSE ni DSFinV-K.

Ce que signifie DSFinV-K

Digitale Schnittstelle der Finanzverwaltung für Kassensysteme — l'interface numérique de l'administration fiscale pour les systèmes de caisse. Elle définit un format de données unique et neutre afin qu'un contrôleur puisse lire les données de n'importe quelle caisse avec le même outil. Le contrôleur charge votre export dans un logiciel d'audit, généralement IDEA, et lance des contrôles automatisés : trous dans les numéros de ticket, ruptures dans la chaîne de signatures de la TSE, motifs d'annulation suspects, incohérences de TVA, totaux journaliers qui ne collent pas aux tickets Z.

Autrement dit : l'export est la déposition de votre caisse. Il doit être complet, cohérent et produit sur demande.

À quoi ressemble un contrôle

Une Kassen-Nachschau est inopinée. Un contrôleur peut se présenter pendant les heures d'ouverture, demander à voir la caisse, observer son usage et exiger l'export DSFinV-K sur place, sur une clé USB. Si l'export ne fonctionne pas, ou prend des heures, c'est déjà une observation.

Trois choses qu'un exploitant doit pouvoir faire sans appeler un technicien :

1. Déclencher l'export DSFinV-K pour n'importe quelle période, depuis la caisse ou l'arrière-boutique.
2. Présenter la Verfahrensdokumentation — qui a configuré quoi, quelle TSE est en service, comment sont gérées les pannes.
3. Montrer que les clôtures journalières — Tagesabschlüsse, tickets Z — sont faites chaque jour et concordent avec l'export.

Si l'une des trois est un « il faut que j'appelle quelqu'un », faites-la corriger dès maintenant par votre fournisseur.

Pour les développeurs et les intégrateurs

Le DSFinV-K est un ensemble de fichiers CSV accompagnés d'un index.xml qui les décrit, livré en paquet par caisse et par période. Il comporte trois couches structurelles.

Données de référence. Les tables Stamm_ portent le contexte auquel une transaction appartient : Stamm_Abschluss, Stamm_Orte, Stamm_Kassen, Stamm_Terminals, Stamm_Agenturen, Stamm_USt, Stamm_TSE. Chaque clôture journalière — Z_KASSE_ID, Z_ERSTELLUNG, Z_NR — est la clé à laquelle se rattache toute autre ligne.

Données de tickets. Les tables Bon contiennent une ligne par ticket dans Bonkopf, avec les tables filles Bonkopf_USt pour la ventilation de TVA, Bonkopf_Zahlarten pour les paiements, Bonkopf_AbrKreis, et Bonpos pour les lignes d'articles avec Bonpos_USt, Bonpos_Preisfindung et Bonpos_Zusatzinfo. BON_TYP distingue une vente — un Beleg — de la formation, de l'annulation et des types non fiscaux « AVBelegabbruch ».

Données de transactions TSE. TSE_Transaktionen fait le pont entre vos tickets et les signatures : numéro de transaction, heures de début et de fin, type et données du processus, compteur et valeur de signature, et l'identifiant de TSE issu de Stamm_TSE. Chaque ligne Bonkopf doit référencer exactement une transaction TSE.

S'y ajoutent les tables de clôture — Z_GV_Typ, Z_Zahlart, Z_Waehrungen — qui rapprochent les totaux par type d'opération, mode de paiement et devise.

Règles pratiques apprises à la dure :

• Le modèle d'abord, l'export ensuite. Si votre table de transactions ne peut pas répondre à « quelle transaction TSE a signé ce ticket, et quelle était la ventilation de TVA au niveau ligne », aucun formatage CSV ne vous sauvera. L'export est la projection d'un modèle de données correct.
• Immuabilité. Ne modifiez ni ne supprimez jamais une ligne de ticket. Les corrections sont de nouveaux tickets portant une référence d'annulation. Les contrôleurs cherchent les retouches.
• Numérotation. Les numéros de ticket doivent être sans trou par caisse. Testez ce qui se passe en cas de plantage entre la réponse FINISHED de la TSE et votre propre validation.
• Les clôtures sont obligatoires. Une journée sans ligne Stamm_Abschluss est une journée que le contrôleur ne peut pas rapprocher. Automatisez la clôture ; ne comptez pas sur la mémoire du personnel.
• Encodage et format. UTF-8, séparateur point-virgule, champs texte entre guillemets, dates en ISO 8601 avec fuseau. L'index.xml doit décrire chaque fichier précisément — les validateurs rejettent un paquet pour un écart trivial.
• Utilisez l'export du fournisseur de TSE quand c'est possible. Les prestataires cloud comme fiskaly produisent de leur côté le fichier TSE_Transaktionen et l'export du journal TAR ; vous les fusionnez avec vos données métier. Cela retire la partie la plus propice aux erreurs.
• Testez avec le validateur officiel — la DFKA et plusieurs éditeurs publient des vérificateurs — et avec une vraie période de production, pas une journée fabriquée.

La version 2.3 a apporté des définitions de champs plus strictes et des clarifications plutôt que de nouvelles tables. Si vous produisiez déjà proprement des exports 2.2, la montée de version tient surtout de la validation. Sinon, c'est le moment.

Ceci est une information générale, non un conseil juridique ou fiscal.

Daleenda audite les implémentations DSFinV-K et construit des couches d'export pour des caisses sur mesure. Envoyez-nous un paquet d'exemple et nous vous dirons ce qu'un Betriebsprüfer y trouverait.

Faites relire votre export