Migracja SAP S/4HANA w trakcie roku a JPK CIT. Jak prawidłowo raportować JPK_KR_PD?

Migracja do SAP S/4HANA w trakcie roku podatkowego to jedno z najbardziej wymagających przedsięwzięć dla działów finansowo‑księgowych. JPK_KR_PD to struktura raportowa obejmująca księgi rachunkowe oraz dane potrzebne do rozliczenia podatku CIT, której termin do złożenia po raz pierwszy dla większości podatników upływa 31.07.2027 r.

W dobie nowych obowiązków raportowych JPK_KR_PD zmiana systemu nie jest wyłącznie projektem IT – wpływa bezpośrednio na ciągłość ksiąg, spójność danych i możliwość wygenerowania poprawnego pliku JPK.

Najważniejsze wnioski:
– Migracja SAP w trakcie roku wpływa na raportowanie JPK CIT.
– Najbezpieczniejszy jest jeden kompletny plik JPK_KR_PD obejmujący zapisy z całego roku podatkowego.
– W praktyce często konieczne jest przygotowanie dwóch częściowych plików.
– Kluczowe znaczenie ma zachowanie ciągłości i spójności zapisów i planu kont.
– Problemy pojawiają się szczególnie przy migracji sald.
– Prawidłowe mapowanie planu kont ma kluczowe znaczenie dla poprawnego raportowania JPK_KR_PD.
– Warto odpowiednio wcześniej rozpocząć pracę nad wdrożeniem raportowania JPK_KR_PD, szczególnie jeśli planowana jest zmiana systemu finansowo-księgowego.

1. Wyzwanie dla organizacji

Ciągłe zmiany przepisów i skomplikowane obowiązki raportowe często zmuszają spółki do zmiany systemu finansowo-księgowego. Celem jest uzyskanie narzędzia umożliwiającego wypełnienie ustawowych obowiązków księgowych i podatkowych, a także pozwalającego na efektywne zarządzanie, kontrolowanie płynności, planowanie budżetów, klarowne raportowanie i powiązanie z procesami z innych obszarów. Zmiana systemu finansowo-księgowego stanowić może także wymóg koncernowy dopasowania się do oprogramowania i do raportowania grupy.

Największym wyzwaniem dla zmiany programu finansowo-księgowego w ciągu roku są: konieczność migracji danych oraz konfiguracja i parametryzacja nowego systemu. Sprawdzeniem poprawności przeprowadzonej migracji są testy procesów w nowym środowisku. 

Optymalnym rozwiązaniem jest zmiana oprogramowania na początku roku podatkowego i obrotowego. W praktyce często z różnych przyczyn zmiana ma miejsce w ciągu roku.

Checklista przed migracją SAP

✅ Zweryfikuj plan kont i strukturę ksiąg.

✅ Sprawdź możliwość odtworzenia historii zapisów księgowych.

✅ Zidentyfikuj sposób raportowania JPK_KR_PD w nowym systemie księgowym.

✅ Ustal, czy nowy program umożliwia wygenerowanie pliku JPK_KR_PD za cały rok podatkowy.

✅Wygeneruj testowe pliki JPK_KR_PD z poprzedniego i z obecnego systemu, czyli sprzed i po migracji.

✅ zweryfikuj kompletność, zgodność i spójność danych w plikach częściowych JPK_KR_PD.

✅ Zweryfikuj kompletność i spójność danych archiwalnych.

✅ Udokumentuj proces migracji.

2. Specyfika S/4

Przedmiotowa problematyka najbardziej dotyka użytkowników starszych wersji oprogramowania SAP. Ze względu na zakończenie wsparcia przez firmę SAP dla SAP ECC, który był głównym filarem pakietu ERP stoją oni bowiem przed koniecznością migracji do najnowszego wydania – S/4HANA. Brak migracji do nowego systemu przed 31.12.2027 r. będzie się wiązał dla użytkowników z brakiem jakichkolwiek aktualizacji czy poprawkami bezpieczeństwa oraz wyższymi kosztami utrzymania, a także brakiem dostępu do nowych funkcjonalności SAP.

SAP S/4 HANA to nowoczesne oprogramowanie ERP zaprojektowane w celu wspierania przedsiębiorstw w zarządzaniu procesami biznesowymi w kluczowych obszarach działalności, takich jak finanse, produkcja, łańcuch dostaw, sprzedaż i zakupy czy zarządzanie zasobami. W uproszczeniu wskazać można, że jest „następcą” technologicznym oprogramowania SAP R/3 i SAP ERP, które wykorzystując wbudowaną sztuczną inteligencję czy automatyzację procesów pozwala na zwiększenie efektywności operacyjnej.

Co to oznacza dla podatników CIT użytkujących oprogramowania dostarczane przez SAP? Konieczność generowania JPK_KR_PD w sytuacji zmiany oprogramowania przykładowo z R/3 na S/4HANA i migracji danych, często w trakcie roku podatkowego. W praktyce oznacza to nierzadko kumulację projektów wdrożeniowych w spółce i konieczność znacznego zaangażowania specjalistów IT i działów księgowo-podatkowych.

3. Istotne aspekty księgowe prawidłowej migracji danych

Zmieniając system w ciągu roku przede wszystkim nie można dopuścić do nieprawidłowości w księgach rachunkowych oraz w konstrukcji sprawozdania finansowego. O ile przed wejściem w życie raportowania JPK CIT istotny był tylko obraz finansowy spółki na dzień bilansowy, o tyle obecnie liczy się nie tylko koniec roku, ale każde jedno księgowanie. Stąd takie znaczenie ma prawidłowa migracja danych, a także szczegółowe zaplanowanie procesu oraz przeprowadzenie go w odpowiednich ramach czasowych. 

Wśród istotnych „księgowych” aspektów migracji należy wskazać:

1. Zapewnienie ciągłości ksiąg rachunkowych – nowy system może mieć inną logikę numeracji dokumentów i ewidencji (np. dzienników, zapisów, planu kont, numeracja kontrahentów) niż poprzednie systemy, stąd konieczne przeprowadzenie odpowiednich mapowań numeracji celem zachowania ciągłości danych.
2. Zapewnienie spójności danych w całym roku obrotowym – przeprowadzenie mapowania kont, aby zapewnić jednolitość ksiąg rachunkowych.
3. Zgodność sald, zapisów i historii dokumentów – dane z poprzedniego systemu muszą być kompletnie przeniesione, aby nie dopuścić do luki w danych, co dalej spowoduje niezgodności w rejestrach czy błędy także w rozliczeniach podatkowych (w tym: odtworzenie nierozliczonych pozycji na rozrachunkach, weryfikacja zgodności sald końcowych i początkowych.
4. Dostęp do danych archiwalnych – po zmianie systemu jednostka musi nadal posiadać pełny dostęp do danych historycznych dla celów kontroli, audytu i sprawozdawczości.
5. Udokumentowanie migracji – celem archiwizacji daty migracji, zakresu migrowanych danych, sposób kontynuacji numeracji i prowadzenia ewidencji, mapowania kont i kontrahentów, a także przeprowadzonych procedur kontrolnych.

4. JPK_KR_PD po zmianie systemu księgowego w trakcie roku podatkowego

Podatnik CIT ma w praktyce dwie możliwości: złożyć dwa odrębne pliki JPK_KR_PD, wygenerowane jeden z SAP R3, a drugi z SAP S/4HANA, albo złożyć jeden plik z nowego systemu, obejmujący całość księgowań.

Najbezpieczniejszym sposobem jest oczywiście złożenie jednego raportu. Byłoby to możliwe, gdyby nowy system mógł odtworzyć pełne księgi od pierwszego dnia roku podatkowego. A to z kolei będzie możliwe wyłącznie w sytuacji uprzedniego poprawnego i całościowego przeniesienia wszystkich danych (zapis po zapisie) z SAP r4 do SAP S4/HANA.      

W praktyce ze względu na objętość danych nie są one migrowane całościowo, lecz jedynie przenosi się jednym zapisem dotychczasowe obroty zarejestrowane na koncie księgowym SAP R3 na odpowiadające mu konto księgowe w SAP S/4HANA. 

W takiej sytuacji rozwiązaniem dla podatnika CIT jest wygenerowanie i złożenie dwóch JPK_KR_PD:

• Pierwszy za okres od początku roku podatkowego do dnia migracji (SAP R/3),
• Drugi za okres od dnia migracji do końca roku podatkowego (SAP S/4HANA).

Powyższą możliwość dopuszcza Minister Finansów, co wskazał w sekcji Q&A opublikowanej na stronie internetowej Ministerstwa (odpowiedź na pytanie nr 140). Zgodnie z tym, jeżeli podatnik posiada kilka systemów księgowych, to za raportowany okres zobowiązany jest połączyć dane w jeden kompletny plik JPK_KR_PD za cały rok podatkowy/obrotowy oraz zidentyfikować:

• wszystkie konta księgowe, na których w raportowanym okresie występują obroty i/lub salda,
• wszystkie konta syntetyczne, których konta analityczne zaprezentowały w raportowanym okresie obroty i/lub salda.

Jak wskazuje Minister, dla struktury logicznej JPK_KR_PD wdrożono funkcjonalność pozwalającą na podzielenie przez podatnika generowanego pliku JPK_KR_PD na dowolne okresy nie krótsze niż jeden dzień. Przy czym uwzględnić należy, że pliki JPK_KR_PD generowane za dowolne okresy muszą mieć zachowaną ciągłość zapisów tak, aby po scaleniu ich w jeden plik, w scalonym pliku odzwierciedlały w pełni księgi rachunkowe jednostki, bez żadnych luk i powtórzeń w każdym z węzłów.

5. Jak w praktyce wygenerować częściowe pliki JPK_KR_PD?

Jak wynika z instrukcji wskazanej przez Ministra Finansów w sekcji Q&A (przykładowo pytanie nr 150), „pliki częściowe JPK_KR_PD generowane za dowolne okresy muszą mieć zachowaną ciągłość zapisów tak, aby po scaleniu przekazanych danych odzwierciedlały w pełni księgi rachunkowe jednostki, bez żadnych luk i powtórzeń w każdym z węzłów”.

Nadto kolejno raportowane okresy cząstkowe powinny następować bezpośrednio po sobie i obejmować w sumie cały raportowany okres roku podatkowego (ewent. obrotowego), bez występowania przerw czy powtórzeń. Wtedy przesyłane pliki częściowe JPK_KR_PD zapewnią ciągłość raportowania.

Aby zachować spójność i ciągłość danych w pliku częściowym za dowolny okres w węźle „ZOiS” dla każdego konta należy wskazać wartości według poniższego schematu:

• w polu S_4 – bilansu otwarcia konta (Winien) na dzień rozpoczynający rok podatkowy/obrotowy,
• w polu S_5 – bilansu otwarcia konta (Ma) na dzień rozpoczynający rok podatkowy/obrotowy,
• w polu S_6 – obroty konta (Winien) za okres cząstkowy,
• w polu S_7 – obrotów konta (Ma) za okres cząstkowy,
• w polu S_8 – obrotów konta (Winien) za okres od dnia rozpoczynającego rok podatkowy/obrotowy do dnia końcowego okresu cząstkowego,
• w polu S_9 – obrotów konta po stronie (Ma) za okres od dnia rozpoczynającego rok podatkowy/obrotowy do dnia końcowego okresu cząstkowego,
• w polu S_10 – salda konta (Winien) na dzień końcowy okresu cząstkowego,
• w polu S_11 – salda konta (Ma) na dzień końcowy okresu cząstkowego.

Case study 1

Zmiana systemu finansowo-księgowego nastąpiła w spółce mającej rok kalendarzowy jako podatkowy począwszy od 01.10.2026 r. Mając powyższą instrukcję na uwadze w plikach częściowych należy wykazać salda i obroty według poniższego schematu:

Dla spełnienia powyższych wymogów istotne znaczenie ma również fakt, czy w związku ze zmianą systemu księgowego zmianie uległ także sam plan kont.

Case study 2

Spółka zmieniła system księgowy począwszy od 01.10.2026 r. W nowym systemie plan kont będzie taki sam jak w dotychczasowym, kontynuowana będzie także numeracja w ewidencjach. Spółka zamierza złożyć 2 pliki JPK_KR_PD: jeden za okres 01-09.2026 r. z SAP R/3, a drugi za okres 10-12.2026 r. z SAP S4/HANA. Spółka nie planuje przenieść pojedynczych zdarzeń gospodarczych i zapisów z SAP R/3do SAP S4/HANA. 

Spółka wprowadziła w SAP S4/HANA jako bilans otwarcia dla danego konta księgowego sumarycznie wartość bilansu otwarcia na początek roku obrotowego i dotychczasowych obrotów na nim (dane z SAP R/3), ujmując je pod datą ostatniego dnia miesiąca przed rozpoczęciem użytkowania SAP S4/HANA, czyli z datą 30.09.2026 r. Dla kont wynikowych przeniesione zostały w ten sposób tylko obroty z okresu styczeń-wrzesień.

Przy takim podejściu problematycznym będzie wygenerowanie pliku JPK_KR_PD z SAP S4/HANA, bowiem – jak wskazano w tabeli powyżej – w każdym pliku częściowym należy wykazać wartość bilansu otwarcia, a ta nie będzie możliwa do wygenerowania wprost z nowego systemu. Spółka nie będzie miała także możliwości wygenerowania prawidłowo wartości obrotów narastających, bowiem obroty za 01-09.2026 r. ujęte są w SAP S4/HANA razem z bilansem otwarcia (dla kont bilansowych). 

Mając na uwadze powyższe, przy przenoszeniu sald z SAP R/3 do SAP S4/HANA uwzględnić należy wymagania raportowania JPK CIT.

6. Podsumowanie

Prawidłowe przygotowanie migracji wymaga ścisłej współpracy zespołów finansowych, podatkowych i IT już na etapie projektowania nowego środowiska SAP. W założeniu raport JPK_KR_PD powinien zawierać ciągłe i spójne dane uzgodnione ze sprawozdaniem finansowym. W konsekwencji musi obejmować całość ksiąg i komplet zapisów oraz zapewnić identyfikacje wszystkich kont księgowych, na których w raportowanym okresie występują obroty, salda.

W praktyce S/4 rzadko pozwala na pełne odtworzenie ksiąg, jeśli migracja następuje w trakcie roku. W takiej sytuacji rozwiązaniem jest wygenerowanie dwóch JPK CIT:

• JPK 1 – od początku roku do dnia migracji (SAP R3),
• JPK 2 – od dnia migracji do końca roku (np. SAP S/4).

Istotnym aspektem jest zachowanie ciągłości, spójności danych, a także pełnej zgodności sald bilansowych.

Planujesz migrację do SAP S/4HANA? Warto już na etapie projektu uwzględnić wymagania JPK CIT. Eksperci RSM wspierają organizacje zarówno w analizie skutków podatkowych migracji SAP jak i w przygotowaniu raportowania JPK CIT zgodnego z wymaganiami Ministerstwa Finansów.