E-reporting : ce que votre code devra déclarer même si vous ne faites pas de B2B

Table des matières

« On ne fait que du B2C, on n’est pas concernés » — si, justement

C’est la phrase que j’entends le plus souvent quand la réforme arrive dans une conversation entre développeurs : « nous, on vend à des particuliers, la facturation électronique ne nous concerne pas ». Raté. La réforme a deux jambes, et si la première — l’échange de factures électroniques B2B — ne vous concerne effectivement pas, la seconde vous attend : le e-reporting.

Le principe, tel que le formule impots.gouv.fr : les entreprises assujetties devront recourir à une plateforme agréée « pour adresser des données de transactions et de paiement à l’administration à compter du 1er septembre 2026 ». Deux familles de données, donc :

• les données de transactions : pour les opérations qui ne passent pas par le circuit de facturation électronique B2B domestique — typiquement les ventes aux particuliers et les opérations avec l’international ;
• les données de paiement : l’encaissement effectif, qui intéresse l’administration notamment parce que, pour les prestations de services, la TVA est exigible au paiement.

La logique d’ensemble est limpide vue de loin : l’administration veut une vision des flux soumis à TVA. Ce qui passe en facture électronique B2B, elle le voit par la branche du Y (épisode 1). Ce qui n’y passe pas, elle le demande en données. Vous ne transmettez jamais directement : c’est votre plateforme agréée qui porte vos données au concentrateur de l’administration.

Ce que ça implique côté conception

Je vais rester au niveau architecture — le détail des périodicités, des formats de dépôt et des cas particuliers relève des spécifications externes (v3.2), à lire avant d’implémenter ; ce qui suit est la structure du problème, celle qui ne changera pas d’une version de spec à l’autre.

1. Le e-reporting est un pipeline de données, pas une facture de plus. Ne le collez pas au module de facturation : sa matière première est votre journal de ventes et d’encaissements. Caisse, boutique en ligne, abonnements, PSP — les sources sont multiples, et votre premier chantier est de les fédérer vers une représentation commune datée, typée, rattachée à la bonne entité assujettie.

2. C’est un système à périodes. Contrairement à la facture (un objet, un envoi), le e-reporting fonctionne par périodes de déclaration : on collecte des opérations sur une fenêtre, on transmet, on passe à la suivante. Côté code, cela réclame trois choses qui ne s’improvisent pas : une définition non ambiguë de la période (fuseaux, bornes, date d’opération vs date d’enregistrement), une clôture explicite (quand une période est-elle finie ? peut-elle encore recevoir des retardataires ?), et un traitement des corrections après coup.

3. Les corrections sont un cas nominal, pas une exception. Un remboursement arrive après la clôture. Une vente est annulée. Un encaissement est rapproché tardivement. Le guide officiel de démarrage consacre une question entière à « comment régulariser des données de e-reporting qui n’ont pas pu être transmises immédiatement » — c’est dire si le dispositif prévoit l’imperfection. Votre modèle doit donc distinguer la période d’origine d’une opération et la période de déclaration dans laquelle elle a effectivement été transmise, et savoir émettre des corrections rattachées proprement. Si vous avez déjà conçu un système comptable, vous reconnaissez le patron : on n’efface jamais, on contre-passe.

4. La traçabilité est une exigence de premier ordre. Le guide est explicite : une difficulté temporaire de e-reporting ne remet pas en cause la validité des factures, le paiement ou la poursuite de l’activité — mais l’entreprise doit pouvoir démontrer sa trajectoire de mise en conformité. Traduction : votre pipeline doit journaliser ce qui a été transmis, quand, pour quelle période, avec quel accusé — et ce qui n’a pas pu l’être, avec la raison et la date de régularisation. Un registre append-only des transmissions vaut tous les slides de conformité.

Les pièges d’ingénierie que je vois venir

Trois pièges spécifiques à ce chantier, du vécu :

Le double comptage entre les deux jambes. Une même activité peut alimenter les deux circuits — du B2B en facture électronique ET du B2C en e-reporting. La frontière entre les deux (qui est cette contrepartie ? l’opération est-elle domestique ?) doit être une décision explicite et tracée de votre code, pas une déduction implicite. Et rappelez-vous la leçon multi-tenant, qui s’applique ici mot pour mot : un périmètre réglementaire ne se déduit jamais d’une donnée absente. « Pas de numéro d’entreprise » ne signifie pas « c’est un particulier » — ça signifie « donnée manquante », et la différence entre les deux est un flux fiscal qui disparaît en silence.

L’agrégation qui perd la piste. Selon les régimes, certaines transmissions sont agrégées. L’erreur classique est d’agréger à la source et de jeter le détail : le jour où une correction ou un contrôle arrive, vous ne savez plus décomposer. Agrégez au moment de la transmission, conservez le grain fin en dessous.

L’encaissement traité comme un événement de plus. Les données de paiement méritent leur propre soin : elles arrivent par d’autres canaux (PSP, banque, caisse), avec leurs propres délais et leurs propres rapprochements. Si votre système d’encaissement est approximatif — paiements partiels, pourboires, remboursements croisés — le e-reporting va exposer cette approximation à l’administration. Encore un chantier de données déguisé en chantier d’intégration.

Par où commencer, concrètement

1. Inventoriez vos opérations hors facturation électronique : B2C, international, et les encaissements de tout le monde. C’est votre périmètre e-reporting.
2. Lisez la partie e-reporting des spécifications externes (et seulement elle, dans un premier temps) pour votre régime : périodicités, contenu, canaux de dépôt.
3. Choisissez le rattachement à votre plateforme agréée — c’est le même choix structurant que dans l’épisode 3, et idéalement le même prestataire que pour vos factures.
4. Construisez le registre avant le flux : la table des transmissions (période, contenu, accusé, corrections) est le squelette ; le formatage des données vient après.
5. Réutilisez la machinerie d’états déjà en place : le registre des transmissions et leurs accusés se conçoivent avec les mêmes réflexes que les statuts de facture (épisode 4).
6. Testez la correction dès le premier sprint : si votre pipeline ne sait pas régulariser proprement, il n’est pas fini — c’est le cas nominal du régime de croisière.

Épilogue

Le e-reporting est la jambe discrète de la réforme, et pourtant c’est elle qui touche le plus d’entreprises — toutes celles qui encaissent, en fait. Côté ingénierie, c’est un beau problème de pipeline : fédération de sources, périodes et clôtures, corrections nominales, registre de transmissions. Rien que du classique bien exécuté — à condition de l’avoir budgété.

Prochain épisode, on lève la tête vers le réseau : Peppol pour les développeurs français. Et pour un coup de main sur ce chantier précis : gaetancottrez.dev/facturation-electronique 🔗.

Vos cas tordus d’encaissement m’intéressent — racontez-les en commentaire, je me ferai une joie de vous répondre.

Sources (consultées en août 2026) : Facturation électronique et plateformes agréées 🔗 (impots.gouv.fr — « données de transactions et de paiement ») · Guide pratique de démarrage 🔗 (PDF, DGFiP — questions 21 à 24 sur le e-reporting). Note de relecture : le périmètre exact des opérations, les périodicités par régime et l’exigibilité TVA à l’encaissement sont à re-vérifier contre les spécifications externes v3.2 et le BOFiP avant publication — l’article reste volontairement au niveau structurel.