SEPA XML file rejected? pain.002 reason codes (AM10, DU01, FF01…) and how to fix them

Free tool: Rebuild the file with PayBatchKit – runs in your browser, files are not uploaded.

You uploaded a SEPA credit transfer file (pain.001) and the bank said no. There are two ways this happens:

Immediately on upload: online banking shows "invalid file", "schema validation failed" or similar. The file is not valid XML for the version the bank expects.
Later, in a status report: the bank accepted the upload, then sent back a pain.002 "payment status report" with the status RJCT (rejected) or PART (partly accepted) and one or more reason codes.

The reason codes come from the ISO 20022 external code list ExternalStatusReason1Code. Every bank uses a subset, but the meaning is the same everywhere.

Rejections of the whole file

Code	Meaning	Usual cause	Fix
`FF01`	File format incomplete or invalid	XML does not match the schema: wrong pain version, a missing element, an amount written `1250,00` instead of `1250.00`, a date like `2026-02-30`.	Validate against the XSD of the version your bank wants; regenerate rather than hand-edit.
`AM10` / `AM16` / `AM17`	Control sum invalid (overall, group level, payment-information level)	`CtrlSum` no longer matches the amounts – typically after someone deleted a payment from the XML by hand.	Recalculate in cents; `CtrlSum` appears in `GrpHdr` and in each `PmtInf`.
`AM18` / `AM19` / `AM20`	Number of transactions invalid	`NbOfTxs` does not match the number of `CdtTrfTxInf` blocks.	Same as above: regenerate after every change.
`DU01`	Message identification is not unique	The same `MsgId` was uploaded before – often a re-upload of a corrected file.	Give every file a new `MsgId`.
`DU02`	Payment information block is not unique	A reused `PmtInfId`.	New ID per batch.
`AM05`	Duplication	The bank thinks the same file or payment was already submitted.	Check the payment overview before re-sending – the first upload may have gone through.
`CH04` / `CH03` / `DT01`	Execution date too far in the past / too far in the future / invalid date	An old file re-used, or a typo in `ReqdExctnDt`.	Use today or a future business day; some banks cap how far ahead you can schedule.
`FF04`	Service level code missing or invalid	`SvcLvl/Cd` is not `SEPA`, or a non-SEPA payment is in a SEPA file.	Use `SEPA`, EUR, and SEPA-country IBANs only.

Rejections of single payments

Code	Meaning	Usual cause	Fix
`AC01`	Incorrect account number	IBAN typo or wrong length.	Check the IBAN – the IBAN checker catches almost all typos with the mod-97 check digits.
`AC04` / `AC06`	Account closed / blocked	A valid IBAN, but the account is no longer usable.	Ask the payee for new details; no format tool can detect this.
`RC01`	Bank identifier incorrect	A wrong or outdated BIC.	Inside the EEA you can usually leave the BIC out; otherwise correct it.
`BE04`	Missing creditor address	Some payments (for example to non-EEA SEPA countries such as Switzerland or the UK) need the payee's address.	Add town and country (or a full structured address). See structured addresses.
`AM04`	Insufficient funds	Not enough money on your account at execution.	Fund the account or split the batch.
`AM02` / `AM21`	Amount not allowed / above the limit agreed with the bank	A payment or file above your daily or per-file limit.	Ask your bank to raise the limit or split the file.

Upload errors without a code

Wrong version. The xmlns on the first line ends in pain.001.001.03 or .09; a bank that expects one may refuse the other. See .03 vs .09.
Characters outside the SEPA set. The basic set is a–z A–Z 0–9 / - ? : ( ) . , ' + and space. Umlauts, &, ß, curly quotes or emoji in names and references may be rejected; some banks accept more, many don't.
Field too long. Name 70, remittance text 140, IDs 35 characters.
Encoding. Save as UTF-8. A file re-saved by a text editor in another encoding can break accented names.
Account not enabled. Some banks need file upload or the debtor IBAN activated for bulk payments first – the file is fine, the permission isn't.

A checklist before you upload

Every IBAN passes mod-97, every amount has at most two decimals and uses a dot in the XML.
NbOfTxs and CtrlSum match, at both levels.
A new MsgId for every upload.
The execution date is a real, future business day.
The version is the one your bank documents.
After uploading, compare the bank's preview (count and total) with your sheet before you approve.

Avoid the hand edits: PayBatchKit rebuilds the whole pain.001 from your Excel or CSV – IBAN check digits, character set, counts, control sums, a fresh message ID, and warnings for past or weekend execution dates. Our tests validate the output against the official ISO 20022 XSDs. It runs in your browser; your payment list is not uploaded.

Reason codes and their use differ by bank: your bank's own pain.002 specification is the final word. This page is general information, not banking advice.

Free tool: Rebuild the file with PayBatchKit – runs in your browser, files are not uploaded.

Sources

Related guides

Published 2026-10-03 by Karuna Labs. Our tools check file structure and checksums; always review outputs (and payment files in your bank's preview) before relying on them. This is general information, not financial, tax or legal advice.