← All guides

Why banks reject SEPA credit transfer files: the most common reasons

The rejection reasons that account for nearly every failed SEPA payment file — wrong totals, bad IBANs, forbidden characters, wrong charge codes, stale dates and duplicate references.

A rejected payment file feels mysterious from the outside. The bank portal shows a red banner, the error text is three lines of jargon, and the payments — salaries, rent, supplier invoices — simply do not move. From the inside, though, rejections are boring. Banks run the same automated checks in the same order, and the same handful of mistakes fails those checks again and again. After validating large numbers of real-world files, the pattern is clear: nearly every rejection comes from one of about eight causes, and most of them take under a minute to fix once you know which one you are looking at. This guide names them, explains why each one happens, and shows how to stop it happening twice.

One important distinction first: a file rejection is not the same as a payment return. A rejection means the bank refused the file or the payment before execution — the money never left your account. A return happens after execution, when the receiving bank sends the money back, for example because the account was closed. Returns have their own status messages and their own causes. This guide is about rejections, the kind you can prevent entirely by checking the file before upload. If you want the checking routine itself, our pre-flight validation guide walks through it step by step.

1. The control total or count does not match the payments

The champion of rejection reasons is arithmetic. Every pain.001 file states how many transactions it contains (NbOfTxs) and what they add up to (CtrlSum), in the group header and in each payment block. The bank adds up the payments itself and compares. Any difference — even one cent, even one extra transaction after a late edit — and the whole file is refused. The usual story is a workflow one: the ERP writes the header when the export starts, somebody removes a payment afterwards in the portal or in a text editor, and the header no longer describes the file. Rounding is the second story: amounts computed with floating point arithmetic drift by a cent on large batches. The fix is discipline: never edit an exported file by hand, and always recompute the totals as the very last step before upload. Our guide on how CtrlSum and NbOfTxs are calculated shows the two-level structure in detail.

2. An IBAN has a typo — and the check digits prove it

IBANs are built to catch typos. Two of their digits are check digits, computed from all the others with the mod-97 algorithm, so a single wrong digit or two swapped digits break the maths with near certainty. Banks run this check on every account number in the file, debtor and creditor alike. One supplier IBAN copied wrongly into the vendor master three years ago will reject every file that includes that supplier, forever, until somebody fixes the master data. The rejection message rarely says which account failed in plain words, which is why a validator that points at the exact payment saves so much time. When an IBAN fails, re-copy it from the source document — an invoice or bank statement — never try to repair the digits by guessing, and then fix the master record, not just the file. The maths behind the check is friendly once you see it worked once: IBAN mod-97 explained simply.

3. A name or reference uses characters SEPA does not allow

SEPA payments travel through systems that agree on a small, safe character set: basic Latin letters, digits, and a short list of punctuation. Anything else — an ampersand in a company name, a hash sign in an invoice reference, accented letters pasted from a spreadsheet, an emoji in a payment description typed as a joke — can stop the file or the payment at the first system that enforces the set. Company names are the classic source, because legal names genuinely contain ampersands and plus signs, and the person entering the supplier has no way to know the payment system cannot carry them. The cure is to sanitise at export time: replace or drop the characters the scheme cannot carry, consistently, in names, addresses and references. Our full guide to the SEPA character set lists what is allowed and how to transliterate the common cases.

4. The charge bearer is not SLEV

Every SEPA credit transfer must say who pays the charges, in the ChrgBr element, and for SEPA the only correct answer is SLEV — charges are handled following the rules of the scheme, which in practice means each side pays its own bank. ERP systems that also handle international payments often default to DEBT, SHAR or CRED depending on the payment type, and those values are perfectly legal in the ISO schema — which is why this error passes generic XML checks and then fails at the scheme layer. A template that mixes SEPA and non-SEPA payments in one export is the usual culprit. Set SLEV for SEPA euro payments, always, and check the template after any ERP update, because defaults have a habit of quietly returning. We devoted a short guide to what SLEV means and when other codes are legitimate.

5. The execution date is in the past, or not a banking day

Files are often prepared days before they are sent, and sometimes they sit in an approval queue over a weekend. If the requested execution date in the file has passed by the time the bank processes it, many banks reject the batch rather than silently re-dating it. The same applies to dates that fall on weekends or public holidays in the debtor country: the scheme promises execution on banking days, and a file that demands a Sunday gets refused or delayed depending on the bank. This rejection class spikes on Monday mornings and after holidays, which tells you it is a calendar problem, not a data problem. Build the banking calendar into your export routine, regenerate files that waited too long instead of resending them, and treat a past-date warning from any checker as a stop sign, not a footnote.

6. Duplicate references make payments indistinguishable

Two identifiers do the filing work in a pain.001 file: MsgId names the file, and EndToEndId names each payment inside it. Banks and reconciliation software rely on them to answer the question which payment is this. When an ERP reuses the same EndToEndId for every payment — a constant string, an invoice number that legitimately appears twice, a counter that resets — the bank may reject the file, reject the duplicate payments, or accept them and leave your reconciliation team unable to match returns to payments. Duplicate MsgId values across files are worse: many banks treat a repeated MsgId as a double submission and refuse the second file entirely, which looks like a mystery rejection when a failed upload is simply retried. Generate identifiers that are unique by construction, and never retry an upload without checking whether the first attempt actually arrived. The detailed rules are in our guide on MsgId and EndToEndId uniqueness.

7. The currency, amount format or account is wrong for SEPA

SEPA credit transfers are euro payments. A file that includes an amount in another currency, or a payment block whose account currency and amount currency disagree, fails the scheme check even though the schema is happy. Amount format causes quieter failures: the ISO standard allows up to two decimal places for euro amounts in this context and a maximum total length; an ERP that exports unit prices with four decimals, or computes a total with a rounding tail, produces amounts no bank will book. Negative amounts and zero amounts are also refused — a credit note is not a negative payment. These errors often arrive together with the totals problem, because the same code that formats amounts feeds the control sum. Fix amount formatting in one place, in the export, and half of two rejection classes disappear at once.

8. The file is fine — but it breaks the bank’s own guidelines

The most confusing rejections are the ones where your file passes the schema and the scheme rules and still comes back refused. The missing layer is the bank’s implementation guidelines: each bank narrows the standard for its own channels, requiring certain fields, forbidding others, capping batch sizes, or accepting only some pain.001 versions. A file can be a model citizen at one bank and non-compliant at another. There is no shortcut around reading your bank’s current guidelines, but there is a shortcut to finding the difference: compare the rejected file with the last file that bank accepted, element by element. The change between the two files is almost always where the answer lives. Our guide on bank implementation guidelines and why valid files still fail explains this layer properly.

How the bank tells you — and how to read it

Part of the frustration is that rejection news arrives badly. Depending on the bank and the channel, you may get a portal banner with a short text, a status message in a pain.002 report, an EBICS order status, or a phone call from your relationship team. The technical reports use reason codes from standard lists — codes for format errors, invalid account numbers, duplicate submissions and the like — and each code covers a family of sins rather than one exact defect. A format code, for instance, can mean anything from a broken schema to a forbidden character. Read the code as a direction, not a diagnosis: it tells you which family to investigate, and then a validator that reports line-level findings does the diagnosing. This is also why you should always fetch the machine-readable status report instead of relying on the portal banner: the banner summarises, the report specifies, and the specification is what your fix will be checked against next time. Keep both with the payment run, because the second occurrence of the same code, three months later, stops being a mystery the moment you can compare reports.

One more reading skill matters: separate the file-level verdict from the payment-level verdicts. Some channels reject the whole file for a structural problem but return individual payments for data problems, while others refuse the file outright for either. When a report says part of a batch was accepted, resist the urge to resend the whole file after fixing the failed payments — that is how duplicate payments are born, the accepted half paid twice. Resend only the rejected payments, as a new file with a new message identifier, and reconcile the accepted half against the status report line by line. The teams that handle partial rejections calmly are the ones who treat the status report as part of the payment, not as an error message.

Notice what is not on this list: exotic banking rules, sanctions lists, secret limits. Ordinary files fail for ordinary reasons, in the data your own systems produced. That is good news, because it means a five-minute check before upload prevents nearly all of them. Run the file through a validator that covers the schema, the totals, the IBANs and the scheme rules — you can validate free on the home page — read every error, fix the master data or the template behind it rather than patching the single file, and keep the report with the payment run. Teams that adopt that loop find their rejection rate falls to the occasional genuinely new case, which is exactly where human attention belongs. For batch-heavy teams, the pricing page shows which plans add multi-file validation and exportable reports for your audit trail.