Facturation électronique : Comprendre le e-reporting et le flux 10 (Guide Éditeur)

La réforme française de la facturation électronique ne se limite pas au e-invoicing. Elle impose aussi un second dispositif, souvent moins bien compris mais tout aussi structurant pour les éditeurs : le e-reporting.

En pratique, le e-reporting oblige les entreprises à transmettre à l’administration fiscale certaines données de transaction et données de paiement qui ne passent pas par le circuit classique de la facture électronique B2B domestique.

👉 Pour un éditeur, le sujet n’est donc pas seulement “envoyer un flux”, mais :

• qualifier les bonnes opérations
• les rattacher à la bonne période
• produire le bon niveau d’agrégation
• gérer les contrôles du PPF

Qu’est-ce que le e-reporting dans la réforme de la facturation électronique ?

Le e-reporting couvre tout ce que l’e-invoicing ne couvre pas, dès lors que ces opérations ont un impact TVA en France.

Cela vise notamment :

• Les opérations B2C ; les logiciels de caisse (restauration, POS...) par exemple mas aussi les transaction avec un particulier hors caisse ou transaction avec un non assujeti type structure associative.
• Les opérations B2B internationales ; les transactions entre un asujeti TVA français et une entreprise étrangère, que ce soit pour un flux d'achat ou de vente.
• Certaines données de paiement liées au opération B2C ou B2Bi cités précédemment

L'idée est que l'administration fiscale française puisse avoir une vue sur l'ensemble des transactions et données fiscales (TVA) associées pour compléter le périmètre de la réforme de la facturation électronique.

📅 Le calendrier d'obligation pour 2026 et 2027

• 1er septembre 2026 :

  • réception obligatoire pour toutes les entreprises (facturation électronique)
  • émission + e-reporting pour grandes entreprises et ETI

• 1er septembre 2027 :

  • obligation de e-reporting étendue aux PME et micro-entreprises

---

⚡ À retenir / TL;DR

• Le e-reporting couvre : B2C, B2B international, paiements
• Le e-reporting complète ce que le e-invoicing ne couvrait pas
• Le flux 10 (F10) est le format d’échange dédié
• 4 blocs : 10.1, 10.2, 10.3, 10.4
• Le vrai sujet = logique métier et fiscale, pas le XML
• Transactions et paiements peuvent être décorrélés dans le temps
• Approche recommandée : unitaire en entrée, agrégation en sortie
• Objectifs : donnée une vue complète à l'administration fiscale et permettre à terme le préremplissage des déclaration TVA.

Référentiel sur les normes du e-reporting français : Spécifications externes B2B

---

E-reporting vs E-invoicing : Quelles différences pour votre produit ?

E-reporting : définition, périmètre et objectif

Le e-reporting est l’obligation de transmettre à l’administration fiscale des données relatives :

• aux opérations internationales entre entreprises
• aux opérations avec des non-assujettis (B2C)
• aux paiements associés (selon les cas)

📊 Comparatif des blocs du flux 10 (e-reporting)

Le périmètre : B2C, B2B international et données de paiement

1. Opérations B2C

• Bloc 10.3 : transactions
• Bloc 10.4 : paiements

Les opérations B2C correspondent à toutes les ventes réalisées avec des non-assujettis à la TVA, c’est-à-dire principalement des particuliers, mais aussi certaines organisations non soumises à TVA. Par exemple les associations.

Dans le cadre du e-reporting, ces opérations ne sont pas transmises sous forme de factures individuelles, mais via une logique d’agrégation réglementaire.

Concrètement, chaque occurrence du bloc correspond à :

• une journée d’activité
• une devise
• un type de transaction

Prenons l'exemple d'un restaurateur qui passe par un logiciel de caisse. Sa caisse enregistreuse va en général, à la fin de la journée, faire un ticket-Z ou Z de caisse qui est déjà une aggrégation des transactions de la journée.

La déclaration à l'administration fiscale se fait ensuite sur une période fiscale par aggrégation des tickets Z eux mêmes. Ce point cera détaillé plus bas.

⚠️ Point clé : transaction ≠ paiement

• la transaction (10.3) correspond à l’acte de vente
• le paiement (10.4) correspond à l’encaissement

Ces deux événements peuvent :

• intervenir à des dates différentes
• être rattachés à des périodes fiscales différentes

Exemples :

• paiement différé (BNPL, virement)
• acompte + solde
• remboursement partiel
• omnicanal (commande web, paiement en magasin)

2. Opérations B2B internationales - flux 10.1

• Opérations hors e-invoicing domestique
• Cas : B2Bi, Bi2B, Bi2Bi

Les opérations B2B internationales concernent les transactions entre assujettis à la TVA dès lors qu’elles n’entrent pas dans le périmètre du e-invoicing domestique français.

Autrement dit : toute opération entre entreprises avec une dimension internationale peut relever du e-reporting, dès lors qu’elle a un impact TVA en France.

Cela inclut plusieurs cas de figure, parfois complexes d’un point de vue fiscal :

• ventes à des entreprises étrangères
• achats auprès de fournisseurs étrangers
• opérations taxables en France impliquant des acteurs non établis

Les spécifications distinguent plusieurs cas :

• B2Bi : vente d’une entreprise française vers une entreprise étrangère
• Bi2B : acquisition en France auprès d’un fournisseur étranger
• Bi2Bi : opérations complexes où la TVA est due en France, même si les deux parties ne sont pas établies en France

👉 Ces cas impliquent souvent :

• autoliquidation
• règles spécifiques de territorialité
• analyse fine du régime TVA

Le flux 10.1 sert à transmettre les données de facturation liées aux opérations internationales.

Contrairement au B2C :

• on est ici sur une logique nominative
• 1 occurrence = 1 facture

👉 Ce bloc est utilisé lorsque :

• une facture est émise (ou reçue selon le rôle)
• et que l’opération doit être déclarée via le e-reporting

3. Données de paiement - Flux 10.2

• Concernent les cas de TVA à l’encaissement
• Encadrées par l’article 290 A du CGI

Le bloc 10.2 concerne les encaissements liés aux factures internationales, lorsque la transmission des paiements est requise (ex : TVA à l’encaissement).

👉 Ici aussi :

• 1 occurrence = 1 encaissement
• lien direct avec une facture du bloc 10.1

⚠️ Point clé : facture ≠ paiement

Comme pour le B2C, mais avec une granularité différente :

• le bloc 10.1 = logique facture (émission)
• le bloc 10.2 = logique encaissement (paiement)

Ces deux dimensions peuvent être :

• découplées dans le temps
• transmises sur des périodes différentes

Exemples :

• paiement en plusieurs fois
• acompte + solde
• facture émise en N, encaissée en N+1
• retards de paiement

❌ Ce que le e-reporting ne couvre pas

• Pas de remplacement du e-invoicing
• Le B2B domestique = facture électronique obligatoire

Pourquoi le e-Reporting ?

1. Lutter contre la fraude à la TVA

   • Le e-reporting permet à l’administration fiscale de recevoir directement les données de transaction et paiement qui échappent au circuit classique de facturation B2B domestique.
   • Cela réduit les risques de fraude ou omission sur les ventes B2C ou internationales.

2. Fiabiliser les données fiscales

   • La transmission systématique et standardisée des flux 10 assure une cohérence entre transactions, paiements et déclarations TVA.
   • Les erreurs de saisie, doublons ou omissions sont plus faciles à détecter et corriger.

3. Faciliter le pré-remplissage des déclarations

   • Grâce au e-reporting, l’administration dispose d’une vision consolidée et à jour des opérations.
   • Les entreprises peuvent bénéficier de déclarations TVA pré-remplies, réduisant le travail manuel et les risques d’erreur.

En résumé, le e-reporting complète le e-invoicing en couvrant toutes les opérations qui impactent la TVA mais échappent aux factures électroniques domestiques, avec un double bénéfice pour l’administration et les entreprises.

E-reporting vs e-invoicing

Comparatif

🔑 Différence fondamentale

• E-invoicing → pivot = facture
• E-reporting → pivot = transaction / paiement / agrégat

---

Zoom sur le Flux 10 : Structure et Blocs 10.1 à 10.4

Flux 10

Le flux 10 est :

• un format réglementaire
• structuré pour :
  • contrôle
  • agrégation
  • rectification

Données racine :

• identifiant de transmission
• SIREN déclarant
• période
• type de transmission

Flux 10.1 : Factures internationales

Le flux 10.1 est dédié aux opérations internationales entre entreprises qui nécessitent une déclaration dans le cadre du e-reporting.

Principes clés :

• 1 occurrence = 1 facture : chaque facture internationale doit être déclarée individuellement.
• Logique nominative : les informations sont liées à une facture précise et aux parties concernées (vendeur, acheteur), contrairement aux flux agrégés B2C.

Données attendues :

• Identification complète des parties (SIREN, pays d’établissement, rôle dans la transaction)
• Montants HT, TVA et TTC
• Devise utilisée et taux de change si applicable
• Mentions fiscales spécifiques (autoliquidation, exonération, mécanismes particuliers)
• Référence de la facture et date d’émission

Selon la norme AFNOR XP Z12-014 version 1.3 :

Comme il n’est pas autorisé de créer des factures avec une date de facture postérieure à sa date de création, les données de facture présentes dans un flux 10 (flux 10.1) ne peuvent pas avoir une date de facture (TT-19) postérieure à la date de remise du flux 10 (sous 10 jours de la fin de période pour les entreprises au régime normal).

Points importants côté éditeur logiciel :

• Assurer la correspondance exacte facture ↔ flux 10.1
• Vérifier que la facture relève bien du B2B international et n’entre pas dans le périmètre du e-invoicing domestique
• Gérer les devises et conversions pour que les montants soient corrects et conformes à la TVA française
• Préparer le système pour des rectificatifs si une facture est modifiée après transmission

En résumé : le 10.1 est un flux unitaire et nominatif, centré sur la facture internationale, avec une traçabilité complète pour l’administration fiscale.

Flux 10.2 : Paiements internationaux

Le flux 10.2 concerne les encaissements liés aux factures internationales, lorsque la TVA est exigible à l’encaissement.

Principes clés :

• 1 occurrence = 1 encaissement : chaque paiement reçu pour une facture internationale doit être déclaré individuellement.
• Lien facture obligatoire : chaque encaissement doit être relié à la facture correspondante (référence et date), garantissant la traçabilité et la cohérence avec le flux 10.1.

Données attendues :

• Référence de la facture et date d’émission correspondante
• Montant encaissé et devise
• Date réelle de paiement
• Mode de paiement (si requis par la réglementation)
• Rattachement au bon régime de TVA et au bon rôle du déclarant

Points importants côté éditeur de la solution métier :

• Assurer la corrélation exacte entre facture (10.1) et paiement (10.2)
• Gérer les paiements partiels et les multi-encaissements pour une même facture
• Vérifier les conversions de devise pour que les montants soient conformes à la TVA
• Préparer le système à envoyer des flux rectificatifs en cas d’erreur ou de modification du paiement

En résumé : le 10.2 est un flux unitaire et nominatif, centré sur l’encaissement de chaque facture internationale, avec un lien obligatoire vers la facture pour assurer la traçabilité et la conformité fiscale.

Flux 10.3 : Transactions B2C

Le flux 10.3 concerne les transactions avec des non-assujettis (particuliers) et s’inscrit dans la logique B2C du e-reporting.

Principes clés :

• Données agrégées : contrairement aux flux unitaires B2B, les transactions B2C sont transmises sous forme consolidée.
• 1 occurrence = 1 jour + devise + type de transaction : chaque ligne du flux regroupe toutes les ventes d’un même jour pour une devise et un type de transaction donné (ex. vente comptoir, e-commerce, ticket de caisse).

Données attendues :

• Montants totaux HT et TTC pour la journée
• Ventilation TVA par taux applicable
• Nombre de transactions par type
• Devise utilisée
• Identification de l’établissement ou point de vente si nécessaire

Points importants côté éditeur :

• Les tickets unitaires ou ventes individuelles ne sont pas transmis ; le flux repose sur l’agrégation réglementaire.
• Gestion des annulations, remboursements et corrections journalières pour garantir l’exactitude des montants agrégés.
• Les systèmes omnicanal doivent consolider les ventes de plusieurs points de vente ou canaux dans le flux unique par jour/devise/type.
• Préparer la plateforme métier et l'interfaçage avec la Plateforme Agréée pour rectificatifs si l’agrégation d’un jour doit être ajustée.

En résumé : le 10.3 est un flux agrégé, centré sur les transactions B2C, conçu pour fournir à l’administration une vue consolidée sans transmettre chaque ticket individuel.

Flux 10.4 : Paiements B2C

Le flux 10.4 est dédié aux encaissements issus des transactions B2C, avec une logique d’agrégation quotidienne.

Principes clés :

• Agrégation des encaissements : toutes les entrées de fonds d’une même journée sont consolidées pour chaque point de vente ou canal.
• Logique journalière : chaque occurrence correspond à une journée d’activité, par devise et par type de paiement.

Données attendues :

• Montant total encaissé HT et TTC pour la journée
• Ventilation TVA selon les taux applicables
• Nombre de paiements par type (espèces, carte, virement…)
• Devise utilisée
• Identification de l’établissement ou du canal si nécessaire

Points importants côté éditeur :

• Il faut distinguer la date de transaction de la date d’encaissement, car elles peuvent différer (ex. acomptes, paiements différés, e-commerce).
• Consolider les paiements venant de plusieurs canaux ou points de vente dans le même flux journalier.
• Préparer la plateforme métier à envoyer des flux rectificatifs à la PLateforme Agréée si des encaissements sont ajustés après clôture de la journée.
• S’assurer que l’agrégation respecte la périodicité définie par le régime TVA du déclarant.

En résumé : le 10.4 est un flux agrégé, centré sur les encaissements B2C, conçu pour fournir à l’administration une vue consolidée sans remonter chaque paiement individuel.

---

Architecture logicielle : Comment gérer l'agrégation et les périodes de TVA ?

Agrégation

• par SIREN
• par rôle (vendeur / acheteur)

⚠️ Cas à gérer avec prudence

• exonérations
• hors champ TVA
• autoliquidation
• régimes spécifiques

📆 Périodes des liasses fiscales

Dépendent du régime TVA :

• mensuel
• trimestriel

C'est variable selon les clients et utilisateurs du logiciel d'encaissement / de facturation

Pour certains régimes de TVA, les périodes de transmission des données de transaction sont différentes des périodes de transmission des données de paiement. De ce fait, les plateformes agréées doivent transmettre au portail public de facturation (PPF) les données de transaction et de paiement (F10) de manière distincte, à l’issue des périodes correspondantes à chaque type de données. (Extrait des specifications-externes-v3.1 - www.impots.gouv.fr/specifications-externes-b2b)

Périodes de transmission du e‑reporting selon le régime TVA

Transaction vs paiement

Dans le e-reporting, transaction et paiement ne sont pas toujours synchronisés.

Points clés :

• Les transactions représentent les ventes ou prestations réalisées.
• Les paiements correspondent aux encaissements réellement reçus.
• Selon le régime de TVA, les périodes peuvent différer : une vente effectuée en fin de mois peut être encaissée le mois suivant.
• Les transmissions sont distinctes : le flux 10.3 (transactions B2C) est envoyé séparément du flux 10.4 (paiements B2C), chacun avec sa propre période et son propre agrégat.

Exemple pour un logiciel de caisse :
Imaginons un commerce utilisant un POS standard :

• Le 28 mars, 100 ventes sont enregistrées (transactions).
• Les clients paient à différentes dates : 80 le 28 mars, 20 par virement le 3 avril.
• Le flux 10.3 transmet les 100 transactions le 31 mars.
• Le flux 10.4 transmet 80 encaissements le 31 mars et 20 encaissements le 5 avril, chacun regroupé par jour et type de paiement.

En résumé : un logiciel d'encaissement doit idéalement séparer la logique transaction/paiement, gérer les périodes distinctes et produire des flux cohérents pour l’administration, même si les données proviennent des mêmes ventes.

Flux rectificatifs et cycle de vie du document sur le PPF

Le e-reporting prévoit la gestion des flux rectificatifs pour corriger les erreurs sur des périodes déjà transmises.

Flux RE :

• Chaque flux RE annule et remplace l’ensemble des données d’une période précédemment transmise, en fonction du type de données et du rôle du déclarant.
• Permet de reconstituer une photo exacte et réglementaire de la période corrigée.

🚨 Contrôles et rejets

Le PPF applique plusieurs contrôles pour valider les flux reçus.

Types de contrôles

• Sémantiques : cohérence métier des données (ex. total HT = somme des lignes)
• Cohérence : respect des règles fiscales et des périodes
• Unicité : absence de doublons sur la même période ou facture
• Structure : conformité XML et format des blocs

Statuts possibles

• 300 : déposée et acceptée
• 301 : rejetée

Motifs fréquents de rejet

• REJ_SEMAN : problème sémantique
• REJ_UNI : problème d’unicité
• REJ_COH : incohérence des données
• REJ_PER : incohérence de période

⚠️ Pourquoi les rejets surviennent souvent

Une mauvaise architecture produit peut provoquer des rejets, même si le flux XML est techniquement correct :

• Mauvaise qualification réglementaire : données mal attribuées au rôle, type ou période
• Agrégation trop tôt : perte de granularité nécessaire pour les corrections
• Absence de versioning : impossibilité de suivre les différentes versions envoyées

Exemple concret avec un logiciel de caisse :
Imaginons un POS qui agrège ses ventes B2C quotidiennement :

• Le 15 mars, un encaissement a été mal rattaché à la journée du 14 mars.
• Le flux 10.4 envoyé le 16 mars serait incorrect.
• Un flux RE est alors émis pour la journée du 14 mars afin de corriger l’agrégation et rétablir la conformité.

En résumé : anticiper les rejets du PPF nécessite une logique produit robuste et un interfaçage exhaustif avec la Plateforme Agréée, capable de qualifier correctement les données, gérer les périodes et versionner les transmissions.

Cas d’usage éditeurs

🛒 POS / solutions d'encaissement

• volumétrie forte
• besoin d’agrégation journalière

🌐 E-commerce

• multi-canaux
• paiements différés
• complexité des dates

🧾 Services (TVA encaissement)

• paiements fractionnés
• acomptes

🌍 International

• devises
• règles fiscales complexes

Le point de vue Iopole sur le e-reporting : Avis, stratégie et conseils

Modèle de données

Doit distinguer :

• transaction
• facture
• paiement
• qualification fiscale
• période
• version

📆 Gestion des périodes

• ouverture / clôture
• recalcul
• rectification
• Nécessite de capturer et exploiter ou transmettre à une PA qui gère l'aggrégation le régime de TVA du client final

Afin de faciliter l’intégration des flux de transmission dans le portail public de facturation (PPF) et leur prise en compte par l’administration fiscale, les plateformes agréées les adressent au portail public de facturation (PPF) dans un délai de 8h à l’issue du dernier jour du délai de dépôt au titre de la période. (Extrait des specifications-externes-v3.1 - www.impots.gouv.fr/specifications-externes-b2b)

🔍 Traçabilité

• source → transmission
• calcul appliqué
• version envoyée

🔧 Corrections

• recalcul complet
• renvoi flux rectificatif

🚀 Approche recommandée pour les éditeurs

Pour produire un e-reporting fiable, un éditeur de logiciel doit structurer sa donnée dès l’origine et s’interfacer correctement avec une Plateforme Agréée. L’objectif : garantir une transmission exhaustive, cohérente et exploitable par l’administration.

✔️ Méthode : Unitaire → agrégation

1. Collecte unitaire : récupérer chaque transaction et encaissement depuis le logiciel (POS, e-commerce, ERP).
2. Qualification réglementaire : identifier le type d’opération, le rôle du déclarant, le régime TVA applicable.
3. Rattachement à la période : déterminer à quelle période fiscale chaque donnée doit être associée.
4. Agrégation au bon moment : consolider les données pour créer les flux conformes (10.1 → 10.4) ou pour un envoi rectificatif, tout en conservant le détail unitaire pour la traçabilité.

Selon la norme AFNOR XP Z12-014 version 1.3 :

Services optionnels des Plateformes Agréées ou des Solutions Compatibles : Proposer des services d’agrégation d’enregistrements unitaires de e-reporting dans les périodes de e-reporting de l’assujetti, pour créer les fichiers de e-reporting (flux 10) attendus par le CdD du PPF Services optionnels des Plateformes Agréées ou des Solutions Compatibles : Proposer des services d’agrégation d’enregistrements unitaires de e-reporting dans les périodes de e-reporting de l’assujetti, pour créer les fichiers de e-reporting (flux 10) attendus par le CdD du PPF.

👍 Avantages de cette approche

• Meilleure traçabilité : chaque flux peut être lié à sa source exacte.
• Correction facilitée : possibilité d’envoyer des flux rectificatifs précis sans reconstruire toute la liasse.
• Moins de rejets PPF : la logique d’agrégation respecte les périodes et les rôles, limitant les erreurs structurelles ou sémantiques.

❌ À éviter

• Logique d’export simpliste qui ignore la qualification réglementaire.
• Confusion entre date de transaction et date d’encaissement.
• Agrégation faite trop tôt ou sans conserver l’historique.
• Absence de mécanisme de flux rectificatif pour corriger les erreurs.

⚠️ Points pratiques

• Vérifier avec la Plateforme Agréée comment seront facturés les différents flux (unitaire ou agrégé).
• Définir clairement la logique d’agrégation avant transmission pour éviter les incohérences.
• L’éditeur doit préparer le système pour tous les scénarios : ventes B2C, paiements différés, multi-canaux, opérations internationales.

En résumé : pour un éditeur, la clé est de collecter finement, qualifier correctement et agréger au bon moment. et de s'aligner avec son partenaire Plateforme Agréée (si le logiciel de facturation n'est pas lui même PA). Cette approche minimise les rejets, facilite les corrections et garantit un e-reporting fiable et exploitable.

---

🧾 Conclusion

Le e-reporting est un chantier produit à part entière de la facturation électronique pour un éditeur de logiciel :

• Intègre logique métier, fiscale et temporelle
• Nécessite de structurer la donnée dès l’origine et de s’interfacer efficacement avec une Plateforme Agréée
• L’objectif n’est pas seulement de générer un XML, mais de construire une chaîne robuste, capable de gérer transactions, paiements, agrégation, rectificatifs et rejets.

Pour un éditeur, réussir le e-reporting, c’est transformer la conformité en processus fiable et maintenable, tout en exploitant les flux via la Plateforme Agréée.

---

❓ FAQ

Le e-reporting est-il obligatoire ?

Oui, pour les opérations hors e-invoicing :

• 2026 : grandes entreprises / ETI
• 2027 : PME / micro

Différence 10.1 vs 10.3 ?

• 10.1 : facture internationale (nominatif)
• 10.3 : B2C (agrégé)

Les paiements sont-ils toujours requis ?

Non, uniquement si TVA à l’encaissement

Pourquoi c’est complexe ?

Parce qu’il faut gérer :

• agrégation
• périodes
• SIREN
• rectificatifs
• contrôles

Un POS doit-il envoyer chaque ticket ?

Non → agrégation journalière

Que faire en cas d’erreur ?

➡️ envoyer un flux rectificatif (RE)

Rejets à anticiper ?

• sémantique
• unicité
• cohérence
• période

---

Contacter nos Experts e-Reporting pour mettre en conformité votre logiciel de facturation / logiciel de caisse :