The SEPA character set: which characters are safe in a payment

ARLing s. r. o. · 6 September 2026

This matters most in the fields a person actually typed: the name on the account, the free-text payment reference, and any address written into the file. IBANs, BICs and amounts are not affected, because they are already restricted to letters, digits and a decimal point by their own field rules.

Why a text-based format has a character problem at all

pain.001, the ISO 20022 message used for a SEPA batch payment, is an XML file, and XML text is Unicode: technically, nothing stops a field from holding any script in the world. The restriction is not in the XML schema itself. It sits one level down, in what individual banks and national banking associations agree to accept, and it traces back to older interbank messaging conventions built around a small Latin character set.

We can document this from two unrelated countries, enough to call it a pattern rather than a local quirk, though we have not checked every bank in every SEPA country and do not claim the list below is enforced identically everywhere. In Slovakia, ČSOB's own SEPA documentation states plainly that a SEPA XML file with diacritics cannot be imported into its BusinessBanking Lite portal at all, and gives the exact allowed set. In Germany, the interbank data exchange agreement of the national banking associations (the DFÜ-Abkommen, Anlage 3) defines the same set of letters, digits and punctuation marks, and states that a bank may replace an out-of-set character with a space or a similar-looking one, or reject the file outright.

The safe list

a-z   A-Z   0-9   (space)
/   -   ?   :   (   )   .   ,   '   +

That is 62 letters and digits, one space, and ten punctuation marks: 73 characters in total. Both sources above give this same list, character for character.

What falls outside it, and it is a longer list than people expect

• Every accented Latin letter. á, à, â, ã, å, ä, é, è, ê, ë, í, ì, î, ï, ó, ò, ô, õ, ö, ø, ú, ù, û, ü, ñ, ç, ý, ß, ł, and their uppercase forms.
• Any non-Latin script, Cyrillic and Greek included.
• Ordinary punctuation many people assume is fine. The semicolon, ampersand, quotation marks (straight or curly), the asterisk, hash, at sign, percent sign, square and curly brackets, the backslash, and the equals sign are all outside the list above.
• The en dash and em dash. Only the plain hyphen-minus, the third character on the list, is safe. A dash pasted in from a word processor is often the wrong one and looks identical on screen.

What a bank actually does with a character outside the list

We can only report what we have found documented, and it is not the same answer everywhere. ČSOB's documentation is explicit that its BusinessBanking Lite portal will not import a file with diacritics at all: the whole batch is rejected, not just the one payment with the accented name. The German DFÜ-Abkommen, by contrast, authorizes the receiving bank to replace an out-of-set character with a space or a similar-looking one instead of rejecting the file, while leaving it free to reject anyway. For any bank not named here, we have not verified which of the two it does, and we are not going to guess: treat outright rejection as the safe assumption until you have tested your own bank's import.

Silent replacement is its own quiet problem: a name reduced to a space or an approximate letter still imports without an error, and the mismatch only surfaces later, when a bank statement no longer matches the invoice.

The practical fix: transliterate before you export

Replacing each accented letter with its closest plain-ASCII equivalent before the file is generated produces text that is, by construction, inside the safe list above. It passes at a bank that rejects the whole file, and it passes at a bank that would otherwise replace the character with something else, because there is nothing left for either bank to react to. This is worth doing to the creditor and debtor name fields and to the free-text payment reference in particular, since those are the fields a person is most likely to have typed with an accent in them.

There is no single official conversion table that every bank applies the same way. The European Payments Council has published a best-practice document for the opposite direction, extending what a system accepts rather than reducing what you send it (reference EPC217-08, below); we could not confirm its mappings directly, so we do not repeat them here. The table below is the substitution logic used in ARLing's own SEPA tools, for applying by hand if your software does not do this for you.

A transliteration table

Dropping the accent and keeping the base letter, the convention used throughout the table above, is the one we could confirm in our own tools' source code, and it is also the approach most accounting and payment software applies. A German name loses its umlaut this way rather than having it spelled out: "Müller" becomes "Muller", not "Mueller". Some German systems instead expand ä, ö and ü to ae, oe and ue, keeping a name closer to how it would be typed on a keyboard without umlauts; neither of our two banking sources documents which of the two a receiving bank expects, so if your own software already expands umlauts that way, there is no reason to change it. The double-s for ß is the standard plain-ASCII substitute for that letter regardless of which convention you use for the umlauts. Either approach for ä/ö/ü lands inside the safe list; which one you pick mostly affects how easily a human reader recognizes the name afterward.

A short checklist before you export

• Check name fields first: accented personal and company names are where this breaks most often, not amounts or account numbers.
• Check the payment reference text, especially if typed or pasted by hand rather than pulled from a fixed template.
• Watch for a long dash or curly quotation marks pasted from a word processor: they look ordinary but sit outside the safe list.
• If your accounting software already transliterates on export, there is likely nothing to do; if not, ask the vendor whether it is planned.

ARLing is not a bank, and nothing here is legal or accounting advice. A file built only from the safe characters above is not a guarantee that a bank will accept the payment for other reasons, and banks can change what they accept at any time. If you want to check whether a pain.001 file you already built contains characters outside this set, our free SEPA pain.001 Doctor flags every field with an out-of-set character, runs entirely in your browser, and does not upload the file anywhere.