Publié le 24 août 2026
Facturation électronique B2B domestique et e-reporting ne couvrent pas les mêmes opérations. Les ventes à des particuliers ou à d’autres personnes non assujetties relèvent notamment du e-reporting de transaction. Certaines opérations appellent aussi des données de paiement lorsque la TVA est exigible à l’encaissement.
Pour un éditeur, le principal chantier se trouve souvent dans la qualité des données sources. Un total comptable produit en fin de mois ne suffit pas nécessairement à expliquer les agrégats attendus par journée, catégorie et taux de TVA. Le logiciel doit conserver l’origine de chaque montant, la date métier et les corrections successives.
Cette préparation complète le travail plus large pour intégrer la facturation électronique dans un logiciel métier. Elle ne remplace pas l’analyse fiscale du périmètre propre à l’entreprise.
E-invoicing et e-reporting : ne pas confondre les deux flux
L’e-invoicing organise l’échange des factures B2B domestiques entrant dans le champ de la réforme. Le e-reporting de transaction porte sur certaines opérations qui n’empruntent pas ce circuit, notamment les ventes B2C et des opérations internationales. Le e-reporting de paiement ajoute, dans les cas concernés par la TVA à l’encaissement, la date et le montant encaissé par taux.
La plateforme agréée assure les transmissions prévues par son immatriculation. Le logiciel métier qualifie les opérations, calcule les montants et prépare des données vérifiables. Une solution compatible peut isoler le raccordement technique sans devenir elle-même une plateforme agréée. Codisys accompagne cette intégration de la facturation électronique dans les applications métier.
Quelles opérations B2C faut-il identifier dans le logiciel ?
Le modèle doit distinguer le statut fiscal du client, son pays, la vente de biens ou la prestation de services, les catégories utiles, les taux de TVA et les régimes particuliers lorsqu’ils s’appliquent. Il doit aussi permettre de déterminer si l’opération entre dans le périmètre du e-reporting ou suit un autre circuit.
L’absence de numéro de TVA ne suffit pas, à elle seule, à qualifier automatiquement un client ou une opération. La règle de qualification doit être explicite, documentée et définie avec les interlocuteurs fiscaux, comptables et métier compétents. Le logiciel conserve ensuite cette décision au lieu de la recalculer différemment lors de chaque export.
Les données de transaction B2C à préparer
La fiche DGFiP « Données de transaction à transmettre », mise à jour en août 2026, identifie pour le B2C le SIREN du redevable, la période, l’option pour le paiement de la TVA d’après les débits lorsqu’elle s’applique, la journée, la catégorie de transaction, la base totale hors taxe et le montant de TVA. Lorsque plusieurs taux s’appliquent, base et TVA sont ventilées par taux. La version consultée ne liste pas le nombre de transactions dans ce socle.
| Donnée | Rôle | Source probable | Contrôle conseillé |
|---|---|---|---|
| SIREN | Identifier l’entité déclarante | Fiche entreprise ou tenant | Format et rattachement à l’entité |
| Période | Délimiter le flux préparé | Moteur de reporting | Début et fin cohérents |
| Date de journée | Porter l’agrégation journalière | Date de transaction | Fuseau et date métier stables |
| Catégorie | Qualifier l’opération | Produit, prestation, règle fiscale | Valeur explicite et documentée |
| Base HT | Conserver la base imposable | Lignes de vente | Remises, avoirs et arrondis cohérents |
| TVA et taux | Ventiler le montant de taxe | Moteur de calcul | Rapprochement base, taux et TVA |
Pourquoi les données sont-elles agrégées par jour ?
Le logiciel peut conserver chaque ticket et chaque vente, tandis que le flux B2C transmis utilise des agrégats journaliers. Cette différence ne doit pas casser la traçabilité : tout total doit pouvoir être reconstitué à partir des transactions sources, avec une date métier stable et une ventilation fiscale identique.
Annulations et corrections ne doivent pas effacer l’historique. Un agrégat recalculé reste rapprochable de sa version précédente et des opérations qui l’ont produit. Une logique de calcul partagée entre ticket, facture, journal de vente, agrégat et flux limite les écarts. L’algorithme d’arrondi, lui, doit être validé pour le contexte plutôt qu’inventé dans le connecteur.
Quelles données de paiement faut-il prévoir ?
La fiche officielle sur les données de paiement, mise à jour en août 2026, vise les opérations dont la TVA est exigible à l’encaissement, hors opérations autoliquidées et option pour les débits. Elle attend la date d’encaissement effectif et le montant encaissé, ventilé par taux de TVA.
Trois rattachements doivent être modélisables : le paiement d’une facture électronique, celui d’une opération B2B internationale sans dépôt de facture électronique, et l’encaissement lié à des opérations B2C agrégées par jour. Selon le cas, le logiciel conserve aussi le numéro de facture, la période et le SIREN de l’entité qui encaisse.
Le moyen de paiement n’est pas la donnée fiscale principale
Carte, virement, espèces, prélèvement, chèque ou portefeuille numérique restent utiles pour le rapprochement et le support. Ils ne doivent pourtant pas être présentés comme des champs réglementaires obligatoires du e-reporting lorsque la source officielle ne les exige pas. Les données bancaires ou un identifiant de carte n’ont pas à être ajoutés au flux par défaut.
Pour le reporting de paiement, le cœur du modèle est la date réelle d’encaissement, le montant, la ventilation par taux, le rattachement métier, la période et l’entité déclarante. La date de facture et la date d’encaissement restent deux événements distincts.
Gérer les paiements partiels, remboursements et corrections
Une opération peut recevoir plusieurs encaissements, un paiement partiel, un remboursement, une annulation ou un avoir. Le logiciel doit relier chaque événement à sa donnée initiale, conserver les versions corrigées et permettre une nouvelle transmission sans perdre le retour précédent.
Aucun traitement comptable universel ne convient à tous les cas. Les règles pour les paiements partiels et les régularisations doivent être définies avec la plateforme agréée, l’expert-comptable, la documentation fiscale applicable et les règles métier de l’entreprise.
Modèle de données conseillé dans un logiciel métier
Séparer les valeurs qui décrivent l’opération de celles qui sécurisent son traitement évite de confondre obligation réglementaire et choix d’architecture. Avant de développer, il reste utile de vérifier les données du logiciel et leur propriétaire fonctionnel.
Données réglementaires ou métier
legal_entity_sirenreporting_period_startetreporting_period_endtransaction_daycustomer_tax_statusetcustomer_countryoperation_categoryvat_on_debits_optionvat_rate,taxable_basis_amountetvat_amountpayment_day,collected_amountetsource_invoice_number
Données internes recommandées
source_transaction_idetsource_document_idreporting_batch_idetexternal_submission_idinternal_statusetprovider_statusprepared_at,submitted_atetacknowledged_atcorrection_of,idempotency_keyetcontent_hashlast_error_code,last_error_messageetretry_countcreated_byetcorrected_by
Ne pas coder les périodicités en dur
Fréquences et délais dépendent notamment du régime de TVA. Le modèle doit paramétrer le type de période, ses dates de début et de fin, la date limite, le régime fiscal, l’état de préparation, l’état de transmission et une éventuelle régularisation.
La DGFiP a actualisé en août 2026 son tableau des fréquences et délais de transmission. Le consulter évite de figer dans le code une règle susceptible d’évoluer ou de ne pas correspondre au régime de l’entreprise.
Organiser un workflow de préparation et de transmission
Des statuts internes comme « à préparer », « incomplet », « prêt à transmettre », « transmis », « accepté », « à corriger », « corrigé » et « régularisé » rendent le travail lisible. Ils ne doivent pas être présentés comme des statuts réglementaires officiels.
Le logiciel distingue son état interne, celui de la solution compatible, le retour de la plateforme agréée et l’état fiscal ou métier. Lorsqu’un retour arrive après l’envoi, le guide sur le suivi des rejets et retours après transmission aide à préserver cette nuance.
Traçabilité, reprise et prévention des doublons
Chaque lot possède un identifiant stable et une clé d’idempotence. Le journal relie la date d’envoi, le contenu transmis, son empreinte, la réponse reçue et l’historique des corrections. En cas d’indisponibilité, la reprise réutilise ces références et ne recrée pas silencieusement le même flux.
La conservation du détail ayant produit l’agrégat facilite le rapprochement et l’audit. Une architecture API de facturation électronique doit prévoir ces preuves dès la conception, au lieu de les reconstituer après un incident.
Comment Codisys Invoice Connect intervient-il ?
Codisys Invoice Connect fournit une interface commune permettant aux logiciels métier de préparer et transmettre les données nécessaires via la plateforme agréée raccordée. La passerelle centralise les contrôles, les identifiants de suivi, les statuts, les erreurs et la traçabilité.
Codisys Invoice Connect est une solution compatible facturation électronique raccordée à Hubtimize e-Invoicing, plateforme agréée développée par EsaLink. Codisys Invoice Connect n’est pas lui-même une plateforme agréée.
Définition et conditions d’usage : présentation officielle DGFiP des deux labels.
Checklist des données à vérifier dans le logiciel
- identifier l’entité déclarante ;
- conserver son SIREN ;
- qualifier le client et son pays ;
- distinguer vente de biens et prestation de services ;
- conserver le taux de TVA par opération ;
- conserver la base HT et la TVA ;
- fiabiliser la date de transaction ;
- enregistrer la date réelle d’encaissement ;
- ventiler les encaissements par taux de TVA ;
- produire des agrégats journaliers explicables ;
- conserver le détail source ;
- gérer les périodes de transmission ;
- historiser corrections et régularisations ;
- prévenir les doublons ;
- suivre les réponses de la plateforme.
Conclusion
Le e-reporting est d’abord un sujet de données. La qualité du flux dépend de la qualification des opérations, des dates, des bases HT, de la TVA et des encaissements conservés dans le logiciel métier. Les agrégats doivent rester explicables et les corrections auditables.
Structurer les paiements au dernier moment fragilise le rapprochement. Une solution compatible raccordée à une plateforme agréée peut isoler la connexion technique, mais elle ne remplace ni les bonnes données sources ni la validation des règles fiscales applicables.