Your bank rejected your SEPA XML.Find out exactly why.
Paste the pain.001 file from your accounting software, pick your bank, and you immediately know which line is wrong and what belongs there instead. Not “import error”, but the exact element, its value and the fix.
- ISO 20022 schema and EPC rules, any bank
- 160+ automated tests
- 0 € for the check, no account
- 29 € for the auto-corrected file
Paste the XML, pick your bank. You get the exact errors.
The file is read directly in your browser and never sent anywhere. Within a second you see which element is wrong, what value it has and what belongs there instead.
The settings (bank, expected number of transactions) are stored in the page URL after a check. The XML itself is not, so the result cannot be shared through the URL. To share a result, use the “copy report” button.
Would you rather not deal with this yourself?
Also covers errors the automatic fix cannot repair, for example a wrong bank BIC.
Send us the file and within 24 hours you get a written report on what needs fixing in it, addresses included, and the corrected file. 149 € once, no subscription, no further fees.
The check is done and invoiced by ARLing s. r. o., Company ID 56583486, Bratislava. You pay nothing upfront: we issue the 149 € invoice only after the corrected file and the report are delivered, and you pay it by bank transfer, not through Stripe. The tool's code is public at github.com/AndryRoby.
Nothing you paste is sent anywhere. The check runs in your browser, against the banks’ own published rules.
The rules come from the technical documentation of Tatra banka, VÚB and ČSOB, from public statements by SLSP and from the ISO 20022 standard. If the tool misses a case, report it as an issue on GitHub.
This tool is not a bank and is not affiliated with Tatra banka, Slovenská sporiteľna, VÚB or ČSOB. A clean result does not guarantee that the bank will accept the payment.
The address in a SEPA payment: the EPC postponed the date, the direction stays.
The 2025 SEPA scheme rulebooks were to end the fully unstructured address, meaning one or more lines of free text in <AdrLine>, from 15 November 2026. The European Payments Council postponed that end on 9 September 2026 and will set a new date in October 2026. Until then the free-text address remains supported. The direction does not change: the EPC recommends moving straight to a fully structured address, and your bank may apply its own rules earlier.
If the address is structured or hybrid, the minimum is two fields: the town in <TwnNm> and the two-letter country code in <Ctry>. A hybrid address may carry at most two lines of free text alongside these two fields.
This applies to SEPA credit transfers, instant transfers and direct debits, so also to the pain.001 files exported by your accounting software. The address stays optional: a file with no addresses is not affected.
The old address, which the EPC wants to end:
<PstlAdr>
<AdrLine>Ivanská cesta 32E</AdrLine>
<AdrLine>821 04 Bratislava</AdrLine>
</PstlAdr>A structured address, recommended:
<PstlAdr>
<StrtNm>Ivanská cesta</StrtNm>
<BldgNb>32E</BldgNb>
<PstCd>82104</PstCd>
<TwnNm>Bratislava</TwnNm>
<Ctry>SK</Ctry>
</PstlAdr>You will come across both 22 and 15 November 2026. Neither applies today. Version 1.0 of the 2025 SEPA Credit Transfer rulebook said 22 November, version 1.1 corrected it to 15 November 2026, and on 9 September 2026 the EPC postponed the end of the free-text address. It will announce the new date in October 2026.
Sources: European Payments Council, postponement of the end of unstructured addresses, 10 Sep 2026 (verified on 24 September 2026); verified on 6 September 2026: European Payments Council, 2025 SEPA Credit Transfer rulebook, version 1.1 (this version moved the date from 22 to 15 Nov 2026, later postponed; the rulebook applies from 5 Oct 2025), ECB and the Payments Market Practice Group (template letter to corporate clients, 22 Oct 2025), Komerční banka (announces that the upcoming MultiCash 5.0 will be compatible with pain.001.001.09; this page does not name an end date for version .03). If any source has changed its wording since, write to us and we will correct the rule.
The check is free.
It grew out of our own need: to verify SEPA XML before uploading it to online banking. The check needs no account and has no limit. When the tool can fix the errors it found, you can download the corrected file for 29 €; only if you want it.
If it saves you an afternoon, tell us what the tool missed. Open an issue on GitHub.
Tell me when a new tool is out. New tools only. No newsletter, no sharing. Unsubscribe by replying to the email.
Thank you. We will only write when there is something new.
Could not save. Write to support@arling.sk.
Just one file? That is the 149 € check with the result within 24 hours.
Need this check for a company? Bulk checking of hundreds of files, automatic fixes and a link into your accounting system. Tell us what you need and we will answer within 24 hours.
Tell us what I needThe questions people actually search for.
Direct answers about the SEPA pain.001 problems this tool diagnoses.
Why did Tatra banka reject my pain.001 file?
On import, Tatra banka checks more than whether the XML is valid pain.001. It checks the exact namespace pain.001.001.03, PmtMtd=TRF, SvcLvl/Cd=SEPA, ChrgBr=SLEV, the debtor BIC being exactly TATRSKBX, the date ReqdExctnDt (not in the past, and not more than 31 days ahead), a maximum of 500 transactions in the whole file (all PmtInf blocks together), length limits on names and remittance text, and for Slovak creditor IBANs also the modulo-11 check. Breaking a single rule is enough for the import to fail.
How do I write the variable symbol into SEPA XML?
pain.001.001.03 has no separate fields for the Slovak payment symbols VS, ŠS and KS. By the NBS convention they go into PmtId/EndToEndId in the order /VS.../SS.../KS..., for example /VS123/SS456/KS0308. VS and ŠS take at most 10 digits, KS at most 4. The wrong order does not stop the transfer, but the other side cannot match the payment to an invoice.
Which characters are allowed in a SEPA payment (accents)?
ČSOB lists the exact set in its documentation: letters a-z, A-Z, digits 0-9, space and the characters / - ? : ( ) . , ' +. ČSOB does not import diacritics (č, š, ž, ä, ô, ľ) into BusinessBanking Lite at all. At other banks diacritics may not block the file straight away, but exporting without them is safer every time.
What does an NbOfTxs or CtrlSum error mean?
GrpHdr/NbOfTxs must match exactly the number of CdtTrfTxInf transactions in the file. GrpHdr/CtrlSum must be the exact sum of the InstdAmt amounts to 2 decimal places. A mismatch, typically after editing the file by hand without recalculating the totals, is one of the most common and least understandable reasons for a batch to be rejected.
Is the creditor BIC required in pain.001?
It depends on the bank. VÚB marks CdtrAgt/BIC as mandatory in its own specification. Tatra banka can derive it from a correct SEPA IBAN and tolerates a missing one. ČSOB made it optional on 1 February 2016. If you generate one file for several banks, always include the BIC.
Is my data sent anywhere?
No. The whole check runs in your browser. The XML, IBANs, amounts and names are not sent anywhere; the tool has no backend. The only network activity is loading the page’s static files and an anonymous usage counter (Umami), which records only the outcome (pass, warn, fail), never the contents of the file.