# Comment suivre les rejets de clients répartis sur plusieurs plateformes agréées ?

Consolidez les événements de chaque plateforme en conservant leur code d’origine, leur date et la facture concernée. Ajoutez une date de dernière récupération et un responsable de traitement : une absence de retour doit rester visible, sans être assimilée à une facture acceptée.

Publié le 2026-09-17. Mis à jour le 2026-09-14.

Version HTML : https://diag-invoice.fr/questions-facturation-electronique/suivre-rejets-plusieurs-plateformes

## Construire un suivi par facture et par événement

Commencez par identifier le dossier client, la plateforme, le sens de circulation et la référence du document. Conservez séparément les événements reçus avec leur code brut, leur motif et leur date.

Une vue de portefeuille peut ensuite présenter un libellé commun, à condition que l’origine du retour reste consultable. La traduction aide à agir ; elle ne doit pas effacer la distinction entre rejet technique, refus du destinataire et information encore manquante.

Les données conseillées ci-dessous servent à organiser le travail d’un cabinet. Elles ne prétendent pas définir une liste de champs obligatoire pour toutes les API de plateforme.

Colonnes utiles dans un suivi de portefeuille

| Information | Utilité pour le cabinet |
| --- | --- |
| Client, plateforme et référence de facture | Retrouver le dossier sans confondre deux circuits. |
| Code brut, motif et date de l’événement | Comprendre le retour et conserver sa provenance. |
| Dernière récupération réussie | Repérer un suivi incomplet ou devenu ancien. |
| Responsable et prochaine action | Éviter qu’un rejet reste sans traitement attribué. |
| Résultat confirmé après intervention | Séparer l’action effectuée de son résultat. |

## Vérifier les possibilités de récupération de chaque plateforme

Le référentiel d’interopérabilité décrit des opérations de recherche de flux et la mise à disposition d’un flux de cycle de vie lorsqu’une facture est rejetée. Cela donne un cadre technique à examiner avec l’intégrateur.

Il faut ensuite vérifier les services réellement accessibles pour le client : habilitations, périmètre du mandat, export, interface disponible et profondeur d’historique. La présence d’une opération dans une norme ne démontre pas qu’un raccordement particulier fonctionne déjà.

Documentez la source de chaque remontée. Un import manuel daté peut être exploitable ; il ne doit simplement pas être présenté comme un suivi à jour en continu.

## Faire apparaître les retours absents et les reprises

Prévoyez un état de suivi « retour non récupéré » ou « récupération à vérifier ». Si un événement manque, le silence de votre tableau ne permet pas de conclure à l’acceptation de la facture.

Lors d’une reprise, vérifiez les événements déjà enregistrés pour éviter de créer plusieurs tâches pour le même retour. Conservez leur ordre réel et la date de récupération, qui peut être postérieure à la date de l’événement.

Le tableau doit rendre visibles les dossiers nécessitant une action, mais aussi ceux dont les informations ne sont plus fraîches. Après intervention, recherchez le nouveau retour au lieu de solder le dossier sur la seule déclaration d’une correction.

## Sources et repères techniques

### [AFNOR · Interfaces des services de facturation](https://fnfe-mpe.org/ressources/)

XP Z12-013 V1 ; Flow Service 1.3.0 · juin 2026

Tableau 4, p. 27 : AlreadyExistingFlow ; §5.5.2, p. 28 : mise à disposition d’un flux CDAR 213 ; opération searchFlows.

AlreadyExistingFlow concerne un flux déjà envoyé et réceptionné, par exemple avec une empreinte identique. La source distingue expressément ce cas du doublon de numéro de facture.

### [AIFE · Statuts du cycle de vie de la facture](https://www.impots.gouv.fr/specifications-externes-b2b)

Document général v3.2 · 30 avril 2026

Tableau 8, p. 59 : 213 « Rejetée » et 210 « Refusée ».

213 correspond à une anomalie détectée par un contrôle fonctionnel de la PA d’émission ou de réception ; 210 à un refus de la facture par le destinataire.

XP Z12-013 V1, juin 2026, §5.5.2 p.28 : mise à disposition d’un flux CDAR 213 après rejet par la PA d’émission ou de réception. L’opération searchFlows figure dans le corpus Interop FE consulté.

Pour les libellés 213 « Rejetée » et 210 « Refusée », référence : AIFE document général v3.2 du 30/04/2026, tableau 8 p.59. Conserver ces codes distincts dans toute consolidation.

## Ce qu’il faut faire

1. Inventorier les sources accessibles pour chaque client et chaque plateforme.
2. Conserver les références, les codes bruts, les dates et la dernière récupération réussie.
3. Attribuer un responsable et une action aux rejets, refus et récupérations manquantes.
4. Rapprocher les nouveaux événements après intervention et contrôler les doublons de remontée.

## Questions liées

- [Facture rejetée ou refusée : quelle différence et qui doit agir ?](https://diag-invoice.fr/questions-facturation-electronique/facture-rejetee-ou-refusee/index.md)
- [Je reçois une facture par e-mail et par la plateforme : est-ce un doublon ?](https://diag-invoice.fr/questions-facturation-electronique/facture-double-email-plateforme/index.md)
- [Ma facture est rejetée avec REJ_SEMAN : comment trouver ce qui bloque ?](https://diag-invoice.fr/questions-facturation-electronique/rejet-rej-seman/index.md)

## Revenir à la question principale

- [Comment tester les factures produites par mon logiciel de gestion ?](https://diag-invoice.fr/questions-facturation-electronique/tester-factures-logiciel-gestion/index.md)

Diag Invoice automatise le contrôle des factures et la lecture des écarts techniques décrits dans ces réponses.