1. Input and generation checks
Community and Pro. Your CSV, XLS, or XLSX data is checked before any XML is written: required fields, IBAN checksums, amounts and control totals, field limits, and XML character legality.
A rejected SEPA file usually means a cryptic bank error, a support call, and a delayed payment run. SEPA Generator checks your payment data locally before the pain.001 XML is generated, and SEPA Generator Pro validates the finished file — or a file another system produced — against the supported official schemas bundled with Pro, so common rejection causes are caught while they are still easy to fix.
Validation runs locally on your computer — payment files are never uploaded to a server.
SEPA validation covers several different things. Knowing which part does what makes it much easier to tell where a problem came from — and what any tool can and cannot promise.
Community and Pro. Your CSV, XLS, or XLSX data is checked before any XML is written: required fields, IBAN checksums, amounts and control totals, field limits, and XML character legality.
Pro. The generated file is validated against the supported official schemas bundled with Pro, so structural and element-level problems are found in the XML itself rather than by your bank.
Pro. The report explains the findings from the checks above — row, field, severity, message, and suggested correction — so you can review, share, or archive them. It presents results; it is not a separate validation mechanism.
Pro. A SEPA XML file produced by another system can be validated on its own, with the same schema validation and the same detailed report, before you send it.
Bank acceptance is a fifth, separate step that no tool controls — see the boundary note below.
Every generation run checks the input file and payment data against common SEPA input rules before any XML is written. This is real validation, included free.
Debtor and creditor IBANs are checked including checksum validation, along with BIC format and the initiating party SIRET where used.
Transaction amounts are checked for valid format, exact decimals and control totals are computed, and the requested execution date is validated before generation.
Missing required fields, field length limits including remittance information, end-to-end identifiers, and XML character legality are checked row by row.
Structured postal address data is validated when generating pain.001.001.09. See the pain.001.001.02 vs .09 guide for why structured addresses matter, and the SEPA structured address deadline for what changes on 15 November 2026.
Pro keeps every Community check and adds schema-level validation, an explanation of the findings, and the ability to check files it did not generate.
XSD validation against the supported official schemas bundled with Pro, applied to the file Pro generates and to SEPA XML produced by another system. Duplicate warnings and character/interoperability warnings flag values that are technically valid but commonly cause trouble in bank systems.
Every finding is listed by row, field, severity, message, and suggested correction, exportable as an HTML report to review, share, or archive. See a real example report. Explore SEPA Generator Pro.
Validation helps detect common input errors and schema problems, but final acceptance can still depend on your bank, upload channel, account configuration, the required message version, and bank-specific rules. Test your first production file with your banking portal.
No — and that is deliberate. SEPA payment files contain names, IBANs, and amounts. SEPA Generator is a desktop app that validates and generates files locally, so your payment data never leaves your computer.
The Community Edition validates your input data (CSV, XLS, XLSX) before generating the XML. SEPA Generator Pro can additionally validate an existing SEPA XML file you already have, using XSD validation against the supported official schemas bundled with Pro.
The checks are what finds problems: input and generation checks in Community, and XSD validation against the supported official schemas bundled with Pro. The detailed HTML report is how Pro explains those findings — row, field, severity, message, and suggested correction — so it presents results rather than performing a separate kind of validation.
No. Validation catches common input errors and schema problems early, which removes the most frequent avoidable causes of rejection. Final acceptance can still depend on your bank, upload channel, account configuration, the required message version, and bank-specific rules, so always test your first production file with your banking portal.
Download the free Community Edition and let it check your payment data before every generation — locally, on your computer. Need XSD validation, detailed reports, or validation of existing SEPA XML? Explore Pro.
Generating pain.001 files? About pain.001 generation. Working with direct debits? About pain.008 generation.