JPK_V7, KPiR i raporty marketplace — które kwoty powinny się ze sobą zgadzać?

Najważniejsza zasada jest taka, że tych wartości nie należy oczekiwać jako identycznych tylko dlatego, że dotyczą tego samego miesiąca sprzedaży. JPK_V7, KPiR, raport sprzedażowy marketplace i raport wypłat mają inne cele i przedstawiają działalność z różnych perspektyw. JPK_V7 służy rozliczeniu VAT, KPiR podatku dochodowego, raport marketplace odzwierciedla transakcje według zasad i struktury danych przyjętych przez platformę, natomiast payout pokazuje przepływ pieniężny wynikający z rozrachunku pomiędzy sprzedawcą a marketplace. Sam fakt, że wartości te się różnią, nie musi więc oznaczać błędu. Problem zaczyna się wtedy, gdy przedsiębiorca nie potrafi wyjaśnić, z czego wynika dana rozbieżność, jakie transakcje ją tworzą i jak przejść od sprzedaży klientom do wartości wykazanych w ewidencjach podatkowych oraz do kwoty wypłaconej na rachunek. Dobrze przeprowadzone uzgodnienie powinno pozwalać odtworzyć tę ścieżkę na podstawie danych źródłowych, z uwzględnieniem sprzedaży, korekt, VAT, kosztów platformy i wypłat.

Czy ten artykuł jest dla mnie?

Ten artykuł jest przede wszystkim dla przedsiębiorców, którzy sprzedają własne towary za pośrednictwem marketplace i nie traktują już tego kanału jako dodatkowego źródła kilku czy kilkunastu zamówień miesięcznie, lecz jako istotną część działalności. Jeżeli jesteś czynnym podatnikiem VAT, prowadzisz KPiR, otrzymujesz od platform zbiorcze raporty sprzedażowe i rozliczeniowe, a na rachunku bankowym widzisz wypłaty pomniejszone o prowizje, logistykę, reklamy albo inne opłaty, proste porównanie miesięcznych sum może szybko przestać wystarczać. Szczególnie dotyczy to firm, które zwiększają skalę sprzedaży, obsługują dużą liczbę transakcji albo przygotowują się do wejścia na kolejne rynki. Im większy wolumen, tym częściej pojawia się sytuacja, w której raport marketplace pokazuje jedną wartość sprzedaży, ewidencja VAT inną podstawę, przychód w KPiR ma jeszcze inną wartość, a wypłata od platformy jest niższa o prowizje i pozostałe potrącenia. Przy większej skali działalności różnice pomiędzy tymi wartościami mogą być znaczące, nie dlatego, że któraś z nich jest automatycznie błędna, lecz dlatego, że każda z nich opisuje inny element tego samego procesu sprzedażowego.

Tekst jest szczególnie istotny dla przedsiębiorców, którzy chcą mieć kontrolę nad tym, czy dane sprzedażowe i księgowe dają się ze sobą logicznie uzgodnić przed dalszym skalowaniem działalności. W praktyce wielu sprzedawców błędnie utożsamia przychód z kwotą faktycznie otrzymaną od platformy, mimo że zasady podatkowe prowadzą do innych wniosków. Prowizje i inne opłaty marketplace mogą ekonomicznie pomniejszać payout, ale nie oznacza to, że automatycznie pomniejszają przychód ze sprzedaży klientowi. Podobnie kwota widoczna w raporcie platformy nie musi być bezpośrednio porównywalna z jedną pozycją w JPK_V7 albo KPiR bez wcześniejszego ustalenia, czy mówimy o wartości brutto, netto, sprzedaży po korektach, rozrachunku czy wypłacie. Podstawowy model opisany tutaj dotyczy przede wszystkim typowej krajowej sprzedaży własnych towarów przez czynnego podatnika VAT. Sprzedaż zagraniczna, OSS, WDT, eksport, transakcje walutowe, procedura marży, sprzedaż rejestrowana na szczególnych zasadach czy przypadki, w których platforma jest uznawana za dostawcę, wymagają odrębnej analizy i nie powinny być mechanicznie porównywane według jednego schematu.

Najważniejsza odpowiedź: które kwoty powinny się ze sobą zgadzać?

Przy uzgadnianiu sprzedaży z marketplace najważniejsze jest porównywanie danych, które rzeczywiście opisują ten sam zakres transakcji i pełnią podobną funkcję ewidencyjną. Sam fakt, że raport platformy, JPK_V7, KPiR i wyciąg bankowy dotyczą tego samego miesiąca, nie oznacza jeszcze, że końcowe sumy powinny być identyczne. Każde z tych źródeł pokazuje działalność z innej perspektywy. Raport marketplace odzwierciedla sprzedaż według metodologii konkretnej platformy, JPK_V7 służy rozliczeniu VAT, KPiR ujmuje przychody i koszty dla potrzeb podatku dochodowego, a raport rozliczeniowy pokazuje przepływy finansowe pomiędzy platformą a sprzedawcą. Dlatego prawidłowe uzgodnienie nie polega na znalezieniu jednej liczby występującej wszędzie, lecz na ustaleniu, które wartości odnoszą się do tych samych transakcji oraz jak wyjaśnić różnice wynikające z podatku VAT, momentu ujęcia, korekt, sposobu dokumentowania i rozliczeń z platformą.

Raport sprzedaży marketplace a JPK_V7

W typowej krajowej sprzedaży własnych towarów przez czynnego podatnika VAT punktem wyjścia powinno być wyodrębnienie z raportu marketplace tej sprzedaży, którą sam sprzedawca ma obowiązek wykazać w polskim VAT. To zastrzeżenie jest istotne, ponieważ raport platformy może obejmować transakcje o różnym charakterze podatkowym, w tym sprzedaż zagraniczną, sprzedaż rozliczaną według procedur szczególnych albo przypadki, w których rola platformy w rozliczeniu VAT jest inna niż przy zwykłej krajowej sprzedaży własnych towarów. Dopiero po określeniu właściwego zakresu można przejść do porównania podstawy opodatkowania i VAT należnego według odpowiednich stawek. Jeżeli raport marketplace prezentuje przede wszystkim wartości brutto, nie należy porównywać jego końcowej sumy bezpośrednio z pojedynczą wartością z JPK_V7. Najpierw trzeba ustalić, jaka część sprzedaży stanowi podstawę opodatkowania, jaki VAT jej odpowiada oraz które transakcje faktycznie powinny znaleźć się w polskiej ewidencji VAT sprzedawcy.

Przy takim uzgodnieniu trzeba uwzględnić zwroty, anulowania, rabaty i korekty, ale również moment, w którym wpływają one na ewidencję VAT. To szczególnie ważne w sytuacji, gdy marketplace pokazuje zdarzenie według daty technicznej przyjętej przez platformę, podczas gdy dla celów podatkowych znaczenie ma inny moment. Dlatego wartości z raportu marketplace i JPK_V7 powinny być przede wszystkim uzgadnialne w zakresie tych samych transakcji, a nie zawsze identyczne po prostym zsumowaniu danych za ten sam miesiąc kalendarzowy. Jeżeli po wydzieleniu właściwego zakresu sprzedaży, rozbiciu jej na stawki VAT i uwzględnieniu korekt nadal pozostaje różnica, wtedy trzeba sprawdzić między innymi daty, brakujące transakcje, sposób przypisania stawek, charakter sprzedaży oraz to, czy wszystkie operacje objęte raportem platformy rzeczywiście powinny być wykazywane przez sprzedawcę w polskim VAT.

JPK_V7 a KPiR

W relacji pomiędzy JPK_V7 a KPiR nie warto przyjmować zbyt prostego założenia, że miesięczne sumy powinny się ze sobą zgadzać jeden do jednego. Jednym z najważniejszych punktów kontrolnych jest uzgodnienie sprzedaży wykazywanej dla potrzeb VAT z odpowiadającym jej przychodem podatkowym ujmowanym w KPiR, z wyłączeniem VAT należnego oraz po uwzględnieniu różnic wynikających z zasad ewidencji i momentu ujęcia. Dla czynnego podatnika VAT VAT należny co do zasady nie stanowi przychodu podatkowego, dlatego przy typowej sprzedaży opodatkowanej właściwym punktem ekonomicznego odniesienia jest wartość bez podatku VAT. Nie oznacza to jednak, że każda pozycja w KPiR musi być od początku technicznie zapisana wyłącznie jako kwota netto. Sposób prowadzenia ewidencji może zależeć od dokumentów źródłowych, rodzaju sprzedaży oraz przyjętego sposobu ujmowania danych, dlatego najważniejszy jest prawidłowy wynik podatkowy i możliwość odtworzenia sposobu jego ustalenia.

Jeżeli więc towar został sprzedany za 1 230 zł brutto przy stawce 23%, w typowym przypadku wartość 1 000 zł jest zasadniczym punktem odniesienia przy analizie przychodu podatkowego, ponieważ 230 zł stanowi VAT należny. Nie oznacza to jednak, że suma sprzedaży wynikająca z JPK_V7 za dany miesiąc musi zawsze być identyczna z sumą przychodów widocznych w KPiR za ten sam okres. Różnice mogą wynikać z momentu powstania obowiązku podatkowego w VAT, zasad rozpoznawania przychodu dla podatku dochodowego, sposobu dokumentowania sprzedaży, korekt albo z faktu, że nie każde zdarzenie widoczne w ewidencji VAT odpowiada zwykłemu przychodowi ze sprzedaży towarów ujmowanemu w KPiR. Dlatego prawidłowe pytanie nie brzmi: „czy te dwie sumy są identyczne?”, lecz raczej: „czy potrafimy przypisać do siebie te same transakcje i wyjaśnić każdą różnicę pomiędzy ich ujęciem w VAT i podatku dochodowym?”.

Raport marketplace a KPiR

Przy porównywaniu danych z marketplace z KPiR punktem odniesienia powinien być przychód wynikający ze sprzedaży, a nie kwota, którą platforma faktycznie wypłaciła na rachunek bankowy. W praktyce to właśnie pomieszanie tych dwóch poziomów jest jednym z częstszych źródeł problemów. Jeżeli klient kupuje towar za 1 230 zł brutto, a platforma przed wypłatą potrąca prowizję, opłatę za reklamę, usługę logistyczną albo inne należności wynikające z rozliczenia, nie oznacza to automatycznie, że wartość sprzedaży klientowi została pomniejszona o te kwoty. W typowym przypadku sprzedaż pozostaje sprzedażą, natomiast prawidłowo udokumentowane wydatki związane z usługami platformy mogą być analizowane odrębnie jako koszty podatkowe, jeżeli spełniają warunki ich zaliczenia do kosztów uzyskania przychodów. Nie należy więc sprowadzać przychodu do kwoty netto wypłaconej przez marketplace.

Również tutaj nie należy oczekiwać, że raport marketplace i KPiR zawsze pokażą identyczną miesięczną sumę bez żadnych dodatkowych obliczeń. Platforma może posługiwać się datą zamówienia, płatności, wysyłki, dostawy, zakończenia transakcji, zwrotu albo rozliczenia, podczas gdy przychód podatkowy ujmuje się według zasad wynikających z przepisów. Znaczenie mają także korekty, szczególnie gdy sprzedaż została zrealizowana w jednym okresie, zwrot wystąpił w kolejnym, a jego finansowe rozliczenie przez platformę nastąpiło jeszcze później. Dlatego raport marketplace i KPiR powinny być uzgadniane na poziomie właściwie przypisanych transakcji, a nie wyłącznie końcowych miesięcznych sum. Jeżeli przedsiębiorca potrafi wskazać, które transakcje tworzą przychód, jak zostały skorygowane i dlaczego określona operacja została ujęta w konkretnym okresie, różnica pomiędzy raportami nie musi świadczyć o błędzie.

Raport rozliczeniowy marketplace a rachunek bankowy

Raport rozliczeniowy marketplace pełni inną funkcję niż raport sprzedażowy. Jego zadaniem jest pokazanie, jak platforma rozliczyła środki przypadające sprzedawcy w danym cyklu. Może obejmować kwoty związane ze sprzedażą, prowizjami, opłatami za usługi dodatkowe, rozliczeniami zwrotów, korektami wcześniejszych okresów, rezerwami, przewalutowaniami lub innymi elementami wpływającymi na saldo. Po uwzględnieniu tych pozycji powstaje payout, czyli kwota przeznaczona do wypłaty. To właśnie payout przypisany do konkretnego settlementu powinien być punktem odniesienia przy porównywaniu raportu rozliczeniowego z rachunkiem bankowym. Jeżeli platforma wykazuje określoną wypłatę, zasadniczo powinna ona dać się powiązać z odpowiednim przelewem lub zestawem przelewów, choć w praktyce trzeba uwzględnić między innymi walutę, podział płatności, przewalutowanie czy ewentualne opłaty bankowe.

Ważne jest przy tym prawidłowe rozumienie poszczególnych elementów potrącenia. Prowizja albo usługa reklamowa może stanowić koszt podatkowy, ale nie dzieje się tak automatycznie wyłącznie dlatego, że marketplace potrącił daną kwotę z wypłaty. Wydatek musi być prawidłowo udokumentowany i spełniać ogólne warunki zaliczenia do kosztów uzyskania przychodów. Zwrot środków klientowi nie jest natomiast po prostu kosztem platformy, lecz może wpływać na korektę sprzedaży lub przychodu. Z tego względu payout należy traktować jako wynik rozrachunku finansowego, a nie jako kategorię podatkową samą w sobie. Wypłata z marketplace nie jest właściwym punktem odniesienia ani dla przychodu w KPiR, ani dla wartości sprzedaży wykazanej w JPK_V7, nawet jeśli wszystkie te kwoty dotyczą działalności prowadzonej w tym samym okresie.

Jedna tabela, która pokazuje cały mechanizm

Najprościej uporządkować te zależności, oddzielając sprzedaż, podatki i przepływy pieniężne. Raport marketplace pokazuje transakcje według zasad przyjętych przez platformę, JPK_V7 odzwierciedla sposób ich ujęcia dla potrzeb VAT, KPiR służy ustaleniu przychodu i kosztów dla podatku dochodowego, a raport rozliczeniowy wraz z rachunkiem bankowym pokazuje przepływ środków pomiędzy platformą a przedsiębiorcą. Dopiero po rozdzieleniu tych warstw można właściwie ocenić, które dane powinny być do siebie zbliżone, które jedynie uzgadnialne, a których nie należy bezpośrednio porównywać.

Najważniejsza różnica przebiega więc pomiędzy sprzedażą a rozrachunkiem pieniężnym. JPK_V7 i KPiR dotyczą podatkowego ujęcia określonych zdarzeń gospodarczych, podczas gdy bank pokazuje jedynie przepływ środków. Raport marketplace może być źródłem danych dla obu tych obszarów, ale dopiero po ustaleniu, jaki typ informacji zawiera dany raport i jaką datą posługuje się platforma. Dlatego celem uzgodnienia nie jest osiągnięcie identycznych sum w każdym miejscu. Celem jest możliwość przejścia od danych sprzedażowych do zapisów w JPK_V7 i KPiR, a następnie od rozliczenia z platformą do wypłaty widocznej na rachunku bankowym, z pełnym wyjaśnieniem różnic wynikających z podatków, korekt, dat, dokumentów oraz sposobu rozrachunku.

Dlaczego wypłata z marketplace nie jest przychodem ze sprzedaży?

Wypłata z marketplace i przychód ze sprzedaży opisują dwa różne etapy tej samej działalności. Przychód powstaje w związku ze sprzedażą towaru klientowi, natomiast payout pokazuje wynik późniejszego rozrachunku pomiędzy sprzedawcą a platformą. Jeżeli klient kupuje produkt za określoną kwotę, to właśnie ta transakcja jest punktem wyjścia do ustalenia wartości sprzedaży, podstawy opodatkowania VAT oraz przychodu podatkowego. Platforma może natomiast przed przekazaniem pieniędzy potrącić własną prowizję, opłaty za reklamę, logistykę, obsługę zamówień, dodatkowe usługi albo inne należności wynikające z zasad rozliczenia. W settlementach mogą też pojawiać się refundy dotyczące wcześniejszych sprzedaży, chargebacki, rezerwy, uwolnienia rezerw, korekty platformy, salda przeniesione z poprzednich okresów czy kompensaty. W efekcie przedsiębiorca może otrzymać na konto kwotę wyraźnie niższą lub po prostu inną niż wartość sprzedaży dokonanej na rzecz klientów. Nie oznacza to jednak, że sprzedaż była niższa. Oznacza jedynie, że payout jest końcowym efektem wielu pozycji rozrachunkowych, które nie mają jednego wspólnego charakteru podatkowego.

Prowizje, reklamy czy usługi logistyczne mogą mieć własne skutki podatkowe i księgowe, ale nie należy traktować ich jako automatycznego pomniejszenia wartości sprzedaży tylko dlatego, że zostały potrącone przed wypłatą. Jeżeli dana opłata jest prawidłowo udokumentowana i spełnia warunki zaliczenia do kosztów uzyskania przychodów, może zostać rozliczona jako koszt. Zwrot środków klientowi może z kolei prowadzić do korekty wcześniej rozpoznanej sprzedaży lub przychodu, a anulowanie zamówienia, które nie doprowadziło jeszcze do dokonania sprzedaży, może mieć zupełnie inny charakter niż późniejszy zwrot zrealizowanej transakcji. Rezerwa zatrzymana przez platformę nie jest natomiast ani nową sprzedażą, ani automatycznie kosztem. Dlatego payout trzeba traktować przede wszystkim jako rezultat rozrachunku finansowego z marketplace, a nie jako samodzielną kategorię przychodową. To rozróżnienie staje się szczególnie ważne przy większej skali, gdy miesięczne settlementy obejmują transakcje z różnych okresów i wiele typów korekt.

Prosty przykład: sprzedaż 12 300 zł brutto, ale przelew tylko 11 070 zł

Załóżmy, że przedsiębiorca sprzedaje w Polsce towary opodatkowane stawką 23% VAT. W danym okresie klienci kupili produkty za łącznie 12 300 zł brutto. W tej kwocie znajduje się 10 000 zł wartości netto oraz 2 300 zł VAT należnego. Marketplace pobiera jednocześnie 1 230 zł prowizji i przed przekazaniem środków potrąca ją z salda sprzedawcy. W tym uproszczonym przykładzie pomijamy rezerwy, refundy z wcześniejszych okresów, inne opłaty, korekty salda i przesunięcia pomiędzy settlementami, dzięki czemu na rachunek bankowy trafia 11 070 zł. Gdyby przedsiębiorca spojrzał wyłącznie na wyciąg bankowy, mógłby dojść do błędnego wniosku, że właśnie tyle wyniosła jego sprzedaż albo przychód. Tymczasem przelew pokazuje jedynie wynik rozrachunku finansowego. Sprzedaż klientom wyniosła 12 300 zł brutto, a prowizja została rozliczona osobno w relacji pomiędzy sprzedawcą a platformą.

Ten przykład celowo pokazuje najprostszy możliwy model, w którym payout daje się bezpośrednio wyprowadzić ze sprzedaży i jednego potrącenia. W rzeczywistych raportach marketplace zależność może być bardziej złożona, ponieważ konkretny przelew nie musi odpowiadać wyłącznie sprzedaży wygenerowanej w tym samym okresie. Settlement może obejmować saldo początkowe, zwroty dotyczące wcześniejszych transakcji, zatrzymane środki, uwolnione rezerwy, chargebacki, korekty platformy i inne pozycje przenoszone pomiędzy cyklami rozliczeniowymi. Nie zmienia to jednak podstawowej zasady. JPK_V7, KPiR i bank pokazują różne warstwy tej samej działalności, dlatego ich końcowe sumy nie powinny być mechanicznie sprowadzane do jednej wartości.

Co zobaczymy w JPK_V7?

W typowym przypadku krajowej sprzedaży opodatkowanej stawką 23% wartość 12 300 zł brutto należy rozdzielić na 10 000 zł podstawy opodatkowania oraz 2 300 zł VAT należnego. To właśnie te wartości są właściwe dla ewidencji VAT w zakresie tej konkretnej sprzedaży. Prowizja pobrana przez marketplace nie obniża automatycznie podstawy opodatkowania sprzedaży towaru klientowi. Klient nabył bowiem towar za 12 300 zł brutto i to ta transakcja określa wartość sprzedaży. Fakt, że sprzedawca następnie rozlicza z platformą prowizję za jej własną usługę, jest odrębnym zdarzeniem. Dlatego oczekiwanie, że po potrąceniu prowizji w JPK_V7 pojawi się podstawa odpowiadająca kwocie wypłaty, byłoby błędne.

W rzeczywistym rozliczeniu trzeba oczywiście sprawdzić, czy w analizowanym okresie nie wystąpiły zdarzenia wpływające na podstawę opodatkowania lub VAT należny. Należy przy tym odróżnić anulowanie zamówienia przed dokonaniem sprzedaży od późniejszego zwrotu towaru albo korekty już zrealizowanej transakcji, ponieważ zdarzenia te mogą mieć inne skutki ewidencyjne i podatkowe. Trzeba także pamiętać, że prosty model odnosi się do sprzedaży, którą przedsiębiorca sam wykazuje w polskim VAT. Jeżeli raport platformy obejmuje również inne typy transakcji, nie powinny one automatycznie trafiać do tego samego porównania.

Co powinno trafić do KPiR?

W tym przykładzie, przy typowej krajowej sprzedaży towaru przez czynnego podatnika VAT, zasadniczym punktem odniesienia dla przychodu podatkowego jest 10 000 zł wartości sprzedaży bez VAT należnego. VAT należny co do zasady nie stanowi przychodu podatkowego, dlatego nie należy utożsamiać kwoty brutto 12 300 zł z przychodem dla podatku dochodowego. Jednocześnie nie należy utożsamiać przychodu z kwotą 11 070 zł wypłaconą przez platformę. To, że część należności została potrącona na poczet prowizji, nie zmienia wartości sprzedaży dokonanej na rzecz klienta. Jeżeli więc analizujemy ten prosty przypadek bez różnic dotyczących momentu ujęcia, korekt czy specyficznych zasad dokumentowania, przychód odpowiada wartości 10 000 zł.

Prowizja platformy powinna zostać rozpatrzona odrębnie. Jeżeli przedsiębiorca posiada prawidłowy dokument i spełnione są warunki zaliczenia wydatku do kosztów uzyskania przychodów, odpowiednia wartość prowizji może zostać ujęta po stronie kosztowej. Sam fakt potrącenia określonej kwoty przez marketplace nie przesądza jeszcze o jej podatkowej kwalifikacji. Nie powinno się także uzyskiwać „przychodu po prowizji” przez proste odjęcie kwoty potrąconej przez platformę od sprzedaży. Taki sposób myślenia miesza przychód, koszt i rozrachunek pieniężny, które powinny być analizowane osobno.

Co pojawi się na rachunku bankowym?

Na rachunku bankowym pojawi się w tym uproszczonym przykładzie 11 070 zł, ponieważ tyle wynosi saldo przekazane sprzedawcy po potrąceniu 1 230 zł prowizji. Wyciąg bankowy pokazuje jednak tylko przepływ pieniężny. Nie odpowiada na pytanie, jaka była podstawa opodatkowania VAT, jaka część sprzedaży stanowiła przychód podatkowy ani czy poszczególne opłaty marketplace spełniają warunki zaliczenia do kosztów. Z tego powodu rachunek bankowy nie jest właściwym źródłem do ustalania wartości sprzedaży dla VAT ani przychodu w KPiR. Jest natomiast ważnym źródłem kontrolnym przy uzgadnianiu raportu rozliczeniowego platformy.

W bardziej złożonych przypadkach nawet zależność pomiędzy settlementem a przelewem może wymagać dodatkowego wyjaśnienia. Platforma może zatrzymać część środków w rezerwie, przenieść saldo do kolejnego okresu, uwolnić wcześniejszą rezerwę, rozliczyć refund lub chargeback z poprzedniego cyklu, wykonać kilka przelewów albo zastosować przewalutowanie. Dlatego przedsiębiorca powinien potrafić powiązać konkretną wypłatę z odpowiednim settlementem i wyjaśnić pozycje, które przechodzą pomiędzy okresami, zamiast zakładać, że każda aktywność rozliczeniowa z danego miesiąca musi w całości zakończyć się jednym przelewem.

Gdzie powstaje najczęstszy błąd?

Najczęstszy błąd pojawia się wtedy, gdy przedsiębiorca przyjmuje kwotę faktycznie otrzymaną od platformy jako wartość przychodu. Takie podejście może wydawać się intuicyjne, szczególnie gdy księgowanie zaczyna się od wyciągu bankowego, ale nie odzwierciedla właściwie relacji pomiędzy sprzedażą a rozrachunkiem z marketplace. Przelew może być niższy od sprzedaży z powodu prowizji, usług dodatkowych, zwrotów, rezerw czy innych potrąceń, ale sama różnica nie oznacza automatycznie pomniejszenia przychodu. Poszczególne pozycje trzeba oceniać według ich rzeczywistego charakteru. Prowizja może stanowić koszt, zwrot może skutkować korektą sprzedaży, a rezerwa może być jedynie czasowym zatrzymaniem środków.

Drugim częstym błędem jest oczekiwanie, że payout będzie równy sprzedaży wykazanej w JPK_V7. Takie porównanie zestawia ze sobą wynik rozrachunku pieniężnego i dane ewidencji VAT, czyli wielkości o innym znaczeniu. Jeżeli przedsiębiorca chce sprawdzić poprawność rozliczeń, powinien najpierw powiązać dane sprzedażowe z JPK_V7, następnie odpowiadający im przychód z KPiR, a osobno settlement z wypłatą bankową. Przy takim podejściu różnica przestaje być automatycznie traktowana jako błąd, a staje się pozycją, którą trzeba przypisać do konkretnej przyczyny.

Jak uzgodnić raport marketplace krok po kroku?

Dobre uzgodnienie powinno pozwalać przejść od sprzedaży klientom do danych podatkowych, a następnie od rozrachunku z platformą do rzeczywistej wypłaty na konto. Najlepiej robić to w stałej kolejności, ponieważ próba rozpoczęcia od przelewów bankowych często prowadzi do mieszania sprzedaży z prowizjami, zwrotami, rezerwami i innymi potrąceniami. W przypadku średniej firmy e-commerce szczególnie ważne jest zachowanie spójnej metodologii miesiąc po miesiącu. Przy rosnącej liczbie zamówień nie chodzi już wyłącznie o znalezienie jednej różnicy, ale o zbudowanie procesu, w którym każda istotna kwota może zostać przypisana do konkretnego źródła danych, typu transakcji i sposobu rozliczenia.

Krok 1. Ustal pełny zakres sprzedaży klientom

Pierwszym etapem powinno być ustalenie, jakie transakcje z klientami rzeczywiście znajdują się w analizowanych danych. W typowym modelu krajowym punktem wyjścia będzie wartość brutto sprzedaży, ale przy bardziej złożonej działalności jedna zbiorcza kwota może być niewystarczająca. Raport marketplace może obejmować różne rynki, różne modele rozliczenia VAT, sprzedaż krajową, transakcje zagraniczne, sprzedaż objętą szczególnymi procedurami oraz operacje, które nie powinny być traktowane w ten sam sposób podatkowo. Dlatego ważniejsze od znalezienia jednej sumy jest ustalenie pełnego zakresu sprzedaży i podziału jej na kategorie, które później będzie można prawidłowo uzgodnić z ewidencjami.

Na tym etapie trzeba również zidentyfikować zwroty, rabaty, korekty i anulowania. Anulowanie zamówienia przed dokonaniem sprzedaży należy odróżnić od późniejszego zwrotu towaru lub korekty już zrealizowanej transakcji, ponieważ zdarzenia te mogą mieć inne skutki ewidencyjne i podatkowe. Warto też ustalić, jaką datą posługuje się konkretny raport platformy. Może to być data zamówienia, płatności, wysyłki, dostawy, refundu albo settlementu. Bez tego łatwo porównać ze sobą dwie liczby, które odnoszą się do podobnych transakcji, ale do innych momentów ich ujęcia.

Krok 2. Zbuduj most od sprzedaży i pozycji rozrachunkowych do payoutu

W uproszczeniu most może wychodzić od sprzedaży i prowadzić przez zwroty, korekty, prowizje, opłaty oraz pozostałe pozycje rozrachunkowe do payoutu. W rzeczywistych settlementach trzeba jednak uwzględnić także saldo początkowe, rezerwy, uwolnienia rezerw, refundy odnoszące się do wcześniejszych okresów, chargebacki, korekty platformy, kompensaty oraz inne pozycje przenoszone pomiędzy cyklami rozliczeniowymi. Dlatego poprawny model nie zawsze wygląda jak proste „sprzedaż minus koszty równa się wypłata”. Znacznie trafniej jest traktować settlement jako zestaw wpływów i obciążeń, które razem prowadzą do salda przeznaczonego do wypłaty.

Schemat kontrolny można więc ująć następująco: sprzedaż i inne wpływy, następnie plus lub minus refundy i korekty, plus lub minus pozycje odnoszące się do wcześniejszych okresów, minus opłaty i pozostałe potrącenia, plus lub minus zmiany rezerw i sald, prowadzą do payoutu. Taki most nie zastępuje księgowania i nie oznacza, że wszystkie elementy settlementu mają ten sam charakter podatkowy. Jego zadaniem jest wyjaśnienie przepływu finansowego. Jeżeli sprzedaż wynosi 500 tys. zł, a wypłata 420 tys. zł, sama różnica 80 tys. zł nie pozwala stwierdzić, czy wszystko jest prawidłowe. Dopiero rozpisanie jej na konkretne pozycje pokazuje, czy saldo faktycznie się zamyka.

Krok 3. Rozbij sprzedaż według stawek VAT i rodzaju transakcji

Po ustaleniu pełnego zakresu sprzedaży należy podzielić ją według stawek VAT oraz rodzaju transakcji. Sama stawka podatku nie zawsze wystarcza, ponieważ dwie operacje z taką samą wartością procentową mogą podlegać innym zasadom rozliczenia ze względu na miejsce opodatkowania albo charakter sprzedaży. Dlatego obok wartości netto, VAT i stawki trzeba znać również typ transakcji. W prostym modelu krajowym będzie to na przykład zwykła sprzedaż krajowa opodatkowana według odpowiedniej stawki, natomiast przy ekspansji zagranicznej potrzebne jest dodatkowe rozdzielenie sprzedaży objętej innymi zasadami.

Taki podział pozwala uniknąć sytuacji, w której cała sprzedaż z marketplace jest wrzucana do jednego zestawienia wyłącznie dlatego, że pochodzi z tego samego kanału. Przy większej skali działalności to właśnie segmentacja według charakteru transakcji pozwala najczęściej szybko znaleźć źródło różnicy. Jeżeli jedna grupa sprzedaży uzgadnia się poprawnie, a problem występuje tylko w określonym kraju, typie operacji albo stawce, analiza staje się znacznie prostsza niż przy porównywaniu jednej globalnej sumy.

Krok 4. Uzgodnij część sprzedażową z JPK_V7

Dopiero po uporządkowaniu sprzedaży według stawek i rodzaju transakcji można przejść do uzgodnienia z JPK_V7. Należy porównać podstawy opodatkowania oraz odpowiadający im VAT należny, ale wyłącznie w zakresie sprzedaży, którą przedsiębiorca sam wykazuje w polskim VAT. To ograniczenie ma kluczowe znaczenie, ponieważ raport marketplace może obejmować również transakcje, których nie należy mechanicznie ujmować w takim samym modelu jak zwykłej krajowej sprzedaży. Trzeba także uwzględnić korekty oraz właściwy moment ich ujęcia, ponieważ platforma i ewidencja podatkowa mogą posługiwać się innymi datami.

Dobrze przeprowadzone uzgodnienie powinno pozwalać odpowiedzieć na pytanie, dlaczego określona sprzedaż znalazła się w JPK_V7 w danym okresie i jak odnosi się do danych z platformy. Jeżeli pojawia się rozbieżność, należy sprawdzić przede wszystkim zakres transakcji, daty, korekty, stawki VAT, rodzaj sprzedaży i sposób jej dokumentowania. Celem nie jest wymuszenie identycznej miesięcznej sumy, lecz możliwość przypisania różnicy do konkretnego i prawidłowo udokumentowanego powodu.

Krok 5. Uzgodnij przychód z KPiR

Kolejny etap polega na powiązaniu sprzedaży z odpowiadającym jej przychodem podatkowym w KPiR. W przypadku czynnego podatnika VAT punktem odniesienia jest co do zasady wartość bez VAT należnego, ale samo uzgodnienie powinno uwzględniać zasady rozpoznawania przychodu, sposób dokumentowania oraz moment ujęcia poszczególnych transakcji. Nie należy więc zakładać, że każda miesięczna suma netto z raportu marketplace musi bez żadnych korekt odpowiadać jednej miesięcznej sumie w KPiR. Znacznie ważniejsze jest ustalenie, jakie transakcje tworzą przychód i dlaczego zostały ujęte w konkretnym okresie.

W praktyce przydatne jest oddzielenie różnic wynikających z błędów od różnic wynikających wyłącznie z momentu albo sposobu ewidencji. Jeżeli dana sprzedaż znajduje się w raporcie platformy w jednym okresie, ale zgodnie z zasadami podatkowymi została rozpoznana w KPiR w innym, nie oznacza to automatycznie nieprawidłowości. Powinna jednak istnieć możliwość pokazania, z czego ta różnica wynika. Uzgodnienie ma więc prowadzić do spójnej odpowiedzi na pytanie, czy przychód wykazany w KPiR rzeczywiście wynika ze sprzedaży przedsiębiorcy, a nie z kwoty payoutu lub przypadkowej sumy z raportu finansowego platformy.

Krok 6. Dopiero na końcu uzgodnij payout z bankiem

Ostatnim etapem jest powiązanie raportu rozliczeniowego marketplace z rachunkiem bankowym. Na tym poziomie interesuje nas nie wartość sprzedaży, lecz kwota payout przypisana do konkretnego settlementu. Jeżeli platforma wykazuje określoną wypłatę, powinna ona zasadniczo znaleźć odzwierciedlenie w odpowiednim przelewie albo zestawie przelewów. Przy analizie trzeba jednak uwzględnić walutę, przewalutowanie, podział wypłaty, opłaty bankowe, saldo przechodzące pomiędzy settlementami oraz środki zatrzymane w rezerwie. W praktyce część aktywności widocznej w konkretnym okresie rozliczeniowym może więc wpływać na payout dopiero później.

Dopiero na tym etapie bank staje się właściwym punktem kontroli. Nie należy wcześniej próbować dopasowywać przelewu do wartości sprzedaży z JPK_V7 ani do przychodu w KPiR, ponieważ prowadzi to do mieszania poziomu podatkowego i pieniężnego. Prawidłowa kolejność jest odwrotna: najpierw trzeba ustalić zakres sprzedaży i jej skutki podatkowe, następnie wyjaśnić settlement wraz z saldami, rezerwami i korektami, a na końcu powiązać końcową wypłatę z rachunkiem bankowym. Dzięki temu pozostająca różnica nie jest od razu traktowana jako błąd księgowy, lecz jako pozycja, której źródło można odnaleźć w danych rozliczeniowych platformy.

Dlaczego kwoty mogą się różnić, mimo że rozliczenie jest prawidłowe?

Różnica pomiędzy raportem marketplace, JPK_V7, KPiR i rachunkiem bankowym nie musi oznaczać błędu. W dużym e-commerce jest wręcz normalne, że te same transakcje wyglądają inaczej w zależności od tego, czy patrzymy na nie z perspektywy sprzedaży, VAT, podatku dochodowego czy przepływu pieniężnego. Problem pojawia się dopiero wtedy, gdy przedsiębiorca nie potrafi przypisać rozbieżności do konkretnej przyczyny. Dlatego zamiast oczekiwać jednej identycznej sumy we wszystkich źródłach, trzeba rozumieć, jakie dane zawiera dany raport, według jakich dat są prezentowane i do jakiego celu służą. W praktyce najczęstsze różnice wynikają z podatku VAT, opłat platformy, zwrotów, dat transakcji, korekt, walut, sposobu przygotowania raportu oraz sprzedaży zagranicznej.

VAT: brutto w raporcie, netto i VAT w ewidencji

Raport marketplace może prezentować wartość transakcji brutto lub inną wartość wynikającą z metodologii danego raportu. W wielu przypadkach będzie to sprzedaż brutto, ale zależy to od rodzaju raportu udostępnianego przez platformę. Jeżeli klient kupuje towar za 1 230 zł brutto przy stawce 23%, w jednym z raportów można zobaczyć właśnie kwotę 1 230 zł, natomiast dla potrzeb VAT istotne są 1 000 zł podstawy opodatkowania i 230 zł VAT należnego. W KPiR, w typowym przypadku czynnego podatnika VAT, punktem odniesienia dla przychodu będzie z kolei wartość bez VAT należnego. Już na tym prostym poziomie jedna sprzedaż może więc występować w raportach w kilku różnych formach i żadna z nich nie musi być błędna.

W praktyce oznacza to, że nie powinno się porównywać kwoty z raportu platformy bezpośrednio z jedną sumą z JPK_V7 albo z przychodem w KPiR, jeżeli wcześniej nie ustalono, co dokładnie pokazuje dany raport. Najpierw trzeba sprawdzić jego metodologię, następnie rozdzielić sprzedaż według właściwych stawek, ustalić wartość netto i VAT oraz upewnić się, że porównywane są te same transakcje. Dopiero wtedy można ocenić, czy dane rzeczywiście są ze sobą uzgadnialne.

Prowizje i opłaty platformy

Marketplace może potrącać z salda sprzedawcy prowizje, opłaty za reklamy, logistykę, obsługę zamówień, magazynowanie albo inne usługi. Z punktu widzenia przepływu pieniężnego oznacza to, że wypłata na konto jest niższa niż wartość sprzedaży klientom. Nie oznacza to jednak, że sprzedaż sama w sobie była niższa. Jeżeli klient kupił towar za 1 230 zł, to prowizja pobrana później przez platformę nie zmienia automatycznie wartości tej sprzedaży. Jest odrębną operacją wynikającą z relacji pomiędzy przedsiębiorcą a marketplace.

W praktyce oznacza to, że payout może być wyraźnie niższy niż sprzedaż wykazana dla celów VAT i podatku dochodowego. Prowizje i inne opłaty należy analizować osobno, z uwzględnieniem ich dokumentowania i podatkowej kwalifikacji. Sam fakt, że określona kwota została potrącona z wypłaty, nie oznacza jeszcze, że można ją automatycznie odjąć od przychodu.

Zwroty, anulowania i rabaty

Zwroty, anulowania i rabaty często wyglądają podobnie w raporcie platformy, ale podatkowo nie zawsze oznaczają to samo. Anulowanie zamówienia przed dokonaniem sprzedaży może nie prowadzić do powstania sprzedaży, podczas gdy zwrot już dostarczonego towaru jest korektą transakcji, która wcześniej została zrealizowana. Rabat może natomiast zmniejszać cenę sprzedaży, a jego wpływ na ewidencję zależy od momentu i sposobu udokumentowania korekty. Jeżeli wszystkie te zdarzenia zostaną wrzucone do jednej kategorii „minusów”, łatwo otrzymać pozornie poprawny wynik finansowy, który nie odpowiada właściwemu ujęciu podatkowemu.

W praktyce oznacza to konieczność rozróżnienia, czy dana pozycja usuwa sprzedaż, koryguje już rozpoznaną transakcję, czy tylko zmienia jej wartość. Ma to szczególne znaczenie przy automatycznych eksportach z marketplace, gdzie system może prezentować wszystkie zdarzenia w podobny sposób, mimo że dla JPK_V7 i KPiR trzeba je traktować inaczej.

Inne daty zamówienia, płatności, wysyłki, dostawy i wypłaty

Marketplace może przypisywać transakcji kilka różnych dat. Jedna może dotyczyć złożenia zamówienia, druga płatności, kolejna wysyłki, dostawy, zwrotu, settlementu albo samej wypłaty środków. Dla użytkownika panelu wszystkie te daty mogą wyglądać jak elementy tej samej sprzedaży, ale dla uzgodnienia księgowego nie są zamienne. Jeżeli raport sprzedażowy został wygenerowany według daty zamówienia, a księgowość ujmuje transakcję według innego momentu wynikającego z przepisów, miesięczne sumy mogą różnić się nawet wtedy, gdy żadnej transakcji nie brakuje.

W praktyce oznacza to, że przed porównaniem dwóch raportów trzeba ustalić, według jakiego pola daty zostały przygotowane. Szczególnie przy dużym wolumenie sprzedaży różnice na przełomie miesiąca mogą być istotne, ponieważ część zamówień z końca jednego okresu zostanie ujęta podatkowo dopiero w kolejnym albo odwrotnie. Bez kontroli dat taka różnica może wyglądać jak błąd w księgowaniu, choć w rzeczywistości wynika tylko z innego sposobu przypisania transakcji do okresu.

Inny moment ujęcia przychodu dla PIT i obowiązku podatkowego VAT

W typowej sprzedaży krajowej momenty ujęcia dla PIT i VAT często prowadzą do wykazania sprzedaży w tym samym okresie, jednak przepisy nie są identyczne i w określonych sytuacjach mogą powodować różnice okresowe. Dotyczy to między innymi korekt, przedpłat, specyficznych modeli realizacji albo innych zdarzeń, dla których sposób rozpoznania obowiązku podatkowego i przychodu nie jest oparty na dokładnie tych samych regułach. Z tego powodu JPK_V7 i KPiR nie powinny być porównywane wyłącznie na zasadzie mechanicznej równości miesięcznych sum.

W praktyce oznacza to, że lepiej uzgadniać konkretne grupy transakcji i identyfikować różnice okresowe. Jeżeli przedsiębiorca potrafi pokazać, że dana sprzedaż została ujęta w jednym rejestrze w maju, a w drugim w czerwcu z prawidłowego powodu, sama różnica miesięczna nie świadczy o błędzie. Najważniejsza jest możliwość wyjaśnienia, dlaczego moment ujęcia danej transakcji różni się pomiędzy ewidencją VAT i KPiR.

Waluty i przewalutowania

Sprzedaż zagraniczna albo wypłaty w różnych walutach mogą generować różnice nawet wtedy, gdy wszystkie transakcje zostały prawidłowo rozpoznane. Marketplace może prezentować wartość zamówienia w walucie klienta, raport rozliczeniowy w walucie konta sprzedawcy, a przelew bankowy może być dodatkowo przewalutowany według kursu zastosowanego przez platformę, operatora płatności albo bank. Równolegle dla celów podatkowych mogą obowiązywać odrębne zasady przeliczania waluty zgodnie z przepisami właściwymi dla danego podatku. W efekcie jedna sprzedaż może mieć kilka różnych wartości po przeliczeniu.

W praktyce oznacza to, że różnice kursowe i przewalutowania powinny być wyodrębnione jako osobna kategoria uzgodnienia. Nie warto próbować „dopasować” sprzedaży do przelewu przez ręczne korygowanie przychodu. Najpierw trzeba ustalić, jaka była wartość transakcji podatkowo, a następnie osobno wyjaśnić, z czego wynika różnica pomiędzy tą wartością a faktycznym rozliczeniem pieniężnym.

W praktyce różnice mogą wynikać również z rodzaju raportu pobranego z platformy. Raport sprzedażowy, raport finansowy, settlement czy raport wypłat mogą prezentować tę samą działalność według różnych zasad agregacji i różnych dat. Przed rozpoczęciem uzgodnienia warto więc upewnić się, że porównywane raporty opisują ten sam zakres transakcji i że wiadomo, według jakiej logiki zostały przygotowane.

Korekty rozliczane w innym okresie

Marketplace może rozliczyć refund, chargeback, korektę ceny albo inne zdarzenie kilka dni lub kilka tygodni po pierwotnej sprzedaży. W praktyce oznacza to, że settlement za sierpień może zawierać pozycje odnoszące się do sprzedaży z lipca, czerwca albo nawet wcześniejszych miesięcy. Podobnie rezerwa zatrzymana w jednym cyklu może zostać uwolniona dopiero w kolejnym. Jeżeli przedsiębiorca porównuje tylko miesięczne sumy bez śledzenia takich przesunięć, może dojść do wniosku, że raporty się nie zgadzają, choć różnica wynika wyłącznie z przeniesienia określonej pozycji pomiędzy okresami.

W praktyce oznacza to konieczność prowadzenia uzgodnienia również w czasie, a nie tylko w obrębie jednego miesiąca. Dobrze przygotowane zestawienie powinno pozwalać wskazać, że dana korekta widoczna obecnie dotyczy wcześniejszej sprzedaży i została już uwzględniona albo dopiero wpłynie na konkretną pozycję podatkową.

Sprzedaż zagraniczna i transakcje wymagające odrębnego podejścia

Największe ryzyko pojawia się wtedy, gdy do jednego zestawienia trafiają transakcje, które podatkowo należą do różnych kategorii. Sprzedaż krajowa, OSS, WDT, eksport, procedury szczególne oraz przypadki, w których platforma jest uznawana za dostawcę, nie powinny być mechanicznie analizowane według jednego schematu. Dwie transakcje mogą wyglądać niemal identycznie w panelu marketplace, ale ich wpływ na polski JPK_V7 może być zupełnie inny.

W praktyce oznacza to, że przedsiębiorca planujący ekspansję powinien już na poziomie danych sprzedażowych rozdzielać transakcje według ich charakteru podatkowego. Im większa skala i liczba rynków, tym mniej użyteczna staje się jedna zbiorcza suma sprzedaży. Uzgodnienie powinno być prowadzone w osobnych kategoriach, tak aby każda grupa transakcji trafiała do właściwego sposobu rozliczenia.

Liczba zamówień też nie musi zgadzać się z liczbą pozycji w JPK_V7

Liczba zamówień widocznych w marketplace nie jest właściwym miernikiem zgodności z liczbą pozycji w JPK_V7. Platforma może pokazywać każdą transakcję klienta oddzielnie, podczas gdy ewidencja VAT może, zgodnie z zasadami dokumentowania danej sprzedaży, ujmować określone transakcje zbiorczo. Dotyczy to między innymi sytuacji, w których sprzedaż jest dokumentowana raportem fiskalnym albo innym zbiorczym dokumentem przewidzianym dla danego rodzaju ewidencji. W rezultacie setki lub tysiące pojedynczych zamówień mogą prowadzić do znacznie mniejszej liczby zapisów w pliku JPK_V7.

Najważniejsza jest więc zgodność wartości podatkowych w odpowiednich kategoriach, a nie liczby wierszy. Jeżeli raport marketplace pokazuje 2 000 zamówień, a JPK_V7 kilkanaście lub kilkadziesiąt pozycji odnoszących się do tej sprzedaży, sama różnica ilościowa nie jest dowodem błędu. Problem pojawia się dopiero wtedy, gdy wartości podstaw opodatkowania i VAT należnego nie dają się uzgodnić albo przedsiębiorca nie potrafi wskazać, w jaki sposób poszczególne zamówienia zostały objęte zapisami zbiorczymi.

Co z prowizjami marketplace?

Prowizja nie pomniejsza sprzedaży klientowi

Jeżeli klient kupuje towar za 1 230 zł brutto, a platforma potrąca 123 zł prowizji, wartość sprzedaży klientowi nadal wynosi 1 230 zł brutto. Prowizja nie zmienia ceny, którą klient zapłacił za towar, tylko stanowi odrębne rozliczenie pomiędzy sprzedawcą a platformą. Dlatego nie należy automatycznie obniżać wartości sprzedaży do 1 107 zł tylko dlatego, że tyle pozostało po potrąceniu prowizji. Właśnie takie podejście prowadzi później do rozbieżności pomiędzy raportem sprzedażowym, JPK_V7 i KPiR.

W praktyce oznacza to, że wartość sprzedaży należy ustalać na podstawie transakcji z klientem, a prowizję analizować osobno. Jeżeli platforma potrąca ją bezpośrednio z należnych środków, zmienia to payout, ale nie samą wartość sprzedaży.

Prowizja jest osobnym rozliczeniem kosztowym

Prowizja marketplace może stanowić koszt podatkowy, jeżeli jest prawidłowo udokumentowana i spełnia ogólne warunki zaliczenia wydatku do kosztów uzyskania przychodów. Jeżeli platforma wystawia fakturę z wykazanym polskim VAT i spełnione są warunki odliczenia, odpowiednia kwota może zostać ujęta jako VAT naliczony. W przypadku wielu zagranicznych platform konieczne jest jednak odrębne rozliczenie VAT zgodnie z zasadami dotyczącymi nabycia usług od zagranicznych kontrahentów. Samo potrącenie prowizji z payoutu nie przesądza ani o momencie ujęcia kosztu, ani o prawie do odliczenia VAT.

W praktyce oznacza to, że przychód ze sprzedaży i prowizja powinny być rozliczane jako dwa odrębne zdarzenia. Nie należy „netować” ich tylko dlatego, że platforma technicznie pobiera swoją należność przed wykonaniem przelewu. Najpierw trzeba prawidłowo ustalić wartość sprzedaży, a następnie osobno ocenić dokument, charakter usługi i sposób jej rozliczenia podatkowego.

Co w przypadku zagranicznego usługodawcy?

Jeżeli sprzedaż usługodawcą pobierającym prowizję jest podmiot zagraniczny, trzeba dodatkowo sprawdzić zasady rozliczenia VAT od nabywanej usługi. W wielu przypadkach może pojawić się konieczność rozliczenia importu usług albo zastosowania innych zasad właściwych dla nabycia usług od zagranicznego kontrahenta. Nie oznacza to jednak, że sama towaru klientowi zmienia swoją wartość. Usługa platformy nadal pozostaje odrębnym zdarzeniem od sprzedaży produktu.

W praktyce oznacza to, że przedsiębiorca powinien analizować osobno sprzedaż klientom i zakup usług od zagranicznej platformy. Próba łączenia obu operacji w jedną kwotę „po prowizji” zaciera właściwy obraz rozliczenia i utrudnia późniejsze uzgodnienie JPK_V7, KPiR oraz settlementów.

Najczęstsze błędne porównania

Najczęstsze nieporozumienia wynikają z założenia, że wszystkie raporty powinny prowadzić do jednej liczby. Stwierdzenie „przelew na konto powinien zgadzać się z JPK_V7” jest błędne, ponieważ bank pokazuje przepływ pieniężny, a JPK_V7 dane podatkowe. Podobnie nieprawidłowe jest założenie, że prowizję można po prostu odjąć od przychodu, ponieważ prowizja i sprzedaż są odrębnymi zdarzeniami. Raport brutto z marketplace nie musi też odpowiadać przychodowi w KPiR, ponieważ u czynnego podatnika VAT przychód jest co do zasady ustalany bez VAT należnego.

Równie mylące jest oczekiwanie, że każde zamówienie będzie miało osobny odpowiednik w JPK_V7 albo że każda różnica sum oznacza błąd księgowy. W praktyce część sprzedaży może być ujmowana zbiorczo zgodnie z zasadami jej dokumentowania, a miesięczne rozbieżności mogą wynikać z korekt, różnic w datach, walut, rezerw, rodzaju raportu czy przesunięć między settlementami. Dlatego właściwe pytanie nie brzmi „czy wszystkie liczby są identyczne?”, lecz czy każdą różnicę można logicznie wyjaśnić i powiązać z konkretnym zdarzeniem, dokumentem albo zasadą rozliczenia.

Co się stanie, jeśli tego nie uzgodnisz?

Brak regularnego uzgadniania danych z marketplace nie musi od razu prowadzić do błędu podatkowego, ale znacząco zwiększa ryzyko, że nieprawidłowość pozostanie niezauważona przez kolejne okresy. Przy dużej liczbie transakcji pojedyncza różnica może wyglądać niegroźnie, szczególnie jeśli wynosi kilka lub kilkanaście złotych na zamówieniu. Problem zaczyna się wtedy, gdy podobny mechanizm powtarza się setki albo tysiące razy. W średniej firmie e-commerce niewielkie rozbieżności w sposobie przypisywania stawek, korekt, zwrotów czy opłat mogą po kilku miesiącach przełożyć się na kwoty, których nie da się już sprawdzić jednym raportem. Im większa skala sprzedaży, tym mniej skuteczne jest kontrolowanie danych „na oko” i tym większe znaczenie ma stałe uzgadnianie źródeł.

Błąd może pozostać niewidoczny przez kilka miesięcy

Najbardziej niebezpieczne są nie te błędy, które od razu powodują dużą różnicę, lecz te, które powtarzają się systematycznie. Jeżeli raport z marketplace jest co miesiąc importowany według niewłaściwej daty, część korekt trafia do niewłaściwego okresu albo jedna kategoria sprzedaży jest regularnie przypisywana do niewłaściwej stawki VAT, miesięczna rozbieżność może wydawać się niewielka. Przy dużym wolumenie z czasem zaczyna się jednak kumulować. Po kilku miesiącach przedsiębiorca widzi już nie kilkaset złotych, lecz kilka, kilkanaście albo kilkadziesiąt tysięcy złotych różnicy i nie ma prostego sposobu, żeby ustalić, od którego momentu problem się rozpoczął.

W praktyce oznacza to, że brak miesięcznego uzgodnienia przesuwa moment wykrycia błędu w przyszłość. Zamiast poprawić jedną kategorię transakcji w bieżącym okresie, trzeba później wracać do archiwalnych raportów, odtwarzać ustawienia eksportów, sprawdzać historię refundów i porównywać settlementy z wyciągami bankowymi. Przy ekspansji na kolejne rynki sytuacja staje się jeszcze trudniejsza, ponieważ dochodzą różne waluty, modele rozliczeń i rodzaje transakcji. Regularne reconciliation nie eliminuje wszystkich błędów, ale znacząco ogranicza ryzyko, że mała nieprawidłowość będzie przez pół roku powielana w coraz większej skali.

Możesz wykazać niewłaściwy przychód w KPiR

Jednym z najbardziej praktycznych zagrożeń jest utożsamienie payoutu z przychodem ze sprzedaży. Taki skrót może wydawać się logiczny, bo przelew od marketplace jest konkretną kwotą widoczną na rachunku i łatwo go powiązać z działalnością. Problem polega na tym, że payout może już uwzględniać prowizje, opłaty, refundy, rezerwy, korekty salda i inne pozycje rozrachunkowe. Nie pokazuje więc po prostu wartości sprzedaży, lecz wynik szerszego rozliczenia finansowego z platformą.

Jeżeli przedsiębiorca utożsami payout z przychodem ze sprzedaży, może nieprawidłowo ustalić przychód podatkowy, ponieważ payout obejmuje również elementy inne niż sama sprzedaż. W praktyce taka nieprawidłowość może przez długi czas pozostawać niewidoczna, ponieważ kwota z banku zgadza się z raportem wypłat i sprawia wrażenie „zamkniętej”. Problem ujawnia się dopiero wtedy, gdy ktoś zaczyna porównywać ją z rzeczywistą sprzedażą klientów albo z danymi podatkowymi. Dlatego przychód powinien wynikać z prawidłowo rozpoznanej sprzedaży, a nie z tego, ile środków platforma przelała po rozliczeniu własnych należności i pozostałych pozycji settlementu.

Możesz zaniżyć albo zawyżyć podstawę opodatkowania VAT

Błędy w uzgodnieniu sprzedaży mogą również prowadzić do nieprawidłowego określenia podstawy opodatkowania i VAT należnego. Ryzyko rośnie szczególnie wtedy, gdy firma obsługuje różne stawki VAT, dużą liczbę zwrotów i korekt albo kilka typów transakcji w jednym raporcie. Wystarczy, że część sprzedaży zostanie przypisana do niewłaściwej kategorii, korekta zostanie ujęta w niewłaściwym okresie w stosunku do zasad właściwych dla danej korekty albo dane z raportu zostaną potraktowane jako jedna zbiorcza suma bez rozdzielenia rodzaju transakcji. Wtedy JPK_V7 może nie odzwierciedlać prawidłowo sprzedaży, którą przedsiębiorca powinien wykazać w polskim VAT.

W praktyce problem nie polega wyłącznie na zaniżeniu podatku. Możliwe jest również jego zawyżenie, na przykład wtedy, gdy zwrot albo prawidłowa korekta nie zostaną uwzględnione. Z perspektywy przedsiębiorcy obie sytuacje są niekorzystne. W pierwszej pojawia się ryzyko zaległości i konieczności skorygowania rozliczeń, w drugiej firma może zapłacić więcej podatku, niż wynikałoby to z prawidłowego ujęcia transakcji. Regularne uzgodnienie pozwala wychwycić takie przypadki wcześniej, zanim różnica zacznie obejmować kilka okresów rozliczeniowych.

Rozbieżności mogą wyjść dopiero podczas czynności sprawdzających lub kontroli

Jeżeli dane nie są regularnie uzgadniane wewnętrznie, pierwszym momentem, w którym ktoś zacznie zadawać szczegółowe pytania o rozbieżności, mogą być dopiero czynności sprawdzające albo kontrola. Wtedy nie wystarczy powiedzieć, że „marketplace raportuje inaczej”. Trzeba być w stanie odtworzyć, jaka sprzedaż odpowiada danym wykazanym w JPK_V7, jak ustalono przychód, jakie korekty zastosowano, dlaczego przyjęto określone daty i skąd pochodzi kwota wypłaty. Jeżeli dane pochodzą z kilku raportów i dotyczą tysięcy transakcji, takie odtworzenie może wymagać analizy znacznie bardziej szczegółowej niż zwykłe sprawdzenie miesięcznej sumy.

W praktyce oznacza to konieczność wracania do historycznych plików, raportów finansowych platformy, settlementów, faktur, wyciągów bankowych, korekt i danych transakcyjnych. Im starszy okres, tym większe ryzyko, że zmienił się format raportu, część danych została zarchiwizowana albo osoba odpowiedzialna za wcześniejsze rozliczenie nie pamięta już przyjętego sposobu postępowania. Dlatego warto tworzyć ścieżkę uzgodnienia na bieżąco, kiedy źródła różnicy są jeszcze łatwe do zidentyfikowania, a przyjęta metodologia możliwa do opisania.

Im później znajdziesz różnicę, tym trudniej ustalić jej źródło

Różnica wykryta w tym samym miesiącu jest zazwyczaj znacznie prostsza do wyjaśnienia niż różnica wykryta po pół roku. W bieżącym okresie można jeszcze łatwo sprawdzić konkretne refundy, zmiany cen, prowizje, rezerwy czy nietypowe settlementy. Po kilku miesiącach trzeba już analizować ciąg powiązanych ze sobą zdarzeń. Jedna korekta może odnosić się do sprzedaży z wcześniejszego okresu, jej refund może pojawić się w kolejnym settlementcie, a wypłata związana z tym saldem może zostać wykonana jeszcze później. Bez zachowanej historii uzgodnienia zaczyna się ręczne odtwarzanie procesu od końca.

W praktyce brak spójnej tabeli uzgodnieniowej oznacza często porównywanie starych eksportów, wyciągów bankowych i dokumentów księgowych po jednej pozycji. Przy kilku marketplace i kilku krajach może to oznaczać wiele godzin pracy, które nie tworzą nowej wartości dla firmy, lecz służą jedynie odtworzeniu tego, co można było opisać na bieżąco. Z punktu widzenia rozwijającego się e-commerce jest to również problem operacyjny: im bardziej firma rośnie, tym droższe staje się ręczne tłumaczenie historycznych rozbieżności i tym większe znaczenie ma możliwość odtworzenia nie tylko liczb, ale także założeń, według których dane zostały wcześniej zaklasyfikowane.

Największy problem: nie sama różnica, lecz brak możliwości jej wyjaśnienia

Sama rozbieżność pomiędzy raportem marketplace, JPK_V7, KPiR i bankiem nie jest jeszcze dowodem nieprawidłowości. Jak pokazują wcześniejsze przykłady, różnice mogą wynikać z VAT, prowizji, rezerw, przewalutowań, korekt, innych dat raportowania albo przesunięć pomiędzy settlementami. Ważne jest natomiast to, czy przedsiębiorca potrafi wskazać, która część różnicy pochodzi z konkretnego źródła i czy potrafi przejść od danych sprzedażowych do ewidencji podatkowej oraz od settlementu do przelewu bankowego.

W praktyce dobrze prowadzone uzgodnienie powinno pozwalać odpowiedzieć nie tylko na pytanie „ile wynosi różnica?”, ale przede wszystkim „dlaczego ona istnieje?”. Jeżeli 50 tys. zł rozbieżności można podzielić na zwroty, korekty, rezerwy, prowizje i pozycje odnoszące się do wcześniejszych okresów, sytuacja wygląda zupełnie inaczej niż wtedy, gdy te same 50 tys. zł pozostaje niewyjaśnione. Organ podatkowy co do zasady nie oczekuje, że wszystkie raporty pokażą tę samą liczbę. Problem zaczyna się wtedy, gdy nie potrafisz pokazać, skąd bierze się różnica.

Jak powinna wyglądać miesięczna tabela uzgodnieniowa?

Miesięczna tabela uzgodnieniowa powinna przede wszystkim umożliwiać przejście od danych źródłowych do wartości wykazanych podatkowo i finansowo, przy zachowaniu możliwości odtworzenia zastosowanych założeń. Nie wystarczy więc zapisać samej liczby. W razie późniejszej analizy trzeba również wiedzieć, dlaczego użyto konkretnego raportu, według jakiej daty przypisano transakcję do okresu, dlaczego określona kategoria została wyłączona z porównania albo czemu dana sprzedaż została zakwalifikowana do konkretnego sposobu rozliczenia. W prostszym modelu tabelę można prowadzić według okresów i grup transakcji, a w bardziej złożonym według kraju, kanału sprzedaży, stawki VAT, rodzaju operacji i waluty.

Przy większym wolumenie nie zawsze będzie praktyczne umieszczanie każdej pojedynczej transakcji w głównej tabeli miesięcznej, ale system powinien pozwalać zejść do danych źródłowych. Dlatego identyfikator zamówienia, numer referencyjny, identyfikator settlementu albo inny klucz łączący zestawienie z raportem platformy może być równie ważny jak sama kwota. Dobrze zaprojektowana tabela nie tylko pokazuje, że dane się uzgadniają, ale pozwala również odtworzyć metodę, która doprowadziła do danego wyniku.

Przy większej skali warto dodać również pola dotyczące kursu waluty, rynku sprzedaży, identyfikatora settlementu, salda początkowego i końcowego, rezerw oraz daty użytej do przypisania transakcji do okresu. W przypadku bardziej złożonych modeli pomocne może być także zapisanie krótkiej informacji o tym, dlaczego dana grupa transakcji została włączona albo wyłączona z konkretnego uzgodnienia. Dzięki temu tabela nie jest tylko zbiorem liczb, lecz zapisem metodologii, którą można później odtworzyć.

Tabela nie powinna być traktowana jako kolejny raport tworzony wyłącznie „dla księgowości”. Jej główną rolą jest stworzenie trwałego mostu pomiędzy sprzedażą, podatkami i przepływem pieniężnym. Jeżeli za kilka miesięcy trzeba będzie wyjaśnić konkretną różnicę, dobrze prowadzona tabela powinna pozwolić znaleźć jej źródło, wskazać zastosowane założenia i dojść do danych źródłowych bez ponownego analizowania całej historii sprzedaży od początku.

Checklista: 7 rzeczy do sprawdzenia przed zamknięciem miesiąca

Przy dużej liczbie transakcji najważniejsza jest powtarzalność procesu. Jeżeli uzgodnienie co miesiąc wygląda inaczej, zależy od tego, kto akurat przygotowuje dane albo zaczyna się od przypadkowego raportu pobranego z platformy, z czasem coraz trudniej ocenić, czy rozbieżność wynika z podatków, korekt, różnic w datach czy po prostu z użycia niewłaściwego źródła. Dlatego przed zamknięciem miesiąca warto przejść przez ten sam zestaw kontroli i upewnić się, że sprzedaż, JPK_V7, KPiR, settlementy oraz bank tworzą logiczną i możliwą do odtworzenia ścieżkę. Nie chodzi o to, aby każda liczba była identyczna, lecz aby każda istotna różnica miała przypisaną przyczynę.

1. Określ zakres uzgodnienia. Ustal, które transakcje rzeczywiście porównujesz. Oddziel typową sprzedaż krajową od OSS, WDT, eksportu, transakcji walutowych i innych kategorii wymagających innego sposobu rozliczenia. Sprawdź również, jakiego okresu i jakich dat dotyczy raport marketplace.
2. Wyodrębnij sprzedaż i zdarzenia ją korygujące. Rozdziel sprzedaż klientów, zwroty, anulowania, rabaty i korekty. Pamiętaj, że anulowane zamówienie, które nie doprowadziło do sprzedaży, nie jest tym samym co późniejszy zwrot już zrealizowanej transakcji.
3. Rozbij sprzedaż według stawek VAT i rodzaju transakcji. Ustal wartość netto, VAT i stawkę podatku, ale nie ograniczaj analizy wyłącznie do procentowej stawki. Transakcje o różnym charakterze podatkowym powinny pozostać w osobnych kategoriach.
4. Uzgodnij sprzedaż z JPK_V7. Porównaj podstawy opodatkowania i VAT należny w zakresie sprzedaży, którą przedsiębiorca sam wykazuje w polskim VAT. Uwzględnij moment ujęcia korekt, sposób dokumentowania oraz różnice wynikające z dat stosowanych przez platformę.
5. Uzgodnij przychód z KPiR. Sprawdź, czy sprzedaż daje się powiązać z odpowiadającym jej przychodem podatkowym, z wyłączeniem VAT należnego i z uwzględnieniem właściwego momentu rozpoznania przychodu. Nie zakładaj automatycznie, że jedna miesięczna suma netto z raportu musi być identyczna z jedną sumą w KPiR.
6. Rozlicz prowizje i pozostałe opłaty oddzielnie. Nie pomniejszaj przychodu tylko dlatego, że marketplace potrącił prowizję, reklamę, logistykę albo inną należność przed wypłatą. Każdą opłatę trzeba ocenić według jej charakteru, dokumentu źródłowego oraz zasad właściwych dla kosztów i VAT.
7. Uzgodnij payout z raportem rozliczeniowym i bankiem. Sprawdź, czy wypłata wynika z konkretnego settlementu albo jego części i czy odpowiada przelewowi na rachunku. Uwzględnij waluty, rezerwy, salda przechodzące, podział wypłat, wcześniejsze refundy, chargebacki oraz inne pozycje rozrachunkowe.

Taka kolejność ogranicza ryzyko pomieszania danych podatkowych z przepływami pieniężnymi. Najpierw trzeba ustalić, co rzeczywiście zostało sprzedane i jak powinno zostać ujęte podatkowo, później wyjaśnić rozrachunek z platformą, a dopiero na końcu dopasować payout do banku. Jeżeli któryś z tych etapów nie daje się zamknąć, nie warto „wyrównywać” danych ręczną korektą tylko po to, żeby miesięczna suma wyglądała dobrze. Pozostającą różnicę trzeba zidentyfikować, opisać i powiązać z konkretną transakcją, dokumentem albo pozycją settlementu.

Kiedy prosty model uzgodnienia nie wystarczy?

Prosty model oparty na krajowej sprzedaży własnych towarów jest bardzo użyteczny jako punkt wyjścia, ale nie powinien być stosowany bez zmian do każdej sprzedaży marketplace. Wraz z ekspansją zagraniczną rośnie liczba transakcji, które z zewnątrz mogą wyglądać podobnie, ale podatkowo podlegają innym zasadom. Dotyczy to w szczególności OSS, WDT, eksportu, sprzedaży w walutach, procedury marży, sprzedaży rejestrowanej na kasie fiskalnej, faktur korygujących oraz przypadków, w których platforma jest uznawana za dostawcę. Jeżeli takie transakcje zostaną wrzucone do jednego zestawienia razem ze zwykłą krajową sprzedażą opodatkowaną 23%, końcowa suma może wyglądać spójnie, ale samo uzgodnienie będzie niewiele mówiło o poprawności podatkowej.

OSS, WDT i eksport wymagają osobnego zakresu danych

Sprzedaż zagraniczna powinna być wydzielona już na etapie danych źródłowych. W przypadku OSS znaczenie ma między innymi kraj konsumpcji i sposób rozliczenia podatku należnego w państwie konsumenta. WDT oraz eksport podlegają z kolei własnym zasadom dotyczącym miejsca opodatkowania, dokumentacji i warunków zastosowania właściwego sposobu rozliczenia. Dlatego nie należy porównywać całej sprzedaży zagranicznej z polskim JPK_V7 tak, jakby była zwykłą krajową sprzedażą opodatkowaną według polskich stawek.

W praktyce oznacza to konieczność stworzenia osobnych koszyków danych dla różnych rodzajów transakcji. Dopiero wewnątrz właściwej kategorii można sprawdzać, czy sprzedaż została rozpoznana w odpowiednim miejscu, okresie i systemie rozliczeniowym. Przy kilku krajach taka segmentacja powinna być standardem, a nie dodatkową analizą wykonywaną dopiero wtedy, gdy suma się nie zgadza.

Sprzedaż w walutach wymaga rozdzielenia wartości podatkowej i rozrachunkowej

Przy sprzedaży walutowej jedna transakcja może mieć kilka równoległych wartości. Marketplace może pokazywać kwotę w walucie klienta, raport finansowy w walucie rozliczeniowej konta, bank wartość po kolejnym przewalutowaniu, a ewidencje podatkowe kwotę ustaloną według zasad przeliczenia właściwych dla danego podatku. Jeżeli przedsiębiorca sprowadzi te wartości do jednej liczby bez zachowania informacji o kursie i źródle przeliczenia, różnice kursowe zaczną mieszać się z błędami sprzedażowymi.

W praktyce uzgodnienie powinno zachowywać walutę pierwotną, zastosowany kurs, wartość po przeliczeniu oraz źródło, z którego pochodzi dana liczba. Dzięki temu można oddzielić różnicę wynikającą z samej sprzedaży od różnicy powstałej na etapie rozrachunku finansowego i przewalutowania.

Procedura marży nie pasuje do zwykłego schematu netto plus VAT

Procedura marży wymaga szczególnej ostrożności, ponieważ sposób ustalenia podstawy opodatkowania różni się od standardowej sprzedaży, w której VAT oblicza się od pełnej wartości netto towaru. Dlatego prosty model „sprzedaż brutto minus VAT równa się przychód netto do uzgodnienia” nie powinien być automatycznie stosowany do transakcji rozliczanych według procedury marży. Sam raport marketplace może przy tym nie wskazywać, że dana sprzedaż wymaga innego sposobu traktowania.

W praktyce takie transakcje powinny być oznaczone i analizowane osobno jeszcze przed przygotowaniem porównania z JPK_V7. W przeciwnym razie łatwo uzyskać pozorną rozbieżność wynikającą nie z błędu w danych, lecz z zastosowania niewłaściwego modelu obliczeń.

Sprzedaż na kasie fiskalnej i dokumentowanie zbiorcze zmieniają sposób porównania

Jeżeli sprzedaż jest rejestrowana na kasie fiskalnej albo dokumentowana zbiorczo zgodnie z zasadami właściwymi dla danego typu transakcji, liczba zamówień z marketplace nie będzie odpowiadała liczbie pozycji w ewidencji VAT. Jedno zestawienie może obejmować dużą liczbę pojedynczych transakcji, a w JPK_V7 pojawi się zapis wynikający z raportu zbiorczego. Nie oznacza to, że którejś sprzedaży brakuje.

W praktyce trzeba wówczas kontrolować przede wszystkim wartości podatkowe przypisane do właściwej kategorii i dokumentu zbiorczego. Kluczowe jest zachowanie możliwości zejścia z sumy ewidencyjnej do danych źródłowych, nawet jeżeli sama struktura JPK_V7 nie odzwierciedla każdego zamówienia osobno.

Faktury korygujące mogą przesuwać różnice pomiędzy okresami

Korekty są jednym z najczęstszych powodów, dla których dwa prawidłowe raporty nie pokazują tej samej miesięcznej sumy. Marketplace może zarejestrować refund w jednym momencie, dokument korygujący może zostać wystawiony w innym, a skutki podatkowe powinny zostać ujęte zgodnie z zasadami właściwymi dla danej korekty. Dlatego korekty nie powinny być traktowane wyłącznie jako pozycje „na minus” w okresie, w którym platforma zwróciła klientowi pieniądze.

W praktyce warto każdej większej korekcie albo grupie korekt przypisać okres sprzedaży źródłowej, datę zdarzenia, dokument oraz okres ujęcia podatkowego. Przy większym wolumenie pozwala to kontrolować różnice przechodzące pomiędzy miesiącami bez konieczności ponownego analizowania pełnej historii zamówień.

Gdy platforma jest uznawana za dostawcę, zakres uzgodnienia się zmienia

W określonych modelach marketplace platforma może być traktowana dla celów VAT jako dostawca wobec klienta. W takiej sytuacji nie można automatycznie założyć, że cała wartość widoczna w raporcie platformy powinna zostać wykazana przez sprzedawcę w taki sam sposób jak zwykła własna sprzedaż krajowa. To właśnie dlatego wcześniej tak ważne było ograniczenie uzgodnienia JPK_V7 do sprzedaży, którą przedsiębiorca sam wykazuje w polskim VAT.

W praktyce transakcje tego typu powinny być oznaczone już w danych źródłowych i wyłączone z prostego modelu porównującego całą sprzedaż marketplace z krajową ewidencją VAT. Jeżeli firma rozwija sprzedaż na wielu rynkach, identyfikacja takich przypadków staje się jednym z ważniejszych elementów całego procesu reconciliation.

Podsumowanie: nie szukaj jednej identycznej kwoty

Najczęstszy błąd w analizie danych marketplace zaczyna się od bardzo intuicyjnego założenia: skoro sprzedaż, JPK_V7, KPiR i wypłata dotyczą tej samej firmy i podobnego okresu, gdzieś powinna istnieć jedna liczba, która wszystko połączy. W praktyce takiego wyniku często nie ma i nie powinno być. Raport sprzedażowy opisuje transakcje według metodologii platformy, JPK_V7 pokazuje skutki w VAT, KPiR służy rozliczeniu podatku dochodowego, a settlement i bank opisują przepływ pieniędzy. Prawidłowe uzgodnienie polega na połączeniu tych warstw, a nie na wymuszeniu równości pomiędzy nimi.

W typowym modelu krajowej sprzedaży wartość sprzedaży bez VAT należnego powinna być możliwa do uzgodnienia z odpowiadającym jej przychodem podatkowym w KPiR, po uwzględnieniu zasad rozpoznania przychodu i sposobu dokumentowania. Z kolei podstawę opodatkowania i VAT należny należy uzgadniać z właściwymi częściami ewidencji VAT w zakresie sprzedaży, którą przedsiębiorca sam rozlicza w Polsce. Payout powinien natomiast prowadzić do raportu finansowego lub settlementu i odpowiedniego przelewu bankowego. Nie jest odpowiednikiem przychodu i nie powinien służyć jako skrót do ustalania wartości sprzedaży.

Dobrze działający proces nie kończy się więc stwierdzeniem, że „liczby się zgadzają”. Powinien pozwalać pokazać, jak od zamówień klientów przechodzimy do sprzedaży netto i VAT, jak uwzględniamy zwroty i korekty, w jaki sposób rozpoznajemy przychód i koszty, co dzieje się z prowizjami i pozostałymi opłatami oraz jak z tych wszystkich elementów powstaje saldo rozliczeniowe prowadzące do payoutu. Celem nie jest doprowadzenie wszystkich raportów do jednej liczby, lecz stworzenie spójnej i możliwej do odtworzenia ścieżki od sprzedaży klientowi, przez podatki i rozrachunki, aż do pieniędzy faktycznie wypłaconych na rachunek.

W miarę wzrostu liczby zamówień i wejścia na kolejne rynki ręczne uzgadnianie danych staje się coraz bardziej czasochłonne i podatne na błędy. Dlatego warto budować proces uzgodnienia w sposób powtarzalny i możliwie zautomatyzowany, tak aby każdą istotną różnicę można było wyjaśnić bez ręcznego analizowania tysięcy transakcji.