ACH (Automated Clearing House) 送金は、企業や個人が電子的に資金を送金したり受け取ったりする一般的な方法です。2022 年には、300 億件の ACH 送金が行われ、その総額は 76 兆ドルを超えました。この決済手段は非常に便利で、コスト効率がよく、一般的になりましたが、ACH 送金の拒否は引き続きよく発生しています。

ACH 送金を処理できない場合、ACH ネットワークによって、送金が完了しなかった理由を示す「拒否コード」または「リターンコード」が返されます。それらには、単に口座番号が間違っているというような簡単な理由や、金融機関がこの種の取引に課す規則と規制のような複雑な理由もあります。

ACH 拒否が発生した場合に事業者にとって重要なのは、今後問題が発生することを防ぎ、利用者の信頼と満足度を維持するために、何が問題となったかを把握することです。以下に、さまざまな種類の拒否コード、拒否の原因、それらを防止する方法、および発生した場合の対処方法を示します。

この記事の内容

• ACH 送金とは
  
• ACH 拒否コードとは
  
• ACH 拒否が起こる原因
  
• ACH 拒否コードのリスト
  
• 事業者での ACH 拒否への対処方法
  

ACH 送金とは

ACH (Automated Clearing House) 送金は、異なる金融機関の間で資金を移動させる電子送金の一種です。これらの取引は通常、アメリカの Nacha (National Automated Clearing House Association の短縮語) が定めた規則に従って一括で処理されます。

ACH 送金は、信頼性とコスト効率が高く、さまざまな用途で利用できる決済手段であり、アメリカの企業によって広く受け入れられています。一定の制限はありますが、メリットの方がデメリットを上回ります。特に、業務効率とコスト管理に関してそう言えます。以下に、ACH 送金について知っておくべき重要な点を示します。

ACH 送金の特徴

• コスト効率の高さ: ACH 送金では、電信送金やクレジットカード取引よりもコストを抑えられます。運営経費の削減を目指す事業者は、この理由から ACH 送金をよく選びます。

• 汎用性: この送金方法は、給与の口座振込、サブスクリプションのような継続支払い、ベンダーへの支払いなど、さまざまな用途で使用できます。

• 一括処理: リアルタイムの取引とは異なり、ACH 送金は通常一括で処理されます。このため、売上処理に時間 (一般的に最大 3 営業日) がかかることが多くなっています。

• 種類: ACH 送金は、ACH デビットと ACH クレジットの決済に分けることができます。ACH デビットでは、事前に承認されている場合に、事業者が別の口座から資金を引き出すことができます。ACH クレジット決済は、事業者による口座への入金を可能にします。また、給与やベンダーへの支払いによく使用されています。

事業者にとって重要な点

• 非常に効率の良い決済手段である
  ACH 送金の一括処理により、取引が売上として処理される時間がわかるため、事業者はより効果的に財務アクティビティを計画することができます。

• 決済に関する規制に準拠している
  Nacha が定める規約に準拠することで、不正利用や不審請求の申請のリスクを最小限に抑え、一貫した安全な体験が保証されます。

• 財務予測の精度が向上する
  ACH 送金は、予測しやすく、コストを抑えられるため、現金管理を向上させることができます。事業者は、利用可能なリソースを最適化することで、より正確に財務について予測することができます。

• 柔軟な決済戦略と互換性がある
  ACH 決済を受け付けることで、事業者はクレジットカードの使用を好まない利用者をより惹きつけることができ、両者にとってメリットの多い代替手段となります。

制限事項

• 処理に時間がかかる
  ACH 送金の欠点の 1 つは、売上処理に時間がかかることです。数日かかることがあり、売上を迅速に受け取る必要がある事業者にとって問題になる可能性があります。

• 残高不足のリスク
  ACH デビットでは、支払人の口座に十分な資金がない場合に処理されない可能性があり、支払いの遅延や追加料金が発生する恐れがあります。

• エラーの解決が複雑になる場合がある
  ACH 送金は自動化され、一括処理されるため、エラーの解決に他の支払い方法より時間がかかったり、複雑な作業を要したりすることがあります。

ACH 拒否コードとは

ACH 拒否コードは、ACH 取引で処理に失敗した理由を示す英数字のメッセージです。これらのコードは、特定の ACH 送金で何がうまくいかなかったかを示し、事業者や金融機関が是正措置を取れるようにします。

ACH 拒否が起こる原因

ACH 拒否はさまざまな理由で発生する可能性がありますが、それらの理由は、管理上のエラー、承認の問題、財務上の不備、タイミングと処理の制約、リスク管理と規制の遵守の 5 つのカテゴリーに分類できます。それぞれのカテゴリーに固有の一連の課題があり、特定の解決策が必要です。ACH 拒否が起こる理由について、以下に詳細を示します。

管理上のエラー

• 口座情報の誤り: ACH 拒否の理由で最も一般的なものの 1 つは、口座番号や金融番号の誤りです。もし口座番号または金融番号のいずれかが間違っていれば、送金は行われません。

• 口座が解約されている、または存在しない: もし口座が解約されたり、そもそも存在していなかったりした場合、ACH 取引は R02 または R03 などの特定のコードで拒否されます。

• 口座の種類の不一致: 一部の ACH 取引では、法人口座や貯蓄口座など、特定の種類の口座が必要とされます。もし不一致が生じた場合、送金は行われません。

承認の問題

• 事前承認の欠如: ACH デビットを処理するためには、通常、口座名義人が事前に承認を行う必要があります。このような承認が行われていないと、取引は拒否されます。

• 承認の取り消し: 時々、利用者やビジネスパートナーが以前に付与したデビットの承認を取り消すことがあります。そのような場合、その後の ACH 取引はすべて拒否されます。

• 企業による承認に対する申し立て: 企業取引の状況下では、一方の企業体が ACH デビットまたはクレジットの承認がされていないと指摘した場合、取引にフラグが立てられ、拒否されます。

財務上の問題

• 資金不足: ACH 拒否のもっとも単純な理由の 1 つは、引き落とされる口座に十分な資金がないことです。これにより R01 がトリガーされます。

• 未回収の資金: 口座に資金があっても、それがまだ処理されていない、または回収されていない資金である場合があります。この場合、R09 の拒否コードが返されます。

• 支払い停止指示: 口座名義人は特定の取引に対して支払い停止指示を発行する権利を持っています。そのような指示が出された場合、該当する ACH デビットは拒否されます。

タイミングと処理の制約

• 古いエントリーや期限切れのエントリー: ACH 取引では、処理が可能な期間に制限が設けられることがあります。送金があまりに遅くなると、拒否される場合があります。

• 取引制限の超過: 個人口座と事業者の両方で、送金可能な金額に関して異なる制限が設定されている場合があります。Nacha は 2022 年に、ACH 同日決済の上限を 1 回の支払いにつき 100 万ドルに引き上げました。これらの限度額を超えた場合、取引は拒否されます。

• 送金元の問題: 問題が受取口座ではなく、送金元となる金融機関 (ODFI) にあることがあります。もしそれらの金融機関が何らかの理由でエントリーの差戻しを要求した場合、その取引は完了しません。

リスク管理と規制の遵守

• 不正利用の疑い: 金融機関は継続的に疑わしいアクティビティをモニタリングしています。ACH 取引に潜在的な不正利用のフラグが立てられると、未承認の取引を防ぐために取引は拒否されます。

• 規制の不遵守: Nacha のガイドラインや他の規制基準に準拠していない場合にも、取引が拒否される可能性があります。これには、エンドツーエンドの暗号化が行われていないことや、2 段階認証プロトコルに従っていないことが含まれます。

これらの理由を把握すると、事業者や金融機関で ACH 取引プロセスの微調整、トラブルシューティングの改善、問題の迅速な解決や円滑な運営を行えるようになります。

ACH 拒否コードのリスト

銀行振込を決済手段として受け付けている場合、ACH 拒否コードやリターンコードを受け取ることは避けられないものです。特定のコードについて扱う前に、いくつかの重要な用語について説明します。

• エントリー: ACH 取引の送信
  
• 差戻し: エントリーが処理のために受け入れられた後、ODFI に差戻された場合
  
• 拒否: エントリーが最初から ACH ネットワークに処理のために受け入れられなかった場合
  
• ODFI: ACH 取引を送信する、送金元となる金融機関
  
• RDFI: ACH 取引を受信する、送金先となる金融機関
  

すべての ACH 拒否コードと、それらが意味すること、その原因、および求められるアクションについてのリストを以下に示します。

R01 - 残高不足

• 説明: 口座に取引を成立させる十分な資金がありません。
  
• 防止策: 定期的に口座残高を確認し、残高が低下した際のアラートを設定します。
  
• アクション: 問題を解決するために口座名義人に連絡し、資金が入金されたら取引を送信します。
  

R02 - 解約された口座

• 説明: 送信先になっている口座が口座名義人によって解約されました。
  
• 防止策: 取引を開始する前に、口座のステータスを確認します。
  
• アクション: 口座名義人から新しい口座情報を入手し、記録を更新します。
  

R03 - 口座がない / 口座が見つからない

• 説明: 口座番号または経路の選定情報が RDFI の口座と一致しません。
  
• 防止策: 取引を開始する前に、口座番号を確認します。
  
• アクション: 受取人に正しい口座情報を指定するように求めます。
  

R04 - 無効な口座番号

• 説明: 取引に指定された口座番号が正しくありません。理由としては、数字に誤りがある、デジタル検証をパスしない、RDFI の口座番号と一致しないなどが挙げられます。
  
• 防止策: あらかじめ定義された形式に照らし合わせて口座番号を検証します。
  
• アクション: 正しい口座番号を取得し、再送信します。
  

R05 - 法人の SEC コードを使用して個人口座に未承認の引き落としがされた

• 説明: 法人の Standard Entry Class (SEC) コードが誤って個人口座に使用されました。
  
• 防止策: 取引の種類に適した SEC コードを使用していることを確認します。
  
• アクション: SEC コードを修正し、取引を再送信します。
  

R06 - ODFI のリクエストによる差戻し

• 説明: さまざまな理由により、ODFI が取引を差戻しました。
  
• 防止策: 送信前に取引の詳細を確認します。
  
• アクション: ODFI と連絡を取り、問題を特定して、次の手順を判断します。
  

R07 - 利用者によって承認が取り消された

• 説明: 利用者が取引の承認を取り消しました。
  
• 防止策: 承認状況を最新の状態に保ち、利用者とのコミュニケーションをとります。
  
• アクション: 新たに承認されない場合は、再送信しないでください。
  

R08 - 支払い停止

• 説明: 口座名義人がこの特定の取引に対して支払い停止の指示を出しました。このコードは、ほとんどの支払い停止の一般的な指示ですが、ソースドキュメントまたは RCK エントリー (再提示された小切手のエントリー、または不渡り小切手) の停止を除きます。これらについては、後程紹介する個別のコードがあります。
  
• 防止策: 口座名義人に承認と決済の詳細について確認を取ります。
  
• アクション: 口座名義人に連絡を取り、問題を解決します。
  

R09 - 未回収の資金

• 説明: 口座にまだ処理されていない資金がある可能性があります。それが原因で取引に対して残高不足が生じています。
  
• 防止策: 資金が処理されるスケジュールに注意してください。
  
• アクション: 資金が回収された後に再送信してください。
  

R10 - 利用者による不承認の通知

• 説明: 取引が承認されなかったことを利用者が通達してきました。
  
• 防止策: 取引を開始する前に、適切な承認が行われるようにします。
  
• アクション: 新しい承認が得られないまま、再送信しないでください。
  

R11 - チェックトランケーションエントリーの差戻し

• 説明: 銀行のポリシーに基づくさまざまな理由でトランケーション (小切手現金化) エラーが発生しました。
  
• 防止策: トランケーションを行う前に小切手の詳細を確認します。
  
• アクション: 銀行に詳細について相談し、必要に応じて再処理してください。
  

R12 - 口座が別の RDFI に売却済み

• 説明: 利用者が銀行を変更し、口座が別の RDFI に移行されました。
  
• 防止策: 口座情報を定期的に更新します。
  
• アクション: 新しい銀行口座の詳細を利用者から入手し、記録を更新します。
  

R13 - 無効な ACH 金融番号

• 説明: ACH 金融番号が正しくありません。
  
• 防止策: 取引を開始する前に、金融番号を確認します。
  
• アクション: 金融番号を更新して再送信します。
  

R14 - 代表受取人が死去または職務継続不可

• 説明: 代表受取人が死去したか、職務を継続できなくなりました。
  
• 防止策: 代表受取人とそのステータスを継続的に追跡します。
  
• アクション: 新しい代表受取人の情報を入手し、記録を更新します。
  

R15 - 受取人または口座名義人が死去

• 説明: 受取人または口座名義人が死去しました。
  
• 防止策: 口座名義人と受取人の情報を定期的に更新します。
  
• アクション: 取引を停止し、相続人または新しい口座名義人と相談します。
  

R16 - 口座の凍結

• 説明: 法的措置または銀行のポリシーにより口座が凍結されています。
  
• 防止策: 口座に関する法的な問題を追跡します。
  
• アクション: 詳細と解決策を得るために金融機関に連絡します。
  

R17 - ファイルレコードの編集基準

• 説明: エントリーに無効なフォーマットやデータが含まれており、取引が疑わしい状況で開始されたと RDFI が判断する可能性があります。
  
• 防止策: 送信する前に、エントリーの各フィールドを確認します。
  
• アクション: エントリーを修正して再送信します。
  

R18 - エントリーの効力発生日が間違っている

• 説明: 間違ったエントリーの効力発生日に取引が開始されました。エントリーの効力発生日とは、ODFI が取引の実行を希望している日付です。
  
• 防止策: 送信する前に、エントリーの効力発生日を確認します。
  
• アクション: 日付を修正して再送信します。
  

R19 - 金額フィールドのエラー

• 説明: 金額フィールドに入力された金額が無効です。
  
• 防止策: 送信する前に金額を確認します。
  
• アクション: 金額を修正して再送信します。
  

R20 - 非取引口座

• 説明: ポリシーまたは規制によって、この口座での ACH 取引が制限されています。
  
• 防止策: 取引を開始する前に、口座の種類を確認します。
  
• アクション: 別の支払い方法または口座を使用してください。
  

R21 - 無効な企業 ID

• 説明: 企業 ID 情報が正しくないか、情報が古くなっています。誤った入力が原因であることがよくあります。
  
• 防止策: 取引を開始する前に、企業 ID を確認します。
  
• アクション: 企業 ID を更新し、再送信します。
  

R22 - 無効な個人 ID 番号

• 説明: 入力された個人 ID (通常は利用者が利用者の ID フィールドに入力) が無効です。
  
• 防止策: 取引を開始する前に、個人 ID 番号を確認します。
  
• アクション: 個人 ID 番号を更新して再送信します。
  

R23 - 受取側によるクレジットエントリーの拒否

• 説明: 取引の受取側となる金融機関 (RDFI) がクレジットエントリーを拒否しました。おそらく、異議申し立てまたは合意に至っていないことが原因と思われます。
  
• 防止策: RDFI との取引条件を確認します。
  
• アクション: RDFI との間で問題を解決し、適宜処理します。
  

R24 - エントリーの重複

• 説明: 同じ取引が複数回送信されました。
  
• 防止策: 取引が重複しないようにしっかり管理します。
  
• アクション: 本当に重複している正しい処理であるか確認し、適切な措置を取ります。
  

R25 - 追記エラー

• 説明: 口座名義人を識別したり、RDFI に支払い情報を提供したりする追記レコードの内容が正しくないか、順序が間違っています。
  
• 防止策: 送信する前に、追記レコードを確認します。
  
• アクション: 追記レコードを修正して再送信します。
  

R26 - 必須フィールドのエラー

• 説明: 不完全なデータ入力が原因で、必須フィールドの情報が不足しています。これにより、ACH オペレーターが取引を拒否することがあります。
  
• 防止策: すべての必須フィールドが入力されていることを確認します。
  
• アクション: 未入力のフィールドに入力し、再送信します。
  

R27 - 追跡番号エラー

• 説明: 送信された追跡番号が、追記レコードの追跡番号と一致していません。
  
• 防止策: 送信する前に、追跡番号を確認します。
  
• アクション: 追跡番号を修正して再送信します。
  

R28 - 金融番号のチェックデジットエラー

• 説明: チェックデジット (金融番号の最後の桁) が正しくありません。
  
• 防止策: 金融番号とそのチェックデジットを確認します。
  
• アクション: チェックデジットを修正して再送信します。
  

R29 - 法人顧客による不承認の通知

• 説明: 法人の口座名義人が、取引を承認しないことを RDFI に通知しました。
  
• 防止策: 取引を開始する前に、適切な承認が行われるようにします。
  
• アクション: 新しい承認が得られないまま、再送信しないでください。
  

R30 - RDFI がチェックトランケーションプログラムに参加していない

• 説明: RDFI がチェックトランケーションプログラムに参加していません。
  
• 防止策: RDFI のケイパビリティを確認します。
  
• アクション: 別の決済方法を使用してください。
  

R31 - 許容できる差戻しエントリー

• 説明: RDFI が ODFI にコーポレートクレジット、デビットカード、または Corporate Trade Exchange (CTX) 決済方式の差戻しを依頼し、ODFI が同意しました。
  
• 防止策: 双方の合意に基づいているため、該当しません。
  
• アクション: ODFI と RDFI の間での合意によって設けられたガイドラインに従います。
  

R32 - RDFI で売上処理ができない

• 説明: さまざまな理由により、RDFI でエントリーを売上として処理できません。
  
• 防止策: RDFI の売上処理能力を確認します。
  
• アクション: 具体的な理由について RDFI に尋ね、適切な対応を取ります。
  

R33 - XCK エントリーの差戻し

• 説明: RDFI が紛失、破損、損傷した小切手 (XCK エントリー) を差戻しました。
  
• 防止策: 小切手が差戻される条件 (紛失または損傷) を把握します。
  
• アクション: 小切手を処理できない理由を調べ、適宜次の手順を実施します。
  

R34 - DFI の関与の制限

• 説明: 連邦または州の規制当局が、RDFI の ACH 取引に関する処理能力を制限しました。
  
• 防止策: 事前に RDFI のケイパビリティについて確認します。
  
• アクション: 処理を進める方法について RDFI と協議します。
  

R35 - 不適切なデビットエントリーの差戻し

• 説明: 一部のシナリオでは許可されていないにもかかわらず、デビットエントリーが不適切に送信されました。
  
• 防止策: 適切なデビットエントリーの基準を理解します。
  
• アクション: 理由について調べ、再送信する前に修正します。
  

R36 - 不適切なクレジットエントリーの差戻し

• 説明: 一部のシナリオでは許可されていないにもかかわらず、クレジットエントリーが不適切に送信されました。
  
• 防止策: 適切なクレジットエントリーの基準を理解します。
  
• アクション: 理由について調べ、再送信する前に修正します。
  

R37 - 支払いのソースドキュメントが提出済み

• 説明: 支払いに関する既存の ACH 取引に関連したソースドキュメントが提出されて、重複した支払い処理が試行されました。
  
• 防止策: ソースドキュメントと関連する ACH エントリーを追跡します。
  
• アクション: 重複について調べ、修正します。
  

R38 - ソースドキュメントの支払い停止

• 説明: 受取側の口座名義人が、電子決済に変換された小切手の支払い停止をリクエストしました。
  
• 防止策: 支払い停止の指示をモニタリングします。
  
• アクション: 処理を停止し、口座名義人に問い合わせます。
  

R39 - 不適切なソースドキュメント

• 説明: ACH 決済に関するソースドキュメントに誤りがあるか、不適切な点があります。
  
• 防止策: エントリーを作成する前に、ソースドキュメントを確認します。
  
• アクション: ソースドキュメントを差し替えるか、修正します。
  

R40 - 連邦政府機関による ENR エントリーの差戻し

• 説明: 連邦政府機関が自動登録エントリー (ENR エントリー) を差戻しました。
  
• 防止策: ENR エントリーに関する規則を遵守します。
  
• アクション: 具体的な理由について当局に尋ね、適切な対応を取ります。
  

R41 - 無効な取引コード

• 説明: 取引コードが間違っています。これは特に、連邦政府当局での口座振込または直接支払いサービスの登録に関連しています。
  
• 防止策: 送信する前に、取引コードを確認します。
  
• アクション: 取引コードを修正し、再送信します。
  

R42 - 金融番号 / チェックデジットエラー

• 説明: 連邦政府 ENR エントリーで、金融番号の末尾にあるチェックデジットが間違っています。
  
• 防止策: 金融番号とそのチェックデジットを確認します。
  
• アクション: チェックデジットを修正して再送信します。
  

R43 - 無効な DFI 口座番号

• 説明: RDFI の口座番号が間違っています。このリターンコードは ENR エントリーのみで発生し、連邦政府機関に関する問題に限定されます。
  
• 防止策: 取引を開始する前に、口座番号を確認します。
  
• アクション: 口座番号を修正して再送信します。
  

R44 - 無効な個人 ID 番号

• 説明: 提供された個人 ID 番号が、レコードの ID 番号と一致しません (これは特に連邦政府の取引と関連があります)。
  
• 防止策: 取引を開始する前に、個人 ID 番号を確認します。
  
• アクション: 個人 ID 番号を更新して再送信します。
  

R45 - 無効な個人名

• 説明: 口座名義人の名前が正しくないか、記載ミスがあります。
  
• 防止策: 取引を開始する前に、名前を確認します。
  
• アクション: 名前を更新し、再送信します。
  

R46 - 無効な代表受取人インジケーター

• 説明: 代表受取人インジケーターコードが正しくありません。
  
• 防止策: 取引を開始する前に、インジケーターコードを確認します。
  
• アクション: インジケーターコードを修正し、再送信します。
  

R47 - 重複登録

• 説明: RDFI は連邦政府機関に ENR を送信して、これらの機関との ACH 決済または口座振込を開始します。この場合、同じ ENR が複数回送信されました。
  
• 防止策: 登録が重複しないようにしっかり管理します。
  
• アクション: 本当に重複している正しい処理であるか確認し、適切な措置を取ります。
  

R50 - RCK の受け付けに影響する州法

• 説明: RDFI がデジタル決済を許可していない州にあるか、または州法に基づいて特定の期間内に支払い済み小切手を利用者に返却することを求めている州に所在している可能性があります。
  
• 防止策: 取引を規制する州法について把握します。
  
• アクション: 取引が振り分けられる州の特定の法律を調査し、将来の取引においてそれに従うようにします。
  

R51 - RCK エントリーに関連するアイテムが不適格または RCK エントリーが不適切

• 説明: 差戻された小切手や再提出された小切手のエントリーが不適格で処理に適していないか、エントリーの準備または実行が不適切でした。
  
• 防止策: エントリーの適格性や正確性について確認します。
  
• アクション: 取引をレビューして、すべての該当する規制やガイドラインに準拠していることを確認します。
  

R52 - RCK エントリーに関連するアイテムの支払い停止

• 説明: 口座名義人が電子的に再処理される予定の不渡り小切手について停止指示を出しました。
  
• 防止策: 処理を進める前に、支払い停止指示が出ていないことを確認します。
  
• アクション: 小切手発行銀行か支払人に連絡を取って、問題を解決します。
  

R53 - 決済に関するアイテムと RCK エントリーの提出

• 説明: 元の取引とそれに対応する RCK エントリーの両方が提出され、重複した取引が発生しました。
  
• 防止策: アイテムとエントリーの両方が提出された際に注意します。
  
• アクション: 決済レコードを照合し、重複した取引を削除します。
  

R61 - 差戻しの誤送信

• 説明: 差戻した取引が間違った機関に送信されました。
  
• 防止策: 正しい金融番号を確認します。
  
• アクション: 経路の選定情報を修正し、取引を再送します。
  

R62 - 誤った取引の差戻しまたは返金の振込

• 説明: デビットエントリーが間違って送信されたか、差戻す必要があります。
  
• 防止策: 確定する前に、エントリーをダブルチェックします。
  
• アクション: 必要に応じて、取引の修正または差戻しを行います。
  

R63 - 金額の誤り

• 説明: 取引で指定された金額が間違っています。
  
• 防止策: 送信する前に、取引金額を確認します。
  
• アクション: 金額を修正し、新しい取引を開始します。
  

R64 - 個人 ID の誤り

• 説明: 差戻し取引の個人 ID 番号が、元のエントリーの番号と一致しません。
  
• 防止策: 個人 ID 情報を確認します。
  
• アクション: 情報を更新し、取引を再び処理します。
  

R65 – 取引コードの誤り

• 説明: 取引コードが、その種類の取引に対して正しくありません。
  
• 防止策: 取引コードが正しいことを確認します。
  
• アクション: 取引コードを更新し、取引を再送信します。
  

R66 – 企業 ID の誤り

• 説明: 取引の企業 ID が、バッチヘッダーレコード (一連の取引の送金に関するメタ情報) の ID 番号と一致しません。
  
• 防止策: 企業 ID 情報を確認します。
  
• アクション: 企業 ID を修正し、取引を再び処理します。
  

R67 – 差戻しの重複

• 説明: 差戻しエントリーがすでに処理されていて、重複が発生しました。
  
• 防止策: 再送信しないで済むように処理済みの差戻しを追跡します。
  
• アクション: アクションは不要ですが、今後発生しないように社内プロセスを見直してください。
  

R68 – 期限切れの差戻し

• 説明: 差戻しが必要な期間内に処理されませんでした。
  
• 防止策: 差戻しの処理の期限をモニタリングします。
  
• アクション: 可能であれば許可された期間内に再送信します。
  

R69 – フィールドエラー

• 説明: 1 つ以上のフィールドで ODFI が入力した情報に、不正確な口座番号や口座名の不一致などの不正確な情報が含まれています。これにより、その取引は差戻されます。
  
• 防止策: 送信前にすべてのフィールドを確認します。
  
• アクション: 指摘されたフィールドのエラーを修正して、再送信します。
  

R70 - 許容できる差戻しエントリーが受け入れられなかったか、差戻しが ODFI によってリクエストされなかった

• 説明: 有効な差戻しエントリーが適切に処理されなかったか、または ODFI によって差戻しがリクエストされませんでした。
  
• 防止策: 差戻しに関する ODFI の規則に従います。
  
• アクション: 受け入れられなかった理由を確認し、適切に処理します。
  

R71 - 誤送信された不渡りの差戻し

• 説明: 不渡りの差戻しエントリー (ODFI に一度送信されたが正しく処理されず、再度送信する必要があるエントリー) が、正しい機関に送信されませんでした。
  
• 防止策: 差戻し用の金融番号が正しいことを確認します。
  
• アクション: 不渡りの差戻しを適切な機関にリダイレクトします。
  

R72 - 期限切れの不渡りの差戻し

• 説明: 不渡りの差戻しが必要な期間内に処理されませんでした。
  
• 防止策: 不渡りの差戻し期限に関する情報を常に最新に保ちます。
  
• アクション: 可能であれば許可された期間内に再送信します。
  

R73 - 期間内の元の差戻し

• 説明: RDFI で、元の差戻しが必要な期間内に処理されたことを確認しています。
  
• 防止策: 該当しません。
  
• アクション: アクションは不要です。
  

R74 - 修正済みの差戻し

• 説明: 以前に不適切に処理された差戻しが修正されました。
  
• 防止策: 該当しません。
  
• アクション: アクションは不要です。
  

R75 - 重複ではないリターン

• 説明: これは拒否コード R67 に対する応答です。RDFI は、ODFI による差戻しエントリーの不渡りが不当であると異議を申し立てています。
  
• 防止策: 該当しません。
  
• アクション: アクションは不要です。
  

R76 - エラーが見つからない

• 説明: ODFI がフィールドエラーを指摘した拒否コード R69 への応答です。このコードは正式な異議申し立てになります。RDFI は、これらのエラーが実際に存在していないと判断しています。
  
• 防止策: 該当しません。
  
• アクション: アクションは不要です。
  

R77 - R62 不渡りの差戻しの受け入れ拒絶

• 説明: これは拒否コード R62 に対する応答です。RDFI が不適切な取引をすでに差戻したか、または R62 で指定された通りに受取人から資金を回収できないことを示しています。
  
• 防止策: 不渡りの差戻しの受け入れに関する基準を把握します。
  
• アクション: 受け入れられなかった理由を確認し、必要に応じて再送信します。
  

次の拒否コードは国際 ACH 取引 (IAT) に関連しています。

R80 - IAT エントリーのコーディングエラー

• 説明: IAT エントリーにコーディングエラーが存在します。
  
• 防止策: IAT エントリーのコーディングを確認します。
  
• アクション: コーディングエラーを修正し、IAT エントリーを再送信します。
  

R81 - IAT プログラムに不参加

• 説明: RDFI が IAT プログラムに参加していません。
  
• 防止策: RDFI が IAT プログラムに参加していることを確認します。
  
• アクション: IAT プログラムに参加している RDFI を探すか、取引に IAT を使用しないようにします。
  

R82 - 無効な国外の RDFI ID

• 説明: 国外の RDFI の ID が間違っています。
  
• 防止策: 国外の機関の ID 詳細をダブルチェックします。
  
• アクション: ID 情報を修正し、取引を再処理します。
  

R83 - 国外の RDFI で売上処理ができない

• 説明: 国外の RDFI で取引を完了できません。
  
• 防止策: 取引を開始する前に、当該の国外の機関で取引を売上として処理できることを確認します。
  
• アクション: 国外の機関に直接確認し、問題を解決します。
  

R84 - ゲートウェイによってエントリーが処理されない

• 説明: 指定されたゲートウェイ (金融機関の ACH ネットワークへの入口として機能するサービスプロバイダー) でエントリーが処理されませんでした。
  
• 防止策: 取引が有効なゲートウェイを経由して振り分けられるようにします。
  
• アクション: 有効なゲートウェイを経由して取引を再送信するか、解決するためにゲートウェイに連絡します。
  

R85 - 国外向け国際決済のコードの誤り

• 説明: 国外向け国際決済のコーディングに間違いがありました。
  
• 防止策: 国際決済のコーディングを確認します。
  
• アクション: コードを修正し、取引を再送信します。
  

事業者での ACH 拒否への対処方法

ACH 拒否が少なくなると、チームの業務負担が減り、利用者にとってもプロセスが簡単になります。これにより、顧客維持率が向上する可能性があります。

不要な ACH 拒否を予防し、発生した場合に効率的に対処するには、事業者が多角的な戦略を実施する必要があります。これには予防措置、問題のタイムリーな特定、適切なフォローアップアクションが含まれます。以下で、講じることができる措置を紹介します。

予防措置

• 口座情報の確認: ACH 取引を開始する前に、受取人の口座番号と金融番号を確認します。これは、手作業で行うことも、電子的な検証サービスを介して行うこともできます。

• 安全で適切な承認: 継続支払いの場合、顧客やベンダーから書面による承認を取得し、安全に保管します。これらを定期的に更新し、常に有効であるようにします。

• 取引制限の実施: 取引ごとおよび 1 日の取引限度額を設定して、許容額を超えないようにします。超えた場合は、拒否をトリガーします。

• スタッフやパートナーのトレーニング: 財務取引を処理する従業員のトレーニングを定期的に実施し、法令遵守の要件を含む ACH ネットワークの複雑な点を理解できるようにして、エラーが発生する可能性を減らします。

• リアルタイムのアラートを利用する: 口座残高や取引ステータスのリアルタイム通知を提供するシステムを導入します。これにより、不足した資金や未決済の資金による拒否を回避できます。

• 定期的に口座を調整する: 常に会計記録と銀行明細書を照らし合わせて消し込みを行い、拒否につながる恐れのある不一致を見逃さないようにします。

拒否への対応

• 拒否を即座に識別する: 拒否が発生した際に主な担当者にすぐに通知するアラートを設定し、迅速に対応できるようにします。

• 拒否コードを解釈する: ACH 拒否コードを参照して、拒否の具体的な理由を把握します。こうすることで、その後にすべきことを判断できます。

• 関係者とのコミュニケーション: 利用者、従業員、ベンダーに問題について知らせて、協力して解決にあたります。これには、口座情報の更新や新しい承認フォームの確保が含まれます。

• 必要な修正を行う: 修正された情報で社内システムを更新し、必要に応じて新しい ACH 取引を開始します。

• 記録を保持する: 拒否とその後の問題解決のために取った措置を文書化します。これは監査に役立つ場合があり、問題の解決に取り組んでいることを示せます。

• 手続きを評価および調整する: 個々の問題を解決した後、パターンやシステム上の問題を特定するためにそれらを分析します。必要に応じて手続きを変更し、将来の発生を防ぎます。

特定のシナリオに対するアクション

• 給与: 給与の口座振り込みの場合、新しい従業員を登録する際や、従業員が銀行口座の詳細の変更について報告してきたときに、口座情報をダブルチェックするようにします。

• ベンダーへの支払い: ベンダーに支払う際には、サプライチェーンの運営に影響を与えかねない取引の遅延が生じないように、フォームと承認が最新であることを確認します。

• 定期的な利用者への請求: サブスクリプションや分割払いの場合、各請求サイクルの前に、利用者にリマインド通知を送り、十分な残高があることを確認するように促したり、口座情報を更新する機会を提供したりします。

• E コマース取引: E コマース事業では、確認機能をペイメントゲートウェイと連携させて、口座の詳細をリアルタイムで確認できるようにします。

• 高額取引: 大きな金額が関わる取引の場合、承認や口座の問題による拒否のリスクを減らすために、電話確認などの確認手順の追加を検討してください。