Obowiązek raportowania JPK CIT – obejmujący struktury JPK_KR_PD (księgi rachunkowe z częścią podatkową) i JPK_ST_KR (środki trwałe i wartości niematerialne i prawne) – z teorii przeszedł w praktykę. Pierwsze raporty za rok 2025 trafiają do urzędów skarbowych w lipcu 2026, a od stycznia 2026 obowiązkiem objęta jest kolejna grupa podatników.
Doświadczenia firm, które przeszły już przez proces przygotowania plików JPK CIT, pokazują, że problemy wdrożeniowe powtarzają się w przewidywalnych miejscach. W tym artykule omawiamy najczęstsze z nich – od znaczników kont księgowych, przez spójność między JPK_KR_PD a JPK_ST_KR, po kwestie techniczne związane z walidacją i wysyłką plików.
Znaczniki kont to element, który w praktyce generuje największą liczbę problemów wdrożeniowych. Struktura JPK_KR_PD wymaga, aby każde konto księgowe wykazywane w Zestawieniu Obrotów i Sald (węzeł ZOiS) miało przypisane odpowiednie znaczniki identyfikujące – zgodnie ze słownikami opublikowanymi przez Ministerstwo Finansów w rozporządzeniu z 16 sierpnia 2024 roku.
S_12_1 – znacznik rachunkowy obowiązkowy – identyfikuje charakter konta w kontekście rachunkowości (np. aktywa obrotowe, zapasy, materiały). Każde konto ostatecznego zapisu musi mieć przypisany co najmniej ten znacznik. Jego brak powoduje natychmiastowe odrzucenie pliku przez walidator.
S_12_2 – znacznik rachunkowy fakultatywny – pozwala na dokładniejsze uszczegółowienie kategorii rachunkowej. Nie jest wymagany, ale jego użycie pomaga w jednoznacznej klasyfikacji kont o złożonym charakterze.
S_12_3 – znacznik podatkowy – przypisuje konto do odpowiedniej kategorii w rozliczeniu podatku dochodowego. Dotyczy kont wynikowych (przychody, koszty) oraz kont pozabilansowych służących do ewidencji różnic między wynikiem rachunkowym a podatkowym.
Brak znaczników na kontach analitycznych – firmy często nadają znaczniki wyłącznie na kontach syntetycznych, pomijając analitykę. Tymczasem JPK_KR_PD wymaga znaczników na kontach, na których dokonywane są faktyczne zapisy – czyli zazwyczaj na najniższym poziomie analitycznym.
Nieodpowiedni poziom szczegółowości – słownik znaczników ma strukturę hierarchiczną (np. BABI1 → BABI1_O → BABI1_A). Pytanie, na jakim poziomie szczegółowości nadać znacznik, budzi wątpliwości. Ministerstwo Finansów w sekcji pytań i odpowiedzi potwierdziło, że jeśli firma nie posiada wyodrębnionych kont na najniższym poziomie, może użyć znacznika o mniejszym stopniu szczegółowości – nie musi przebudowywać planu kont.
Pominięcie znaczników podatkowych (PD) – znaczniki PD (np. PD1 – przychody podatkowe, PD4 – koszty uzyskania przychodu) dotyczą kont wynikowych. Ich brak oznacza, że węzeł RPD (Rozliczenie Podatku Dochodowego) nie będzie mógł zostać prawidłowo zasilony danymi. Wyjątkiem są spółki opodatkowane estońskim CIT – zgodnie z wyjaśnieniami MF, nie muszą one nadawać znaczników PD ani wypełniać węzła RPD.
Znaczniki na kontach pozabilansowych – firmy prowadzące ewidencję różnic podatkowych na kontach pozabilansowych muszą nadać im osobne znaczniki PD z przyrostkiem _PB (np. PD1_PB, PD4_PB). To łatwo pominąć, bo konta pozabilansowe bywają traktowane jako „mniej ważne” w codziennej księgowości.
Dobrze skonfigurowany system ERP pozwala na przypisanie znaczników bezpośrednio w planie kont, na odpowiednim poziomie analitycznym. Każdy nowy zapis księgowy automatycznie dziedziczy znacznik przypisany do konta, na które trafia. System powinien również sygnalizować brak znacznika na koncie, które wykazuje obroty – zanim plik zostanie wygenerowany i wysłany, a nie dopiero po odrzuceniu przez walidator MF.
JPK CIT to nie jeden plik, ale dwie odrębne struktury, które muszą być spójne – JPK_KR_PD (księgi rachunkowe) i JPK_ST_KR (ewidencja środków trwałych). W praktyce spójność między nimi to jedno z najczęstszych źródeł problemów.
Wartości amortyzacji podatkowej wykazane w JPK_ST_KR (naliczona amortyzacja poszczególnych środków trwałych) muszą być zbieżne z kosztami amortyzacji wykazanymi w dzienniku i na kontach kosztowych w JPK_KR_PD. Jeśli sumy się nie zgadzają, organ podatkowy natychmiast widzi rozbieżność – i może ją potraktować jako sygnał do kontroli.
Ponadto wartość początkowa podatkowa środków trwałych w JPK_ST_KR powinna odpowiadać zapisom na kontach bilansowych środków trwałych w JPK_KR_PD. Każda zmiana wartości początkowej (ulepszenie, częściowa likwidacja) musi być odzwierciedlona spójnie w obu strukturach.
Różnice między amortyzacją bilansową a podatkową – firma może stosować inne stawki amortyzacyjne dla celów rachunkowych niż podatkowe (np. skrócona amortyzacja bilansowa vs. stawki z wykazu MF). Jeśli system ERP prowadzi tylko jedną linię amortyzacji, dane w JPK_ST_KR i JPK_KR_PD będą ze sobą niespójne. System musi obsługiwać dwie równoległe linie amortyzacji – bilansową i podatkową – z osobnym naliczaniem odpisów.
Nieaktualna ewidencja środków trwałych – środki trwałe wciąż figurujące w ewidencji mimo faktycznej likwidacji, brak numerów inwentarzowych (szacunkowo 15–30% bazy przy pierwszej weryfikacji), nieaktualne lokalizacje. Każdy z tych braków powoduje, że plik JPK_ST_KR nie przechodzi walidacji. Rozwiązaniem jest fizyczny spis z natury – dający jednoznaczny punkt zerowy.
Środki trwałe poniżej limitu – składniki majątku jednorazowo odpisane w koszty (wartość poniżej 10 000 zł) nie podlegają ewidencji środków trwałych i nie powinny pojawiać się w JPK_ST_KR. Jeśli system ERP automatycznie wciąga je do ewidencji, plik będzie zawierał nadmiarowe pozycje.
System ERP z modułem środków trwałych zintegrowanym z księgowością eliminuje większość tych problemów, ponieważ dane o amortyzacji, wartości początkowej i zmianach są prowadzone w jednym źródle. Raport kontrolny, który porównuje sumy amortyzacji z JPK_ST_KR i odpowiadające im koszty z JPK_KR_PD jeszcze przed wysyłką, pozwala wyłapać rozbieżności zanim trafią do urzędu skarbowego.
Węzeł RPD w strukturze JPK_KR_PD zawiera dane służące do rozliczenia podatku dochodowego – przychody podatkowe, koszty uzyskania przychodu, dochód lub stratę oraz różnice między wynikiem bilansowym a podatkowym. To sekcja, która wymaga nie tylko poprawnych znaczników PD na kontach, ale również uzgodnienia danych z deklaracją CIT-8.
Brak wyodrębnionych kont podatkowych – węzeł RPD wymaga danych, które muszą być uzgodnione z kontami wynikowymi lub pozabilansowymi oznaczonymi znacznikami PD. Jeśli firma dotychczas nie prowadziła ewidencji różnic podatkowych na osobnych kontach (a jedynie w arkuszach kalkulacyjnych poza systemem), uzupełnienie węzła RPD wymaga przebudowy procesu.
Nieprawidłowe znaczniki podatkowe – przypisanie kosztu do znacznika PD4 (koszty uzyskania przychodu) zamiast PD5 (koszty niestanowiące kosztów uzyskania przychodu) zmienia obraz podatkowy firmy i może prowadzić do rozbieżności z deklaracją CIT-8. Dobór znaczników PD wymaga każdorazowej oceny charakteru podatkowego operacji, a nie mechanicznego mapowania.
Rozbieżność RPD z CIT-8 – dane w węźle RPD muszą być spójne z zeznaniem podatkowym. Jeśli przychody podatkowe w RPD nie zgadzają się z przychodami wykazanymi w CIT-8, organ podatkowy dysponuje narzędziem do automatycznego wykrycia tej rozbieżności. System ERP powinien umożliwiać wygenerowanie raportu uzgadniającego RPD z CIT-8 jeszcze przed złożeniem obu dokumentów.
Struktura JPK_KR_PD wymaga, aby zapisy w dzienniku zawierały numery NIP kontrahentów występujących w operacjach gospodarczych. Ponadto, jeśli operacja dotyczy faktury wystawionej lub otrzymanej za pośrednictwem KSeF, zapis powinien zawierać numer identyfikujący fakturę w Krajowym Systemie e-Faktur.
Baza kontrahentów musi być kompletna i spójna – każdy kontrahent w systemie ERP musi mieć poprawnie przypisany NIP. Faktury zaksięgowane na konto „Różni kontrahenci” lub z brakującym NIP-em powodują, że plik JPK_KR_PD jest niekompletny. Porządkowanie bazy kontrahentów powinno nastąpić przed pierwszym generowaniem pliku, a nie w trakcie naprawiania błędów walidacji.
Numery KSeF muszą być zapisane przy dekretach – system ERP zintegrowany z KSeF automatycznie przechowuje numery KSeF przy odpowiednich dokumentach. Jeśli integracja nie obejmuje automatycznego zapisu numeru KSeF w dzienniku, dane trzeba uzupełniać ręcznie – co jest pracochłonne i błędogenne przy dużej liczbie dokumentów.
Firmy z dużą liczbą operacji księgowych mogą generować pliki JPK_KR_PD o znacznych rozmiarach. Ministerstwo Finansów dopuszcza możliwość dzielenia pliku JPK_KR_PD na mniejsze okresy (kwartalne, miesięczne, a nawet tygodniowe) z zachowaniem ciągłości zapisów. To istotne rozwiązanie dla podmiotów, których roczny plik przekraczałby limity techniczne lub był niepraktycznie duży do weryfikacji.
Uwaga: JPK_ST_KR nie podlega dzieleniu – plik ewidencji środków trwałych musi obejmować cały rok i być wysłany jako jeden dokument. W przypadku dużej bazy środków trwałych wymaga to optymalizacji danych (np. usunięcie zlikwidowanych pozycji).
Ministerstwo Finansów udostępnia walidator plików JPK. Warto przeprowadzić walidację techniczną (zgodność XML ze schematem XSD) i merytoryczną (spójność sum kontrolnych, kompletność znaczników, poprawność NIP-ów) jeszcze przed oficjalną wysyłką. System ERP z wbudowanym mechanizmem walidacji pozwala na wyłapanie błędów na etapie generowania pliku – zanim trafi on do urzędu skarbowego.
Nie czekaj z pierwszą generacją pliku do terminu złożenia. Wygenerowanie testowego pliku JPK_KR_PD (np. za pierwszy kwartał roku) pozwala zidentyfikować braki w znacznikach, niespójności w danych kontrahentów i problemy z integracją KSeF – z odpowiednim wyprzedzeniem, by je naprawić.
JPK CIT to nie jednorazowe zadanie eksportowe, ale nowy standard raportowania, który wymaga uporządkowania danych u źródła – w planie kont, w ewidencji środków trwałych i w bazie kontrahentów. Firmy, które traktują przygotowanie do JPK CIT jako projekt porządkujący procesy księgowe, zyskują nie tylko zgodność z przepisami, ale również wyższą jakość danych finansowych na co dzień.
Kluczową rolę w tym procesie pełni system ERP, który integruje księgowość, ewidencję środków trwałych i raportowanie podatkowe w jednym środowisku – eliminując rozbieżności wynikające z prowadzenia danych w rozproszonych narzędziach. Im wcześniej firma przeprowadzi audyt gotowości i testową generację pliku, tym mniejsze ryzyko problemów w momencie, gdy termin złożenia będzie już na wyciągnięcie ręki.
Czym różni się JPK_KR_PD od JPK_ST_KR?
JPK_KR_PD to struktura obejmująca dane z ksiąg rachunkowych – dziennik, zestawienie obrotów i sald oraz część podatkową (węzeł RPD). JPK_ST_KR to osobna struktura zawierająca dane o środkach trwałych i wartościach niematerialnych i prawnych – wartości początkowe, stawki amortyzacji podatkowej, naliczoną amortyzację. Razem tworzą one tzw. JPK CIT.
Co to są znaczniki kont w JPK CIT?
Znaczniki to kody przypisywane do kont w planie kont zgodnie ze słownikami Ministerstwa Finansów. Znacznik S_12_1 (rachunkowy, obowiązkowy) identyfikuje charakter konta w kontekście rachunkowości. Znacznik S_12_3 (podatkowy) przypisuje konto do kategorii w rozliczeniu podatku dochodowego. Ich prawidłowe nadanie jest warunkiem poprawnej walidacji pliku JPK_KR_PD.
Czy można podzielić plik JPK_KR_PD na mniejsze okresy?
Tak. Ministerstwo Finansów dopuszcza dzielenie pliku JPK_KR_PD na okresy kwartalne, miesięczne, a nawet tygodniowe, z zachowaniem ciągłości zapisów. Nie dotyczy to jednak JPK_ST_KR – plik ewidencji środków trwałych musi obejmować cały rok podatkowy.
Jaki jest termin złożenia JPK CIT za rok 2025?
Na mocy rozporządzenia z lutego 2026 roku termin złożenia plików JPK CIT za rok podatkowy 2025 został wydłużony do końca siódmego miesiąca po zakończeniu roku podatkowego. Dla firm z rokiem kalendarzowym oznacza to termin do 31 lipca 2026 roku.
Czy spółki na estońskim CIT muszą nadawać znaczniki podatkowe?
Nie. Zgodnie z wyjaśnieniami Ministerstwa Finansów, podatnicy opodatkowani ryczałtem od dochodów spółek (estoński CIT) nadają znaczniki rachunkowe (S_12_1, S_12_2), ale nie muszą nadawać znaczników podatkowych PD. W węźle RPD wykazują wartości zerowe.
Jak system ERP pomaga w przygotowaniu JPK CIT?
System ERP integruje plan kont ze znacznikami, prowadzi dwie linie amortyzacji (bilansową i podatkową), automatycznie zapisuje numery KSeF przy dekretach, generuje plik XML zgodny ze schematem XSD i umożliwia walidację przed wysyłką. Dzięki temu dane w JPK_KR_PD i JPK_ST_KR są spójne, a proces raportowania zautomatyzowany.
