JPK_KR_PD w SAP – wymagania i przygotowanie danych

Sprawdź, jakie dane i konfigurację trzeba przygotować w SAP, aby prawidłowo generować JPK_KR_PD – od znaczników kont i danych kontrahentów po KSeF, RPD i SAP DRC.

JPK_KR_PD to kluczowa struktura JPK_PD dla podatników prowadzących księgi rachunkowe. Obejmuje dane z ksiąg rachunkowych rozszerzone o informacje wymagane na potrzeby podatku dochodowego – znaczniki kont, dane kontrahentów, numery faktur z KSeF oraz rachunek różnic podatkowych (RPD). Dla podatników objętych obowiązkiem raportowania ksiąg rachunkowych JPK_PD obejmuje również powiązaną strukturę JPK_ST_KR, dotyczącą środków trwałych oraz wartości niematerialnych i prawnych – tej strukturze poświęcamy odrębny materiał.

W SAP struktura JPK_KR_PD występuje pod oficjalną nazwą SAF-T Accounting Ledgers PD (JPK_KR_PD) – to terminologia używana w SAP Help Portal oraz w konfiguracji SAP Document and Reporting Compliance. Ten artykuł nie jest kolejnym omówieniem harmonogramu obowiązku ani checklistą projektu wdrożeniowego – te tematy omawiamy osobno. Tutaj koncentrujemy się na samej strukturze i na tym, jakie konkretnie dane – z jakich obszarów SAP FI – trzeba przygotować, żeby wygenerowany plik był nie tylko poprawny technicznie, ale też wiarygodny merytorycznie.

JPK_KR_PD to struktura JPK dla ksiąg rachunkowych w ramach JPK_PD. Obejmuje m.in. dane dziennika, zestawienie obrotów i sald, dane kontrahentów, znaczniki kont oraz rachunek różnic podatkowych (RPD). W SAP raport jest obsługiwany przez funkcjonalność SAF-T Accounting Ledgers PD w ramach SAP Document and Reporting Compliance.

Czym jest JPK_KR_PD i jak łączy się z JPK_PD?

Ministerstwo Finansów definiuje JPK_PD jako obszar raportowania obejmujący struktury JPK dla podatków dochodowych. Dla podatników prowadzących księgi rachunkowe w praktyce oznacza to dwie struktury: JPK_KR_PD – dla samych ksiąg rachunkowych, rozszerzonych o dane istotne podatkowo – oraz JPK_ST_KR – dla ewidencji środków trwałych i wartości niematerialnych i prawnych. To istotne rozróżnienie: JPK_PD nie jest jednym plikiem, tylko zestawem struktur, a JPK_KR_PD jest w tym zestawie strukturą centralną z punktu widzenia ksiąg rachunkowych – ale nie jedyną.

JPK_KR_PD odwzorowuje dane ksiąg rachunkowych w strukturze logicznej określonej przez Ministerstwo Finansów. Obejmuje m.in. dziennik, zestawienie obrotów i sald, dane kontrahentów, zapisy na kontach księgi głównej wraz ze znacznikami oraz rachunek różnic podatkowych, pokazujący przejście od wyniku bilansowego do podstawy opodatkowania CIT.

W SAP struktura występuje pod nazwą SAF-T Accounting Ledgers PD (JPK_KR_PD) – to oficjalna terminologia stosowana w SAP Help Portal i w konfiguracji Customizing dla lokalizacji polskiej. Standardowym mechanizmem generowania i walidacji pliku jest SAP Document and Reporting Compliance (DRC), dostępny w aplikacji „Uruchom raporty ustawowe” (Run Statutory Reports) – szczegóły tego procesu omawiamy w dalszej części artykułu.

JPK_KR a JPK_KR_PD – czym się różnią?

To pytanie pojawia się w niemal każdym projekcie: skoro SAP od lat generuje JPK_KR, dlaczego trzeba konfigurować coś nowego? Odpowiedź w jednym zdaniu: JPK_KR to struktura ksiąg rachunkowych przekazywana na żądanie organu podatkowego, natomiast JPK_KR_PD to struktura ksiąg rachunkowych rozszerzona o dane wymagane w ramach JPK dla podatków dochodowych i przekazywana zgodnie z harmonogramem JPK_PD.

JPK_KR funkcjonuje od 1 lipca 2018 r. jako struktura przekazywana na żądanie organu podatkowego – najczęściej w toku kontroli lub czynności sprawdzających, na podstawie art. 193a Ordynacji podatkowej. Podatnik nie wysyła jej samodzielnie ani cyklicznie – generuje ją dopiero na wezwanie urzędu, wyłącznie za wskazany okres.

JPK_KR_PD wprowadza odmienny model: podatnicy objęci obowiązkiem prowadzą księgi w formie elektronicznej zgodnej ze strukturą logiczną publikowaną przez Ministerstwo Finansów i przekazują je cyklicznie – po zakończeniu roku podatkowego lub obrotowego – bez odrębnego wezwania. Wprowadzenie JPK_KR_PD nie eliminuje JPK_KR – obie struktury współistnieją. JPK_KR pozostaje dostępny na żądanie, między innymi dla okresów lub podmiotów, których nie obejmuje jeszcze obowiązek okresowego raportowania JPK_KR_PD. W SAP oznacza to, że mechanizm generowania starszej struktury JPK_KR pozostaje utrzymywany równolegle do nowej konfiguracji JPK_KR_PD, a nie jest przez nią zastępowany.

Poza charakterem prawnym (na żądanie vs okresowo) różnice sięgają też samej struktury pliku:

Dla zespołu SAP FI oznacza to, że istniejącej konfiguracji JPK_KR nie można po prostu rozszerzyć o kilka dodatkowych pól. Znaczniki kont, dane kontrahentów w wymaganym formacie i logika węzła RPD to elementy, których w mapowaniu do JPK_KR po prostu nie było – wymagają odrębnej analizy i odrębnej konfiguracji w ramach lokalizacji polskiej i SAP Document and Reporting Compliance, nawet jeśli oba raporty korzystają ostatecznie z tych samych dokumentów księgowych w module FI.

JPK_KR_PD 2026 – kogo dotyczy i jakie są terminy?

Obowiązek raportowania JPK_KR_PD Ministerstwo Finansów rozłożyło na trzy etapy, w zależności od wielkości i rodzaju podatnika: pierwszy etap obejmuje podatników CIT, których przychód przekroczył 50 mln EUR, oraz podatkowe grupy kapitałowe; drugi etap – pozostałych podatników CIT oraz określone grupy podatników PIT; trzeci etap – pozostałych podatników prowadzących księgi rachunkowe.

Istotna zmiana dotyczy również samego terminu przekazania pliku. JPK_KR_PD jest przekazywany po zakończeniu roku podatkowego lub obrotowego, a zakres obowiązku został rozłożony na kolejne grupy podatników zgodnie z powyższym harmonogramem. W przypadku podatników CIT od 1 lipca 2026 r. obowiązuje termin do końca siódmego miesiąca po zakończeniu roku podatkowego lub obrotowego, a dla podatników PIT – termin do 31 lipca.

Co to oznacza dla SAP: niezależnie od tego, do którego etapu należy organizacja, dane, które trafiają do JPK_KR_PD, dotyczą zdarzeń księgowanych już w bieżącym roku – przygotowanie planu kont, danych kontrahentów i logiki RPD warto więc rozpocząć z wyprzedzeniem względem faktycznego terminu pierwszej wysyłki. Pełny, aktualizowany harmonogram wraz z omówieniem zmian wchodzących w życie na dany rok podatkowy znajdziesz w naszym artykule JPK CIT 2026 – co zmienia się w SAP? Aktualny harmonogram i terminy warto każdorazowo sprawdzić względem bieżących przepisów Ministerstwa Finansów, ponieważ ulegały już kilkukrotnym korektom.

Jakie dane zawiera JPK_KR_PD?

Struktura logiczna JPK_KR_PD, publikowana przez Ministerstwo Finansów, składa się z kilku głównych węzłów. Dla zespołu SAP FI struktura JPK_KR_PD jest czymś więcej niż dokumentacją podatkową – pokazuje wprost, jakie dane system musi dostarczyć do raportu.

Węzły Nagłówek i Podmiot1 są technicznie najprostsze – to dane identyfikacyjne organizacji i parametry samego raportu. Zwykle nie wymagają dedykowanej pracy nad danymi źródłowymi, o ile dane rejestrowe spółki są aktualne w systemie. Węzeł Kontrahent i węzeł Dziennik omawiamy szerzej w dalszych sekcjach, ponieważ to one generują najwięcej pracy przy przygotowaniu danych – podobnie jak węzeł RPD, któremu poświęcamy odrębną sekcję.

Warto dodać: węzeł ZOiS przewiduje kilka wariantów, dostosowanych do rodzaju jednostki raportującej (m.in. jednostki ogólne, banki, zakłady ubezpieczeń, fundusze inwestycyjne, jednostki stosujące MSSF/MSR). Przy konfiguracji w SAP warto na wczesnym etapie ustalić, który wariant dotyczy danej spółki, ponieważ wpływa to na zakres wymaganych pól.

Jak wygląda przepływ danych JPK_KR_PD w SAP?

Zanim przejdziemy do szczegółów poszczególnych obszarów, warto spojrzeć na cały proces jako jeden przepływ – od księgowania dokumentu w SAP FI, przez klasyfikację i mapowanie, po gotowy, zwalidowany plik XML. Poniższa tabela porządkuje ten przepływ etapami, wraz z typowym ryzykiem na każdym z nich.

Znaczniki kont S_12_1, S_12_2 i S_12_3 w SAP

Każde konto księgi głównej raportowane w JPK_KR_PD musi mieć przypisany znacznik zgodny ze słownikiem publikowanym przez Ministerstwo Finansów. To znaczniki – nie sama obecność konta w planie kont – decydują o tym, jak zapis trafia do zestawienia obrotów i sald oraz jak jest interpretowany przy rozliczeniu podatkowym.

Struktura przewiduje trzy pola znaczników:

• S_12_1 – znacznik podstawowy, obowiązkowy dla każdego raportowanego konta. Wiąże konto z pozycją bilansu lub rachunku zysków i strat zgodnie ze słownikiem Ministerstwa Finansów.
• S_12_2 – znacznik dodatkowy, fakultatywny. Stosuje się go, gdy dane konto ze względu na swój charakter lub saldo może odpowiadać więcej niż jednej pozycji sprawozdania finansowego.
• S_12_3 – znacznik podatkowy, opcjonalny. Przypisuje się go wyłącznie wtedy, gdy istnieje faktyczna podstawa, by oznaczyć konto jako istotne przy analizie różnic między wynikiem bilansowym a podatkowym. S_12_3 pomaga identyfikować konta istotne dla części podatkowej raportowania, ale wartości w węźle RPD nie powinny być traktowane jako prosta suma zapisów ZOiS oznaczonych tym znacznikiem – logika RPD wymaga odrębnej analizy, którą omawiamy w dalszej części artykułu.

W terminologii SAP Customizing znaczniki S_12_1/S_12_2 odpowiadają tzw. znacznikom finansowym (Financial Tags), a S_12_3 – znacznikowi podatkowemu (Income Tax Tag). Ministerstwo Finansów wprost wskazuje, że przypisanie znaczników wymaga analizy rzeczywistej treści ekonomicznej kont i przyjętych w organizacji zasad rachunkowości – nie ma uniwersalnej reguły „konto X = znacznik Y”, którą dałoby się mechanicznie przenieść między firmami czy branżami. To jeden z powodów, dla których mapowanie planu kont bywa najbardziej pracochłonnym elementem całego przygotowania danych.

Konta o niejednorodnym charakterze

Szczególnej uwagi wymaga sytuacja, w której na jednym koncie księgowane są zdarzenia gospodarcze o różnej charakterystyce ekonomicznej – np. konto kosztowe, na którym część zapisów stanowi koszt w pełni uzyskania przychodu, a część podlega ograniczeniom podatkowym. Nie należy jednak automatycznie zakładać, że rozwiązaniem jest zmiana planu kont. Najpierw trzeba ustalić, czy przyjęty sposób ewidencji pozwala prawidłowo przypisać wymagane znaczniki zgodnie z zasadami rachunkowości i podatkowymi.

Dla operacji, które są tylko częściowo istotne podatkowo (np. faktury dokumentujące zdarzenie w części stanowiące, a w części niestanowiące kosztu uzyskania przychodów), dobrą praktyką bywa księgowanie odrębnych pozycji – jednej dla części stanowiącej KUP, drugiej dla części niestanowiącej KUP, każdej z właściwym kodem podatkowym i znacznikiem – zamiast prowadzenia jednego zbiorczego zapisu. W niektórych organizacjach może to dodatkowo prowadzić do rozdzielenia określonych rodzajów operacji na poziomie kont analitycznych, ale nie jest to uniwersalna reguła i każdorazowo wymaga konsultacji z doradcą podatkowym.

Jak to wygląda technicznie w SAP

Mapowanie znaczników odbywa się na poziomie planu kont FI i jest odzwierciedlane w konfiguracji Customizing dla lokalizacji polskiej oraz w ustawieniach SAP Document and Reporting Compliance odpowiedzialnych za generowanie węzła ZOiS. Warto pamiętać o możliwości przypisania alternatywnego znacznika finansowego do konta, które ze swojej natury obsługuje więcej niż jeden kontekst raportowy – to rozwiązuje część przypadków „kont mieszanych” bez konieczności duplikowania kont w planie kont.

W praktyce oznacza to konieczność jednorazowego, kompletnego przeglądu wszystkich kont wykorzystywanych przez daną spółkę – nie tylko kont aktywnych w bieżącym roku obrotowym, ponieważ raport obejmuje pełen zakres zapisów za dany rok podatkowy.

Konfiguracja JPK_KR_PD w SAP – co trzeba ustawić?

Poza samą jakością danych źródłowych, generowanie JPK_KR_PD wymaga kilku konkretnych ustawień Customizing w obszarze lokalizacji polskiej i SAP Document and Reporting Compliance. Na poziomie konceptualnym sprowadzają się one do trzech kroków:

1. Definicja znaczników finansowych (Define Financial Tags). Zdefiniowanie w systemie listy znaczników odpowiadających polom S_12_1 i S_12_2 zgodnie ze słownikiem Ministerstwa Finansów – to punkt odniesienia dla kolejnego kroku mapowania.
2. Definicja znaczników podatkowych (Define Income Tax Tags). Analogiczna definicja dla znacznika podatkowego S_12_3, wykorzystywanego przy identyfikacji kont istotnych dla rachunku różnic podatkowych.
3. Mapowanie kont G/L do znaczników finansowych i podatkowych (Map G/L Accounts to Financial Tags and Income Tax Tags). Przypisanie zdefiniowanych znaczników do poszczególnych kont planu kont – to krok, który wymaga zaangażowania zarówno zespołu SAP FI, jak i działu podatkowego, ponieważ decyzje mapujące mają bezpośredni wpływ na treść raportu.

Poza mapowaniem znaczników, konfiguracja obejmuje standardowo także ustawienia samego raportu w ramach SAP Document and Reporting Compliance (parametry okresu, formularza i procesu walidacji) oraz – tam, gdzie dotyczy – integrację z modułem Asset Accounting dla danych zasilających JPK_ST_KR. Zakres i dokładne nazewnictwo poszczególnych aktywności Customizing mogą się różnić w zależności od wersji systemu i wariantu wdrożenia (S/4HANA on-premise, Private Cloud, Public Cloud) – warto zweryfikować je względem aktualnego przewodnika konfiguracyjnego SAP dla posiadanego środowiska.

Dane kontrahentów i numer NIP w JPK_KR_PD

Poza znacznikami kont drugim obszarem, który najczęściej wymaga dodatkowej pracy z danymi, są dane podstawowe kontrahentów. Struktura JPK_KR_PD wiąże zapisy księgowe z danymi identyfikacyjnymi kontrahenta – przede wszystkim numerem identyfikacji podatkowej wraz z kodem kraju.

W wielu organizacjach, które przez lata prowadziły księgi bez potrzeby raportowania tego poziomu szczegółowości, dane kontrahentów w SAP bywają niekompletne z typowych problemów z jakością danych podstawowych: zdublowanych rekordów tego samego kontrahenta, zakładanych przez różne osoby, brakujących lub błędnie wprowadzonych numerów NIP dla podmiotów zagranicznych, niejednolitych formatów zapisu identyfikatorów (z myślnikami, spacjami, prefiksem kraju lub bez), a także sytuacji, w których kontrahent jest poprawnie powiązany z dokumentem źródłowym, ale nie z samym zapisem na koncie księgowym, który trafia do raportu.

Co warto zrobić w praktyce:

• przeprowadzić audyt i deduplikację danych podstawowych kontrahentów (Business Partner / dostawca / odbiorca) pod kątem kompletności numerów NIP;
• ujednolicić format zapisu identyfikatorów podatkowych, w tym rozróżnienie polskiego NIP od zagranicznych numerów identyfikacyjnych innego rodzaju;
• zweryfikować, czy powiązanie kontrahenta z zapisem księgowym jest spójne również dla dokumentów księgowanych zbiorczo lub korygowanych.

Numer NIP kontrahenta jest wymagany w danych JPK_KR_PD, o ile został kontrahentowi nadany i jest wymagany dla danej operacji – nie każdy kontrahent, zwłaszcza zagraniczny bez polskiej rejestracji podatkowej, musi go posiadać. Dokładny zakres i moment, w którym te dane stają się w pełni obowiązkowe, bywał w poszczególnych latach przedmiotem przepisów przejściowych – aktualny status opisujemy w artykule poświęconym zmianom w JPK CIT na dany rok. Problemem nie jest więc sam brak NIP u kontrahenta bez polskiej rejestracji podatkowej, lecz brak prawidłowo odwzorowanych i rozróżnionych identyfikatorów podatkowych w danych źródłowych SAP.

KSeF i pole D_12 w JPK_KR_PD

Struktura JPK_KR_PD przewiduje w węźle Dziennik pole na numer identyfikujący fakturę lub fakturę korygującą w Krajowym Systemie e-Faktur (pole D_12). To pole ma charakter warunkowy – uzupełnia się je tam, gdzie dokument źródłowy rzeczywiście podlegał fakturowaniu w KSeF, a nie dla każdego zapisu w dzienniku.

Im szerszy zakres transakcji firmy jest objęty obowiązkowym lub dobrowolnym fakturowaniem w KSeF, tym większa część danych do JPK_KR_PD jest potencjalnie już dostępna w systemie. Warunkiem jest jednak to, że numer KSeF rzeczywiście dociera do warstwy, z której korzysta raport JPK_KR_PD – a to nie zawsze jest oczywiste w złożonych architekturach SAP.

W projekcie JPK_KR_PD należy zweryfikować, gdzie w architekturze SAP przechowywany jest numer KSeF oraz czy jest dostępny dla dokumentu i danych wykorzystywanych przez raport. W środowiskach z Central Finance, wieloma systemami źródłowymi lub zewnętrzną platformą fakturowania przepływ numeru KSeF do warstwy raportowej wymaga osobnej weryfikacji – SAP dokumentuje przykładowo scenariusze, w których numer referencyjny KSeF nie jest replikowany z systemu źródłowego do Central Finance, co ma bezpośrednie znaczenie dla dostępności tego pola w danych raportowych.

Co to oznacza dla SAP: organizacje, które wdrożyły integrację z KSeF niezależnie od projektu JPK CIT, mają tu zwykle przewagę – numer KSeF jest już dostępny w danych źródłowych i wymaga jedynie poprawnego zmapowania do pola D_12. Tam, gdzie integracja z KSeF dopiero dojrzewa lub architektura obejmuje Central Finance bądź wiele systemów źródłowych, warto zweryfikować przepływ numeru KSeF na poziomie dokumentu FI już na etapie projektowania tej integracji – a nie dopiero przy konfiguracji samego raportu JPK_KR_PD. Szerzej integrację SAP z KSeF omawiamy w osobnym materiale poświęconym temu tematowi.

RPD – rachunek różnic podatkowych w danych SAP

Węzeł RPD (rachunek różnic podatkowych) jest tym elementem struktury, który przekształca dane księgowe w informację podatkową – pokazuje różnice między wynikiem bilansowym a podstawą opodatkowania CIT. To zdecydowanie najbardziej złożony merytorycznie węzeł całego pliku i jeden z głównych powodów, dla których JPK_KR_PD nie jest po prostu kolejnym eksportem XML z modułu FI.

Najważniejsza różnica między raportem technicznym a gotowością podatkową: SAP może wygenerować plik XML zgodny ze schematem, ale poprawność węzła RPD wymaga uzgodnienia danych księgowych z logiką podatkową – to proces merytoryczny, a nie wyłącznie techniczny.

Orientacyjny zakres pól RPD obejmuje różnice o charakterze przychodowym i kosztowym, w podziale na różnice trwałe i przejściowe:

Uwaga: dokładne brzmienie i zakres poszczególnych pól K_1–K_8 wynika z aktualnego schematu XSD i objaśnień Ministerstwa Finansów, które mogą ewoluować wraz ze zmianami przepisów. Zestawienie powyżej ma charakter orientacyjny – przed skonfigurowaniem logiki klasyfikacji w SAP rekomendujemy każdorazową weryfikację względem aktualnej wersji struktury oraz konsultację z doradcą podatkowym.

Znacznik podatkowy S_12_3 pomaga identyfikować konta istotne dla części podatkowej raportowania, ale – jak wskazaliśmy wcześniej – wartości w węźle RPD nie powinny być traktowane jako prosta suma zapisów ZOiS oznaczonych tym znacznikiem. Konieczne jest uwzględnienie zdarzeń ewidencjonowanych poza księgami rachunkowymi (stąd pola K_7 i K_8) oraz różnic o charakterze przejściowym, które w kolejnych latach się odwracają.

Z tego powodu przygotowanie danych do RPD warto traktować nie jako techniczną konfigurację reguły „konto → KUP/NKUP → pole XML”, lecz jako odrębny proces klasyfikacji podatkowej, prowadzony wspólnie przez zespół SAP FI i dział podatkowy – najlepiej z wyprzedzeniem, a nie dopiero przy pierwszym generowaniu pliku za zamknięty rok podatkowy.

SAP DRC – generowanie i walidacja JPK_KR_PD

W środowiskach SAP obsługujących raport JPK_KR_PD standardowy proces generowania pliku wykorzystuje SAP Document and Reporting Compliance i aplikację „Uruchom raporty ustawowe” (Run Statutory Reports). Proces – w uproszczeniu – przebiega w czterech krokach.

1. Wybór raportu i okresu

Użytkownik wybiera w aplikacji odpowiedni raport dla struktury JPK_KR_PD, okres raportowania oraz cel złożenia (deklaracja pierwotna lub korekta).

2. Generowanie pliku XML

System tworzy plik na podstawie danych już zaksięgowanych w SAP – raport można uruchamiać wielokrotnie, po każdym księgowaniu lub korekcie danych, zanim plik zostanie ostatecznie zatwierdzony.

3. Walidacja

SAP DRC wykonuje walidację formalną (zgodność ze schematem XSD, obecność pól wymaganych strukturą) oraz udostępnia szczegółowy log błędów i ostrzeżeń. Walidacja techniczna potwierdza jednak wyłącznie zgodność ze schematem – nie zastępuje przeglądu merytorycznego danych przez dział podatkowy, zwłaszcza w obszarze znaczników i węzła RPD.

4. Podpis i przekazanie do organu

Plik jest podpisywany (podpisem kwalifikowanym lub profilem zaufanym/ePUAP, w zależności od formy prawnej podatnika). Sposób elektronicznego przekazania pliku zależy od zastosowanego wariantu rozwiązania SAP i konfiguracji integracji z usługą elektronicznego składania – SAP dokumentuje elektroniczne przekazywanie plików JPK poprzez SAP Document and Reporting Compliance, cloud edition jako element odpowiednich scenariuszy wdrożeniowych.

Dlatego przed projektem należy zweryfikować dostępny scenariusz przekazywania dla konkretnej wersji SAP S/4HANA lub SAP ERP. System odnotowuje status przekazania i umożliwia pobranie urzędowego poświadczenia odbioru (UPO).

Cały mechanizm techniczny generowania, walidacji i podpisu pliku pokrywa standardowa funkcjonalność SAP – nie wymaga budowy rozwiązania od podstaw. Realna praca projektowa koncentruje się w innym miejscu: w konfiguracji mapowania (znaczniki, kontrahenci, RPD, KSeF) opisanej w poprzednich sekcjach oraz w jakości danych źródłowych, które raport wykorzystuje.

Standardowy raport wygeneruje technicznie poprawny plik XML nawet wtedy, gdy dane merytoryczne są niekompletne – co nie zwalnia podatnika z odpowiedzialności za poprawność treści pliku.

JPK_KR_PD w SAP S/4HANA

Obowiązek prawny nie różnicuje podatników według wersji systemu ERP – dotyczy zarówno organizacji na SAP S/4HANA, jak i tych wciąż korzystających z SAP ECC.

W środowiskach SAP S/4HANA JPK_KR_PD jest obsługiwany natywnie w ramach SAP Document and Reporting Compliance, zintegrowanego z aplikacją Run Statutory Reports – to priorytetowy kierunek rozwoju nowych funkcji zgodności regulacyjnej dla Polski w portfolio SAP.

Zakres dostępnej funkcjonalności dla Polski może się różnić między wariantami wdrożenia – on-premise, RISE with SAP, Private Cloud Edition i Public Cloud Edition – dlatego przed projektem warto zweryfikować, czy zainstalowana wersja i aktualne SAP Notes dla lokalizacji polskiej obejmują pełną funkcjonalność wymaganą do obsługi struktury JPK_KR_PD, w tym znaczniki, węzeł Kontrahent i węzeł RPD, w konkretnym wariancie chmurowym, z którego korzysta organizacja.

JPK_KR_PD w SAP ECC

Czy SAP ECC obsługuje JPK_KR_PD? Tak. SAP udostępnia funkcjonalność JPK_KR_PD również dla SAP ERP 6.0. Dostępność zależy jednak od wersji systemu, Enhancement Package, poziomu Support Package oraz zastosowanych SAP Notes. Przed rozpoczęciem projektu należy więc sprawdzić konkretny stack systemu, zamiast zakładać, że każda instalacja ECC obsługuje pełny zakres funkcjonalności.

SAP dokumentuje wsparcie dla JPK_KR_PD w SAP ERP 6.0 dla kilku kombinacji Enhancement Package i Support Package, m.in.:

Szczegółowy zakres wsparcia dla poszczególnych kombinacji wersji i Support Package jest dokumentowany przez SAP w ramach SAP Note 3562309 – zalecamy zweryfikowanie aktualnej treści tej notatki (oraz powiązanych z nią poprawek dla lokalizacji polskiej) względem konkretnej instalacji przed rozpoczęciem projektu, ponieważ zakres wsparcia bywa aktualizowany wraz ze zmianami schematu.

Jak sprawdzić gotowość SAP do JPK_KR_PD?

Poniższa lista koncentruje się wyłącznie na gotowości danych i konfiguracji – nie na harmonogramie projektu ani zarządzaniu wdrożeniem, co omawiamy w osobnym przewodniku wdrożeniowym.

• Czy plan kont FI został przeanalizowany pod kątem znaczników S_12_1 (obowiązkowy dla każdego konta) oraz, tam gdzie ma to zastosowanie, S_12_2 i S_12_3?
• Czy konta o niejednorodnym charakterze zostały zidentyfikowane, a sposób ich ewidencji pozwala prawidłowo przypisać wymagane znaczniki?
• Czy dane podstawowe kontrahentów (Business Partner / dostawca / odbiorca) są kompletne, zdeduplikowane i czy numery identyfikacji podatkowej są zapisane w spójnym formacie?
• Czy sprawdzono, gdzie w architekturze SAP przechowywany jest numer KSeF i czy jest dostępny dla danych wykorzystywanych przez raport – zwłaszcza w środowiskach z Central Finance lub wieloma systemami źródłowymi?
• Czy istnieje wspólnie z działem podatkowym ustalona logika klasyfikacji danych dla węzła RPD, uwzględniająca różnice trwałe, przejściowe oraz zdarzenia nieujęte w księgach?
• Czy zainstalowane w SAP SAP Notes dla lokalizacji polskiej (dla S/4HANA lub dla konkretnej kombinacji EHP/SP w SAP ECC) czy zainstalowane poprawki SAP odpowiadają aktualnemu schematowi JPK_KR_PD?
• Czy wygenerowano i zwalidowano testowy plik JPK_KR_PD na danych historycznych – zarówno pod kątem technicznym (zgodność ze schematem), jak i merytorycznym (przegląd przez dział podatkowy)?

Im więcej odpowiedzi „nie” lub „nie wiem”, tym wyraźniejszy sygnał, że sama obecność raportu w systemie nie oznacza gotowości danych, które ten raport ma przedstawić.

Najczęstsze błędy w danych źródłowych

W praktyce projektowej powtarza się kilka typów błędów, które rzadko wynikają z samej konfiguracji raportu, a niemal zawsze z jakości danych źródłowych:

• znaczniki przypisane mechanicznie, bez analizy rzeczywistej treści ekonomicznej konta – co ujawnia się dopiero przy przeglądzie merytorycznym przez dział podatkowy;
• konta o niejednorodnym charakterze księgowań, bez wykorzystania alternatywnych znaczników finansowych ani rozdzielenia pozycji tam, gdzie jest to zasadne;
• niespójne dane kontrahentów – zdublowane rekordy, brakujące lub błędnie sformatowane numery NIP, zwłaszcza dla podmiotów zagranicznych;
• niepełny lub niesprawdzony przepływ numeru KSeF do warstwy raportowej, zwłaszcza w architekturach z Central Finance lub wieloma systemami źródłowymi;
• rozbieżności między kontami oznaczonymi znacznikiem podatkowym a ręcznie wprowadzanymi wartościami RPD, wynikające z braku jednej, spójnej logiki klasyfikacji;
• nieaktualna lokalizacja polska SAP – brak zainstalowanych SAP Notes odpowiadających bieżącemu schematowi JPK_KR_PD, w tym niewłaściwy poziom Support Package w środowiskach SAP ECC.

Podsumowanie

JPK_KR_PD to nie kolejny wariant znanego już eksportu księgowego, tylko odrębna, centralna struktura JPK_PD dla ksiąg rachunkowych – z własnymi węzłami, własną logiką znaczników i własnym rachunkiem różnic podatkowych, których starszy JPK_KR nigdy nie zawierał.

Sama dostępność standardu SAP – skonfigurowane SAP Document and Reporting Compliance i aplikacja Run Statutory Reports – to dopiero punkt wyjścia. Sama obecność standardowej funkcjonalności SAP nie oznacza jeszcze, że organizacja jest gotowa do raportowania. Kluczowe jest poprawne przełożenie wymagań struktury JPK_KR_PD na dane i konfigurację SAP FI: precyzyjne mapowanie znaczników kont zgodnie z rzeczywistą treścią ekonomiczną, kompletne i spójne dane kontrahentów, zweryfikowany przepływ numerów KSeF do warstwy raportowej oraz wiarygodną, uzgodnioną z działem podatkowym logikę klasyfikacji dla węzła RPD.

Organizacje, które potraktują te obszary jako pełnoprawny etap przygotowania danych – a nie formalność przed pierwszym uruchomieniem raportu – wchodzą w obowiązek raportowania JPK_KR_PD ze zdecydowanie mniejszym ryzykiem błędu merytorycznego.