Codes de retour ACH : la référence complète R01-R85, vérifiée sur les sources officielles

Qu'est-ce qu'un code de retour ACH ?

Un code de retour ACH est un code de trois caractères que la banque du destinataire (RDFI) inscrit dans un enregistrement addenda de type 99, aux positions 4 à 6, pour indiquer à l'émetteur pourquoi une entrée a été renvoyée. Il en existe officiellement exactement 70 : R01 à R47, R50 à R53, R61, R62, R67 à R77, et R80 à R85. Des codes comme R63, R64, R65 et R66 sont largement publiés sur le web mais ne sont pas du tout des codes de retour — ce sont les sous-codes d'addenda de R69, « Field Error(s) ». La vraie question à laquelle un code répond est de savoir si vous pouvez réémettre l'entrée : un retour pour absence d'autorisation (R05, R07, R10, R29, R51) ne peut pas être réémis sans une nouvelle autorisation, tandis que R11 — pourtant un code d'absence d'autorisation — peut être corrigé et renvoyé.

Validez votre fichier maintenant

Gratuit, instantané et 100 % dans votre navigateur - aucun fichier n'est jamais envoyé.

Ouvrir le ACH / NACHA Validator

Où le code se trouve réellement dans le fichier

Un retour n'est pas un message que vous recevez à côté du paiement. C'est une entrée, à l'intérieur d'un fichier ACH, porteuse d'un enregistrement addenda de type 99. Le code se trouve aux positions 4 à 6 de cet enregistrement de 94 caractères — c'est pourquoi un retour se parse, il ne se lit pas dans un e-mail.

799R01 091000010000001      091000019100001...
 │ │  └── positions 4-6: the return reason code
 │ └───── positions 2-3: addenda type 99 = a return
 └─────── position 1: record type 7 = addenda

Deux conséquences que l'on comprend souvent de travers, et toutes deux coûteuses. Un retour est une vraie entrée : l'argent revient. Une Notification of Change, addenda de type 98, est une entrée à zéro dollar : le paiement est passé, et la banque vous demande de corriger votre donnée pour la prochaine fois. Traiter un NOC comme un paiement échoué et le renvoyer paie deux fois la même facture.

Et les champs d'un retour ne sont pas réécrits. Nacha indique que chaque champ d'un retour ou d'un NOC reste inchangé par rapport à l'entrée d'origine. Il n'existe pas de code SEC « RET » ; le Company Entry Description ne devient pas « RETURN » ni « SOFTWARE ». Les vrais fichiers de retour portent ce que portait l'original — « TRANSFER », « Vendor Pay ». Un parseur qui cherche ces marqueurs ne trouvera rien, et conclura, à tort, que le fichier n'est pas un retour.

Les codes qui comptent vraiment

Sur soixante-dix, une poignée représente l'écrasante majorité des retours — et la Federal Reserve les regroupe pour vous, nommément, dans son propre ACH Return Reason Report.

R01 — Insufficient Funds

Le compte est valide et ouvert ; l'argent n'était simplement pas là au moment de la comptabilisation. Le retour arrive dans les deux jours ouvrés bancaires. C'est aussi l'un des rares codes que vous pouvez réémettre, dans les conditions posées par les règles Nacha : Company Name, Company ID et montant identiques, et « RETRY PYMT » dans le Company Entry Description.

R02, R03, R04 — ce que la Fed elle-même appelle les Invalid/Admin Returns

Compte clôturé ; compte inexistant ou introuvable ; numéro de compte invalide. Ce sont des problèmes de donnée, pas des problèmes d'argent : votre enregistrement du compte du client est faux, et réémettre la même entrée échouera de la même façon. Corrigez le mandat, pas le calendrier.

R05, R07, R10, R11, R29, R51 — le groupe Unauthorized Returns de la Fed

C'est le groupe qui porte le risque réglementaire, car un taux de retours pour absence d'autorisation supérieur au seuil Nacha met en jeu votre capacité même à émettre. C'est aussi le groupe où réémettre n'est pas une nouvelle tentative mais une violation des règles — à la seule exception de R11, ci-dessous.

R14 et R15 — un décès

Le mandataire ou le titulaire du compte est décédé. Ce sont les deux seuls codes qui portent une Date of Death, aux positions 22 à 27 de l'addenda 99. Sur tous les autres codes de retour, ce champ est vide — et un parseur qui le lit quand même produira une date sortie de nulle part.

Les mythes — et l'un d'eux était le nôtre

Cette section existe parce que le contenu gratuit sur les codes de retour ACH est, par endroits, tout simplement faux, et que les erreurs sont reprises par de grandes sociétés de paiement réputées. Nous avons revérifié les soixante-dix codes contre le guide de mapping ISO 20022 de Nacha, l'ACH Return Reason Report de la Federal Reserve et le Green Book du Trésor américain. Quatre constats.

R63, R64, R65 et R66 ne sont pas des codes de retour

La liste officielle passe de R62 directement à R67 — aussi bien dans le guide de Nacha que dans le rapport de la Fed. Ce qui est publié comme « R63 — Incorrect Dollar Amount » est en réalité le sous-code 03 de l'addenda R69, tel que le Green Book l'imprime. Si vous avez construit une table de correspondance à partir d'une page d'éditeur, elle contient quatre codes qui n'arriveront jamais, et il lui manque le mécanisme qui les produit.

R11 n'est pas une « Checksum Abbreviation Error »

La page publique de Stripe l'affirme. C'est faux, et cela inverse le conseil. R11 signifie que le client déclare que le prélèvement n'était pas conforme aux termes de l'autorisation — mauvais montant, prélèvement trop tôt. Depuis 2020, c'est le seul code d'absence d'autorisation que vous pouvez corriger : corrigez l'erreur sous-jacente et envoyez une nouvelle entrée dans les 60 jours suivant la date de règlement du retour, sans nouvelle autorisation.

R85 n'est pas un code IAT

R80 à R84 s'appliquent aux entrées IAT sortantes. Le périmètre de R85, dans la table de Nacha elle-même, est tout code SEC SAUF IAT : c'est une entrée codée comme domestique que la passerelle reconnaît comme un paiement international sortant, qui aurait dû être une IAT dès le départ. Regrouper R80-R85 sous « les codes IAT » prend précisément à l'envers celui qui compte.

R44 existe — et c'est nous qui nous trompions

« Invalid Individual ID Number », pour les entrées ENR. Il figure dans le guide de Nacha et dans le rapport de la Fed. Nous l'avions délibérément laissé de côté sur ce site, parce que les pages d'éditeurs d'où nous le tenions se contredisaient — nous avons pris l'absence de source fiable pour l'absence de code. Il est publié désormais, et cette page existe en partie pour le dire.

R69, « Field Error(s) », ne nomme pas le champ fautif dans le code. Il le nomme dans l'addenda, sous la forme d'un sous-code à deux chiffres — et cette liste est toute la raison pour laquelle R63-R66 semblent réels à qui les a vus hors contexte (source : Green Book, domaine public) :

01Return contains incorrect DFI Account Number
02Return contains incorrect Original Entry Trace Number
03Return contains incorrect dollar amount
04Return contains incorrect Individual Identification Number / Identification Number
05Return contains incorrect Transaction Code
06Return contains incorrect Company Identification Number
07Return contains an invalid Effective Entry Date

Les 70 codes de retour ACH

Regroupés par sujet, les plus fréquents d'abord. Chaque code renvoie à sa propre page : ce qu'il signifie, ce qui le provoque, le délai de retour lorsqu'une source officielle en indique un, et si vous pouvez réémettre l'entrée. Cette table est générée à partir des mêmes données que celles qu'utilise notre validateur : elle ne peut donc pas s'écarter de l'outil.

Provision

Compte

Autorisation & contestations

Données & format

Routage

Administratif

Autres

Codes qui n'existent pas, quoi qu'en dise un résultat de recherche : R48, R49, R54 à R60, R63 à R66, R78, R79, et tout ce qui est au-delà de R85. Un nouveau code arrive : R90, « Entry Returned Due to RDFI's Sanctions Compliance Obligations », entre en vigueur le 17 mars 2028 — et le même jour, R16 perd sa moitié OFAC et retrouve le seul sens « Account Frozen ».

Que faire quand un retour arrive

Dans l'ordre. Les deux premières étapes prennent une minute, et ce sont les deux qui évitent les erreurs coûteuses.

1Lisez les positions 4 à 6 de l'addenda 99. C'est ça, le code — pas le libellé que le portail de votre banque a décidé d'y coller.
2Posez la seule question qui compte vraiment : est-ce un retour pour absence d'autorisation ? R05, R07, R10, R29 et R51 ne peuvent pas être réémis. Renvoyer l'entrée n'est pas une nouvelle tentative, c'est une violation des règles.
3S'il s'agit de R11, vous pouvez corriger et renvoyer — dans les 60 jours suivant la date de règlement du retour, sans nouvelle autorisation. C'est l'exception à la règle ci-dessus, et elle vaut de l'argent bien réel.
4S'il s'agit de R69, ouvrez l'addenda. Le sous-code à deux chiffres vous indique quel champ l'ODFI juge erroné, et il y en a sept.
5S'il s'agit de R01 ou R09, la réémission est permise par les règles Nacha : Company Name, Company ID et montant doivent être identiques, et « RETRY PYMT » doit figurer dans le Company Entry Description. Les règles plafonnent aussi le nombre de fois et la durée — ces chiffres exacts ne sont publiés que dans le rulebook payant, et nous ne citons pas de nombres que nous ne pouvons pas sourcer.

Validez ensuite le fichier corrigé avant de l'envoyer. Un second retour sur la même entrée n'est pas gratuit, et sur les codes d'absence d'autorisation il n'est même pas permis.

Validez un fichier ACH avant qu'il ne revienne

Déposez un fichier NACHA dans le validateur : structure des enregistrements, chiffres de contrôle ABA, entry hash, totaux de contrôle du batch et du fichier — et les addenda décodés, y compris les retours (99), les notifications de changement (98) et l'IAT (10 à 18). Tout s'exécute dans votre navigateur ; le fichier ne quitte jamais votre machine.

Ouvrir le validateur ACH

Sources officielles — et ce que nous refusons de dire

Le livre des Nacha Operating Rules est protégé par le droit d'auteur et vendu. Nous ne l'avons pas acheté et nous n'en reproduisons pas le texte. Tout ce qui figure sur cette page est vérifié contre des publications officielles gratuites : le guide de mapping ISO 20022 de Nacha, qui porte la table complète des codes ; l'ACH Return Reason Report de la Federal Reserve, qui énumère les codes qu'elle traite avec et sans activité — ce qui le rend décisif sur la question des codes qui existent ; et le Green Book du Trésor américain, qui est dans le domaine public. Là où seul le rulebook payant énonce un chiffre — les délais des retours contestés et refusés, les limites exactes de réémission — cette page dit que la règle existe et n'invente pas le nombre.

Questions fréquemment posées

Combien y a-t-il de codes de retour ACH ?

Soixante-dix. R01 à R47, R50 à R53, R61, R62, R67 à R77, et R80 à R85. Le guide de mapping ISO 20022 de Nacha et l'ACH Return Reason Report de la Federal Reserve listent le même ensemble, et le rapport de la Fed est décisif parce qu'il énumère les codes qu'elle traite avec et sans activité — un code absent de ce rapport est un code qui n'existe pas.

R63 est-il un vrai code de retour ACH ?

Non. R64, R65 et R66 non plus. La liste officielle passe de R62 directement à R67. Ce qui est publié ailleurs comme « R63 — Incorrect Dollar Amount » est le sous-code 03 de l'addenda attaché à R69, « Field Error(s) ». La confusion se comprend — la liste des sous-codes se lit exactement comme une liste de codes de retour — mais un R63 n'arrivera jamais dans votre fichier.

Quelle est la différence entre R10 et R11 ?

Les deux sont des retours pour absence d'autorisation et les deux portent un délai de 60 jours. R10 signifie que le client déclare que le prélèvement n'était pas autorisé du tout. R11 signifie que le client déclare que le prélèvement n'a pas suivi les termes d'une autorisation qui, elle, existe bien — un mauvais montant, un prélèvement pris trop tôt. La différence pratique est décisive : avec R11, vous pouvez corriger l'erreur et envoyer une nouvelle entrée dans les 60 jours suivant la date de règlement du retour, sans obtenir de nouvelle autorisation. Avec R10, vous ne le pouvez pas.

Puis-je réémettre une entrée qui a été retournée ?

Cela dépend entièrement du code. R01 et R09 (provision) peuvent être réémis dans les conditions des règles Nacha, avec des Company Name, Company ID et montant identiques et « RETRY PYMT » dans le Company Entry Description. Les codes d'absence d'autorisation — R05, R07, R10, R29, R51 — ne le peuvent pas : ils exigent une nouvelle autorisation, et les renvoyer est une violation des règles. R11 est l'exception : corrigez et renvoyez dans les 60 jours, sans nouvelle autorisation.

Où se trouve le code de retour dans un fichier ACH ?

Dans un enregistrement addenda de type 99, aux positions 4 à 6 de l'enregistrement de 94 caractères. La position 1 est le type d'enregistrement (« 7 » pour un addenda), les positions 2 et 3 sont le code de type d'addenda (« 99 » pour un retour). Les positions 22 à 27 portent une Date of Death, mais uniquement sur R14 et R15 — sur tout autre code, ce champ est vide.

Quelle est la différence entre un retour et une Notification of Change ?

Un retour (addenda 99) renvoie l'argent : le paiement a échoué. Une Notification of Change (addenda 98) est une entrée à zéro dollar : le paiement a réussi, et la banque du destinataire vous indique qu'une de vos données — un numéro de compte, un routing number, un code de transaction — doit être corrigée pour la prochaine fois. Renvoyer un NOC comme un paiement paie deux fois la même facture.

De combien de temps une banque dispose-t-elle pour retourner une entrée ACH ?

Deux jours ouvrés bancaires est la norme administrative : le Green Book indique qu'un retour doit être reçu à l'ouverture du deuxième jour ouvré bancaire suivant la date de règlement de l'entrée d'origine. Les prélèvements non autorisés sur un compte de particulier bénéficient d'un délai étendu de 60 jours calendaires. Les délais exacts des retours refusés et contestés ne sont publiés que dans le rulebook Nacha payant — nous ne citons pas de chiffres que nous ne pouvons pas sourcer, et R68 « Untimely Return » et R72 « Untimely Dishonored Return » existent précisément pour sanctionner un délai dépassé.

Un nouveau code de retour ACH arrive-t-il ?

Oui. R90, « Entry Returned Due to RDFI's Sanctions Compliance Obligations », entre en vigueur le 17 mars 2028. Le même jour, R16 perd la moitié OFAC de son sens et redevient le seul « Account Frozen ». Aucun de ces deux changements n'est en vigueur aujourd'hui, et R90 n'existe pas encore dans le réseau.