Facturation électronique en France pour les retailers : POS, omnicanal et e-reporting
Les retailers font face à un défi de facturation électronique en France différent de celui des entreprises qui émettent toutes leurs factures depuis un seul ERP.
Table of Contents
Les retailers font face à un défi de facturation électronique en France différent de celui des entreprises qui émettent toutes leurs factures depuis un seul ERP.
Un retailer peut traiter ses ventes en magasin, sur son site web, via des marketplaces, par l’intermédiaire d’équipes de service client et sur des canaux de vente en gros. Certains clients sont des entreprises. D’autres sont des consommateurs. Certaines transactions sont domestiques, d’autres transfrontalières.
La préparation à la facturation électronique commence donc, pour le retail, par la classification des transactions et l’identification des sources de données, et pas uniquement par le modèle de facture.
Points clés à retenir
- Les retailers doivent séparer la facturation électronique B2B domestique de l’e-reporting B2C et transfrontalier.
- Les systèmes POS peuvent devenir des sources importantes de données pour l’e-reporting.
- L’ERP, le POS, le e-commerce, les marketplaces et les systèmes de paiement peuvent tous contribuer aux données nécessaires.
- Les volumes élevés de transactions rendent la qualité des données et l’automatisation essentielles.
- Les remboursements, avoirs et corrections doivent être testés avant la mise en production.
- Les factures B2B doivent contenir les données structurées et les informations de routage requises.
- Les données de paiement peuvent être importantes pour l’e-reporting dans certaines situations.
- Une couche technologique peut connecter les systèmes retail à l’infrastructure française de facturation électronique.
Pourquoi la facturation électronique est plus complexe dans le retail
Un retailer dispose rarement d’un seul parcours client.
Un consommateur peut acheter un produit en magasin. Un autre client peut acheter sur le site web. Une entreprise française peut demander une facture après un achat en ligne. Un client grossiste peut recevoir régulièrement des factures B2B depuis l’ERP.
Ces transactions peuvent suivre des processus fiscaux et de reporting français différents.
La question essentielle n’est donc pas simplement : « Le retailer a-t-il émis une facture ? »
Il faut plutôt se demander : « Quel est le type de transaction, qui est le client, où la transaction est-elle traitée au regard de la TVA et quel processus de reporting s’applique ? »
1. Séparer les flux B2B et B2C
Les transactions B2B domestiques éligibles entre entreprises établies en France et soumises à la TVA française relèvent du cadre français de facturation électronique.
Les transactions B2C sont différentes.
Les ventes B2C peuvent relever de l’e-reporting des transactions lorsque les règles de TVA françaises applicables l’exigent.
Un retailer doit donc classifier les transactions avant d’envoyer les données dans le flux approprié.
Par exemple :
| Transaction | Processus français probable |
|---|---|
| Une entreprise française achète auprès d’un retailer français | Facturation électronique B2B domestique, lorsque les conditions sont remplies |
| Un consommateur français achète en magasin | E-reporting des transactions, lorsque applicable |
| Un consommateur français achète en ligne | E-reporting des transactions, lorsque applicable |
| Achat par une entreprise étrangère | Analyse TVA transfrontalière et reporting applicable |
| Vente à un consommateur étranger | Analyse TVA et e-reporting |
Ce tableau constitue un point de départ et ne remplace pas une analyse TVA au niveau de chaque transaction.
2. Les systèmes POS deviennent importants
Le système POS d’un retailer contient souvent les informations nécessaires pour comprendre les ventes aux consommateurs.
Il peut notamment contenir :
- Date de transaction
- Magasin
- Produit
- Quantité
- Montant HT
- Taux de TVA
- Montant de TVA
- Mode de paiement
- Remboursements
- Informations client lorsqu’elles sont collectées
Si le POS transmet uniquement un chiffre d’affaires quotidien à l’ERP, l’entreprise doit vérifier si les données disponibles sont suffisantes pour les exigences d’e-reporting applicables.
La solution n’est pas nécessairement de remplacer le POS.
Le retailer doit plutôt déterminer quelles données le POS peut exporter et comment elles peuvent être classifiées et consolidées avant le reporting.
3. L’omnicanal rend la classification encore plus importante
Un retailer omnicanal peut avoir :
- Magasins physiques
- Boutique en ligne
- Ventes via marketplaces
- Click-and-collect
- Commandes prises par le service client
- Ventes en gros
- Portails de comptes B2B
Chaque canal peut produire des données différentes.
L’architecture de facturation électronique doit donc s’appuyer sur un modèle commun de transaction.
Au minimum, il convient de capturer :
- Entité juridique
- Type de client
- Pays du client
- Traitement TVA
- Catégorie de transaction
- Canal de vente
- Montant taxable
- Montant de TVA
- Informations de paiement lorsque pertinentes
Cela évite que chaque canal de vente applique sa propre interprétation des règles françaises.
4. Les factures B2B nécessitent des données clients mieux structurées
Les retailers qui vendent aux entreprises doivent disposer de données clients fiables.
Pour les factures B2B françaises, vérifiez notamment :
- Dénomination sociale du client
- SIREN du client lorsque requis
- Établissement du client et SIRET ou informations d’adressage lorsque pertinents
- PA de réception
- Ligne d’adressage
- Adresse de facturation
- Adresse de livraison lorsqu’elle est différente
- Informations TVA
- Conditions de paiement
Cela est particulièrement important pour les grands clients disposant de plusieurs établissements.
Le seul nom du client ne suffit pas pour router de manière fiable une facture structurée.
5. Les remboursements et avoirs nécessitent leurs propres tests
Le retail génère un volume important de remboursements.
Un client peut retourner un produit après la vente initiale. Un remboursement partiel peut intervenir ultérieurement. Une commande annulée peut entraîner la création d’un avoir.
Ces événements doivent rester liés à la transaction d’origine.
Testez :
- Remboursement intégral
- Remboursement partiel
- Retour après émission de la facture
- Annulation de commande
- Avoir
- Correction de prix
- Remboursement en doublon
- Remboursement après paiement
Les enregistrements comptables et de reporting doivent rester cohérents.
Ne concevez pas les remboursements comme un processus séparé appartenant uniquement au système de paiement. Les équipes finance, fiscalité et technologie doivent disposer d’une vision commune de la vente d’origine et de son ajustement.
6. E-commerce et marketplaces
Le retail en ligne ajoute une autre source de données transactionnelles.
La plateforme e-commerce peut connaître le pays du client et le statut du checkout. Une marketplace peut détenir les données de commande et de paiement. L’ERP peut contenir l’enregistrement comptable.
Le retailer doit déterminer quel système constitue la source de référence pour chaque champ.
Par exemple :
| Donnée | Source possible |
|---|---|
| Compte client | E-commerce ou CRM |
| Produit | ERP ou système produit |
| Traitement TVA | Moteur fiscal ou ERP |
| Commande | E-commerce |
| Facture | ERP ou système de facturation |
| Paiement | Passerelle de paiement |
| Comptabilité | ERP |
| Statut de reporting | Couche technologique de facturation électronique |
Ce modèle de source de référence réduit les divergences entre les systèmes.
7. E-reporting des paiements
L’e-reporting des paiements peut s’appliquer à certaines transactions lorsque la TVA française devient exigible lors de l’encaissement, sous réserve des exceptions applicables.
Les retailers doivent donc déterminer si certaines de leurs transactions créent une obligation d’e-reporting des paiements.
La passerelle de paiement, l’acquéreur ou l’ERP peut détenir les informations nécessaires.
Il ne faut pas supposer que chaque paiement par carte doit être déclaré individuellement. L’obligation dépend des règles françaises applicables et de la transaction concernée.
Le système doit plutôt être capable d’identifier les transactions pour lesquelles les données de paiement sont requises.
8. Traitement des volumes élevés
Les systèmes retail peuvent générer des milliers de transactions.
Les volumes élevés créent plusieurs risques techniques :
- Messages en doublon
- Lots retardés
- Exports incomplets
- Agrégations incorrectes
- Remboursements manquants
- Écarts entre les données POS et ERP
- Échecs de reporting
L’intégration doit permettre un traitement contrôlé et un rapprochement des données.
Pour chaque période de reporting, le retailer doit pouvoir comparer les transactions sources avec les enregistrements préparés pour transmission.
Cela est particulièrement important lorsque plusieurs magasins ou canaux de vente alimentent le même processus de reporting.
9. Tester une intégration de facturation électronique pour le retail
Un plan de test retail utile comprend :
Tests des transactions en magasin
Tester les ventes normales, retours, remises, plusieurs taux de TVA et identification du client.
Tests B2B
Tester un client professionnel français, plusieurs établissements, le routage correct et la correction d’une facture.
Tests e-commerce
Tester les ventes aux consommateurs, annulations, remboursements et commandes transfrontalières.
Tests marketplace
Tester les données de commande marketplace, les modèles de vendeur officiel et les données de paiement lorsque pertinentes.
Tests de rapprochement
Comparer les données POS, e-commerce, ERP et reporting.
Tests d’échec
Tester les doublons, les données manquantes, les transmissions échouées et la gestion des nouvelles tentatives.
Les tests doivent utiliser des volumes de transactions réalistes lorsque cela est possible.
10. Comment Complyance peut s’intégrer
Complyance peut fournir une couche technologique et d’intégration entre les systèmes retail et l’infrastructure française de facturation électronique.
Cette approche peut connecter l’ERP, le POS, le e-commerce et les autres systèmes sources, appliquer le mapping et la validation, puis préparer les données appropriées pour les échanges et le reporting réglementés.
Pour la France, la configuration exacte de la PA, les formats pris en charge, les fonctions API et les responsabilités de reporting doivent être confirmées pour le déploiement envisagé.
L’objectif est de connecter les systèmes existants du retailer sans obliger chaque magasin, site web ou application POS à devenir son propre système de conformité français.
Checklist de facturation électronique pour le retail en France
Avant la mise en production, confirmer que :
- Toutes les entités juridiques françaises sont identifiées.
- Les transactions B2B et B2C sont classifiées.
- Les données POS sont disponibles pour l’e-reporting applicable.
- Les données e-commerce sont cartographiées.
- Les flux marketplace sont compris.
- Les données SIREN et d’établissement des clients sont maintenues lorsque requises.
- La PA de réception est officiellement désignée lorsque nécessaire.
- Les informations de routage sont testées.
- Les remboursements et avoirs sont liés aux transactions d’origine.
- Les données de paiement sont disponibles lorsque le reporting s’applique.
- La prévention des doublons est mise en œuvre.
- Les données POS, ERP et reporting peuvent être rapprochées.
- Les procédures d’échec et de reprise sont testées.
Conclusion
La facturation électronique en France pour les retailers est un projet impliquant plusieurs systèmes.
Le travail essentiel concerne le POS, la plateforme e-commerce, l’ERP, les données clients, les systèmes de paiement et le processus de reporting.
Les retailers qui cartographient rapidement leurs types de transactions et leurs sources de données peuvent construire un processus plus fiable pour la facturation électronique B2B et l’e-reporting.
Sources officielles
DGFiP : découvrir la réforme de la facturation électronique
DGFiP : facturation électronique et plateformes agréées
DGFiP : spécifications externes de la facturation électronique
Frequently Asked Questions
Non. La facturation électronique B2B domestique et l’e-reporting des transactions B2C sont deux processus différents.
Non. Un POS est un système métier. Les échanges et le reporting réglementés utilisent le cadre des plateformes agréées.
Oui. La réforme n’impose pas à elle seule de remplacer un ERP. L’important est de vérifier que les systèmes existants peuvent fournir les données requises et se connecter à l’infrastructure appropriée.
Pas automatiquement. Le traitement TVA, la structure de la transaction et les parties concernées déterminent le processus applicable.
About the Author
Swathy
Content Marketer
I’m a Content Marketer at Complyance, focused on e-invoicing. Over the years, I’ve created a wide range of content, including blog posts, whitepapers, and product guides, which have supported Complyance’s growth across markets such as the UAE and EU regions. My goal is to deliver content that is comprehensive, clear, accurate, and easy to understand, no matter how complex the topic.
