How to create a SEPA XML file from CSV or Excel

Last updated: 10 July 2026

Creating a SEPA Credit Transfer file sounds intimidating — ISO 20022, pain.001, XML namespaces — but the actual workflow is straightforward once it is broken into steps. This guide walks through the full process using SEPA Generator, a free local desktop app, though the overall workflow applies to any serious tool.

The steps: prepare the data, pick an input format, validate, choose the pain.001 version, generate locally, review the result, and test with your bank.

Step 1: Prepare your payment data

Every SEPA credit transfer batch needs the same core information:

• Debtor side: your company name and IBAN (the account that pays), and where applicable an identifier such as a SIRET.
• Per payment: creditor name, creditor IBAN, amount in euros, and remittance information (what the payment is for — max 140 characters unstructured).
• Batch level: the requested execution date.

Gather this in one place before anything else. Most errors in generated files trace back to gaps or typos in this source data — see common rejection errors for what typically goes wrong.

Step 2: Choose your input format — CSV, XLS, or XLSX

Where does your data live?

• In a spreadsheet a person maintains — keep it in Excel and use the XLS/XLSX file directly. See Excel to SEPA XML for the Excel-specific workflow.
• In an accounting system, ERP, or payroll tool — export a CSV batch. See CSV to SEPA XML for that route, including recurring and scripted exports.

Either way, the columns need to follow the expected layout. SEPA Generator ships with input templates for both CSV and Excel, available from inside the app, so you can start from a file with the right columns instead of guessing.

Step 3: Check the debtor configuration

Set up the paying account once: company name, IBAN, and identifiers. In SEPA Generator this is part of the app settings, so recurring payment runs do not need to repeat debtor data in every input file. Double-check the debtor IBAN — an error here affects every payment in the batch.

Step 4: Choose the pain.001 version

Banks accept specific pain.001 versions per upload channel, most commonly pain.001.001.02 (long-established) or pain.001.001.09 (the current 2019 ISO 20022 revision with structured address support).

Check your bank’s documentation or ask your contact which version your channel expects. If you are unsure how the versions differ, read pain.001.001.02 vs pain.001.001.09. In SEPA Generator you simply select the version at generation time — the same input file can produce either.

Step 5: Generate the XML — locally

Open your CSV or Excel file in the app, confirm the execution date and pain.001 version, and generate. The XML file is written to your computer.

This local step matters more than it seems: a payment file contains names, IBANs, and amounts. With a desktop tool, that data never leaves your machine — there is no upload to a website, no third-party processing, and nothing to trust but your own computer.

Step 6: Review validation results

Before generating, SEPA Generator validates the input: IBAN checksums, BIC format, amounts, execution date, required fields, and remittance length, among others. If validation fails, the app reports what is wrong and where.

Fix problems in the source data (the spreadsheet or the system that produced the export), then regenerate. Never hand-edit the generated XML — it invites structural errors that are much harder to find.

When validation passes, open the generation summary and sanity-check the totals: number of transactions and total amount should match what you expect from the source file.

Step 7: Test with your bank before production use

Standards conformance is necessary but not sufficient: banks apply their own rules per channel and account, from accepted message versions to batch limits and field conventions.

For your first file (and after any format change):

1. Prepare a minimal test batch — one small payment is enough.
2. Upload it through the real target channel (web portal, EBICS, host-to-host).
3. Confirm it is accepted and, ideally, that the payment settles as expected.
4. Only then run production batches.

If the bank rejects the file, the rejection reason usually maps to one of the common rejection errors — or to a channel rule your bank can clarify.

Recap

Step	What to do
1	Collect debtor, creditor, amount, and remittance data
2	Use Excel directly or export CSV from your system
3	Configure and double-check the debtor account
4	Confirm the pain.001 version your bank expects
5	Generate the XML locally
6	Fix validation errors at the source; check the summary
7	Test with your bank’s channel before production

The free Community Edition covers this entire workflow — CSV/XLS/XLSX input, templates, validation, and both pain.001 versions — processing everything locally on your computer.