15 Common SEPA XML Errors and How to Fix Them
A comprehensive guide to the most frequent SEPA pain.001 and pain.008 validation errors, with practical solutions for each.
Why SEPA XML files get rejected
SEPA XML files (pain.001 for credit transfers and pain.008 for direct debits) follow strict ISO 20022 schemas defined by the European Payments Council (EPC). Even minor deviations from the expected structure cause banks to reject entire payment batches. Understanding common errors saves time and prevents costly payment delays.
This guide covers the 15 most frequent SEPA XML errors encountered by treasury teams, accountants, and developers across Europe. Each error includes the root cause, the XML element involved, and a tested fix.
Whether you use SAP, Oracle, or a custom ERP, these patterns apply universally to all SEPA-compliant payment files.
Schema and structure errors
These errors occur when the XML structure does not match the EPC XSD schema.
1. Wrong namespace or schema version
The root <Document> element must declare the correct namespace for your pain.001 version (e.g., urn:iso:std:iso:20022:tech:xsd:pain.001.001.09). Mixing namespaces from different versions causes immediate XSD validation failure.
2. Missing mandatory GrpHdr fields
The GroupHeader (GrpHdr) block requires MsgId, CreDtTm, NbOfTxs, CtrlSum, and InitgPty. Omitting any of these fields — especially CtrlSum — causes the file to fail schema validation before the bank even parses the payment instructions.
3. Invalid XML encoding or BOM
SEPA XML must use UTF-8 encoding. Files with a BOM (Byte Order Mark), UTF-16, or Windows-1252 encoding are rejected. Ensure your export tool writes pure UTF-8 without BOM.
4. Elements in wrong order
ISO 20022 schemas enforce strict element ordering. For example, in PmtInf, the PmtMtd must appear before ReqdExctnDt. Swapping element positions — even if all data is present — causes schema validation failure.
5. Duplicate MsgId across files
Each SEPA file must have a unique MsgId. If your system reuses the same MsgId for different payment batches, banks will reject the duplicate as a potential replay attack. Use timestamps or UUIDs to ensure uniqueness.
IBAN and BIC errors
Account identifier errors are the single most common reason for SEPA rejections.
6. Invalid IBAN checksum (mod-97)
IBANs use a mod-97 algorithm for their check digits (positions 3-4). A single digit error makes the checksum fail. Always validate IBANs programmatically before including them in your SEPA file. ValidateFin checks every IBAN in your file automatically.
7. IBAN length mismatch for country
Each country has a fixed IBAN length (e.g., DE=22, FR=27, BE=16, NL=18). An IBAN with the wrong number of characters for its country prefix is immediately invalid.
8. Deprecated or invalid BIC
BIC/SWIFT codes can become obsolete after bank mergers. Using a deprecated BIC causes routing failures. For SEPA payments within the EEA, BIC is optional since 2016 — consider omitting it and letting the bank derive it from the IBAN.
Amount and currency errors
Financial validation errors that cause batch-level rejection.
9. CtrlSum does not match transaction total
The CtrlSum in GrpHdr must exactly equal the sum of all InstdAmt values in the file. Even a 0.01€ rounding difference causes the entire file to be rejected. Use decimal-precise arithmetic, not floating-point.
10. Non-EUR currency in SEPA file
SEPA Credit Transfers only support EUR. If your file contains amounts in GBP, CHF, or other currencies, the bank will reject it. Use a separate international payment channel for non-EUR transfers.
11. Amount format with wrong decimal separator
SEPA XML uses a period (.) as the decimal separator, not a comma. The value must have exactly 2 decimal places: <InstdAmt Ccy="EUR">1500.00</InstdAmt>. Values like "1500" or "1.500,00" are invalid.
Date and identifier errors
Common mistakes in dates and reference fields.
12. Past or invalid execution date
The ReqdExctnDt must be a current or future business day. Most banks reject dates in the past and dates more than 30 days ahead. Weekend dates are shifted to Monday, but some banks reject them outright.
13. Invalid characters in EndToEndId
The EndToEndId field (max 35 characters) only allows a restricted set: a-z, A-Z, 0-9, and a few special characters (/, -, ?, :, (, ), ., +, space). Characters like #, @, é, ü are rejected.
14. Missing creditor identifier for SDD
SEPA Direct Debit (pain.008) requires a valid Creditor Identifier (CI) in CdtrSchmeId. This is a country-specific registration (e.g., ICS in France, Gläubiger-ID in Germany). Without it, the entire SDD batch fails.
15. NbOfTxs count mismatch
The NbOfTxs field in GrpHdr must match the actual number of CdtTrfTxInf (or DrctDbtTxInf) elements in the file. A mismatch — often caused by partial file generation — causes immediate rejection.
Validate your SEPA files instantly
ValidateFin catches all 15 errors listed above — and more. Upload your pain.001 or pain.008 file and get instant feedback on schema compliance, IBAN validation, amount consistency, and character encoding.
Open SEPA ValidatorFrequently Asked Questions
What is the most common SEPA XML error?
The most common error is an invalid IBAN checksum (mod-97 failure). This accounts for roughly 30% of all SEPA file rejections. Always validate IBANs before generating your payment file.
Can I fix SEPA errors without regenerating the entire file?
It depends on the error. Simple fixes like correcting an IBAN or adjusting CtrlSum can be done by editing the XML directly. However, structural errors (wrong element order, missing namespace) usually require regeneration from the source system.
Does ValidateFin check all 15 errors?
Yes. ValidateFin validates your SEPA file against EPC XSD schemas, checks every IBAN with mod-97, verifies CtrlSum consistency, validates character encoding, and flags all structural issues. The validation runs entirely in your browser — no file is uploaded.
Why does my bank reject a file that passed XSD validation?
XSD validation only checks XML structure. Banks also apply business rules: valid execution dates, correct CtrlSum, unique MsgId, and proper IBAN/BIC. ValidateFin checks both schema and business rules.
Are SEPA error codes standardized?
Yes. Banks use ISO 20022 reason codes (e.g., AC01 for incorrect IBAN, AM05 for duplicate, AG01 for forbidden transaction type). The EPC maintains a complete list in the SEPA Reason Codes document.
How do I prevent SEPA errors in my ERP?
Implement IBAN validation at data entry, use a SEPA XML library (not string concatenation) for file generation, validate the output file before sending, and always test with your bank's validation tool first.
What happens when a SEPA file is rejected?
The bank returns a pain.002 status report with rejection reason codes for each failed transaction. You must fix the errors and resubmit the entire file or the affected payment block.
Can character encoding issues be silent?
Yes. Some characters (like smart quotes " " or em dashes —) look correct on screen but are outside the SEPA character set. They cause rejection without an obvious visual clue. ValidateFin flags these invisible encoding issues.
Is there a difference between pain.001.001.03 and .09 error handling?
The newer versions (09, 11) have stricter validation. Some fields that were optional in 03 are now mandatory. The character set restrictions are the same. ValidateFin validates against the specific version declared in your file.
How long do I have to fix a rejected SEPA file?
There is no standard deadline, but payment delays accumulate. Most treasury teams aim to fix and resubmit within 4 business hours. Pre-validation with ValidateFin eliminates most rejection scenarios.