France · première période e-reporting

Rapprocher le premier dépôt d’e-reporting en France

Rapprochez les données e-reporting de transaction et de paiement, de l’ERP à la plateforme agréée, avant l’échéance de la première période.

Résumé pratique :
  • Ventilez avant de totaliser : un même élément ne compte pas dans deux circuits.
  • Premier geste : faites approuver l’échéancier propre à chaque personne morale.
  • Pas de feu vert quand le sort d’un élément reste indéterminé, même si les chiffres tombent juste.
Dernière vérification : 7 septembre 2026Sources officiellesRésumé clairInformation pratique, pas un conseil juridique
Sources officielles priorisées
Dates de vérification visibles
Checker gratuit, sans inscription

Ce qu’il faut savoir

Guide

1. Qui doit agir maintenant et sur quel périmètre ?

La réforme est entrée en vigueur le 1er septembre 2026, selon l’actualité publiée par Service-Public le 2 septembre. Dès cette date, toutes les entreprises concernées doivent pouvoir recevoir des factures électroniques. Les grandes entreprises et les entreprises de taille intermédiaire (ETI) doivent en outre émettre leurs factures électroniques et transmettre leur e-reporting ; les PME et micro-entreprises entreront dans l’obligation d’émission et d’e-reporting le 1er septembre 2027. Pour une grande entreprise ou une ETI, le travail immédiat consiste donc à sécuriser la première population réellement ouverte depuis le 1er septembre, sans attendre la préparation de la déclaration de TVA. Trois circuits doivent rester distincts. La **facturation électronique** concerne les factures entrant dans le circuit réglementé, notamment le B2B domestique visé par la réforme. L’**e-reporting** porte sur les données de transaction et, lorsque les règles l’exigent, sur les données de paiement transmises par une plateforme agréée (PA). La comptabilité courante et la déclaration de TVA restent, quant à elles, des processus ayant leurs propres règles, périodes, écritures et validations. Un rapprochement utile relie ces univers mais ne les confond pas : une écriture au grand livre ne prouve pas à elle seule qu’une donnée a été extraite, reçue et traitée par la PA. Seule une PA immatriculée peut transmettre à l’administration les données réglementées de facture, de transaction et de paiement. La première question n’est cependant pas « la PA a-t-elle envoyé un fichier ? », mais « avons-nous identifié toutes les opérations attendues, selon le bon SIREN, le bon régime de TVA, la bonne période et la bonne voie de reporting ? ». La population comprend typiquement les ventes B2C à agréger par jour, certaines opérations B2B internationales décrites à un niveau proche de la facture, ainsi que les encaissements applicables lorsque la TVA est exigible à l’encaissement. Elle ne doit pas absorber indistinctement les factures B2B domestiques déjà déposées dans leur circuit propre ni tous les mouvements bancaires. Les fiches DGFiP d’août 2026 détaillent les fréquences et les données ; le guide pratique de démarrage explique comment traiter une difficulté temporaire. Les références au CGI, notamment les articles 290 et 290 A, et aux articles 242 nonies M à P de l’annexe II et 41 septies J à P de l’annexe IV, sont reprises par ces documents officiels. Elles sont citées ici comme repères documentaires, sans interprétation juridique. La méthode ci-dessous ajoute des contrôles internes recommandés — clés de rapprochement, heures de gel, seuils d’escalade et règles de visa — qui ne sont pas des exigences fixées par la DGFiP. **Réponse opérationnelle :** si votre groupe comprend une grande entreprise ou une ETI, identifiez aujourd’hui les SIREN déjà soumis à l’e-reporting, leur régime de TVA et leurs flux depuis le 1er septembre. Au 7 septembre 2026, la première décade n’est pas achevée : il est pertinent de contrôler la collecte et les écarts provisoires, mais pas de présenter la période du 1er au 10 septembre comme complète ni de signer un dépôt final. Ce guide apporte des informations pratiques et ne constitue pas un conseil juridique, fiscal ou comptable.

Guide

2. Choisir le calendrier correspondant au régime de TVA

La fréquence ne se déduit ni de la taille du fichier ni du rythme de clôture du groupe. Elle dépend du régime de TVA indiqué dans la fiche officielle DGFiP « fréquences et délais », mise à jour en août 2026. Le tableau suivant restitue les échéances de cette fiche ; les mentions d’« échéance interne » et de « responsable » sont des contrôles d’organisation recommandés, pas des délais légaux supplémentaires. | Régime de TVA | Données de transaction — fréquence et échéance officielles | Données de paiement — échéance officielle | Responsable et coupure interne recommandés | |---|---|---|---| | Réel normal mensuel | Par décades : jours 1–10, au plus tard le 20 du même mois ; jours 11–20, au plus tard le 30 du même mois, sauf février ; jours 21–fin de mois, au plus tard le 10 du mois suivant | Mensuelles, **avant le 10 du mois suivant** | Fiscalité propriétaire du calendrier ; extraction figée deux à trois jours ouvrés avant l’échéance, après accord de la comptabilité et de l’équipe chargée des données | | Réel normal avec option trimestrielle parce que la TVA annuelle payée est inférieure à 4 000 € | Mensuelles, **avant le 10 du mois suivant** | Mensuelles, **avant le 10 du mois suivant** | Fiscalité confirme l’option par SIREN ; coupure après la fin du mois et avant la fenêtre de transmission convenue | | Régime simplifié de TVA | Mensuelles, au plus tard à une date comprise entre le 25 et le 30 du mois suivant | Même fréquence et même fenêtre | Responsable TVA documente la date exacte applicable ; l’équipe informatique conserve la version extraite et les preuves de remise | | Franchise en base de TVA | Bimestrielles, par périodes calendaires, au plus tard à une date comprise entre le 25 et le 30 du mois suivant la fin de la période | Même fréquence et même fenêtre | Propriétaire métier confirme le périmètre malgré l’absence de TVA collectée ; gel après clôture de la période bimestrielle | Pour une entreprise au réel normal mensuel, la période du **1er au 10 septembre 2026** est la première décade de données de transaction. La fiche donne le **20 septembre 2026** comme échéance. Ce constat ne transforme pas le 7 septembre en date de clôture : les ventes des 8, 9 et 10 septembre ne sont pas encore connues. L’équipe peut vérifier les sept premiers jours, corriger une règle de correspondance et tester les accusés, mais elle doit garder la période ouverte jusqu’à sa fin. La fiche signale une exception pour la deuxième décade de février. Elle ne justifie pas d’inventer ici une date de remplacement. De même, lorsqu’une date tombe un jour non ouvré, ce guide ne décale pas automatiquement l’échéance : vérifiez la fiche officielle alors en vigueur et les consignes applicables au calendrier concerné. Cette vérification doit apparaître dans le dossier de période avec sa date et son auteur. Un calendrier exploitable contient quatre horodatages : fin de la période officielle, gel interne de l’extraction, remise à la PA, puis obtention et revue du résultat. Par exemple, une entreprise pourrait recommander en interne un gel le 17 septembre à 09 h 00 pour viser l’échéance officielle du 20 septembre, à condition de prévoir une extraction différentielle des écritures tardives et de documenter ce choix. Ce gel est une règle interne de prudence, pas une date DGFiP. Le responsable fiscal possède l’interprétation du périmètre ; la finance valide les totaux ; l’équipe chargée des données prouve la traçabilité ; l’opérateur PA suit les retours. Un suppléant et une heure d’escalade évitent qu’une absence bloque le visa. **Point de contrôle calendrier :** conservez, pour chaque SIREN, une ligne versionnée indiquant régime, fréquence, période, échéance officielle, source officielle consultée, coupure interne, propriétaire et suppléant. Un groupe multi-entités ne doit jamais appliquer le calendrier de la société mère à toutes ses filiales par défaut.

Guide

3. Figer une population reproductible par SIREN, période et voie

Le rapprochement commence par un manifeste de périmètre, pas par un total comptable. Attribuez un identifiant de contrôle à la combinaison **SIREN + période officielle + voie de reporting + version d’extraction**. Ajoutez l’horodatage de gel, le système source, la règle de sélection, le fuseau utilisé pour la date de vente ou d’encaissement et le responsable. Cette clé permet de reproduire la population sans écraser la version précédemment remise à la PA. Séparez au minimum quatre voies. Premièrement, le B2B domestique relevant de la facturation électronique : il sert de frontière et de contrôle d’exclusion, car il ne faut pas le recopier mécaniquement dans la population de transactions hors facture. Deuxièmement, les opérations B2C avec des personnes non assujetties : la fiche DGFiP d’août 2026 prévoit une agrégation quotidienne ; les contrôles attendus s’organisent par jour, catégorie prévue et taux de TVA, avec base imposable hors taxe et TVA correspondante. Troisièmement, le B2B international : les données sont largement au niveau de la facture et peuvent inclure, selon le cas, identifiants, pays, catégorie biens ou services, date d’émission, numéro unique, montants imposables et TVA par taux, totaux et devise. Certains détails de ligne, remises ou frais ne prennent effet qu’au 1er septembre 2027 ; il serait donc erroné d’imposer dès maintenant une liste universelle à tous les cas. Quatrièmement, les données de paiement applicables, isolées selon les règles décrites plus loin. Le manifeste doit expliciter les exclusions : écritures d’ouverture, simulations, journaux de test, transferts internes hors population, mouvements bancaires sans opération reportable, opérations en autoliquidation pour la voie paiement, prestations sous option pour les débits, et toute transaction déjà classée dans une autre voie. Une exclusion n’est acceptable que si elle porte un code de motif, la règle qui l’a produite et un échantillon vérifiable. Un filtre silencieux dans le connecteur est une faiblesse de contrôle, même si le total paraît plausible. Pour rendre le gel reproductible, archivez les paramètres de requête, les plages de dates, la table de correspondance fiscale, la version du code ou du paramétrage, le nombre d’enregistrements source et l’empreinte ou l’identifiant du lot lorsque l’outil le permet. Ne supposez pas un format de fichier imposé : exigez seulement une exportation lisible et stable de la population et de sa transformation. Si des ventes arrivent après le gel, placez-les dans une file « tardives » rattachée à la période exacte ; ne les glissez pas dans la période suivante pour équilibrer artificiellement la journée. **Test de frontière à deux sens :** partez d’un échantillon ERP, caisse ou facturation et vérifiez sa destination : facture électronique domestique, agrégat B2C, flux B2B international, paiement applicable ou exclusion justifiée. Puis partez de chaque ligne ou objet remis à la PA et retrouvez son opération source. Le premier sens repère les omissions ; le second détecte les doublons, les éléments inventés par transformation et les rattachements au mauvais SIREN. Enfin, versionnez toute correction. La version V1 doit rester consultable avec ses totaux, ses erreurs et son accusé ; V2 doit indiquer quelles lignes ont été ajoutées, annulées ou remplacées et pourquoi. Une simple mention « fichier corrigé » ne suffit pas pour reconstituer la première période ni pour éviter qu’un opérateur rejoue le lot initial.

Guide

4. Construire la chaîne de preuve des sources jusqu’aux accusés

Une chaîne de preuve complète relie cinq frontières : **ERP, facturation ou caisse**, puis **banque ou trésorerie lorsque le paiement est dans le champ**, ensuite **extraction et transformation**, **réception par la PA**, enfin **résultat ou accusé et file de correction**. Le grand livre, le compte de TVA et les journaux de vente sont des contrôles importants, mais ils ne remplacent pas la preuve technique du passage d’une frontière à l’autre. Utilisez une matrice par clé de contrôle. Les colonnes « base imposable » et « TVA/valeur de paiement » ne s’appliquent pas uniformément à toutes les voies ; indiquez « sans objet » plutôt que de fabriquer une équivalence. Les limites ci-dessous sont des preuves recommandées, non une méthode de rapprochement prescrite par la DGFiP. | Clé de contrôle | Nombre | Base imposable HT | TVA ou valeur de paiement | Frontière de preuve attendue | |---|---:|---:|---:|---| | SIREN–période–B2C–jour–catégorie–taux | Tickets source et agrégats produits | Somme quotidienne HT | TVA quotidienne correspondante | Export caisse → règle d’agrégation → objet reçu par la PA → résultat | | SIREN–période–B2B international–document | Factures et avoirs uniques | Montant imposable par taux, puis total net | TVA par taux lorsqu’elle s’applique | Facturation/ERP → transformation document → trace PA → accusé ou rejet | | SIREN–mois–paiement–date réelle–taux | Encaissements reportables, pas mouvements bancaires bruts | N/A si la donnée contrôlée est le paiement | Montant réellement encaissé en euros par taux | Banque/trésorerie + affectation fiscale → enrichissement Encaissée ou flux applicable → résultat | | SIREN–période–lot–version | Objets envoyés, acceptés, rejetés, sans résultat et corrigés | Totaux des voies concernées | Totaux des voies concernées | Identifiant d’extraction → identifiant de remise/trace → export des résultats → journal de correction | À chaque frontière, capturez le nombre et les totaux avant et après. Une variation peut être légitime — par exemple plusieurs ventes B2C deviennent un agrégat journalier — mais la règle doit expliquer la réduction du nombre sans perdre la base ni la TVA par jour et par taux. Pour un B2B international au niveau facture, une diminution inattendue du nombre demande une explication document par document. Pour un encaissement partagé entre plusieurs factures, le montant bancaire peut rester unique alors que l’affectation produit plusieurs liens : contrôlez à la fois la somme et la cardinalité. La preuve d’accusé doit être exportable et rattachable au lot ou aux objets concernés. N’imposez pas un nom de statut universel : chaque PA peut présenter ses résultats différemment, et le cadre ne justifie pas d’inventer un code technique commun. Demandez plutôt la signification documentée de chaque état, son horodatage, son niveau — lot, agrégat, facture ou donnée — et la possibilité de distinguer reçu, accepté, rejeté, corrigé et encore sans résultat lorsqu’ils existent dans le service choisi. Le grand livre apporte un contrôle indépendant. Comparez les journaux de vente et comptes de TVA à la population fiscale après avoir expliqué les différences de date, de périmètre et d’agrégation. Un écart entre la caisse et le grand livre peut provenir d’une interface comptable tardive ; un écart entre l’ERP et la PA peut venir d’un filtre du connecteur ; une absence d’accusé peut être un problème de transport ou de visibilité. Ces causes n’appellent pas la même correction. Le dossier de preuve minimal conserve le manifeste, les exports source, les totaux par clé, la version de transformation, la remise PA, les résultats, les tickets d’incident et la décision finale. Aucune durée de conservation n’est inventée ici : appliquez les règles juridiques, fiscales, comptables et internes confirmées pour votre organisation.

Guide

5. Rapprocher les données de transaction sans se laisser tromper par le total général

Pour le **B2C**, rapprochez d’abord les ventes de caisse ou de facturation au niveau le plus fin disponible, puis reconstruisez l’agrégat attendu par **date civile, catégorie prévue et taux de TVA**. La fiche DGFiP d’août 2026 attend notamment, pour chaque catégorie listée et chaque taux, la base imposable quotidienne hors taxe et la TVA correspondante. Le nombre de tickets est un contrôle interne utile, mais il ne remplace pas les montants réglementaires. Vérifiez aussi les annulations, retours, avoirs, ventes hors taxe et corrections de caisse : ils doivent suivre une règle stable et ne pas être neutralisés hors de leur journée sans justification. Le rapprochement est bidirectionnel. Du système de caisse vers l’extraction, chaque ticket admissible doit contribuer exactement une fois à la bonne cellule jour–catégorie–taux. De l’extraction vers la caisse, chaque agrégat doit se décomposer en opérations existantes. Contrôlez les cellules à zéro, les journées manquantes et les jours où l’activité est atypiquement faible. Une journée sans vente peut être réelle ; elle doit être distinguée d’une interface restée arrêtée. Pour le **B2B international**, privilégiez un contrôle document par document : numéro unique, date d’émission, pays et identifiants applicables, nature biens ou services, devise, montant imposable et TVA par taux lorsque ces données sont requises. Incluez les avoirs et corrections avec leur relation au document d’origine lorsque le système la fournit. Évitez d’exiger indistinctement tous les champs détaillés à toutes les opérations : la fiche prévoit des champs conditionnels et une montée en charge de certains détails au 1er septembre 2027. La devise exige deux vues. Conservez le montant et la devise du document, puis la valeur utilisée pour les contrôles en euros avec la source du taux, sa date et la règle d’arrondi validée par la fiscalité. Ne compensez pas un écart de conversion par une écriture manuelle non traçable dans l’extraction. Les écarts d’arrondi doivent être observables par document ou par cellule, puis expliqués selon une règle interne ; ce guide ne fixe ni tolérance ni seuil de matérialité officiel. Comparez les bases et la TVA par taux, catégorie, jour ou document avant de regarder le grand total. Deux erreurs opposées peuvent produire zéro écart global : l’omission d’une facture de 5 000 € et d’un avoir de –5 000 € laisse la base nette inchangée tout en rendant la population incomplète. De même, 1 000 € classés à 20 % au lieu de 10 % peuvent être masqués par une erreur inverse de même base. Les clés, nombres et distributions par taux sont donc aussi importants que le total. Lorsque l’ERP, le journal de ventes et le compte de TVA ne coïncident pas, classez l’écart avant correction : décalage de comptabilisation, mauvaise entité, mauvais taux, transaction tardive, duplicata, avoir absent, devise, ou erreur de paramétrage fiscal. La fiscalité décide de la classification ; l’équipe chargée des données démontre la transformation ; la comptabilité confirme le lien avec les écritures. Ne forcez pas le connecteur à « faire correspondre » un total comptable si la population fiscale correcte suit une autre frontière temporelle. **Critères de sortie de la voie transaction :** population source et PA rapprochées dans les deux sens, écarts par taux expliqués, avoirs et corrections reliés, devise reproductible, résultats PA attachés et anomalies ouvertes attribuées. Si une différence reste inconnue, le visa doit indiquer un blocage ou une réserve selon une règle interne préalablement approuvée, jamais selon une tolérance présentée comme officielle.

Guide

6. Rapprocher uniquement les paiements effectivement reportables

Les données de paiement ne couvrent pas tous les crédits bancaires. La fiche DGFiP d’août 2026 les limite aux opérations pour lesquelles la TVA est exigible à l’encaissement, par exemple certaines prestations de services et certains acomptes sur biens. Les opérations en autoliquidation sont exclues de ce flux de paiement, tout comme les opérations relevant de l’option pour le paiement de la TVA d’après les débits. La qualification fiscale précède donc le rapprochement technique. Pour chaque encaissement admissible, contrôlez la **date réelle de perception** et le **montant encaissé en euros par taux de TVA**. La date de facture, la date d’échéance client, la date de saisie comptable ou une date de valeur bancaire ne doivent pas remplacer automatiquement la date réelle. Lorsque le relevé bancaire ne suffit pas à l’établir, documentez la source retenue et faites valider la règle par la fonction fiscale ou comptable compétente. Les paiements partiels demandent une allocation explicite : une facture de 12 000 € réglée à hauteur de 4 000 € ne doit pas apparaître comme totalement encaissée. À l’inverse, un virement de 15 000 € couvrant trois factures doit conserver une preuve du mouvement unique et de ses trois affectations, sans tripler le montant. Les remboursements, rétrofacturations, trop-perçus et encaissements non affectés passent dans une file de qualification ; ils ne sont ni supprimés pour équilibrer le lot ni déclarés automatiquement comme des ventes. Le mode de transmission dépend du contexte. Lorsqu’un paiement concerne une facture électronique B2B domestique déposée auprès d’une PA, la fiche indique un enrichissement du statut **« Encaissée »**. Pour une opération B2B internationale sans facture électronique déposée, les données de paiement sont transmises facture par facture dans un flux global. Pour le B2C, elles sont agrégées par jour d’encaissement. Ces trois chemins ne doivent pas être mélangés dans un seul compteur, même si le montant bancaire total est commun. Construisez deux contrôles séparés. Le **contrôle fiscal** répond à « cette opération relève-t-elle de la TVA à l’encaissement, à quel taux et à quelle date ? ». Le **contrôle de correspondance** répond à « quel mouvement règle quelle facture, quel agrégat ou quel statut, et quelle trace PA en apporte la preuve ? ». Une correspondance bancaire parfaite peut être fiscalement fausse si une opération sous option pour les débits est incluse. Une qualification fiscale correcte peut rester techniquement non prouvée si le connecteur ne restitue pas les liens d’affectation. Les rapprochements utiles comprennent : somme des encaissements admissibles par date et taux ; somme des enrichissements Encaissée ; somme des paiements internationaux facture par facture ; agrégats B2C quotidiens ; remboursements et espèces non affectées en suspens ; résultats PA reçus. Conservez le nombre d’événements source, le nombre d’objets de reporting et le montant, car un paiement ventilé peut modifier les nombres sans modifier la valeur. **Erreurs à éviter :** aspirer tout le journal de banque, prendre la date de lettrage comme date réelle sans analyse, déclarer deux fois le même encaissement via Encaissée et un flux séparé, ignorer un paiement partiel, ou forcer une allocation incertaine pour fermer la période. Aucune règle interne de correspondance ne doit être présentée comme une position DGFiP ; les cas fiscaux ambigus nécessitent une validation professionnelle adaptée.

Guide

7. Traiter les absences, rejets, erreurs, doublons et résultats inconnus

Le guide pratique DGFiP de démarrage indique qu’une difficulté temporaire d’e-reporting ne doit pas arrêter l’activité économique. Il faut toutefois distinguer deux situations : les données existent correctement mais ne peuvent pas être transmises, ou les données ne sont pas produites correctement. Dans le premier cas, préservez le lot, les horodatages et l’incident avant de retransmettre lorsque le canal est rétabli. Dans le second, corrigez la source ou la transformation avant tout envoi ; le guide recommande d’éviter de transmettre des données manifestement erronées. Appliquez cet arbre de décision borné : 1. **Résultat présent et accepté selon la documentation de la PA :** rattachez la preuve à la version et rapprochez les nombres et montants ; ne rejouez rien. 2. **Rejet explicite :** exportez la règle ou le motif au niveau disponible, identifiez les objets touchés, corrigez uniquement la cause prouvée, puis créez une nouvelle version liée à l’ancienne. 3. **Donnée absente de la PA mais présente dans la population source :** vérifiez le filtre et la transformation ; si l’omission est confirmée, préparez une correction ciblée sur la période et les opérations exactes. 4. **Donnée erronée déjà transmise :** distinguez la correction ou annulation permise par le dispositif de la simple retransmission ; conservez avant/après, justification et résultat. 5. **Doublon confirmé :** bloquez tout rejeu du lot complet, identifiez l’identifiant d’origine et traitez le doublon selon les capacités documentées de la PA. 6. **Aucun résultat ou état incompris :** classez « inconnu », conservez la preuve de remise, demandez l’interprétation à la PA et empêchez qu’un dépassement du délai d’attente déclenche automatiquement une seconde transmission. Pour une régularisation, le guide officiel invite à identifier précisément la période, les opérations, les clients, les montants, la TVA et les données de paiement concernés. Votre journal doit distinguer **absent** de **faux** : ajouter une ligne manquante n’a pas le même effet qu’annuler puis remplacer une ligne inexacte. La correction doit aussi être rapprochée des factures, encaissements et écritures comptables afin d’éviter une seconde divergence. La file de correction devrait contenir : SIREN, période, voie, version, objet source, résultat PA, type d’anomalie, propriétaire, décision, action, nouvelle trace et état de rapprochement. Une protection anti-doublon fondée sur une clé métier et une trace technique est préférable à un bouton « renvoyer tout ». Testez son comportement sur un lot déjà reçu et sur un lot dont le résultat est retardé. **Mauvaises pratiques :** soumettre en masse toutes les périodes après une panne, effacer le lot rejeté, changer un montant directement dans le portail sans répercussion contrôlée dans la source, inventer une nouvelle échéance, ou considérer l’absence d’accusé comme une acceptation. Le guide de démarrage ne promet ni immunité contre les pénalités, ni délai de grâce, ni régime de protection juridique. Il fournit une conduite prudente : préserver les données et les preuves d’incident, corriger ou transmettre de manière maîtrisée et conserver la trace de régularisation. La sortie de crise n’est acquise que lorsque la population régularisée retrouve ses factures, recettes, encaissements et écritures, et que le résultat PA est attaché. S’il reste un état inconnu, le signataire doit voir clairement ce qui manque, l’impact potentiel et le propriétaire ; un vert technique générique ne suffit pas.

Guide

8. Évaluer l’ERP, le connecteur et la PA, puis constituer le dossier de visa

Une démonstration commerciale doit reproduire une période et ses défauts, pas seulement afficher un tableau de bord. Demandez au fournisseur de charger un petit jeu représentatif — agrégats B2C multi-taux, facture et avoir B2B international, paiement partiel et résultat retardé — puis exigez les exports qui permettraient à une autre personne de refaire le contrôle. Les questions suivantes peuvent alimenter un appel d’offres ou une recette : 1. Peut-on extraire la population complète par SIREN, période, voie et régime de TVA, y compris les exclusions avec leur motif ? 2. Le produit verrouille-t-il une version de période tout en conservant une extraction différentielle pour les opérations tardives ? 3. Chaque transformation expose-t-elle sa version de règle, son horodatage et ses totaux avant/après ? 4. Une opération source peut-elle être suivie jusqu’à un identifiant de remise ou de trace PA, puis jusqu’au résultat correspondant ? 5. Les rejets sont-ils exportables au niveau de la règle et de l’objet, plutôt que seulement sous forme d’un compteur global ? 6. Comment une correction distingue-t-elle ajout, annulation, remplacement et rejeu, avec un lien vers la version initiale ? 7. Quelle protection empêche un doublon lorsque l’accusé est retardé ou qu’un opérateur relance un lot ? 8. Peut-on exporter les accusés, états, motifs, horodatages et définitions d’état sans capture d’écran manuelle ? 9. Le système rapproche-t-il séparément nombres, bases HT, TVA par taux et valeurs de paiement avec l’ERP, la caisse, le grand livre et le compte de TVA ? 10. Les paiements montrent-ils la date réelle, le taux, l’affectation, les paiements partiels et le chemin Encaissée, international ou agrégé B2C ? 11. Quels rôles peuvent préparer, corriger, transmettre, approuver et exporter les preuves, et les actions sont-elles tracées ? 12. Qui possède chaque preuve en cas d’incident : entreprise, intégrateur, éditeur ERP ou PA, et comment l’entreprise la récupère-t-elle si le contrat change ? Évaluez les réponses sur des preuves observées : export réellement obtenu, traçabilité démontrée, anomalie reproduite et reprise sans doublon. Ne classez pas les solutions sur une promesse de « conformité totale ». Une capacité peut être présente dans l’ERP mais perdue dans le connecteur ; la PA peut recevoir le lot sans restituer un résultat assez fin pour le rapprochement. Le contrat, la matrice de responsabilités et la recette doivent couvrir la chaîne entière. Le **dossier de visa de première période** devrait réunir : fiche calendrier datée ; manifeste de périmètre et exclusions ; exports source et PA ; matrice des nombres, bases, TVA et paiements ; preuves de conversion de devise ; résultats et accusés ; registre des rejets, inconnus et corrections ; rapprochement avec le grand livre et le compte de TVA ; décision sur les anomalies résiduelles ; approbations des équipes fiscales, financières et chargées des données. Les heures de gel, seuils d’escalade et signatures sont définis par l’entreprise. Ils doivent être visibles comme contrôles internes, et non attribués à la DGFiP. Avant le visa, posez trois questions : la population est-elle exhaustive dans les deux sens ? Chaque transformation et chaque correction est-elle reproductible ? Tout objet remis possède-t-il un résultat compris ou une anomalie ouverte avec propriétaire ? Si la réponse est non, le dossier doit indiquer « en attente » ou une réserve formalisée selon la gouvernance interne, plutôt que masquer le point par un total général. Une revue indépendante de préparation peut transformer ces exigences en rapport d’écarts, scénario de démonstration et critères de présélection. Elle est particulièrement utile lorsque l’ERP, le connecteur et la PA se partagent les responsabilités ou lorsque les exports ne suffisent pas à reconstituer la piste d’audit. Le résultat attendu n’est pas une recommandation automatique de fournisseur, mais une liste courte de solutions qui ont prouvé, sur vos cas, la complétude, les contrôles et la propriété des preuves.

Guide

9. Exemple fictif multi-entités : écarts, corrections et décisions de visa

L’exemple suivant est entièrement fictif. Les heures de coupure et règles de blocage sont des contrôles internes recommandés pour illustrer la méthode ; elles ne viennent pas de la DGFiP. Le groupe **Orion** comprend deux SIREN. *Orion Distribution SA*, grande entreprise au réel normal mensuel, est soumise depuis le 1er septembre 2026. Sa première décade de transactions va du 1er au 10 septembre, avec l’échéance officielle du 20 septembre. *Orion Services SAS*, ETI ayant valablement opté pour le réel normal trimestriel en raison d’une TVA annuelle payée inférieure à 4 000 €, transmet transactions et paiements mensuellement avant le 10 du mois suivant. Au 7 septembre, les deux populations restent ouvertes. Le scénario suppose donc une répétition de contrôle exécutée après les dates de fin : gel interne fictif de Distribution le 11 septembre à 08 h 00 et gel mensuel fictif de Services le 2 octobre à 09 h 00. **Population attendue de Distribution, 1er–10 septembre.** La caisse contient 1 240 tickets. Après classement, elle produit 20 cellules B2C : dix agrégats quotidiens « biens à 20 % » pour 120 000 € de base HT et 24 000 € de TVA, plus dix agrégats « catégorie à 10 % » pour 30 000 € HT et 3 000 € de TVA. Total B2C attendu : 20 agrégats, 150 000 € HT, 27 000 € de TVA. Le registre B2B international contient 14 documents uniques, factures et avoirs compris, pour une base nette de 74 500 € et 1 900 € de TVA applicable selon les cas documentés. Le total de contrôle transaction est donc 34 objets attendus, 224 500 € de base nette et 28 900 € de TVA, tout en conservant les deux voies séparées. La V1 reçue par la PA présente 19 agrégats B2C, 149 200 € HT et 26 840 € de TVA. **Écart 1 :** l’agrégat « biens 20 % » du 6 septembre manque, soit 800 € HT et 160 € de TVA. Le journal technique montre qu’une caisse a repris sa connexion après l’heure d’extraction. Décision : ajouter uniquement cette cellule dans V2, reliée aux tickets et à l’incident ; ne pas rejouer les dix jours. Le B2B international V1 affiche 12 documents, mais exactement 74 500 € de base et 1 900 € de TVA. **Écarts 2 et 3 :** une facture de 5 000 € hors TVA applicable et un avoir de –5 000 € de même traitement ont tous deux été filtrés parce que le code pays avait été vidé lors d’une fusion de référentiels. Les totaux nets étaient donc parfaitement égaux malgré deux omissions. Décision : restaurer le pays et les identifiants applicables dans l’ERP, produire deux objets ciblés en V2 et conserver la preuve que ni l’un ni l’autre n’était déjà présent. **Écart 4 :** une facture en dollars apparaît avec une base de contrôle de 9 180 € dans l’extraction alors que la règle de conversion validée donne 9 120 €. La cause est l’emploi du taux de la date d’import plutôt que du taux associé à la date d’émission selon la politique fiscale interne. Décision : corriger la règle versionnée, remplacer l’objet concerné et recalculer le total B2B. Cet exemple ne crée pas de règle officielle de change : Orion fait valider sa propre méthode par sa fiscalité. Après corrections, la V2 B2B comporte toujours 14 documents mais son total final est ramené à 74 440 € HT et 1 900 € de TVA, car la différence de conversion de 60 € était incluse dans le chiffre initial. Le contrôle transaction final de Distribution devient donc **34 objets, 224 440 € HT et 28 900 € de TVA**. Les exports V1 et V2, les trois transformations ciblées et les résultats PA sont joints. Selon la règle fictive d’Orion, tout document absent bloque le visa ; après réception des résultats compris pour V2, le responsable fiscal signe la décade le 18 septembre. Si le 20 septembre est non ouvré, l’équipe vérifie séparément le traitement officiel au lieu de supposer un report. **Population paiement de Services, septembre complet.** Après qualification fiscale, Orion attend 18 événements ou objets de contrôle pour **46 200 € encaissés** : onze encaissements liés à des factures électroniques B2B domestiques, totalisant 31 000 €, à suivre par enrichissement Encaissée ; quatre paiements de prestations B2B internationales transmis facture par facture, totalisant 10 000 € ; trois agrégats B2C par jour d’encaissement, totalisant 5 200 €. Les comptes bancaires comportent beaucoup plus de mouvements, mais les virements internes, prêts, paiements relevant de l’option pour les débits et opérations en autoliquidation ne sont pas inclus dans cette population. La première extraction contient aussi 18 éléments, pour 47 400 €. **Écart 5 :** un encaissement partiel de 2 400 € reçu le 29 septembre manque, car le connecteur a retenu la date de valeur du 1er octobre. Décision : rétablir la date réelle de réception et rattacher le paiement partiel à la facture sans déclarer son solde non payé. **Écart 6 :** un règlement de 3 600 € lié à une opération en autoliquidation a été inclus par une règle bancaire trop large. Décision : l’exclure avec motif fiscal validé. Le calcul 47 400 € + 2 400 € – 3 600 € retrouve les 46 200 € attendus. **Écart 7 :** un virement de 6 000 € réglant deux factures totalise correctement 6 000 €, mais l’export PA ne montre qu’un seul lien d’affectation. Il ne s’agit pas d’un écart de valeur ; c’est une rupture de preuve due à un modèle de connecteur limité à une relation un-à-un. Décision : ne pas renvoyer le paiement ; corriger l’export de correspondance et obtenir une trace montrant les deux affectations sans doubler la valeur. Le contrôle final de Services indique **18 éléments de reporting, 46 200 €**, répartis entre 31 000 € Encaissée, 10 000 € B2B international et 5 200 € B2C quotidien. Toutefois, la décision au 7 septembre reste « période ouverte — aucun visa final ». Dans le scénario d’octobre, le visa mensuel demeure en attente tant que la preuve des deux affectations n’est pas exportable ; il est signé seulement après correction de cette trace et compréhension des résultats PA. Le groupe ne compense jamais ce défaut par le bon total bancaire. Cet exemple montre quatre leçons : les nombres détectent ce que les montants nets cachent ; une date technique ne remplace pas la date réelle d’encaissement ; une exclusion fiscale exige un motif ; et un accusé ou une trace incompréhensible empêche un visa probant, même lorsque base, TVA et paiement s’équilibrent.

Checklist

Confirmer, pour chaque SIREN, la taille d’entreprise, le régime de TVA, la fréquence et l’échéance officielle applicables.

Créer une clé versionnée par SIREN, période, voie de reporting et extraction, avec heure de gel et propriétaire.

Séparer le B2B domestique en facturation électronique, les agrégats B2C, le B2B international et les paiements applicables.

Exporter les exclusions et leurs motifs afin de détecter les filtres silencieux du connecteur.

Rapprocher dans les deux sens les nombres, bases HT et TVA par jour, catégorie, taux ou document.

Qualifier fiscalement les encaissements avant de les rapprocher à la banque, aux factures et aux traces PA.

Conserver les versions de transformation, les identifiants de remise, les résultats, les rejets et les états inconnus.

Corriger uniquement les objets prouvés, avec avant/après, motif et protection contre les doublons.

Comparer les populations finales au grand livre et au compte de TVA en expliquant les différences de période et de périmètre.

Faire viser le dossier par les responsables des équipes fiscales, financières et chargées des données, ou documenter clairement le blocage restant.

Questions fréquentes

Quelle différence entre e-reporting et facturation électronique ?

La facturation électronique organise l’émission, la réception et la transmission des factures entrant dans son champ, notamment le B2B domestique concerné. L’e-reporting transmet via une PA des données sur d’autres opérations, notamment certaines transactions B2C ou internationales et, lorsqu’elles sont applicables, des données de paiement. La comptabilité et la déclaration de TVA restent des sources et contrôles distincts : leur total ne constitue pas un accusé PA.

Qui doit agir pour l’e-reporting en septembre 2026 ?

Depuis le 1er septembre 2026, les grandes entreprises et les ETI concernées commencent l’émission de factures électroniques et l’e-reporting. Toutes les entreprises affectées doivent être capables de recevoir des factures électroniques dès cette date. Les PME et micro-entreprises suivent au 1er septembre 2027 pour l’émission et l’e-reporting ; il faut néanmoins confirmer la situation de chaque SIREN et son régime de TVA.

Quelle est la première échéance de septembre pour une entreprise au réel normal mensuel ?

La première période de données de transaction couvre les 1er au 10 septembre 2026 et la fiche DGFiP d’août 2026 donne le 20 septembre comme échéance. Au 7 septembre, cette décade n’est pas complète et ne doit pas être signée comme finale. L’entreprise doit aussi vérifier la fiche en vigueur et le traitement applicable si une date tombe un jour non ouvré, sans inventer elle-même un report.

Quels totaux et quelles preuves faut-il rapprocher ?

Contrôlez les nombres, bases HT et TVA par taux, jour, catégorie ou document pour les transactions, ainsi que la valeur des paiements admissibles en euros par date et taux. Reliez les exports ERP, facturation ou caisse, le grand livre et le compte de TVA, la transformation, la remise PA, les résultats et la file de correction. Conservez les différences de périmètre expliquées plutôt que de forcer l’égalité d’un seul total général.

Les ventes B2C sont-elles transmises chaque jour ou vente par vente ?

La fiche DGFiP d’août 2026 prévoit une agrégation par jour pour les transactions avec des personnes non assujetties, avec notamment la base imposable hors taxe et la TVA correspondante par catégorie listée et taux. Garder le détail des tickets reste utile comme preuve interne permettant de recomposer chaque agrégat. Cela ne signifie pas que toutes les autres voies, comme le B2B international, sont agrégées de la même manière.

Quels encaissements faut-il inclure dans les données de paiement ?

Uniquement les opérations pour lesquelles la TVA est exigible à l’encaissement, par exemple certaines prestations de services et certains acomptes sur biens, selon leur qualification. Les opérations en autoliquidation et celles sous option pour les débits sont exclues de ce flux. Contrôlez la date réelle de réception, le montant en euros par taux, les paiements partiels et le bon chemin — Encaissée, B2B international facture par facture ou agrégat B2C quotidien.

Que faire si une donnée manque, est rejetée ou reste sans résultat PA ?

Distinguez une donnée correcte impossible à transmettre d’une donnée mal produite. Préservez le lot et l’incident, corrigez la cause prouvée, créez une version ciblée et évitez tout rejeu massif ; un état inconnu doit rester ouvert jusqu’à ce que sa signification soit confirmée. L’absence d’accusé ne vaut pas acceptation, et le guide de démarrage DGFiP ne promet ni délai de grâce ni protection automatique contre les pénalités.

Quelles capacités de l’ERP, du connecteur et de la PA sont décisives ?

Exigez une extraction exhaustive par SIREN, période et voie, un verrouillage versionné, une traçabilité source-à-résultat, des rejets au niveau de la règle, des corrections liées à l’original, une protection anti-doublon et des accusés exportables. Vérifiez aussi le rapprochement au grand livre, les rôles et droits, ainsi que la propriété des preuves entre l’entreprise, l’intégrateur et la PA. Une démonstration avec anomalies réelles est plus probante qu’une promesse générale de conformité.

Réglementation, formats et termes clés

Francefacturation électroniqueadministration fiscale françaiseimpots.gouv.frplateforme agrééeFactur-XUBLCIISIRENTVAe-reportingPMEmicro-entrepriselogiciel comptableCommission européenneEN 16931Directive 2014/55/UEfacture électronique structuréeRapprochement de la première période d’e-reporting en France

France — Hub pays

À lire aussi

Sources officielles

Nous privilégions les sources gouvernementales et européennes officielles lorsque disponibles, avec des dates de vérification visibles.