01
Rejet de plateforme et refus de l’acheteur ne sont pas le même problème
La DGFiP distingue le rejet intervenant dans la chaîne technique du refus exprimé par l’acheteur. Un rejet peut venir d’un format non conforme, de données obligatoires absentes ou incohérentes, d’un identifiant de partie incorrect, d’une difficulté d’adressage ou de routage, ou d’une autre anomalie bloquante. Le refus, lui, appartient au cycle de vie après réception et doit être interprété selon le motif communiqué par l’acheteur. Avant toute correction, relevez donc le statut, le message ou code renvoyé, la facture concernée, l’horodatage et l’acteur qui a produit ce retour. Cette séparation évite de modifier les données fiscales ou commerciales alors que le défaut est seulement technique, ou inversement de traiter un désaccord métier comme un simple bug de format.
- Copier le statut et le motif exacts au lieu de résumer l’incident par « la facture ne passe pas ».
- Distinguer donnée/format/adressage/routage d’un refus motivé par le destinataire.
- Conserver l’identifiant de facture et les références de la tentative pour pouvoir relier correction et nouveau statut.
02
Corriger la cause racine avant de réémettre
Lorsque l’erreur vient de votre flux, corrigez-la dans la source ou le mapping responsable puis vérifiez la sortie structurée avant de réémettre. Une valeur changée uniquement à la main sur une facture ne résout pas un défaut qui se reproduira sur le prochain lot. Classez le rejet par couche : donnée source, mapping ERP, profil Factur-X/UBL/CII, contrôle de cohérence, identification du destinataire, routage ou incident du prestataire. Si la difficulté relève de la transmission ou des données de réception, le guide DGFiP recommande de se rapprocher de la plateforme, du prestataire ou du client concerné. Après correction, suivez le nouveau statut jusqu’à obtenir une preuve externe adaptée ; un contrôle local réussi reste une preuve de pré-validation, pas une preuve que la Plateforme Agréée a accepté ou remis la facture.
- Corriger dans le référentiel ou le mapping qui a produit l’erreur, pas seulement dans le document final.
- Re-tester un petit corpus représentatif si la règle affecte plusieurs types de factures ou plusieurs ERP.
- Après réémission, vérifier le nouveau statut externe au lieu de déduire le succès d’une validation locale.
03
Assurer la continuité sans créer de doublon et garder la preuve de l’incident
Le guide pratique de démarrage prévoit que la continuité de l’activité peut nécessiter un canal alternatif lorsque le destinataire ne dispose pas de la facture, tout en insistant sur la maîtrise du risque de double traitement. Si une solution de continuité est utilisée, identifiez clairement qu’il s’agit de la même facture et organisez la réconciliation avant tout nouvel envoi électronique. Gardez au minimum le message de rejet, sa cause, la correction appliquée, la facture régularisée, les références de réémission, les échanges avec la plateforme ou le client, l’owner et les horodatages. Cette traçabilité permet d’expliquer ce qui s’est passé et de démontrer les actions correctrices. Elle ne transforme pas pour autant un incident documenté en garantie réglementaire, en preuve de transmission ou en report général des obligations.
- Éviter deux versions actives de la même facture dans les circuits de paiement et de comptabilisation.
- Relier chaque correction à son rejet d’origine et au statut de la nouvelle tentative.
- Conserver les preuves d’incident et de correction sans présenter InvoiceBatch FR comme une Plateforme Agréée ou une certification.
Étape suivante
Passer du guide à une vérification concrète.
InvoiceBatch FR reste un preflight technique de corpus : il ne remplace pas votre ERP ou votre Plateforme Agréée et ne constitue ni une certification ni une preuve de transmission.
Pré-valider un corpus avant réémission (EN)Sources officielles
Ces sources cadrent les affirmations réglementaires de cette page. Les contrats et API d’une PA réelle doivent en plus être vérifiés auprès du fournisseur concerné.