This page shows a real validation report written by SEPA Generator Pro — not a mock-up. We built a small direct debit file with deliberate mistakes, ran it through the same validation pipeline the desktop application uses before it generates pain.008.001.08 XML, and published the exact HTML report it produced. Read it to see what is checked, how each finding points at a specific row and field, and where validation ends and your bank's own rules begin.
Every value in this example is fictional. The companies are invented, the references are marked SYNTH and RUM-TEST, and the account numbers are published sample IBANs — one deliberately corrupted so the checksum fails. Nothing comes from a real mandate, customer or account, and none of these files may be submitted to a bank.
The report was generated locally by the production report writer, with a fixed timestamp so the example can be reproduced exactly. Its summary reads:
| Summary field | Value |
|---|---|
| Message type | pain.008.001.08 (SEPA Core direct debit) |
| Validation result | Validation failed |
| Errors | 2 |
| Warnings | 3 |
| Collections in the file | 7 |
| Control total | 521.15 EUR |
Two errors stop generation; three warnings do not. That distinction is the point of the report: an error means the file cannot be written correctly from this data, a warning means the data is usable but worth a second look.
A fictional gym, "Solstice Fitness Studios (EXAMPLE)", collects seven monthly membership fees by SEPA Core Direct Debit for a collection date of 15 June 2030. The spreadsheet was seeded with five problems and left otherwise correct, so valid rows sit next to broken ones as they would in a real export.
One debtor IBAN has an altered digit, so its check digits fail. One
row carries the sequence type MONTHLY, which is not a
SEPA value. One collection is an exact duplicate of the row above it.
One end-to-end reference contains an ampersand. One remittance text
contains a character outside the Latin-1 range.
The remaining rows are ordinary collections with mandate references, signature dates in the past and amounts within the scheme ceiling. They appear in the control total but produce no findings — a clean row is simply absent from the diagnostics table.
The input file is published alongside the report, so you can compare them line by line: download the synthetic CSV. Its column names are the SEPA Generator import format described on the Direct Debit generator page; your own headers can be mapped instead.
The layout is the same for credit transfers and direct debits, and the same whether the run passed or failed.
Each finding below is quoted verbatim from the published report. What matters as much as the message is the layer it comes from: a schema violation, a scheme rule, a preventive check and an interoperability advisory are four different kinds of problem.
The IBAN "NL91ABNA0417164301" is invalid: the MOD 97 check digits are incorrect.
Suggested correction: Verify the debtor IBAN, including its length and check digits.
One digit of a published Dutch sample IBAN was changed, so the international check digits no longer match the account number. The XML schema cannot see this — an IBAN is just a string to the XSD — but the receiving bank will. Correct the account number in the source row.
SEPA Generator preventive check, implementing the ISO 13616 IBAN standardSequence type "MONTHLY" is not valid. Use FRST (first collection), RCUR (recurring), OOFF (one-off) or FNAL (final collection)
Suggested correction: Use FRST, RCUR, OOFF or FNAL.
A column that means "billed monthly" in your own system is not a SEPA sequence type. The scheme allows exactly four values, and the schema itself would reject anything else, so the file is stopped before generation rather than after upload.
SEPA Generator preventive check enforcing the ISO 20022 and EPC sequence-type code listProbable duplicate of row 5: same debtor IBAN, amount, mandate reference and sequence type.
Suggested correction: If this collection is intended more than once, check the mandate and end-to-end references.
Rows 5 and 6 are identical, which is what an accidental double export looks like. A duplicate collection is valid XML and the scheme does not forbid it, so this is a warning: only you know whether the same debtor really should be collected twice. This check has no equivalent in any rulebook; it exists because the mistake is common and expensive.
SEPA Generator heuristic — not a scheme ruleThe end-to-end reference contains a character that is not in the SEPA character set: "&". This character does not by itself violate the XML schema, but some banks may reject or alter this value.
Suggested correction: Use only letters, digits, spaces and / - ? : ( ) . , ' +
The reference SYNTH&DD-0005 is escaped correctly in the XML and passes schema validation. The EPC implementation guidelines nevertheless define a restricted character set for references, and identifiers travel through many systems before they reach the debtor's bank. Renaming the reference costs nothing.
EPC character-set guidance, surfaced as an advisoryThe remittance information contains a character outside the Latin-1 range: "花". This character does not by itself violate the XML schema, but some banks may not accept or preserve it.
Suggested correction: Consider replacing unusual characters with plain Latin equivalents.
The file is UTF-8 and the schema is satisfied, so this is not an error. It is a warning because handling of characters beyond Latin-1 is one of the areas where banks genuinely differ: some pass the text through, some transliterate it, some reject the message.
Interoperability advisory about bank-specific handlingWarnings are advisory. None of the three above makes the file invalid, and a bank may well process all of them without comment — but each one describes a situation where something can go wrong that the schema cannot see.
"Valid XML" is a narrower statement than most people expect. The report separates it from everything else.
Whether the document conforms to the official ISO 20022 schema for the detected message version. It catches structure, element order, data types and code lists, and nothing else. A file full of wrong IBANs can be perfectly schema-valid.
The EPC implementation guidelines add requirements the schema does not express: the allowed character set for references, the amount ceiling, mandate data expectations.
Checks the application performs because they save you a rejection: IBAN check digits, BIC format, decimal precision, field lengths, missing mandate references and probable duplicates. The duplicate check is a deliberate heuristic, not a rule.
Requirements set by your bank, payment service provider, upload channel or contract, which no independent tool can see. Validation catches many avoidable structural and data issues, but no independent validator can guarantee acceptance by every bank or submission channel.
Address data is handled separately again: Address Readiness is a report-only review of the address fields in an existing file, and it does not appear here because pain.008 files generated by SEPA Generator carry no postal address. See what changes on 15 November 2026. Message-version migration is a separate workflow too, and it converts files rather than repairing data.
The report above comes from input validation: the checks that run on your imported data before any XML exists. Pro also validates XML files it did not create, and that is a deliberately narrower workflow — the file is checked against the bundled official schema and nothing else, because there is no source spreadsheet to compare it with.
A small pain.008.001.08 Core file with two collections, one of which
carries <SeqTp>WEEKLY</SeqTp> — a value that
does not exist in the schema's code list.
Download the invalid XML.
Validation failed, schema pain.008.001.08, schema status
Failed, with both parser findings located at line 23,
column 38: the value is "not facet-valid with respect to
enumeration '[FRST, RCUR, FNAL, OOFF, RPRE]'", and consequently the
value of element SeqTp "is not valid".
Open the XSD report.
Line and column come from the XML parser itself, which is why this report points at a position in the document rather than a row in a spreadsheet. External XML validation is a Pro feature; the free Community Edition, an open-source credit transfer generator, does not include it. Neither report modifies the file it examined.
A clean report means the data passed the checks described above. It does not mean your bank will accept the file: bank rules, channel requirements and account configuration are outside what any local tool can inspect.
The report identifies issues and suggests corrections. It never rewrites your data, never silently repairs XML and offers no one-step fix. You change the source and run the workflow again.
Whether a collection is due, a mandate still valid or an amount correct are questions about your records, not about file structure. The duplicate warning is the closest the tool gets, and it only asks the question.
Both reports on this page were written by the desktop application on an ordinary computer. Parsing, validation and report generation run locally; no XML file, spreadsheet or payment detail is uploaded to Niryosys, and there is no bank connection and no transmission of payment files at any point.
The report is a single HTML file with inline styles, no scripts and no external requests, so you can archive it or attach it to a ticket like any other document. See the privacy note for what the application does use the network for.
The only value fixed by hand in these examples is the "Generated on" timestamp, supplied through the same parameter the application fills with the current time, so that regenerating the artifacts produces byte-identical files. Every finding, count, message and style is exactly what the application wrote.
All four are examples containing fictional data only. Read them; do not submit them to a bank.
These are example documents, not software downloads. Installers live on the Community download page and the Pro download page.
Detailed validation reports, external XML validation and Direct Debit generation are SEPA Generator Pro capabilities. Pro is €119/year at the founding price, an annual subscription with 3 activations, and every charge is covered by a 14-day money-back guarantee. Checkout and invoicing are handled by Lemon Squeezy as our Merchant of Record.
Pro launches soon
Questions about licensing or billing? Pro support · Terms, licensing & refunds
It is a local HTML document produced by SEPA Generator Pro. For imported data it lists every error and warning found before generation, with the row, field, message and suggested correction. For an existing XML file it reports the result of official XSD schema validation, with the line and column of each finding.
No. Every company, mandate reference and end-to-end reference on this page is invented, and the account numbers are published sample IBANs — one of them deliberately corrupted so its checksum fails. Nothing comes from a real mandate or a real account, and these files must not be submitted to a bank.
Input data and generated files for pain.001.001.02, pain.001.001.09 and pain.008.001.08. External XML validation checks existing files in those same versions against the official schemas bundled with Pro. Legacy pain.001.001.03 and pain.008.001.02 files are handled by the separate migration workflow.
No. It means the file matches the official schema and passes the checks the application can perform. Acceptance can still depend on your bank, upload channel, account configuration, the message version required and bank-specific rules, so test your first production file through your own banking channel.
No. It reports findings with suggested corrections and leaves your data exactly as it is. You correct the source rows, or the system that produced the XML, and run the workflow again. There is no automatic repair and no silent rewriting.
No. Parsing, validation and report writing all happen in the desktop application on your own computer. No payment file is sent to Niryosys, and the report itself is a self-contained HTML file with no scripts and no external requests, so opening it makes no network connection either.
