# JPK i eksport księgowy w e-commerce 2026: zgodność, którą pomija większość sklepów > JPK_V7M co miesiąc, JPK_KR na żądanie kontroli, a do tego KSeF. W sklepach internetowych 7 na 10 nie potrafi wytworzyć spójnej ewidencji bez kilkudniowej pracy ręcznej. Anatomia czystego eksportu księgowego w WooCommerce i PrestaShop. - Strona: - Język: pl - Opublikowano: 2026-05-25 - Zaktualizowano: 2026-10-08 - Inne języki: [fr](https://www.datafirefly.com/2026/05/25/fec-export-comptable-ecommerce-woocommerce-prestashop-conformite-fiscale-2026/index.md), [en](https://www.datafirefly.com/en/2026/05/25/accounting-export-ecommerce-fec-france-woocommerce-prestashop-tax-compliance-2026/index.md), [es](https://www.datafirefly.com/es/2026/05/25/fec-exportacion-contable-ecommerce-woocommerce-prestashop-conformidad-fiscal-2026/index.md), [de](https://www.datafirefly.com/de/2026/05/25/fec-buchhaltungs-export-ecommerce-woocommerce-prestashop-steuerkonformitaet-2026/index.md), [it](https://www.datafirefly.com/it/2026/05/25/esportazione-contabile-ecommerce-woocommerce-prestashop-conformita-fiscale-2026/index.md), [pt](https://www.datafirefly.com/pt/2026/05/25/fec-exportacao-contabilistica-ecommerce-woocommerce-prestashop-conformidade-fiscal-2026/index.md), [nl](https://www.datafirefly.com/nl/2026/05/25/fec-boekhoudexport-ecommerce-woocommerce-prestashop-fiscale-conformiteit-2026/index.md) - Indeks: ## 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: 1. **Brak pojęcia dziennika**. Jeden wiersz to jedno zamówienie, a nie zapis Wn i Ma. 2. **Brak rozksięgowania na konta**. Kwoty netto, VAT i wysyłka nie są mapowane na konta planu. 3. **Brak ciągłej numeracji zapisów**. 4. **Brak rozdzielenia sprzedaży od wpływu**. Data płatności i data ujęcia są mylone. 5. **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](https://www.datafirefly.com/pl/produkt/eksport-ksiegowy-woocommerce-fec/) albo [PrestaShop](https://www.datafirefly.com/pl/produkt/dfaccountingexport-eksport-ksiegowy-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](https://www.datafirefly.com/pl/2026/05/26/kopie-zapasowe-sklepu-prestashop-regula-3-2-1-szyfrowanie-przywracanie-2026/). ### 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](https://www.datafirefly.com/pl/2026/05/23/prawo-do-bycia-zapomnianym-rodo-art-17-usuwanie-konta-prestashop-2026/). ### 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 1. **Wstępne mapowanie z biurem**: sesja na dwie godziny, aby zwalidować użyte konta, dzienniki i obsługę przypadków szczególnych. 2. **Eksport miesięczny** przekazywany do biura na bieżąco. Pominięty miesiąc to miesiąc do odtworzenia. 3. **Uzgadnianie rozrachunków** w celu wychwycenia zwrotów i korekt nieujętych w ewidencji. 4. **Zamknięcie roczne** z finalną walidacją i zaszyfrowanym archiwum na wymagany okres. 5. **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](https://www.datafirefly.com/pl/solutions/prestashop/zgodne-fakturowanie/) oraz [w WooCommerce](https://www.datafirefly.com/pl/solutions/wordpress/zgodne-fakturowanie/).