E-Invoice Finder
Menu
Pays Logiciels Échéances Guides Checker Vérifier obligation
ENFRDEPLNL
Plan indépendant de recette logicielle 2026

Comment tester un logiciel e-reporting en France avant le déploiement

Plan opérationnel pour tester en démo un logiciel d’e-reporting en France : B2C, international, encaissements, avoirs, rejets, rapprochement et plateforme agréée.

Résumé pratique :
  • Demandez des fichiers horodatés, pas seulement des captures d’écran.
  • Faites rejouer les anomalies jusqu’à leur résolution complète.
  • N’acceptez aucune zone grise sur le propriétaire de chaque interface.
Voir le rapportSources officielles
Dernière vérification : 24 juillet 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. Transformer la démo commerciale en démonstration de conformité opérationnelle

La réforme française couvre trois périmètres distincts selon la DGFiP : la facturation électronique B2B domestique, l’e-reporting des transactions réalisées notamment avec des particuliers ou des opérateurs établis à l’étranger, et la transmission des données d’encaissement lorsque la TVA est exigible sur les encaissements. Un logiciel peut bien gérer l’un de ces périmètres et échouer sur un autre ; la recette doit donc partir de vos opérations réelles plutôt que d’un parcours standard préparé par le vendeur. Toutes les entreprises devront pouvoir recevoir des factures électroniques à compter du 1er septembre 2026. Les grandes entreprises et les entreprises de taille intermédiaire devront également émettre et réaliser leur e-reporting à cette date, tandis que les petites et microentreprises disposeront jusqu’au 1er septembre 2027 pour ces obligations d’émission et de reporting. Ce calendrier ne dispense pas les petites structures de préparer leurs données, leurs interfaces et leur capacité de réception avant 2026. Les échanges réglementés passent par une plateforme agréée par l’administration fiscale, désignée ici comme PA. L’ancien terme PDP peut encore apparaître dans des contrats, documentations ou interfaces. Une solution dite compatible ne peut pas assurer seule les transmissions réglementées si elle n’est pas agréée ; elle doit alors être effectivement connectée à une PA, avec des responsabilités et des preuves de bout en bout clairement établies. • Demandez si la démonstration utilise une vraie connexion de test à une PA ou une simple simulation locale. • Identifiez séparément les flux de facturation électronique, de transaction e-reporting et de paiement ou encaissement. • Faites préciser quels composants sont déjà disponibles, lesquels sont en bêta et lesquels figurent seulement sur la feuille de route. • Vérifiez le rôle exact de l’ERP, du logiciel de facturation, de la caisse ou du POS, du système comptable, de l’API et de la PA. • Exigez une traçabilité entre chaque donnée source, sa transformation et l’accusé de traitement correspondant.

Guide

2. Préparer les données et responsabilités avant la démo

Préparez un petit jeu de données représentatif, anonymisé si nécessaire, couvrant vos canaux de vente, régimes de TVA, devises, catégories de clients et modes d’encaissement. Les données doivent provenir des systèmes qui feront réellement autorité après le déploiement : ERP, facturation, POS ou caisse, comptabilité, outil de paiement et référentiel client. Un jeu artificiellement parfait masque les défauts de SIREN, les identifiants étrangers absents, les différences d’arrondi et les dates incohérentes. Cartographiez chaque champ important avant la session : identité du vendeur, type de client, pays, SIREN ou identifiant étranger, date et nature de l’opération, base hors taxe, taux et montant de TVA, devise, statut, référence de facture ou d’avoir, date d’encaissement et montant encaissé par taux. Pour le B2C, la DGFiP prévoit généralement une agrégation journalière par taux de TVA, sans attente de données personnelles sur le consommateur. Invitez les personnes capables de répondre immédiatement aux questions de données et d’exploitation. Le vendeur devrait faire participer un spécialiste produit ou intégration, et pas seulement un commercial. De votre côté, prévoyez au minimum un représentant finance ou fiscalité, le propriétaire de l’ERP ou de la facturation, un responsable des encaissements et un interlocuteur IT ou sécurité. • Remettez au vendeur les dix scénarios et les critères de réussite avant la démo afin d’éviter une présentation improvisée ou sélective. • Définissez le système maître pour les clients, les factures, les ventes de caisse, les avoirs, les paiements et les statuts. • Préparez des exemples avec données incomplètes, doublons et erreurs de format, pas uniquement des cas valides. • Documentez les règles internes relatives à la TVA sur les débits, à la TVA sur les encaissements et aux opérations sous autoliquidation. • Convenez d’un espace sécurisé pour récupérer les fichiers, journaux, accusés, exports et captures produits pendant la recette. • Attribuez à l’avance un responsable interne et un responsable fournisseur pour chaque interface.

Guide

3. Définir des critères d’acceptation observables

Un scénario est réussi seulement si le logiciel reçoit correctement les données, applique la bonne classification, génère la sortie attendue, transmet ou simule fidèlement la transmission vers la PA, puis restitue un statut exploitable. Une mention générique telle que « conforme » ou « envoyé » n’est pas une preuve suffisante si elle ne permet pas de retrouver les données et le résultat de contrôle. Les critères doivent inclure les cas positifs et négatifs. Pour chaque test, consignez le résultat attendu, le résultat observé, l’écart, sa gravité, son propriétaire et la date de correction prévue. Après correction, rejouez exactement le même scénario avec les mêmes identifiants afin de vérifier la résolution et l’absence de régression. Les formats structurés UBL et CII, ainsi que le format mixte Factur-X, font partie des approches acceptées dans le contexte de la réforme. Un PDF ordinaire envoyé par e-mail n’est pas une facture électronique conforme. La recette doit donc inspecter les données structurées et pas seulement le rendu visuel du document. • Réussite fonctionnelle : la catégorie fiscale, les montants, les taux, les dates et les identifiants correspondent aux données validées. • Réussite technique : les messages respectent le format attendu et produisent des identifiants, statuts et horodatages exploitables. • Réussite opérationnelle : un utilisateur autorisé peut détecter, comprendre, corriger et rejouer une anomalie sans manipulation opaque. • Réussite comptable : les totaux transmis se rapprochent des journaux de vente, de TVA et d’encaissement selon des règles documentées. • Réussite d’audit : les entrées, transformations, transmissions, rejets, corrections et exports restent consultables et exportables. • Échec bloquant : mauvaise classification, perte de transaction, double transmission, montant erroné ou absence de preuve de traitement.

Guide

4. Tests 1 à 5 : B2C, international et premiers encaissements

Exécutez ces tests dans le logiciel proposé, idéalement à partir d’un import ou d’une API proche de votre architecture cible. Ne laissez pas le démonstrateur corriger silencieusement les fichiers en dehors du produit : toute transformation manuelle doit être visible, documentée et reproductible. Pour chaque scénario, conservez au minimum le fichier ou message d’entrée, la sortie structurée, les règles de transformation appliquées, les journaux, l’identifiant de lot ou de transmission et le statut retourné. Si l’environnement ne permet pas une transmission réelle à une PA de test, demandez une distinction explicite entre ce qui a été exécuté et ce qui a seulement été simulé. • Test 1 — Agrégation journalière B2C multi-taux. Entrée : ventes domestiques d’une journée comprenant, par exemple, des bases à 20 %, 10 % et 5,5 %, avec plusieurs tickets. Sortie attendue : agrégats journaliers correctement ventilés par taux, sans données personnelles inutiles sur les consommateurs, avec date et totaux rapprochables. Preuves : export des ventes sources, calcul d’agrégation, message produit, contrôles d’arrondi et statut de traitement. • Test 2 — Ventes B2C sans facture individuelle. Entrée : totaux de caisse ou de POS, annulations de tickets et clôture journalière sans facture nominative. Sortie attendue : données de transaction produites à partir des totaux pertinents, sans création artificielle d’une facture électronique pour chaque consommateur. Preuves : rapport Z ou équivalent, détail des annulations, table de correspondance POS vers e-reporting et total transmis. • Test 3 — Client professionnel étranger, devise et classification export ou intra-UE. Entrée : vente à un client établi hors de France avec identifiant TVA ou autre identifiant étranger lorsque pertinent, adresse pays, devise étrangère et exemple distinct d’export ou d’opération intra-UE. Sortie attendue : absence de faux SIREN français, conservation de l’identifiant étranger, conversion ou déclaration monétaire selon la configuration validée et classification exacte de l’opération. Preuves : fiche client, taux de change utilisé le cas échéant, données structurées et justification de la catégorie retenue. • Test 4 — Service domestique avec TVA exigible à l’encaissement. Entrée : facture de service soumise à la TVA sur les encaissements, sans option pour les débits et sans autoliquidation, puis règlement complet. Sortie attendue : émission ou traitement correct de la facture et création d’une donnée d’encaissement indiquant notamment la date et le montant encaissé ventilé par taux de TVA ; pour une facture électronique, le statut « encaissée » peut compléter l’information. Preuves : facture, événement de paiement, ventilation, message transmis et statut associé. • Test 5 — Encaissements partiels à des dates différentes. Entrée : facture de service de 1 200 € TTC réglée en deux fois, par exemple 480 € puis 720 € à des dates distinctes. Sortie attendue : deux événements d’encaissement séparés, sans déclarer prématurément le solde total, avec cumul final cohérent et ventilation correcte. Preuves : relevés ou événements de paiement, journal d’affectation, messages successifs, solde restant et rapprochement final.

Guide

5. Tests 6 à 10 : avances, corrections, exclusions et résilience

La seconde série évalue les situations qui provoquent le plus souvent des écarts entre facturation, comptabilité et paiement. Elle doit montrer comment le logiciel gère le cycle de vie complet d’une opération, et non uniquement la création initiale d’un enregistrement. Observez particulièrement les identifiants techniques et métier. Une correction ne doit pas effacer l’historique, un rejet ne doit pas être confondu avec une acceptation et une relance réseau ne doit pas créer un doublon. Le système doit rendre les dépendances avec la PA et les autres applications compréhensibles pour l’équipe d’exploitation. • Test 6 — Acompte ou avance. Entrée : paiement reçu avant la livraison ou la prestation, puis document d’acompte et facture finale. Sortie attendue : traitement conforme à la configuration fiscale validée, liaison explicite entre l’avance et le document final, et absence de double comptabilisation du paiement. Preuves : chronologie, références croisées, événements d’encaissement, calculs et rapprochement du solde. • Test 7 — Avoir, remboursement et annulation. Entrée : facture ou vente déjà enregistrée, avoir partiel, remboursement ultérieur et cas distinct d’annulation avant transmission. Sortie attendue : correction correctement typée, référence à l’opération d’origine, signe et montants cohérents, sans suppression silencieuse de l’historique. Preuves : document initial, avoir, événement de remboursement, journaux de statuts et comparaison avant-après. • Test 8 — TVA sur les débits ou autoliquidation. Entrée : service avec option pour la TVA sur les débits, puis opération distincte relevant de l’autoliquidation. Sortie attendue : absence de données d’encaissement indues lorsque le reporting de paiement ne s’applique pas, routage vers le bon traitement et conservation du motif. Preuves : paramètres fiscaux, décision de classification, sortie produite ou exclue et journal expliquant l’exclusion. • Test 9 — Lot rejeté, corrigé et resoumis. Entrée : lot contenant volontairement un identifiant invalide, un champ obligatoire absent ou un total incohérent. Sortie attendue : rejet visible avec motif précis, correction contrôlée, nouvelle soumission traçable et confirmation finale, sans perte des lignes valides ni duplication. Preuves : accusé de rejet, détail de l’erreur, version corrigée, identifiants de soumission et statut final. • Test 10 — Doublon, idempotence, rapprochement et export d’audit. Entrée : même message envoyé deux fois, reprise après interruption réseau et export d’une période complète. Sortie attendue : détection ou neutralisation du doublon, conservation d’une piste d’audit, rapprochement des sources avec les transmissions et export lisible sans dépendance irréversible au fournisseur. Preuves : clés d’idempotence, journaux techniques, rapport d’écarts, fichier exporté et procédure de reprise.

Guide

6. Vérifier les calculs avec un exemple chiffré illustratif

Supposons, à titre purement illustratif, qu’une journée de ventes B2C contienne 1 000 € HT au taux de 20 %, soit 200 € de TVA, et 500 € HT au taux de 10 %, soit 50 € de TVA. Le total TTC de la journée serait alors de 1 750 €. Le logiciel devrait être capable de restituer les agrégats séparés par taux et de les rapprocher du POS ou du journal de ventes sans transmettre les noms des consommateurs. Ajoutons une facture de service domestique de 1 200 € TTC comprenant, dans cet exemple simplifié, 1 000 € HT et 200 € de TVA à 20 %, avec TVA exigible à l’encaissement. Si le client paie 480 € le 10 octobre puis 720 € le 28 octobre, le système devrait produire deux événements correspondant aux montants et dates effectivement encaissés, selon la ventilation validée avec le conseiller de l’entreprise et la PA. Cet exemple n’établit pas les obligations applicables à toutes les opérations. Les règles de cadence, les données exactes, les arrondis, le traitement des devises et les mappings dépendent notamment du régime de TVA, du type de transaction, des spécifications en vigueur et du paramétrage de la plateforme. Validez ces éléments avec votre conseil, votre PA et la documentation DGFiP à jour. • Rapprochez les bases HT, la TVA et le TTC par taux entre la source, le message généré et le rapport final. • Contrôlez les écarts d’arrondi au niveau du ticket, de la facture, de la journée et de la période. • Vérifiez que les deux encaissements sont datés séparément et que leur cumul ne dépasse pas 1 200 €. • Testez un paiement non affecté, une différence de quelques centimes et une réaffectation après correction. • Conservez la formule ou la règle de ventilation utilisée afin qu’elle puisse être expliquée lors d’un contrôle interne.

Guide

7. Matrice de décision : questions de réussite ou d’échec

Transformez les observations de la démo en matrice de décision notée. Pour chaque question, utilisez une réponse simple : réussi avec preuve, réussi sous condition, non démontré ou échec. Une fonctionnalité annoncée mais non testable doit rester « non démontrée » et ne pas recevoir la même note qu’une capacité observée. Pondérez davantage les critères susceptibles de provoquer une déclaration inexacte, une perte de données ou un blocage opérationnel. Les fonctions d’interface agréables ont leur importance, mais elles ne compensent pas une mauvaise classification fiscale, une reprise manuelle fragile ou l’impossibilité d’exporter l’audit trail. La décision finale doit préciser les hypothèses de volume, les systèmes couverts, la PA utilisée, les interfaces incluses et les développements encore nécessaires. Sans ce périmètre, deux offres apparemment comparables peuvent en réalité transférer des responsabilités très différentes à votre équipe. • Périmètre : le produit distingue-t-il correctement B2B domestique, B2C, international, export, intra-UE et données d’encaissement ? • PA et architecture : la connexion à une plateforme agréée est-elle active, contractuellement identifiée et testée de bout en bout, ou s’agit-il seulement d’une solution compatible ? • Mapping : chaque donnée issue de l’ERP, du logiciel de facturation, du POS, de la comptabilité et de l’API a-t-elle une source, une règle et un contrôle documentés ? • Paiements et corrections : les encaissements partiels, avances, avoirs, remboursements, annulations, TVA sur les débits et autoliquidation sont-ils traités sans double comptage ? • Rejets et rapprochement : les erreurs sont-elles compréhensibles, assignables, rejouables et rapprochables avec les journaux financiers et les retours de la PA ? • Sécurité et exploitation : les permissions, validations, journaux, séparation des rôles, conservation et alertes répondent-ils à vos exigences internes ? • Réversibilité et livraison : les données et preuves sont-elles exportables, et les responsabilités d’implémentation, de support, de mise à jour et de résolution d’incident sont-elles nommées ?

Guide

8. Risques et erreurs fréquentes pendant la sélection

Le premier risque consiste à confondre une interface séduisante avec un flux réglementaire complet. Un tableau de bord peut afficher des statuts fictifs ou internes sans prouver qu’une PA a reçu et traité les données. Demandez toujours où commence et où s’arrête la responsabilité de chaque éditeur. Le deuxième risque est de sous-estimer les données d’encaissement. Elles peuvent s’appliquer indépendamment du type de client lorsque la TVA est exigible sur les encaissements, notamment pour certaines prestations de services lorsque l’option pour les débits n’a pas été exercée et qu’aucune autoliquidation ne s’applique. Une simple case « payé » ne démontre pas nécessairement la capture de la date, du montant et de la ventilation par taux. Enfin, évitez de figer les mappings ou la cadence sur une présentation commerciale ancienne. Les spécifications, règles opérationnelles et configurations de plateforme peuvent évoluer. Organisez une veille fondée sur les documents DGFiP actuels et faites valider les situations sensibles par les personnes compétentes. • Accepter un PDF envoyé par e-mail comme preuve de facture électronique conforme. • Supposer qu’une solution compatible peut transmettre réglementairement sans connexion démontrée à une PA. • Envoyer des données personnelles B2C inutiles alors que l’agrégation journalière par taux est généralement attendue. • Forcer un identifiant étranger dans un champ SIREN ou perdre l’information de devise et de pays. • Déclarer le montant total d’une facture dès le premier paiement partiel. • Corriger directement en base sans conserver l’erreur, la version modifiée et la nouvelle soumission. • Choisir un outil sans tester les exports, la réversibilité, les volumes et la reprise après incident.

Guide

9. Passer de la recette à un plan de mise en œuvre

À l’issue de la démo, consolidez les résultats dans un registre unique comprenant preuves, écarts, risques, responsables et échéances. Séparez les défauts du produit, les développements d’interface, les problèmes de qualité des données et les décisions fiscales ou comptables encore ouvertes. Cette distinction évite que chaque partie attribue ultérieurement les anomalies à une autre. Demandez ensuite un pilote sur un périmètre limité mais représentatif : une entité, un canal B2C, quelques clients étrangers et un ensemble de services avec paiements partiels. Le pilote doit reprendre les dix scénarios, mesurer les temps de traitement, observer les rejets et confirmer le rapprochement de bout en bout avant une généralisation. Planifiez enfin les contrôles récurrents après mise en production. Ils devraient couvrir les transmissions manquantes, doublons, rejets non résolus, écarts de TVA, paiements non affectés, changements de mapping et disponibilité des preuves. Revalidez le dispositif lorsque la DGFiP, la PA, l’ERP ou le modèle opérationnel modifie ses spécifications. • Classez chaque écart selon son impact réglementaire, financier, opérationnel et technique. • Obtenez une date, un responsable et une méthode de vérification pour chaque correction. • Faites approuver les règles de classification et d’encaissement par les fonctions compétentes. • Inscrivez les formats Factur-X, UBL ou CII et les responsabilités de conversion dans l’architecture cible. • Testez la montée en charge, la reprise, les alertes et les délais de support avant le déploiement général. • Conservez le dossier de recette et l’audit trail dans un emplacement contrôlé et accessible aux équipes autorisées.

Checklist

Préparer dix scénarios représentatifs avec résultats attendus et données anonymisées.

Identifier le système maître pour chaque client, vente, facture, avoir, paiement et statut.

Confirmer le nom et le rôle de la plateforme agréée connectée à la solution.

Tester l’agrégation journalière B2C avec plusieurs taux de TVA et des annulations.

Tester les identifiants étrangers, devises, exports et opérations intra-UE.

Tester un encaissement complet, deux paiements partiels et un acompte.

Vérifier les exclusions ou routages liés à la TVA sur les débits et à l’autoliquidation.

Provoquer un rejet, effectuer la correction et contrôler la resoumission.

Tester les doublons, le rapprochement, les permissions et l’export de l’audit trail.

Attribuer chaque écart et chaque interface à un responsable avec une échéance vérifiable.

Questions fréquentes

Comment tester un logiciel e-reporting avant de le choisir ?

Fournissez au vendeur des scénarios représentatifs de vos ventes B2C, transactions internationales, services et encaissements, puis demandez leur exécution dans le produit. Pour chaque cas, comparez l’entrée, la classification, la sortie structurée, le retour de la PA, les journaux et le rapprochement. Une promesse ou une feuille de route ne doit pas être notée comme une fonction démontrée.

Quels scénarios faut-il absolument demander pendant une démo ?

Couvrez au minimum l’agrégation B2C multi-taux, les ventes de caisse sans facture nominative, les clients professionnels étrangers, les exports ou opérations intra-UE, la TVA sur les encaissements, les paiements partiels, les acomptes, les avoirs, les rejets et les doublons. Les scénarios doivent inclure des erreurs volontaires afin de vérifier la correction, la resoumission et l’audit trail.

Comment vérifier l’agrégation journalière de l’e-reporting B2C ?

Partez du détail d’une journée de caisse ou de POS contenant plusieurs taux de TVA, remboursements et annulations. Recalculez les bases, la TVA et les totaux par taux, puis comparez-les aux agrégats générés et au message destiné à la PA. Vérifiez également qu’aucune donnée personnelle du consommateur n’est ajoutée sans nécessité.

Comment tester les encaissements partiels et les avoirs ?

Utilisez une facture de service soumise à la TVA sur les encaissements, réglée à deux dates différentes, puis ajoutez un avoir partiel ou un remboursement. Le logiciel doit conserver chaque événement, son montant, sa date, sa ventilation et son lien avec le document d’origine. Le cumul doit rester rapprochable et aucun paiement ne doit être déclaré deux fois.

Une solution compatible suffit-elle pour transmettre les données réglementaires ?

Non, pas si elle n’est pas elle-même une plateforme agréée. Une solution compatible peut préparer les données ou piloter les processus, mais les transmissions réglementées doivent passer par une PA connectée et identifiée. Demandez une preuve de cette connexion, les responsabilités contractuelles et les statuts retournés de bout en bout.

Quelles preuves conserver après la recette du logiciel ?

Conservez les données d’entrée, les mappings, les sorties structurées, les identifiants de lots, les accusés, les rejets, les corrections, les journaux d’horodatage et les rapports de rapprochement. Ajoutez les captures utiles et les décisions de configuration, mais ne reposez pas uniquement sur elles. Les preuves devraient être exportables et compréhensibles sans accès permanent à l’outil du fournisseur.

Le reporting des paiements concerne-t-il uniquement les clients particuliers ?

Non. D’après la présentation de la DGFiP, les données d’encaissement concernent les opérations pour lesquelles la TVA est exigible à l’encaissement, quel que soit le type de client. Les cas exacts doivent néanmoins être validés selon le régime de TVA, l’option pour les débits, une éventuelle autoliquidation et la nature de l’opération.

Peut-on valider la conformité avec un PDF et un statut « envoyé » ?

Non. Un PDF ordinaire transmis par e-mail ne constitue pas une facture électronique conforme au dispositif, contrairement aux approches structurées telles que UBL, CII ou Factur-X dans le contexte prévu. De même, un statut interne « envoyé » doit être relié à une transmission réelle ou clairement simulée, à un identifiant, à un horodatage et à un retour exploitable de la PA.

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éePlan de recette 2026/2027 pour une démo de logiciel e-reporting en France

France — Hub pays

France

Ouvrir le hub pays →

Utilisez le hub pays pour retrouver tous les guides, échéances, checklists, formats et comparatifs liés à ce marché.

À lire aussi

Sources officielles

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