En Europe, les éditeurs de logiciels de caisse font face à deux obligations de conformité en même temps. La fiscalisation est un terrain connu : un pays après l'autre exige désormais que chaque transaction soit signée de manière inaltérable à la caisse. La facturation électronique arrive vite. L'Italie impose des factures structurées depuis 2019, la Belgique, la France et la Pologne ont suivi en 2026, et l'Allemagne et l'Espagne sont les prochaines, en 2027.
Face à deux obligations, la plupart des éditeurs construisent deux intégrations. La fiscalisation reste dans la caisse, tandis que la facturation électronique part au back-office, coupée de l'encaissement où la vente a eu lieu.
Sur le papier, cela fonctionne. En pratique, une vente se retrouve dans deux bases de données, avec deux pistes d'audit qui peuvent ne pas concorder et, dans le pire des cas, la même TVA due deux fois.
Voici comment cela fonctionne lorsque les deux passent par la caisse, avec une API, un prestataire et une piste d'audit.
Que se passe-t-il vraiment quand la facture vit dans un second système ?
« Déconnecté » ne signifie presque plus papier et stylo. En général, l'outil de facturation électronique est relié à l'ERP, au logiciel comptable ou à une couche middleware entre les deux. Chaque transaction est exportée, synchronisée ou ressaisie et, sur une diapositive, le problème semble réglé.
En réalité, plusieurs systèmes se partagent désormais l'enregistrement d'une seule vente, et chaque transfert entre eux est un point où la vérité peut se dédoubler.
Suivons une vente B2B tout au long de cette chaîne :
- La vente commence dans la caisse. Lignes d'articles, taux de TVA, paiement et signature fiscale sont saisis au comptoir. C'est l'enregistrement qui fait foi juridiquement.
- Les données quittent la caisse. Elles transitent par un export nocturne, une synchronisation middleware ou un import CSV, ou quelqu'un les ressaisit à partir d'un ticket. À chaque étape, codes TVA, règles d'arrondi, familles d'articles et remises sont transposés dans le modèle d'un autre système. Chaque transposition est une traduction, pas une copie.
- La facture est recréée. Le second système produit la facture électronique à partir des données reçues, pas à partir de la vente elle-même. Si une ligne disparaît, si un code TVA est réaffecté ou si une remise est appliquée dans un autre ordre, la facture ne correspond plus à l'enregistrement fiscal.
- Les corrections font diverger les systèmes. Imaginez qu'une vente soit annulée dans la caisse après la synchronisation, ou qu'un avoir soit émis dans l'ERP sans toucher à la caisse. Les deux systèmes ne s'accordent alors plus jamais sur ce qui a été vendu, et rien dans cette configuration ne les réaligne.
- Le contrôleur voit deux versions. Le journal fiscal enregistre une version de la vente, l'archive des factures en enregistre une autre. Les rapprocher transaction par transaction, sur des durées de conservation pouvant aller jusqu'à dix ans, revient au commerçant. Il s'en aperçoit généralement au pire moment : pendant le contrôle.
Il existe une conséquence plus lourde que des enregistrements discordants : la même vente, taxée deux fois.
Dans les systèmes de TVA de l'UE, la taxe mentionnée sur un document émis est en principe due à l'administration fiscale. Lorsque la caisse émet un ticket faisant apparaître la TVA et qu'un second système émet plus tard une facture complète pour la même vente, sans que les deux soient liés comme une seule opération, le commerçant risque de devoir cette TVA deux fois jusqu'à ce que le doublon soit détecté et corrigé. L'Allemagne l'écrit noir sur blanc au § 14c UStG : la TVA mentionnée à tort ou en supplément est due, un point c'est tout. Ce qui commence comme une faille de processus finit en dette fiscale.
Rien de tout cela n'est un cas marginal. C'est le quotidien de la configuration à deux systèmes, et chaque outil de facturation électronique de back-office est construit autour.
Pourquoi la facture doit être là où la vente a lieu
L'alternative intégrée est simple. La même couche cloud qui signe la transaction pour la fiscalisation émet aussi la facture électronique, à partir des données réelles de la transaction au moment de la vente.
Trois scènes du quotidien montrent la différence :
Le dîner d'affaires. Un client règle un dîner d'équipe bien au-delà du seuil de la facture simplifiée.
- Intégré : la facture électronique est émise à table ou arrive dans la boîte mail du client quelques secondes plus tard. Elle est produite à partir de la transaction signée et liée au ticket, de sorte que la déduction de la dépense est assurée dès le premier jour.
- Déconnecté : quelques semaines plus tard, le client écrit pour demander une facture. Quelqu'un reconstitue le dîner dans le logiciel comptable à partir d'une photo du ticket. Le restaurant a désormais émis deux documents mentionnant la TVA pour un seul repas. S'ils ne sont pas liés comme une seule opération, le restaurant risque de devoir cette TVA deux fois. C'est un risque fiscal, pas seulement un problème de service.
Le comptoir professionnel. Un acheteur professionnel donne son numéro de TVA intracommunautaire à la caisse d'un magasin.
- Intégré : la caisse qui imprime le ticket émet aussi la facture électronique, et le système de comptabilité fournisseurs de l'acheteur la traite automatiquement.
- Déconnecté : la vente arrive dans l'ERP avec l'export nocturne. Là, un code TVA réaffecté et une règle d'arrondi différente produisent une facture qui ne correspond plus au centime près à l'enregistrement fiscal. Personne ne s'en rend compte jusqu'à ce qu'un contrôleur compare les deux systèmes.
Le départ de l'hôtel. Un client d'entreprise quitte l'hôtel.
- Intégré : la réception émet sur-le-champ la facture électronique pour tout le séjour. Le touriste suivant dans la file reçoit simplement un ticket. C'est le même flux, avec une seule question.
- Déconnecté : le logiciel de gestion hôtelière synchronise la note avec la comptabilité pendant la nuit. Le lendemain matin, la comptabilité ajuste le tarif entreprise, si bien que la facture finalement envoyée ne correspond plus aux données de la réception.
Dans tous les cas, les données naissent dans la caisse. Déplacer la facture vers un second système, c'est reconstruire ces données ailleurs, avec tout ce qui déraille quand une synchronisation, une correspondance ou une personne reconstruit des données au lieu de les réutiliser.
Intégré ou déconnecté : la comparaison
| Critère | Intégré (dans la caisse via le cloud) | Déconnecté (configuration back-office) |
|---|---|---|
| Exactitude des données | Facture produite à partir de la transaction réelle : mêmes lignes, même ventilation de TVA, un seul système de référence | Traduite dans le modèle de données d'un autre système, et les traductions dérivent : codes TVA, arrondis et structure des lignes cessent peu à peu de correspondre à l'enregistrement fiscal |
| Piste d'audit | Signature fiscale, ticket et facture XML liés dans un seul système et archivés de manière conforme | Deux pistes d'audit dans deux bases de données, à rapprocher transaction par transaction |
| Risque de double TVA | Une chaîne de documents liée par vente : ticket et facture renvoient à la même opération | Ticket plus facture ultérieure non liée pour la même vente : la TVA mentionnée deux fois peut être due deux fois (en Allemagne : § 14c UStG) jusqu'à correction |
| Déduction de TVA de l'acheteur | Facture électronique conforme à la caisse ou quelques secondes plus tard | L'acheteur court après la facture pendant des semaines ; souvent, elle n'arrive jamais |
| Charge pour le personnel | Une seule question à la caisse, aucune seconde étape à retenir | Repérer le cas B2B, noter les informations sur papier, transmettre au back-office |
| Préparation au reporting en temps réel | La couche cloud se trouve déjà dans le flux de transaction : le reporting s'ajoute sans toucher à la caisse | Ne peut pas déclarer au moment de la transaction par conception ; refonte structurelle lorsque le reporting arrive |
| Déploiement multi-pays | Une intégration couvre XRechnung, ZUGFeRD, Factur-X, FatturaPA, Peppol et d'autres régimes | Les formats et canaux de chaque pays sont gérés séparément dans chaque outil de back-office |
Une API, un prestataire : ce que la consolidation fait économiser
Sous le capot, fiscalisation et facturation électronique résolvent le même type de problème. Chacune prend une transaction, la convertit dans un format exigé par la loi, la transmet et la conserve de manière probante pendant des années.
Gérez-les comme deux systèmes séparés et vous dupliquez chaque couche :
- deux modèles de données à garder synchronisés
- deux configurations d'authentification et structures d'organisation
- deux pistes d'audit à rapprocher
- deux prestataires et files de support à coordonner
- deux séries d'évolutions réglementaires à suivre dans chaque pays
Dans le modèle intégré, la facturation électronique s'appuie sur ce que vous avez déjà pour la fiscalisation : les mêmes données de transaction, la même authentification, la même structure d'organisation, le même journal inaltérable, la même archive et le même contrat de support. Deux obligations, une intégration. Ajouter la seconde obligation coûte bien moins cher, tout comme ajouter le pays suivant.
ViDA arrive et rapproche la conformité de la vente
La meilleure raison de bien concevoir cette architecture, c'est ce qui vient ensuite. Le paquet européen VAT in the Digital Age (ViDA) rend obligatoires les exigences de déclaration numérique pour les opérations transfrontalières d'ici 2030, les États membres y superposant leurs propres régimes nationaux en temps réel.
La direction est claire : la déclaration se rapproche de la transaction. Un outil de back-office qui reçoit les données plusieurs jours après la vente ne peut suivre qu'en raccourcissant sa synchronisation, et chaque synchronisation est un point de plus où les deux enregistrements peuvent diverger. Quand le délai de déclaration se réduira, la configuration déconnectée n'aura pas besoin d'une mise à jour. Elle devra être reconstruite.
Une couche cloud intégrée se trouve déjà dans le flux de transaction. Elle signe la transaction aujourd'hui, et ajouter une étape de déclaration demain prolonge ce même flux, sans retoucher l'intégration de la caisse. C'est le même pari d'architecture qui a tranché la dernière vague de conformité : la fiscalisation cloud a supplanté le matériel précisément parce qu'une plateforme distante et versionnée absorbe les évolutions réglementaires pour chaque caisse connectée.
Là où le modèle déconnecté tient encore
La facturation électronique intégrée n'est pas une obligation légale aujourd'hui, et le modèle déconnecté garde du sens dans quelques cas :
- Les petits tickets restent simples. En dessous du seuil de la facture simplifiée (250 € en Allemagne), un ticket suffit. Mais les ventes au-dessus de ce seuil sont précisément les transactions B2B qui comportent un risque de contrôle et de double TVA.
- Les échéances sont échelonnées. Sur plusieurs marchés, l'émission de factures électroniques depuis la caisse reste facultative pendant un ou deux ans. Mais construire l'intégration prend du temps, et les éditeurs qui commencent maintenant n'auront pas à la bâtir dans l'urgence la dernière année.
Le modèle déconnecté est légal, mais il coûte cher, d'une manière que la grille tarifaire ne montre pas : travail de rapprochement, frictions lors des contrôles, risque de double TVA, acheteurs frustrés, développement en double et refonte dès que la déclaration se rapprochera de la vente, avant 2030.
Points clés
- Une seule vente B2B à la caisse peut relever à la fois de la fiscalisation et de la facturation électronique : les répartir sur deux systèmes crée deux enregistrements pour une seule transaction.
- Si un ticket et une facture séparée ne sont pas liés comme une seule opération, la même TVA peut être due deux fois. En Allemagne, c'est le § 14c UStG qui le prévoit.
- Faire passer les deux obligations par une seule API permet de partager l'authentification, la piste d'audit et l'archive, de sorte que le pays suivant coûte moins cher.
- ViDA rapproche la déclaration de TVA de la transaction d'ici 2030. Une couche cloud déjà présente dans le flux de transaction peut ajouter la déclaration sans refonte.
La place de fiskaly
fiskaly construit une infrastructure cloud de conformité TVA précisément pour cette situation. Notre API de facturation électronique fiskaly E-INVOICE fonctionne sur la même plateforme que nos produits de fiscalisation, de sorte que les deux obligations partagent une authentification, une structure d'organisation et une piste d'audit. Formats EN 16931, accès Peppol et archivage conforme sont tous couverts par une seule intégration.
