SEPA XML File Format Explained (2026 UK Guide)
2026-05-03
Your payment file looked fine in Excel. The amounts matched. The supplier names were there. You uploaded it to the bank portal, clicked submit, and got a rejection that said something like “invalid schema”, “illegal character”, or “message ID length exceeded”.
That moment catches a lot of finance teams off guard because the problem usually isn’t the payment itself. It’s the file format.
A SEPA XML file is the format many banks expect when you send euro payment instructions or direct debit collections. For a UK business paying European suppliers, collecting euro subscriptions, or running cross-border payroll, that “technical” file quickly becomes an operations issue. One wrong character, one missing field, or one outdated version can stop the whole run.
This guide gives you a practical SEPA XML file format explained in plain English. It’s written for the person who starts with Excel or CSV, not for someone who wants to memorise XML rules. You’ll see what the file is, how it’s structured, which fields matter, why banks reject submissions, and how teams move from spreadsheets to a bank-ready file without constant trial and error.
Your Guide to the SEPA XML Format
The usual problem starts on a busy day. Accounts payable is trying to send supplier payments. Accounts receivable is preparing a direct debit run. Someone exports data from the ERP, tidies a spreadsheet, and assumes the bank upload will be straightforward.
Then the bank rejects the file.
The message is often too technical to be useful to a non-technical user. “UTF-8 issue” doesn’t help much when you’re staring at customer names copied from a spreadsheet. “pain.001 validation error” doesn’t explain why your file won’t upload before the cut-off time.
That’s why this topic matters to finance managers, administrators, bookkeepers, and small business owners. SEPA XML isn’t just an IT format. It’s the exact shape your payment instructions need to take so the bank can read them without ambiguity. If the shape is wrong, the bank won’t guess what you meant.
Practical rule: Treat a SEPA file like a bank form completed by machine. Every box must exist, the data must sit in the correct box, and the wording must follow the bank’s rules.
For UK businesses, this matters most when handling euro payments and collections. The operational pressure is familiar. Payroll has a deadline. A supplier is waiting. A customer collection run needs to go out today, not after three rounds of format fixes.
The good news is that the file itself is more logical than it first appears. Once you stop seeing XML as code and start seeing it as a structured form, it becomes much easier to understand. The tags are labels. The nesting shows which pieces belong together. The validations are strict, but they’re consistent.
If you’ve ever wondered why a neat spreadsheet turns into a rejected upload, the answer is usually here. The spreadsheet has the data. The SEPA XML file gives that data the exact structure the bank expects.
What Is a SEPA XML File?
A SEPA XML file is a standard digital format used to send payment instructions between businesses and banks. Think of it as a universal template for money movement. Instead of every bank reading a different spreadsheet layout or legacy file type, they all expect the same structured language.
A standard language for banks
The technical standard behind it is ISO 20022. In practical terms, that means your payment data is organised in a format banks can validate automatically. If you want a broader primer before diving into the file itself, Tagada’s guide to understanding SEPA gives useful context on the payment area and why the standard exists.
A simple analogy helps here. If your spreadsheet is a stack of payment notes, SEPA XML is the official envelope and document layout that every bank clerk agrees to accept. The recipient bank doesn’t need to interpret your internal column names or guess whether “Ref” means invoice number, payroll batch, or customer account. The tags define that precisely.
This standardisation has had a real effect in the UK. The SEPA XML format, standardised under ISO 20022 pain.001.001.03, uses a Group Header with a unique <MsgId> of up to 35 characters and a creation timestamp <CreDtTm>, followed by Payment Information and Transaction Details. After the 2014 SEPA migration, UK SMEs saw direct debit processing errors fall by 45%, according to The Information Lab’s summary of SEPA XML structure and migration impact.
Two common file types
In day-to-day finance work, you’ll usually meet two main SEPA message types:
-
Credit Transfer, PAIN.001
Used when your business is sending money out, such as supplier payments or salary payments. -
Direct Debit, PAIN.008
Used when your business is collecting money from customers who have authorised you to debit their account.
The file type matters because the required fields differ. A supplier payment doesn’t need a debit mandate. A direct debit does.
A short visual overview can make the terminology less intimidating:
Why non-technical teams should care
You don’t need to become an XML specialist. You do need to know what the bank is asking for. Once you recognise that PAIN.001 means outgoing transfers and PAIN.008 means direct debit collections, most of the confusion starts to fade.
The rest is mostly about matching business data to the right labelled fields, then checking that the file version, characters, dates, and identifiers all meet the schema rules.
Anatomy of the SEPA XML Structure
A SEPA XML file looks dense because it uses nested tags. The easiest way to read it is like a set of folders inside folders. The outer folder contains the whole document. Inside that, one section identifies the file itself, another groups shared payment details, and another lists the individual transactions.
The root document
At the top sits the <Document> element. This is the outer container. It tells the bank’s system, “everything inside here belongs to one SEPA message”.
Inside the document, you’ll see a message type container such as <CstmrCdtTrfInitn> for credit transfers or a direct debit equivalent. You can ignore the abbreviations at first. Their job is to identify what sort of message the document contains.
Group Header
The Group Header, shown as <GrpHdr>, works like the cover sheet for the whole file. It carries information that applies at file level rather than transaction level.
Common examples include:
<MsgId>for the file’s unique message ID<CreDtTm>for the file creation date and time- summary values that help the bank understand the batch
This section matters because the bank uses it to identify, track, and validate the file before looking at the line-by-line payments.
A useful mental model is this: if the XML file were a courier bag, the Group Header would be the shipping label on the outside.
Payment Information
The next major block is <PmtInf>, short for Payment Information. This groups transactions that share the same operational context.
That might include the account being debited, the requested execution date, the payment method, and service-level instructions. Rather than repeating that same information for every single payment, the file states it once for the group.
Many readers get confused, expecting every transaction to be fully self-contained. In SEPA XML, some details live at the batch level and some live at the transaction level. If you place shared data in the wrong place, the bank can reject the file even if the values themselves are correct.
Transaction Details
Inside <PmtInf>, you then get the individual payment entries. For credit transfers this is commonly <CdtTrfTxInf>. For direct debits, the transaction element differs, but the idea is the same.
Each transaction contains the details for one payment or collection, such as:
- the amount
- the beneficiary or debtor
- the IBAN
- the reference information
- transaction-specific identifiers
A simple hierarchy example
Here’s the structure in plain language:
| Level | What it does | Example |
|---|---|---|
| Document | Holds the entire message | One uploaded file |
| Group Header | Identifies the file | Message ID, creation timestamp |
| Payment Information | Groups shared batch details | Debit account, execution date |
| Transaction Details | Holds one specific payment | One supplier payment or one customer collection |
When people say XML is “strict”, they usually mean this hierarchy must be respected. You can’t casually move a tag because it “looks like it belongs there”. The structure itself is part of the instruction.
Key Elements for Transfers and Direct Debits
A finance manager preparing a first SEPA submission often starts with a simple question: “Which fields are different for a supplier payment versus a customer collection?” That is where many spreadsheet-to-XML projects go off course. The file format looks similar at first glance, but PAIN.001 credit transfers and PAIN.008 direct debits carry different instructions, and the bank checks those differences closely.
A practical way to read the tags is to treat them like labelled boxes on a payment form. Some boxes appear in both file types. Others exist only because a direct debit needs proof of authorisation, while a credit transfer does not.
The side by side view
| Element Purpose | Credit Transfer (PAIN.001) Tag | Direct Debit (PAIN.008) Tag |
|---|---|---|
| File message identifier | <MsgId> |
<MsgId> |
| File creation timestamp | <CreDtTm> |
<CreDtTm> |
| Payment batch information | <PmtInf> |
<PmtInf> |
| Individual transaction block | <CdtTrfTxInf> |
<DrctDbtTxInf> |
| End-to-end reference | <EndToEndId> |
<EndToEndId> |
| Debtor account in batch context | <DbtrAcct> |
Often creditor and collection context apply instead |
| Creditor account in transaction context | <CdtrAcct> |
Collection goes to creditor account context |
| Amount | <InstdAmt> |
<InstdAmt> |
| Mandate details | Not usually required | <MndtId> and mandate signature date details |
| Creditor agent or debtor agent details | <CdtrAgt> and related bank tags |
Equivalent bank routing tags in debit structure |
Credit transfer essentials
A PAIN.001 file is for money your business sends out, such as supplier payments, payroll, or expense runs.
A stripped-back example looks like this:
<CdtTrfTxInf>
<PmtId>
<EndToEndId>INV-10458</EndToEndId>
</PmtId>
<Amt>
<InstdAmt Ccy="EUR">1250.00</InstdAmt>
</Amt>
<Cdtr>
<Nm>ABC Industrial Supplies Ltd</Nm>
</Cdtr>
<CdtrAcct>
<Id>
<IBAN>IE00BANK00000000000000</IBAN>
</Id>
</CdtrAcct>
</CdtTrfTxInf>
Read this as a payment instruction form:
<EndToEndId>is your tracking reference<InstdAmt>is the amount to send<Nm>is the payee name<IBAN>is the destination account
A common error is exporting outgoing payments as negative amounts because that is how they appear in an accounting system. In the XML instruction, <InstdAmt> should be a positive value, with the payment type itself indicating that money is leaving your account. The EPC SEPA Credit Transfer customer-to-PSP implementation guidelines set out how these fields are structured and validated.
Direct debit essentials
A PAIN.008 file is for collecting money from customers. Because you are pulling funds rather than pushing them out, the file must include mandate information that shows the collection has been authorised.
A simplified example:
<DrctDbtTxInf>
<PmtId>
<EndToEndId>SUBSCRIPTION-MAY</EndToEndId>
</PmtId>
<InstdAmt Ccy="EUR">49.00</InstdAmt>
<DrctDbtTx>
<MndtRltdInf>
<MndtId>MANDATE-2024-001</MndtId>
<DtOfSgntr>2024-03-01</DtOfSgntr>
</MndtRltdInf>
</DrctDbtTx>
<Dbtr>
<Nm>Jane Example</Nm>
</Dbtr>
</DrctDbtTxInf>
The extra fields matter for a simple reason. A bank needs more than the amount and the customer name. It also needs the instruction that links the collection back to the signed mandate.
<MndtId>identifies the customer’s direct debit mandate<DtOfSgntr>records the date that mandate was signed
If either value is missing, wrongly formatted, or inconsistent with your mandate records, the file may validate technically but still fail bank checks later in the process.
Validation points that matter in practice
For UK businesses converting from Excel or a legacy payment export, problems often start long before the upload. A worksheet may contain long internal references, copied special characters, or reused batch IDs. Those values look harmless on screen, but XML validation is less forgiving.
For example, <MsgId> is a file-level identifier, so it should be unique for the batch, short enough for the scheme and bank limits, and free of unsupported characters. The EPC SEPA Direct Debit Core customer-to-PSP implementation guidelines explain these field rules in detail.
Before you upload, it helps to run a SEPA XML validation check before submission. That catches the problems that often appear during conversion from business-friendly formats into bank-friendly XML.
Fields that are easy to misread
End-to-end ID
The <EndToEndId> is your transaction reference, not an account identifier. It works like the reference box on an invoice or remittance advice. Use something your team can trace later, such as an invoice number, payroll run code, or subscription reference.
That choice matters when a supplier phones about a missing payment or a customer disputes a collection.
Message ID
The <MsgId> identifies the whole file, not one transaction inside it. If you reuse it across multiple submissions, some bank systems may treat the new file as a duplicate. A clear naming rule helps, especially when your SEPA XML is generated from spreadsheets and someone is tempted to copy last month’s file and just change the amounts.
The practical test is simple. If a finance colleague can point to a tag and explain what business question it answers, the mapping is usually sound. If the team cannot explain it without referring back to a schema document, that field needs another review before submission.
Common Validation Errors and How to Fix Them
A finance manager exports a payment run from Excel, converts it to XML, uploads the file, and gets back a vague message such as “invalid schema” or “unexpected character”. That moment is where SEPA starts to feel harder than it is.
In practice, SEPA validation errors usually come from a short list of issues: text that contains unsupported characters, dates or timestamps in the wrong format, fields that exceed allowed lengths, account details that fail checks, or tags placed in the wrong part of the file. The trick is to trace the error back to the source data, not just stare at the finished XML.
Illegal characters in names and text fields
Text fields often cause trouble because they are copied in from business systems that were never designed with XML rules in mind. A supplier name from Excel, a customer record pasted from email, or a payment reference copied from a PDF can all carry hidden characters.
Symptom: The bank flags an invalid character, rejects the file during upload, or reports a schema validation problem.
Diagnosis: A field such as <Nm>, address data, or a reference contains unsupported symbols, smart quotes, extra line breaks, or characters your bank’s accepted SEPA variant does not allow.
Cure: - remove unsupported characters before export - trim leading and trailing spaces - standardise text cleaning in your spreadsheet or ERP extract - check pasted values from Word, PDFs, and email signatures
XML tags work like labelled boxes on a paper form. If the box only accepts certain characters, a perfectly normal business name can still fail when the file is checked by the bank.
Timestamp mismatches
The <CreDtTm> field is easy to overlook because it looks administrative rather than financial. Yet banks use it to assess when the file was created, and small formatting differences can trigger rejection.
Symptom: The file uploads but fails checks related to creation date, sequencing, or message format.
Diagnosis: The export tool writes the timestamp in the wrong ISO format, uses the wrong timezone handling, or takes the value from a system clock that is incorrect.
Cure: 1. confirm that the timestamp follows the required ISO date-time format 2. check the server or desktop clock on the system generating the file 3. avoid editing timestamps by hand inside the XML 4. test output separately for each bank portal if you submit to more than one bank
A good rule is simple. If your team would not manually type that value into a bank form, they should not manually edit it in XML either.
Schema structure errors
Sometimes every amount, IBAN, and name looks correct, but the file still fails. That usually means the problem sits in the structure of the XML itself.
Symptom: Errors such as “invalid schema”, “unexpected element”, or “file not compliant”.
Diagnosis: A required parent tag is missing, an element appears in the wrong order, or the file uses a message version the bank does not accept.
Cure: - validate the XML against the correct XSD before upload - confirm the accepted pain.001 or pain.008 version with your bank - avoid rearranging tags manually unless you understand the hierarchy - compare the generated file with a bank-approved sample
If you want a practical workflow, this guide on how to validate a SEPA XML file before submission shows the checks worth running before you upload.
Bank messages often describe the symptom rather than the cause. One misplaced closing tag can surface as a generic schema error.
Length limits and overfilled fields
SEPA fields are closer to predefined boxes on a payment form than open text areas. Each box has a limit, and conversion tools can accidentally overfill them when they merge several business values into one tag.
Symptom: The file appears readable, but the bank rejects it without an obvious formatting issue.
Diagnosis: A field such as a message ID, name, or remittance reference is longer than the allowed maximum.
Cure: - apply character limits in the source spreadsheet - split combined references into separate columns before conversion - shorten internal descriptions that are only useful inside your ERP - test edge cases, such as long supplier names or batched invoice references
This type of error is common during spreadsheet-to-XML conversion because a single Excel cell can hold far more text than the XML field it maps to.
IBAN and account detail errors
IBAN problems look small on screen and cause big delays in practice. One missing character, one stray space, or one account number mapped into the wrong tag is enough to stop a file or return a payment later.
Symptom: Rejection during upload, or a payment that fails after initial acceptance.
Diagnosis: The IBAN format is invalid, the BIC or account detail is in the wrong element, or the account owner data and account number come from different source records.
Cure: - validate IBANs before generating the XML - remove spaces unless your software normalises them automatically - keep beneficiary name and account details sourced from the same master record - review any manual edits made after export
This is also where older systems create avoidable friction. If your finance data sits across disconnected tools, the wider task may include work to connect old ERP to modern AI and cleaner validation steps before the SEPA file is generated.
Teams usually fix SEPA validation problems faster once they stop treating the XML as the starting point. The XML is only the final container. The essential work is cleaning, mapping, and checking the source data that fed it.
From Spreadsheets and Legacy Formats to SEPA XML
Most finance teams don’t start with XML. They start with a spreadsheet, a CSV export, or a legacy banking format created years ago for one specific bank. That’s why the challenge isn’t entering payment data from scratch. It’s mapping familiar columns into the exact XML fields required for submission.
Think in columns to tags
Suppose your spreadsheet has these columns:
| Spreadsheet column | Meaning in plain English | Likely XML destination |
|---|---|---|
| Supplier Name | Who gets paid | <Nm> |
| IBAN | Destination account | <IBAN> |
| Amount EUR | Payment amount | <InstdAmt> |
| Invoice Ref | Your payment reference | <EndToEndId> |
| Payment Date | Requested execution date | Batch-level payment date field |
That’s the conversion process in essence. You’re not inventing data. You’re assigning each column to the right labelled field in a stricter structure.
For the 70% of UK PYMEs using Excel for payment runs, this mapping step is critical. Proper IBAN validation during conversion can reduce payment bounce rates by 62%. The November 2025 sunset of the 2009 XML version also raises the pressure on the 2.1 million UK SMEs that rely on SEPA for a quarter of their euro exports, according to SoA People’s summary of the upcoming SEPA XML changes.
Why manual conversion breaks down
Manual conversion sounds manageable when there are only a few transactions. It gets risky when:
- one spreadsheet column mixes two meanings
- dates are stored in inconsistent formats
- names contain copied formatting or unsupported characters
- one bank wants a different version than another
- an old ERP export still reflects a legacy banking layout
That’s where legacy systems become part of the payments problem. If your source data comes from an older platform, the challenge isn’t only formatting. It’s integration. Teams dealing with that broader issue may find this article on how to connect old ERP to modern AI helpful because it addresses the practical gap between older operational systems and newer automation workflows.
A realistic conversion workflow
A sensible spreadsheet-to-XML process often looks like this:
- export the payment data from your ERP or accounting system
- clean names, references, and dates in Excel or CSV
- map each column to the correct SEPA field
- validate IBANs and field lengths
- generate the XML
- validate the finished file before upload
If you want a dedicated example of that path, this guide on converting CSV to SEPA XML shows the flow clearly.
The important point is that XML generation is only the last step. Most rejections begin earlier, in the source file.
Automating Conversion with ConversorSEPA
At some point, organizations often decide they don’t want staff manually checking tags, lengths, and encodings before every bank run. That’s where automation becomes more practical than hand-built exports.
What automation changes
Instead of asking a finance manager to understand XML syntax, an automated workflow asks for something much simpler:
- upload the file you already have
- map the columns once
- validate the critical fields
- generate a bank-ready SEPA XML output
That approach becomes more useful as version requirements change. With the mandatory migration to newer pain.001 XML versions by March 2026, UK SMEs face increased API integration challenges. 42% of SMEs reported payment delays from version mismatches in H2 2025, and post-Brexit variances can spike errors by 18%. Region-specific cloud validators such as ConversorSEPA’s API, which is described with 99.9% uptime, are highlighted in GenerateSEPA’s discussion of SEPA document changes and UK-specific migration issues.
That matters because version drift is hard to manage manually. A spreadsheet doesn’t tell you whether a bank now expects a different schema variant.
Where a tool fits in the workflow
A service like ConversorSEPA is built for the common situation this article has focused on: you already have payment data in Excel, CSV, JSON, or older AEB-style files, and you need valid SEPA XML for transfers or direct debits. The practical functions are straightforward:
- convert familiar file formats into SEPA XML
- map business columns to required SEPA fields
- validate IBANs and key file elements before submission
- support API-driven automation for technical teams
- remove the need to hand-edit XML
For developers, an API matters because SEPA generation can become part of a larger finance workflow rather than a manual monthly task. If that’s your route, this overview of a SEPA XML API is a useful place to compare how API-based generation works.
Why finance and AP teams care
The benefit isn’t that automation makes XML “fancy”. The benefit is that it makes routine payment operations less fragile. That aligns with broader enterprise AP best practices, where the goal is cleaner upstream data, fewer manual exceptions, and more reliable approval-to-payment workflows.
The strongest payment process isn’t the one with the cleverest file format. It’s the one that removes preventable errors before the bank sees them.
If your team still spends time fixing rejected uploads after the fact, the primary value of automation is consistency. The same mapping. The same validation. The same output rules every time.
Your Pre-Submission Checklist
Before you upload your next file, pause for a final review. A SEPA XML submission is usually rejected for a small reason, not a mysterious one.
Use this checklist:
- Confirm the file type: Make sure you’re submitting PAIN.001 for credit transfers or PAIN.008 for direct debits.
- Check the version requirement: Your bank may require a newer schema version than the one your ERP still exports.
- Review the message ID: Keep
<MsgId>unique, within the allowed length, and free of unsupported characters. - Verify the timestamp: Ensure
<CreDtTm>uses the correct ISO date-time format. - Validate names and references: Remove unsupported characters, hidden formatting, and overlong values.
- Confirm UTF-8 encoding: Especially for direct debit files, encoding errors can cause rejection before content is even reviewed.
- Validate every IBAN: Don’t rely on visual checks.
- Check amount formatting: Make sure payment amounts are in the required format and context for the file type.
- For direct debits, confirm mandate data: Include the correct mandate ID and signature date where required.
- Run validation before upload: Don’t use the bank portal as your first test environment.
A good habit is to treat the XML output as the final stage of data quality, not the first. If the source spreadsheet is messy, the XML will merely formalise that mess.
If your team is still converting spreadsheets, CSV exports, or legacy bank files by hand, ConversorSEPA offers a practical way to generate SEPA XML files with built-in validation and support for common business formats, so you can focus on the payment run rather than the file syntax.
Frequently Asked Questions
- What is the SEPA XML file format?
- The SEPA XML file format is a standardised digital structure based on ISO 20022 used to send payment instructions between businesses and banks. It organises payment data into nested XML tags that banks can validate automatically. The two main types are pain.001 for credit transfers and pain.008 for direct debit collections.
- What is the difference between pain.001 and pain.008?
- Pain.001 is used for credit transfers, meaning your business is sending money out to suppliers, employees, or other payees. Pain.008 is used for direct debit collections, meaning your business is pulling funds from customer accounts. Direct debit files require additional mandate information such as the mandate ID and signature date that credit transfers do not need.
- Why does my SEPA XML file keep getting rejected by the bank?
- Most rejections stem from a short list of issues: unsupported characters in name or reference fields, incorrect date or timestamp formats, fields that exceed allowed character lengths, invalid IBANs, or XML tags placed in the wrong structural position. Tracing the error back to the source spreadsheet data rather than editing the XML directly is the most effective fix.
- How do I convert a spreadsheet to SEPA XML?
- The conversion process involves mapping each spreadsheet column to the correct SEPA XML field, cleaning the source data, validating IBANs and field lengths, then generating the XML file. Tools like ConversorSEPA automate this workflow by accepting Excel, CSV, or legacy file formats and producing valid SEPA XML with built-in validation checks before submission.
