Automated Clearing House (ACH) 送金は、企業や個人が電子的に送受信を行うための一般的な決済手段です。2024 年の送金総額は 86 兆 2,000 億ドルに達し、ACH ネットワークで処理された支払いの件数は 335 億 6,000 万件でした。この決済手段は便利で費用対効果が高く人気がありますが、ACH 送金が拒否されることは依然としてよくあります。

ACH 送金を処理できない場合、ACH ネットワークは「拒否コード」または「リターンコード」を返し、送金が完了しなかった理由を説明します。コードは R01 から R85 まであり、残高不足や口座番号の誤りが一般的な理由として挙げられます。

ACH の拒否が発生した場合、企業は今後の問題を防ぎ、顧客の信頼と満足度を維持するために、何が問題だったのかを把握することが重要です。以下では、さまざまな種類の拒否コード、拒否の原因、防止策、発生した際の対処法について解説します。

目次

• ACH 送金とは？
  
• ACH の拒否コードとは？
  
• ACH の拒否が発生する理由
  
• ACH の拒否コード一覧
  
• 企業による ACH の拒否の対処法
  
• Stripe Payments の活用方法
  

ACH 送金とは

ACH (Automated Clearing House) 送金は、さまざまな金融機関の間で資金を移動する電子送金の一形態です。これらの取引は通常、一括して処理され、米国の Nacha (当初は National Automated Clearing House Association) が定めるルールに準拠します。

ACH 送金は、アメリカのビジネスに広く受け入れられている、信頼性が高く、コスト効率に優れた、多目的な決済手段です。この送金の清算には数日かかる場合がありますが、特に業務の効率性やコスト管理の面において、その汎用性の高さと低コストのメリットは、デメリットを上回ることが多くあります。以下は、ACH 送金について知っておくべき重要なポイントです。

ACH 拒否コードとは

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

ACH 拒否が起こる原因

ACH の拒否が発生する理由はさまざまですが、一般的には、管理上のエラー、オーソリに関する問題、資金不足、タイミングや処理の制約、またはリスク管理と規制コンプライアンスの 5 つのカテゴリのいずれかに分類されます。各カテゴリには独自の課題があり、それぞれに応じた解決策が必要です。ACH の拒否が発生する理由について詳しくは、以下をご覧ください。

管理上のエラー

• 不正確な口座情報: ACH の拒否が発生する最も一般的な理由の 1 つは、口座番号またはルーティング番号の不正確さです。不正確な口座情報は、ACH 送金をブロックします。

• 解約済みまたは存在しない口座: 解約済みまたは存在しない口座は、R02 や R03 などのコードによる ACH の拒否を引き起こします。

• 口座タイプの不一致: 口座タイプの不一致により、ACH 送金がブロックされます。

承認の問題

• 事前オーソリの欠如: オーソリが欠如していると、ACH の拒否が発生します。

• オーソリの取り消し: 取り消されたオーソリは、その後の ACH 取引をブロックします。

• 企業におけるオーソリの不服申し立て: 企業の取引において、企業法人が ACH 引き落としや入金をオーソリしていないと報告する場合があります。これが発生すると、システムは取引にフラグを立てて拒否します。

財務上の問題

• 残高不足: ACH の拒否の最もわかりやすい理由の 1 つは、引き落とされる口座の資金不足です。残高不足は R01 の拒否を引き起こします。

• 未回収資金: 口座に資金があってもまだ清算または回収されていない場合、未回収資金が R09 の拒否を引き起こします。

• 支払い停止命令: 口座名義人は、特定の取引に対して支払い停止命令を発行する権利があります。支払い停止命令は、対応する ACH 引き落としをブロックします。

タイミングと処理の制約

• 古くなった、または期限切れのエントリー: ACH 取引を処理できる期間が限られている場合があります。古くなった、または期限切れのエントリーは、ACH の拒否をもたらします。

• 取引限度額の超過: 個人の口座やビジネスは、送金できる金額の限度額が異なる場合があります。Nacha は 2022 年に、同日の ACH 支払いの限度額を 1 回あたり 100 万ドルに引き上げました。送金者が取引限度額を超過すると、ACH 送金の拒否を引き起こします。

• オリジネーションの問題: 場合によっては、問題が受取口座ではなく ODFI (Originating Depository Financial Institution) にあることがあります。ODFI のオリジネーションの問題により、取引の完了が妨げられます。

リスク管理と規制の遵守

• 疑わしい不正利用: 金融機関は、疑わしい活動を継続的に監視しています。疑わしい不正利用は ACH の拒否を引き起こします。

• 規制違反: 規制違反は ACH の拒否を引き起こします。これには、エンドツーエンドの暗号化の失敗や、二要素認証のプロトコルの不遵守が含まれる場合があります。

これらの理由を理解することで、企業や金融機関は ACH 取引プロセスを微調整し、トラブルシューティングを改善し、問題をより早く解決できます。

ACH の拒否コードの一覧と防止方法

ACH の拒否および返品コードは、銀行振込を決済手段として受け付ける際に避けられません。具体的なコードについて説明する前に、いくつかの重要な用語を確認しておきましょう。

• エントリー: ACH 取引の送信のすべて
  
• 返品: エントリーが処理のために受け入れられた後、ODFI に送り返された場合
  
• 拒否: エントリーが最初から ACH ネットワークでの処理のために受け入れられなかった場合
  
• ODFI: ACH 取引を送信する Originating Depository Financial Institution (振出預金金融機関)
  
• RDFI: ACH 取引を受信する Receiving Depository Financial Institution (受領預金金融機関)
  

すべての 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 エントリの返送

• 説明: 紛失、破棄、または破損した小切手 (XCK エントリ) のために、RDFI がエントリを返送しました。
  
• 予防策: 紛失または破損した小切手の返送条件を把握しておきます。
  
• 対応策: 小切手を処理できない理由を評価し、それに応じて次のステップに進みます。
  

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 番号を更新して再送信します。
  

R45 - 無効な個人名

• 説明: 口座名義の名前が不正確、またはスペルミスがあります。
  
• 予防策: 取引を開始する前に名前を検証します。
  
• アクション: 名前を更新して再送信します。
  

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

• 説明: 代理受取人インジケーターコードが不正確です。
  
• 予防策: 取引を開始する前にインジケーターコードを検証します。
  
• アクション: インジケーターコードを修正して再送信します。
  

R47 - 重複登録

• 説明: RDFI は連邦政府省庁に ENR を送信し、これらの機関で ACH 支払いや直接入金を開始します。このケースでは、同じ ENR が複数回送信されています。
  
• 予防策: 重複登録を防止するための制御を実装します。
  
• アクション: 真の重複であるかを確認し、適切な措置を講じます。
  

R50 – RCK の受け入れに影響する州法

• 説明: RDFI は、州法に基づいて、デジタル支払いが許可されていない州にいるか、特定の期間内にキャンセルされた小切手を顧客に返却する必要があります。
  
• 予防策: 取引に適用される州法に習熟します。
  
• アクション: 取引が経由した州の特定の法律を調査し、今後の取引でそれらを遵守します。
  

R51 – RCK エントリーに関連する項目が不適格であるか、RCK エントリーが不適切

• 説明: 返品されて再提示された小切手のエントリーが、不適格であるため処理に適していないか、不適切に準備または実行されています。
  
• 予防: エントリーの適格性と正確性を確認します。
  
• 対応: 取引が適用されるすべての規制とガイドラインに準拠しているか確認します。
  

R52 – RCK エントリーに関連する品目の支払い停止

• 説明: 電子的に再処理されている不渡り小切手に対して、口座名義人が支払い停止を指示しました。
  
• 予防: 処理を進める前に、支払い停止の指示が出されていないことを確認します。
  
• 対応: カード発行会社または支払人に連絡して問題を解決します。
  

R53 – 品目と RCK エントリーが支払いのために提示された

• 説明: 元の取引とそれに対応する RCK エントリーの両方が送信され、重複した取引が発生しました。
  
• 予防: 品目とエントリーの両方を提示する際は注意が必要です。
  
• 対応: 支払い記録を照合して、重複した取引を排除します。
  

R61 – 誤ったルーティングの返品

• 説明: 取り消された取引が間違った機関に送信されました。
  
• 予防: ルーティング番号が正確であることを確認します。
  
• 対応: ルーティング情報を修正し、取引を再送します。
  

R62 – 誤ったまたは取り消し対象の引き落としの返品

• 説明: 引き落としエントリーが誤って送信されたか、取り消す必要があります。
  
• 予防: エントリーを確定する前に再確認します。
  
• 対応: 必要に応じて、修正または取り消しの取引を発行します。
  

R63 – 誤った金額

• 説明: 取引で指定された金額が間違っています。
  
• 予防: 送信前に取引金額を確認します。
  
• 対応: 金額を修正し、新しい取引を開始します。
  

R64 – 誤った個人識別情報

• 説明: 返品取引の個人 ID 番号が元のエントリーのものと一致しません。
  
• 予防: 個人識別情報を確認します。
  
• 対応: 情報を更新し、取引を再処理します。
  

R65 – 誤った取引コード

• 説明: 取引コードが取引のタイプに対して正しくありません。
  
• 予防: 取引コードが正しいことを確認します。
  
• 対応: 取引コードを更新し、取引を再送します。
  

R66 – 誤った会社識別情報

• 説明: 取引内の会社 ID が、バッチヘッダーレコード (取引バッチの転送に関するメタ情報の一部) の ID 番号と一致しません。
  
• 予防: 会社 ID 情報を確認します。
  
• 対応: 会社 ID を修正し、取引を再処理します。
  

R67 – 重複する返品

• 説明: 返品エントリーがすでに処理されているため、重複が発生しています。
  
• 予防: 再送を避けるために処理済みの返品を追跡します。
  
• 対応: アクションは不要ですが、今後の発生を防ぐために社内プロセスを見直してください。
  

R68 – 時機を逸した返品

• 説明: 返品が所定の期間内に処理されませんでした。
  
• 予防: 返品処理の期限を監視します。
  
• 対応: 可能な場合は、許容期間内に再送します。
  

R69 – フィールドエラー

• 説明: 口座番号の誤りや口座名義の不一致など、ODFI が入力した 1 つ以上のフィールドに誤った情報が含まれているため、取引が返品されました。
  
• 予防: 送信前にすべてのフィールドを検証します。
  
• 対応: 指定されたフィールドのエラーを修正し、再送します。
  

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 プログラムに参加していることを確認します。
  
• 対応: 参加している RDFI を見つけるか、取引での IAT の使用を避けます。
  

R82 – 無効な海外 RDFI 識別子

• 説明: 海外 RDFI の識別子が間違っています。
  
• 防止策: 海外機関の識別情報の詳細を再確認します。
  
• 対応: 識別情報を修正し、取引を再処理します。
  

R83 – 海外 RDFI が売上として処理できない

• 説明: 海外 RDFI は取引を完了できません。
  
• 防止策: 取引を開始する前に、海外機関が取引を売上として処理する能力があることを確認します。
  
• 対応: 海外機関と直接協力して問題を解決します。
  

R84 – エントリーがゲートウェイで処理されていない

• 説明: エントリーが、金融機関の ACH ネットワークへのエントリーポイントとして機能する代行業者である指定のゲートウェイで処理されていません。
  
• 防止策: 機能しているゲートウェイ経由で取引をルーティングします。
  
• 対応: 有効なゲートウェイ経由で取引を再提出するか、解決のためにゲートウェイに連絡します。
  

R85 – 誤ってコーディングされた送金 (海外)

• 説明: 送金 (海外) が誤ってコーディングされています。
  
• 予防策: 国際決済のコーディングを確認します。
  
• 対応策: コードを修正して、取引を再送信します。
  

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

ACH の拒否が減れば、チームの運用負担が軽減されるだけでなく、顧客にとってプロセスが容易になり、顧客維持率の向上につながる可能性があります。

不必要な ACH の拒否を防ぎ、実際に発生した場合に効果的に管理するために、企業は多面的な戦略を導入する必要があります。これには、予防措置、問題のタイムリーな特定、適切なフォローアップの実施が含まれます。実行可能なステップは以下のとおりです。

予防措置

• 口座情報の確認: ACH 取引を開始する前に、受取人の口座番号とルーティングナンバーを確認します。これには、手動による方法と、電子的な確認サービスを使用する方法があります。

• 適切なオーソリの確保: 継続課金の場合は、クライアントやベンダーから書面によるオーソリを取得し、安全に保管してください。有効性を確認するために、これらを定期的に更新します。

• 取引制限の導入: 1 回の取引と 1 日の制限を設定し、許容される金額を超過しないようにします。これを超過すると、拒否の原因となる場合があります。

• スタッフやパートナーへの教育: 金融取引を扱う従業員に対し、コンプライアンス要件などの ACH ネットワークの複雑さについて定期的にトレーニングを実施し、エラーが発生する可能性を減らします。

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

• 定期的な口座照合: 拒否につながる可能性のある差異を検出するために、銀行取引明細書と会計記録を常に照合します。

拒否への対応

• 拒否の即時特定: 拒否が発生した時点ですぐに担当者に通知するアラートを設定し、迅速な対応を可能にします。

• 拒否コードの解釈: ACH の拒否コードを参照して、拒否の具体的な理由を理解します。これが今後の対応の指針になります。

• 関係者とのやり取り: 問題について顧客、従業員、またはベンダーに通知し、協力して解決します。これには、口座情報の更新や新しいオーソリフォームの取得が含まれる場合があります。

• 必要な修正の実施: 社内システムを修正後の情報で更新し、必要に応じて新しい ACH 取引を開始します。

• 記録の保持: 拒否と、問題を解決するためにとられたその後のアクションを記録します。これは監査に役立つほか、問題を効果的に解決するという姿勢を示すことにもなります。

• 手順の評価と調整: 個々の問題を解決した後、それらを分析して、パターンや体系的な問題がないか確認します。今後の発生を防ぐために、必要に応じて手順を変更します。

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

• 給与: 給与振込の場合は、新しい従業員のアカウント登録時や、従業員が銀行情報の変更を報告したときに、口座情報を再確認します。

• ベンダーの支払い: ベンダーへの支払い時には、最新のフォームやオーソリがあることを確認し、サプライチェーンの運用に影響を与える可能性のある取引の遅延を防ぎます。

• 顧客の継続課金: サブスクリプションや分割払いの場合は、毎回の請求サイクルの前に十分な資金があることを顧客に通知し、口座情報を更新する機会を提供します。

• e-コマース取引: e-コマースビジネスの場合は、ペイメントゲートウェイに確認機能を組み込み、リアルタイムで口座の詳細を確認できるようにします。

• 高額の取引: 高額な取引の場合は、電話による確認など追加の確認ステップを検討し、オーソリや口座の問題に起因する拒否のリスクを軽減します。

Stripe Payments でできること

Stripe Payments は、ACH クレジットトランスファーを含む 125 種類以上の決済手段を設定し、受け付けられるようにするサービスです。成長中のスタートアップからグローバル企業まで、あらゆるビジネスがオンライン、対面、世界各地で決済を受け付けられる統合型のグローバル決済ソリューションを提供します。

Stripe Payments でできること

• 決済の自動照合: 顧客ごとに仮想銀行口座を使用し、トラブルシューティングツールも備えた自動照合エンジンにより、ACH クレジットトランスファーを特定の決済または請求書に簡単に照合できます。

• 返金の簡素化: 顧客への返金や過剰入金の返還が可能です。

• 決済体験の最適化: 構築済みの決済 UI と Stripe のデジタルウォレット Link を活用することで、摩擦のない顧客体験を実現し、エンジニアリング工数を数千時間削減できます。

• 新市場への迅速な展開: 195 カ国、135 種類以上の通貨に対応した越境決済オプションにより、世界中の顧客にリーチし、多通貨管理の複雑さとコストを軽減できます。

• 対面とオンラインの決済を統合: オンラインと対面のチャネル全体でユニファイドコマース体験を構築し、顧客とのやり取りをパーソナライズし、ロイヤルティを高め、売上を拡大できます。

• 決済パフォーマンスの向上: コーディング不要の不正利用対策やオーソリ成功率改善のための高度な機能など、カスタマイズ可能で設定が簡単な決済ツールで売上を増加させます。

• 柔軟で信頼性の高いプラットフォームで事業成長: 業界最高レベルの信頼性を備えたプラットフォーム上でビジネスを構築し、拡大。これまでの稼働時間は 99.999% を誇ります。

Stripe Payments でオンライン決済と対面決済を強化する方法の詳細をご覧いただくか、今すぐ始めることができます。