01
D’abord : rejet technique ou facture réellement à rectifier ?
Si la plateforme rejette un document parce qu’un contrôle technique ou une donnée bloque, commencez par qualifier ce rejet et corriger la cause dans le système source ou le mapping. Ne créez pas automatiquement un avoir simplement parce qu’un fichier n’a pas passé un contrôle. En revanche, lorsque la facture elle-même doit être annulée, réduite ou remplacée après son entrée dans le cycle métier, la question devient celle du document correctif à émettre. Gardez le statut exact, le motif, la facture d’origine et la décision de correction ensemble afin que l’équipe finance, l’ERP et la plateforme parlent du même événement.
- Rejet technique : corriger la cause et suivre la procédure de retransmission de la PA.
- Erreur métier ou commerciale : déterminer si un avoir ou une facture rectificative est approprié.
- Ne jamais transformer un simple échec de validation en deuxième opération comptable par automatisme.
02
Avoir ou facture rectificative : ce que décrit la DGFiP
Les spécifications externes de la DGFiP indiquent que deux mécanismes peuvent servir à annuler partiellement ou totalement une facture : l’avoir et la facture rectificative. Lorsque le destinataire a refusé la facture, le fournisseur peut émettre un avoir ou une facture rectificative qui annule et remplace la précédente. Lorsque la facture est encore en cours hors statut « Refusée », les spécifications distinguent aussi le stade de paiement : avant le statut « paiement transmis », un avoir ou une facture rectificative peuvent être envisagés ; à partir de ce statut, le mécanisme décrit est l’avoir. Vérifiez toutefois la version du contrat et du workflow de votre Plateforme Agréée avant d’automatiser cette décision.
- Refus du destinataire : relier le document correctif à la facture refusée et conserver le motif.
- Avant « paiement transmis » : contrôler le workflow PA avant de choisir rectificative ou avoir.
- À partir de « paiement transmis » : les spécifications DGFiP décrivent l’émission d’un avoir.
03
Relier la correction à l’original sans perdre la chaîne de preuve
Quel que soit le mécanisme retenu, conservez une chaîne explicite entre la facture initiale et le document correctif : numéro et date de l’original, motif de correction, montant ou lignes affectés, identifiant du nouveau document, statut de transmission et résultat externe. Cette chaîne doit être visible dans l’ERP et dans les éléments de preuve de l’incident afin d’éviter qu’une facture annulée et sa correction restent toutes deux actives. Pour un avoir, gardez également le traitement TVA correspondant dans votre processus comptable ; la DGFiP maintient une fiche dédiée aux régularisations liées aux factures d’avoir.
- Conserver une référence explicite à la facture d’origine et le motif de la correction.
- Réconcilier facture initiale, document correctif, statut externe, comptabilisation et paiement.
- Éviter toute logique qui laisse deux créances ou deux dettes actives pour la même correction.
04
Pré-valider le document correctif avant transmission
Après avoir décidé du traitement comptable et métier approprié, re-générez le document structuré à partir de la source corrigée puis contrôlez un échantillon représentatif avant transmission. InvoiceBatch FR peut aider sur ce périmètre technique borné : comparer l’entrée ERP, le mapping et la sortie UBL, CII ou Factur-X, regrouper les erreurs récurrentes et conserver les résultats de pré-validation. Il ne choisit pas à votre place entre avoir et facture rectificative, ne remplace pas votre comptable ou conseil fiscal, n’est pas une Plateforme Agréée et ne transforme pas une validation locale en preuve d’acceptation ou de remise externe.
- Corriger dans la source ou le mapping qui produit le document, pas seulement dans un PDF final.
- Pré-valider les cas représentatifs avant une réémission en volume.
- Suivre ensuite le statut externe de la correction au lieu de déduire le succès du contrôle local.
É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 le document corrigé (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é.