Zmiana programu księgowego w połowie roku 2026: dlaczego samo przeniesienie sald może nie wystarczyć?

Zmiana systemu ERP albo biura rachunkowego w lipcu, sierpniu czy wrześniu 2026 r. wygląda często prosto: zamykamy miesiąc w starym programie, przenosimy salda na kontach i od następnego dnia księgujemy już w nowym. Taki model może wystarczyć do bieżącej pracy, ale nie zapewnia sam z siebie ciągłości ksiąg ani kompletności JPK_KR_PD. Według stanu prawnego i wyjaśnień Ministerstwa Finansów aktualnych na 24.09.2026 r. roczne raportowanie ma odzwierciedlać całość ksiąg za raportowany rok. Jeżeli zapisy powstawały w kilku systemach, dane muszą łącznie tworzyć pełny, spójny obraz bez luk i powtórzeń. MF dopuszcza podział JPK_KR_PD na okresy nie krótsze niż jeden dzień, ale każdy dzień roku musi zostać objęty raportowaniem, a części po złożeniu razem mają wiernie odtwarzać księgi.

Dlaczego samo przeniesienie sald nie zachowuje historii księgowej

Saldo mówi, ile wynosi stan konta na określony dzień. Nie mówi jednak, z jakich zapisów ten stan powstał. Jeśli 30 czerwca 2026 r. konto rozrachunkowe ma saldo 480 000 zł, a 1 lipca do nowego ERP zostanie wprowadzona tylko jedna pozycja „bilans otwarcia 480 000 zł”, nowy system nie zna faktur, korekt, kompensat, przelewów ani zapisów składających się na tę kwotę. Z punktu widzenia bieżącego księgowania saldo może być poprawne. Z punktu widzenia rocznej historii ksiąg jest to tylko stan początkowy drugiej części roku.

Ustawa o rachunkowości definiuje księgi znacznie szerzej niż jako zestaw sald. Obejmują one m.in. dziennik, księgę główną, księgi pomocnicze oraz zestawienia obrotów i sald. Księgi mają być rzetelne, bezbłędne, sprawdzalne i bieżące, a przy systemie komputerowym trzeba zapewnić kontrolę kompletności zbiorów oraz dostęp do danych pozwalający uzyskać informacje o zapisach za dowolnie wybrany okres sprawozdawczy.

Dlatego przy migracji trzeba rozdzielić dwa pojęcia. Migracja operacyjna może polegać na uruchomieniu nowego programu od sald, otwartych rozrachunków, środków trwałych czy stanów magazynowych. Ciągłość dowodowa i raportowa wymaga jednak zachowania szczegółowych danych z okresu sprzed migracji w formie, która nadal pozwala je odczytać, uzgodnić i wykorzystać do sporządzenia JPK_KR_PD.

Ryzyko jest największe, gdy firma po zmianie biura rachunkowego traci dostęp do starej aplikacji. Kopia bazy danych bez programu, licencji, dokumentacji wersji lub narzędzia eksportowego może okazać się praktycznie bezużyteczna. Ustawa wymaga ochrony ksiąg przed utratą i zmianami oraz tworzenia kopii danych; księgi rachunkowe podlegają też co najmniej pięcioletniemu okresowi przechowywania.

W 2026 r. problem ma dodatkowy wymiar. Dla lat podatkowych lub obrotowych rozpoczynających się po 31 grudnia 2025 r. obowiązek elektronicznego prowadzenia i raportowania obejmuje kolejną grupę przedsiębiorców, w szczególności podatników CIT oraz podatników PIT prowadzących odpowiednie księgi, którzy składają JPK_V7M. Pozostali, w tym objęci JPK_V7K, wchodzą do harmonogramu za lata rozpoczynające się po 31 grudnia 2026 r.

Jak zaplanować zmianę systemu, aby JPK_KR_PD za 2026 r. był kompletny

Najważniejsza zasada brzmi: moment zmiany programu nie dzieli roku podatkowego na dwa niezależne byty. Ministerstwo Finansów wprost odniosło się do zmiany systemu finansowo-księgowego w trakcie roku. JPK_KR_PD ma obejmować całość zapisów ksiąg, a przy kilku systemach dane muszą odzwierciedlać cały rok. Jednocześnie struktura pozwala raportować pliki częściowe za dowolne okresy nie krótsze niż jeden dzień, pod warunkiem pełnej ciągłości: bez brakujących dni, bez nakładania się okresów i bez dublowania zapisów.

W praktyce są dwa bezpieczne modele. Pierwszy to pełna migracja historii transakcyjnej do nowego ERP. Wszystkie zapisy od początku roku, wraz z numerami dokumentów, datami, kontami, analityką, kontrahentami i danymi podatkowymi, są przenoszone i uzgadniane. To wygodne, ale technicznie trudne: trzeba pilnować identyfikatorów, hierarchii kont, numeracji, walut, powiązań dokumentów oraz tego, by migracja nie tworzyła nowych zapisów różniących się od ksiąg źródłowych.

Drugi model to pozostawienie pierwszej części roku w starym systemie i rozpoczęcie księgowania w nowym systemie od ustalonego dnia. Wtedy stary system musi zachować zdolność do odtworzenia danych za swój okres, a nowy – za okres po migracji. Można przygotować JPK_KR_PD częściowo, ale granica musi być jednoznaczna. Jeżeli stary system raportuje do 30 czerwca, nowy powinien rozpocząć okres 1 lipca; nie może powstać ani luka, ani podwójne ujęcie 1 lipca.

Trzeba też pamiętać, że kompletność dotyczy nie tylko kwot. W JPK_KR_PD raportowane są m.in. dane dziennika, zapisów na kontach i zestawienia obrotów i sald. MF wskazuje, że w ZOiS należy wykazać wszystkie konta, na których w raportowanym okresie występują obroty lub salda, a także konta syntetyczne, jeżeli obroty lub salda występują na ich analitykach. Sam wykaz kont końcowych może więc być niewystarczający.

W roku rozpoczynającym się po 31 grudnia 2025 r. trzeba ponadto uwzględniać dodatkowe dane wymagane dla JPK podatków dochodowych. Obejmują one – zależnie od statusu podatnika i rodzaju danych – m.in. NIP kontrahenta, numer identyfikujący fakturę w KSeF, jeżeli faktura została wystawiona przy użyciu KSeF, znaczniki identyfikujące konta oraz dane służące rozliczeniu różnic między wynikiem rachunkowym i podatkowym. Dla PIT prowadzących księgi rachunkowe analogiczne obowiązki dodatkowych danych wynikają z rozporządzenia obowiązującego od 1 stycznia 2026 r.

Przed przełączeniem systemu warto więc wykonać próbę końcową: wygenerować plik lub eksport odpowiadający strukturze JPK_KR_PD za okres od początku roku do planowanego dnia migracji, sprawdzić jego poprawność techniczną i uzgodnić wartości z księgami. Nie należy odkładać tego do 2027 r., gdy dostęp do starego programu może już wygasnąć, a osoby znające konfigurację mogą nie być dostępne.

1. Ustal dokładną datę graniczną i zamknij księgowanie w starym systemie za okres do tej daty.
2. Wygeneruj pełne zestawienia kontrolne i testowy JPK_KR_PD za stary okres.
3. Przenieś do nowego systemu salda i dane operacyjne potrzebne do dalszej pracy, ale nie traktuj ich jako zamiennika historii.
4. Uzgodnij saldo końcowe starego systemu z saldem początkowym nowego, osobno dla kont księgi głównej i kluczowych analityk.
5. Sprawdź, czy identyfikatory kont, kontrahentów, dokumentów, znaczniki podatkowe i dane KSeF można spójnie połączyć w raportowaniu rocznym.
6. Zabezpiecz możliwość ponownego wygenerowania danych, korekt i plików także po zakończeniu umowy ze starym dostawcą lub biurem.

Checklista danych do odebrania ze starego programu lub biura rachunkowego

Najlepiej odebrać dane przed wyłączeniem dostępu i potwierdzić ich kompletność protokołem. Sam plik PDF z obrotówką oraz bilans otwarcia do nowego systemu to za mało.

• Pełny eksport zapisów dziennika od początku roku do dnia migracji: numer zapisu, daty, numer i rodzaj dowodu, opis, kwoty, waluta, konta Wn/Ma oraz identyfikatory pozwalające powiązać pozycje.
• Księga główna i księgi pomocnicze wraz z pełną analityką, nie tylko saldami końcowymi.
• Zestawienia obrotów i sald na koniec każdego zamkniętego miesiąca oraz na dzień poprzedzający migrację, z obrotami narastająco od początku roku.
• Plan kont z hierarchią: konta syntetyczne i analityczne, konta nadrzędne, nazwy, status aktywności oraz przypisane znaczniki wymagane w JPK_KR_PD.
• Słownik kontrahentów z kodami używanymi w starym systemie, NIP i krajem identyfikacji; jeżeli dane kontrahenta zmieniały się w roku, należy zachować historię użytych identyfikatorów.
• Identyfikatory KSeF i powiązania faktur z zapisami księgowymi w zakresie, w jakim są wymagane dla raportowanego okresu.
• Dane do rozliczenia podatku dochodowego: przypisania kont do znaczników podatkowych, ewidencję różnic trwałych i przejściowych, informacje o kosztach i przychodach rozpoznawanych podatkowo w innych okresach oraz dane potrzebne do węzła RPD.
• Ewidencję środków trwałych i WNiP z historią wartości początkowej, amortyzacji bilansowej i podatkowej, dokumentów nabycia, przyjęcia, zbycia lub likwidacji oraz numerów inwentarzowych.
• Rozrachunki nierozliczone na dzień migracji: faktura źródłowa, kwota pierwotna, pozostała kwota, termin płatności, waluta, kompensaty, zaliczki i powiązane płatności.
• Rejestry kasowe i bankowe, rozliczenia delegacji, zaliczek pracowniczych i innych kont pomocniczych, jeżeli tworzą zapisy księgowe.
• Dowody księgowe i załączniki albo jednoznaczny dostęp do ich archiwum, tak aby każdy zapis można było połączyć z dokumentem źródłowym.
• Historia korekt, storna, przeksięgowania, dokumenty techniczne migracji oraz wykaz operacji wykonanych już po pierwotnym zamknięciu okresu.
• Kopia techniczna bazy wraz z informacją o wersji programu i sposobie odtworzenia, ale dodatkowo eksporty w formatach czytelnych i możliwych do przetworzenia niezależnie od starej aplikacji.
• Testowy JPK_KR_PD za okres obsługiwany przez stary system oraz raport walidacji; jeśli obowiązek dotyczy także JPK_ST_KR, również dane potrzebne do jego prawidłowego przygotowania.

Po odbiorze danych trzeba wykonać kontrolę ilościową i wartościową. Liczba zapisów w eksporcie powinna zgadzać się z dziennikiem, obroty dziennika z obrotami zestawienia obrotów i sald, a saldo końcowe starego systemu z otwarciem nowego. Warto także losowo prześledzić kilka dokumentów „od faktury do konta i do JPK”. Jeżeli na tym etapie nie da się odtworzyć ścieżki, po zakończeniu współpracy będzie jeszcze trudniej.

FAQ

Czy można rozpocząć pracę w nowym ERP tylko od sald? Tak, jako rozwiązanie operacyjne jest to możliwe, jeżeli sposób prowadzenia ksiąg pozostaje prawidłowy. Nie oznacza to jednak, że wcześniejsze zapisy można usunąć lub zostawić w niedostępnym systemie. Do raportowania i kontroli trzeba zachować pełną historię pierwszej części roku oraz możliwość jej połączenia z zapisami z nowego programu.

Czy za 2026 r. można wysłać dwa pliki JPK_KR_PD – jeden ze starego, drugi z nowego systemu? MF dopuszcza podział JPK_KR_PD na okresy nie krótsze niż jeden dzień. Części muszą bezpośrednio następować po sobie, obejmować cały raportowany rok i po złożeniu razem odtwarzać pełne księgi bez luk i powtórzeń w każdym z węzłów. Nie można więc potraktować dwóch plików jako dwóch niezależnych ksiąg.

Czy wystarczy zachować kopię bazy starego programu? Nie zawsze. Kopia techniczna jest ważna, ale musi istnieć realna możliwość odczytu danych. Jeżeli do uruchomienia bazy potrzebna jest niedostępna wersja aplikacji, licencja albo infrastruktura, sama kopia może nie zapewnić dostępu do ksiąg. Dlatego potrzebne są również eksporty, zestawienia i dokumentacja umożliwiająca odtworzenie danych.

Co z korektą po migracji? Jeżeli korekta dotyczy okresu raportowanego w pliku częściowym, co do zasady należy ponownie przesłać komplet danych za ten sam okres częściowy. Gdy korekta wpływa na kolejne części, także one mogą wymagać korekty. To kolejny powód, aby nie wyłączać dostępu do historii zaraz po migracji.

Do kiedy trzeba przekazać JPK_KR_PD? Według zasad obowiązujących 24.09.2026 r. podmioty podlegające CIT przekazują księgi do końca siódmego miesiąca po zakończeniu roku podatkowego lub obrotowego, a podmioty podlegające PIT – do 31 lipca po zakończeniu roku podatkowego. Dla roku kalendarzowego 2026 oznacza to co do zasady termin 31 lipca 2027 r.

Rekomendacja operacyjna: przed zmianą ERP lub biura rachunkowego w 2026 r. nie zatwierdzaj odbioru migracji na podstawie samego bilansu otwarcia. Wymagaj kompletnego pakietu danych źródłowych, testowego JPK_KR_PD za okres ze starego systemu, uzgodnienia sald i obrotów oraz pisemnego potwierdzenia, kto i w jaki sposób przygotuje pełne raportowanie za cały rok. Dostęp do starego systemu wyłącz dopiero wtedy, gdy potrafisz odtworzyć wcześniejsze zapisy bez pomocy dotychczasowego dostawcy.