JPK: pliki, które trzeba umieć wygenerować, zanim ktoś o nie poprosi
Jednolity Plik Kontrolny to polski odpowiednik tego, co w innych krajach nazywa się znormalizowanym plikiem księgowym. W praktyce sklep internetowy ma do czynienia z trzema strukturami: JPK_V7M (albo V7K przy rozliczeniu kwartalnym), łączącym ewidencję VAT z deklaracją i wysyłanym co miesiąc, JPK_KR z księgami rachunkowymi, przekazywanym na żądanie organu, oraz JPK_FA z fakturami. Do tego dochodzi Krajowy System e-Faktur, który zmienia sposób wystawiania i archiwizowania faktur.
Różnica wobec zwykłego eksportu zamówień jest zasadnicza. JPK_V7M nie jest opcją, tylko comiesięcznym obowiązkiem, a jego treść musi wynikać z ewidencji, którą da się odtworzyć i uzasadnić. JPK_KR bywa żądany w trakcie kontroli, w terminie, w którym nie zdążysz odbudować historii. To właśnie ten punkt, czyli wytworzenie pliku pod presją czasu i bez możliwości poprawiania przeszłości, czyni eksport księgowy ze sklepu krytycznym.
W audytowanych przez nas sklepach 7 na 10 nie potrafi wyprodukować spójnego eksportu księgowego bez kilkudniowej pracy ręcznej. A rachunek jest prosty: brak wiarygodnej ewidencji oznacza zakwestionowanie rozliczeń i szacowanie podstawy opodatkowania na warunkach organu, zwykle niekorzystnych dla firmy.
Dlaczego e-commerce i księgowość nie dogadują się naturalnie
WooCommerce i PrestaShop prowadzą bazę handlową: zamówienia, płatności, zwroty, korekty, koszty wysyłki. Księgowy potrzebuje bazy księgowej: zrównoważonych zapisów po stronie Wn i Ma, zakodowanych według zakładowego planu kont.
Tłumaczenie jednego modelu na drugi przechodzi przez sześć pojęć.
1. Konta zakładowego planu kont
W Polsce nie ma jednego narzuconego planu kont, bo każda jednostka ustala zakładowy plan kont na podstawie ustawy o rachunkowości. Konwencje są jednak ustabilizowane i typowa sprzedaż B2C angażuje:
- Rozrachunki z odbiorcami (zespół 2, np. konto 201 albo 200 z analityką per klient przy niskim wolumenie, zbiorczo przy wysokim)
- Przychody ze sprzedaży towarów (zespół 7, np. 730 albo 700)
- VAT należny (np. 221 z analityką per stawka: 23 %, 8 %, 5 %, 0 %)
- Przychody z tytułu wysyłki jako odrębna analityka, z własnym VAT-em
- Konto rozliczeniowe płatności przed wpływem środków
- Rachunek bankowy (np. 130) przy faktycznym wpływie
- Usługi obce albo koszty finansowe na prowizje operatorów płatności
Konkretną numerację trzeba ustalić ze swoim biurem rachunkowym, bo to ono odpowiada za spójność z resztą ksiąg.
2. Dzienniki i rejestry
Minimum trzy strumienie: sprzedaż (faktura i VAT należny w momencie powstania obowiązku podatkowego), bank (rzeczywisty wpływ na rachunek) oraz pozostałe operacje (korekty, zwroty, prowizje operatorów, różnice kursowe).
3. Data ujęcia kontra data wpływu
Zamówienie opłacone 31 marca o 23.59 i rozliczone przez operatora 2 kwietnia trafia do ewidencji sprzedaży w marcu (moment powstania obowiązku podatkowego), a wpływ środków w kwietniu. To rozjechanie dat jest główną przyczyną błędów w naiwnych eksportach z e-commerce.
4. Obsługa VAT
Trzy przypadki praktyczne:
- Sprzedaż krajowa: VAT należny według właściwej stawki polskiej.
- Wewnątrzwspólnotowa dostawa towarów B2B z ważnym numerem VAT UE kontrahenta: stawka 0 % przy spełnieniu warunków dokumentacyjnych, z wykazaniem w JPK_V7M i informacji podsumowującej VAT-UE.
- Sprzedaż B2C do innych krajów UE: po przekroczeniu progu 10 000 EUR rocznie łącznie stosujesz stawkę kraju konsumenta i rozliczasz się przez procedurę OSS, poza standardowym JPK_V7M.
Procedura OSS jest pułapką, która wywraca zgodność w sklepach wielokrajowych. Wymaga odrębnej analityki per kraj i stawka, bo bez niej kwartalne rozliczenie OSS jest niewykonalne.
5. Zwroty i korekty
Zwrot klienta generuje fakturę korygującą ORAZ zapis rozliczenia zwrotu pieniędzy. Oba muszą pojawić się osobno, z powiązaniem do dokumentu pierwotnego. Ujmowanie zwrotu jako „anulowania” pierwotnego zapisu jest nieprawidłowe, bo psuje ciągłość zapisów.
6. Prowizje operatorów płatności
Zamówienie za 400 zł opłacone przez operatora wpływa na rachunek pomniejszone o prowizję. Różnica idzie na koszty, nie znika. Bez tego rozksięgowania uzgodnienie rachunku bankowego jest niemożliwe.
Dlaczego natywne eksporty e-commerce nie wystarczają
WooCommerce i PrestaShop mają natywne eksporty CSV zamówień. Nie są one ewidencją księgową z pięciu powodów:
- Brak pojęcia dziennika. Jeden wiersz to jedno zamówienie, a nie zapis Wn i Ma.
- Brak rozksięgowania na konta. Kwoty netto, VAT i wysyłka nie są mapowane na konta planu.
- Brak ciągłej numeracji zapisów.
- Brak rozdzielenia sprzedaży od wpływu. Data płatności i data ujęcia są mylone.
- Brak obsługi zwrotów, korekt i prowizji.
Efekt praktyczny: biuro rachunkowe dostaje arkusz i spędza od 8 do 12 godzin na okres, odtwarzając zapisy ręcznie. Przy 2 000 zamówień rocznie to kilka tysięcy złotych dodatkowej obsługi. Przy 20 000 zamówień rocznie biuro albo odmawia prowadzenia, albo wycenia przetworzenie na kilkanaście tysięcy złotych.
Architektura czystego eksportu księgowego
Poważny moduł eksportu dla WooCommerce albo PrestaShop wdraża pięć warstw.
Warstwa 1: mapowanie kont
Administrator konfiguruje powiązanie między encjami sklepu a kontami zakładowego planu kont: kategoria produktu na konto przychodów, metoda dostawy na przychody z wysyłki, stawka VAT na analitykę VAT należnego, metoda płatności na konto rozliczeniowe, a potem bank, prowizje operatorów na koszty z podziałem per operator.
Warstwa 2: generowanie zapisów
Dla każdego zamówienia w okresie moduł tworzy od 3 do 8 odrębnych zapisów: sprzedaż netto, VAT należny per stawka, wysyłka, wpływ środków z przesunięciem daty oraz prowizja operatora jako osobny zapis. Przy korekcie generujemy zapisy przeciwstawne, nigdy modyfikację pierwotnych.
Warstwa 3: stabilna numeracja
Numer zapisu jest nadawany według trwałego licznika, restartowanego z każdym rokiem obrotowym. Raz wyeksportowany zapis zachowuje swój numer na zawsze, więc moduł musi przechowywać ten stan, aby przy ponownym generowaniu nie przenumerować.
Warstwa 4: walidacja i kontrole
Przed eksportem moduł sprawdza równowagę stron Wn i Ma w każdym zapisie, ciągłość numeracji, zgodność formatu i dat, obecność wszystkich wymaganych pól oraz istnienie użytych kont w skonfigurowanym planie.
Warstwa 5: eksport
Plik końcowy powstaje w formacie uzgodnionym z biurem rachunkowym albo w strukturze XML zgodnej ze schemą JPK, jeśli moduł generuje plik wprost. W praktyce częstszy i bezpieczniejszy jest wariant pośredni: sklep produkuje czystą ewidencję, a program księgowy składa z niej finalne JPK.
Pułapki prawne, których nie wolno zlekceważyć
1. Okres przechowywania
Księgi rachunkowe i dowody księgowe przechowuje się co do zasady 5 lat, licząc od początku roku następującego po roku obrotowym, którego dotyczą. Dla sklepu obejmuje to eksporty bazy, faktury PDF i logi operatorów płatności. Strategia kopii zapasowych musi pokrywać ten horyzont: zobacz nasz artykuł o kopiach zapasowych PrestaShop i regule 3-2-1.
2. Zapisy muszą być chronologiczne i nieodwracalne
Ustawa o rachunkowości wymaga, aby zapisy były trwałe i uporządkowane chronologicznie. Moduł, który pozwala „przegenerować” zamknięty okres, nadpisując przeszłość, jest nie do przyjęcia. Po zamknięciu okresu ewidencja jest zamrożona.
3. Konsekwencje braku wiarygodnej ewidencji
Nierzetelne albo wadliwe prowadzenie ksiąg jest sankcjonowane na gruncie kodeksu karnego skarbowego, a niezłożenie albo nieprzekazanie wymaganych plików w terminie skutkuje dodatkowymi konsekwencjami. Wysokość zależy od kwalifikacji czynu i okoliczności, więc konkretne ryzyko warto omówić z doradcą podatkowym.
4. RODO i dane księgowe
Artykuł 17 RODO pozwala klientowi żądać usunięcia danych, ale obowiązek księgowy narzuca ich przechowywanie. Rozwiązanie prawne: zachowujemy dane niezbędne do wypełnienia obowiązku (nazwa, adres do faktury, kwoty), a usuwamy resztę. Temat rozwijamy w artykule o prawie do bycia zapomnianym bez zrywania śladu księgowego.
5. Krajowy System e-Faktur
KSeF zmienia sposób wystawiania i przechowywania faktur w obrocie krajowym, wprowadzając ustrukturyzowaną fakturę przekazywaną przez system centralny. Harmonogram wdrożenia był kilkukrotnie zmieniany, a szczegóły obowiązków zależą od statusu podatnika i rodzaju transakcji. To temat, który trzeba ustalić z księgowością przed budową stacku fakturowego w sklepie, a nie po, bo wpływa na to, kto i w jakim formacie generuje fakturę: sklep czy system zewnętrzny.
WooCommerce i PrestaShop: dwie logiki wdrożenia
WooCommerce
WooCommerce jest projektowany pod rynek amerykański, więc polska ewidencja wymaga wtyczki, która potrafi odczytać zamówienia, ich pozycje i podatki oraz zmapować bramki płatności na konta. Trzeba też zadbać o zgodność z HPOS i o poprawną obsługę zwrotów.
PrestaShop
PrestaShop natywnie obsługuje stawki VAT, konta klientów oraz sekwencyjne faktury i korekty (ps_order_invoice, ps_order_slip). Praca modułu jest więc prostsza: zamienić faktury i korekty na zapisy księgowe, bez przeliczania VAT od zera.
Przypadki szczególne
Sprzedaż B2B wewnątrzwspólnotowa
Przy ważnym numerze VAT UE kontrahenta stosujemy stawkę 0 % przy spełnieniu warunków dokumentacyjnych, z wykazaniem w JPK_V7M oraz w informacji podsumowującej. Moduł traktujący taką sprzedaż jak krajową B2C generuje błędną ewidencję.
Procedura OSS dla B2C w UE
Powyżej progu 10 000 EUR rocznie ewidencja musi rozdzielać sprzedaż per kraj i stawka, inaczej kwartalne rozliczenie OSS jest niewykonalne.
Abonamenty i rozliczenie w czasie
Przy sprzedaży abonamentowej część przychodu dotyczy przyszłych okresów. Moduł powinien umożliwiać ujęcie rozliczeń międzyokresowych, zamiast księgować całość jednorazowo.
Bony i karty podarunkowe
Sprzedaż bonu nie jest sprzedażą towaru, lecz zobowiązaniem wobec klienta, a moment rozliczenia zależy od tego, czy bon jest jednego czy różnego przeznaczenia. To subtelność, na której potyka się większość eksportów automatycznych, i punkt do ustalenia z księgowością.
Zalecany obieg pracy z biurem rachunkowym
- Wstępne mapowanie z biurem: sesja na dwie godziny, aby zwalidować użyte konta, dzienniki i obsługę przypadków szczególnych.
- Eksport miesięczny przekazywany do biura na bieżąco. Pominięty miesiąc to miesiąc do odtworzenia.
- Uzgadnianie rozrachunków w celu wychwycenia zwrotów i korekt nieujętych w ewidencji.
- Zamknięcie roczne z finalną walidacją i zaszyfrowanym archiwum na wymagany okres.
- Test raz w roku: zasymulować żądanie JPK_KR i sprawdzić, czy dane da się wytworzyć w rozsądnym czasie.
Zastrzeżenie
Ten artykuł ma charakter informacyjny i nie stanowi porady podatkowej ani księgowej. Struktury JPK, harmonogram KSeF oraz szczegółowe obowiązki ewidencyjne bywają nowelizowane. Konkretne mapowanie kont, kwalifikację transakcji i terminy ustal z księgowym albo doradcą podatkowym prowadzącym Twoją firmę.
W syntezie
Ewidencja księgowa w e-commerce to nie kolejny eksport. To obowiązek, którego niedopełnienie otwiera drogę do zakwestionowania rozliczeń. Poważny moduł eksportu zastępuje od 10 do 30 godzin ręcznego przetwarzania na okres, zabezpiecza terminy w razie kontroli i daje biuru rachunkowemu plik nadający się do bezpośredniego zaimportowania.
Dobry odruch w 2026 roku: zwalidować mapowanie z biurem rachunkowym już przy instalacji modułu, eksportować co miesiąc i raz w roku przetestować wytworzenie kompletu danych. Godzina dyscypliny miesięcznie zamiast tygodni stresu w razie kontroli.
Aby przejść do działania: nasze zestawienia modułów do zgodnego fakturowania w PrestaShop oraz w WooCommerce.
