15 typowych błędów XML SEPA i jak je naprawić
Kompleksowy przewodnik po najczęstszych błędach walidacji SEPA pain.001 i pain.008, z praktycznymi rozwiązaniami dla każdego z nich.
Dlaczego pliki XML SEPA są odrzucane
Pliki XML SEPA (pain.001 dla poleceń przelewu i pain.008 dla poleceń zapłaty) przestrzegają rygorystycznych schematów ISO 20022 zdefiniowanych przez European Payments Council (EPC). Nawet drobne odstępstwa od oczekiwanej struktury powodują, że banki odrzucają całe partie płatności. Zrozumienie typowych błędów oszczędza czas i zapobiega kosztownym opóźnieniom w płatnościach.
Ten przewodnik obejmuje 15 najczęstszych błędów XML SEPA, z jakimi borykają się zespoły skarbowe, księgowi i programiści w całej Europie. Każdy błąd zawiera przyczynę główną, zaangażowany element XML i sprawdzone rozwiązanie.
Niezależnie od tego, czy używasz SAP, Oracle czy niestandardowego ERP, te wzorce mają zastosowanie powszechnie do wszystkich plików płatności zgodnych z SEPA.
Błędy schematu i struktury
Te błędy występują, gdy struktura XML nie odpowiada schematowi XSD EPC.
1. Nieprawidłowa przestrzeń nazw lub wersja schematu
Element główny <Document> musi deklarować właściwą przestrzeń nazw dla wersji pain.001 (np. urn:iso:std:iso:20022:tech:xsd:pain.001.001.09). Mieszanie przestrzeni nazw z różnych wersji powoduje natychmiastowy błąd walidacji XSD.
2. Brakujące obowiązkowe pola GrpHdr
Blok GroupHeader (GrpHdr) wymaga MsgId, CreDtTm, NbOfTxs, CtrlSum i InitgPty. Pominięcie któregokolwiek z tych pól — szczególnie CtrlSum — powoduje, że plik nie przechodzi walidacji schematu, zanim bank przetworzy instrukcje płatności.
3. Nieprawidłowe kodowanie XML lub BOM
Plik XML SEPA musi używać kodowania UTF-8. Pliki z BOM (Byte Order Mark), UTF-16 lub kodowaniem Windows-1252 są odrzucane. Upewnij się, że narzędzie eksportu zapisuje czysty UTF-8 bez BOM.
4. Elementy w nieprawidłowej kolejności
Schematy ISO 20022 wymuszają ścisłą kolejność elementów. Na przykład w PmtInf, PmtMtd musi pojawić się przed ReqdExctnDt. Zamiana pozycji elementów — nawet jeśli wszystkie dane są obecne — powoduje błąd walidacji schematu.
5. Zduplikowane MsgId w plikach
Każdy plik SEPA musi mieć unikalny MsgId. Jeśli system ponownie używa tego samego MsgId dla różnych partii płatności, banki odrzucą duplikat jako potencjalny atak powtórzeniowy. Użyj znaczników czasu lub UUID, aby zapewnić unikalność.
Błędy IBAN i BIC
Błędy w identyfikatorach kont są najczęstszą przyczyną odrzuceń SEPA.
6. Nieprawidłowa suma kontrolna IBAN (mod-97)
Numery IBAN używają algorytmu mod-97 dla cyfr kontrolnych (pozycje 3-4). Pojedynczy błąd cyfry powoduje niepowodzenie sumy kontrolnej. Zawsze waliduj numery IBAN programowo przed umieszczeniem ich w pliku SEPA. ValidateFin automatycznie sprawdza każdy IBAN w pliku.
7. Niezgodna długość IBAN dla kraju
Każdy kraj ma stałą długość IBAN (np. DE=22, FR=27, BE=16, NL=18). IBAN z nieprawidłową liczbą znaków dla prefiksu kraju jest natychmiast nieważny.
8. Przestarzały lub nieprawidłowy BIC
Kody BIC/SWIFT mogą stać się przestarzałe po fuzjach bankowych. Używanie przestarzałego BIC powoduje błędy routingu. Dla płatności SEPA w EOG BIC jest opcjonalny od 2016 roku — rozważ jego pominięcie i pozwól bankowi na jego wyprowadzenie z IBAN.
Błędy kwoty i waluty
Błędy walidacji finansowej powodujące odrzucenie całej partii.
9. CtrlSum nie odpowiada sumie transakcji
CtrlSum w GrpHdr musi być dokładnie równy sumie wszystkich wartości InstdAmt w pliku. Nawet różnica zaokrąglenia 0,01€ powoduje odrzucenie całego pliku. Używaj arytmetyki dziesiętnej, nie zmiennoprzecinkowej.
10. Waluta inna niż EUR w pliku SEPA
Polecenia przelewu SEPA obsługują tylko EUR. Jeśli plik zawiera kwoty w GBP, CHF lub innych walutach, bank go odrzuci. Użyj osobnego międzynarodowego kanału płatności dla przelewów w walutach innych niż EUR.
11. Format kwoty z nieprawidłowym separatorem dziesiętnym
XML SEPA używa kropki (.) jako separatora dziesiętnego, nie przecinka. Wartość musi mieć dokładnie 2 miejsca po przecinku: <InstdAmt Ccy="EUR">1500.00</InstdAmt>. Wartości takie jak "1500" lub "1.500,00" są nieprawidłowe.
Błędy daty i identyfikatora
Typowe błędy w polach daty i referencji.
12. Miniona lub nieprawidłowa data wykonania
ReqdExctnDt musi być bieżącym lub przyszłym dniem roboczym. Większość banków odrzuca daty z przeszłości i daty powyżej 30 dni do przodu. Daty weekendowe są przesuwane na poniedziałek, ale niektóre banki je odrzucają.
13. Nieprawidłowe znaki w EndToEndId
Pole EndToEndId (maks. 35 znaków) dopuszcza tylko ograniczony zestaw: a-z, A-Z, 0-9 i kilka znaków specjalnych (/, -, ?, :, (, ), ., +, spacja). Znaki takie jak #, @, é, ü są odrzucane.
14. Brakujący identyfikator wierzyciela dla SDD
SEPA Direct Debit (pain.008) wymaga ważnego Identyfikatora Wierzyciela (CI) w CdtrSchmeId. Jest to rejestracja specyficzna dla danego kraju (np. ICS we Francji, Gläubiger-ID w Niemczech). Bez niego cała partia SDD nie powiedzie się.
15. Niezgodna liczba NbOfTxs
Pole NbOfTxs w GrpHdr musi odpowiadać rzeczywistej liczbie elementów CdtTrfTxInf (lub DrctDbtTxInf) w pliku. Rozbieżność — często spowodowana częściowym generowaniem pliku — powoduje natychmiastowe odrzucenie.
Natychmiastowa walidacja plików SEPA
ValidateFin wykrywa wszystkie 15 wymienionych powyżej błędów — i więcej. Prześlij swój plik pain.001 lub pain.008 i otrzymaj natychmiastową informację zwrotną na temat zgodności ze schematem, walidacji IBAN, spójności kwot i kodowania znaków.
Otwórz walidator SEPACzęsto zadawane pytania
Jaki jest najczęstszy błąd XML SEPA?
Najczęstszym błędem jest nieprawidłowa suma kontrolna IBAN (niepowodzenie mod-97). Stanowi to około 30% wszystkich odrzuceń plików SEPA. Zawsze waliduj numery IBAN przed wygenerowaniem pliku płatności.
Czy mogę naprawić błędy SEPA bez ponownego generowania całego pliku?
Zależy to od błędu. Proste poprawki, takie jak korekta numeru IBAN lub dostosowanie CtrlSum, można wykonać bezpośrednio edytując XML. Jednak błędy strukturalne (nieprawidłowa kolejność elementów, brakująca przestrzeń nazw) zazwyczaj wymagają ponownego wygenerowania z systemu źródłowego.
Czy ValidateFin sprawdza wszystkie 15 błędów?
Tak. ValidateFin waliduje plik SEPA względem schematów XSD EPC, sprawdza każdy IBAN metodą mod-97, weryfikuje spójność CtrlSum, waliduje kodowanie znaków i oznacza wszystkie problemy strukturalne. Walidacja działa całkowicie w przeglądarce — żaden plik nie jest przesyłany.
Dlaczego mój bank odrzuca plik, który przeszedł walidację XSD?
Walidacja XSD sprawdza tylko strukturę XML. Banki stosują również reguły biznesowe: prawidłowe daty wykonania, poprawne CtrlSum, unikalne MsgId oraz prawidłowe IBAN/BIC. ValidateFin sprawdza zarówno schemat, jak i reguły biznesowe.
Czy kody błędów SEPA są standaryzowane?
Tak. Banki używają kodów przyczyn ISO 20022 (np. AC01 dla nieprawidłowego IBAN, AM05 dla duplikatu, AG01 dla zabronionego typu transakcji). EPC prowadzi pełną listę w dokumencie SEPA Reason Codes.
Jak zapobiegać błędom SEPA w moim ERP?
Wdróż walidację IBAN przy wprowadzaniu danych, używaj biblioteki XML SEPA (nie konkatenacji ciągów) do generowania plików, waliduj plik wyjściowy przed wysłaniem i zawsze najpierw testuj za pomocą narzędzia walidacyjnego swojego banku.
Co się dzieje, gdy plik SEPA zostaje odrzucony?
Bank zwraca raport statusu pain.002 z kodami przyczyn odrzucenia dla każdej nieudanej transakcji. Musisz naprawić błędy i ponownie przesłać cały plik lub blok płatności.
Czy problemy z kodowaniem znaków mogą być niewidoczne?
Tak. Niektóre znaki (jak typograficzne cudzysłowy " " lub myślniki —) wyglądają poprawnie na ekranie, ale są poza zestawem znaków SEPA. Powodują odrzucenia bez oczywistego sygnału wizualnego. ValidateFin oznacza te niewidoczne problemy z kodowaniem.
Czy jest różnica w obsłudze błędów między pain.001.001.03 a .09?
Nowsze wersje (09, 11) mają bardziej rygorystyczną walidację. Niektóre pola, które były opcjonalne w wersji 03, są teraz obowiązkowe. Ograniczenia zestawu znaków są takie same. ValidateFin waliduje względem konkretnej wersji zadeklarowanej w pliku.
Ile czasu mam na naprawienie odrzuconego pliku SEPA?
Nie ma standardowego terminu, ale opóźnienia w płatnościach narastają. Większość zespołów skarbowych dąży do poprawy i ponownego przesłania w ciągu 4 godzin roboczych. Wstępna walidacja z ValidateFin eliminuje większość scenariuszy odrzucenia.