JPK_KPiR a sprzedaż z kilku marketplace’ów: jak przygotować spójną ewidencję?

Z perspektywy rozliczeń podatkowych liczba marketplace’ów nie tworzy jednak kilku odrębnych przedsiębiorstw. Organy podatkowe nie traktują poszczególnych marketplace’ów ani kanałów sprzedaży jako odrębnych działalności gospodarczych wymagających prowadzenia osobnych KPiR. Jeżeli wszystkie kanały należą do jednego przedsiębiorcy i są prowadzone w ramach tej samej działalności, ich wyniki powinny zostać ujęte w jednej podatkowej księdze przychodów i rozchodów. Dotyczy to sprzedaży realizowanej przez platformy krajowe, zagraniczne, własny sklep internetowy oraz kanały B2B. Można, a przy większej skali wręcz warto, prowadzić osobne zestawienia pomocnicze dla poszczególnych marketplace’ów, krajów, walut lub modeli sprzedaży. Takie zestawienia ułatwiają kontrolowanie kompletności danych, wykrywanie różnic oraz analizowanie rentowności kanałów, ale nie zastępują właściwej księgi. Wszystkie przychody i koszty muszą ostatecznie spotkać się w jednej spójnej KPiR, a następnie zostać odzwierciedlone w pliku JPK_PKPIR właściwym dla prowadzonej ewidencji.

Najwięcej problemów powstaje wtedy, gdy w jednym procesie zaczynają mieszać się cztery różne kategorie danych. Pierwszą jest sprzedaż, czyli zdarzenie gospodarcze, które zgodnie z przepisami podatkowymi prowadzi do rozpoznania przychodu. Moment jego powstania nie zawsze jest tożsamy z momentem złożenia zamówienia albo otrzymania zapłaty, ponieważ może zależeć między innymi od dnia wydania towaru, wykonania usługi lub wystawienia faktury. Drugą kategorią jest wypłata środków przez marketplace, która może nastąpić kilka lub kilkanaście dni później i obejmować wiele zamówień z różnych okresów. Trzecią są prowizje, opłaty za obsługę płatności, reklamę, logistykę, magazynowanie albo inne usługi platformy. Czwartą tworzą dokumenty stanowiące podstawę zapisów w księdze, takie jak faktury sprzedaży, raporty z kasy fiskalnej, ewidencja sprzedaży bezrachunkowej oraz prawidłowe dokumenty kosztowe. Pomieszanie tych kategorii prowadzi do błędów, ponieważ żadna z nich nie może automatycznie zastępować pozostałych.

Kwota wpływająca na rachunek bankowy jest często wynikiem potrącenia prowizji, opłat, zwrotów, kosztów logistycznych i innych obciążeń. Z tego powodu nie powinna być automatycznie utożsamiana z wartością przychodu. Wyciąg bankowy potwierdza przepływ pieniędzy, ale nie wyjaśnia jeszcze, z jakich transakcji powstała dana kwota, kiedy należało rozpoznać przychód ani na podstawie jakich dokumentów powinien zostać dokonany zapis w KPiR. Przedsiębiorca może sprzedać towary o wartości znacznie wyższej niż kwota faktycznie przekazana przez platformę, ponieważ część środków została zatrzymana na pokrycie opłat albo zwrócona klientom. Może również otrzymać jedną zbiorczą wypłatę obejmującą sprzedaż z kilku dni lub tygodni. Księgowanie wyłącznie wartości przelewu prowadziłoby więc do pominięcia części przychodów, błędnego rozliczenia kosztów lub przypisania transakcji do niewłaściwego okresu.

Dla rozwijającej się firmy e-commerce kluczowe jest stworzenie procesu, który pozwala przejść od pojedynczego zamówienia do zapisu w księdze bez utraty informacji po drodze. Każdy kanał powinien dostarczać dane według ustalonego standardu, każda transakcja musi zostać przypisana do właściwego sposobu dokumentowania, a wypłaty i opłaty platform należy rozliczać oddzielnie od wartości sprzedaży. Potrzebny jest również sposób identyfikowania zwrotów, anulacji i faktur, które nie mogą zostać ponownie ujęte w zestawieniu zbiorczym. Spójna ewidencja powstaje wtedy, gdy raporty handlowe można porównać z dokumentami sprzedaży, dokumenty z zapisami KPiR, a zapisy księgowe z wartościami wykazywanymi w JPK_PKPIR. Im wcześniej firma wprowadzi taki standard, tym łatwiej będzie dołączać kolejne marketplace’y bez tworzenia osobnych, niepołączonych obiegów danych.

Czym jest JPK_KPiR i co zmienia dla sprzedawców internetowych?

Wprowadzenie obowiązkowego raportowania KPiR w ustrukturyzowanej formie jest kolejnym etapem cyfryzacji rozliczeń podatkowych. Dla przedsiębiorcy oznacza to nie tylko zmianę formatu przekazywania informacji, lecz także wzrost znaczenia jakości danych znajdujących się w księdze. W tradycyjnym modelu część nieścisłości mogła pozostawać ukryta w zestawieniach pomocniczych, opisach dokumentów albo ręcznie przygotowanych podsumowaniach. Ustrukturyzowany plik wymaga natomiast, aby dane zostały zapisane w określonych polach i tworzyły logiczną całość. W przypadku sprzedaży wielokanałowej szczególnie istotna staje się możliwość wskazania, skąd pochodzi dana wartość, jak została obliczona oraz czy nie obejmuje transakcji ujętych już na podstawie innych dokumentów. Sam obowiązek nie zmienia zasad powstawania przychodów ani dokumentowania kosztów, ale sprawia, że zaniedbania w integracji danych mogą być łatwiejsze do wykrycia.

JPK_PKPIR jako elektroniczne odzwierciedlenie księgi

Oficjalna nazwa struktury to JPK_PKPIR. Jest to ustrukturyzowany plik elektroniczny przedstawiający dane z podatkowej księgi przychodów i rozchodów. Struktura jest przygotowana w formacie XML, co oznacza, że informacje muszą zostać zapisane zgodnie z określonym schematem technicznym. Plik obejmuje między innymi dane identyfikacyjne podatnika, informacje dotyczące okresu, zapisy odpowiadające pozycjom znajdującym się w księdze oraz wartości kontrolne, takie jak liczba zapisów i suma przychodów. Nie jest to swobodnie przygotowane zestawienie ani zwykły eksport do arkusza kalkulacyjnego. Poszczególne informacje mają określone miejsce, format i znaczenie, dzięki czemu mogą być przetwarzane w sposób automatyczny. Obowiązek raportowania dotyczy określonych grup podatników zgodnie z harmonogramem wdrażania JPK w podatkach dochodowych, dlatego samo opublikowanie struktury obowiązującej od 1 stycznia 2026 roku nie oznacza, że każdy przedsiębiorca prowadzący KPiR od tego dnia przesyła plik na takich samych zasadach.

JPK_PKPIR nie zastępuje podatkowej księgi przychodów i rozchodów. Jest elektronicznym odzwierciedleniem danych, które wcześniej zostały w niej ujęte. Jeżeli księga zawiera poprawne, kompletne i właściwie udokumentowane zapisy, przygotowanie pliku powinno być końcowym etapem procesu księgowego. Jeżeli jednak KPiR została zasilona niepełnymi raportami, zawiera powielone transakcje albo opiera się na wartościach po potrąceniu prowizji, te same nieprawidłowości mogą zostać przeniesione do JPK_PKPIR. Plik nie rozstrzygnie samodzielnie, czy wypłata z platformy została błędnie potraktowana jako przychód, czy faktura znalazła się również w zestawieniu zbiorczym ani czy zwrot został przypisany do właściwego okresu. Pokazuje rezultat wcześniejszego procesu księgowego, a nie naprawia jego słabych punktów.

Z tego powodu przygotowania do raportowania nie powinny ograniczać się do sprawdzenia, czy używany system księgowy umożliwia eksport danych do formatu XML. Znacznie ważniejsze jest ustalenie, w jaki sposób informacje ze wszystkich platform trafiają do ewidencji, kto kontroluje ich kompletność oraz na podstawie jakich dokumentów powstają poszczególne zapisy. W średniej firmie e-commerce oznacza to potrzebę współpracy między osobami odpowiedzialnymi za sprzedaż, finanse, księgowość i systemy informatyczne. Księgowość nie powinna otrzymywać wyłącznie końcowej kwoty wypłaty, a dział operacyjny nie powinien zakładać, że każdy raport dostępny na platformie nadaje się bezpośrednio do zaksięgowania. Potrzebny jest wspólny model danych, który pozwala przejść od zamówienia, przez dokument źródłowy i ewidencję pomocniczą, aż do właściwego zapisu w KPiR.

Wygenerowanie JPK_PKPIR należy traktować jako końcowy etap zamknięcia i weryfikacji księgi. Wcześniej trzeba zebrać dokumenty sprzedażowe i kosztowe, rozliczyć anulacje, przypisać zwroty do właściwych transakcji, wykluczyć duplikaty oraz uzgodnić zestawienia pomocnicze z zapisami księgowymi. Dopiero poprawnie prowadzona KPiR może zostać wiarygodnie przedstawiona w formacie wymaganym przez administrację skarbową. Dla firmy prowadzącej sprzedaż na kilku rynkach oznacza to konieczność stałego kontrolowania nie tylko wartości przychodów, ale również źródeł danych, sposobu ich agregowania i powiązania z dokumentami. Im większa skala działalności, tym trudniej odtworzyć taki proces dopiero po zakończeniu roku.

Kogo dotyczy obowiązek?

JPK_PKPIR jest związany z prowadzeniem podatkowej księgi przychodów i rozchodów. W praktyce dotyczy przedsiębiorców opodatkowanych według skali podatkowej lub podatkiem liniowym, jeżeli zgodnie z przepisami prowadzą KPiR i należą do grup objętych obowiązkiem według harmonogramu wdrażania. Z punktu widzenia rozwijającego się e-commerce sama liczba sklepów, marketplace’ów, magazynów, rachunków bankowych czy obsługiwanych krajów nie przesądza o liczbie ksiąg. Jeżeli działalność jest prowadzona przez jednego podatnika w ramach jednej firmy rozliczanej na podstawie KPiR, wszystkie jej przychody i koszty powinny zostać ujęte w tej samej księdze. Nie zmienia tego fakt, że część sprzedaży odbywa się w Polsce, część za granicą, a poszczególne platformy stosują różne modele rozliczeń.

Obowiązek jest wdrażany etapami. Od 1 stycznia 2026 roku nowe zasady dotyczą przedsiębiorców zobowiązanych do przekazywania miesięcznych plików JPK_V7M. Muszą oni prowadzić księgę przy użyciu programu komputerowego, a pierwszy JPK_PKPIR obejmujący rok podatkowy 2026 przekażą w 2027 roku. Pozostali podatnicy PIT prowadzący odpowiednie księgi, w tym przedsiębiorcy rozliczający VAT kwartalnie i przekazujący JPK_V7K, zostają objęci nowymi zasadami od 1 stycznia 2027 roku. Ich pierwszy plik będzie dotyczył roku podatkowego 2027 i zostanie przekazany w 2028 roku. Harmonogram ma więc znaczenie praktyczne, ponieważ nie każdy przedsiębiorca prowadzący KPiR rozpoczyna raportowanie w tym samym terminie.

Dla średniej firmy e-commerce późniejszy termin wejścia w obowiązek nie powinien być jednak powodem do odkładania przygotowań. Uporządkowanie danych z kilku marketplace’ów zwykle wymaga zmiany procesów, a nie jednorazowego ustawienia funkcji w programie księgowym. Trzeba ustalić, które raporty będą podstawą kontroli, jak oddzielać sprzedaż fakturową od pozostałej, gdzie przechowywać dokumenty kosztowe, kto monitoruje zwroty oraz w jaki sposób wyjaśniać różnice między wartością zamówień a wypłatami. Im więcej rynków, walut i modeli logistycznych obsługuje firma, tym trudniej naprawić cały proces bezpośrednio przed pierwszym terminem raportowania. Problemy narastają szczególnie wtedy, gdy każdy kanał jest obsługiwany według innych zasad, a wiedza o rozliczeniach pozostaje rozproszona między kilka osób lub arkuszy.

Przygotowanie do JPK_PKPIR może być okazją do stworzenia systemu finansowego, który będzie skalowalny również po wejściu na nowe marketplace’y. Dobrze zaprojektowana ewidencja nie służy wyłącznie spełnieniu obowiązku podatkowego. Pozwala szybciej zamykać miesiące, ograniczyć liczbę ręcznych korekt, lepiej kontrolować zwroty i opłaty oraz analizować rzeczywistą rentowność poszczególnych kanałów. Firma planująca ekspansję powinna więc traktować spójność danych jako część infrastruktury potrzebnej do wzrostu. Dodanie kolejnej platformy nie powinno oznaczać stworzenia nowego, odizolowanego procesu, lecz włączenie następnego źródła danych do wcześniej ustalonego modelu ewidencji.

Jak często wysyła się JPK_PKPIR?

JPK_PKPIR nie jest plikiem miesięcznym i nie należy utożsamiać go z raportowaniem JPK_VAT. Pliki związane z VAT są przekazywane cyklicznie zgodnie z właściwym trybem rozliczania podatnika, natomiast JPK_PKPIR obejmuje dane z podatkowej księgi przychodów i rozchodów za rok podatkowy. Podatnik przekazuje go po zakończeniu tego roku, w terminie odpowiadającym terminowi złożenia właściwego zeznania rocznego PIT. Pierwsza grupa przedsiębiorców, objęta nowymi zasadami od 1 stycznia 2026 roku, nie przesyła więc JPK_PKPIR co miesiąc w trakcie 2026 roku. Pierwszy plik przygotuje za cały rok podatkowy 2026 i przekaże w 2027 roku. Analogicznie podatnicy wchodzący do systemu od 2027 roku przekażą pierwszy roczny plik obejmujący ten rok w 2028 roku.

Roczna częstotliwość raportowania nie oznacza jednak, że ewidencję można uporządkować dopiero po zakończeniu roku. W sprzedaży wielokanałowej dwanaście miesięcy może oznaczać dziesiątki tysięcy zamówień, wiele cykli wypłat, tysiące zwrotów oraz setki dokumentów prowizyjnych. Jeżeli firma nie uzgadnia danych na bieżąco, przy przygotowaniu rocznego pliku może odkryć, że część raportów nie jest już dostępna, zmienił się sposób oznaczania transakcji albo nie da się łatwo ustalić, dlaczego dana wypłata różni się od wartości sprzedaży. Trudności pojawiają się również wtedy, gdy zwroty dotyczą wcześniejszych miesięcy, faktury zostały wystawione w innym systemie niż zamówienia, a opłaty platform zostały potrącone w kilku osobnych rozliczeniach.

JPK_PKPIR jest przekazywany raz w roku, ale dane tworzące ten plik powstają każdego dnia. Dlatego należy rozdzielić dwa procesy: formalne przesłanie pliku oraz regularne prowadzenie i kontrolowanie księgi. Pierwszy odbywa się po zakończeniu roku podatkowego, drugi musi działać przez cały rok. Bezpieczny model zakłada bieżące dokumentowanie transakcji, regularną kontrolę kompletności danych oraz uzgadnianie wszystkich kanałów po zakończeniu każdego miesiąca. Dzięki temu przygotowanie rocznego JPK_PKPIR nie polega na odtwarzaniu historii sprzedaży, lecz na wygenerowaniu pliku z wcześniej sprawdzonej i zamkniętej księgi.

Dla firmy planującej ekspansję ma to również wymiar organizacyjny. Nowy marketplace powinien zostać włączony do procesu księgowego jeszcze przed rozpoczęciem sprzedaży, a nie dopiero wtedy, gdy pojawią się pierwsze różnice w raportach. Z wyprzedzeniem należy ustalić dostępne dokumenty, format danych, zasady rozliczania prowizji, częstotliwość wypłat i sposób obsługi korekt. Trzeba też określić, które informacje będą trafiały do ewidencji pomocniczej, w jaki sposób sprzedaż zostanie powiązana z fakturami oraz kto będzie odpowiadał za wyjaśnianie rozbieżności. Dzięki temu zwiększenie liczby kanałów nie prowadzi do powstania kolejnych niepołączonych arkuszy, lecz rozszerza jeden spójny system ewidencji.

Czy ten temat dotyczy właśnie Ciebie?

Sprzedaż przez kilka kanałów nie zawsze od razu oznacza skomplikowaną księgowość. Jeżeli liczba transakcji jest niewielka, wszystkie dokumenty powstają w jednym systemie, a raporty mają podobną strukturę, kontrolowanie danych może pozostawać stosunkowo proste. Sytuacja zmienia się jednak wraz ze wzrostem firmy. Kolejny marketplace, nowy kraj sprzedaży, własny sklep internetowy albo rozwój kanału B2B zwiększają nie tylko liczbę zamówień, lecz także liczbę źródeł, z których trzeba pobierać informacje potrzebne do prawidłowego prowadzenia KPiR. Każda platforma może stosować inny sposób prezentowania sprzedaży, prowizji, kosztów dostawy, zwrotów i wypłat. Nie każdy raport udostępniany przez platformę stanowi jednak dokument księgowy będący podstawą zapisu w KPiR. Część raportów pełni wyłącznie funkcję rozliczeniową, operacyjną albo kontrolną i wymaga zestawienia z właściwymi dokumentami źródłowymi.

Dane mogą trafiać do firmy w różnych terminach, walutach i formatach, a część dokumentów jest wystawiana przez przedsiębiorcę, część przez jego system sprzedażowy, a część powstaje za pośrednictwem platformy w ramach samofakturowania, czyli self-billingu, lub innych rozwiązań przewidzianych przez daną platformę. Dopóki liczba transakcji pozostaje niewielka, takie rozproszenie można jeszcze kontrolować ręcznie. W średniej firmie e-commerce, która obsługuje tysiące zamówień i przygotowuje się do wejścia na kolejne rynki, ręczne porównywanie plików szybko przestaje być wystarczające. Z czasem prowadzi do zależności od wiedzy pojedynczych pracowników, opóźnień w zamknięciu miesiąca oraz różnic, których po kilku tygodniach trudno już logicznie wyjaśnić.

Ten temat dotyczy przede wszystkim przedsiębiorców, którzy przestali traktować marketplace jako dodatkowy kanał, a zaczęli budować na sprzedaży wielokanałowej znaczną część swojego biznesu. Jeżeli sprzedajesz przez co najmniej dwie platformy, łączysz je z własnym sklepem albo prowadzisz jednocześnie sprzedaż B2C i B2B, dane prawdopodobnie powstają już w kilku niezależnych miejscach. Szczególnej uwagi wymaga sytuacja, w której platformy przekazują zbiorcze wypłaty pomniejszone o prowizje, koszty usług, zwroty lub inne potrącenia. Wówczas kwota przelewu nie pokazuje pełnej wartości sprzedaży ani wszystkich zdarzeń, które trzeba prawidłowo ująć w księdze. Jeżeli sposób przekazywania danych do księgowości nie zmienia się od czasu, gdy firma realizowała kilkadziesiąt zamówień miesięcznie, ryzyko pominięcia transakcji, ujęcia jej w niewłaściwym okresie albo zaksięgowania po raz drugi zwiększa się wraz z każdym nowym kanałem.

Kiedy sprzedaż wielokanałowa wymaga szczególnej kontroli?

Spójna ewidencja staje się szczególnie ważna, gdy część faktur wystawiasz samodzielnie, a część powstaje za pośrednictwem platform lub innych systemów obsługujących zamówienia, w tym w ramach samofakturowania albo rozwiązań przewidzianych przez operatora danego kanału. W takim modelu trzeba wiedzieć nie tylko, jaka była łączna wartość sprzedaży, lecz także które transakcje zostały już udokumentowane indywidualną fakturą i nie powinny ponownie znaleźć się w zbiorczym zapisie. Podobny problem może wystąpić przy sprzedaży B2C, gdy część zamówień może być ujmowana w ewidencji sprzedaży bezrachunkowej, jeżeli taki sposób dokumentowania jest dopuszczalny, część podlega ewidencji na kasie fiskalnej, a do wybranych transakcji wystawiane są faktury. Sposób dokumentowania zależy między innymi od rodzaju sprzedaży, statusu nabywcy, obowiązków związanych z kasą fiskalną oraz pozostałych wymogów podatkowych.

Bez jednoznacznych reguł łatwo włączyć tę samą sprzedaż do kilku zestawień albo, obawiając się duplikatu, pominąć ją całkowicie. W średniej firmie e-commerce ręczna kontrola pojedynczych zamówień może być jeszcze możliwa przy ograniczonej skali, ale staje się kosztowna i zawodna, gdy proces obejmuje wiele tysięcy transakcji miesięcznie. Szczególnie ryzykowne są sytuacje, w których raport zbiorczy zawiera zarówno sprzedaż bez indywidualnych dokumentów, jak i transakcje ujęte wcześniej na podstawie faktur. Jeżeli system nie pozwala ich wyraźnie rozdzielić, księgowość może zaksięgować tę samą sprzedaż dwukrotnie.

Temat jest równie istotny, jeżeli zwroty, anulacje i korekty są obsługiwane w kilku systemach. Zamówienie może zostać anulowane na platformie, ale nadal pozostać w pliku pobranym wcześniej do księgowania. Zwrot może zostać zatwierdzony w jednym miesiącu, a potrącony z wypłaty w kolejnym. Faktura korygująca może powstać w systemie sprzedażowym, podczas gdy informacja o zwrocie znajduje się w raporcie marketplace’u pod innym numerem lub identyfikatorem. Jeżeli księgowość otrzymuje kilka plików CSV, raport PDF i dodatkowe zestawienie przygotowane ręcznie, musi być jasne, który dokument stanowi podstawę zapisu, a który pełni wyłącznie funkcję kontrolną. Brak takiego rozróżnienia sprawia, że zespół finansowy poświęca czas na odtwarzanie przebiegu transakcji zamiast na sprawdzenie, czy księga rzeczywiście obejmuje wszystkie przychody i koszty.

Krótki test diagnostyczny

Najprostszym sposobem oceny procesu jest próba przejścia od wartości widocznej w KPiR do danych źródłowych. Sprawdź, czy sumę sprzedaży z każdego kanału można bez większego problemu porównać z zapisami w księdze oraz czy dla każdego wpisu da się wskazać fakturę, raport z kasy, dopuszczalną w danej sytuacji ewidencję sprzedaży bezrachunkowej albo inny właściwy dokument. Zastanów się także, czy przychód jest oddzielony od prowizji i pozostałych opłat pobieranych przez platformę. Jeżeli księgowość otrzymuje przede wszystkim informacje o wypłatach, ale nie ma pełnego obrazu sprzedaży przed potrąceniami, proces nie zapewnia jeszcze wystarczającej kontroli. Wpływ na rachunek może pomóc w uzgodnieniu rozliczeń, jednak nie powinien zastępować dokumentów pokazujących wartość i moment sprzedaży.

Kolejne pytanie dotyczy zakresu raportów używanych do księgowania. Czy wiadomo, które z nich obejmują sprzedaż udokumentowaną fakturami, a które pokazują wyłącznie transakcje przeznaczone do ujęcia zbiorczego? Czy można potwierdzić, że raport nie obejmuje sprzedaży wcześniej ujętej na podstawie indywidualnych dokumentów? Czy zwroty i anulacje są widoczne zarówno w systemie sprzedaży, jak i w danych przekazanych do księgowości? Czy po kilku miesiącach można ustalić, z czego wynika różnica między sprzedażą brutto a kwotą wypłaconą przez platformę? Warto również sprawdzić, czy firma potrafi odtworzyć sposób obliczenia każdej większej kwoty zbiorczej bez angażowania osoby, która ręcznie przygotowała zestawienie.

Jeżeli na co najmniej jedno z tych pytań odpowiedź brzmi „nie” albo „zależy, kto to sprawdza”, proces wymaga uporządkowania przed przygotowaniem danych do JPK_PKPIR. Brak pełnej odpowiedzi nie musi automatycznie oznaczać, że KPiR została poprowadzona nieprawidłowo. Może jednak wskazywać, że poprawność ewidencji zależy od ręcznej pracy, wiedzy pojedynczej osoby albo dodatkowych wyjaśnień przesyłanych poza głównym obiegiem dokumentów. Taki model jest szczególnie ryzykowny podczas ekspansji, ponieważ kolejne platformy, kraje i waluty zwiększają liczbę wyjątków oraz utrudniają utrzymanie jednolitych zasad.

Proces przygotowany do wzrostu powinien umożliwiać regularne uzgodnienie danych bez każdorazowego odtwarzania logiki raportów. Każdy nowy kanał powinien zostać włączony do istniejącego standardu dokumentowania, kontroli i archiwizacji, z uwzględnieniem różnic wynikających z przepisów podatkowych właściwych dla danego modelu sprzedaży. Dzięki temu rozwój firmy nie prowadzi do mnożenia osobnych arkuszy, wyjątków i ręcznych instrukcji, lecz rozszerza jeden kontrolowany obieg danych.

Jedna działalność, wiele marketplace’ów, jedna KPiR

Sprzedaż wielokanałowa sprawia, że firma działa jednocześnie w kilku środowiskach handlowych, ale nie zmienia podstawowej konstrukcji jej rozliczeń. Poszczególne platformy mogą mieć odmienne regulaminy, systemy płatności i modele naliczania opłat, jednak z perspektywy KPiR są źródłami zdarzeń gospodarczych występujących w ramach działalności tego samego podatnika. Jeżeli sprzedaż jest prowadzona w jednej działalności gospodarczej rozliczanej na podstawie KPiR, przychody i koszty ze wszystkich kanałów powinny zostać ujęte we wspólnej księdze zgodnie z zasadami wynikającymi z przepisów podatkowych oraz na podstawie właściwych dokumentów. Nie oznacza to, że dane z każdego marketplace’u należy od razu łączyć w jeden nieczytelny raport. Przeciwnie, przy większej skali potrzebne są szczegółowe ewidencje pomocnicze, które pozwalają kontrolować osobno każdy kanał, a jednocześnie zachować spójność całego rozliczenia.

Najważniejsze jest rozróżnienie między rozdzieleniem danych na potrzeby operacyjne a rozdzieleniem działalności na potrzeby podatkowe. Firma może analizować sprzedaż według platform, krajów, walut, magazynów, marek lub kategorii produktów. Może również prowadzić osobne zestawienia dla sprzedaży B2B, B2C, zwrotów, korekt i kosztów platform. Takie podziały pomagają zarządzać biznesem oraz przygotowywać prawidłowe zapisy księgowe. Nie oznaczają jednak, że każdy marketplace otrzymuje własną KPiR. Zadaniem ewidencji pomocniczych jest uporządkowanie danych przed ich ujęciem we wspólnej księdze oraz stworzenie ścieżki pozwalającej wyjaśnić, z jakich transakcji i dokumentów powstała konkretna wartość.

Dlaczego marketplace’y nie tworzą osobnych rozliczeń podatkowych?

Organy podatkowe nie traktują poszczególnych marketplace’ów ani kanałów sprzedaży jako odrębnych działalności gospodarczych wymagających prowadzenia osobnych KPiR. Platforma jest miejscem, za pośrednictwem którego przedsiębiorca zawiera transakcje, przyjmuje zamówienia lub korzysta z dodatkowych usług. Sama zmiana kanału nie powoduje, że powstaje nowy podatnik albo oddzielna firma. Jeżeli ten sam przedsiębiorca sprzedaje towary przez kilka marketplace’ów i własny sklep, wszystkie zdarzenia gospodarcze dotyczą prowadzonej przez niego działalności. Wspólna KPiR powinna więc obejmować przychody i koszty ze wszystkich źródeł zgodnie z zasadami podatkowymi oraz na podstawie dokumentów właściwych dla danego rodzaju transakcji.

Jedna księga nie oznacza jednak braku szczegółowości. Przedsiębiorca powinien być w stanie ustalić, z którego kanału pochodzi sprzedaż, na jakim rynku została zrealizowana, w jakiej walucie została wykazana i na podstawie jakiego dokumentu została ujęta. Przydatne są w tym celu osobne zestawienia pomocnicze, oznaczenia źródeł oraz jednolity sposób opisywania dokumentów. Można na przykład przechowywać raporty w folderach przypisanych do określonych platform i okresów, a w ewidencji pomocniczej stosować identyfikatory pozwalające połączyć zapis z zamówieniem, dokumentem sprzedaży i raportem źródłowym. Taki podział zwiększa przejrzystość, ale jego wynik musi zostać prawidłowo przeniesiony do wspólnej KPiR. Osobne zestawienie nie staje się alternatywną księgą i nie powinno funkcjonować bez możliwości porównania z księgowością całej firmy.

Rozdzielanie danych według kanałów ma również znaczenie zarządcze. Firma może dzięki temu ocenić rentowność platform, udział zwrotów, wysokość prowizji i koszty obsługi każdego rynku. Analiza biznesowa oraz rozliczenie podatkowe korzystają często z tych samych danych, ale przedstawiają je z innej perspektywy. Raport zarządczy może pokazywać marżę marketplace’u po potrąceniu opłat, jednak raport zarządczy nie jest dokumentem księgowym i sam w sobie nie stanowi podstawy zapisu w KPiR. W ewidencji podatkowej sprzedaż oraz koszt usług platformy powinny zostać rozpoznane zgodnie z przepisami i na podstawie właściwych dokumentów. Bezpośrednie przeniesienie wyniku raportu rentowności do KPiR mogłoby prowadzić do zaksięgowania wartości po potrąceniach zamiast prawidłowego ujęcia przychodu i kosztów.

Jak działa zasada „wiele źródeł, jedna ewidencja”?

Każdy kanał powinien dostarczać dane według jednolitego standardu wewnętrznego, z uwzględnieniem różnic wynikających z przepisów podatkowych. Sprzedaż krajowa, sprzedaż w procedurze OSS, sprzedaż lokalna po zagranicznej rejestracji VAT, transakcje B2B oraz eksport mogą podlegać odmiennym zasadom dokumentowania i opodatkowania. Nie oznacza to jednak, że dla każdego modelu firma powinna tworzyć całkowicie odrębny proces. Wewnętrzny standard powinien określać, jakie dane muszą zostać zebrane, w jaki sposób należy je zweryfikować i jak powiązać je z właściwym dokumentem, natomiast reguły podatkowe decydują o sposobie ujęcia konkretnej transakcji.

Marketplace A może udostępniać szczegółowy raport zamówień, marketplace B oddzielny raport sprzedaży i zwrotów, a marketplace C kilka zestawień dotyczących transakcji, prowizji i wypłat. Własny sklep może natomiast przekazywać dane bezpośrednio z systemu sprzedażowego. Informacje te nie powinny trafiać do KPiR w niezmienionej postaci tylko dlatego, że zostały wygenerowane przez platformę. Najpierw trzeba ustalić, co przedstawia dany raport, czy może stanowić podstawę zapisu, czy obejmuje transakcje fakturowane, jak pokazuje anulacje i zwroty, czy kwoty są prezentowane przed potrąceniami oraz czy nie obejmuje sprzedaży już wcześniej ujętej na podstawie indywidualnych dokumentów. Dopiero po przeprowadzeniu takiej kontroli dane mogą zostać wykorzystane do przygotowania prawidłowego zapisu.

Uproszczony przebieg procesu można przedstawić następująco: marketplace A, marketplace B, marketplace C i własny sklep przekazują dane do ewidencji pomocniczych, informacje z tych ewidencji są weryfikowane i ujmowane w KPiR, a prawidłowo prowadzona księga znajduje następnie odzwierciedlenie w JPK_PKPIR. Każdy etap pełni inną funkcję. Raport platformy pokazuje dane handlowe lub rozliczeniowe, ewidencja pomocnicza pozwala je uporządkować i sprawdzić, KPiR stanowi właściwą księgę podatkową, a JPK_PKPIR przekazuje dane z tej księgi w ustrukturyzowanej formie. Pominięcie któregoś z etapów może sprawić, że wartości zostaną zaksięgowane bez wystarczającej kontroli albo po zakończeniu okresu nie będzie można wyjaśnić sposobu ich obliczenia.

Wiele źródeł danych nie musi oznaczać wielu odmiennych procesów. Firma może ustalić minimalny zestaw informacji wymaganych dla każdego kanału. Powinien on obejmować między innymi datę transakcji, numer zamówienia, identyfikator dokumentu księgowego, wartość sprzedaży, walutę, kraj opodatkowania, sposób udokumentowania, status realizacji oraz informacje o zwrocie, anulacji lub korekcie. Przy sprzedaży zagranicznej szczególnie ważne jest prawidłowe oznaczenie rynku, waluty i modelu opodatkowania, ponieważ transakcje realizowane przez tę samą platformę mogą podlegać różnym zasadom. Następnie firma powinna określić, jakie raporty potwierdzają prowizje i inne koszty oraz w jaki sposób będą one uzgadniane z wypłatami.

Marketplace, który nie udostępnia danych dokładnie w oczekiwanym układzie, wymaga odpowiedniego przekształcenia raportu, ale nie powinien wymuszać całkowicie odmiennej logiki kontroli. Dzięki temu dodanie kolejnej platformy polega na dopasowaniu jej danych do istniejącego modelu wewnętrznego, przy jednoczesnym uwzględnieniu właściwych zasad podatkowych. Firma zyskuje w ten sposób proces, który można skalować bez utraty przejrzystości i bez mnożenia ręcznych wyjątków.

Co powinno się zgadzać?

Spójność ewidencji nie oznacza, że każda kwota widoczna w systemach będzie identyczna. Raport sprzedaży, dokumenty źródłowe, ewidencje pomocnicze, KPiR i przelew na rachunek bankowy przedstawiają różne etapy tego samego procesu. Zgadzać powinny się przede wszystkim wartości, które odnoszą się do tego samego zakresu transakcji, okresu, rynku i sposobu dokumentowania. Suma sprzedaży wynikająca z faktur, raportów z kasy oraz ewidencji sprzedaży bezrachunkowej stosowanej w przypadkach, w których jest ona dopuszczalna, powinna odpowiadać przychodom ujętym w KPiR po uwzględnieniu prawidłowo rozliczonych korekt. Zestawienia pomocnicze dla poszczególnych kanałów powinny natomiast wyjaśniać, jak z danych o zamówieniach i dokumentach powstały kwoty przeniesione do księgi.

Na końcu dane z prawidłowo prowadzonej KPiR powinny znaleźć odzwierciedlenie w JPK_PKPIR. Nie oznacza to, że plik powinien być porównywany bezpośrednio z każdym raportem platformy. JPK_PKPIR odzwierciedla księgę, a nie surowe dane operacyjne z marketplace’u. Jeżeli raport sprzedażowy zawiera anulowane zamówienia, wartości w kilku walutach, transakcje z różnych krajów albo sprzedaż wcześniej udokumentowaną fakturami, przed porównaniem z KPiR trzeba odpowiednio wyjaśnić i przekształcić jego zakres.

Kontroli wymagają także wypłaty z platform, ale należy porównywać je z ewidencją w odpowiedni sposób. Kwota wypłaty z marketplace’u nie musi być równa wartości przychodu, ponieważ platforma może potrącić prowizje, opłaty, zwroty, koszty dostawy, rezerwy lub inne należności. Wypłata może również obejmować zamówienia z kilku okresów albo nie zawierać części środków, które zostaną przekazane później. Z tego powodu uzgodnienie rachunku bankowego nie powinno polegać na prostym porównaniu przelewu z przychodem w KPiR. Potrzebne jest rozliczenie pokazujące wartość sprzedaży, wszystkie potrącenia, zatrzymane środki oraz kwotę ostatecznie przekazaną przedsiębiorcy.

Jeżeli sprzedaż wyniosła 500 000 zł, a platforma wypłaciła 440 000 zł, różnica nie powinna pozostać niewyjaśniona i nie może zostać automatycznie zakwalifikowana jako koszt uzyskania przychodu. Może obejmować prowizje, opłaty logistyczne, zwroty, środki zatrzymane do kolejnego okresu oraz inne rozliczenia, z których każde wymaga osobnej analizy i właściwego dokumentu. Spójna ewidencja pozwala przejść od 500 000 zł sprzedaży do 440 000 zł wypłaty, wskazując po drodze wszystkie elementy tworzące różnicę. Jednocześnie umożliwia potwierdzenie, że przychód został ujęty tylko raz, koszty posiadają odpowiednie podstawy, a zwroty i korekty zostały przypisane do właściwych transakcji i okresów.

Pełne uzgodnienie powinno więc obejmować dokumenty sprzedaży, ewidencje pomocnicze, zapisy w KPiR, dane przygotowywane do JPK_PKPIR oraz przepływy pieniężne. Nie chodzi o mechaniczne zrównanie wszystkich raportów, lecz o możliwość logicznego wyjaśnienia różnic między nimi. Firma powinna wiedzieć, dlaczego wartość sprzedaży odbiega od wartości wypłat, dlaczego zwrot pojawił się w innym okresie niż pierwotna transakcja, które dokumenty potwierdzają naliczone koszty oraz czy sprzedaż została opodatkowana w prawidłowym kraju i walucie. Taki poziom kontroli pozwala nie tylko przygotować spójną ewidencję, ale również szybciej wykrywać brakujące dokumenty, błędy integracji i nieprawidłowe potrącenia dokonywane przez platformy.

Wypłata z marketplace’u to nie przychód do zaksięgowania

Jednym z najczęstszych błędów w księgowości e-commerce jest utożsamianie kwoty przekazanej przez marketplace z przychodem ze sprzedaży. Na rachunek bankowy przedsiębiorcy trafia zazwyczaj wartość rozliczeniowa, która powstała po połączeniu wielu zamówień, zwrotów, prowizji i innych operacji. Taki przelew pomaga sprawdzić, czy platforma rozliczyła się ze sprzedawcą, ale nie pokazuje samodzielnie pełnej wartości sprzedaży ani momentu, w którym przychód powinien zostać rozpoznany. W KPiR nie księguje się po prostu tego, co wpłynęło na konto, lecz przychody i koszty wynikające z właściwych zdarzeń gospodarczych oraz dokumentów. Wypłata jest więc przede wszystkim elementem uzgodnienia rozrachunków z platformą, a nie automatyczną podstawą wpisania przychodu.

Rozróżnienie to ma szczególne znaczenie w firmach, które korzystają z kilku marketplace’ów i otrzymują wypłaty według różnych harmonogramów. Jedna platforma może przekazywać środki codziennie, druga raz w tygodniu, a trzecia dopiero po upływie okresu przeznaczonego na obsługę zwrotów. Część pieniędzy może być czasowo zatrzymywana jako rezerwa, a niektóre koszty mogą zostać potrącone jeszcze przed dokonaniem przelewu. Gdyby każdą wypłatę potraktować jako przychód, moment i wysokość zapisów w KPiR zależałyby od technicznych zasad działania platformy, a nie od przepisów podatkowych i rzeczywistego przebiegu sprzedaży. Proces powinien więc zaczynać się od dokumentów i danych dotyczących transakcji, natomiast przepływy bankowe należy wykorzystywać do późniejszego potwierdzenia, że wszystkie elementy rozliczenia zostały prawidłowo wyjaśnione.

Dlaczego payout nie jest dokumentem sprzedaży?

Payout, czyli zbiorcza wypłata z marketplace’u, może obejmować dziesiątki albo tysiące zamówień zrealizowanych w różnych dniach. Często zawiera sprzedaż z końca poprzedniego miesiąca, transakcje z miesiąca bieżącego, korekty wcześniejszych rozliczeń oraz środki zwolnione z rezerwy. Jednocześnie platforma może pomniejszyć wypłatę o prowizje, opłaty za obsługę płatności, usługi reklamowe, logistykę, magazynowanie, koszty dostawy, zwroty dla klientów oraz inne należności. Kwota widoczna na rachunku jest zatem wynikiem rozliczenia wielu pozycji, a nie wartością jednej transakcji sprzedaży. Payout sam w sobie co do zasady nie stanowi dokumentu będącego podstawą ujęcia przychodu w KPiR. Określone zestawienie może w nietypowej sytuacji spełniać wymagania właściwego dowodu księgowego, ale zależy to od jego treści, zakresu danych i zgodności z wymaganiami przewidzianymi dla danego rodzaju zapisu. Sam fakt, że raport został wygenerowany przez platformę, nie przesądza jeszcze o jego statusie.

Data przelewu również nie musi odpowiadać dacie powstania przychodu. Towar może zostać wydany klientowi 28 stycznia, platforma może zamknąć okres rozliczeniowy 31 stycznia, a środki przekazać dopiero 4 lutego. Przesunięcie wynika wówczas z harmonogramu operatora, a nie z tego, że sprzedaż nastąpiła w lutym. Wyciąg bankowy potwierdza, że określona kwota została otrzymana, lecz nie zastępuje faktury, raportu fiskalnego, dowodu wewnętrznego ani dopuszczalnego zestawienia sprzedaży. Nie pokazuje również, czy część wpływu dotyczyła transakcji ujętych wcześniej na podstawie indywidualnych faktur. Nadal pozostaje jednak ważnym elementem kontroli, ponieważ pozwala sprawdzić, czy wartość sprzedaży, prowizji, zwrotów, rezerw i pozostałych potrąceń prowadzi do kwoty rzeczywiście przekazanej przedsiębiorcy. Jeżeli między raportem platformy a przelewem występuje różnica, nie należy automatycznie uznawać jej za koszt. Najpierw trzeba ustalić, czy obejmuje udokumentowaną prowizję, zwrot, przewalutowanie, środki czasowo zatrzymane albo korektę wcześniejszego okresu.

Kiedy powstaje przychód?

Moment powstania przychodu z działalności gospodarczej określają przede wszystkim regulacje wynikające z art. 14 ustawy o PIT. Zgodnie z zasadą ogólną przychód powstaje w dniu wydania rzeczy, zbycia prawa majątkowego albo wykonania usługi, również częściowego, nie później jednak niż w dniu wystawienia faktury albo uregulowania należności. W sprzedaży towarów przez internet najczęściej trzeba więc ustalić, kiedy nastąpiło wydanie towaru, a następnie sprawdzić, czy wcześniej nie wystawiono faktury lub nie otrzymano zapłaty mającej znaczenie dla rozpoznania przychodu. Nie należy mechanicznie przyjmować daty złożenia zamówienia, wysłania paczki ani przekazania zbiorczej wypłaty przez marketplace. Każda z tych dat opisuje inny etap procesu, a właściwy moment powinien wynikać z przepisów i rzeczywistego przebiegu transakcji.

Data wypłaty środków przez platformę nie wyznacza więc automatycznie daty przychodu ani daty zapisu w KPiR. Jedna wypłata może obejmować sprzedaż z kilku dni lub miesięcy, a część środków może zostać przekazana dopiero po rozliczeniu zwrotów albo zakończeniu okresu rezerwowego. Szczególne zasady mogą obowiązywać między innymi przy usługach rozliczanych okresowo, zaliczkach, korektach oraz kasowym PIT. Kasowy PIT jest wyjątkiem od zasad ogólnych i dotyczy wyłącznie podatników spełniających ustawowe warunki. Nie należy stosować jego logiki do każdej firmy tylko dlatego, że marketplace wypłaca środki z opóźnieniem. Nawet przy tej metodzie zbiorczy przelew trzeba powiązać z konkretnymi należnościami i dokumentami. W dobrze zaprojektowanym procesie obok siebie przechowuje się datę zamówienia, datę wydania towaru, datę wystawienia dokumentu, datę otrzymania zapłaty oraz datę payoutu, dzięki czemu moment przychodu nie jest ustalany na podstawie przypadkowej daty widocznej w jednym raporcie.

Prosty przykład liczbowy

Załóżmy, że wartość sprzedaży brutto wykazana w raportach marketplace’u wyniosła 20 000 zł. Platforma naliczyła 2 000 zł prowizji i innych opłat, a klienci dokonali zwrotów o wartości 1 000 zł. Na rachunek przedsiębiorcy wpłynęło w rezultacie 17 000 zł. Gdyby firma zaksięgowała wyłącznie kwotę przelewu, połączyłaby w jednym zapisie sprzedaż, koszty usług platformy oraz zwroty. Nie byłoby wiadomo, jaka była pierwotna wartość transakcji, które opłaty posiadają odpowiednie dokumenty ani jakich zamówień dotyczą korekty. W efekcie przychód zostałby określony na podstawie wyniku rozrachunku, a nie na podstawie właściwych dokumentów sprzedażowych. Przykład ma charakter uproszczony i pokazuje mechanizm rozliczenia, a nie sposób ustalania podstawy opodatkowania PIT w każdej możliwej sytuacji.

Prawidłowe podejście wymaga rozdzielenia poszczególnych elementów. Sprzedaż należy ująć na podstawie faktur, raportów fiskalnych, dziennych dowodów wewnętrznych albo właściwego zestawienia sprzedaży, zależnie od sposobu dokumentowania transakcji. Prowizje i inne opłaty mogą zostać rozpoznane jako koszty tylko wtedy, gdy spełniają warunki uznania ich za koszty uzyskania przychodu i są właściwie udokumentowane. Zwroty trzeba powiązać z pierwotnymi transakcjami oraz odpowiednimi korektami. Wartość 20 000 zł została określona jako sprzedaż brutto w znaczeniu handlowym, co nie oznacza, że identyczna kwota zawsze trafi do kolumny przychodowej KPiR. U czynnego podatnika VAT przychodem z działalności zasadniczo nie jest należny VAT, a przy sprzedaży zagranicznej znaczenie mogą mieć również waluta i sposób opodatkowania. Najważniejszy wniosek pozostaje jednak ten sam: 17 000 zł wypłaty nie zastępuje danych o 20 000 zł sprzedaży, 2 000 zł opłat i 1 000 zł zwrotów.

Jakie dokumenty powinny zasilać KPiR?

KPiR nie powinna być zasilana każdym plikiem, który da się pobrać z marketplace’u. Podstawą zapisów są dowody przewidziane w przepisach, natomiast raporty handlowe, operacyjne i rozliczeniowe mają często charakter pomocniczy. Mogą dostarczać danych potrzebnych do sporządzenia ewidencji, sprawdzenia kompletności transakcji albo uzgodnienia wypłat, ale nie stają się przez to automatycznie fakturą, raportem fiskalnym ani innym dokumentem księgowym. Firma powinna dla każdego modelu sprzedaży z góry określić, jaki dokument stanowi podstawę zapisu w KPiR, które raporty służą jedynie do kontroli oraz w jaki sposób zostaną wyeliminowane transakcje ujęte wcześniej na podstawie innych dokumentów.

Od 1 stycznia 2026 roku obowiązuje nowe rozporządzenie w sprawie prowadzenia podatkowej księgi przychodów i rozchodów. Zgodnie z wynikającymi z niego zasadami przychody ze sprzedaży ujmuje się na podstawie właściwych faktur, raportów fiskalnych albo, w przypadku przychodów nieudokumentowanych fakturami i raportami fiskalnymi, na podstawie przewidzianych w przepisach dowodów lub zestawień sprzedaży. Ma to istotne znaczenie w e-commerce, ponieważ raport wypłat, zestawienie obrotów czy raport rentowności nie mogą automatycznie zastąpić dokumentu, na podstawie którego powinien zostać dokonany zapis w księdze. Każde źródło danych musi zostać przypisane do odpowiedniej kategorii dokumentów, a system powinien pozwalać ustalić, czy konkretna sprzedaż została ujęta na podstawie faktury, raportu fiskalnego czy zestawienia sprzedaży nieudokumentowanej fakturą.

Faktury sprzedaży

Faktury są podstawowym dokumentem sprzedaży w relacjach B2B, a także w tych transakcjach B2C, dla których są wystawiane zgodnie z obowiązującymi zasadami. Dokument może powstać w systemie przedsiębiorcy, w zewnętrznym systemie fakturowym albo za pośrednictwem platformy, w tym w ramach samofakturowania lub innego rozwiązania przewidzianego przez operatora. Niezależnie od sposobu wystawienia faktura powinna dokumentować sprzedaż dokonaną przez właściwego podatnika i zawierać wymagane dane. W procesie ewidencyjnym należy zachować powiązanie między numerem dokumentu, datą sprzedaży, nabywcą, wartością przychodu, walutą i identyfikatorem zamówienia. Jeżeli dokument został wystawiony w KSeF, potrzebne jest również zachowanie właściwego numeru identyfikującego fakturę w tym systemie.

Największym zagrożeniem przy sprzedaży wielokanałowej jest podwójne ujęcie tej samej transakcji. Jeden raport marketplace’u może obejmować zarówno sprzedaż niefakturowaną, jak i zamówienia udokumentowane indywidualnymi fakturami. Przed wykorzystaniem wartości zbiorczej trzeba więc sprawdzić, czy nie zawiera ona sprzedaży wcześniej ujętej na podstawie konkretnych dokumentów. Podobna kontrola jest konieczna w przypadku faktur wystawionych do sprzedaży zarejestrowanej wcześniej na kasie fiskalnej. Przychód został już wówczas uwzględniony w raporcie fiskalnym i nie powinien być księgowany po raz drugi na podstawie faktury. Każdy dokument powinien mieć oznaczenie pozwalające ustalić, czy stanowi samodzielną podstawę zapisu, czy potwierdza transakcję objętą wcześniej innym dowodem.

Ewidencja sprzedaży bezrachunkowej

W przypadku przychodów, które nie są dokumentowane fakturami ani raportami fiskalnymi, możliwe jest dokonywanie zapisów na podstawie dziennego dowodu wewnętrznego albo prowadzonego zestawienia sprzedaży, potocznie określanego jako ewidencja sprzedaży bezrachunkowej. Możliwość zastosowania takiego rozwiązania zależy jednak od charakteru sprzedaży, statusu nabywcy i sposobu dokumentowania transakcji. Zależy również od przepisów dotyczących obowiązku ewidencjonowania sprzedaży przy zastosowaniu kas rejestrujących. Sama okoliczność, że klient jest konsumentem albo że zamówienie zostało złożone przez internet, nie oznacza automatycznie, że sprzedaż można ująć w takiej ewidencji. Najpierw trzeba sprawdzić, czy transakcja nie powinna zostać zarejestrowana na kasie i czy nie została już udokumentowana fakturą.

Zestawienie powinno zawierać informacje pozwalające ustalić datę i wysokość przychodu oraz zachować kolejność wpisów. W firmie e-commerce warto rozszerzyć je o dane pomocnicze, takie jak identyfikator zamówienia, kanał sprzedaży, waluta, kraj opodatkowania oraz oznaczenie ewentualnego zwrotu lub korekty. Ewidencję można prowadzić łącznie dla kilku kanałów albo zachować rozdzielenie według marketplace’ów, jeżeli ułatwia to kontrolę. Niezależnie od wybranego modelu suma sprzedaży niefakturowanej nie może obejmować transakcji ujętych wcześniej na podstawie faktur, raportów fiskalnych lub innych dowodów. Najważniejsze jest zachowanie możliwości odtworzenia, z jakich zamówień powstała wartość przeniesiona do KPiR oraz czy każda sprzedaż została wykazana dokładnie raz.

Raporty z kasy fiskalnej

Jeżeli sprzedaż jest ewidencjonowana przy użyciu kasy rejestrującej, zapisy w KPiR mogą być dokonywane na podstawie raportów fiskalnych zgodnie z zasadami wynikającymi z rozporządzenia w sprawie prowadzenia podatkowej księgi przychodów i rozchodów. W zależności od przyjętego sposobu prowadzenia ewidencji podstawę może stanowić raport dobowy albo raport okresowy miesięczny. Dokument powinien być jednoznacznie przypisany do okresu, urządzenia i zakresu sprzedaży, którego dotyczy. W firmie korzystającej z kilku kas lub łączącej sprzedaż internetową ze stacjonarną trzeba dodatkowo sprawdzać, czy wszystkie raporty zostały przekazane do księgowości, czy żaden nie został pominięty oraz czy ten sam raport nie został zaimportowany dwukrotnie.

Sprzedaż fiskalna musi być oddzielona od faktur i zestawień dotyczących sprzedaży nieudokumentowanej fakturą. Jeżeli klient otrzymał fakturę do transakcji zarejestrowanej wcześniej na kasie, nie należy ponownie ujmować przychodu na podstawie tej faktury. Jeżeli natomiast sprzedaż nie została zarejestrowana na kasie, nie może zostać dodana do raportu wyłącznie po to, aby uprościć proces księgowy. Zwroty i reklamacje wpływające na wartość sprzedaży fiskalnej wymagają odpowiedniej dokumentacji korekty i powiązania z pierwotnym raportem. Sam status „zwrócone” widoczny w panelu marketplace’u nie wystarcza do automatycznego obniżenia przychodu. Informację z platformy trzeba połączyć z dokumentacją przewidzianą dla korekty sprzedaży fiskalnej.

Dokumenty kosztowe wystawiane przez platformy

Prowizje, abonamenty, opłaty transakcyjne, koszty reklamy, obsługi płatności, magazynowania i dostawy nie powinny być rozliczane wyłącznie poprzez pomniejszenie przychodu. Są to odrębne zdarzenia gospodarcze, które mogą stanowić koszty uzyskania przychodu, jeżeli pozostają w związku z działalnością, nie podlegają ustawowym wyłączeniom i zostały prawidłowo udokumentowane. Najczęściej podstawą zapisu będzie faktura wystawiona przez operatora marketplace’u lub innego dostawcę usługi. Sam raport wypłat, na którym widoczna jest potrącona prowizja, nie zastępuje automatycznie dokumentu kosztowego. Pokazuje jedynie, że określona kwota została potrącona z należności przedsiębiorcy.

Niektóre platformy wystawiają kilka dokumentów za ten sam okres, ponieważ oddzielnie rozliczają prowizje, reklamę, logistykę, abonament i inne świadczenia. Firma powinna sprawdzić, czy wszystkie faktury zostały pobrane, czy wystawiono je na prawidłowe dane oraz czy odpowiadają potrąceniom widocznym w rozliczeniu. Przy usługach nabywanych od podmiotów zagranicznych potrzebna może być również osobna analiza skutków w VAT, w tym zasad dotyczących importu usług. Fakt, że koszt został potrącony przed wypłatą i przedsiębiorca nie wykonał osobnego przelewu, nie powoduje, że wydatek znika. Nadal wymaga on właściwego dokumentu i odpowiedniego ujęcia.

Klasyfikacja wydatku zależy od jego rzeczywistego charakteru, a nie od nazwy kategorii używanej przez platformę. Prowizja od sprzedaży, opłata za reklamę, koszt obsługi płatności i usługa logistyczna nie muszą być ujmowane w ten sam sposób. Nie należy więc zbiorczo księgować wszystkich potrąceń jako jednej prowizji. Rozliczenie platformy powinno zostać zestawione z fakturami i rozdzielone na kategorie odpowiadające rzeczywiście nabytym usługom. Różnica między sprzedażą a wypłatą nie może być automatycznie zakwalifikowana jako koszt uzyskania przychodu.

Rozliczenie okresowe inne niż faktura może stanowić podstawę zapisu tylko wtedy, gdy spełnia wymagania właściwego dowodu księgowego i jest dopuszczalne dla danego zdarzenia. Nazwa „statement”, „settlement” albo „invoice summary” nie przesądza jeszcze o jego statusie. Trzeba sprawdzić wystawcę, datę, strony transakcji, opis operacji, wartość oraz możliwość powiązania dokumentu z działalnością przedsiębiorcy. Najbezpieczniejszy model zakłada, że raport rozliczeniowy służy do uzgodnienia potrąceń, natomiast zapis kosztu powstaje na podstawie właściwego dokumentu. Dzięki temu różnicę między sprzedażą a wypłatą można wyjaśnić pozycja po pozycji, bez łączenia wielu odmiennych kosztów w jedną zbiorczą kwotę.

Jak stworzyć spójną ewidencję sprzedaży z kilku marketplace’ów?

Spójna ewidencja nie powstaje przez połączenie wszystkich raportów w jeden arkusz ani przez automatyczne przesłanie danych z platform do programu księgowego. Jej podstawą jest świadomie zaprojektowany proces, w którym wiadomo, skąd pochodzi każda informacja, jaki dokument stanowi podstawę zapisu oraz kto odpowiada za sprawdzenie kompletności danych. W firmie prowadzącej sprzedaż na kilku marketplace’ach trzeba jednocześnie uwzględnić różne modele transakcji, terminy wypłat, waluty, sposoby dokumentowania oraz zasady opodatkowania. Celem nie jest ujednolicenie wszystkich transakcji podatkowo, ponieważ sprzedaż krajowa, zagraniczna, B2B, B2C lub objęta szczególną procedurą może wymagać odmiennego podejścia. Ujednolicić należy przede wszystkim wewnętrzny sposób zbierania, opisywania, weryfikowania i przekazywania danych do księgowości.

Dobrze przygotowany proces powinien działać niezależnie od liczby obsługiwanych kanałów. Dodanie kolejnego marketplace’u nie może oznaczać tworzenia nowego, całkowicie odrębnego obiegu dokumentów, zrozumiałego tylko dla jednej osoby. Nowy kanał powinien zostać włączony do istniejącego standardu, który określa minimalny zakres danych, rodzaj dokumentów źródłowych, sposób obsługi korekt oraz zasady archiwizacji. Dzięki temu firma może rozwijać sprzedaż bez utraty kontroli nad księgowością, a księga nie staje się zbiorem przypadkowych wartości pochodzących z różnych systemów. Cały proces można podzielić na sześć etapów, które prowadzą od rozpoznania źródeł danych do zachowania pełnej ścieżki dokumentacyjnej dla każdego zapisu.

Krok 1: sporządź mapę wszystkich kanałów sprzedaży

Pierwszym etapem jest sporządzenie pełnej mapy kanałów, przez które firma przyjmuje zamówienia i rozlicza sprzedaż. Nie należy ograniczać się wyłącznie do listy marketplace’ów. Trzeba uwzględnić również własny sklep internetowy, sprzedaż hurtową, zamówienia przyjmowane bezpośrednio, punkty stacjonarne oraz dodatkowe systemy, w których powstają faktury, paragony lub korekty. Dla każdego kanału należy określić, czy klientami są konsumenci, przedsiębiorcy czy obie grupy, w jakich krajach realizowana jest sprzedaż, w jakiej walucie zawierane są transakcje oraz jaki model podatkowy może mieć zastosowanie. Istotne jest także ustalenie, czy platforma jedynie pośredniczy w sprzedaży, czy dodatkowo obsługuje płatności, logistykę, fakturowanie, zwroty albo rozliczenia podatkowe.

Mapa powinna pokazywać również sposób dokumentowania sprzedaży, miejsce wystawiania faktur, częstotliwość udostępniania raportów oraz to, gdzie obsługiwane są anulacje i korekty. Dla jednego kanału faktury mogą powstawać w centralnym systemie firmy, dla innego w rozwiązaniu platformy, a w kolejnym część sprzedaży może być rejestrowana na kasie fiskalnej. Należy wskazać rodzaje pobieranych opłat, w tym prowizje, abonamenty, koszty reklamy, płatności, dostawy, magazynowania i obsługi zwrotów. Trzeba też zapisać, jakie formaty raportów są dostępne, czy dane można pobierać w CSV, PDF, XML, XLSX, przez API lub w innym formacie oraz jak długo pozostają dostępne w panelu. Taka mapa szybko ujawnia miejsca, w których firma nie posiada pełnych danych albo nie ma ustalonej odpowiedzialności za ich przekazanie do księgowości.

Krok 2: przypisz dokument źródłowy do każdego rodzaju sprzedaży

Po zidentyfikowaniu wszystkich kanałów trzeba przypisać właściwy dokument źródłowy do każdego rodzaju transakcji. Sprzedaż B2B co do zasady dokumentuje się fakturą i ujmuje zgodnie z danymi wynikającymi z tego dokumentu. Wybrane transakcje B2C również mogą być dokumentowane fakturami. Sprzedaż na rzecz konsumentów, która nie została udokumentowana fakturą ani raportem fiskalnym, może być ujmowana na podstawie odpowiedniego zestawienia sprzedaży lub dowodu wewnętrznego, jeżeli taki sposób dokumentowania jest w danej sytuacji dopuszczalny. Jeżeli transakcja podlega ewidencji na kasie rejestrującej, podstawą zapisu będą właściwe raporty fiskalne. Najważniejsze jest to, aby dla każdej kategorii z góry było wiadomo, jaki dokument ma znaczenie księgowe, a jakie raporty pełnią jedynie funkcję kontrolną.

Podobną zasadę należy zastosować do kosztów i korekt. Prowizje, opłaty abonamentowe, reklama, logistyka i inne usługi powinny być rozliczane na podstawie faktur albo innych dokumentów spełniających wymagania właściwego dowodu. Zwroty i anulacje muszą zostać powiązane z pierwotną sprzedażą oraz dokumentem, na podstawie którego została ona ujęta. Jeżeli transakcja była udokumentowana fakturą, potrzebna może być odpowiednia korekta faktury. Jeżeli była objęta raportem fiskalnym albo zestawieniem sprzedaży, korekta powinna zostać rozliczona w sposób właściwy dla tej formy dokumentowania. Sam status zamówienia w panelu marketplace’u nie wystarcza. Przypisanie dokumentów źródłowych eliminuje sytuacje, w których ten sam raport raz służy do zaksięgowania przychodu, a innym razem do potwierdzenia przelewu, bez jasnego określenia jego rzeczywistej funkcji.

Krok 3: ujednolić dane pobierane z platform

Każda platforma prezentuje dane w inny sposób, ale firma powinna stworzyć jeden wewnętrzny standard informacji wymaganych dla wszystkich kanałów. Minimalny zakres powinien obejmować datę sprzedaży, numer zamówienia, identyfikator kanału, kraj opodatkowania, walutę, wartość brutto, wartość netto oraz kwotę podatku, jeżeli występuje. Potrzebny jest także status zamówienia, informacja o wystawionej fakturze, numer dokumentu księgowego, kwota zwrotu, data korekty, wysokość prowizji, pozostałe opłaty oraz data wypłaty. Przy sprzedaży zagranicznej warto dodatkowo oznaczać sposób rozliczenia podatku, na przykład OSS, lokalny VAT, eksport albo WDT, ponieważ transakcje realizowane przez ten sam marketplace mogą podlegać odmiennym zasadom w zależności od kraju klienta, miejsca rozpoczęcia wysyłki, miejsca zakończenia transportu i statusu nabywcy.

Ujednolicenie nie oznacza, że wszystkie raporty muszą mieć identyczny układ już w chwili pobrania. Oznacza natomiast, że dane z każdego kanału powinny zostać przekształcone do wspólnego modelu, zanim trafią do kontroli i księgowania. Jeżeli jeden raport zawiera wartości po potrąceniu prowizji, trzeba pozyskać dane pozwalające odtworzyć sprzedaż przed potrąceniami. Jeżeli platforma rozdziela zwroty i zamówienia na dwa pliki, należy połączyć je za pomocą wspólnego identyfikatora. Jeżeli faktury powstają poza marketplace’em, dane trzeba uzupełnić o numer dokumentu i informację, czy transakcja została już ujęta indywidualnie. Wewnętrzny standard powinien działać jak wspólny język między sprzedażą, księgowością i finansami, dzięki któremu każde zamówienie można jednoznacznie sklasyfikować.

Krok 4: prowadź ewidencje pomocnicze dla poszczególnych kanałów

Osobne ewidencje pomocnicze dla marketplace’ów są przydatne, ponieważ pozwalają zachować szczegółowość danych bez tworzenia osobnych KPiR. Każde zestawienie może pokazywać sprzedaż, faktury, zwroty, anulacje, prowizje i wypłaty dotyczące konkretnego kanału, kraju albo waluty. Dzięki temu łatwiej wykryć brakujące zamówienie, różnicę między raportami lub transakcję, która została ujęta podwójnie. Ewidencja pomocnicza nie powinna jednak funkcjonować jako odizolowany arkusz, którego sumy są ręcznie przepisywane do księgowości bez możliwości sprawdzenia źródła. Każda wartość przenoszona do KPiR powinna być powiązana z raportem, dokumentem i zakresem transakcji, z których została obliczona.

Każdy wpis w ewidencji pomocniczej powinien umożliwiać powrót do zamówienia albo dokumentu źródłowego. Potrzebny jest więc numer zamówienia, identyfikator transakcji, numer faktury lub innego dowodu, data oraz informacja o kanale. W przypadku zapisów zbiorczych należy zachować zestawienie pozycji tworzących daną sumę. Jeżeli po kilku miesiącach księgowość otrzyma pytanie o konkretny wpis, powinna być w stanie ustalić, które transakcje zostały w nim ujęte, jakie korekty zastosowano i z jakiego raportu pochodziły dane. Ewidencja pomocnicza ma największą wartość wtedy, gdy nie tylko agreguje liczby, ale tworzy pełną ścieżkę między zamówieniem, dokumentem księgowym, KPiR i rozliczeniem platformy.

Krok 5: ustal jeden sposób opisywania wpisów

Jednolity sposób opisywania wpisów pozwala szybciej rozpoznać ich źródło i ogranicza liczbę dodatkowych wyjaśnień. Opis powinien zawierać nazwę lub identyfikator kanału, rodzaj dokumentu, numer albo zakres numerów, datę lub okres oraz informację, czy zapis dotyczy sprzedaży B2B, B2C, sprzedaży fiskalnej, korekty czy kosztu. W przypadku sprzedaży zagranicznej warto dodać kraj, walutę albo oznaczenie procedury, jeżeli ma to znaczenie dla późniejszej kontroli. Przykładowy opis może brzmieć: „Marketplace A – zestawienie sprzedaży B2C nieudokumentowanej fakturą – 15.01.2026”. Jeżeli zapis obejmuje cały okres, opis powinien wskazywać jego dokładny zakres oraz identyfikator raportu, na podstawie którego powstała wartość.

Standard opisu powinien być stosowany niezależnie od tego, kto przygotowuje dane. Nie może zależeć od pamięci księgowego, właściciela firmy albo pracownika działu operacyjnego. Warto ustalić zamknięty zestaw nazw dokumentów i oznaczeń kanałów, aby ta sama platforma nie występowała w księdze pod kilkoma skrótami. Opisy nie powinny być przesadnie długie, ale muszą pozwalać odróżnić podobne wpisy i szybko odnaleźć dokumentację. Jeżeli jeden zapis dotyczy sprzedaży, drugi korekty, a trzeci kosztów platformy, każdy powinien mieć wyraźnie inną nazwę. Dobrze zaprojektowany standard ułatwia także kontrolę JPK_PKPIR, ponieważ dane w księdze są czytelne i można je powiązać z konkretnymi źródłami bez ręcznego przeszukiwania wielu folderów.

Krok 6: archiwizuj raporty i dokumenty

Archiwizacja powinna obejmować zarówno dokumenty księgowe, jak i raporty pomocnicze wykorzystane do przygotowania zapisów. Należy zachowywać pliki źródłowe pobrane z platform, w tym raporty CSV, PDF, XML, XLSX, dane pobrane przez API oraz inne formaty zawierające informacje o sprzedaży, zwrotach, opłatach i wypłatach. Pliki powinny być uporządkowane według kanału, okresu i rodzaju dokumentu, tak aby po kilku miesiącach można było łatwo odtworzyć przebieg rozliczenia. Warto zachować oryginalny plik pobrany z marketplace’u, wersję przetworzoną na potrzeby wewnętrznej ewidencji wraz z informacją o zakresie wykonanych przekształceń oraz końcowe zestawienie, na podstawie którego dokonano zapisu w KPiR. Nadpisywanie pierwotnych raportów usuwa możliwość sprawdzenia, jakie dane były dostępne w momencie księgowania.

Informacja o wykonanych przekształceniach powinna wskazywać między innymi, czy usunięto anulowane zamówienia, wyłączono sprzedaż ujętą wcześniej na podstawie faktur, przeliczono waluty, połączono raport sprzedaży z raportem zwrotów albo przypisano dokumenty kosztowe do potrąceń. Nie musi to być rozbudowana dokumentacja techniczna. Powinna jednak umożliwiać innej osobie odtworzenie logiki, według której z pliku źródłowego powstała kwota przeniesiona do ewidencji. Ma to szczególne znaczenie przy automatycznych integracjach i danych pobieranych przez API, ponieważ końcowy raport może być wynikiem kilku operacji wykonywanych bez ręcznej ingerencji. Firma powinna wiedzieć, jakie reguły zastosowano, kiedy zostały zmienione i od którego okresu obowiązuje nowa wersja procesu.

Szczególne znaczenie ma zachowanie właściwej wersji raportu. Platformy mogą aktualizować dane po zwrocie, anulacji lub korekcie, dlatego ten sam raport pobrany w dwóch różnych dniach może zawierać inne wartości. Firma powinna wiedzieć, która wersja została użyta do księgowania i jakie późniejsze zmiany wymagały korekty. Każdy plik warto oznaczyć datą pobrania, okresem, kanałem oraz statusem, na przykład „źródłowy”, „zweryfikowany” albo „zaksięgowany”. Dokumenty kosztowe powinny być powiązane z potrąceniami widocznymi w rozliczeniu, a zestawienia sprzedaży z odpowiednimi wpisami w KPiR. Taki system archiwizacji sprawia, że firma nie tylko posiada pliki, lecz potrafi wykazać, które z nich stanowiły podstawę zapisu, które służyły do kontroli i jak rozwiązano ewentualne rozbieżności.

Jak uniknąć podwójnego księgowania sprzedaży?

Podwójne księgowanie sprzedaży rzadko wynika z ponownego wczytania tego samego pliku do jednego systemu. Znacznie częściej pojawia się wtedy, gdy informacje dotyczące tej samej transakcji trafiają do księgowości kilkoma niezależnymi drogami. Faktura może zostać zaimportowana z systemu fakturowego, zamówienie może pozostać w raporcie sprzedaży marketplace’u, a jego wartość może dodatkowo pojawić się w raporcie fiskalnym, zestawieniu rozliczeniowym albo integracji z systemem ERP. Każde źródło przedstawia rzeczywiste dane, ale ich zakresy częściowo się pokrywają. Jeżeli przed dokonaniem zapisów nie zostanie sprawdzone, co dokładnie obejmuje każdy dokument i raport, ta sama sprzedaż może zwiększyć przychód więcej niż jeden raz.

Ryzyko rośnie wraz z liczbą kanałów, integracji i miejsc, w których wystawiane są dokumenty. Faktury mogą powstawać w jednym systemie, zamówienia być obsługiwane w drugim, paragony w trzecim, a rozliczenia finansowe pobierane bezpośrednio z panelu platformy. Zwroty i korekty mogą pojawiać się jeszcze w innym module. W takim środowisku nie wystarczy kontrolować, czy numer faktury nie powtarza się w jednym pliku. Proces powinien umożliwiać sprawdzenie, czy to samo zamówienie, identyfikator transakcji marketplace’u, płatność albo wydanie towaru nie zostały ujęte pod różnymi oznaczeniami. Podstawową zasadą pozostaje przypisanie każdej sprzedaży do jednego sposobu ujęcia przychodu oraz zachowanie informacji, który dokument stanowił podstawę zapisu w KPiR.

Najczęstszy scenariusz błędu

Typowy błąd zaczyna się od prawidłowo wystawionej faktury. Dokument trafia do KPiR jako podstawa ujęcia przychodu, ale zamówienie pozostaje jednocześnie w raporcie sprzedaży pobranym z marketplace’u. Jeżeli raport jest następnie wykorzystywany do przygotowania zbiorczego zestawienia sprzedaży nieudokumentowanej fakturami, wartość tej transakcji zostaje wykazana po raz drugi. Trzecie ujęcie może pojawić się wtedy, gdy osoba rozliczająca platformę potraktuje payout jako dodatkowy przychód, nie sprawdzając, że wypłata obejmuje należności wynikające ze sprzedaży zaksięgowanej już na podstawie faktury i zestawienia zbiorczego. Jedna transakcja może więc przejść przez trzy różne systemy i zostać ujęta trzy razy, mimo że każdy etap był obsługiwany oddzielnie i na pierwszy rzut oka wyglądał poprawnie.

Podobne ryzyko występuje przy sprzedaży zarejestrowanej na kasie fiskalnej. Jeżeli do paragonu zostanie później wystawiona faktura, przychód nie powinien zostać ponownie ujęty w KPiR tylko dlatego, że nowy dokument pojawił się w systemie fakturowym. Sprzedaż została już objęta raportem fiskalnym. Duplikat może również powstać po zwrocie lub korekcie, gdy pierwotna wartość pozostaje w jednym raporcie, a poprawiona transakcja jest importowana jako nowa pozycja. Dlatego kontrola powinna obejmować nie tylko numery faktur, lecz także numery zamówień, identyfikatory transakcji marketplace’u, identyfikatory płatności i rozliczeń, daty, kwoty oraz sposób dokumentowania sprzedaży. Na jednej platformie mogą równolegle funkcjonować order ID, transaction ID i settlement ID, a każdy z tych numerów pełni inną rolę w uzgodnieniu.

Jak oddzielić sprzedaż fakturową od pozostałej?

Każde zamówienie powinno mieć jednoznaczne oznaczenie wskazujące, czy została do niego wystawiona faktura, czy sprzedaż została zarejestrowana na kasie, czy też może zostać objęta zestawieniem sprzedaży nieudokumentowanej fakturami i raportami fiskalnymi. Oznaczenie powinno być przekazywane razem z danymi do raportu wykorzystywanego przez księgowość. Sam status informujący, że klient poprosił o fakturę, może nie wystarczyć. Potrzebny jest numer istniejącego dokumentu, data jego wystawienia oraz identyfikator pozwalający połączyć fakturę z konkretnym zamówieniem i transakcją marketplace’u. Jeżeli dokument powstaje poza platformą, dane z systemu fakturowego powinny zostać zestawione z raportem sprzedaży przed ustaleniem wartości wpisu zbiorczego.

Transakcje udokumentowane fakturami trzeba wyłączyć z zakresu danych wykorzystywanych do przygotowania zapisu dotyczącego sprzedaży niefakturowanej. Oryginalny raport powinien jednak pozostać w archiwum, natomiast wersja przetworzona musi wskazywać, które pozycje zostały pominięte i z jakiego powodu. Dobrą praktyką jest stosowanie tej samej logiki we wszystkich kanałach, nawet jeżeli platformy używają innych nazw pól i statusów. Oznaczenia typu „invoice issued” lub „business customer” nie zawsze potwierdzają, że dokument rzeczywiście powstał, dlatego końcowa kontrola powinna opierać się na numerze faktury i możliwości odnalezienia jej w systemie. Reguły muszą obejmować również faktury wystawione do sprzedaży fiskalnej, dokumenty generowane w ramach samofakturowania i korekty. Faktura korygująca nie przedstawia nowej sprzedaży, lecz zmienia wartość transakcji ujętej wcześniej.

Lista kontrolna przed zaksięgowaniem raportu

Przed zaksięgowaniem raportu trzeba ustalić, jaki okres i zakres sprzedaży rzeczywiście obejmuje. Warto sprawdzić, czy znajdują się w nim transakcje B2B albo inne zamówienia udokumentowane indywidualnymi fakturami, a także czy raport zawiera sprzedaż zarejestrowaną na kasie. Kolejne pytanie dotyczy anulowanych zamówień. Niektóre platformy pozostawiają je w raportach, mimo że nie doszło do sprzedaży, albo przedstawiają je jako oddzielne pozycje korygujące. Konieczne jest więc ustalenie, czy wartość końcowa została już pomniejszona o anulacje, czy takie pozycje wymagają wyłączenia podczas przetwarzania danych. Trzeba również potwierdzić, czy raport pokazuje wartość zamówień, dokumentów sprzedaży, płatności czy wypłat, ponieważ te pojęcia nie są wymienne.

Osobnej kontroli wymagają zwroty oraz sposób prezentowania kwot. Zwrot wykazany w bieżącym miesiącu może dotyczyć sprzedaży ujętej kilka miesięcy wcześniej, a raport może pokazywać go jako ujemną wartość bez wskazania pierwotnego dokumentu. Przed księgowaniem trzeba powiązać korektę z właściwą transakcją i ustalić, czy raport prezentuje kwoty brutto, netto, wartość podatku czy sumę po potrąceniu opłat. Nazwy takie jak „revenue”, „net amount” albo „sales proceeds” mogą mieć różne znaczenie w zależności od platformy. Końcowym etapem jest porównanie raportu z zapisami, które trafiły już do KPiR. Kontrola powinna potwierdzić, że ten sam zakres sprzedaży nie został wcześniej ujęty na podstawie faktur, raportów fiskalnych, innych zestawień albo integracji z systemem księgowym.

Prowizje, opłaty i koszty marketplace’ów w KPiR

Rozliczenie marketplace’u nie kończy się na prawidłowym ujęciu sprzedaży. Platformy pobierają wiele rodzajów opłat, które wpływają na wysokość payoutu i rentowność kanału, ale nie zawsze są przedstawiane na jednym dokumencie. Prowizja może być naliczana dla każdej transakcji, reklama rozliczana w odrębnym cyklu, a usługi logistyczne wykazywane na kolejnej fakturze. Do tego dochodzą koszty obsługi płatności, magazynowania, zwrotów, przewalutowania, relokacji towarów i usług dodatkowych. Z perspektywy przedsiębiorcy wszystkie te pozycje zmniejszają kwotę otrzymywaną z platformy, jednak podatkowo wymagają rozpoznania ich rzeczywistego charakteru i przypisania do właściwych dokumentów.

Kluczowe jest utrzymanie rozdzielenia między przychodem a kosztami. Platforma może potrącić własne należności przed przekazaniem pieniędzy sprzedawcy, ale takie potrącenie nie powoduje automatycznie zmniejszenia przychodu ze sprzedaży. Sprzedaż towaru klientowi i zakup usługi od operatora są odrębnymi zdarzeniami gospodarczymi. Każde powinno zostać ujęte według zasad właściwych dla jego charakteru i na podstawie odpowiedniego dokumentu. Raport wypłaty pomaga połączyć obie strony rozliczenia oraz wyjaśnić, dlaczego kwota przelewu jest niższa od wartości należności ze sprzedaży, ale sam nie zastępuje dokumentacji przychodowej ani kosztowej.

Dlaczego nie należy księgować wyłącznie kwoty netto wypłaty?

Księgowanie wyłącznie kwoty otrzymanej od marketplace’u zaciera różnicę między sprzedażą, zwrotami, kosztami i środkami czasowo zatrzymanymi przez platformę. Jeżeli klienci kupili towary o wartości 100 000 zł, a operator przekazał przedsiębiorcy 84 000 zł, nie oznacza to automatycznie, że przychód wyniósł 84 000 zł ani że pozostałe 16 000 zł stanowi koszt uzyskania przychodu. Różnica może obejmować prowizje, reklamę, opłaty logistyczne, zwroty, rezerwy, przewalutowanie i korekty wcześniejszych okresów. Część pozycji może stanowić prawidłowo udokumentowany koszt, część może korygować sprzedaż, a część może być należnością, która zostanie przekazana dopiero w kolejnym okresie.

Potrącenie prowizji nie zmniejsza automatycznie przychodu. Przedsiębiorca uzyskuje przychód ze sprzedaży towaru, a równocześnie ponosi wydatek za usługi marketplace’u. Koszt może zostać rozpoznany po spełnieniu warunków wynikających z ustawy o PIT i na podstawie właściwego dokumentu, natomiast samo obniżenie wypłaty nie potwierdza jeszcze, że potrącenie spełnia te wymagania. Bezpieczniejszy proces pozwala przejść od pełnej wartości sprzedaży przez zwroty, korekty, rezerwy i poszczególne opłaty aż do kwoty payoutu. Takie rozdzielenie ma również znaczenie zarządcze, ponieważ ujawnia rzeczywistą skalę obrotu i pozwala ocenić, czy wzrost sprzedaży na danej platformie nie jest osiągany kosztem coraz wyższych wydatków reklamowych, logistycznych lub transakcyjnych.

Jakie koszty mogą pojawić się w rozliczeniach?

Najbardziej oczywistym kosztem jest prowizja od sprzedaży, naliczana procentowo od wartości transakcji albo według stawki przypisanej do określonej kategorii produktu. Platforma może pobierać również opłaty za wystawianie ofert, abonament, dodatkową widoczność produktów, kampanie reklamowe, obsługę płatności, przewalutowanie oraz udział w programach promocyjnych. Poszczególne pozycje bywają prezentowane w innych raportach i dokumentach. Określenie „marketplace fees” może więc obejmować kilka różnych usług, których nie warto łączyć w jedną ogólną kategorię wyłącznie dlatego, że zostały potrącone z tej samej wypłaty. Opłata pobierana przez platformę za usługę przewalutowania jest przy tym czymś innym niż różnice kursowe powstające przy podatkowym rozliczaniu należności i zobowiązań.

Znaczącą część kosztów mogą stanowić usługi logistyczne. Transport może oznaczać dostawę produktu do klienta, wysyłkę towaru do magazynu operatora, przewóz między magazynami albo relokację zapasów w ramach sieci fulfillmentowej. Każda z tych operacji ma inny cel gospodarczy i nie zawsze powinna być traktowana w identyczny sposób. Do rozliczeń dochodzą również opłaty za magazynowanie, kompletowanie zamówień, pakowanie, obsługę zwrotów, długoterminowe przechowywanie, utylizację produktów i usługi dodatkowe. Nazwa kategorii używana przez platformę nie przesądza o właściwym ujęciu w KPiR. Potrzebne jest ustalenie, jaką usługę rzeczywiście wykonano i jaki dokument ją potwierdza.

Jak powiązać koszty z dokumentami?

Proces powinien zaczynać się od regularnego pobierania faktur i pozostałych dokumentów kosztowych udostępnianych przez platformę. Sam miesięczny raport wypłat może nie wystarczyć, ponieważ faktury za prowizje, reklamę, logistykę i usługi dodatkowe często znajdują się w różnych częściach panelu oraz obejmują odmienne okresy. Każdy dokument trzeba sprawdzić pod kątem danych nabywcy, wystawcy, daty, waluty, rodzaju usługi i okresu rozliczeniowego. Przy usługach świadczonych przez zagranicznego operatora bardzo często powstaje obowiązek rozliczenia importu usług zgodnie z ustawą o VAT. Konieczne jest więc ustalenie, jaki podmiot wystawił dokument, z jakiego kraju działa oraz czy polski przedsiębiorca jest zobowiązany do wykazania podatku według zasad właściwych dla takiego nabycia.

W dalszej kolejności dokumenty trzeba porównać z potrąceniami widocznymi w rozliczeniu platformy. Łączna wartość faktur nie zawsze odpowiada potrąceniom z jednej wypłaty, ponieważ dokument może obejmować cały miesiąc, podczas gdy payouty są realizowane co kilka dni. Część opłat może być pobierana z kilku kolejnych wypłat, a korekta dokumentu pojawić się dopiero w następnym okresie. Uzgodnienie powinno więc uwzględniać datę wystawienia, okres świadczenia usługi, dzień potrącenia, walutę i identyfikator rozliczenia. Proces powinien umożliwiać połączenie kosztu z fakturą, odpowiednią pozycją raportu i zapisem w KPiR, a jednocześnie potwierdzać, że dokument nie został zaksięgowany drugi raz przez inną integrację lub import.

Każde potrącenie powinno mieć wyjaśnione źródło, ale nie każda pozycja widoczna w raporcie wypłat będzie kosztem podatkowym. Różnicę między sprzedażą a payoutem można uznać za uzgodnioną dopiero wtedy, gdy wiadomo, jaka część wynika ze zwrotów, jaka z udokumentowanych usług, jaka z rezerw, a jaka z innych rozliczeń. Warto unikać zbiorczego księgowania wszystkich obciążeń jako jednej prowizji. Lepszym rozwiązaniem jest podział zgodny z rzeczywistym charakterem usług, nawet jeżeli platforma przedstawiła je w jednym zestawieniu. Dzięki temu KPiR pokazuje przychody i koszty w sposób odpowiadający zdarzeniom gospodarczym, a raport marketplace’u pełni właściwą funkcję: łączy dokumenty, przepływy pieniężne i dane operacyjne, lecz żadnego z nich nie zastępuje.

Zwroty, anulacje i korekty – najsłabszy punkt ewidencji

Zwroty i anulacje należą do najtrudniejszych elementów sprzedaży wielokanałowej, ponieważ zazwyczaj pojawiają się później niż pierwotne zamówienie i mogą zostać zapisane w innym systemie niż dokument sprzedaży. Klient składa zamówienie na marketplace’ie, faktura powstaje w zewnętrznym systemie, wysyłkę rejestruje operator logistyczny, a informacja o zwrocie trafia do raportu rozliczeniowego platformy dopiero przy kolejnej wypłacie. Każdy etap ma własną datę oraz identyfikator, dlatego zwykłe odjęcie wartości zwrotów od bieżącej sprzedaży nie zawsze pozwala prawidłowo odtworzyć przebieg transakcji. Proces powinien umożliwiać powiązanie korekty z pierwotnym zamówieniem, dokumentem księgowym, okresem ujęcia przychodu oraz rozliczeniem finansowym marketplace’u.

Dodatkową trudność tworzy różnica między statusem handlowym zamówienia a jego znaczeniem podatkowym. Platforma może określić transakcję jako anulowaną, zwróconą lub zrefundowaną, ale sam status widoczny w panelu nie rozstrzyga jeszcze, czy sprzedaż została wcześniej ujęta ani jak należy ją skorygować. Inaczej wygląda zamówienie anulowane przed wydaniem towaru i wystawieniem dokumentu, a inaczej zwrot produktu po zakończeniu sprzedaży. Firma potrzebuje więc procedury, która nie opiera się wyłącznie na końcowym statusie zamówienia, lecz odtwarza kolejność zdarzeń oraz wskazuje dokument stanowiący podstawę pierwotnego zapisu i późniejszej korekty.

Anulowane zamówienia

Pierwszym krokiem przy anulowanym zamówieniu jest ustalenie, czy doszło już do zdarzenia powodującego rozpoznanie przychodu i czy transakcja została ujęta w KPiR. Jeżeli klient zrezygnował przed realizacją zamówienia, towar nie został wydany, płatność została cofnięta, a faktura ani paragon nie powstały, pozycja co do zasady nie powinna zasilać zestawienia będącego podstawą księgowania sprzedaży. Problem polega na tym, że część raportów marketplace’ów pokazuje wszystkie zamówienia utworzone w danym okresie, niezależnie od ich końcowego statusu. Niezrealizowane pozycje mogą więc pozostać w pliku obok transakcji zakończonych, a ich automatyczne zsumowanie prowadzi do zawyżenia wartości sprzedaży.

Inaczej należy podejść do zamówienia anulowanego po wystawieniu dokumentu albo po ujęciu przychodu. W takiej sytuacji samo usunięcie pozycji z późniejszego raportu nie cofa wcześniejszego zapisu. Trzeba sprawdzić, czy wystawiono fakturę korygującą, czy transakcja została zarejestrowana na kasie oraz jakie dokumenty potwierdzają anulowanie i zwrot środków. Oryginalne zamówienie powinno pozostać w archiwum razem z informacją o jego dalszym losie. Bezpieczniejszym rozwiązaniem jest oznaczenie pozycji jako anulowanej oraz powiązanie jej z dokumentem korygującym niż usuwanie śladów pierwotnej operacji. Dzięki temu można wykazać, dlaczego zamówienie pojawia się w raporcie handlowym, ale nie zwiększa ostatecznej wartości przychodu albo zostało skorygowane po wcześniejszym zaksięgowaniu.

Zwroty po zaksięgowaniu sprzedaży

Jeżeli klient zwraca towar po ujęciu sprzedaży w KPiR, korekta musi zostać powiązana z pierwotnym zamówieniem oraz dokumentem, na podstawie którego rozpoznano przychód. Potrzebne są identyfikatory pozwalające połączyć zwrot z numerem faktury, paragonem, raportem fiskalnym albo pozycją w zestawieniu sprzedaży. Sama informacja o refundacji widoczna w raporcie payoutu nie wyjaśnia jeszcze, czy zwrot został już uwzględniony w innym systemie ani jakiej części transakcji dotyczy. Klient może zwrócić tylko jeden z kilku produktów, otrzymać zwrot kosztu dostawy albo uzyskać częściową rekompensatę bez oddania towaru. Każdy z tych przypadków może mieć inny wpływ na pierwotnie wykazaną wartość i wymaga dokumentacji odpowiadającej rzeczywistemu przebiegowi zdarzenia.

Sposób korekty zależy od formy udokumentowania sprzedaży i przyczyny zmiany. Przy fakturze konieczne może być wystawienie faktury korygującej, natomiast korekta sprzedaży fiskalnej lub wartości ujętej w zestawieniu wymaga zastosowania zasad właściwych dla danego rodzaju ewidencji. W podatku dochodowym znaczenie ma również to, czy korekta wynika z późniejszego zdarzenia, takiego jak zwykły zwrot towaru, czy z błędu rachunkowego albo oczywistej omyłki występującej już w pierwotnym dokumencie. W pierwszym przypadku korekta przychodu jest co do zasady ujmowana na bieżąco zgodnie z dokumentem potwierdzającym jej przyczynę, natomiast błąd istniejący od początku może wymagać odniesienia do pierwotnego okresu. Raport marketplace’u powinien zatem inicjować analizę korekty, a nie automatycznie pomniejszać bieżącą sprzedaż bez sprawdzenia jej podstawy.

Zwroty na przełomie miesięcy lub lat

Zwroty na przełomie okresów szczególnie często powodują różnice między raportem sprzedaży, payoutem i KPiR. Towar może zostać sprzedany w listopadzie, zwrócony w grudniu, a jego wartość potrącona przez platformę dopiero z wypłaty styczniowej. W każdym z tych miesięcy system pokazuje inny fragment transakcji. Raport sprzedaży zawiera pierwotne zamówienie, raport zwrotów informację o refundacji, a rozliczenie finansowe późniejsze potrącenie. Proste porównanie miesięcznych sum nie doprowadzi do zgodności, jeżeli dane nie zostaną połączone za pomocą numeru zamówienia, identyfikatora transakcji, dokumentu sprzedaży oraz identyfikatora zwrotu lub rozliczenia. Różnica pomiędzy okresami nie musi oznaczać błędu, ale musi być możliwa do logicznego wyjaśnienia.

Jeszcze większej kontroli wymagają zwroty dokonane po zakończeniu roku. Firma powinna zachować pełną ścieżkę wskazującą datę sprzedaży, moment ujęcia przychodu, datę zwrotu, dokument korygujący, wartość w walucie transakcji i sposób przeliczenia na złote. Trzeba również ustalić, czy korekta wynika z późniejszego zdarzenia gospodarczego, czy z błędu istniejącego już w pierwotnym zapisie, ponieważ może to wpływać na okres jej rozliczenia. Jeżeli rozbieżność zostanie wykryta po przygotowaniu albo przekazaniu JPK_PKPIR, konieczna jest ocena, czy zmiana KPiR powoduje również potrzebę korekty pliku i rozliczenia rocznego. Najważniejsze jest zachowanie ciągłości informacji, aby korekta nie wyglądała jak niezależna ujemna transakcja, której nie można przypisać do wcześniejszej sprzedaży.

W przypadku sprzedaży zagranicznej trzeba dodatkowo ustalić, w którym systemie rozliczeniowym powinna zostać wykazana korekta. Jeżeli pierwotna transakcja została rozliczona w procedurze OSS, w ramach lokalnej rejestracji VAT, jako eksport albo według innych zasad właściwych dla sprzedaży międzynarodowej, zwrot powinien zostać przypisany do tego samego modelu rozliczenia. Samo pomniejszenie bieżącej sprzedaży w polskim zestawieniu może nie odzwierciedlać prawidłowo skutków podatkowych. Proces powinien zatem przechowywać informację nie tylko o kraju klienta i walucie, lecz także o procedurze lub rejestracji, w ramach której wykazano pierwotną sprzedaż.

Harmonogram kontroli spójności ewidencji

Spójnej ewidencji nie da się zbudować wyłącznie podczas rocznego zamknięcia księgi. W średniej firmie e-commerce jeden rok może obejmować setki tysięcy operacji, wiele zmian statusów, rozliczenia w różnych walutach oraz dokumenty dostępne w panelach platform tylko przez określony czas. Im później firma rozpocznie wyjaśnianie rozbieżności, tym trudniej będzie ustalić, czy brakująca kwota wynika z anulowanego zamówienia, korekty, rezerwy, prowizji czy błędu integracji. Kontrola powinna więc działać warstwowo: część informacji jest weryfikowana przy powstaniu transakcji, część w krótkich cyklach operacyjnych, a pełne uzgodnienie odbywa się po zakończeniu miesiąca.

Częstotliwość poszczególnych czynności można dostosować do skali firmy, ale przenoszenie całego procesu na koniec roku tworzy niepotrzebne ryzyko. Przy dużej liczbie zamówień bieżące kontrole powinny być w znacznym stopniu zautomatyzowane, natomiast pracownicy powinni analizować przede wszystkim wyjątki, takie jak brak dokumentu, powtarzający się identyfikator, nietypowa wartość potrącenia albo zwrot bez pierwotnej transakcji. Taki model ogranicza ręczną pracę, a jednocześnie pozwala wykryć problem wtedy, gdy dane oraz osoby odpowiedzialne za jego wyjaśnienie są nadal łatwo dostępne.

Na bieżąco: dokumentuj każdą sprzedaż

Na poziomie pojedynczego zamówienia trzeba potwierdzić, jaki dokument powstał i w jaki sposób transakcja ma zostać później ujęta. System powinien rozróżniać fakturę, sprzedaż fiskalną oraz sprzedaż, która może zostać objęta właściwym zestawieniem, jeżeli przepisy dopuszczają taki sposób dokumentowania. Potrzebne są także oznaczenia anulacji, zwrotów i korekt oraz powiązania między zamówieniem a numerem dokumentu. Brak faktury, nieudana fiskalizacja albo niewłaściwy status nabywcy powinny zostać wykryte możliwie szybko, zanim transakcja trafi do zbiorczego raportu i zostanie połączona z tysiącami innych pozycji.

Bieżąca kontrola nie musi oznaczać ręcznego sprawdzania każdego zamówienia. Proces może automatycznie wskazywać pozycje bez dokumentu, zamówienia posiadające więcej niż jeden numer faktury, zwroty bez identyfikatora pierwotnej sprzedaży albo transakcje o niespójnym statusie w dwóch systemach. Najważniejsze jest eliminowanie braków na poziomie źródłowym. Jeżeli błąd zostanie naprawiony jeszcze w systemie sprzedażowym, kolejne raporty będą zawierały prawidłową informację. Gdy firma ogranicza się do ręcznej korekty końcowego arkusza, problem może wrócić przy następnym pobraniu danych albo pojawić się ponownie w integracji księgowej.

Raz w tygodniu: sprawdzaj kompletność kanałów

Cotygodniowa kontrola powinna koncentrować się na tym, czy każdy aktywny kanał dostarczył pełny zestaw danych. Warto porównać liczbę zamówień z raportami sprzedaży, sprawdzić ciągłość numerów dokumentów oraz zweryfikować, czy wszystkie faktury kosztowe dostępne w panelach zostały pobrane i przekazane do księgowości. Jeżeli platforma udostępnia dane przez API, potrzebna jest również kontrola, czy integracja działała przez cały okres i nie pominęła części operacji z powodu błędu technicznego. Brak danych z jednego dnia może pozostać niewidoczny w miesięcznej sumie, szczególnie gdy sprzedaż regularnie się zmienia.

Ten sam cykl powinien obejmować nietypowe potrącenia, ujemne salda, zatrzymane rezerwy, duże zwroty i różnice między oczekiwaną a faktyczną wypłatą. Nie każda rozbieżność wymaga natychmiastowego zapisu w KPiR, ale każda powinna otrzymać status i osobę odpowiedzialną za wyjaśnienie. Dobrą praktyką pozostaje prowadzenie rejestru otwartych różnic z informacją o kanale, okresie, kwocie, prawdopodobnej przyczynie oraz terminie rozwiązania. Dzięki temu nierozpoznane potrącenie nie znika w kolejnym raporcie, a zamknięcie miesiąca nie zaczyna się od ponownego poszukiwania problemów wykrytych kilka tygodni wcześniej.

Po zakończeniu miesiąca: uzgadniaj sumy

Po zamknięciu miesiąca należy porównać sprzedaż według kanałów z dokumentami stanowiącymi podstawę zapisów oraz z wartościami ujętymi w KPiR. Uzgodnienie powinno uwzględniać faktury, raporty fiskalne, właściwe zestawienia sprzedaży, zwroty, korekty i anulacje. Nie wystarczy stwierdzić, że łączna suma jest zbliżona do oczekiwanego poziomu. Firma powinna potrafić wykazać, z jakich dokumentów powstała wartość przychodu, które transakcje wyłączono z raportów zbiorczych oraz dlaczego korekty pojawiły się w danym okresie. W przypadku sprzedaży zagranicznej potrzebna jest również kontrola walut, sposobu przeliczenia i oznaczenia właściwego modelu rozliczenia podatku.

Kolejną warstwą jest uzgodnienie rozliczeń z platformami. Wartość sprzedaży trzeba zestawić ze zwrotami, prowizjami, fakturami za reklamę i logistykę, rezerwami oraz payoutami. Celem nie jest doprowadzenie do prostego zrównania przychodu z przelewem, lecz wyjaśnienie wszystkich elementów różnicy. Otwarte pozycje powinny zostać przeniesione do kolejnego okresu z czytelnym opisem, zamiast znikać w zbiorczej kwocie. Miesięczne zamknięcie jest zakończone dopiero wtedy, gdy dane z kanałów, dokumenty, KPiR i przepływy finansowe tworzą spójny obraz, a każda istotna rozbieżność została rozwiązana albo formalnie oznaczona jako oczekująca.

Przed wygenerowaniem oraz wysłaniem JPK_PKPIR przeprowadź kontrolę końcową

Przed wygenerowaniem oraz wysłaniem JPK_PKPIR trzeba upewnić się, że księga obejmuje komplet dokumentów za cały raportowany rok i nie zawiera zapisów powielonych przez faktury, raporty fiskalne, zestawienia zbiorcze lub integracje. Kontrola powinna objąć prawidłowość dat, numerów dokumentów, opisów zdarzeń, wartości przychodów i kosztów oraz korekt dokonanych po zamknięciu poszczególnych miesięcy. Szczególnej uwagi wymagają transakcje z przełomu roku, zwroty ujęte w późniejszym okresie, dokumenty w walutach obcych oraz pozycje, których sposób rozliczenia zmieniał się w trakcie roku. Warto również potwierdzić, że wszystkie korekty wprowadzone do ewidencji pomocniczych znalazły odzwierciedlenie w KPiR.

Samo wygenerowanie technicznie poprawnego pliku nie powinno kończyć kontroli. Między utworzeniem JPK_PKPIR a jego wysłaniem mogą zostać wykryte brakujące dokumenty, korekty albo różnice wymagające zmiany zapisów w księdze. Po każdej istotnej zmianie plik powinien zostać wygenerowany ponownie z aktualnych danych, a jego wartości kontrolne trzeba porównać z ostateczną wersją KPiR. Firma powinna również zadbać, aby wysłany plik odpowiadał dokładnie tej wersji księgi, która została zatwierdzona po zakończeniu kontroli, a nie wcześniejszemu eksportowi pozostawionemu w folderze roboczym.

Najważniejszym testem pozostaje możliwość odtworzenia źródła każdego zapisu. Dla pojedynczej faktury ścieżka powinna prowadzić do zamówienia i dokumentu, a dla wartości zbiorczej do zestawienia zawierającego transakcje składające się na sumę. Dokumenty kosztowe muszą być powiązane z rzeczywistymi usługami i potrąceniami, natomiast payouty z pełnym rozliczeniem sprzedaży, korekt, opłat i rezerw. JPK_PKPIR jest elektronicznym odzwierciedleniem KPiR, dlatego kontrola samego pliku nie zastąpi weryfikacji księgi i danych źródłowych. Jeżeli kwoty są formalnie poprawne, ale nie można wyjaśnić sposobu ich obliczenia, proces nadal nie zapewnia wystarczającej spójności.

Czy proces jest gotowy do JPK_PKPIR?

Poniższa checklista pozwala szybko ocenić, czy dane sprzedażowe, dokumenty i zapisy księgowe tworzą spójny proces. Każda odpowiedź negatywna wskazuje obszar, który warto wyjaśnić przed zatwierdzeniem KPiR i wysłaniem JPK_PKPIR.

• Każdy aktywny kanał sprzedaży ma przypisany właściwy dokument źródłowy.
• Wiadomo, które raporty stanowią podstawę zapisu, a które służą wyłącznie do kontroli.
• Sprzedaż udokumentowana fakturami została wyłączona z odpowiednich zapisów zbiorczych.
• Sprzedaż fiskalna nie została ponownie ujęta na podstawie faktur wystawionych do paragonów.
• Nie ma transakcji zaksięgowanych dwukrotnie przez różne raporty, integracje lub systemy.
• Anulowane zamówienia zostały wyłączone albo odpowiednio skorygowane, zależnie od etapu realizacji.
• Zwroty są powiązane z pierwotnymi zamówieniami i dokumentami sprzedaży.
• Korekty sprzedaży zagranicznej zostały przypisane do właściwego systemu rozliczeń podatku.
• Prowizje, reklama, logistyka i pozostałe koszty mają odpowiednie dokumenty.
• Usługi zagranicznych operatorów zostały sprawdzone pod kątem importu usług.
• Potrącenia widoczne w payoutach zostały wyjaśnione i przypisane do właściwych kategorii.
• Każdy payout został uzgodniony ze sprzedażą, zwrotami, kosztami, rezerwami i innymi rozliczeniami.
• Wszystkie raporty źródłowe, dokumenty i wersje przetworzonych zestawień zostały zarchiwizowane.
• Integracje oraz połączenia API zostały sprawdzone pod kątem brakujących lub powielonych danych.
• Otwarte różnice mają przypisany status, właściciela i termin wyjaśnienia.
• Dane z ewidencji pomocniczych są zgodne z ostateczną wersją KPiR.
• Plik JPK_PKPIR został wygenerowany ponownie po ostatnich korektach księgi.
• Można odtworzyć źródło, dokumentację i sposób obliczenia każdego zapisu.
• Co się stanie, jeśli nie przygotujesz spójnej ewidencji?

Brak spójnej ewidencji rzadko ujawnia się jako jeden łatwy do poprawienia błąd. Zwykle przez kilka miesięcy narastają drobne różnice: pojedyncze zamówienia nie trafiają do zestawienia, część faktur zostaje ujęta ponownie w raporcie zbiorczym, prowizje są potrącane bez powiązania z dokumentami, a zwroty pojawiają się w innym okresie niż pierwotna sprzedaż. Dopóki skala działalności pozostaje niewielka, takie rozbieżności można próbować wyjaśniać ręcznie. W średniej firmie e-commerce, która działa na kilku rynkach i obsługuje tysiące transakcji, ten model szybko przestaje być bezpieczny. Błąd dotyczący nawet niewielkiego odsetka zamówień może przełożyć się na istotną kwotę w skali miesiąca lub roku, szczególnie gdy ten sam problem występuje równolegle w kilku kanałach.

Konsekwencją nie musi być od razu kontrola podatkowa. Często pierwszym sygnałem są przedłużające się zamknięcia miesiąca, brak możliwości uzgodnienia payoutów, rosnąca liczba ręcznych korekt i sprzeczne informacje pochodzące z różnych systemów. Księgowość dysponuje inną wartością sprzedaży niż dział finansowy, zespół operacyjny opiera się na raporcie zamówień, a rachunek bankowy pokazuje jeszcze inną kwotę. Firma może przez długi czas działać z takim rozdźwiękiem, ale przygotowanie JPK_PKPIR wymusza uporządkowanie danych znajdujących się w KPiR. Jeżeli nie można wyjaśnić, jak z raportów źródłowych powstała konkretna wartość w księdze, sam eksport poprawnego technicznie pliku nie usuwa problemu.

Co się stanie, jeśli nie przygotujesz spójnej ewidencji?

Błędny JPK będzie tylko objawem większego problemu

JPK_PKPIR powstaje na podstawie danych ujętych wcześniej w KPiR. Jeżeli księga zawiera pominięte transakcje, duplikaty, niewłaściwe daty albo wartości powstałe przez zaksięgowanie payoutów zamiast dokumentów sprzedaży, problemy te mogą zostać przeniesione do pliku. Walidacja techniczna sprawdza strukturę i format danych, ale nie potwierdza, że przedsiębiorca ujął każdą sprzedaż dokładnie raz, prawidłowo rozliczył zwroty ani posiada dokumenty dla kosztów pobranych przez platformy. Plik może więc przejść kontrolę techniczną, mimo że jego zawartość odzwierciedla błędnie prowadzoną księgę.

Samo poprawienie JPK_PKPIR może okazać się niewystarczające, ponieważ źródłem problemu nie jest wówczas plik, lecz KPiR oraz dane, na podstawie których ją prowadzono. Najpierw trzeba ustalić, które zapisy wymagają zmiany, odnaleźć dokumenty źródłowe, skorygować ewidencje pomocnicze i sprawdzić wpływ poprawek na rozliczenie roczne. Dopiero z poprawionej księgi można wygenerować właściwą wersję JPK_PKPIR. Jeżeli błąd wpłynął również na zeznanie PIT, zaliczki lub inne rozliczenia, konieczna może być analiza szerszego zakresu korekt. Próba ręcznego zmienienia wyłącznie wartości w pliku stworzyłaby kolejną niespójność, ponieważ wysłany JPK nie odpowiadałby księdze, którą ma odzwierciedlać.

Możesz wykazać zbyt niski przychód

Zaniżenie przychodu często wynika z księgowania kwot wypłacanych przez marketplace zamiast pełnej wartości sprzedaży wynikającej z właściwych dokumentów. Jeżeli platforma potrąci prowizję, koszty reklamy, opłaty logistyczne i inne należności, na rachunek trafia kwota niższa niż wartość transakcji z klientami. Potraktowanie payoutu jako sprzedaży powoduje, że część przychodu znika z ewidencji, a koszty platformy nie są wykazane jako odrębne zdarzenia. Podobny efekt może powstać, gdy firma uwzględnia tylko kanały obsługiwane przez główną integrację, natomiast sprzedaż z mniejszego marketplace’u, kanału hurtowego albo zagranicznego konta nie trafia do zestawienia przekazywanego księgowości.

Pominięcia zdarzają się również wtedy, gdy raport obejmuje wyłącznie zamówienia posiadające określony status, integracja API nie pobrała danych z części okresu albo wartości w obcej walucie zostały odrzucone podczas importu. Jeżeli zaniżony przychód wpłynie na wysokość podatku, może powstać konieczność skorygowania księgi, JPK_PKPIR, zeznania podatkowego lub innych rozliczeń, zgodnie z przepisami Ordynacji podatkowej oraz właściwych ustaw podatkowych. Może być również konieczne uregulowanie brakującej kwoty wraz z należnymi odsetkami. Im później problem zostanie wykryty, tym większy zakres danych trzeba przeanalizować. Kompletność kanałów powinna być więc kontrolowana nie tylko przez porównanie końcowych sum, lecz także przez sprawdzenie, czy każdy aktywny marketplace przekazał pełny zestaw raportów za dany okres.

Możesz zapłacić podatek od zawyżonego przychodu

Brak spójności nie zawsze działa na korzyść przedsiębiorcy. Przychód może zostać również zawyżony, przede wszystkim przez podwójne ujęcie tych samych transakcji. Typowym przykładem jest sprzedaż zaksięgowana najpierw na podstawie faktury, a następnie ponownie w zbiorczym zestawieniu marketplace’u. Jeżeli dodatkowo jako przychód zostanie potraktowany payout, jedna transakcja może zwiększyć wartość w KPiR nawet kilka razy. Podobne ryzyko powstaje przy fakturach wystawionych do sprzedaży zarejestrowanej wcześniej na kasie oraz przy integracjach, które przekazują dokumenty do księgowości niezależnie od ręcznie przygotowanych raportów.

Przychód może być zawyżony także przez nieuwzględnienie prawidłowo udokumentowanych zwrotów, anulacji i korekt. Raport sprzedaży pokazuje pierwotne zamówienie, ale informacja o późniejszym zwrocie pozostaje w innym pliku albo pojawia się dopiero przy kolejnej wypłacie. Jeżeli oba źródła nie zostaną połączone, KPiR może nadal zawierać pełną wartość sprzedaży, mimo że transakcja została częściowo lub całkowicie skorygowana. Przedsiębiorca może w rezultacie zapłacić podatek od kwoty wyższej niż prawidłowo ustalony dochód. Odzyskanie nadpłaty wymaga wówczas odtworzenia dokumentacji i skorygowania właściwych zapisów, co po wielu miesiącach może być znacznie bardziej pracochłonne niż bieżące powiązanie zwrotu z pierwotną sprzedażą.

Możesz mieć problem z obroną zapisów podczas kontroli

Podczas weryfikacji rozliczeń ważna jest nie tylko końcowa kwota, lecz także możliwość wykazania, z czego ona wynika. Jeżeli w KPiR znajduje się zbiorczy zapis sprzedaży, przedsiębiorca powinien potrafić wskazać dokument będący podstawą jego ujęcia oraz dane pozwalające odtworzyć transakcje składające się na sumę. Sam arkusz zawierający ręcznie wpisaną wartość może nie wystarczyć, jeżeli nie wiadomo, z jakiego raportu powstał, które pozycje zostały wyłączone, jak rozliczono faktury ani czy uwzględniono anulacje. Brak dokumentów źródłowych utrudnia także wyjaśnienie kosztów, szczególnie gdy prowizje, reklama i logistyka zostały zaksięgowane jako jedna zbiorcza różnica między sprzedażą a wypłatą.

Rozbieżności pomiędzy KPiR, raportami platform i rachunkiem bankowym nie zawsze oznaczają nieprawidłowość. Payout może obejmować inny okres, część pieniędzy może pozostawać w rezerwie, a zwrot może zostać potrącony później. Firma musi jednak umieć przedstawić logiczne uzgodnienie tych różnic. Jeżeli tylko jedna osoba zna sposób przygotowania zestawienia, ale nie zachowano raportów, reguł przekształcenia ani identyfikatorów transakcji, odejście pracownika albo zmiana biura księgowego może pozbawić firmę możliwości odtworzenia procesu. Dobrze udokumentowana ścieżka zapisu ogranicza takie ryzyko, ponieważ wyjaśnienie kwoty nie zależy od pamięci konkretnej osoby.

Porządkowanie danych po wielu miesiącach może być znacznie trudniejsze

Dane dostępne w panelu marketplace’u nie zawsze pozostają niezmienne. Status zamówienia może zostać zaktualizowany po zwrocie, raport pobrany później może zawierać korektę, a platforma może zmienić format kolumn lub sposób oznaczania transakcji. Część raportów jest dostępna tylko przez określony czas, a szczegółowe dane mogą wymagać osobnego wygenerowania. Jeżeli firma nie archiwizuje plików użytych do księgowania, po wielu miesiącach może posiadać jedynie aktualną wersję raportu, która nie odpowiada informacjom dostępnym w chwili dokonania zapisu. Odtworzenie różnicy wymaga wtedy porównania kilku wersji danych i ustalenia, które zmiany były wynikiem zwrotów, a które błędów lub aktualizacji systemu.

Najbardziej czasochłonne jest ręczne odtwarzanie setek lub tysięcy transakcji bez wspólnych identyfikatorów. Trzeba wówczas dopasowywać zamówienia do faktur na podstawie kwot, dat i danych klientów, oddzielać sprzedaż od wypłat oraz szukać dokumentów prowizyjnych w wielu częściach panelu. Przy sprzedaży zagranicznej dochodzą waluty, różne modele VAT oraz korekty przypisane do procedury OSS lub lokalnych rejestracji. Koszt uporządkowania danych może być znacznie wyższy niż koszt bieżącej kontroli, a jednocześnie firma traci czas w okresie, w którym powinna koncentrować się na rozwoju. Spójna ewidencja nie eliminuje wszystkich korekt, ale sprawia, że każdą z nich można szybko przypisać do dokumentu, transakcji i właściwego okresu.

Największym ryzykiem nie jest sam błąd techniczny w pliku JPK. Jest nim brak możliwości wykazania, skąd wzięła się konkretna kwota w KPiR.

Praktyczny model spójnej ewidencji krok po kroku

Budowa spójnego procesu nie wymaga, aby wszystkie marketplace’y korzystały z identycznych raportów albo żeby każda transakcja była rozliczana w taki sam sposób. Sprzedaż krajowa, eksportowa, B2B, B2C, objęta OSS albo lokalnym VAT może podlegać różnym zasadom. Wspólny powinien być natomiast sposób zarządzania informacją: każda transakcja ma określone źródło, dokument, identyfikator, status i miejsce w procesie księgowym. Firma musi również wiedzieć, które dane służą do dokonania zapisu, a które jedynie do jego kontroli i uzgodnienia z przepływem pieniędzy.

Poniższy model można zastosować zarówno przy porządkowaniu istniejącej sprzedaży, jak i przed uruchomieniem kolejnego marketplace’u. Nie jest to jednorazowe zadanie wykonywane wyłącznie na potrzeby JPK_PKPIR. To schemat kontroli wewnętrznej, który powinien działać przez cały rok i rozwijać się razem z firmą. Każdy nowy kanał należy włączyć do tego samego procesu, z uwzględnieniem właściwych zasad dokumentowania i opodatkowania.

Model w dziesięciu krokach

1. Spisz wszystkie kanały sprzedaży. Uwzględnij marketplace’y, własne sklepy, sprzedaż hurtową, punkty stacjonarne i dodatkowe systemy, w których powstają zamówienia lub dokumenty. Dla każdego kanału określ kraje sprzedaży, waluty, rodzaje klientów, sposób obsługi płatności i model rozliczeń podatkowych.
2. Określ sposób dokumentowania każdego rodzaju transakcji. Ustal, które sprzedaże są ujmowane na podstawie faktur, raportów fiskalnych, dziennych dowodów wewnętrznych albo właściwych zestawień. Sprawdź również, jak dokumentowane są zwroty, korekty, prowizje i pozostałe usługi platform.
3. Ustal jednolity zakres danych pobieranych z marketplace’ów. Każdy kanał powinien dostarczać między innymi datę transakcji, identyfikator zamówienia, numer dokumentu, wartość, walutę, kraj opodatkowania, status, informację o zwrocie oraz identyfikatory płatności i rozliczeń. Przy sprzedaży zagranicznej oznacz sposób rozliczenia, na przykład OSS, lokalny VAT, eksport lub WDT.
4. Oddziel sprzedaż od wypłat i kosztów platform. Przychód ustalaj na podstawie właściwych dokumentów i zasad podatkowych, a payout wykorzystuj do uzgodnienia rozrachunków. Prowizje, reklamy, logistykę i pozostałe opłaty przypisuj do odpowiednich dokumentów kosztowych zamiast pomniejszać nimi automatycznie wartość sprzedaży.
5. Oznacz transakcje fakturowane, aby uniknąć duplikatów. Powiąż fakturę z numerem zamówienia i identyfikatorem transakcji marketplace’u. Przed przygotowaniem zapisu zbiorczego wyłącz sprzedaż ujętą już na podstawie faktur lub raportów fiskalnych, zachowując informację o zakresie i przyczynie wyłączenia.
6. Prowadź ewidencje pomocnicze dla poszczególnych kanałów. Zachowaj szczegółowość pozwalającą przejść od sumy do pojedynczego zamówienia, dokumentu i korekty. Osobne zestawienia powinny wspierać jedną KPiR, a nie tworzyć niezależne, niemożliwe do uzgodnienia obiegi danych.
7. Przenoś prawidłowo zweryfikowane dane do jednej KPiR. Każdy zapis powinien mieć czytelny opis, właściwą datę i dokument źródłowy. Dla wartości zbiorczych zachowaj zestawienie pozycji składających się na sumę, a dla dokumentów indywidualnych połączenie z zamówieniem i kanałem sprzedaży.
8. Regularnie uzgadniaj sprzedaż, zwroty, koszty i wypłaty. Kontroluj dokumenty na bieżąco, kompletność kanałów co najmniej raz w tygodniu i pełne rozliczenie po zakończeniu miesiąca. Prowadź rejestr otwartych różnic, w którym każda nierozpoznana kwota ma opis, osobę odpowiedzialną i termin wyjaśnienia.
9. Archiwizuj dokumenty oraz raporty źródłowe. Zachowuj oryginalne pliki, wersje przetworzone wraz z opisem wykonanych zmian i końcowe zestawienia wykorzystane do księgowania. Oznaczaj datę pobrania, kanał, okres i status pliku, aby po kilku miesiącach było wiadomo, która wersja stanowiła podstawę zapisu.
10. Generuj JPK_PKPIR dopiero z zamkniętej i sprawdzonej księgi. Przed wysłaniem potwierdź kompletność dokumentów, brak duplikatów, prawidłowość korekt oraz zgodność ewidencji pomocniczych z KPiR. Jeżeli po wygenerowaniu pliku zostaną wprowadzone zmiany do księgi, przygotuj nowy eksport z aktualnych danych. Po każdej zmianie zapisów w KPiR należy ocenić, czy wcześniej wygenerowany plik nadal odpowiada aktualnej treści księgi. Wysłana wersja JPK_PKPIR powinna być zgodna z ostatecznie zatwierdzoną ewidencją, a nie z wcześniejszym eksportem pozostawionym w folderze roboczym.

Po czym poznać, że model rzeczywiście działa?

Dobrze zaprojektowany proces nie polega na tym, że wszystkie raporty pokazują identyczne kwoty. Sprzedaż, dokumenty, payouty i przepływy bankowe opisują różne etapy rozliczenia, dlatego między nimi mogą występować uzasadnione różnice. Model działa wtedy, gdy każdą różnicę można wyjaśnić. Firma wie, jaka część wynika z prowizji, jaka ze zwrotów, jaka z rezerw, a jaka z przesunięcia między okresami. Potrafi także wskazać, które dokumenty stanowiły podstawę zapisów i dlaczego określone transakcje zostały wyłączone z raportów zbiorczych.

Drugim testem jest możliwość przekazania procesu innej osobie bez utraty wiedzy. Nowy pracownik, księgowy albo kontroler powinien na podstawie dokumentacji odtworzyć drogę od zamówienia do KPiR, a następnie do JPK_PKPIR. Jeżeli wyjaśnienie kwoty wymaga obecności osoby, która ręcznie przygotowała arkusz kilka miesięcy wcześniej, system nadal jest zbyt zależny od pamięci i nieformalnych ustaleń. Spójna ewidencja jest gotowa do skalowania dopiero wtedy, gdy kolejne kanały można dołączyć do istniejącego standardu, a wzrost liczby zamówień nie powoduje proporcjonalnego wzrostu liczby ręcznych korekt.

Najczęstsze błędy w ewidencji sprzedaży wielokanałowej

Większość problemów nie wynika z jednego poważnego zaniedbania, lecz z powtarzających się uproszczeń stosowanych przy codziennej pracy. Księgowanie wartości wypłaty zamiast sprzedaży, pozostawienie faktur w raporcie zbiorczym albo ręczna zmiana pliku bez zachowania pierwotnej wersji mogą początkowo wyglądać jak sposób na przyspieszenie zamknięcia miesiąca. Przy rosnącej skali działania każde takie uproszczenie utrudnia jednak uzgodnienie danych i zwiększa zależność od wiedzy pojedynczych osób. Poniższe zestawienie pokazuje błędy, które najczęściej zaburzają spójność KPiR i późniejszego JPK_PKPIR.

• Księgowanie payoutu jako wartości sprzedaży Zaniżenie przychodu i połączenie sprzedaży, kosztów oraz zwrotów w jednej kwocie
• Brak wyłączenia faktur z raportu zbiorczego Podwójne ujęcie tej samej sprzedaży
• Ponowne księgowanie faktury wystawionej do sprzedaży fiskalnej Zawyżenie przychodu ujętego wcześniej w raporcie z kasy
• Brak dokumentów dotyczących prowizji i opłat Nieprawidłowe albo niemożliwe do obrony ujęcie kosztów
• Traktowanie wszystkich potrąceń jako jednej prowizji Błędna klasyfikacja kosztów i brak możliwości wyjaśnienia payoutu
• Brak identyfikatorów zamówień, transakcji i rozliczeń Utrata możliwości połączenia raportu z dokumentem i zapisem w KPiR
• Brak powiązania zwrotu z pierwotną sprzedażą Korekta niewłaściwego okresu lub niewłaściwego dokumentu
• Pozostawienie anulowanych zamówień w raporcie sprzedaży Zawyżenie wartości przychodu
• Brak kontroli integracji API Pominięcie albo powielenie części transakcji
• Brak archiwizacji raportów źródłowych Problem z odtworzeniem danych podczas kontroli lub późniejszej korekty
• Nadpisywanie raportów po ręcznych zmianach Utrata informacji o danych pierwotnych i wykonanych przekształceniach
• Księgowanie na podstawie raportu zarządczego Ujęcie wartości przygotowanych do analizy biznesowej zamiast właściwych danych księgowych
• Brak rozdzielenia sprzedaży krajowej i zagranicznej Ryzyko przypisania transakcji do niewłaściwego modelu rozliczenia podatku
• Brak rejestru otwartych różnic Przenoszenie niewyjaśnionych potrąceń i rozbieżności do kolejnych okresów
• Ręczne poprawianie końcowych sum bez korekty danych źródłowych Powracające błędy i utrata pełnej ścieżki audytu
• Wysłanie pliku wygenerowanego przed ostatnią korektą KPiR Niezgodność JPK_PKPIR z aktualną treścią księgi

Zestawienie warto wykorzystywać podczas miesięcznego zamknięcia oraz przy wdrażaniu nowego marketplace’u. Pojawienie się pojedynczego błędu nie musi oznaczać, że cały proces jest nieprawidłowy, ale powinno prowadzić do sprawdzenia, czy problem ma charakter jednostkowy, czy wynika z reguły stosowanej do większej liczby transakcji. Najbardziej niebezpieczne są błędy powtarzalne, ponieważ przy dużym wolumenie mogą wpływać na tysiące zamówień, a jednocześnie pozostawać niewidoczne w zwykłym porównaniu miesięcznych sum. Spójny proces powinien nie tylko wykrywać ich skutki, lecz przede wszystkim usuwać przyczynę na poziomie źródła danych, integracji albo sposobu dokumentowania sprzedaży.

Przykład: trzy kanały sprzedaży w jednej KPiR

Załóżmy, że polska firma e-commerce prowadzi sprzedaż w trzech kanałach. Marketplace A obsługuje przede wszystkim konsumentów, którzy nie otrzymują indywidualnych faktur, a sprzedaż może być ujmowana w odpowiednim zestawieniu, jeżeli taki sposób dokumentowania jest dopuszczalny. Marketplace B obejmuje zarówno transakcje B2B dokumentowane fakturami, jak i sprzedaż B2C bez indywidualnych faktur. Trzecim kanałem jest własny sklep internetowy, w którym sprzedaż jest ewidencjonowana przy zastosowaniu kasy fiskalnej. Każdy kanał udostępnia inne raporty, korzysta z innego sposobu identyfikowania zamówień i rozlicza pieniądze według własnego harmonogramu. Mimo tych różnic firma nie prowadzi trzech osobnych ksiąg. Dane ze wszystkich kanałów muszą zostać uporządkowane, zweryfikowane i ujęte w jednej KPiR.

Przykład ma pokazać mechanizm przepływu informacji, dlatego wartości są uproszczone. W praktyce sposób ujęcia poszczególnych kwot będzie zależał między innymi od statusu podatnika VAT, rodzaju transakcji, miejsca opodatkowania i zastosowanej procedury. Wartość sprzedaży brutto widoczna w raportach handlowych nie zawsze będzie identyczna z przychodem wpisywanym do KPiR. Istotne jest jednak zachowanie logiki procesu: sprzedaż dokumentuje się na podstawie właściwych dowodów, faktury oddziela się od wartości zbiorczych, prowizje rozlicza jako osobne koszty, a wypłaty z platform wykorzystuje do uzgodnienia przepływów pieniężnych.

Marketplace A: sprzedaż B2C bez indywidualnych faktur

Marketplace A wygenerował w danym miesiącu sprzedaż o wartości handlowej 180 000 zł. Większość zamówień pochodziła od konsumentów, do których nie wystawiono indywidualnych faktur, a firma nie ujmowała tej sprzedaży w raportach fiskalnych. Jeżeli spełnione są warunki pozwalające na taki sposób dokumentowania, transakcje mogą zostać objęte właściwym zestawieniem sprzedaży nieudokumentowanej fakturami ani raportami z kasy. Raport zamówień pobrany z platformy nie powinien zostać automatycznie zaksięgowany. Najpierw trzeba wyłączyć anulowane pozycje, powiązać zwroty z pierwotnymi zamówieniami, sprawdzić daty uzyskania przychodów oraz potwierdzić, że żadna transakcja nie otrzymała indywidualnej faktury w innym systemie.

Do ewidencji pomocniczej trafiają numery zamówień, identyfikatory transakcji, daty sprzedaży, wartości, waluty, statusy, informacje o zwrotach i oznaczenia dokumentów. Na tej podstawie powstaje zestawienie stanowiące podstawę ujęcia sprzedaży w KPiR. Firma zachowuje przy tym raport źródłowy, wersję po wyłączeniu anulacji i faktur oraz informację o wykonanych przekształceniach. Marketplace wypłacił przedsiębiorcy kwotę niższą niż wartość sprzedaży, ponieważ potrącił prowizje, zwroty i pozostałe opłaty. Payout nie zastępuje jednak zestawienia sprzedaży. Służy do sprawdzenia, czy wartość sprzedaży, korekt, kosztów i zatrzymanych środków prowadzi do kwoty przekazanej na rachunek.

Marketplace B: sprzedaż B2B i B2C w jednym raporcie

Marketplace B wykazał sprzedaż o łącznej wartości handlowej 120 000 zł. Z tej kwoty 40 000 zł dotyczyło klientów biznesowych, dla których wystawiono faktury, natomiast 80 000 zł obejmowało sprzedaż B2C bez indywidualnych faktur. Raport pobrany z platformy pokazuje wszystkie zamówienia razem, dlatego jego końcowa suma nie może bezpośrednio stać się podstawą jednego wpisu zbiorczego. Najpierw trzeba połączyć raport z rejestrem faktur za pomocą numerów zamówień, identyfikatorów transakcji i numerów dokumentów. Każda pozycja udokumentowana fakturą otrzymuje oznaczenie wykluczające ją z części raportu przeznaczonej do ustalenia sprzedaży niefakturowanej.

Faktury B2B są ujmowane zgodnie z zasadami właściwymi dla dokumentów indywidualnych. Pozostała sprzedaż B2C może trafić do odpowiedniego zestawienia, jeżeli spełnione są warunki jego stosowania. Firma nie usuwa fakturowanych zamówień z raportu źródłowego, lecz zachowuje wersję przetworzoną, w której widoczny jest zakres wyłączeń. Dzięki temu 40 000 zł sprzedaży B2B nie zostaje ponownie uwzględnione w zbiorczej wartości 80 000 zł. Taka kontrola jest potrzebna również wtedy, gdy faktury są wystawiane przez rozwiązanie działające poza marketplace’em albo w ramach samofakturowania, ponieważ sam status klienta biznesowego nie potwierdza jeszcze, że dokument rzeczywiście powstał i trafił do księgowości.

Własny sklep: sprzedaż rejestrowana na kasie fiskalnej

Własny sklep internetowy wygenerował w tym samym miesiącu sprzedaż o wartości handlowej 70 000 zł, która została zarejestrowana na kasie fiskalnej. Podstawą ujęcia tej sprzedaży w KPiR są właściwe raporty fiskalne, a nie raport zamówień ze sklepu ani suma przelewów przekazana przez operatora płatności. Dane z systemu sklepowego pozostają jednak potrzebne do kontroli. Pozwalają sprawdzić, czy wszystkie zrealizowane zamówienia zostały zafiskalizowane, czy anulowane transakcje nie trafiły do raportu oraz czy zwroty zostały odpowiednio udokumentowane i powiązane z pierwotną sprzedażą. System powinien również wskazywać, do których transakcji wystawiono później faktury.

Jeżeli faktura została wystawiona do sprzedaży ujętej wcześniej na kasie, nie powoduje ona ponownego rozpoznania przychodu w KPiR. Firma musi więc oznaczać takie dokumenty w sposób odróżniający je od faktur stanowiących samodzielną podstawę zapisu. W przeciwnym razie raport fiskalny może zostać zaksięgowany jako sprzedaż zbiorcza, a faktura zaimportowana osobno z systemu dokumentowego, co zawyży przychód. Ewidencja pomocnicza sklepu powinna łączyć numer zamówienia, numer paragonu, numer ewentualnej faktury, status zwrotu oraz identyfikator płatności. Dzięki temu raport z kasy pozostaje dokumentem źródłowym, natomiast dane ze sklepu służą do kontroli kompletności i wyjaśniania różnic.

Jak dane z trzech kanałów trafiają do jednej KPiR?

Po zakończeniu miesiąca firma dysponuje trzema odmiennymi zestawami dokumentów. Marketplace A dostarcza dane wykorzystane do przygotowania zestawienia sprzedaży B2C, marketplace B generuje faktury B2B i dane do odrębnego zestawienia sprzedaży B2C, natomiast własny sklep przekazuje raporty fiskalne. W uproszczonym przykładzie wartości handlowe wynoszą 180 000 zł dla marketplace’u A, 40 000 zł sprzedaży fakturowanej i 80 000 zł pozostałej sprzedaży dla marketplace’u B oraz 70 000 zł sprzedaży fiskalnej we własnym sklepie. Łączna sprzedaż przed uwzględnieniem właściwych korekt wynosi więc 370 000 zł. Nie oznacza to jednak jednego wpisu o tej wartości ani automatycznego ujęcia dokładnie takiej kwoty w kolumnie przychodowej KPiR.

Każda część trafia do księgi na podstawie właściwego dokumentu i zgodnie z zasadami podatkowymi. Faktury są ujmowane indywidualnie, sprzedaż niefakturowana na podstawie odpowiednich zestawień, a sprzedaż fiskalna na podstawie raportów z kasy. Jeżeli przedsiębiorca jest czynnym podatnikiem VAT, wartości przychodów w KPiR są ustalane z uwzględnieniem zasad dotyczących należnego podatku. Przy sprzedaży zagranicznej znaczenie mogą mieć również waluty, OSS, lokalne rejestracje VAT, eksport lub WDT. Wspólna KPiR nie oznacza zatem mechanicznego zsumowania wszystkich raportów. Oznacza ujęcie danych ze wszystkich kanałów w jednej księdze, przy zachowaniu właściwych dokumentów, dat i sposobów rozliczenia.

Jak księgowane są prowizje i pozostałe koszty?

Marketplace A i marketplace B pobierają prowizje, opłaty za reklamę, obsługę płatności oraz wybrane usługi logistyczne. Kwoty te są widoczne w raportach rozliczeniowych i pomniejszają payouty, ale firma księguje je oddzielnie od sprzedaży. Dla każdego dokumentu sprawdza wystawcę, nabywcę, okres, walutę i rodzaj usługi. Prowizja od sprzedaży nie jest łączona z opłatą reklamową tylko dlatego, że obie pozycje zostały potrącone z tej samej wypłaty. Podobnie usługa magazynowania, dostawa do klienta i transport towaru do magazynu operatora mogą mieć inny charakter gospodarczy i wymagać osobnej klasyfikacji.

Raport rozliczeniowy służy do uzgodnienia kosztów z wypłatą, ale zapis w KPiR powstaje na podstawie właściwego dokumentu. Firma porównuje więc faktury operatora z potrąceniami i ustala, czy żadna opłata nie została pominięta lub zaksięgowana dwa razy. W przypadku zagranicznego usługodawcy sprawdza również obowiązki związane z importem usług. Dopiero po rozdzieleniu sprzedaży, zwrotów, kosztów i rezerw można wyjaśnić, dlaczego suma pieniędzy przekazana przez marketplace różni się od wartości zamówień. Payout zamyka uzgodnienie finansowe, ale nie zastępuje dokumentów przychodowych ani kosztowych.

Jak ten proces zostaje odwzorowany w JPK_PKPIR?

Po zakończeniu weryfikacji wszystkie prawidłowe zapisy znajdują się w jednej KPiR. Księga obejmuje faktury z marketplace’u B, wartości wynikające z zestawień sprzedaży dla marketplace’ów A i B, raporty fiskalne własnego sklepu oraz dokumenty kosztowe dotyczące prowizji, reklamy, logistyki i pozostałych usług. Każdy wpis posiada opis wskazujący kanał, rodzaj dokumentu, okres i źródło danych. Ewidencje pomocnicze umożliwiają przejście od wartości zbiorczej do pojedynczych zamówień, a archiwum zawiera raporty źródłowe oraz informacje o wykonanych przekształceniach.

JPK_PKPIR odzwierciedla dane znajdujące się w tej księdze. Nie pokazuje odrębnej „księgi marketplace’u A”, „księgi marketplace’u B” i „księgi sklepu”, ponieważ wszystkie kanały należą do tej samej działalności. Nie zastępuje też raportów źródłowych ani ewidencji pomocniczych. Jego poprawność zależy od tego, czy wcześniej prawidłowo sklasyfikowano transakcje, wyeliminowano duplikaty, rozliczono zwroty i ujęto koszty na podstawie właściwych dokumentów. W praktyce plik jest ostatnim etapem procesu, który zaczyna się znacznie wcześniej: w chwili zarejestrowania zamówienia i przypisania mu odpowiedniego sposobu dokumentowania.

Najczęstsze błędy sprzedawców korzystających z kilku marketplace’ów

Większość problemów w sprzedaży wielokanałowej nie wynika z nieznajomości pojedynczego przepisu, lecz z braku wspólnego procesu dla wszystkich kanałów. Każda platforma jest obsługiwana osobno, raporty trafiają do różnych osób, a księgowość otrzymuje dane w kilku formatach i terminach. Dopóki firma prowadzi niewielką sprzedaż, rozbieżności można poprawiać ręcznie. Przy większym wolumenie te same skróty organizacyjne zaczynają powodować powtarzalne błędy, które wpływają na przychody, koszty, zamknięcie miesiąca i późniejsze przygotowanie JPK_PKPIR.

Najbardziej ryzykowne są błędy systemowe, czyli wynikające z reguły stosowanej do całego kanału. Jeżeli firma księguje payout zamiast sprzedaży, problem dotyczy każdej wypłaty. Jeżeli raport zbiorczy nie wyłącza faktur, podwójnie może zostać ujęta znaczna część transakcji B2B. Dlatego kontrola nie powinna kończyć się na znalezieniu pojedynczej nieprawidłowej pozycji. Trzeba sprawdzić, czy podobny mechanizm nie występuje w całym okresie lub na innych marketplace’ach.

Księgowanie payoutu i pomniejszanie przychodu o prowizje

Najczęstszym uproszczeniem jest przyjęcie, że kwota przekazana na rachunek odpowiada sprzedaży. Payout jest jednak wynikiem rozliczenia wielu operacji i może obejmować zamówienia z różnych dni, prowizje, reklamy, logistykę, zwroty, rezerwy oraz korekty wcześniejszych okresów. Zakwalifikowanie wypłaty jako przychodu prowadzi do utraty informacji o pełnej wartości sprzedaży i rzeczywistej strukturze kosztów. Firma widzi jedynie końcowy przelew, ale nie potrafi wykazać, jakie transakcje i potrącenia doprowadziły do jego wysokości.

Powiązanym błędem jest pomniejszanie przychodu bezpośrednio o prowizje platformy. Sprzedaż klientowi i zakup usługi marketplace’u są odrębnymi zdarzeniami gospodarczymi. Prowizja może stanowić koszt, jeżeli spełnia właściwe warunki i posiada odpowiedni dokument, ale nie powinna znikać wewnątrz kwoty netto wypłaty. Prawidłowy proces pokazuje pełną wartość sprzedaży, właściwie udokumentowane korekty oraz osobno ujęte koszty. Dopiero na końcu zestawia te elementy z payoutem.

Brak dokumentów kosztowych i błędna klasyfikacja opłat

Raport marketplace’u może pokazywać, że platforma potrąciła prowizję, abonament, reklamę albo koszt magazynowania, ale informacja o potrąceniu nie zastępuje automatycznie dokumentu kosztowego. Firma powinna regularnie pobierać faktury i sprawdzać, czy odpowiadają obciążeniom widocznym w rozliczeniach. Brak dokumentu może utrudnić prawidłowe ujęcie wydatku i wyjaśnienie, dlaczego wypłata jest niższa od wartości sprzedaży. Problem staje się szczególnie widoczny wtedy, gdy dokumenty za różne usługi znajdują się w kilku częściach panelu albo są wystawiane przez różne podmioty z grupy operatora.

Drugim błędem jest łączenie wszystkich potrąceń pod nazwą „prowizja”. Reklama, obsługa płatności, dostawa do klienta, przewalutowanie, magazynowanie i relokacja towaru nie są jedną usługą tylko dlatego, że zostały potrącone z tego samego salda. Ich rzeczywisty charakter może wpływać na sposób ujęcia w KPiR oraz może wpływać na obowiązki w VAT, szczególnie gdy usługodawcą jest podmiot zagraniczny. Bezpieczniejszym rozwiązaniem jest przypisanie kosztów do dokumentów i kategorii odpowiadających faktycznie nabytym świadczeniom.

Podwójne księgowanie faktur i mieszanie źródeł sprzedaży

Podwójne ujęcie sprzedaży najczęściej pojawia się wtedy, gdy faktury są importowane z jednego systemu, a zbiorczy raport marketplace’u księgowany niezależnie. Jeżeli raport obejmuje również zamówienia fakturowane, przychód zostaje wykazany ponownie. Podobny problem dotyczy faktur wystawionych do sprzedaży zarejestrowanej wcześniej na kasie fiskalnej. Dokument trafia do systemu fakturowego, ale nie powinien tworzyć kolejnego przychodu, ponieważ transakcja została już ujęta w raporcie z kasy.

Ryzyko rośnie, gdy firma nie rozróżnia sprzedaży B2B, B2C, fiskalnej i niefakturowanej. Jeden raport może zawierać wszystkie rodzaje transakcji, ale każda grupa wymaga przypisania do właściwego sposobu dokumentowania. Mieszanie raportów fiskalnych z zestawieniami sprzedaży nieudokumentowanej fakturami prowadzi do utraty kontroli nad zakresem zapisów. Proces powinien umożliwiać oznaczenie każdej transakcji oraz potwierdzenie, że przychód został ujęty dokładnie raz i na podstawie właściwego dokumentu.

Pomijanie zwrotów i ujmowanie korekt w niewłaściwym okresie

Zwroty często pojawiają się w innym raporcie i okresie niż pierwotna sprzedaż. Jeżeli firma analizuje wyłącznie bieżący raport zamówień, może nie zauważyć korekt dotyczących wcześniejszych miesięcy. Zdarza się również odwrotna sytuacja: platforma automatycznie pomniejsza bieżące rozliczenie, a księgowość traktuje tę zmianę jako korektę bieżącej sprzedaży, bez sprawdzenia przyczyny i dokumentu źródłowego. Tymczasem sposób ujęcia zależy między innymi od tego, czy korekta wynika z późniejszego zwrotu, błędu rachunkowego, oczywistej omyłki czy innego zdarzenia.

Brak powiązania zwrotu z numerem zamówienia, fakturą, raportem fiskalnym lub pozycją zestawienia powoduje, że ujemna wartość pozostaje niezależną operacją. Przy sprzedaży zagranicznej trzeba dodatkowo przypisać korektę do właściwego systemu rozliczeń, na przykład OSS albo lokalnej rejestracji VAT. Dobra ewidencja zachowuje pełną ścieżkę od sprzedaży do zwrotu i późniejszego potrącenia w payoucie, nawet jeżeli poszczególne elementy występują w różnych miesiącach.

Brak archiwizacji i stałego standardu przetwarzania danych

Ręczne łączenie raportów nie musi samo w sobie prowadzić do błędów, ale staje się ryzykowne, gdy firma nie stosuje stałych reguł i nie zachowuje informacji o wykonanych zmianach. Jedna osoba usuwa anulowane zamówienia, druga wyłącza faktury, a trzecia przelicza waluty według innej metody. Jeżeli zmodyfikowany plik zastępuje raport źródłowy, po kilku miesiącach nie można ustalić, jakie dane pochodziły z platformy, a jakie zostały poprawione ręcznie. Proces traci ścieżkę audytu i zaczyna zależeć od pamięci pracowników.

Archiwum powinno obejmować oryginalne raporty, wersje przetworzone, opis zastosowanych reguł i końcowe zestawienia wykorzystane do zapisów. Dotyczy to również danych pobieranych przez API, ponieważ automatyczna integracja może pominąć część operacji albo zmienić sposób transformacji po aktualizacji. Stały standard sprawia, że każdy okres jest przygotowywany według tej samej logiki, a kolejne kanały można włączyć do istniejącego procesu bez tworzenia nowych wyjątków.

Odkładanie uzgodnień do momentu przygotowania rocznego JPK

JPK_PKPIR jest przekazywany za rok podatkowy, ale dane tworzące plik powstają każdego dnia. Odkładanie kontroli do końca roku oznacza konieczność przeanalizowania wielu miesięcy sprzedaży, zwrotów, wypłat i zmian statusów w krótkim czasie. Część raportów może być już niedostępna, niektórzy pracownicy mogą nie pamiętać przyczyn ręcznych korekt, a platforma może stosować nowy format danych. W rezultacie przygotowanie JPK przestaje być technicznym eksportem z uporządkowanej księgi i zmienia się w próbę odtworzenia całego roku działalności.

Znacznie bezpieczniejszy jest proces oparty na bieżącej dokumentacji, cotygodniowej kontroli kompletności oraz miesięcznym uzgodnieniu sprzedaży, kosztów, korekt i payoutów. Dzięki temu przed wygenerowaniem JPK_PKPIR firma sprawdza zamkniętą księgę, zamiast ponownie analizować tysiące transakcji. Roczny plik powinien być rezultatem regularnie wykonywanej pracy, a nie momentem, w którym po raz pierwszy porównuje się dane ze wszystkich marketplace’ów.

FAQ: JPK_KPiR i sprzedaż wielokanałowa

Czy dla każdego marketplace’u trzeba prowadzić oddzielną KPiR?

Nie. Jeżeli sprzedaż przez kilka marketplace’ów jest prowadzona przez tego samego podatnika w ramach jednej działalności gospodarczej rozliczanej na podstawie podatkowej księgi przychodów i rozchodów, co do zasady prowadzi on jedną KPiR. Poszczególne platformy nie tworzą odrębnych działalności tylko dlatego, że mają własne systemy płatności, raporty i harmonogramy wypłat. Przychody oraz koszty ze wszystkich kanałów powinny trafić do wspólnej księgi zgodnie z zasadami podatkowymi i na podstawie właściwych dokumentów. Można natomiast prowadzić oddzielne ewidencje pomocnicze dla każdego marketplace’u, kraju, waluty albo rodzaju sprzedaży. Takie zestawienia ułatwiają kontrolę, pozwalają wykrywać braki i pomagają odtworzyć źródło zapisów zbiorczych, ale nie zastępują KPiR. Ich wartości muszą zostać uzgodnione ze wspólną księgą, która następnie znajduje odzwierciedlenie w JPK_PKPIR.

Czy raport wypłat może być podstawą zaksięgowania przychodu?

Raport wypłat sam w sobie co do zasady nie powinien być automatycznie traktowany jako dokument stanowiący podstawę ujęcia przychodu w KPiR. Payout pokazuje przede wszystkim rozliczenie finansowe pomiędzy platformą a sprzedawcą. Może obejmować sprzedaż z kilku dni lub miesięcy, zwroty, prowizje, koszty reklamy, logistykę, przewalutowanie, rezerwy oraz korekty wcześniejszych okresów. Kwota przelewu nie przedstawia więc pełnej wartości sprzedaży ani nie musi odpowiadać momentowi powstania przychodu. Określone zestawienie może wyjątkowo spełniać wymagania właściwego dowodu księgowego, jeżeli jego treść i forma odpowiadają wymogom przewidzianym dla danego rodzaju zapisu. Nie wynika to jednak z samego faktu wygenerowania dokumentu przez marketplace. W praktyce bezpieczniejszym rozwiązaniem jest ustalanie przychodu na podstawie faktur, raportów fiskalnych albo właściwych zestawień sprzedaży, a raport wypłat wykorzystywać do uzgodnienia rozrachunków.

Czy można zaksięgować jedną łączną kwotę sprzedaży ze wszystkich platform?

Jedna łączna kwota może zostać ujęta tylko wtedy, gdy taki sposób zapisu jest dopuszczalny dla określonego rodzaju sprzedaży i opiera się na prawidłowo przygotowanym dokumencie. Nie można automatycznie zsumować wszystkich raportów z marketplace’ów i wpisać końcowej wartości do KPiR bez rozdzielenia transakcji fakturowanych, sprzedaży fiskalnej, sprzedaży nieudokumentowanej fakturami, zwrotów oraz anulacji. Faktury stanowią odrębne dokumenty, a sprzedaż objęta raportem z kasy nie powinna być ponownie uwzględniana w innym zapisie zbiorczym. Agregowanie danych może ułatwiać prowadzenie ewidencji, ale musi zachowywać możliwość przejścia od wartości zbiorczej do transakcji i dokumentów tworzących tę sumę. Firma może prowadzić osobne zestawienia pomocnicze dla poszczególnych kanałów, a następnie ujmować dane we wspólnej KPiR zgodnie z zasadami dotyczącymi konkretnych rodzajów dokumentów.

Jak ujmować sprzedaż B2C bez faktur?

Sposób ujęcia sprzedaży B2C zależy od tego, czy transakcja podlega obowiązkowi ewidencjonowania przy zastosowaniu kasy rejestrującej oraz czy została udokumentowana fakturą. Jeżeli sprzedaż została zarejestrowana na kasie, podstawą zapisów są właściwe raporty fiskalne. Jeżeli nie została udokumentowana fakturą ani raportem z kasy, a przepisy pozwalają na taki model dokumentowania, przychód może zostać ujęty na podstawie przewidzianego w przepisach dziennego dowodu wewnętrznego albo zestawienia sprzedaży. Sam status klienta jako konsumenta nie przesądza jeszcze, że można zastosować ewidencję sprzedaży bezrachunkowej. Najpierw trzeba ocenić obowiązki związane z kasą i charakterem transakcji. W sprzedaży wielokanałowej zestawienie powinno umożliwiać ustalenie daty, wartości, kanału oraz zamówień tworzących wpis, a także wyłączenie faktur, anulacji i sprzedaży objętej raportami fiskalnymi.

Jak księgować prowizje marketplace’u?

Prowizja pobierana przez marketplace jest zdarzeniem odrębnym od sprzedaży dokonanej na rzecz klienta. Fakt, że platforma potrąca swoje wynagrodzenie przed wypłatą środków, nie powoduje automatycznego pomniejszenia przychodu. Koszt prowizji można ująć po spełnieniu warunków wynikających z przepisów podatkowych i na podstawie właściwego dokumentu, najczęściej faktury wystawionej przez operatora. Raport wypłat może pomóc sprawdzić, jaka kwota została potrącona, ale nie zawsze zastępuje dokument kosztowy. Warto także rozdzielać prowizję od innych usług, takich jak reklama, magazynowanie, obsługa płatności, transport czy przewalutowanie. Dokument kosztowy powinien zostać zweryfikowany również pod kątem obowiązków w VAT, zwłaszcza gdy wystawcą jest zagraniczny operator platformy. W takich przypadkach bardzo często trzeba przeanalizować obowiązek rozliczenia importu usług. Każda opłata powinna zostać przypisana do dokumentu, właściwego okresu i rzeczywistego rodzaju świadczenia.

Co zrobić, gdy platforma wystawia faktury klientom w imieniu sprzedawcy?

W pierwszej kolejności trzeba ustalić, na jakiej podstawie platforma wystawia dokumenty oraz kto formalnie pozostaje sprzedawcą. Faktury mogą powstawać w ramach samofakturowania, czyli self-billingu, albo innych rozwiązań przewidzianych przez operatora. Automatyczne wystawienie dokumentu nie zwalnia przedsiębiorcy z kontroli jego poprawności i kompletności. Firma powinna mieć dostęp do wszystkich faktur, znać ich numery, daty, waluty i wartości oraz potrafić połączyć każdy dokument z konkretnym zamówieniem. Niezbędne jest również sprawdzenie, czy faktury wygenerowane przez platformę trafiły do księgowości i czy odpowiadają sprzedaży wykazanej w raportach. Transakcje udokumentowane w ten sposób trzeba wyłączyć z zestawień służących do ujmowania sprzedaży niefakturowanej, aby ta sama wartość nie została zaksięgowana po raz drugi.

Jak uniknąć podwójnego zaksięgowania faktury?

Najskuteczniejszym rozwiązaniem jest powiązanie faktury z numerem zamówienia oraz identyfikatorem transakcji marketplace’u. Każde zamówienie powinno mieć oznaczenie wskazujące, czy powstała do niego faktura, czy zostało zarejestrowane na kasie, czy może zostać objęte właściwym zestawieniem sprzedaży. Przed ustaleniem wartości wpisu zbiorczego trzeba wyłączyć wszystkie transakcje ujęte wcześniej na podstawie indywidualnych dokumentów. Należy również kontrolować faktury wystawione do sprzedaży zarejestrowanej na kasie, ponieważ taki dokument nie powinien powodować ponownego wykazania przychodu. Kontrola samych numerów faktur może być niewystarczająca, szczególnie gdy dane trafiają z kilku systemów. Warto porównywać także numery zamówień, identyfikatory transakcji, kwoty, daty, nabywców oraz źródło importu dokumentu.

Jak ujmować zwroty z wcześniejszych miesięcy?

Zwrot należy przede wszystkim powiązać z pierwotnym zamówieniem i dokumentem, na podstawie którego ujęto sprzedaż. Sposób korekty zależy od rodzaju dokumentu oraz przyczyny zmiany. Przy fakturze potrzebna może być faktura korygująca, natomiast sprzedaż fiskalna i wartości wynikające z zestawień wymagają zastosowania zasad właściwych dla danej ewidencji. W podatku dochodowym znaczenie ma rozróżnienie pomiędzy późniejszym zdarzeniem gospodarczym, takim jak zwrot towaru, a błędem rachunkowym lub oczywistą omyłką istniejącą już przy pierwotnym zapisie. Zwrot widoczny w bieżącym payoucie nie powinien automatycznie pomniejszać sprzedaży bieżącego miesiąca bez sprawdzenia jego podstawy. Przy transakcjach zagranicznych korektę trzeba również przypisać do właściwego systemu rozliczenia VAT, na przykład OSS albo lokalnej rejestracji.

Czy dane w KPiR muszą zgadzać się z kwotami wpływającymi na konto?

Kwota przychodu ujęta w KPiR nie musi być równa kwocie przelewu otrzymanego od marketplace’u. Wypłata może zostać pomniejszona o prowizje, opłaty, zwroty i inne potrącenia, a także obejmować sprzedaż z kilku różnych okresów. Platforma może zatrzymać część środków w rezerwie albo przekazać w bieżącym przelewie kwoty dotyczące wcześniejszych zamówień. Brak identycznych sum nie oznacza więc automatycznie błędu. Konieczne jest jednak uzgodnienie pozwalające logicznie wyjaśnić każdą różnicę. Firma powinna potrafić przejść od wartości sprzedaży przez zwroty, koszty, korekty i zatrzymane środki aż do kwoty payoutu. Rachunek bankowy pełni ważną funkcję kontrolną, ale nie zastępuje dokumentów sprzedażowych i kosztowych ani nie wyznacza automatycznie momentu rozpoznania przychodu.

Jak często sprawdzać zgodność raportów z KPiR?

Przepisy nie narzucają przedsiębiorcy cotygodniowego harmonogramu uzgadniania marketplace’ów, dlatego częstotliwość kontroli jest elementem organizacji wewnętrznej firmy. Przy sprzedaży wielokanałowej warto jednak prowadzić ją na kilku poziomach. Na bieżąco należy sprawdzać, czy zamówienia otrzymują właściwe dokumenty i prawidłowe statusy. Raz w tygodniu można kontrolować kompletność danych, działanie integracji, brakujące faktury kosztowe oraz nietypowe potrącenia. Po zakończeniu miesiąca powinno nastąpić pełne uzgodnienie sprzedaży, dokumentów, zwrotów, kosztów i wypłat. Przed wygenerowaniem oraz wysłaniem JPK_PKPIR potrzebna jest kontrola całej księgi za raportowany rok. Im większa liczba transakcji, tym więcej kontroli warto automatyzować, pozostawiając pracownikom analizę wyjątków i nierozpoznanych różnic.

Czy JPK_PKPIR wysyła się co miesiąc?

JPK_PKPIR nie jest wysyłany co miesiąc tak jak pliki związane z rozliczaniem VAT. Jest przekazywany po zakończeniu roku podatkowego, w terminie powiązanym z terminem złożenia właściwego zeznania rocznego PIT. Obowiązek jest wdrażany etapami. Podatnicy objęci obowiązkiem prowadzenia ksiąg elektronicznych od 1 stycznia 2026 roku prowadzą KPiR w odpowiedniej formie za rok 2026 i po raz pierwszy przekażą dane w strukturze JPK_PKPIR w 2027 roku. Kolejne grupy podatników są obejmowane obowiązkiem zgodnie z harmonogramem wdrażania elektronicznych ksiąg. Roczny charakter pliku nie oznacza jednak, że dane można porządkować dopiero po zakończeniu roku. JPK_PKPIR odzwierciedla KPiR, która musi być prawidłowo prowadzona i regularnie uzgadniana w trakcie całego okresu.

Czy uporządkowane raporty z marketplace’ów wystarczą na wypadek kontroli?

Uporządkowane raporty są ważne, ale same mogą nie wystarczyć. Firma powinna posiadać przede wszystkim dokumenty stanowiące podstawę zapisów w KPiR, takie jak faktury, raporty fiskalne, właściwe dowody i zestawienia sprzedaży oraz dokumenty dotyczące kosztów. Potrzebne są także dane pozwalające połączyć zapisy z zamówieniami, zwrotami, korektami i rozliczeniami platform. Raport źródłowy powinien być zachowany razem z wersją przetworzoną i informacją o wykonanych zmianach, jeżeli na jego podstawie przygotowano zestawienie księgowe. Podczas weryfikacji kluczowa jest możliwość odtworzenia drogi od pojedynczej transakcji do wpisu w KPiR. Raport marketplace’u może pełnić funkcję dowodową lub pomocniczą zależnie od swojej treści, ale nie zastępuje automatycznie wszystkich dokumentów wymaganych dla przychodów i kosztów.

Zakończenie: JPK_PKPIR zaczyna się dużo wcześniej niż podczas generowania pliku

Sprzedaż przez pięć marketplace’ów nie oznacza prowadzenia pięciu oddzielnych KPiR. Dla jednego podatnika prowadzącego działalność na podstawie podatkowej księgi przychodów i rozchodów wszystkie kanały muszą ostatecznie spotkać się w jednej, uporządkowanej ewidencji. Marketplace’y pozostają źródłami zamówień, dokumentów i danych rozliczeniowych, ale nie są odrębnymi systemami podatkowymi. Mogą stosować różne waluty, formaty raportów, terminy wypłat oraz sposoby obsługi zwrotów, jednak informacje z każdego kanału trzeba przypisać do właściwego dokumentu i przenieść do wspólnej księgi zgodnie z zasadami dotyczącymi danej transakcji.

Spójna ewidencja opiera się na trzech fundamentach. Pierwszym są kompletne dokumenty pozwalające prawidłowo ująć sprzedaż, koszty i korekty. Drugim jest wyeliminowanie podwójnych zapisów, szczególnie w sytuacji, gdy faktury, raporty fiskalne, zestawienia sprzedaży i integracje przekazują do księgowości częściowo pokrywające się dane. Trzecim pozostaje regularne uzgadnianie informacji z raportami marketplace’ów, rozliczeniami kosztów i payoutami. Jeżeli te elementy działają na bieżąco, przygotowanie JPK_PKPIR jest końcowym etapem prowadzenia księgi, a nie próbą odtworzenia całego roku sprzedaży na kilka tygodni przed terminem.

Dobrze zaprojektowany proces nie wymaga, aby wszystkie kwoty widoczne w systemach były identyczne. Wymaga natomiast, aby każdą różnicę można było wyjaśnić. Firma powinna wiedzieć, dlaczego payout jest niższy od wartości sprzedaży, z jakim dokumentem związana jest prowizja, do którego zamówienia odnosi się zwrot i które transakcje zostały wyłączone z wpisu zbiorczego. Powinna również potrafić odtworzyć źródło każdej wartości znajdującej się w KPiR bez polegania na pamięci pojedynczego pracownika. Taki model nie tylko ogranicza ryzyko błędów podatkowych, lecz także skraca zamknięcie miesiąca, ułatwia zmianę księgowości i tworzy podstawę do dalszej ekspansji.

Przy rosnącej sprzedaży wielokanałowej uporządkowanie procesu wymaga połączenia wiedzy księgowej ze zrozumieniem działania marketplace’ów, integracji, płatności i rozliczeń zagranicznych. amavat wspiera firmy e-commerce w organizowaniu księgowości obejmującej wiele kanałów i rynków, weryfikacji sposobu przekazywania danych oraz przygotowaniu ewidencji do nowych obowiązków raportowych. Celem nie jest wyłącznie wygenerowanie pliku zgodnego ze schematem technicznym. Jest nim stworzenie procesu, w którym KPiR pozostaje kompletna, przejrzysta i możliwa do uzgodnienia niezależnie od liczby platform, walut i obsługiwanych krajów.

Checklista gotowości do JPK_PKPIR

Poniższa checklista pozwala szybko ocenić, czy proces sprzedaży wielokanałowej jest gotowy do odzwierciedlenia w JPK_PKPIR. Odpowiedź negatywna przy którymkolwiek punkcie nie musi oznaczać błędu w księdze, ale wskazuje obszar wymagający sprawdzenia przed zamknięciem roku i wysłaniem pliku.

• Wszystkie aktywne kanały sprzedaży zostały zidentyfikowane i uwzględnione w procesie księgowym.
• Dla każdego rodzaju sprzedaży określono właściwy dokument będący podstawą zapisu w KPiR.
• Raporty marketplace’ów mają jasno określoną funkcję: księgową, pomocniczą albo rozliczeniową.
• Payouty są wykorzystywane do uzgadniania rozrachunków, a nie automatycznie księgowane jako sprzedaż.
• Sprzedaż, prowizje, zwroty, rezerwy i pozostałe potrącenia są rozdzielone na odrębne zdarzenia.
• Faktury mają powiązanie z numerami zamówień i identyfikatorami transakcji marketplace’ów.
• Transakcje fakturowane zostały wyłączone z raportów wykorzystywanych do przygotowania zapisów zbiorczych.
• Sprzedaż fiskalna nie została ponownie ujęta na podstawie faktur wystawionych do wcześniej zarejestrowanych transakcji.
• Sprzedaż B2B, B2C, fiskalna i nieudokumentowana fakturami jest odpowiednio rozróżniana.
• Anulowane zamówienia zostały wyłączone z wartości sprzedaży albo prawidłowo skorygowane.
• Zwroty są powiązane z pierwotnymi zamówieniami, dokumentami i właściwymi okresami.
• Korekty sprzedaży zagranicznej zostały przypisane do właściwego modelu rozliczenia podatku.
• Prowizje, reklama, logistyka i pozostałe opłaty mają właściwe dokumenty kosztowe.
• Dokumenty wystawione przez zagranicznych operatorów zostały sprawdzone pod kątem obowiązków w VAT.
• Potrącenia widoczne w payoutach zostały porównane z fakturami i rozliczeniami okresowymi.
• Integracje i połączenia API zostały sprawdzone pod kątem brakujących oraz powielonych danych.
• Raporty źródłowe zostały zachowane w niezmienionej wersji.
• Wersje przetworzone zawierają informację o wyłączeniach, korektach i pozostałych wykonanych zmianach.
• Każdy zbiorczy zapis w KPiR można rozłożyć na dokumenty i transakcje tworzące jego wartość.
• Dane z ewidencji pomocniczych zostały uzgodnione z ostateczną wersją KPiR.
• Wszystkie istotne różnice między sprzedażą, dokumentami, kosztami i wypłatami zostały wyjaśnione.
• Po ostatnich korektach KPiR wygenerowano nową, aktualną wersję JPK_PKPIR.
• Plik przeznaczony do wysłania odpowiada dokładnie ostatecznej treści zatwierdzonej księgi.
• Można odtworzyć źródło, dokumentację i sposób obliczenia każdej wartości znajdującej się w KPiR.