E-reporting ERP : cadrer transactions et paiements

Trois volets, trois natures de données

La DGFiP présente la réforme en trois volets. Le premier est la facturation électronique entre assujettis à la TVA établis en France. Le deuxième est la transmission des données de transaction (e-reporting de transactions), qui couvre les ventes à des non-assujettis, par exemple des particuliers, et les opérations avec des clients établis dans l’Union européenne ou hors de l’Union. Le troisième est la transmission des données de paiement, qui ne concerne que les opérations dont la TVA est exigible à l’encaissement, comme les prestations de services et les acomptes, quelle que soit la nature du client.

Le calendrier du e-reporting est celui de l’émission : 1er septembre 2026 pour les grandes entreprises et les ETI, 1er septembre 2027 pour les PME, TPE et microentreprises. Le e-reporting de transactions exclut notamment les importations, les opérations exonérées dispensées de facturation (articles 261 à 261 E du CGI) et certains contrats de défense couverts par une clause de confidentialité.

Quelles données l’ERP doit fournir

Pour les ventes aux particuliers, la plateforme transmet, par période, le cumul de chaque journée : bases hors taxe par taux de TVA et montants de TVA. Pour le B2B international, les données sont celles d’une facture électronique, à ceci près que le numéro de TVA intracommunautaire ou un numéro étranger remplace le SIREN du client non établi en France. Pour les paiements, l’ERP doit fournir la date d’encaissement, le montant encaissé réparti par taux de TVA et, lorsqu’il existe, le numéro de facture.

Les périodicités et les délais de transmission sont fixés par les textes d’application, aux annexes II et IV du CGI, selon le régime d’imposition de l’entreprise. Le guide pratique de démarrage de la DGFiP cite notamment les articles 242 nonies M à 242 nonies P de l’annexe II et 41 septies I à P de l’annexe IV. Faites citer par le prestataire la version qu’il applique.

Repérer les sources de données

Les données viennent de l’ERP, mais aussi d’une caisse, d’un site de vente en ligne ou d’un outil d’encaissement. Inventoriez chaque source et son responsable, puis les événements qui créent ou corrigent la donnée : une facture et son règlement sont parfois enregistrés dans deux applications. Le rapprochement entre les deux doit être étudié avant de promettre un flux automatique.

Un état « payé » dans l’ERP ne suffit pas à établir une date d’encaissement : il peut résulter d’un rapprochement bancaire, d’une saisie ou d’un traitement interne. Comprenez d’où vient la valeur avant de la transmettre.

Qualifier les opérations avant de construire le flux

Ne classez pas toutes les factures étrangères dans un même traitement. Une matrice des opérations, établie avec le responsable fiscal, croise le pays, la nature de l’opération (vente de biens ou prestation de services), le statut du client (assujetti ou non) et le régime de TVA applicable. Le projet technique s’appuie sur cette matrice pour sélectionner les données à transmettre ; il ne décide pas à la place de l’équipe fiscale, et un filtre fondé sur la seule adresse du client est insuffisant.

Sanctions, retards et régularisation

La loi de finances pour 2026 (article 123) fixe à 500 euros par transmission omise l’amende pour défaut de transmission des données de transaction et de paiement, au lieu de 250 euros, dans la limite de 15 000 euros par année civile. Elle n’est pas applicable à une première infraction commise dans l’année civile en cours et les trois précédentes, si elle est réparée spontanément ou dans les trente jours suivant une première demande de l’administration.

Selon le guide de démarrage de la DGFiP, une difficulté temporaire de e-reporting ne remet pas en cause la validité des factures, le paiement ni la poursuite de l’activité. L’entreprise sécurise les données, documente l’incident, transmet ce qui peut l’être et régularise le reste, en rapprochant les données régularisées des factures, des encaissements et des écritures comptables. Il ne s’agit pas de transmettre en masse des données non contrôlées pour rattraper un retard.

Partager la responsabilité

La plateforme transmet selon son service, mais l’entreprise doit pouvoir expliquer ses données sources. Désignez un responsable de validation du lot, un interlocuteur technique pour les anomalies, et faites remettre un état de rapprochement entre données préparées, transmises et réponses reçues. Si une application reste hors périmètre, inscrivez la limite au dossier de décision ; le registre des sources doit être mis à jour à chaque nouvelle activité.

Grille à joindre à la consultation

Livrable attendu

Le livrable attendu est une matrice des opérations accompagnée du dictionnaire des données et de tests de correction. Faites valider le champ fiscal avant de demander un chiffrage technique définitif. Exigez que les périodes et règles configurées renvoient à une référence actuelle. Les cas non qualifiés doivent rester identifiés dans le registre du projet. Le devis distingue l’intégration des sources, la validation métier et le service de transmission souscrit auprès de la plateforme.