Jeden raport z Allegro zamiast tysięcy transakcji? To wymaga ostrożności
Sklep internetowy może w ciągu jednego miesiąca zrealizować kilka tysięcy zamówień przez Allegro, Amazon, własny sklep oraz inne marketplace’y. Z punktu widzenia organizacji księgowości naturalne wydaje się pobranie miesięcznego raportu i zaksięgowanie całej sprzedaży jednym zapisem.
Takie podejście może jednak być zbyt dużym uproszczeniem. Wraz z obowiązkiem elektronicznego prowadzenia ksiąg i raportowania JPK_KR_PD znaczenie ma nie tylko końcowa suma sprzedaży, lecz również możliwość ustalenia, jakie operacje gospodarcze się na nią składają.
Ministerstwo Finansów dopuszcza technicznie wykorzystywanie zapisów zbiorczych. Nie oznacza to jednak, że firma może zastąpić wszystkie dane o klientach, fakturach i KSeF jedną pozycją „sprzedaż Allegro za miesiąc”.
Agregacja jest możliwa, ale nie może prowadzić do utraty informacji wymaganych przez ustawę o rachunkowości, przepisy podatkowe i strukturę JPK_KR_PD.
JPK_KR_PD nie dotyczy każdego sklepu internetowego
Na początku trzeba rozróżnić formę prowadzenia księgowości.
JPK_KR_PD dotyczy podatników prowadzących księgi rachunkowe, czyli pełną księgowość. Może więc obejmować spółki oraz przedsiębiorców prowadzących działalność na większą skalę, którzy są zobowiązani do prowadzenia ksiąg rachunkowych.
Przedsiębiorcy prowadzący podatkową księgę przychodów i rozchodów, jeśli są objęci obowiązkiem elektronicznego raportowania, przekazują dane w strukturze JPK_PKPIR. Podatnicy prowadzący ewidencję przychodów korzystają natomiast ze struktury JPK_EWP.
Dlatego Księgowość ecommerce powinna najpierw ustalić właściwy rodzaj ksiąg, a dopiero później projektować integrację z Allegro, Amazonem i innymi platformami.
Kogo JPK_KR_PD obejmuje w 2026 i 2027 roku
Obowiązek elektronicznego raportowania ksiąg jest wdrażany etapami.
Od 2026 roku obejmuje kolejne grupy podatników, w tym określonych podatników PIT prowadzących księgi rachunkowe i zobowiązanych do przesyłania JPK_V7M. W praktyce ich pierwsze pliki dotyczące ksiąg za 2026 rok będą przekazywane w 2027 roku.
Dla lat podatkowych lub obrotowych rozpoczynających się po 31 grudnia 2026 roku obowiązek obejmie kolejne podmioty, w tym podatników należących do grupy rozliczającej JPK_V7K.
Dla e-commerce oznacza to, że sposób księgowania sprzedaży z marketplace staje się coraz ważniejszy także dla podmiotów, które wcześniej mogły stosować prostszy model importu danych.
Czy sprzedaż z Allegro można księgować zbiorczo
Tak, ale pod określonymi warunkami.
Sama struktura JPK_KR_PD dopuszcza występowanie zapisów opartych na dokumentach zbiorczych. Ministerstwo Finansów wskazuje również sytuacje, w których technicznie pola dotyczące kontrahenta lub numeru KSeF mogą nie wystąpić.
Nie można jednak wyciągać z tego wniosku, że dowolny miesięczny raport z Allegro albo Amazon automatycznie pozwala pominąć dane wymagane przez przepisy.
Kluczowe jest to, czy księgowanie zbiorcze nadal zapewnia prawidłowe prowadzenie ksiąg, możliwość identyfikacji operacji oraz zachowanie wszystkich informacji, które powinny być wykazane w księgach i JPK_KR_PD.
Dokument zbiorczy w rachunkowości ma konkretne wymagania
Ustawa o rachunkowości pozwala stosować dowody zbiorcze służące do łącznego ujęcia zbioru dowodów źródłowych.
Nie jest to jednak dowolna miesięczna suma wygenerowana przez platformę.
Dowody źródłowe objęte takim dokumentem powinny być możliwe do jednoznacznego zidentyfikowania. Ustawa o rachunkowości wymaga, aby były w dowodzie zbiorczym pojedynczo wymienione.
Oznacza to, że księgowanie zbiorcze nie powinno niszczyć ścieżki audytu. Firma nadal musi być w stanie ustalić, jakie transakcje składają się na daną kwotę.
Automatyczny import z Allegro lub Amazon może być prawidłowym rozwiązaniem
Ustawa o rachunkowości pozwala również na automatyczne wprowadzanie zapisów do ksiąg na podstawie danych pochodzących z systemów informatycznych.
Warunkiem jest między innymi możliwość ustalenia źródła danych, sprawdzenia ich kompletności i poprawności oraz zapewnienia odpowiedniej ochrony informacji źródłowych.
To bardzo ważne dla e-commerce.
Najlepszym rozwiązaniem nie musi być ręczne księgowanie kilku tysięcy zamówień. Można korzystać z automatycznych integracji, jeżeli system zachowuje szczegółowe informacje o transakcjach i pozwala je później odtworzyć.
biuro rachunkowe obsługujące e-commerce powinno więc raczej projektować wiarygodny cyfrowy przepływ danych niż kopiować stare rozwiązania papierowej księgowości.
Raport Allegro nie zawsze jest formalnym dowodem zbiorczym
Raport marketplace może być bardzo dobrym źródłem danych, ale nie każdy raport automatycznie spełnia wymagania dowodu księgowego.
Przedsiębiorca powinien wiedzieć, z jakiego systemu pochodzi zestawienie, jakiego okresu dotyczy, kiedy zostało wygenerowane i jakie transakcje obejmuje.
Powinna istnieć również możliwość przejścia od wartości zbiorczej do poszczególnych zamówień, faktur, zwrotów i korekt.
Sama pozycja:
„Sprzedaż Allegro – maj – 680 000 zł”
może być niewystarczająca, jeżeli firma nie potrafi później wykazać, z czego dokładnie wynika ta kwota.
D_3 i D_12 nie są ogólnym zwolnieniem z raportowania danych
To jeden z najważniejszych elementów JPK_KR_PD.
Struktura techniczna może pozwalać na brak pola D_3, czyli danych kontrahenta, albo D_12, czyli numeru KSeF, przy określonych zapisach zbiorczych.
Nie oznacza to jednak, że firma może pomijać te informacje zawsze, gdy stosuje agregację.
Od 2026 roku, jeżeli dla konkretnego dowodu przepisy wymagają identyfikacji podatkowej kontrahenta albo numeru KSeF, danych tych nie można pominąć tylko dlatego, że przedsiębiorca zaksięgował sprzedaż zbiorczo.
Agregacja nie może więc służyć jako sposób na obejście zakresu danych wymaganych przez JPK_KR_PD.
Sprzedaż B2C może być prostsza pod względem danych kontrahenta
Przy sprzedaży konsumenckiej sytuacja jest zwykle prostsza.
Jeżeli nabywcy nie został nadany numer identyfikacji podatkowej, nie wykazuje się go w węźle „Kontrahent” JPK_KR_PD.
Oznacza to, że tysiące konsumentów kupujących produkty na Allegro nie muszą automatycznie tworzyć tysięcy kart kontrahentów tylko na potrzeby JPK_KR_PD.
Nie oznacza to jednak pełnej dowolności w księgowaniu zbiorczym. Sprzedaż nadal musi być prawidłowo udokumentowana, opodatkowana i możliwa do odtworzenia z danych źródłowych.
Dlatego sprzedaż B2C może być łatwiejsza do agregowania pod względem identyfikacji kontrahenta, ale nie jest zwolniona z zasad prawidłowej rachunkowości.
Sprzedaż B2B wymaga znacznie większej szczegółowości
Inaczej wygląda sytuacja, gdy klientem jest przedsiębiorca posiadający NIP.
W takim przypadku dane powinny umożliwiać jednoznaczną identyfikację kontrahenta. Jeżeli sprzedaż została udokumentowana fakturą z numerem KSeF, system księgowy powinien także zachować odpowiednie powiązanie z tym dokumentem.
Dlatego wrzucenie kilkuset klientów biznesowych pod technicznego kontrahenta o nazwie „ALLEGRO” może być nieprawidłowym uproszczeniem.
Marketplace nie jest automatycznie nabywcą sprzedawanego towaru. W typowym modelu rzeczywistym nabywcą pozostaje klient, a Allegro lub Amazon świadczy odrębne usługi wobec sprzedawcy.
Allegro nie jest kontrahentem przy każdej sprzedaży
Sprzedaż realizowana za pośrednictwem Allegro nie oznacza automatycznie sprzedaży na rzecz Allegro.
Jeżeli kupującym jest konsument albo przedsiębiorca, to właśnie on jest nabywcą towaru.
Allegro może być natomiast kontrahentem sprzedawcy w zakresie prowizji, opłat promocyjnych, usług logistycznych lub innych świadczeń platformowych.
Podobnie może wyglądać sytuacja w Amazonie, choć tam każdy model trzeba przeanalizować osobno. Platforma może pełnić różne role zależnie od rodzaju transakcji, kraju i konkretnego programu sprzedażowego.
Dlatego księgowość nie powinna automatycznie traktować marketplace jako nabywcy całej sprzedaży.
Numer KSeF powinien pozostać powiązany z operacją księgową
JPK_KR_PD zawiera pole D_12 służące do wskazywania numeru KSeF.
Jeżeli numer został nadany i zgodnie z przepisami powinien być wykazany, system księgowy musi zachować odpowiednią relację między dokumentem a zapisem w księgach.
Najlepszym rozwiązaniem jest automatyczny przepływ informacji.
Zamówienie z Allegro albo Amazon powinno prowadzić do wystawienia faktury, numer KSeF powinien wrócić do systemu sprzedażowego, a następnie trafić razem z danymi do księgowości.
Ręczne uzupełnianie takich numerów przy tysiącach transakcji szybko staje się niepraktyczne.
KSeF nie pozwala traktować raportu marketplace jako zamiennika każdej faktury
Raport Allegro lub Amazon może obejmować sprzedaż, prowizje, płatności, zwroty, opłaty logistyczne i inne rozliczenia.
Nie jest jednak automatycznie zamiennikiem faktur wystawionych klientom.
Jeżeli klient B2B otrzymał fakturę ustrukturyzowaną, przedsiębiorca powinien zachować relację pomiędzy konkretną transakcją, fakturą, numerem KSeF i właściwym kontrahentem.
Raport marketplace może zasilać księgowość automatycznie, ale nie powinien usuwać informacji potrzebnych do identyfikacji dokumentów.
Amazon księgowość może być znacznie bardziej złożona
Amazon może generować znacznie bardziej rozbudowany zestaw danych niż typowy krajowy marketplace.
Sprzedawca może korzystać z FBA, magazynów w kilku państwach, zagranicznych numerów VAT i sprzedaży w różnych walutach.
Jedno zestawienie może obejmować sprzedaż krajową, WSTO, sprzedaż lokalną z zagranicznego magazynu, zwroty, prowizje, reklamę i fulfillment.
Nie powinno się automatycznie księgować tego wszystkiego jednym zapisem na jednym koncie.
Profesjonalna Księgowość ecommerce powinna najpierw rozdzielić poszczególne rodzaje transakcji, a dopiero później określić sposób agregacji danych.
Wypłata z Allegro lub Amazon nie jest przychodem ze sprzedaży
To jeden z najczęstszych błędów przy księgowaniu marketplace.
Platforma może przelać przedsiębiorcy kwotę pomniejszoną o prowizje, zwroty, opłaty, koszty reklamy lub inne potrącenia.
Jeżeli sklep sprzedał produkty za 300 tys. zł, a marketplace przelał 270 tys. zł, nie oznacza to, że przychód wynosi 270 tys. zł.
Trzeba osobno ustalić wartość sprzedaży, VAT, koszty platformy, zwroty oraz należności i zobowiązania wobec marketplace.
Zaksięgowanie wyłącznie wpływu bankowego może zaniżyć sprzedaż i zaburzyć wynik finansowy.
Raport marketplace powinien uzgadniać się z płatnościami
Sprzedaż nie musi być równa kwocie wypłat z platformy. Różnica powinna jednak być możliwa do wyjaśnienia.
Może wynikać z prowizji, zwrotów, opłat logistycznych, reklam, rezerw albo różnic w terminach rozliczeń.
Dobra księgowość powinna móc przejść przez cały łańcuch:
zamówienie, dokument sprzedaży, raport marketplace, rozrachunek, wypłata.
Jeżeli na którymś etapie dane przestają się zgadzać, system powinien pozwolić wskazać konkretną transakcję powodującą różnicę.
Jedna miesięczna nota księgowa nie zawsze wystarczy
Nie istnieje zasada, że jedna nota miesięczna jest zawsze niedopuszczalna. Nie ma też zasady, że zawsze jest wystarczająca.
Jeden miesięczny zapis może być prawidłowy tylko wtedy, gdy wynika z właściwie skonstruowanego systemu księgowego, a dane źródłowe są kompletne i możliwe do zidentyfikowania.
Sama suma wygenerowana przez marketplace nie wystarczy, jeśli powoduje utratę danych wymaganych przez przepisy podatkowe, ustawę o rachunkowości lub JPK_KR_PD.
Szczególnej ostrożności wymagają faktury B2B, klienci posiadający NIP oraz dokumenty posiadające numer KSeF.
Zwroty i korekty muszą pozostać powiązane ze sprzedażą
W e-commerce transakcja może zostać skorygowana wiele tygodni po pierwotnej sprzedaży.
Klient zwraca towar, sklep wystawia korektę, marketplace dokonuje korekty własnych rozliczeń, a operator płatności zwraca środki.
System księgowy powinien nadal wiedzieć, której sprzedaży dotyczy dana korekta.
Przy fakturach KSeF znaczenie ma także powiązanie faktury korygującej z fakturą pierwotną.
Jeżeli wcześniejsza agregacja uniemożliwia późniejsze odnalezienie konkretnego dokumentu, uproszczenie może generować więcej problemów niż oszczędności.
Sprzedaż wielokanałowa potrzebuje wspólnego modelu danych
Sklep może prowadzić sprzedaż przez Allegro, Amazon, WooCommerce, Shopify i lokal stacjonarny.
Każdy system posiada własne identyfikatory i raporty.
Księgowość powinna jednak otrzymywać dane w jednym spójnym modelu. Przydatne są między innymi informacje o kanale sprzedaży, numerze zamówienia, rodzaju dokumentu, kontrahencie, kraju, walucie, kwocie netto, VAT, brutto i numerze KSeF.
Nie wszystko musi być ręcznie widoczne w pojedynczym zapisie. System powinien jednak umożliwiać późniejsze odtworzenie tych danych.
JPK_KR_PD ma odzwierciedlać rzeczywiste księgi
JPK_KR_PD nie jest dodatkowym raportem tworzonym niezależnie od księgowości dopiero po zakończeniu roku.
Plik ma odzwierciedlać dane wynikające z faktycznie prowadzonych ksiąg.
Dlatego przedsiębiorca nie powinien liczyć na rozwiązanie w stylu:
„przez cały rok księgujemy uproszczone sumy, a potem przed wysyłką JPK dopiszemy potrzebne informacje”.
Jeżeli system finansowo-księgowy nie posiada wymaganych powiązań i identyfikatorów, odtworzenie ich po wielu miesiącach może być kosztowne albo niemożliwe.
Najbezpieczniej projektować sposób księgowania marketplace już od początku tak, aby wymagane dane trafiały do ksiąg automatycznie.
JPK_KR_PD nie oznacza konieczności ręcznego księgowania tysięcy transakcji
Cyfryzacja ksiąg nie oznacza, że księgowa powinna ręcznie wprowadzać każde zamówienie.
Przy dużym e-commerce takie rozwiązanie byłoby nieefektywne.
Nowoczesny system może automatycznie pobierać dane z Allegro i Amazon, rozpoznawać sprzedaż B2B i B2C, przypisywać kontrahentów, pobierać numery KSeF, księgować odpowiednie grupy transakcji i uzgadniać wypłaty.
Automatyzacja jest więc wręcz wskazana.
Musi jednak ograniczać ręczną pracę bez usuwania danych wymaganych przez przepisy.
Dlaczego klasyczna księgowość może nie wystarczyć w e-commerce
Model obsługi firmy wystawiającej 30 faktur miesięcznie jest zupełnie inny niż księgowość sklepu realizującego 20 tys. zamówień.
W e-commerce trzeba połączyć sprzedaż, VAT, faktury, KSeF, marketplace, zwroty, korekty, płatności i prowizje.
JPK_KR_PD dodatkowo zwiększa znaczenie struktury danych.
Dlatego Zakładanie firmy dla ecommerce powinno uwzględniać sposób integracji marketplace z systemem księgowym już od początku działalności.
Rozwiązanie działające przy 50 zamówieniach może całkowicie przestać być praktyczne przy kilku tysiącach transakcji miesięcznie.
Amazon FBA wymaga jeszcze większej szczegółowości
Przy Amazon FBA pojawia się dodatkowy problem związany z międzynarodowym charakterem sprzedaży.
Towary mogą znajdować się w magazynach w kilku państwach, a przedsiębiorca może posiadać kilka zagranicznych rejestracji VAT.
Jedna wypłata Amazon może dotyczyć wielu różnych typów transakcji.
Nie wszystkie powinny być wykazywane w taki sam sposób w polskich księgach i rozliczeniach VAT.
Podobny problem może występować w dropshippingu. Księgowość dropshipping powinna najpierw ustalić, czy przedsiębiorca jest sprzedawcą towaru, pośrednikiem czy działa w innym modelu.
Automatyzacja powinna następować dopiero po prawidłowej kwalifikacji transakcji.
Jak przygotować księgowanie marketplace do JPK_KR_PD
Pierwszym krokiem powinno być ustalenie wszystkich źródeł danych. Sklep powinien wiedzieć, co pochodzi z Allegro, Amazon, programu sklepowego, KSeF, banku i operatora płatności.
Następnie trzeba określić, które rodzaje sprzedaży mogą być bezpiecznie agregowane, a które wymagają zachowania danych konkretnego kontrahenta i dokumentu.
Kolejnym krokiem jest wdrożenie automatycznego przechowywania numerów KSeF i identyfikatorów zamówień.
Trzeba także zaprojektować obsługę zwrotów, korekt oraz uzgadnianie wypłat marketplace.
Na końcu warto wygenerować testowy JPK_KR_PD na rzeczywistych danych i sprawdzić, czy system potrafi odtworzyć wszystkie wymagane informacje.
Księgowanie zbiorcze jest możliwe, ale nie może być sposobem na ukrycie danych
Nieprawidłowe są dwa skrajne podejścia.
Pierwsze zakłada, że każdą transakcję z marketplace trzeba ręcznie księgować pojedynczo. Drugie, że cały miesiąc można zamknąć jedną pozycją bez zachowania szczegółowych informacji.
Prawidłowy model znajduje się pomiędzy.
Firma może stosować automatyzację i odpowiednio skonstruowane zapisy zbiorcze, ale musi zachować możliwość identyfikacji operacji źródłowych.
Techniczna fakultatywność D_3 i D_12 nie oznacza ogólnego zwolnienia z raportowania danych kontrahentów i numerów KSeF. Jeżeli dla danej operacji informacje te są wymagane, agregacja nie może ich usunąć.
W e-commerce celem nie powinno być więc maksymalne ograniczenie liczby zapisów. Najważniejsze jest stworzenie takiego systemu, który potrafi automatycznie przetworzyć tysiące transakcji, ale nadal pozwala odpowiedzieć na pytanie: jaki klient, jaka faktura, jaki numer KSeF i jaka transakcja stoją za konkretną wartością w księgach.
FAQ
- Czy sprzedaż z Allegro można księgować jednym dokumentem zbiorczym?
Tak, w określonych warunkach możliwe jest stosowanie dowodów zbiorczych lub automatycznych zapisów z systemów informatycznych. Nie może to jednak prowadzić do utraty identyfikacji dowodów źródłowych ani danych wymaganych przez przepisy podatkowe i JPK_KR_PD. - Czy przy dokumencie zbiorczym trzeba podawać NIP każdego klienta?
Sama struktura XML dopuszcza niewystąpienie D_3 przy określonych zapisach zbiorczych. Od 2026 roku nie można jednak pominąć wymaganej identyfikacji kontrahenta tylko dlatego, że firma stosuje księgowanie zbiorcze. - Czy konsumenci z Allegro muszą być osobnymi kontrahentami w JPK_KR_PD?
Nie wykazuje się w węźle „Kontrahent” nabywcy, któremu nie nadano numeru identyfikacji podatkowej. Sprzedaż B2C nadal musi jednak być prawidłowo udokumentowana i możliwa do odtworzenia. - Czy numer KSeF trzeba wykazywać w JPK_KR_PD?
Jeżeli numer KSeF został nadany i dla danej operacji przepisy wymagają jego wykazania, należy zachować odpowiednie powiązanie w księgach. Agregacja sprzedaży nie powinna usuwać tej informacji. - Czy wypłata z Allegro lub Amazon może być zaksięgowana jako wartość sprzedaży?
Nie należy automatycznie utożsamiać wypłaty marketplace z przychodem, ponieważ platforma może potrącać prowizje, zwroty i inne opłaty. Księgowość powinna oddzielnie ustalić sprzedaż, koszty oraz rozrachunki z platformą. - Czy Allegro jest kontrahentem przy każdej sprzedaży?
Nie, w typowym modelu Allegro jest platformą pośredniczącą, a nabywcą towaru pozostaje klient. Allegro może być natomiast odrębnym kontrahentem dla prowizji i innych usług świadczonych sprzedawcy. - Czy JPK_KR_PD dotyczy każdego sklepu internetowego?
Nie, JPK_KR_PD dotyczy podatników prowadzących księgi rachunkowe. Podmioty prowadzące PKPiR lub ewidencję przychodów korzystają z odpowiednich struktur JPK_PKPIR albo JPK_EWP. - Jak najlepiej przygotować sprzedaż marketplace do JPK_KR_PD?
Najlepiej połączyć system marketplace, KSeF i księgowość tak, aby zachować identyfikację dokumentów i kontrahentów oraz możliwość uzgodnienia sprzedaży. Automatyzacja powinna ograniczać ręczną pracę, ale nie usuwać informacji wymaganych przez przepisy.
