ISO 20022 w praktyce: jakie terminy naprawdę obowiązują i co dalej z MT940

Trzy scenariusze na najbliższe miesiące

Nie robimy nic. Płatności działają do pierwszego odrzucenia, wyciągi przychodzą w MT940 tak długo, jak bank je udostępnia. Ryzyko nie jest zerojedynkowe, tylko narasta: pojedyncze zwroty, rosnąca liczba pozycji do ręcznego wyjaśnienia, coraz większa różnica między tym, co bank wie o transakcji, a tym, co widzi Twój system.

Obejście ręczne. Przelewy wprowadzane bezpośrednio w bankowości elektronicznej, wyciągi księgowane z palca. Działa przy kilkudziesięciu operacjach miesięcznie. Przy kilkuset to kilka dni pracy w każdym cyklu, do tego ryzyko pomyłki w kwocie lub numerze rachunku, czyli dokładnie ten rodzaj błędu, który potem długo się wyjaśnia.

Wdrożenie. Generator pain.001 i parser camt.053 w systemie, walidacja przed zapisaniem pliku, automatyczne dopasowanie na wyciągu. Projekt planowany, z testami z bankiem i szkoleniem, a nie gaszenie pożaru w tygodniu, w którym coś przestało działać.

Ile trwa przejście i co decyduje o terminie

Dla standardowej instalacji Dynamics AX 2012 lub Dynamics 365 realizacja zajmuje około 60 dni od zamówienia. Na tę liczbę składa się analiza obecnych formatów, mapowanie danych z systemu na znaczniki XML, implementacja, testy i szkolenie użytkowników.

Wąskim gardłem zwykle nie jest kod, tylko bank. Pliki testowe weryfikuje bank, w swojej kolejce, a jego specyfikacja decyduje o szczegółach parsera, bo choć standard jest jeden, wersje komunikatów i sposób wypełniania pól potrafią się różnić. Dlatego harmonogram planuje się od terminu banku wstecz, a nie od dnia, w którym zwolnią się zasoby po stronie IT.

Drugi czynnik to stan Waszego systemu. Instalacja AX 2012 po latach modyfikacji rzadko jest standardowa. To zwykle analiza, a nie samo wdrożenie, decyduje o tym, czy projekt zamknie się w zakładanym czasie.

Po stronie INLOGICA wdrożenie prowadzi jeden programista wiodący, który jest kontaktem w sprawie wdrożenia, testów i wsparcia po uruchomieniu. Samo wdrożenie wymaga stosunkowo niewielkiego zaangażowania Waszego zespołu.

Jeśli chcesz zobaczyć, jak taki zakres wygląda w praktyce (scenariusze płatności, moduły opcjonalne i podział prac między nas, Wasz zespół i bank), opisaliśmy to na stronie wdrożenia ISO 20022 w Microsoft Dynamics AX.

Podsumowanie

• Termin listopadowy przesunięto, kierunek został. Swift i EPC odłożyły wymóg strukturalnego adresu w komunikatach płatniczych, a nowa data ma zostać ogłoszona. Adres rozbity na pola, z miastem i kodem kraju, i tak stanie się obowiązkowy.
• Od 1 stycznia 2027 przelew za fakturę z KSeF ma zawierać numer KSeF albo identyfikator zbiorczy. Ten termin wynika z ustawy o VAT i nie został przesunięty.
• ELIXIR przechodzi na ISO 20022 w pierwszej połowie 2027 roku według harmonogramu KIR.
• MT940 nie ma ogłoszonej daty wycofania, ale nie jest rozwijany, więc wyciąg w starym formacie będzie coraz uboższy od camt.053.
• W Dynamics AX zmienia się format, nie kanał. AX generuje plik pain.001 i wczytuje camt.053, a wymiana plików z bankiem odbywa się jak dziś, ręcznie w bankowości elektronicznej.
• Najwięcej pracy jest w danych, nie w kodzie. Uporządkowane adresy i NIP-y w kartotekach decydują o tym, czy przelewy przejdą bez odrzuceń, a wyciągi dopasują się same.

Przesunięcie terminu nie zdejmuje tematu z listy, tylko daje czas, żeby przejść go w spokojnym tempie: od przeglądu kartotek, przez testy plików z bankiem, po uruchomienie.

Najczęściej zadawane pytania o ISO 20022 i MT940

Czy MT940 przestanie działać w listopadzie 2026?

Nie. Listopad 2026 dotyczył komunikatów płatniczych z niestrukturyzowanym adresem, a nie formatu wyciągów, a i ten termin Swift oraz EPC przesunęły. Większość polskich banków nie ogłosiła daty wycofania MT940 dla klientów firmowych, udostępnia camt.053 równolegle i zachęca do migracji. Konkretny termin warto potwierdzić w swoim banku, bo polityki się różnią.

Czym camt.053 różni się od MT940 w praktyce?

MT940 podaje dane transakcji jako ciąg znaków, z którego nadawcę i tytuł trzeba wyłuskać regułami tekstowymi. camt.053 to XML, w którym każda informacja ma własne pole, łącznie z referencją nadaną przy zleceniu przelewu. Dlatego dopasowanie płatności do dokumentu może działać automatycznie, zamiast opierać się na wyszukiwaniu fraz w opisie.

Czy musimy wdrażać oba moduły naraz?

Nie. Można zacząć od strony płatności albo od wyciągów, zależnie od tego, co bardziej boli. Pełna korzyść pojawia się jednak wtedy, gdy działają razem: pain.001 nadaje referencję, a camt.053 ją odczytuje i zamyka uzgodnienie bez ręcznej pracy.

Czy zmieni się codzienna praca księgowości?

Sposób pracy w systemie zostaje ten sam: ten sam arkusz płatności, ta sama ścieżka zatwierdzania. Zmienia się plik na wyjściu i moment, w którym wychodzą błędy. Walidacja dzieje się w systemie, zanim plik trafi do bankowości elektronicznej.

Czy rozwiązanie łączy się z bankiem przez API?

Nie. Dziś kanałem jest plik i ręczna obsługa w bankowości elektronicznej: wgranie przelewów i pobranie wyciągu. Rozwiązanie zaprojektowano jednak tak, że format komunikatu jest oddzielony od kanału przesyłu. XML w standardzie ISO 20022, który AX generuje i odczytuje, jest tym samym językiem, którym posługują się bankowe API i kanały host-to-host. Połączenie przez API byłoby więc dodatkową warstwą transportu na gotowym fundamencie, a nie budową od nowa.

INLOGICA planuje rozwój produktu w tym kierunku (docelowo wysyłka płatności z AX, statusy przelewów i automatyczny odbiór wyciągów), ale to plan na przyszłość, a nie obecny zakres. Dziś priorytetem jest to, żeby firmy na Dynamics AX miały na czas poprawne pliki w nowym formacie.

Jakie rodzaje przelewów obsługuje eksport pain.001?

W standardzie: przelewy krajowe w złotych, przelewy SEPA w euro, płatności zagraniczne SWIFT w walutach obcych oraz przelewy w mechanizmie podzielonej płatności (split payment). Składki ZUS idą jako zwykły przelew krajowy. Różnice między tymi rodzajami sprowadzają się do scenariuszy i danych wymaganych przez bank odbiorcy, a nie do osobnych narzędzi.

Poza zakresem bazowym są przelewy podatkowe do urzędu skarbowego, bo mają osobną strukturę komunikatu. Można je dodać niewielkim nakładem pracy. Import wyciągów camt.053 obsługuje natomiast wszystkie operacje na rachunku, łącznie z przelewami podatkowymi.

Czy split payment zadziała z modułem MPP od innego dostawcy?

Jeśli funkcjonalność podzielonej płatności w Waszym AX pochodzi od INLOGICA, integracja jest automatyczna. Jeśli dostarczył ją inny partner, rozwiązanie udostępnia punkt wpięcia, a podłączenie może wymagać dodatkowej pracy. Jej zakres zależy głównie od dokumentacji technicznej: gdy jest dostępna, nakład jest znikomy.

Czy adres odbiorcy można poprawić ręcznie przy konkretnym przelewie?

W standardzie nie i jest to świadoma decyzja. Adres i dane bankowe beneficjenta trafiają do pliku zawsze z kartoteki dostawcy w AX, a nie z roboczej kopii. Błąd poprawia się więc raz, w kartotece, i poprawka działa dla wszystkich kolejnych przelewów.

Rolę „tabeli pośredniej” pełni arkusz płatności. Przed wygenerowaniem pliku użytkownik widzi na nim i może edytować identyfikator płatności (EndToEndId), tytuł przelewu, kwotę, datę realizacji, metodę płatności oraz pola split payment (kwota VAT, NIP, numer faktury). W parametrach firmy można włączyć lub wyłączyć przekazywanie ulicy, numeru budynku, lokalu i kodu pocztowego; miasto i kraj są przekazywane zawsze, bo wymaga ich bank. Adres zleceniodawcy edytuje się ręcznie w parametrach.

Jeśli dane adresowe są w złym stanie, najpierw warto je wspólnie przejrzeć i poprawić w kartotekach; do tego można przygotować dedykowane narzędzia analityczne i naprawcze. Gdy porządkowanie danych z wyprzedzeniem nie wchodzi w grę, możliwa jest osobna tabela pośrednia z adresem, powiązana z arkuszem płatności i edytowalna przez użytkownika. To już jednak dostosowanie na życzenie, a nie standard.

Czy rozwiązanie obsłuży numer KSeF w przelewach?

Tak. Od 1 stycznia 2027 roku przelew za fakturę wystawioną w KSeF, gdy obie strony są czynnymi podatnikami VAT, ma zawierać numer KSeF faktury, a przy zapłacie kilku faktur jednym przelewem identyfikator zbiorczy. Obecna wersja rozwiązania odpowiada stanowi prawnemu i technicznemu na dziś, a obsługa numeru KSeF i identyfikatora zbiorczego wejdzie w kolejnej aktualizacji produktu. Jeśli korzystacie z KSeF od INLOGICA, dodatkowe prace przy tej aktualizacji nie powinny być duże.

Czy rozwiązanie obsługuje grupy VAT?

Rozszerzenia dla grup VAT (wybór NIP do weryfikacji na białej liście, aliasy NIP przy imporcie wyciągów, przelew podatkowy VAT grupy, oznaczanie płatności wewnątrzgrupowych kodem INTC) są przewidziane w architekturze jako punkty wpięcia i wdrażane jako kolejny etap, wyceniany indywidualnie. Zakres zależy od roli firmy: czy jest członkiem grupy VAT, jej przedstawicielem, czy tylko płaci dostawcom, którzy do grup VAT należą.

Mamy Dynamics AX 2012, nie Dynamics 365. Czy to działa?

Tak. Funkcjonalność powstała dla Dynamics AX 2012 i działa również w Dynamics 365. Warunkiem jest wschodnioeuropejska warstwa GLS z włączonymi polskimi funkcjonalnościami i praca na standardowych polach systemu; instalacje mocno modyfikowane wymagają osobnej analizy.

Źródła

• mBank, ISO 20022: wyciągi i raporty (dostępność camt.053, brak ogłoszonego terminu wycofania MT940)
• Bank Handlowy w Warszawie, migracja do standardu ISO 20022
• PKO Bank Polski, ISO 20022
• ERP-view, Płatności elektroniczne 2026–2027: kalendarz zmian (harmonogram ELIXIR wg KIR)
• Swift, przesunięcie migracji do strukturalnego adresu w komunikatach płatniczych (27 sierpnia 2026)
• European Payments Council, przesunięcie terminu dla adresów w schematach SEPA (10 września 2026)

Stan na 28 września 2026. Terminy podane przez banki i infrastruktury płatnicze bywają aktualizowane. Przed decyzją warto potwierdzić je u swojego dostawcy usług bankowych.