SEPA XML files are the standard format for bank transfers and direct debits across Europe. Whether you are a treasurer, accountant or developer, understanding the structure of these files is essential for automating your payment workflows. This guide walks through every step, from XML structure to generation tools.
What is a SEPA XML file?
A SEPA XML file is a structured XML document that complies with the ISO 20022 standard. It allows you to initiate credit transfers (pain.001) or direct debits (pain.008) with your bank. The format is standardised across the entire SEPA area (Single Euro Payments Area), ensuring interoperability between the 36 member countries.
Unlike older proprietary formats (BACS in the UK, ACH in the US, CFONB in France), SEPA XML provides a universal structure accepted by every bank in the euro zone. Each file contains a group header (GroupHeader), payment information blocks (PaymentInformation) and individual transactions (CreditTransferTransactionInformation or DirectDebitTransactionInformation).
Unlike older proprietary formats (BACS in the UK, ACH in the US, CFONB in France), SEPA XML provides a universal structure accepted by every bank in the euro zone. Each file contains a group header (GroupHeader), payment information blocks (PaymentInformation) and individual transactions (CreditTransferTransactionInformation or DirectDebitTransactionInformation).
Understanding pain.001 and pain.008
The ISO 20022 standard defines several message types for payments:
pain.001 (CustomerCreditTransferInitiation): used to initiate one or more credit transfers. The business sends this file to its bank to order payments to beneficiary accounts. It is the most common format for supplier payments, payroll and refunds.
pain.008 (CustomerDirectDebitInitiation): used to initiate SEPA direct debits. The creditor sends this file to its bank to collect funds from debtor accounts. It requires a signed mandate (identified by a UMR — Unique Mandate Reference) and a SEPA Creditor Identifier (SCI/ICS).
Each format follows an XSD (XML Schema Definition) that precisely defines the allowed fields, their order and their constraints.
pain.001 (CustomerCreditTransferInitiation): used to initiate one or more credit transfers. The business sends this file to its bank to order payments to beneficiary accounts. It is the most common format for supplier payments, payroll and refunds.
pain.008 (CustomerDirectDebitInitiation): used to initiate SEPA direct debits. The creditor sends this file to its bank to collect funds from debtor accounts. It requires a signed mandate (identified by a UMR — Unique Mandate Reference) and a SEPA Creditor Identifier (SCI/ICS).
Each format follows an XSD (XML Schema Definition) that precisely defines the allowed fields, their order and their constraints.
Structure of a pain.001 file
A pain.001 file consists of three levels:
1. GroupHeader (GrpHdr): contains the message identifier, creation date/time, number of transactions and control sum. This block appears once per file.
2. PaymentInformation (PmtInf): groups the originator's details — name, IBAN, BIC, requested execution date and payment method (TRF for transfers). A file can contain multiple PmtInf blocks.
3. CreditTransferTransactionInformation (CdtTrfTxInf): details each transaction — amount, currency, beneficiary IBAN and name, end-to-end reference (EndToEndId) and remittance information. This is where each payment line is specified.
1. GroupHeader (GrpHdr): contains the message identifier, creation date/time, number of transactions and control sum. This block appears once per file.
2. PaymentInformation (PmtInf): groups the originator's details — name, IBAN, BIC, requested execution date and payment method (TRF for transfers). A file can contain multiple PmtInf blocks.
3. CreditTransferTransactionInformation (CdtTrfTxInf): details each transaction — amount, currency, beneficiary IBAN and name, end-to-end reference (EndToEndId) and remittance information. This is where each payment line is specified.
Required fields and best practices
Every SEPA XML file must contain at minimum:
• MsgId: unique message identifier (max 35 characters).
• CreDtTm: creation date and time in ISO 8601 format.
• NbOfTxs: total number of transactions in the file.
• CtrlSum: control sum (total of all amounts).
• IBAN and BIC of the originator and beneficiaries.
• Amount (InstdAmt): with currency code (EUR for SEPA).
• EndToEndId: unique reference per transaction for tracking.
Best practices: use unique, traceable identifiers; validate every IBAN using the MOD 97-10 algorithm (ISO 13616); and always validate the file against the XSD schema before submitting it to your bank.
• MsgId: unique message identifier (max 35 characters).
• CreDtTm: creation date and time in ISO 8601 format.
• NbOfTxs: total number of transactions in the file.
• CtrlSum: control sum (total of all amounts).
• IBAN and BIC of the originator and beneficiaries.
• Amount (InstdAmt): with currency code (EUR for SEPA).
• EndToEndId: unique reference per transaction for tracking.
Best practices: use unique, traceable identifiers; validate every IBAN using the MOD 97-10 algorithm (ISO 13616); and always validate the file against the XSD schema before submitting it to your bank.
XSD validation: why and how
XSD validation checks that your XML file complies with the structure defined by the official ISO 20022 schema. A structural error — a missing field, incorrect date format or malformed amount — will cause a bank rejection, often incurring fees and delays.
To validate a file, you can use an online tool such as the ISO 20022 validator built into our platform. It detects schema errors, verifies IBANs and BICs, and flags common inconsistencies like past execution dates or zero amounts.
Upfront validation dramatically reduces bank rejections and speeds up payment processing.
To validate a file, you can use an online tool such as the ISO 20022 validator built into our platform. It detects schema errors, verifies IBANs and BICs, and flags common inconsistencies like past execution dates or zero amounts.
Upfront validation dramatically reduces bank rejections and speeds up payment processing.
Tools for generating SEPA XML files
Several approaches exist for creating SEPA XML files:
Custom development: technical teams can use XML libraries to build files from their data. This offers full control but requires development and maintenance time.
ERP/accounting export: some accounting software (Sage, SAP, Xero) offers native SEPA XML export. Quality varies by vendor and version.
Online generator: tools like ISO 20022 Generator let you create compliant pain.001 and pain.008 files directly in the browser. Simply import a CSV/Excel file or enter data manually. The file is validated against the XSD schema and ready for immediate download.
Regardless of the method, the key is to validate every file before submission to avoid costly rejections.
Custom development: technical teams can use XML libraries to build files from their data. This offers full control but requires development and maintenance time.
ERP/accounting export: some accounting software (Sage, SAP, Xero) offers native SEPA XML export. Quality varies by vendor and version.
Online generator: tools like ISO 20022 Generator let you create compliant pain.001 and pain.008 files directly in the browser. Simply import a CSV/Excel file or enter data manually. The file is validated against the XSD schema and ready for immediate download.
Regardless of the method, the key is to validate every file before submission to avoid costly rejections.
Common mistakes to avoid
The most frequent causes of rejection are:
• Invalid IBAN: typos or incorrect check digits. Verify every IBAN with a validation algorithm.
• Missing or incorrect BIC: some banks require the BIC even though it is theoretically optional within SEPA.
• Past execution date: the date must be a future business day.
• Zero or negative amount: every transaction must have a strictly positive amount.
• Duplicate MsgId: the message identifier must be unique for each file submitted.
• Incorrect encoding: the file must be UTF-8 encoded without BOM.
An upfront validator catches these issues before they reach your bank.
• Invalid IBAN: typos or incorrect check digits. Verify every IBAN with a validation algorithm.
• Missing or incorrect BIC: some banks require the BIC even though it is theoretically optional within SEPA.
• Past execution date: the date must be a future business day.
• Zero or negative amount: every transaction must have a strictly positive amount.
• Duplicate MsgId: the message identifier must be unique for each file submitted.
• Incorrect encoding: the file must be UTF-8 encoded without BOM.
An upfront validator catches these issues before they reach your bank.