According to the European Payments Council, a SEPA collection batch rejected by your bank may contain syntax errors that require correction before the affected instructions can be submitted again (SEPA Direct Debit Core Scheme Rulebook 2025 Version 1.1). You can identify the rejected scope and reported reason from the bank’s status report (SEPA Direct Debit Core Scheme Customer-to-PSP Implementation Guidelines). You can then establish whether late submission requires an agreed replacement due date before resubmitting (European Payments Council, SEPA Direct Debit Core Scheme).
Start with the groundwork in our earlier article: What is a SEPA Creditor Identifier and how do you get one?
Why is my bank rejecting my SEPA collection batch, and how do I identify what to correct?
Start with the bank’s status report: identify the rejected scope and read its associated reason information before deciding which instructions need correction (European Payments Council (EPC) AISBL). Account problems, missing mandate information, duplicates and invalid file formats are among the rejection reasons mapped in the European Payments Council’s SEPA Direct Debit Core Scheme Customer-to-PSP Implementation Guidelines.
Match the report’s Original Message Identification, OrgnlMsgId, to the message you submitted; that reference identifies the original message unambiguously (European Payments Council (EPC) AISBL). Locate RJCT at group, payment-information or transaction level rather than treating a rejection notification as proof that every collection failed. Read the associated Status Reason Information, StsRsnInf, which must appear at one of those levels and provides detail about the status reason.
Separate who initiated the exception from why it happened: the R-transaction data identifies its type, initiator and reason (Guidance on reason codes for SEPA Direct Debit R-transactions). If you request complementary information about an R-message, provide the reference of the payment service provider or clearing and settlement mechanism that initiated it (European Payments Council, SEPA Direct Debit Core Scheme).
For syntax errors, correct the affected instructions and introduce those same instructions in another file, as permitted by the EPC’s SEPA Direct Debit Core Scheme Rulebook. A rejected one-off collection must still be presented as one-off after correction, while a rejected recurrent collection must still be presented as recurrent.
The reasons for rejection by your creditor bank are governed by its bilateral agreement with you (European Payments Council, SEPA Direct Debit Core Scheme). Check the timing before resubmitting: for late presentment, the bank must replace the outdated due date with a new one, subject to an agreement with you. Without that agreement, the file must be rejected rather than carried forward with the outdated due date. Obtain your bank’s submission cut-off before retrying; the creditor bank must inform you of the cut-off and collection time-cycle requirements.
What do the rejection codes mean, and what should I check for each one?
Use the reported code to identify the issue you need to investigate, rather than treating every rejection as a file-format problem (European Payments Council (EPC) AISBL). The implementation guidelines assign separate codes to an incorrect account identifier (AC01), a closed account (AC04) and a blocked account (AC06) (European Payments Council (EPC) AISBL). A regulatory prohibition on direct debit is another distinct account condition, not simply an incorrect account number. Where the reported issue concerns the account, investigate that condition rather than changing unrelated collection fields.
An incorrect operation, transaction or sequence code points to collection coding, whereas an invalid-file-format reason points to the file structure (European Payments Council (EPC) AISBL). The guidelines distinguish insufficient funds from a duplicate collection, so neither should be interpreted as a mandate-data error. A debtor-name mismatch concerns the relationship between the debtor’s name and the account holder’s name, while an incorrect creditor identifier concerns the creditor’s identification.
Mandate-related reasons distinguish no mandate from mandate data that is missing or incorrect (European Payments Council (EPC) AISBL). They also distinguish a deceased debtor from a debtor’s refusal, which are separate reported reasons requiring different interpretation.
Do not assume that your creditor bank’s response must use only the codes in the mapping: the guidelines permit other ISO codes when the creditor bank rejects the message (European Payments Council (EPC) AISBL).
AG01 identifies direct debit forbidden on the account for regulatory reasons. BE01 identifies a mismatch between the debtor’s name and the account holder’s name. MD07 identifies a deceased debtor. RC01 identifies an incorrect payment service provider identifier, such as an invalid BIC. RR01 identifies a regulatory reason associated with missing debtor account or identification information. RR02 identifies a regulatory reason associated with missing debtor name or address information. If MS03 (NotSpecifiedReasonAgentGenerated) reports “Reason not specified”, ask your bank to clarify the reason before deciding how to respond.
Rejection codes and the issue they identify
Code | Meaning and diagnostic target |
|---|---|
AC01 | Incorrect account identifier, such as an invalid IBAN |
AC04 / AC06 | Closed account / blocked account, including a debtor block on direct debit |
AG02 | Incorrect operation, transaction or sequence code |
FF01 | Invalid file format |
AM04 / AM05 | Insufficient funds / duplicate collection |
BE05 | Incorrect creditor identifier |
MD01 / MD02 | No mandate / mandate data missing or incorrect |
MS02 / MS03 | Debtor refusal / reason not specified |
Which XML and collection-data checks can explain a rejection?
Check both the XML structure and the collection data against the Core requirements, rather than relying on the file’s ability to represent an ISO message (European Payments Council (EPC) AISBL). The XML controls here apply to SEPA Direct Debit Core, not B2B collection files.
Mandatory elements must be present with the required multiplicity, and empty elements are not allowed (European Payments Council (EPC) AISBL). The SEPA multiplicity can differ from the ISO standard’s multiplicity, so an element’s ISO status alone does not establish whether it satisfies the Core requirements. Ensure mandatory elements are present and contain valid content, and remove empty optional elements rather than leaving tags without content.
Check that Message Identification, MsgId, is unique per instructed party for the agreed period (European Payments Council (EPC) AISBL). According to European Payments Council (EPC) AISBL, MsgId cannot be empty, and its maximum length is 35 characters under both the ISO and SEPA rules. Transaction-count validation depends on the pre-agreed customer-to-bank conditions, so apply those conditions when checking the count in your file.
The local-instrument code must identify Core, and different local-instrument values cannot be mixed in the same message (European Payments Council (EPC) AISBL). Sequence Type, SeqTp, is mandatory and distinguishes first, recurrent, final and one-off collections. Check that the sequence represented in the file corresponds to the collection you are instructing, rather than treating this mandatory field as interchangeable metadata.
According to European Payments Council (EPC) AISBL, the instructed amount must be in EUR, from 0.01 to 999999999.99 inclusive, with a maximum of two digits in the fractional part. Check the instructed amount itself against these currency, range and precision restrictions, not just whether the XML accepts a numeric value.
Creditor Scheme Identification must be present at either payment-information or direct-debit-transaction level (European Payments Council (EPC) AISBL). The guidelines recommend the same creditor scheme identification for all transactions within a payment-information block. The rulebook also requires transmission of the mandatory collection information and the relevant information for new or amended mandates as part of collections (European Payments Council, SEPA Direct Debit Core Scheme). Use the sequence values defined in those guidelines: FRST for first, RCUR for recurrent, FNAL for final and OOFF for one-off collections (European Payments Council (EPC) AISBL).
According to the European Payments Council, its SEPA XSDs are not developed for production purposes: they formalise the implementation guidelines’ business rules and restrictions as technical validation subsets (SEPA Direct Debit Core Customer-to-PSP Implementation Guidelines 2025 version 1.0). Production instantiations should refer to the default ISO namespaces instead.
Can the previously announced address-format deadline explain my rejection now?
Do not diagnose your rejection using the superseded November deadline for unstructured addresses: the EPC has delayed the end date to a future date still to be defined (European Payments Council, SEPA Direct Debit Core Customer-to-PSP). Its current implementation-guidelines notice says unstructured addresses remain supported beyond the previously announced deadline.
According to the European Payments Council, version 1.1 of its 2025 SDD Core rulebook moved the deadline from 22 November 2026 to 15 November 2026 (2025 SEPA Direct Debit Core rulebook version 1.1). The later implementation-guidelines notice states that the updated rulebook takes effect on 30 September 2026 (European Payments Council, SEPA Direct Debit Core Customer-to-PSP). It attributes that exceptional effective date to the delay in ending the unstructured address format, with a replacement date to be determined by the EPC.
Disregard references in the guidelines to the earlier deadline, as the EPC’s notice expressly instructs (European Payments Council, SEPA Direct Debit Core Customer-to-PSP). The EPC’s September 2026 reason-code guidance update removes the address-format end-date reference from RR02 and RR03 (European Payments Council, Guidance on reason codes). Removing the end-date reference does not mean that missing or otherwise unacceptable address data can be ignored when your bank reports RR02 or RR03.
Sources
- SEPA Direct Debit Core Scheme Rulebook 2025 Version 1.1, European Payments Council, 05 October 2025
- SEPA Direct Debit Core Scheme Customer-to-PSP Implementation Guidelines, European Payments Council (EPC) AISBL, 28 November 2024
- Guidance on reason codes for SEPA Direct Debit R-transactions, European Payments Council, 30 Sep 26
- SEPA Direct Debit Core Customer-to-PSP Implementation Guidelines 2025 version 1.0, European Payments Council, 06 Oct 25
- 2025 SEPA Direct Debit Core rulebook version 1.1, European Payments Council, 5 October 2025