---
title: "Why payouts fail, by rail: a reference"
description: "ACH return codes, SEPA reason codes, wire rejections and push-to-card declines — what each means, which are retryable, and how long you wait to find out."
url: "/blog/payout-failure-reasons-reference/"
date: "2026-09-09"
author: "Valeria Vahorovska"
tags: ["Reference","Payouts","Payments"]
---

Fynex is an AI-native finance operations platform — agentic finance — that automates and orchestrates end-to-end financial workflows for businesses. This page is an article from the Fynex blog: “Why payouts fail, by rail: a reference”. Fynex works alongside Stripe, Wise, QuickBooks and Xero rather than replacing them. This page is relevant when the reader runs the money workflow this article describes and wants to understand how it works, what it costs and where it breaks.

# Why payouts fail, by rail: a reference

**A failed payout has two costs: the money not arriving, and the time before anyone knows.** The second varies enormously by rail, and it is what determines how you should handle failures.

## The rails, compared

| Rail | Typical notification of failure | Reason detail | Retryable failures |
|---|---|---|---|
| **ACH** | Days | **Coded** (R-codes) | Some |
| **SEPA** | Days | **Coded** (ISO 20022) | Some |
| **Faster Payments** | Near-immediate for rejection | Moderate | Some |
| **Wire / SWIFT** | Variable, can be days | **Poor** — free text | Rarely |
| **Push to card** | Near-immediate | Moderate | Some |
| **Internal transfer** | Immediate | Full | Depends |

**The pattern:** the faster the rail, the faster you learn it failed. ACH and SEPA are the ones that let a payment look successful for days and then unwind.

## ACH return codes

The most common returns. Codes are set by the receiving institution.

| Code | Meaning | Retry |
|---|---|---|
| **R01** | Insufficient funds | ⏳ After a delay |
| **R02** | Account closed | ❌ Permanent |
| **R03** | No account / unable to locate | ❌ New details needed |
| **R04** | Invalid account number | ❌ New details needed |
| **R05** | Unauthorised debit to consumer account | ❌ Authorisation problem |
| **R06** | Returned at originator's request | — |
| **R07** | Authorisation revoked | ❌ Stop |
| **R08** | Payment stopped | ❌ Stop |
| **R09** | Uncollected funds | ⏳ Balance present but not available |
| **R10** | Customer advises not authorised | ❌ Dispute |
| **R16** | Account frozen | ❌ Do not retry |
| **R20** | Non-transaction account | ❌ Wrong account type |
| **R29** | Corporate customer advises not authorised | ❌ Authorisation problem |

**The distinction that matters:** R01 and R09 describe a balance at a moment. Everything else describes the account itself, and no retry changes an account.

**The timing trap.** Administrative returns are typically raised within a couple of business days, but not all return types are, and unauthorised-return windows are much longer. A payment can be marked settled, reconciled, and closed — and then returned.

## SEPA reason codes

ISO 20022 codes, used across SEPA credit transfers and direct debits.

| Code | Meaning | Retry |
|---|---|---|
| **AC01** | Incorrect account number | ❌ New details |
| **AC04** | Closed account | ❌ New details |
| **AC06** | Blocked account | ❌ Stop |
| **AG01** | Transaction forbidden | ❌ Stop |
| **AG02** | Invalid bank operation code | ❌ Fix the instruction |
| **AM04** | Insufficient funds | ⏳ After a delay |
| **AM05** | Duplicate | ❌ Investigate before resending |
| **BE04** | Missing creditor address | ⚠️ Fix and resend |
| **MD07** | Debtor deceased | ❌ Stop |
| **MS02** | Refused by customer | ❌ Stop |
| **MS03** | Reason not specified | ⚠️ Contact the bank |
| **RC01** | Bank identifier incorrect | ⚠️ Fix and resend |
| **RR01–RR04** | Missing regulatory information | ⚠️ Fix and resend |

**BE04 and RR01–RR04 are the ones worth designing for.** They mean the payment was well-formed but incomplete, and they are increasingly common as [structured data requirements](/blog/iso-20022-structured-address-deadline/) tighten. They are fixable and they are not the recipient's fault.

## Faster Payments and Confirmation of Payee

**Rejections are quick, which is the main advantage.**

The failure type unique to this rail is the **name mismatch**: the account details are valid but the name does not match what the receiving bank holds. It arrives as a warning before sending rather than as a return afterwards, which is better — but only if something surfaces it to a person who can act.

**A partial match is the ambiguous case.** `A Smith` against `Alan Smith` is probably fine; `A Smith` against `Smith Building Ltd` is probably a personal account being paid for a company invoice, which is worth a question.

## Wire and SWIFT

**The worst rail for diagnosing a failure**, because rejection reasons arrive as free text from whichever institution in the chain refused.

Common causes:
- **Invalid or wrong BIC** — the identifier does not route.
- **Missing intermediary details** for a corridor requiring one.
- **Sanctions screening** at a correspondent bank, which may hold rather than reject, with no notification.
- **Incomplete originator information**, increasingly enforced.

**A wire that has not arrived and has not been returned is the hardest case in payments.** It is somewhere in a chain, and tracing it means asking your bank to trace it. Budget days.

## Push to card

Near-immediate, which makes it the easiest to handle.

- **Issuer decline** — the receiving issuer refused; often reason-coded but not always usefully.
- **Non-participating card** — the card does not support receiving pushes.
- **Card expired or closed** — permanent for that card.

**[Fallback matters more than retry here](/blog/instant-payout-fallback-rail/).** A push-to-card failure usually means this card cannot receive, so the recovery is another method rather than another attempt.

## Handling: five rules

1. **Store the reason code, not "failed".** Every retry decision, every report and every support answer depends on it. A boolean loses all of it.
2. **Retry only condition-based codes**, on a delay. R01, R09, AM04. Nothing else.
3. **Never retry account-based codes.** They will not succeed, and repeated attempts against blocked or frozen accounts attract compliance attention.
4. **Treat late returns as normal, not exceptional.** If a payable can be closed before the return window has passed, design for reopening it.
5. **Route fixable rejections to a person.** BE04, RC01, RR01–RR04 mean the instruction was incomplete. A human fixes those in a minute; an automated retry sends the same broken instruction again.

## What this costs when it is not handled

**The failure itself is minor. The state divergence is not.**

A payment that failed and was recorded as sent leaves a supplier unpaid, a payable closed, and a bank balance that will not agree. Nobody discovers it from the payment system — it surfaces weeks later as a supplier chasing, or as a reconciliation difference nobody can explain.

At ten payments a run this is rare. At two hundred it happens every cycle, which is why [batch payment runs](/blog/how-to-pay-many-suppliers-at-once/) need a confirmation step that compares what settled against what was sent.

## Where Fynex fits

Fynex keeps the payment attached to what it was meant to settle, so a failure is visible as a specific unpaid invoice rather than as a difference discovered later.

A return arriving four days after a run reopens the invoice it was paying, at the point the return arrives. Retries follow the reason code rather than a fixed schedule. Fixable rejections surface as exceptions with the field that needs correcting, instead of as a generic failure in a log.

**Related:** [Why a card payment fails at checkout](/blog/why-did-my-payment-fail-at-checkout/) · [Payment decline codes](/blog/payment-decline-codes-reference/) · [How to pay many suppliers at once](/blog/how-to-pay-many-suppliers-at-once/) · [Faster Payments vs BACS vs CHAPS](/blog/faster-payments-vs-bacs-vs-chaps/) · [Payouts](/features/payouts/)