Deux mois après l’entrée en vigueur de la réforme, le 1er septembre 2026, la question n’est plus de savoir si les flux passent, mais comment l’ERP se comporte quand ils ne passent pas. Les bilans précédents ont décrit les premiers points de friction. Cet article prend un autre angle : le paramétrage. Quelles erreurs de données produisent des rejets, comment faire remonter les statuts de cycle de vie dans l’ERP, que transmettre au titre de l’e-reporting, et ce que tout cela change pour la comptabilité et la trésorerie.
Une précision de méthode : la DGFiP n’a pas, à notre connaissance, publié de statistiques consolidées de rejets au 13 novembre 2026. Aucun taux de rejet n’est donc avancé ici. Quand une source manque ou que deux sources divergent, nous l’indiquons plutôt que de combler.
Où en est-on : ce qui est confirmé à date
Calendrier. Depuis le 1er septembre 2026, toutes les entreprises assujetties à la TVA doivent pouvoir recevoir des factures électroniques via une plateforme agréée. L’émission et l’e-reporting concernent à cette date les grandes entreprises et les ETI. Les PME et micro-entreprises suivent un an plus tard, le 1er septembre 2027 (La Poste, e-reporting : quelles données transmettre).
Statuts. La norme AFNOR XP Z12-012 impose quatre statuts obligatoires que toute plateforme agréée doit gérer : déposée, rejetée, refusée, encaissée. Les statuts qui complètent ce socle sont facultatifs (swim.legal, cycle de vie de la facture électronique, consulté le 13 novembre 2026).
Codes de rejet. Une synthèse tenue à jour par Compta Online (publiée le 14 avril 2026, modifiée le 9 novembre 2026) regroupe les anomalies en six familles : rejets techniques, routage et adressage, calculs et montants, TVA et conformité, refus métier, litiges commerciaux. Elle recense 13 codes qui justifient un statut « refusée » et 7 codes d’action corrective (compta-online.com).
Ce que nous n’avons pas pu vérifier. Les pages de référence de la DGFiP sur l’e-reporting (données de transaction, données de paiement, tableau des fréquences) sont publiées sur impots.gouv.fr sous forme de PDF dont nous n’avons pas pu extraire le contenu lors de la rédaction. Les fréquences détaillées ci-dessous s’appuient donc sur des sources secondaires qui ne concordent pas entièrement : à confirmer sur la page officielle avant tout paramétrage.
Top des causes de rejet et correction dans l’ERP
Les articles précédents ont déjà cité les erreurs d’identifiants et de mentions. Le tableau ci-dessous les rattache à la donnée ERP qui en est la source, ce qui est le point utile pour un DSI. Les familles de codes sont celles de la synthèse Compta Online ; la fréquence relative de chaque cause n’est pas documentée publiquement et ne figure donc pas ici.
| Cause (famille de code) | Symptôme côté ERP | Correctif de paramétrage |
|---|---|---|
Destinataire inconnu ou adresse erronée (routage : DEST_INC, ADR_ERR, ROUTAGE_ERR) | Facture « rejetée » ou bloquée à l’émission alors que la pièce est correcte | Stocker SIREN (9 chiffres) et SIRET d’établissement dans des champs dédiés et contrôlés ; renseigner l’adresse de facturation électronique du client ; interroger l’annuaire avant le premier envoi |
Écart de calcul (CALCUL_ERR, MONTANTTOTAL_ERR) | Total TTC différent de la somme des lignes d’un centime | Aligner la règle d’arrondi de l’ERP sur celle du format (arrondi par ligne ou global, un seul choix documenté) ; tester les remises et les avoirs |
Taux ou régime de TVA (TX_TVA_ERR, NON_CONFORME) | Taux incohérent avec le motif d’exonération ou d’autoliquidation | Codifier les motifs d’exonération dans la table TVA ; interdire la saisie libre ; rendre la mention d’autoliquidation obligatoire dans le flux XML et pas seulement dans le PDF |
Référence de commande ou de contrat (CMD_ERR, REF_CT_ABSENT, CONTRAT_TERM) | Refus du client faute de numéro de commande ou de marché | Rendre le numéro de commande obligatoire à la validation de la facture pour les clients qui l’exigent ; contrôler la validité du contrat |
Doublon (DOUBLON, DOUBLE_FACT) | Facture renvoyée après un rejet et refusée comme doublon | Ne jamais ressaisir la même pièce : numéroter une nouvelle facture ou un avoir selon le code d’action reçu |
Encodage et schéma (familles IRR_*, REJ_*) | Caractères accentués corrompus, XML non conforme au schéma | Exporter en UTF-8 ; valider le XML avant transmission avec le contrôleur de la plateforme |
La logique commune : un rejet est presque toujours une donnée de base mal tenue (fiche client, table de TVA, règle d’arrondi), pas un incident de transmission. Corriger à la source évite de retraiter les pièces une à une. Si un lot de rejets revient d’une même cause, c’est que la fiche tiers ou le paramètre est à revoir, pas la facture.
Statuts de cycle de vie : les faire remonter dans l’ERP et les exploiter
Quatre statuts obligatoires, quatre usages distincts. Les définitions suivantes reprennent la synthèse swim.legal.
- Déposée : la facture est déposée sur la plateforme de l’émetteur. Dans l’ERP, c’est l’accusé qui permet de dire « émise » avec une preuve datée.
- Rejetée : la facture a échoué aux contrôles techniques ou réglementaires. Elle est réputée non émise : elle n’a pas d’existence juridique et le délai de paiement ne court pas.
- Refusée : le client la conteste pour un motif de fond. La facture a circulé, mais elle appelle une facture rectificative ou un avoir.
- Encaissée : le fournisseur déclare le paiement reçu. Ce statut compte pour les prestations de services, dont la TVA est exigible à l’encaissement.
Comment les exploiter. Trois paramétrages concrets reviennent :
- Un champ statut sur la pièce comptable, alimenté par l’API ou le fichier de retour de la plateforme, avec l’horodatage de chaque changement. Sans lui, la balance âgée surestime les créances : une facture rejetée n’est pas une créance exigible.
- Des files de travail par statut. Les rejetées vont au service facturation (correction de donnée, réémission), les refusées au service commercial ou au recouvrement (litige, avoir), avec un propriétaire nommé et un délai interne.
- Un statut « encaissée » émis par l’ERP lors du lettrage, pour les opérations concernées. C’est le seul statut obligatoire que le fournisseur doit lui-même produire : il suppose que le rapprochement bancaire et le lettrage soient à jour au moment de la déclaration.
Les statuts facultatifs (prise en charge, approuvée, en litige, suspendue, paiement transmis) ne sont pas obligatoires. Ils valent surtout côté acheteur : un « approuvée » alimente le circuit de validation, un « en litige » arrête la relance automatique. Avant de les activer, vérifiez ceux que votre plateforme propose réellement.
Attention à un angle mort fréquent : une interface qui perd silencieusement un retour de statut laisse l’ERP croire qu’une facture est émise alors qu’elle est rejetée. La supervision des interfaces ERP doit donc couvrir le flux de retour autant que le flux aller.
E-reporting : ce qui doit être transmis, par qui, avec quelle fréquence
L’e-reporting couvre ce que la facture électronique ne couvre pas : les ventes aux particuliers (B2C), les opérations internationales, certaines prestations de services B2B, et les données de paiement. Il n’y a pas de seuil de chiffre d’affaires : toute entreprise assujettie à la TVA entre dans le périmètre à sa date d’échéance (La Poste).
Deux flux distincts.
- Données de transaction : pour chaque période, des données agrégées (montant hors taxes, taux de TVA appliqués) sur les ventes B2C et les opérations internationales (Hayot Expertise).
- Données de paiement : requises pour les opérations dont la TVA est exigible à l’encaissement, typiquement les prestations de services.
Par qui. C’est l’entreprise qui reste responsable de la transmission, via sa plateforme agréée. La délégation à un cabinet comptable est possible, mais la responsabilité demeure à l’entreprise (même source Hayot).
À quelle fréquence : sources divergentes. La Poste indique une transmission dans les 10 jours suivant la période, avec un rythme qui dépend du régime de TVA (plusieurs fois par mois pour le réel normal mensuel, mensuel pour le réel simplifié ou trimestriel, tous les deux mois pour la franchise). Hayot Expertise donne un rythme proche mais des échéances différentes pour le réel simplifié et la franchise (autour du 25 au 30 du mois suivant). Les deux s’accordent sur le principe : la fréquence dépend du régime de TVA et non de la taille. Nous ne retenons donc pas d’échéance chiffrée : le tableau officiel des fréquences et délais de la DGFiP fait foi.
Sanction. Selon La Poste, 500 € par transmission manquante, plafonnés à 15 000 € par an, avec une régularisation possible sous 30 jours sans amende pour une première infraction. Ces éléments reprennent l’article 1788 D du CGI, déjà cité dans notre bilan à J+25 ; vérifiez-les sur le texte en vigueur.
Côté ERP. Deux contrôles préalables : étiqueter chaque vente selon son flux (facture B2B, e-reporting B2C, e-reporting international) et s’assurer que la ventilation par taux de TVA des écritures est exploitable. Les caisses, boutiques en ligne et passerelles de paiement alimentent souvent l’ERP en écritures de synthèse : si le détail par taux se perd à l’import, l’agrégat transmis sera faux.
Impacts comptables et trésorerie
Délais. Une facture rejetée est réputée non émise. Le point de départ du délai de paiement (et donc de la relance) est celui de la facture acceptée, pas celui de la tentative. Pour la trésorerie, chaque rejet corrigé tard décale l’encaissement d’autant.
Avoirs. Une facture refusée se corrige par un avoir et une nouvelle facture, ou une facture rectificative. Il faut que l’ERP lie l’avoir à la facture d’origine (référence obligatoire) et que la comptabilité de TVA suive : l’avoir est lui-même une pièce qui transite par la plateforme et peut être rejetée.
Comptabilisation. Côté client, comptabiliser à la réception de la facture « mise à disposition » plutôt qu’à l’approbation peut créer des dettes sur des factures qui seront ensuite refusées. Décidez, par type de flux, à quel statut l’écriture est passée, et documentez-le pour l’audit. Les règles de piste d’audit de l’ERP s’appliquent aux statuts comme aux pièces.
Rapprochement. Prévoyez un état de rapprochement mensuel : factures comptabilisées, factures déposées, factures rejetées ou refusées non traitées, factures encaissées déclarées. Tout écart non expliqué doit être justifié avant la clôture. Le calendrier réglementaire ERP de janvier 2027 rappelle les échéances qui s’ajoutent.
Plan d’action pour les 30 prochains jours
Semaine 1, mesurer.
- Extraire de la plateforme agréée la liste des rejets et refus depuis le 1er septembre, avec le code de motif
- Classer par famille de code et par cause de donnée (fiche tiers, TVA, arrondi, référence)
Semaine 2, corriger à la source.
- Nettoyer les fiches clients : SIREN sur 9 chiffres, SIRET d’établissement, adresse de facturation électronique
- Verrouiller les motifs d’exonération et d’autoliquidation dans la table de TVA
- Rendre le numéro de commande obligatoire pour les clients qui l’exigent
- Figer la règle d’arrondi et la tester avec remises et avoirs
Semaine 3, brancher les statuts.
- Vérifier que les quatre statuts obligatoires remontent dans l’ERP avec horodatage
- Créer les files de travail rejetées et refusées, avec un responsable
- Exclure les factures rejetées de la balance âgée exigible
- Superviser le flux de retour des statuts (alerte si aucun retour sous un délai défini)
Semaine 4, préparer l’e-reporting.
- Confirmer sur impots.gouv.fr la fréquence applicable à votre régime de TVA
- Étiqueter les ventes B2C et internationales et contrôler la ventilation par taux
- Définir qui transmet (interne ou cabinet) et qui valide
- Mettre en place l’état de rapprochement mensuel avant la prochaine clôture
Pour suivre les clarifications de la DGFiP et les évolutions des normes de plateforme, abonnez-vous à la newsletter de veille réglementaire ERP.
