Black Friday na Amazonie: jak uzgodnić sprzedaż, prowizje, zwroty i VAT przed zamknięciem miesiąca?

Najczęstsze nieporozumienie bierze się z prostego założenia, że skoro Amazon przelał określoną sumę, to właśnie tyle firma „sprzedała”. W praktyce przelew jest wynikiem wielu wcześniejszych zdarzeń i najczęściej obejmuje już potrącenia związane z refundacjami, prowizjami, opłatami za realizację, korektami oraz innymi pozycjami rozrachunkowymi. Nie pokazuje więc sam w sobie pełnej wartości transakcji dokonanych z klientami ani sposobu, w jaki powinien zostać rozliczony VAT. Ten ostatni wymaga dodatkowo ustalenia, kto jest podatnikiem dla konkretnej transakcji, w jakim kraju powstaje obowiązek rozliczenia oraz czy sprzedaż jest wykazywana lokalnie, w procedurze OSS, czy też w określonych przypadkach VAT pobiera i odprowadza marketplace jako deemed supplier. Dlatego najpierw uzgadniasz sprzedaż, VAT, zwroty i koszty na podstawie danych transakcyjnych właściwych dla danego obowiązku, a dopiero później sprawdzasz, czy końcowy rozrachunek można wyjaśnić i powiązać z wypłatą na rachunek bankowy.

Najważniejsza zasada po Black Friday: sprzedaż ≠ wypłata z Amazon

W firmie, która obsługuje setki albo tysiące zamówień dziennie, rachunek bankowy jest ostatnim elementem procesu, a nie jego źródłem. To szczególnie ważne w listopadzie i grudniu, kiedy aktywność sprzedażowa, zwroty oraz wypłaty zaczynają nakładać się na siebie między okresami. Raport związany z settlementem pokazuje przede wszystkim to, co zostało rozliczone w konkretnym cyklu wypłaty, natomiast dane transakcyjne pozwalają ustalić, kiedy rzeczywiście wystąpiła określona aktywność sprzedażowa lub korekta. Jeżeli zamknięcie miesiąca zaczyna się od pytania „ile Amazon nam przelał?”, łatwo pominąć to, co wydarzyło się wcześniej: jakie dostawy rzeczywiście zostały wykonane, w których krajach powstała sprzedaż, kto powinien rozliczyć VAT, jakie refundacje odnoszą się do wcześniejszych transakcji, jakie opłaty zostały naliczone oraz jaka część środków nie została jeszcze wypłacona.

Dla przedsiębiorcy rozwijającego sprzedaż na kilku rynkach ta różnica nie jest wyłącznie problemem księgowym. Wpływa również na ocenę marży, rentowności promocji, efektywności kampanii i płynności. Firma może zakończyć Black Friday z bardzo mocną sprzedażą, a jednocześnie otrzymać wypłatę wyraźnie niższą od wartości transakcji, ponieważ w tym samym settlementcie rozliczono wcześniejsze refundacje, naliczono prowizje i opłaty, a część środków pozostała w rezerwie. Może być też odwrotnie: wypłata otrzymana w pierwszych dniach grudnia będzie obejmowała aktywność z końca listopada. Dlatego sprzedaży nie należy utożsamiać z timingiem wypłaty. Celem prawidłowego zamknięcia miesiąca jest odtworzenie pełnego przepływu od danych transakcyjnych i zasad podatkowych aż do salda rozrachunku oraz banku, bez mieszania tych poziomów w jedną liczbę.

Co naprawdę zawiera przelew od Amazon?

Przelew od Amazon nie jest prostym odzwierciedleniem wartości sprzedaży z danego miesiąca. Jest efektem rozrachunku obejmującego wiele różnych kategorii finansowych. W jego tle znajdują się należności wynikające ze sprzedaży, ale również refundacje dla klientów, prowizje sprzedażowe, opłaty za realizację zamówień, magazynowanie i inne usługi, koszty reklamowe, jeżeli są rozliczane w danym settlementcie, a także różnego rodzaju korekty. Dodatkowo część środków może zostać czasowo zatrzymana w rezerwie albo przeniesiona do kolejnego cyklu wypłaty. W rezultacie kwota widoczna na rachunku bankowym jest końcowym saldem określonego cyklu rozliczeniowego, a nie raportem sprzedaży za listopad. To rozróżnienie staje się szczególnie ważne po Black Friday, kiedy gwałtownie rośnie zarówno wolumen zamówień, jak i liczba operacji powiązanych z wcześniejszymi lub późniejszymi okresami.

Z punktu widzenia zamknięcia miesiąca przelew należy więc traktować jako kwotę netto rozrachunku, którą trzeba następnie uzgodnić z danymi źródłowymi. Nie można na jego podstawie automatycznie określić wartości sprzedaży ani VAT, ponieważ poszczególne elementy settlementu mają różny charakter. Refundacja koryguje wcześniejszą transakcję sprzedażową, prowizja jest opłatą za usługę, rezerwa jest przesunięciem w czasie wypłaty, a korekta może wynikać z jeszcze innego zdarzenia. Również samo potrącenie opłaty w settlementcie nie przesądza o sposobie jej ujęcia podatkowego. Przy usługach trzeba sprawdzić dokument, podmiot świadczący usługę, kraj kontrahenta, wykazany VAT oraz to, czy po stronie sprzedawcy powstaje obowiązek rozliczenia importu usług lub reverse charge. Dlatego bank potwierdza dopiero końcowy etap przepływu pieniędzy, ale nie zastępuje analizy sprzedaży, VAT i kosztów.

Dlaczego zaksięgowanie samego przelewu zniekształca wynik?

Jeżeli przelew netto zostanie potraktowany jako wartość sprzedaży bez rozbicia składających się na niego pozycji, co do zasady zniekształci prezentację sprzedaży, kosztów i rozrachunków. W jednej kwocie mogą zostać ukryte zarówno wpływy ze sprzedaży, jak i refundacje, prowizje, opłaty logistyczne, koszty innych usług, korekty oraz zmiany rezerwy. W efekcie firma traci możliwość odpowiedzi na podstawowe pytania zarządcze: jaka była rzeczywista wartość sprzedaży w okresie, ile kosztował kanał marketplace, jaka część wyniku została pochłonięta przez fulfillment, jak duży był wpływ refundacji i czy pogorszenie przepływów pieniężnych wynikało z niższej sprzedaży, czy wyłącznie z timingu rozliczeń. Przy działalności prowadzonej na kilku rynkach taki skrót utrudnia także porównanie rentowności krajów i może prowadzić do błędnych decyzji o zwiększeniu budżetu reklamowego, zapasu lub skali operacji.

Jeszcze większego znaczenia nabiera to przy VAT. Podatek nie powinien być ustalany na podstawie samego momentu wypłaty przez marketplace, lecz na podstawie danych właściwych dla rozpoznania konkretnej transakcji i obowiązujących dla niej zasad. Samo złożenie zamówienia nie przesądza jeszcze o momencie powstania sprzedaży ani obowiązku podatkowego. Trzeba ustalić, czy doszło do wykonanej dostawy, gdzie znajduje się miejsce opodatkowania, jaka stawka ma zastosowanie oraz kto jest zobowiązany do rozliczenia VAT. W standardowej sprzedaży B2C prowadzonej przez przedsiębiorcę z UE obowiązek może należeć do sprzedawcy i być rozliczany między innymi przez OSS, ale w określonych przypadkach marketplace może działać jako deemed supplier i pobierać oraz odprowadzać VAT we własnym zakresie. Również późniejsza refundacja powinna zostać powiązana z pierwotną transakcją, ale nie oznacza to automatycznie mechanicznego cofnięcia korekty VAT do miesiąca pierwotnej sprzedaży. Właściwy sposób i okres ujęcia korekty trzeba ustalić zgodnie z zasadami mającymi zastosowanie do danej transakcji i procedury rozliczeniowej.

Jak wygląda prawidłowy łańcuch uzgodnienia?

Prawidłowe zamknięcie zaczyna się od danych transakcyjnych, ale nie od prostego założenia, że każde zamówienie automatycznie oznacza sprzedaż i VAT w tym samym momencie. Najpierw trzeba ustalić, które zdarzenia doprowadziły do wykonanej dostawy lub innej transakcji podlegającej rozpoznaniu w danym okresie. Następnie należy określić kraj opodatkowania, właściwą stawkę i podmiot zobowiązany do rozliczenia VAT. Przy sprzedaży transgranicznej oznacza to sprawdzenie między innymi, czy dana transakcja jest rozliczana lokalnie, w ramach OSS, czy w modelu, w którym marketplace jest traktowany jako deemed supplier. Szczególnej uwagi wymagają firmy korzystające z magazynów w kilku państwach, ponieważ samo korzystanie z OSS nie eliminuje wszystkich lokalnych obowiązków związanych z VAT i przepływem własnych zapasów.

Dopiero po rozpoznaniu właściwych transakcji można przejść do refundacji i innych korekt. Refundację należy powiązać z pierwotną transakcją, a następnie ustalić właściwy sposób i okres ujęcia korekty sprzedaży oraz VAT. Kolejnym poziomem są prowizje i opłaty związane z marketplace. Powinny być analizowane oddzielnie od sprzedaży, z uwzględnieniem dokumentów dotyczących konkretnych usług oraz ich skutków podatkowych. Sam fakt, że opłata została potrącona z settlementu, nie oznacza jeszcze, że można ją bez dodatkowej analizy potraktować jako jednolity koszt. Dopiero po uporządkowaniu sprzedaży, VAT, refundacji, prowizji, usług i pozostałych korekt można przejść do uzgodnienia settlementu, a na końcu sprawdzić, czy wynik rozrachunku odpowiada wypłacie widocznej na rachunku bankowym.

Prawidłowy łańcuch wygląda więc następująco: dane zamówienia ustalenie wykonanej dostawy lub transakcji podatkowej kraj i stawka VAT ustalenie, kto rozlicza VAT korekty i refundacje prowizje oraz opłaty settlement bank. Nie chodzi o to, aby każda z tych wartości była sobie równa, ponieważ z natury opisują różne etapy procesu. Chodzi o możliwość przejścia od jednego poziomu do kolejnego i wyjaśnienia każdej różnicy. Jeżeli wartość sprzedaży jest wyższa od wypłaty, powinno być wiadomo, jaka część różnicy wynika z refundacji, jaka z opłat, jaka z korekt, a jaka z rezerwy lub przesunięcia między cyklami. Taki model pozwala oddzielić trzy rzeczy, które przy szybkim wzroście e-commerce bardzo łatwo pomylić: ekonomiczną wartość sprzedaży, sposób rozliczenia VAT oraz kwotę, którą marketplace faktycznie wypłacił firmie.

Czy ten proces jest dla mnie?

Powinieneś szczególnie zadbać o uzgodnienie, jeśli…

Ten proces jest szczególnie ważny, jeśli sprzedaż na Amazonie przestała być dla Twojej firmy dodatkowym kanałem, a stała się istotną częścią obrotu. Im więcej krajów obsługujesz, tym trudniej polegać na prostym porównaniu sprzedaży z kwotami wpływającymi na konto. Dotyczy to zwłaszcza firm korzystających z FBA, przechowujących zapas w więcej niż jednym państwie, rozliczających sprzedaż B2C przez OSS albo łączących sprzedaż B2C i B2B. Raporty rozliczeniowe i wypłaty mogą obejmować wiele transakcji, korekt i opłat, często dotyczących różnych okresów aktywności, a w działalności międzynarodowej także różnych rynków i stawek VAT. Do tego dochodzą przepływy zapasu pomiędzy magazynami, które nie są sprzedażą do klienta, ale mogą mieć odrębne znaczenie dla obowiązków VAT. Im bardziej międzynarodowy staje się biznes, tym bardziej potrzebujesz uzgodnienia opartego na danych transakcyjnych, a nie na jednej kwocie z banku.

Sygnałem ostrzegawczym jest również sytuacja, w której po Black Friday rośnie liczba pełnych i częściowych refundacji, wypłaty zaczynają wyraźnie odbiegać od wartości sprzedaży, część środków pozostaje w rezerwie albo firma rozlicza kilka walut. Warto przyjrzeć się procesowi także wtedy, gdy księgowość próbuje odtworzyć miesięczną sprzedaż głównie z wyciągu bankowego, a różnice są później wyjaśniane ręcznie. Taka metoda może jeszcze funkcjonować przy niewielkim wolumenie, ale wraz ze wzrostem liczby zamówień staje się coraz mniej wiarygodna i coraz bardziej czasochłonna. Dla średniej firmy e-commerce planującej wejście na kolejne rynki ważne jest, aby proces był skalowalny: powinien pozwalać wyjaśnić, skąd wzięła się każda istotna różnica, bez odtwarzania całego miesiąca od początku przy każdym zamknięciu.

Kiedy temat staje się szczególnie pilny?

Największe ryzyko pojawia się wtedy, gdy listopadowa sprzedaż gwałtownie rośnie, a duża część transakcji przypada na ostatnie dni miesiąca. W takim okresie naturalnie zwiększa się liczba pozycji, które przechodzą między listopadem i grudniem. Sprzedaż może zostać rozpoznana w jednym okresie, podczas gdy odpowiadająca jej wypłata pojawi się dopiero w kolejnym cyklu settlementowym. Jednocześnie część klientów rozpocznie zwrot już po zakończeniu Black Friday, więc refundacje związane z listopadowymi transakcjami zaczną pojawiać się w grudniu. Nie oznacza to automatycznie, że każdą taką korektę trzeba „cofnąć” do listopada. Trzeba natomiast powiązać ją z pierwotną transakcją i ustalić właściwy sposób oraz okres ujęcia korekty sprzedaży i VAT. Bez tego trudno odróżnić zwykłe przesunięcie czasowe od rzeczywistego błędu.

Pilność rośnie jeszcze bardziej, jeżeli jednocześnie sprzedajesz i magazynujesz towary w kilku państwach. Wtedy zamknięcie miesiąca nie sprowadza się już do ustalenia jednej wartości sprzedaży i jednego VAT. Jeżeli firma przechowuje towary w kilku państwach, podobnie wyglądające zamówienia klientów mogą mieć różny sposób rozliczenia VAT — zależnie między innymi od kraju wysyłki, kraju dostawy, statusu nabywcy i modelu transakcji. Trzeba ustalić, czy dana sprzedaż trafia do lokalnej deklaracji, OSS czy w określonych przypadkach jest rozliczana przez marketplace jako deemed supplier. Black Friday zwiększa jedynie skalę problemu, który normalnie może pozostawać niewidoczny. Przy kilkukrotnie większym wolumenie jedna nieprawidłowa reguła klasyfikacji zaczyna działać na setkach albo tysiącach transakcji, dlatego listopadowe zamknięcie jest dobrym momentem, aby wykryć słabości procesu przed dalszą ekspansją. W praktyce zamknięcie powinno rozdzielać trzy osie czasu: moment aktywności sprzedażowej, okres właściwy dla ujęcia księgowego i VAT oraz moment rozliczenia i wypłaty przez Amazon. Ich automatyczne utożsamienie jest jednym z głównych źródeł różnic po Black Friday.

Co się stanie, jeśli tego nie zrobisz przed zamknięciem miesiąca?

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

Jeżeli przelew netto zostanie potraktowany jak wartość miesięcznej sprzedaży, księgi mogą przestać pokazywać rzeczywistą skalę działalności prowadzonej na marketplace. Problem nie polega wyłącznie na tym, że wypłata może być niższa od wartości transakcji z klientami. W jednej kwocie mogą być już uwzględnione zarówno refundacje, prowizje, opłaty za realizację zamówień, korekty, zmiany rezerwy, jak i inne pozycje wpływające na saldo. Potraktowanie tego wyniku jako sprzedaży powoduje więc, że różne zdarzenia gospodarcze zostają połączone w jedną liczbę. Zniekształca to obraz sprzedaży, kosztów i rozrachunków oraz utrudnia późniejsze ustalenie, dlaczego marża w danym miesiącu zmieniła się bardziej, niż wynikałoby to z cen, kosztu towaru czy budżetów reklamowych.

Dla rozwijającej się firmy konsekwencje szybko wychodzą poza księgowość. Jeśli zarząd analizuje rentowność rynku na podstawie danych, w których sprzedaż jest już pomniejszona o część opłat i refundacji, może dojść do błędnych wniosków na temat marży, skuteczności promocji i potencjału danego kraju. Jeden rynek może wyglądać na słabszy tylko dlatego, że w jego rozliczeniach skumulowały się wcześniejsze korekty albo większa część opłat. Inny może chwilowo wyglądać lepiej z powodu przesunięcia wypłat. Przy planowaniu ekspansji takie różnice mają znaczenie, ponieważ decyzje o zapasie, zatrudnieniu, budżetach marketingowych i wejściu do kolejnego kraju powinny opierać się na rzeczywistych wynikach działalności, a nie na przepływach pieniężnych pomieszanych z mechaniką rozrachunku marketplace.

VAT może trafić do niewłaściwego okresu lub kraju

Najbardziej kosztowne błędy mogą pojawić się wtedy, gdy timing wypłaty zostanie potraktowany jako wskazówka do ustalenia momentu rozliczenia VAT. Wypłata z grudnia może zawierać środki związane z aktywnością z końca listopada, ale sama data przelewu nie przesądza o tym, w którym okresie dana transakcja powinna zostać wykazana podatkowo. Trzeba ustalić datę właściwą dla rozliczenia transakcji zgodnie z przepisami danego kraju lub procedury, a następnie określić miejsce opodatkowania oraz zasady właściwe dla konkretnego modelu sprzedaży. W działalności transgranicznej dochodzi do tego kraj wysyłki i dostawy, status klienta oraz to, czy sprzedaż rozliczana jest lokalnie, przez OSS czy w szczególnym modelu, w którym VAT pobiera i odprowadza marketplace. Zignorowanie tych elementów może prowadzić do wykazania prawidłowej kwoty w niewłaściwej deklaracji albo niewłaściwym okresie.

Ryzyko rośnie wraz z liczbą krajów i stawek VAT. Jeżeli firma przechowuje towary w kilku państwach, podobnie wyglądające zamówienia klientów mogą mieć różny sposób rozliczenia VAT — zależnie między innymi od kraju wysyłki, kraju dostawy, statusu nabywcy i modelu transakcji. Niewłaściwa reguła przypisująca kraj opodatkowania może powielać się na dużym wolumenie, a błąd staje się widoczny dopiero przy uzgadnianiu deklaracji lub podczas późniejszej kontroli. Podobnie jest z refundacjami: trzeba wiedzieć, której transakcji dotyczą i według jakich zasad powinna zostać ujęta korekta, zamiast automatycznie przypisywać ją do okresu wypłaty albo pierwotnego zamówienia. Dlatego poprawne uzgodnienie VAT wymaga danych transakcyjnych i podatkowych, a nie rekonstrukcji obowiązku na podstawie salda settlementu.

Prowizje mogą zostać błędnie potraktowane jako obniżenie sprzedaży

Kiedy prowizja zostaje potrącona przed wypłatą, z perspektywy rachunku bankowego po prostu zmniejsza się kwota, która trafia na konto. Nie oznacza to jednak, że można potraktować ją jako automatyczne pomniejszenie wartości sprzedaży. Ekonomicznie transakcja z klientem i opłata naliczona przez marketplace są odrębnymi zdarzeniami, które powinny zostać właściwie zidentyfikowane i rozliczone. Jeżeli oba zostaną złączone w jednej kwocie, firma traci informację o faktycznej skali sprzedaży oraz kosztach korzystania z kanału. Przy większym biznesie ma to realne znaczenie dla kontroli marży. Bez osobnego pokazania opłat trudno ustalić, jaka część wyniku jest efektem rabatów i refundacji dla klientów, a jaka wynika z prowizji, fulfillmentu, magazynowania czy innych pozycji związanych z prowadzeniem sprzedaży.

Nie należy przy tym zakładać, że każda potrącona pozycja ma identyczny sposób ujęcia podatkowego. Settlement pomaga uzgodnić rozrachunek, ale nie zastępuje analizy dokumentów dotyczących poszczególnych usług i opłat. Dla prawidłowego ujęcia trzeba sprawdzić, kto wystawia dokument, z jakiego kraju świadczona jest usługa, czy na fakturze widnieje VAT i czy po stronie polskiego sprzedawcy powstaje obowiązek rozliczenia importu usług, w tym VAT na zasadzie reverse charge. Tak samo koszty reklamowe powinny być analizowane zgodnie z dokumentem i sposobem ich rozliczenia, a nie tylko dlatego, że dana kwota pojawiła się w raporcie płatniczym. Jeżeli firma tego nie robi, może jednocześnie błędnie prezentować sprzedaż i niewłaściwie klasyfikować koszty, co utrudnia zarówno księgowość, jak i ocenę rzeczywistego kosztu działania na marketplace.

Zwroty mogą zostać rozliczone podwójnie albo wcale

Po Black Friday zwroty są szczególnie trudne do kontroli, ponieważ duża część z nich pojawia się już po zakończeniu miesiąca, w którym powstała pierwotna sprzedaż. Jeżeli firma patrzy wyłącznie na kolejne settlementy, refundacja może zostać błędnie potraktowana jako niezależne pomniejszenie bieżącej sprzedaży, mimo że ekonomicznie odnosi się do wcześniejszej transakcji. W odwrotnej sytuacji zespół może wcześniej wprowadzić korektę ręcznie, a następnie ponownie uwzględnić ją przy księgowaniu settlementu, co prowadzi do podwójnego rozliczenia tej samej pozycji. Dlatego każda refundacja powinna mieć możliwe do odtworzenia połączenie z pierwotną transakcją, a dopiero później należy ustalić sposób i okres jej ujęcia jako korekty sprzedaży oraz VAT zgodnie z właściwymi zasadami.

Jeszcze łatwiej o błąd przy częściowych refundacjach albo sytuacjach, w których klient otrzymuje zwrot pieniędzy bez fizycznego odesłania całego towaru. Wtedy przepływ pieniędzy i przepływ magazynowy nie muszą być identyczne. Jeśli proces uzgodnienia opiera się na założeniu, że każdej refundacji musi odpowiadać pełny powrót produktu do zapasu, różnice mogą być klasyfikowane jako błędy, mimo że transakcja przebiegła prawidłowo. Z drugiej strony sama informacja o zwrocie towaru nie wystarcza jeszcze do ustalenia kwoty korekty finansowej. Przy dużej skali potrzebne jest więc rozdzielenie zdarzenia sprzedażowego, finansowego i magazynowego, ponieważ dopiero ich zestawienie pozwala zobaczyć, czy klient otrzymał właściwą kwotę, czy korekta została ujęta raz i czy związany z nią VAT został potraktowany zgodnie z właściwymi zasadami.

Różnice między księgami a bankiem zaczną narastać

Jedna niewyjaśniona różnica pomiędzy księgami, settlementem i rachunkiem bankowym rzadko pozostaje problemem wyłącznie jednego miesiąca. Część środków może zostać w rezerwie, wypłata może nastąpić w kolejnym cyklu, a późniejszy chargeback, refundacja lub korekta może ponownie zmienić saldo. Jeżeli listopad zostanie zamknięty bez wskazania, co dokładnie składa się na różnicę między aktywnością transakcyjną a wypłatą, w grudniu zespół zaczyna pracę już z saldem, którego nie potrafi w pełni wyjaśnić. Następnie dochodzą nowe transakcje i kolejne korekty. Po kilku tygodniach trudno powiedzieć, która część różnicy jest normalnym przesunięciem czasowym, która wynika z rezerwy, a która jest rzeczywistym błędem wymagającym korekty.

W praktyce problem objawia się często jako rosnące konto rozrachunkowe, którego saldo jest przenoszone z miesiąca na miesiąc bez jasnego wyjaśnienia. Przy kilku marketplace’ach, walutach i krajach takie różnice szybko zaczynają pochłaniać czas księgowości i działu finansowego. Zamiast analizować bieżące wyniki, zespół wraca do historycznych raportów, szuka konkretnych wypłat i próbuje ręcznie dopasować pozycje sprzed kilku tygodni. Dobrze wykonane uzgodnienie powinno działać inaczej: każda istotna kwota pozostająca na koniec miesiąca powinna mieć jasne wyjaśnienie i oczekiwany dalszy przebieg. Dzięki temu grudniowa wypłata dotycząca listopadowych transakcji nie jest „różnicą do zbadania”, lecz przewidzianym elementem rozrachunku.

Problemy listopada mogą ujawnić się dopiero w grudniu lub styczniu

Black Friday tworzy warunki, w których błędy przez pewien czas mogą pozostać niewidoczne. W listopadzie zespół widzi rekordową sprzedaż i koncentruje się przede wszystkim na realizacji zamówień, dostępności zapasu i obsłudze klientów. Dopiero w grudniu zaczynają napływać refundacje, kolejne settlementy oraz wypłaty dotyczące transakcji z końcówki poprzedniego miesiąca. Jeżeli listopad został zamknięty bez dokładnego uzgodnienia, nowe dane nakładają się na stare różnice. W styczniu może dojść jeszcze kolejna warstwa korekt, chargebacków, opłat i przesunięć. Powstaje wtedy efekt kuli śnieżnej: każda nowa pozycja jest analizowana na tle salda, które już wcześniej nie było w pełni wyjaśnione, więc znalezienie źródła problemu wymaga coraz większej pracy.

Dla firmy planującej ekspansję jest to szczególnie niebezpieczne, ponieważ wraz z wejściem na nowe rynki liczba możliwych kombinacji rośnie. Dochodzą kolejne stawki VAT, magazyny, waluty, modele dostaw i dokumenty dotyczące usług. Proces, który przy jednym kraju generował kilka godzin dodatkowej pracy miesięcznie, po rozszerzeniu działalności może stać się trwałym problemem operacyjnym. Dlatego warto zatrzymać efekt kuli śnieżnej już przy pierwszym zamknięciu po Black Friday. Jeżeli na koniec listopada wiadomo, jakie transakcje należą do okresu, jak zostały potraktowane podatkowo, jakie korekty są już ujęte, jakie opłaty zostały naliczone oraz które środki pozostają do wypłaty, kolejne miesiące zaczynają się od salda, którego charakter i dalszy przebieg można jasno wyjaśnić.

Jakie dane trzeba zebrać przed rozpoczęciem uzgodnienia?

Dane o sprzedaży i VAT

Punktem wyjścia powinny być dane pozwalające odtworzyć aktywność sprzedażową na poziomie pojedynczych transakcji, a następnie przypisać jej właściwy sposób ujęcia księgowego i podatkowego. W praktyce potrzebujesz co najmniej wartości netto, kwoty VAT i wartości brutto, stawki podatku, kraju wysyłki i kraju dostawy, statusu transakcji B2B lub B2C, unikalnego identyfikatora zamówienia albo transakcji oraz numeru właściwego dokumentu. Przy sprzedaży prowadzonej wyłącznie w Polsce część tych informacji może wydawać się drugorzędna, ale przy ekspansji zagranicznej każda zaczyna pełnić konkretną funkcję. Kraj wysyłki i dostawy pomaga określić charakter transakcji, status klienta wpływa na sposób jej klasyfikacji dla VAT, a identyfikator zamówienia pozwala później połączyć sprzedaż z refundacją, korektą lub settlementem. Bez tego poziomu szczegółowości można uzgodnić miesięczną sumę, a jednocześnie nie zauważyć, że część transakcji została przypisana do niewłaściwego kraju, stawki albo sposobu rozliczenia.

Trzeba również pamiętać, że kwota VAT widoczna w danych marketplace nie zawsze oznacza podatek, który ostatecznie ma wykazać sprzedawca. W zależności od modelu transakcji VAT może być rozliczany lokalnie, przez OSS albo w określonych przypadkach pobierany i odprowadzany przez marketplace jako deemed supplier. Dlatego dane sprzedażowe powinny pozwalać ustalić nie tylko wartość netto, brutto i zastosowaną stawkę, lecz również kto rozlicza VAT i według jakiego modelu. W firmie przechowującej towary w kilku państwach ważne jest także zachowanie informacji o miejscu rozpoczęcia wysyłki, ponieważ podobnie wyglądające zamówienia klientów mogą mieć różne konsekwencje podatkowe. Im wcześniej dane zostaną zagregowane do jednej miesięcznej kwoty, tym trudniej później odtworzyć status klienta, kraj opodatkowania, właściwy dokument i sposób rozliczenia konkretnej transakcji.

Dane o zwrotach i refundacjach

Zwroty i refundacje powinny tworzyć odrębną warstwę danych, ponieważ po Black Friday ich liczba szybko rośnie, a duża część pojawia się już po zakończeniu miesiąca, w którym miała miejsce pierwotna aktywność sprzedażowa. Potrzebujesz informacji zarówno o pełnych zwrotach, jak i częściowych refundacjach oraz innych korektach wartości transakcji. Najważniejsze jest jednak zachowanie możliwego do odtworzenia powiązania z pierwotnym zamówieniem lub transakcją. Sama informacja, że klient otrzymał 40 EUR refundacji, nie wystarcza, jeśli nie wiadomo, którego zamówienia dotyczyła, jaka była jego pierwotna wartość, jaki status miał nabywca, w jakim kraju transakcja była rozliczana i jaka stawka VAT została zastosowana. Takie powiązanie jest szczególnie ważne przy częściowych zwrotach, kiedy korekta obejmuje tylko jeden produkt, część ceny albo wybrany element wielopozycyjnego zamówienia.

Warto zachować pierwotną stawkę VAT oraz pozostałe parametry podatkowe transakcji zamiast próbować odtwarzać je na podstawie informacji dostępnych w momencie refundacji. Korekta pozostaje ekonomicznie związana z wcześniejszą sprzedażą, nawet jeśli pojawia się w innym miesiącu albo settlementcie. Nie oznacza to jednak, że każdą grudniową refundację należy automatycznie cofać do listopada. Najpierw trzeba zidentyfikować transakcję źródłową, a następnie ustalić właściwy sposób i okres ujęcia korekty sprzedaży oraz VAT zgodnie z zasadami obowiązującymi dla danego rodzaju sprzedaży i procedury. Przy większym wolumenie takie połączenie powinno być możliwe bez ręcznego przeglądania setek zamówień, ponieważ właśnie brak relacji pomiędzy refundacją a pierwotną transakcją jest jedną z najczęstszych przyczyn trudnych do wyjaśnienia różnic po okresach promocyjnych.

Dane o prowizjach, opłatach i innych korektach

Kolejny zestaw informacji obejmuje prowizje sprzedażowe, opłaty za fulfillment i magazynowanie, abonamenty, koszty reklamowe, jeżeli są rozliczane w danym modelu płatności, opłaty związane ze zwrotami oraz inne adjustments wpływające na rozrachunek. Ważne jest, aby nie wrzucać wszystkich tych pozycji do jednego worka pod nazwą „koszty Amazon”, ponieważ nie każda pozycja widoczna w settlementcie ma taki sam charakter. Typowa prowizja sprzedażowa lub opłata za realizację zamówienia jest czymś innym niż refundacja dla klienta, zmiana rezerwy czy korekta techniczna zwiększająca albo zmniejszająca saldo. Z punktu widzenia właściciela firmy ten podział ma również znaczenie zarządcze. Dopiero po rozdzieleniu prowizji, fulfillmentu, magazynowania i innych opłat można ocenić, ile naprawdę kosztuje dany kanał sprzedaży i co dzieje się z marżą w okresie Black Friday.

Sam settlement nie przesądza jednak o sposobie podatkowego ani księgowego ujęcia każdej pozycji. W przypadku usług potrzebne są właściwe dokumenty, informacje o podmiocie wystawiającym fakturę, jego kraju oraz ewentualnym VAT wykazanym na dokumencie. Nie powinno się ustalać sposobu rozliczenia wyłącznie na podstawie nazwy opłaty widocznej w raporcie albo samego faktu, że została potrącona przed wypłatą. Przy usługach zagranicznych po stronie polskiego sprzedawcy może powstać obowiązek rozliczenia importu usług, w tym VAT na zasadzie reverse charge. Z kolei inne korekty settlementowe mogą wpływać wyłącznie na rozrachunek i wymagać innej klasyfikacji. Dlatego w zamknięciu miesiąca potrzebujesz zarówno danych o potrąceniach i adjustments, jak i faktur, not korygujących oraz innych dokumentów wyjaśniających charakter tych pozycji.

Dane o rozliczeniach i wypłatach

Dane settlementowe są potrzebne po to, aby połączyć wcześniejsze warstwy uzgodnienia z rzeczywistym przepływem pieniędzy. Kluczowe są identyfikator rozliczenia, kwota wypłaty oraz dostępne informacje pozwalające odtworzyć saldo danego cyklu, w tym rezerwy, refundacje, korekty i inne pozycje przenoszone między okresami rozliczeniowymi. Nie należy przy tym zakładać, że każdy raport będzie miał identyczną strukturę albo taki sam zestaw kolumn. Celem nie jest znalezienie konkretnego pola o określonej nazwie, lecz możliwość odpowiedzi na pytanie, dlaczego z danego zestawu transakcji i potrąceń powstała właśnie taka kwota wypłaty. Jeżeli część środków została zatrzymana w rezerwie albo rozliczenie określonych transakcji zostało odroczone, różnica pomiędzy aktywnością sprzedażową a bankiem może być całkowicie prawidłowa, pod warunkiem że można ją zidentyfikować i później śledzić.

Osobnej uwagi wymagają waluty i przewalutowania. W działalności międzynarodowej transakcje mogą być raportowane w walucie lokalnego rynku, podczas gdy wypłata trafia na rachunek w innej walucie. W takim przypadku trzeba ustalić, czy i gdzie nastąpiło przeliczenie oraz jaki miało wpływ na ostateczną wartość przelewu. Jednocześnie należy rozdzielić dwa różne zagadnienia: kurs zastosowany przez marketplace lub operatora płatności do przeliczenia wypłaty oraz kurs właściwy dla ujęcia księgowego albo rozliczenia VAT. Nie muszą być takie same. Dlatego różnica wynikająca z przewalutowania nie powinna automatycznie trafiać do kategorii „niewyjaśnione”, ale też nie można zakładać, że kurs wykorzystany do wypłaty jest jednocześnie właściwym kursem podatkowym. Przy większej liczbie walut to rozróżnienie staje się niezbędne, żeby nie mieszać różnic kursowych z błędami w samym settlementcie.

Dlaczego same raporty zamówień nie wystarczą?

Raporty zamówień mogą być bardzo pomocne, ale pokazują tylko jedną warstwę procesu. Pozwalają zidentyfikować aktywność klientów, produkty, wartości zamówień czy kierunki dostaw, lecz nie pokazują całej drogi pieniądza od transakcji do wypłaty. Po drodze mogą pojawić się refundacje, częściowe korekty, prowizje, fulfillment, opłaty magazynowe, rezerwy, chargebacki i inne adjustments, które zmieniają rozrachunek z marketplace. Dodatkowo data widoczna przy zamówieniu nie musi być automatycznie datą właściwą dla księgowości lub VAT. W profesjonalnym zamknięciu miesiąca nie powinno się więc przyjmować, że jeden raport zamówień jest kompletną odpowiedzią na pytanie, jaka sprzedaż należy do okresu i jaka kwota powinna finalnie znaleźć się w banku.

Dane o zamówieniach są jedną z warstw wejściowych do uzgodnienia, ale same nie stanowią kompletnej podstawy zamknięcia miesiąca. Potrzebujesz również danych transakcyjnych i podatkowych, refundacji, dokumentów dotyczących opłat oraz raportów settlementowych i banku. W praktyce szczególnie ważne jest rozdzielenie trzech osi czasu: momentu aktywności sprzedażowej, okresu właściwego dla ujęcia księgowego i VAT oraz momentu settlementu i wypłaty. Te daty nie muszą się pokrywać i po Black Friday bardzo często się nie pokrywają. Jeśli firma próbuje odtworzyć listopad wyłącznie na podstawie zamówień albo wyłącznie na podstawie wypłat, zawsze będzie brakować części obrazu. Dopiero zestawienie kilku źródeł pozwala przejść od pojedynczej transakcji przez jej skutki podatkowe i finansowe aż do końcowego wpływu na rachunek.

Jak uzgodnić Black Friday krok po kroku przed zamknięciem miesiąca?

Krok 1. Ustal właściwą granicę okresu

Pierwszym zadaniem nie powinno być porównanie wartości sprzedaży z bankiem, lecz ustalenie, które zdarzenia należą do zamykanego miesiąca z punktu widzenia księgowego i podatkowego. Po Black Friday ma to szczególne znaczenie, ponieważ duża część transakcji przypada na ostatnie dni listopada, a ich finansowe rozliczenie może nastąpić dopiero w grudniu. Równocześnie część klientów zacznie zwracać towary już po zakończeniu miesiąca, niektóre środki mogą pozostać w rezerwie, a inne pozycje zostaną rozliczone w kolejnych cyklach. Jeżeli firma nie ustali granicy okresu przed rozpoczęciem uzgodnienia, bardzo łatwo zacznie mieszać listopadową aktywność sprzedażową z grudniowymi przepływami pieniężnymi i późniejszymi korektami. W efekcie każda różnica będzie wyglądała jak problem, mimo że część z nich jest zwykłym skutkiem przesunięcia pomiędzy różnymi momentami raportowania.

Nie istnieje przy tym jedna uniwersalna data, którą można bezwarunkowo zastosować jednocześnie do sprzedaży, ksiąg, VAT i wypłaty. W zależności od rodzaju transakcji i kraju mogą mieć znaczenie inne momenty oraz dokumenty. Dlatego zamknięcie powinno rozdzielać aktywność operacyjną od właściwego okresu księgowego i podatkowego, a oba te poziomy od settlementu. Dopiero po ustaleniu, które transakcje i korekty rzeczywiście należą do listopada, można sensownie analizować, dlaczego odpowiadające im pieniądze pojawiły się wcześniej, później albo zostały częściowo zatrzymane. Taki sposób pracy pozwala traktować różnice czasowe jako kontrolowany element procesu, zamiast próbować na siłę dopasowywać sprzedaż do kwot widocznych na rachunku.

Data sprzedaży a data wypłaty

Data wypłaty nie jest automatycznie datą sprzedaży. Settlement działa według własnego cyklu, natomiast sposób ujęcia transakcji w księgach i VAT wynika z zasad właściwych dla danego rodzaju zdarzenia oraz jurysdykcji. Sprzedaż może zostać właściwie przypisana do końcówki listopada, podczas gdy środki trafią do wypłaty dopiero w grudniu. W drugim kierunku grudniowy settlement może zawierać refundacje albo korekty odnoszące się do wcześniejszych transakcji. Sama data przelewu nie przesądza więc, do którego miesiąca należy sprzedaż ani w którym okresie powinien zostać rozliczony VAT. Trzeba najpierw ustalić datę właściwą dla konkretnej transakcji zgodnie z zasadami księgowymi i podatkowymi, a następnie sprawdzić, kiedy jej skutki zostały uwzględnione w rozliczeniu z marketplace.

W działalności międzynarodowej rozdzielenie tych momentów jest jeszcze ważniejsze. Dla jednego zamówienia możesz mieć datę złożenia zamówienia, moment jego realizacji, datę właściwą dla ujęcia księgowego, okres VAT, moment zaksięgowania transakcji w systemie rozliczeniowym i datę faktycznej wypłaty. Nie muszą być identyczne. Nie oznacza to również, że każda różnica między nimi wymaga korekty. Kluczowe jest to, aby system finansowy i proces zamknięcia potrafiły zachować odpowiednie daty i nie zastępowały jednej drugą. Dzięki temu księgowość może wyjaśnić, dlaczego określona transakcja została ujęta w listopadzie, mimo że związane z nią środki pojawiły się na koncie dopiero w kolejnym miesiącu.

Co zrobić z transakcjami z końca listopada wypłaconymi w grudniu?

Jeżeli po analizie okaże się, że dana transakcja zgodnie z odpowiednimi zasadami należy do listopada, nie należy przenosić jej do grudniowej sprzedaży wyłącznie dlatego, że wypłata nastąpiła później. Taka sytuacja jest typowym przykładem różnicy czasowej pomiędzy okresem sprzedaży a momentem rozliczenia pieniężnego. Na koniec listopada kwota pozostająca do rozliczenia z marketplace powinna być możliwa do zidentyfikowania i wyjaśnienia w rozrachunkach, a późniejsza wypłata powinna dać się z nią powiązać. Nie oznacza to konieczności zakładania z góry konkretnej struktury księgowania dla każdej firmy. Chodzi przede wszystkim o to, aby pieniądze, które pojawią się w grudniu, nie zostały ponownie potraktowane jako grudniowa sprzedaż, jeśli dotyczą aktywności prawidłowo ujętej wcześniej.

Przy większej skali nie wystarczy jednak ogólne wyjaśnienie, że różnica wynika z późniejszej wypłaty. Powinno być wiadomo, które transakcje składają się na kwotę pozostającą do wypłaty oraz czy ich rozliczenie zostało odroczone, objęte rezerwą lub przeniesione do kolejnego cyklu. Nie zawsze można z góry przypisać każdą z tych pozycji do konkretnego przyszłego settlement ID, dlatego proces nie powinien wymagać informacji, której w danym momencie po prostu nie ma. Ważniejsza jest możliwość późniejszego powiązania uwolnionej kwoty z wcześniejszym saldem i potwierdzenia, że różnica została wyjaśniona. Po Black Friday ma to szczególne znaczenie, ponieważ w ostatnich dniach listopada mogą powstać setki lub tysiące transakcji, których cash flow przejdzie na kolejny miesiąc.

Co zrobić z grudniowymi zwrotami listopadowej sprzedaży?

Grudniowy zwrot dotyczący listopadowej transakcji powinien zostać przede wszystkim powiązany z pierwotną sprzedażą. Trzeba ustalić, którego zamówienia dotyczy, jaka była jego wartość, jaki status miał klient, jaka stawka VAT została zastosowana, w jakim kraju transakcja była rozliczana oraz kto odpowiadał za rozliczenie podatku. Dopiero wtedy można określić właściwy sposób i okres ujęcia korekty sprzedaży oraz VAT. Nie należy automatycznie zakładać, że skoro pierwotna sprzedaż została wykazana w listopadzie, każda grudniowa refundacja powinna zostać mechanicznie cofnięta do listopada. Powiązanie ekonomiczne z pierwotną transakcją i okres wykazania korekty to dwa odrębne zagadnienia, które trzeba przeanalizować zgodnie z zasadami właściwymi dla danego rodzaju sprzedaży i procedury VAT.

Z perspektywy reconciliation najważniejsze jest zachowanie ciągłości między pierwotnym zdarzeniem a późniejszą korektą. Refundacja pojawiająca się w grudniowym settlementcie nie powinna zostać błędnie potraktowana jako niezależne pomniejszenie bieżącej sprzedaży ani jako niewyjaśniona różnica w wypłacie. Powinna być rozpoznawalna jako korekta konkretnej wcześniejszej transakcji. Ma to szczególne znaczenie przy refundacjach częściowych, zwrotach jednego produktu z zamówienia wielopozycyjnego oraz sytuacjach, w których klient otrzymuje pieniądze bez pełnego fizycznego zwrotu towaru. W takich przypadkach przepływ pieniężny, magazynowy i podatkowy nie muszą przebiegać równolegle. Dlatego poprawne zamknięcie wymaga ich rozdzielenia, a następnie ponownego połączenia na poziomie konkretnej transakcji.

Krok 2. Uzgodnij transakcje i przypisz właściwe rozliczenie sprzedaży oraz VAT

W drugim kroku trzeba zbudować obraz aktywności sprzedażowej niezależny od wypłat, a następnie ustalić, jaka część transakcji stanowi sprzedaż i VAT rozliczane przez sprzedawcę, a jaka podlega szczególnym zasadom, na przykład modelowi deemed supplier. Przy większej skali nie wystarczy jedna suma miesięczna ani proste rozłożenie każdej transakcji na netto, VAT i brutto. Dwie podobnie wyglądające transakcje mogą mieć zupełnie inne konsekwencje, jeśli jedna jest sprzedażą krajową, druga transgraniczną, jedna została zrealizowana z magazynu w Polsce, a druga z magazynu w Niemczech, albo jeśli w jednym przypadku VAT rozlicza sprzedawca, a w drugim obowiązek wobec klienta spoczywa na marketplace zgodnie z zasadami deemed supplier. Ten etap powinien więc odpowiedzieć nie tylko na pytanie, jaka była wartość aktywności sprzedażowej, ale przede wszystkim jak poszczególne transakcje należy zaklasyfikować dla celów księgowych i VAT.

Zacznij od transakcji z klientem, nie od przelewu

Punktem wyjścia jest wartość transakcji z klientem i dane opisujące jej przebieg, a nie kwota wypłaty. Dzięki nim można ustalić, co rzeczywiście wydarzyło się w danym okresie, jaka była wartość ekonomiczna transakcji, skąd i dokąd przemieszczał się towar oraz jakie zasady podatkowe mogą mieć zastosowanie. Dopiero na kolejnym etapie ustala się, które wartości stanowią sprzedaż i VAT wykazywane przez sprzedawcę, a które podlegają innemu modelowi rozliczenia. Jest to szczególnie ważne przy deemed supplier, ponieważ pełna wartość transakcji klienckiej pozostaje istotna dla reconciliation, ale nie oznacza automatycznie, że cała transakcja jest sprzedażą sprzedawcy dla celów VAT. Przelew pojawia się jeszcze później i jest już wynikiem refundacji, opłat, rezerw, korekt oraz innych pozycji wpływających na saldo.

Jednocześnie transakcji klientowskiej nie należy utożsamiać z samym faktem złożenia zamówienia. Najpierw trzeba ustalić, które zdarzenia rzeczywiście podlegają ujęciu w zamykanym okresie zgodnie z zasadami księgowymi i podatkowymi właściwymi dla danego modelu sprzedaży. Dopiero na tej podstawie można przypisać wartości netto, VAT i brutto w taki sposób, jaki jest właściwy dla sprzedawcy. Takie podejście chroni przed dwoma błędami naraz: włączeniem do listopada transakcji, które jeszcze nie powinny się tam znaleźć, oraz przesuwaniem do grudnia sprzedaży tylko dlatego, że wtedy nastąpiła wypłata. Bank pozostaje więc ostatnim etapem kontroli, a nie miejscem, z którego odtwarza się sprzedaż.

Podziel sprzedaż według kraju i stawki VAT

Po ustaleniu transakcji należących do okresu należy podzielić je według kraju i zastosowanej stawki VAT. Przy sprzedaży w kilku państwach jedna łączna wartość brutto nie daje wystarczającej informacji do zamknięcia miesiąca. Trzeba wiedzieć, gdzie rozpoczęła się wysyłka, gdzie zakończyła się dostawa, jaki status miał nabywca i jaka stawka została zastosowana. Taki podział pozwala później porównać dane z lokalnymi deklaracjami, OSS oraz innymi właściwymi ewidencjami. Ułatwia również wykrycie błędów, których nie widać na poziomie całkowitego obrotu. Firma może mieć poprawną sumę sprzedaży za listopad, a jednocześnie część transakcji może być przypisana do niewłaściwego państwa lub stawki, przez co VAT zostanie rozłożony nieprawidłowo.

Dla firmy rozwijającej działalność międzynarodową szczególnie istotne jest to, że kraj klienta sam w sobie nie wystarcza do ustalenia sposobu rozliczenia VAT. Podobne zamówienia kierowane do klientów we Francji mogą być realizowane z różnych magazynów i mieć odmienny przebieg podatkowy. Dlatego podstawą kontroli powinny być dane obejmujące co najmniej kraj wysyłki, kraj dostawy, stawkę podatku, status klienta oraz model transakcji. Przy FBA ten poziom szczegółowości jest jeszcze ważniejszy, ponieważ fizyczna lokalizacja zapasu może zmieniać się w ramach sieci fulfillmentowej. Podział według kraju i stawki powinien więc wynikać z faktycznych danych o transakcji, a nie wyłącznie ze storefrontu, na którym klient złożył zamówienie, lub z jego adresu.

Oddziel B2C od B2B

Sprzedaż B2C i B2B powinna być rozdzielona już na etapie uzgodnienia, ponieważ status nabywcy może zasadniczo zmieniać sposób rozliczenia VAT. Transakcja z konsumentem w innym państwie UE może podlegać zasadom właściwym dla wewnątrzwspólnotowej sprzedaży towarów na odległość i być rozliczana przez OSS, podczas gdy sprzedaż do przedsiębiorcy może wymagać zupełnie innej klasyfikacji. Nie należy więc patrzeć wyłącznie na kraj dostawy i stosować jednej reguły do wszystkich zamówień. Trzeba ustalić, czy klient działa jako konsument, czy jako przedsiębiorca, oraz czy dostępne dane potwierdzają jego status dla celów podatkowych. W przypadku transakcji B2B istotne mogą być również dane identyfikacyjne nabywcy, w tym właściwy numer VAT UE i jego status.

Z perspektywy reconciliation oddzielenie B2C i B2B ma także znaczenie kontrolne. Jeżeli obie kategorie zostaną połączone w jednej miesięcznej sumie, całkowita wartość może się zgadzać, mimo że część transakcji została nieprawidłowo sklasyfikowana podatkowo. Przy sprzedaży na kilku rynkach problem może być trudny do wykrycia, ponieważ błędna reguła klasyfikacji powiela się na dużej liczbie zamówień. Dlatego status nabywcy powinien być jednym z podstawowych wymiarów kontroli obok kraju wysyłki, kraju dostawy i stawki VAT. Nie oznacza to przy tym, że każda transakcja B2B automatycznie jest WDT albo podlega jednemu określonemu modelowi. Jej sposób rozliczenia trzeba ustalić na podstawie pełnego zestawu danych.

Oddziel FBA od FBM

Rozdzielenie FBA i FBM pomaga zrozumieć nie tylko koszty realizacji, ale również faktyczny przebieg dostawy. W modelu FBM to sprzedawca zazwyczaj organizuje wysyłkę z własnej lokalizacji lub magazynu, natomiast przy FBA towar może być przechowywany i przemieszczany w ramach sieci fulfillmentowej. Z punktu widzenia VAT kluczowe znaczenie ma jednak nie sama etykieta FBA lub FBM, lecz to, skąd towar rzeczywiście został wysłany i dokąd trafił. Jeżeli firma korzysta z magazynów w kilku krajach, podobne zamówienia klientów mogą być realizowane z różnych państw i w konsekwencji wymagać innej klasyfikacji podatkowej. Sam model fulfillmentu jest więc użytecznym filtrem, ale nie powinien zastępować informacji o rzeczywistym ruchu towaru.

Oddzielenie FBA i FBM ułatwia również kontrolę zdarzeń, które nie są sprzedażą klientowską. Przy FBA mogą pojawiać się transfery własnego zapasu pomiędzy magazynami, które nie oznaczają sprzedaży do konsumenta, ale mogą mieć odrębne znaczenie dla VAT. Przy FBM firma zwykle ma większą kontrolę nad lokalizacją, z której rozpoczyna się wysyłka, ale nadal musi poprawnie ustalić kraj rozpoczęcia i zakończenia transportu. Dlatego właściwy proces powinien łączyć dwa poziomy informacji: model realizacji zamówienia pomaga porządkować dane, natomiast faktyczna trasa towaru pozwala ustalić charakter transakcji i jej konsekwencje podatkowe. To rozróżnienie nabiera znaczenia szczególnie wtedy, gdy ekspansja obejmuje nowe magazyny.

Oddziel VAT rozliczany przez sprzedawcę od VAT pobieranego przez marketplace

Jednym z najważniejszych podziałów jest rozróżnienie transakcji, w których VAT rozlicza sprzedawca, od tych, w których w określonych sytuacjach marketplace jest traktowany jako deemed supplier. W tym drugim modelu zasady VAT mogą tworzyć szczególną konstrukcję, w której platforma odpowiada za pobranie i rozliczenie podatku wobec klienta, mimo że gospodarczo towar pochodzi od sprzedawcy. Dlatego nie można przyjąć, że cała kwota VAT widoczna przy transakcjach klientowskich automatycznie zasila zobowiązanie podatkowe sprzedawcy. Trzeba zidentyfikować transakcje objęte takim mechanizmem i oddzielić je od tych, dla których obowiązek rozliczenia VAT pozostaje po stronie przedsiębiorcy.

W praktyce sprzedawca powinien wiedzieć, które transakcje oraz jakie elementy ich rozliczenia powinny zostać wykazane przez niego, a za które odpowiada marketplace zgodnie z zasadami deemed supplier. Nie jest to zawsze prosty podział jednej kwoty na część „sprzedawcy” i część „platformy”. Dlatego uzgodnienie powinno zachować pełną wartość transakcji klienckiej jako element kontroli finansowej, a równocześnie posiadać odrębną klasyfikację podatkową. Dopiero wtedy można właściwie zestawić dane sprzedażowe z ewidencjami VAT, OSS, lokalnymi deklaracjami i settlementami. Przy dużej liczbie zamówień takie oznaczenie powinno być możliwe na poziomie danych, ponieważ ręczne rozpoznawanie każdej transakcji przy zamknięciu miesiąca szybko przestaje być wykonalne.

Sprawdź sprzedaż krajową, transgraniczną i OSS

OSS jest ważnym uproszczeniem dla firm prowadzących określone rodzaje sprzedaży B2C do innych państw UE, ale nie powinien być traktowany jako uniwersalne rozwiązanie dla całego handlu zagranicznego. Pozwala rozliczać kwalifikujące się transakcje w państwach konsumpcji za pośrednictwem jednego państwa identyfikacji, co może znacząco zmniejszyć obciążenie administracyjne. Nie oznacza jednak, że każda zagraniczna transakcja trafia do OSS. Osobno trzeba rozpoznać sprzedaż krajową, sprzedaż transgraniczną B2C objętą procedurą, transakcje B2B oraz inne modele wymagające lokalnego lub odmiennego sposobu rozliczenia. Dlatego w procesie uzgodnienia OSS najlepiej traktować jako jedną z kategorii podatkowych, a nie jako wspólny worek dla całego obrotu poza Polską.

Przy zamknięciu listopada warto sprawdzić, czy transakcje oznaczone jako OSS rzeczywiście spełniają warunki takiej klasyfikacji, czy przypisano właściwy kraj konsumpcji i czy zastosowano odpowiednią stawkę VAT. Jednocześnie trzeba pozostawić poza tą procedurą sprzedaż, która wymaga innego sposobu ujęcia. Dla firmy planującej ekspansję jest to szczególnie istotne, ponieważ wraz z pojawieniem się zapasu w kolejnych państwach prosty schemat „sprzedajemy za granicę, więc wszystko rozliczamy przez OSS” szybko przestaje odpowiadać rzeczywistości. Dobre uzgodnienie powinno więc pokazywać, jaka część sprzedaży jest krajowa, jaka kwalifikuje się do OSS, jaka dotyczy klientów B2B i gdzie występują inne obowiązki lokalne.

Dlaczego OSS nie rozwiązuje problemu magazynowania towaru za granicą?

OSS nie zastępuje lokalnych obowiązków VAT, które mogą wynikać z utrzymywania zapasu za granicą, jego przemieszczania między państwami oraz lokalnych dostaw. Jeżeli firma korzysta z zagranicznych magazynów, w zależności od konkretnego modelu mogą pojawić się obowiązki rejestracyjne i raportowe niezwiązane bezpośrednio z końcową sprzedażą B2C rozliczaną przez OSS. Dotyczy to między innymi przemieszczeń własnego zapasu pomiędzy państwami. Taki ruch nie jest sprzedażą do klienta, ale może wymagać odrębnego ujęcia dla VAT. W efekcie firma może korzystać z OSS dla części sprzedaży transgranicznej B2C, a jednocześnie nadal mieć obowiązki lokalne w państwach, w których utrzymuje lub przemieszcza własny zapas.

Ma to szczególne znaczenie przy FBA, ponieważ decyzja o udostępnieniu zapasu w kolejnych lokalizacjach logistycznych może mieć konsekwencje szersze niż tylko skrócenie czasu dostawy. Z biznesowego punktu widzenia zagraniczny magazyn może poprawiać dostępność produktu i konwersję, ale z perspektywy VAT może powodować nowe zdarzenia do raportowania. Dlatego przed ekspansją warto patrzeć na mapę lokalizacji zapasu równie uważnie jak na mapę klientów. OSS upraszcza określone rozliczenia sprzedaży B2C, ale nie zastępuje analizy lokalnych obowiązków VAT związanych z zapasem, jego transferami i dostawami realizowanymi z zagranicznych magazynów.

Krok 3. Rozlicz prowizje i opłaty niezależnie od transakcji sprzedażowych

Po uzgodnieniu transakcji kolejnym etapem jest oddzielenie opłat, które wpływają na rozrachunek z marketplace. Z perspektywy banku prowizje, fulfillment, magazynowanie czy inne potrącenia po prostu zmniejszają kwotę wypłaty. Z perspektywy reconciliation są jednak osobnymi pozycjami, które powinny zostać zidentyfikowane niezależnie od transakcji klientowskich. Nie oznacza to automatycznie określonego sposobu prezentacji przychodu w rachunkowości, ponieważ ten może wymagać odrębnej analizy modelu principal–agent i warunków konkretnej działalności. Dla kontroli miesiąca najważniejsze jest natomiast to, aby pełna aktywność sprzedażowa oraz koszty i adjustments były widoczne osobno, zamiast znikać w jednej wartości netto wypłaty.

Dlaczego prowizji nie należy bezpośrednio kompensować z transakcją klientowską?

Jeżeli klient zapłacił określoną cenę, opłata naliczona przez marketplace jest odrębnym elementem rozrachunku i powinna być możliwa do zidentyfikowania niezależnie od wartości transakcji klientowskiej. Nie należy jednak wyciągać z tego automatycznego wniosku, że pełna kwota zapłacona przez klienta zawsze stanowi przychód sprzedawcy w rozumieniu rachunkowym. Sposób prezentacji może zależeć między innymi od tego, czy przedsiębiorca działa jako principal czy agent, a przy niektórych transakcjach dochodzą również szczególne zasady deemed supplier dla VAT. Z punktu widzenia samego reconciliation najważniejsze jest zachowanie dwóch odrębnych warstw: wartości aktywności sprzedażowej oraz opłat naliczonych przez marketplace.

Jeżeli prowizja zostanie bezpośrednio skompensowana z wartością transakcji klienckich bez odrębnej identyfikacji, firma straci możliwość analizy pełnej wartości aktywności sprzedażowej oraz rzeczywistych kosztów kanału. Przy dużym wolumenie utrudni to porównanie rynków, produktów i modeli fulfillmentu, ponieważ nie będzie wiadomo, czy niższa kwota wynika ze słabszej sprzedaży, wyższych prowizji czy innych potrąceń. Nie każda pozycja widoczna w settlementcie jest jednak kosztem. Mogą tam występować również refundacje, zmiany rezerwy oraz adjustments o innym charakterze. Dlatego przed zaksięgowaniem każdej pozycji trzeba najpierw ustalić, czym ona rzeczywiście jest, a dopiero później przypisać jej właściwe ujęcie.

Jak pogrupować koszty?

Praktyczny podział powinien pozwalać oddzielnie analizować prowizje sprzedażowe, fulfillment, magazynowanie, reklamę, abonament oraz opłaty związane z obsługą zwrotów. Dzięki temu można ocenić, czy po Black Friday koszty rosną proporcjonalnie do sprzedaży i które elementy najbardziej obciążają marżę. Dla przedsiębiorcy planującego ekspansję jest to szczególnie istotne, ponieważ struktura kosztów może wyglądać zupełnie inaczej na poszczególnych rynkach. Wysoki koszt fulfillmentu może być akceptowalny tam, gdzie przekłada się na większą sprzedaż i szybszą rotację zapasu, ale może całkowicie zmieniać ekonomię produktu o niskiej marży. Podobnie opłaty magazynowe nabierają innego znaczenia, gdy zapas pozostaje w zagranicznym magazynie dłużej, niż pierwotnie zakładano.

Oddzielną kategorię powinny tworzyć adjustments i inne pozycje, których nie należy automatycznie nazywać kosztami. Mogą one zwiększać lub zmniejszać saldo, korygować wcześniejsze rozliczenia albo wynikać z mechanizmu rezerwy. Takie pozycje powinny być najpierw opisane i powiązane z odpowiednim zdarzeniem, a dopiero później zaklasyfikowane. Dzięki temu typowe koszty operacyjne nie mieszają się z technicznymi korektami settlementu, refundacjami lub zmianami rezerwy. Taki układ jest znacznie bardziej użyteczny zarówno dla księgowości, jak i zarządu, ponieważ pozwala odróżnić rzeczywisty wzrost kosztu sprzedaży na marketplace od zmian wynikających wyłącznie z mechaniki rozrachunku.

Dlaczego sam opis opłaty w settlementcie nie wystarcza do jej rozliczenia?

Nazwa opłaty w raporcie płatniczym pomaga ustalić, z czym najprawdopodobniej związane jest potrącenie, ale nie wystarcza do określenia jego pełnego sposobu rozliczenia. Potrzebna jest faktura, nota lub inny właściwy dokument źródłowy, z którego można odczytać kontrahenta, jego dane podatkowe, opis świadczenia, kwotę oraz ewentualny VAT. Te informacje są niezbędne do dalszej analizy, ale sam dokument również nie powinien być traktowany jako jedyne i ostateczne źródło kwalifikacji VAT. Jeżeli faktura została wystawiona błędnie albo jej opis nie odpowiada rzeczywistemu charakterowi świadczenia, nie zmienia to automatycznie zasad, które powinny zostać zastosowane.

Faktura lub inny dokument źródłowy dostarcza danych potrzebnych do ustalenia właściwego sposobu rozliczenia, natomiast kwalifikacja VAT powinna wynikać z rzeczywistego charakteru usługi, statusu stron i właściwych zasad miejsca świadczenia. W przypadku usług kupowanych od zagranicznego kontrahenta po stronie polskiego sprzedawcy może powstać obowiązek rozliczenia importu usług, w tym VAT na zasadzie reverse charge, ale nie należy wyprowadzać takiego wniosku wyłącznie z nazwy opłaty widocznej w settlementcie. Raport płatniczy wyjaśnia przepływ pieniędzy, a dokument źródłowy dostarcza danych potrzebnych do prawidłowej klasyfikacji transakcji. Dopiero zestawienie obu warstw pozwala właściwie uzgodnić opłatę i ustalić jej konsekwencje księgowe oraz podatkowe.

Krok 4. Oddziel zwroty i refundacje od kosztów marketplace

Zwroty po Black Friday potrafią mocno zaburzyć obraz miesiąca, ponieważ zwykle pojawiają się z opóźnieniem względem pierwotnej sprzedaży. W listopadzie firma widzi skok liczby zamówień, natomiast w grudniu zaczynają napływać pełne zwroty, częściowe refundacje i inne korekty dotyczące wcześniejszych transakcji. Najważniejsze jest więc rozdzielenie tych zdarzeń od kosztów marketplace. Refundacja ceny klientowi nie jest tym samym co prowizja, opłata za fulfillment czy koszt obsługi zwrotu. Jednocześnie sam fizyczny powrót produktu nie przesądza jeszcze o tym, że powinna powstać korekta sprzedaży lub VAT. Jeżeli wszystkie te zdarzenia zostaną potraktowane jako jedna grupa potrąceń zmniejszających wypłatę, reconciliation może zgadzać się na poziomie banku, ale przestanie pokazywać, co rzeczywiście stało się z transakcją, zapasem i rozliczeniem podatkowym.

Fizyczny zwrot, refundacja i opłata za obsługę zwrotu — trzy różne zdarzenia

Fizyczny zwrot produktu oznacza ruch towaru, refundacja oznacza zmianę rozliczenia finansowego z klientem, a opłata związana z obsługą zwrotu jest jeszcze innym zdarzeniem wpływającym na rozrachunek z marketplace. Te trzy elementy mogą wystąpić razem, ale nie muszą. Klient może odesłać produkt i otrzymać pełną refundację, może dostać częściowy zwrot ceny, a w określonych sytuacjach może również otrzymać pieniądze bez fizycznego odesłania towaru. Marketplace może równocześnie naliczyć własną opłatę związaną z obsługą procesu. Dlatego nie można przyjąć prostej reguły, że każdy ruch magazynowy oznacza identyczną korektę finansową albo że każda refundacja powoduje dokładnie taki sam ruch zapasu.

W dobrze zbudowanym uzgodnieniu te trzy warstwy są widoczne osobno. Ruch magazynowy pozwala ustalić, co stało się z produktem, refundacja pokazuje, jak zmieniło się rozliczenie z klientem, a opłata marketplace wymaga własnej klasyfikacji jako koszt lub inna właściwa pozycja. Dopiero później można połączyć te informacje w jedną historię konkretnej transakcji. Takie podejście jest szczególnie ważne przy FBA, gdzie zwrot fizyczny może zostać obsłużony w sieci fulfillmentowej niezależnie od momentu pojawienia się refundacji w rozliczeniach. Próba księgowania wszystkiego wyłącznie na podstawie jednej daty albo jednego raportu prowadzi wtedy do podwójnych korekt, brakujących zapisów lub różnic, których później trudno sensownie wyjaśnić.

Jak rozliczyć pełny zwrot?

Przy pełnym zwrocie pierwszym krokiem jest powiązanie refundacji z pierwotną transakcją i ustalenie jej parametrów. Trzeba wiedzieć, jaka była pierwotna wartość sprzedaży, jaki produkt został objęty korektą, jaka stawka VAT miała zastosowanie, w którym kraju transakcja była rozliczana oraz kto odpowiadał za VAT. Dopiero na tej podstawie można ustalić właściwy sposób ujęcia korekty. Jeżeli refundacja odnosi się do wcześniej rozliczonej sprzedaży sprzedawcy, ekonomicznie koryguje ona wcześniejszą transakcję, ale nie oznacza to automatycznie mechanicznego cofnięcia zapisów do miesiąca pierwotnej sprzedaży. Okres i sposób ujęcia korekty trzeba określić zgodnie z zasadami właściwymi dla danej transakcji i procedury VAT.

Pełny zwrot nie powinien być również utożsamiany z kosztem marketplace. Jeżeli klient otrzymuje pieniądze z powrotem, zmienia się rozliczenie wynikające z pierwotnej sprzedaży. Osobno trzeba natomiast analizować opłatę pobraną za obsługę zwrotu, ewentualne korekty prowizji oraz inne adjustments, które mogą pojawić się w settlementcie. Przy większej liczbie zwrotów szczególnie ważne jest zachowanie pełnego śladu transakcji: od pierwotnego order ID, przez dokument sprzedaży i dane VAT, aż do refundacji oraz jej wpływu na rozrachunek. Dzięki temu jedna korekta nie zostanie ujęta dwa razy, na przykład najpierw ręcznie jako zwrot klienta, a następnie ponownie przy księgowaniu kolejnego settlementu.

Jak rozliczyć częściową refundację?

Częściowa refundacja wymaga większej precyzji niż pełny zwrot, ponieważ korekta dotyczy tylko określonego elementu pierwotnej transakcji. Jeżeli klient otrzymuje zwrot części ceny, jednego produktu z zamówienia wielopozycyjnego albo wyłącznie określonej opłaty, nie należy automatycznie korygować całej sprzedaży ani stosować prostego procentu do całego VAT. Trzeba ustalić, czego dokładnie dotyczy refundowana kwota i jakie parametry miała ta część pierwotnej transakcji. Jeżeli zamówienie obejmowało produkty opodatkowane różnymi stawkami, zwrot jednego z nich powinien zostać odniesiony właśnie do tego produktu, a nie proporcjonalnie do całego zamówienia. Punktem odniesienia są parametry pierwotnego zdarzenia, a nie bieżąca stawka podatku czy aktualne ustawienia produktu w systemie.

Częściowej refundacji nie należy też traktować jak ogólnego rabatu od miesięcznego obrotu. Powinna pozostawać powiązana z konkretną sprzedażą, bo dopiero wtedy wiadomo, jakiej wartości ekonomicznej i jakiego VAT dotyczy. Jeżeli marketplace był odpowiedzialny za VAT w modelu deemed supplier, sposób podatkowego ujęcia korekty po stronie sprzedawcy może być inny niż w zwykłej sprzedaży, dlatego także tutaj nie powinno się stosować jednej reguły do całego wolumenu. Z perspektywy reconciliation najważniejsze jest prawidłowe przypisanie refundowanej kwoty do odpowiedniego elementu pierwotnej transakcji i zachowanie pełnego śladu źródłowego, który pozwala później wyjaśnić zarówno korektę finansową, jak i jej skutki podatkowe.

Dlaczego zwrot powinien być powiązany z pierwotną transakcją?

Bez powiązania refundacji z pierwotną sprzedażą trudno stwierdzić, co właściwie zostało skorygowane. Dlatego potrzebny jest co najmniej identyfikator zamówienia lub transakcji, właściwy dokument, pierwotna stawka podatku oraz informacja o kraju VAT. Przy sprzedaży międzynarodowej często potrzebne będą również dane o kraju wysyłki i dostawy, statusie klienta oraz modelu rozliczenia podatku. Dzięki temu można ustalić nie tylko kwotę refundacji, lecz również to, czy została ona przypisana do właściwego rynku i właściwej kategorii podatkowej. W przeciwnym razie zwrot pojawiający się w grudniu może zostać potraktowany jak przypadkowe pomniejszenie grudniowej sprzedaży, mimo że ekonomicznie odnosi się do konkretnej listopadowej transakcji.

Powiązanie z pierwotną transakcją pełni również funkcję kontrolną. Pozwala sprawdzić, czy dana refundacja nie została już wcześniej ujęta, czy odpowiada rzeczywistej wartości zamówienia i czy zastosowano prawidłowe parametry korekty. Przy dużym wolumenie jest to szczególnie ważne, ponieważ pojedyncze niepowiązane zwroty łatwo znikają w miesięcznych sumach. Problem ujawnia się dopiero wtedy, gdy wartości z settlementu nie da się pogodzić z ewidencją sprzedaży i VAT. Jeżeli każda refundacja ma czytelne połączenie z order ID, dokumentem, stawką i krajem rozliczenia, znacznie łatwiej przejść od korekty do pierwotnej transakcji i wyjaśnić jej wpływ na miesiąc.

Co z refundacją bez fizycznego zwrotu produktu?

Refundacja bez fizycznego zwrotu pokazuje bardzo wyraźnie, dlaczego nie można utożsamiać ruchu magazynowego z korektą finansową. Klient może otrzymać zwrot środków mimo że produkt nie wraca do magazynu, a w innych sytuacjach towar może wrócić fizycznie wcześniej, niż pojawi się odpowiednia korekta finansowa. Z tego powodu raport magazynowy nie powinien być jedynym źródłem do ustalania refundacji, podobnie jak sama refundacja nie wystarcza do odtworzenia ruchu zapasu. Oba zdarzenia trzeba śledzić niezależnie, a następnie połączyć na poziomie konkretnego zamówienia lub produktu.

Z punktu widzenia zamknięcia miesiąca liczy się przede wszystkim to, czy refundacja została prawidłowo zidentyfikowana jako korekta odpowiedniej transakcji oraz czy jej skutki podatkowe zostały ustalone zgodnie z zasadami właściwymi dla pierwotnej sprzedaży. Fizyczna lokalizacja produktu po refundacji może mieć znaczenie operacyjne i magazynowe, ale nie powinna być automatycznie utożsamiana z momentem korekty finansowej lub VAT. Przy FBA taki rozdział jest szczególnie istotny, ponieważ logistyka zwrotów może być obsługiwana niezależnie od przepływu pieniędzy. Dobrze przeprowadzone uzgodnienie pozwala więc rozdzielić przepływ towaru, przepływ środków i konsekwencje podatkowe, a następnie sprawdzić, czy wszystkie trzy elementy odnoszą się do tej samej transakcji.

Krok 5. Uzgodnij settlement z rachunkiem bankowym

Dopiero po uzgodnieniu transakcji sprzedażowych, VAT, refundacji, prowizji, opłat i innych adjustments można przejść do banku. W tym momencie rachunek nie służy już do ustalania sprzedaży, lecz do potwierdzenia, czy wynik rozrachunku z marketplace odpowiada rzeczywistemu przepływowi pieniędzy. To zasadnicza zmiana perspektywy. Zamiast próbować wyprowadzać listopadowy obrót z wartości przelewu, zaczynasz od szczegółowych danych i sprawdzasz, jak złożyły się na saldo settlementu, a następnie jak to saldo przełożyło się na wypłatę. Przy dużym wolumenie jest to najbardziej wiarygodny i skalowalny sposób na odróżnienie prawidłowej różnicy czasowej od rzeczywistego błędu.

Zacznij od salda rozliczenia

Saldo settlementu jest punktem, w którym spotykają się wcześniejsze elementy procesu. Powinno być możliwe do odtworzenia na podstawie transakcji klientowskich, refundacji, opłat, adjustments, rezerw i innych pozycji wpływających na rozrachunek. Nie chodzi przy tym o założenie, że każdy raport będzie prezentował identyczny zestaw pól ani że każda pozycja od razu będzie miała oczywistą klasyfikację. Ważne jest, aby na podstawie dostępnych danych można było wyjaśnić, dlaczego kwota przeznaczona do wypłaty ma właśnie taką wartość. Jeżeli saldo jest niższe od wartości aktywności sprzedażowej, różnica powinna wynikać z konkretnych i możliwych do zidentyfikowania elementów rozrachunku.

Takie podejście chroni przed częstym błędem polegającym na traktowaniu settlementu jak raportu sprzedaży. Settlement pokazuje wynik rozrachunku w określonym cyklu, a nie pełny obraz aktywności przypisanej do miesiąca księgowego lub podatkowego. Dlatego dobrze wykonane uzgodnienie powinno działać w dwóch kierunkach: od transakcji do salda oraz od salda do poszczególnych kategorii, które je tworzą. Jeżeli jedna większa pozycja nie ma wyjaśnienia, nie powinna zostać automatycznie wrzucona do „pozostałych kosztów” tylko po to, aby bank się zgodził. Najpierw trzeba ustalić, czym rzeczywiście jest i dlaczego pojawiła się w rozrachunku.

Dopasuj wypłaty do banku

Kolejnym etapem jest zestawienie wypłat wynikających z rozrachunku z rzeczywistymi wpływami na rachunek bankowy. Nie zawsze oznacza to prostą relację jeden settlement = jeden przelew widoczny tego samego dnia. W praktyce trzeba brać pod uwagę harmonogram wypłat, daty księgowania bankowego, waluty oraz ewentualne przesunięcia między momentem przygotowania wypłaty i zaksięgowania środków na koncie. Dlatego sama różnica dat nie jest błędem. Ważniejsze jest to, czy konkretną wypłatę można ostatecznie powiązać z odpowiednim rozrachunkiem i czy jej wartość daje się wyjaśnić po uwzględnieniu wszystkich istotnych elementów.

Jeżeli wpłata pojawia się dopiero na początku grudnia, mimo że dotyczy salda zbudowanego częściowo z listopadowych transakcji, nie należy z tego powodu zmieniać klasyfikacji listopadowej aktywności. Bank potwierdza jedynie, kiedy środki faktycznie znalazły się na rachunku. Na koniec miesiąca kwoty pozostające do rozliczenia powinny być możliwe do zidentyfikowania, a po otrzymaniu przelewu powinno dać się pokazać, którą wcześniejszą różnicę on wyjaśnia lub zamyka. Takie podejście pozwala uniknąć sytuacji, w której grudniowa wypłata jest omyłkowo traktowana jak nowa grudniowa sprzedaż.

Uwzględnij waluty i przewalutowania

Przy sprzedaży międzynarodowej zgodność rozrachunku z bankiem komplikuje się dodatkowo przez waluty. Transakcje mogą być prowadzone w walucie lokalnego rynku, natomiast środki mogą zostać wypłacone na rachunek prowadzony w innej walucie. W takim przypadku różnica pomiędzy sumą pozycji źródłowych a wartością przelewu nie musi oznaczać brakującej transakcji. Może wynikać z przewalutowania zastosowanego na etapie wypłaty. Dlatego w reconciliation trzeba zachować informację o walucie źródłowej, walucie wypłaty i mechanizmie przeliczenia, aby oddzielić efekt kursowy od refundacji, opłat lub innych korekt.

Jednocześnie kurs wykorzystany przez marketplace lub operatora płatności do przeliczenia wypłaty nie powinien być automatycznie traktowany jako kurs właściwy dla księgowości albo VAT. To dwie odrębne warstwy. Pierwsza wyjaśnia, dlaczego na rachunek wpłynęła określona kwota w określonej walucie, druga wynika z zasad właściwych dla ujęcia danej transakcji. Jeśli firma tego nie rozdzieli, może próbować wyjaśniać jako błąd settlementu różnicę wynikającą wyłącznie z zastosowania innych zasad przeliczenia. Przy kilku rynkach i dużym wolumenie nawet niewielkie różnice kursowe mogą dawać istotne kwoty, dlatego powinny mieć własną kategorię kontrolną.

Zidentyfikuj środki pozostające w rezerwie

Rezerwa oznacza kwotę zatrzymaną przez marketplace zgodnie z obowiązującym mechanizmem rezerw, która na dany moment nie jest dostępna do wypłaty. Nie powinna być więc traktowana jak brakująca sprzedaż ani automatycznie jak koszt. Warto przy tym pamiętać, że rezerwa może mieć charakter dynamicznego salda, dlatego nie zawsze da się przypisać ją w relacji jeden do jednego do konkretnych wcześniejszych transakcji. Z perspektywy zamknięcia miesiąca ważniejsze jest ustalenie, jaka kwota pozostaje zatrzymana oraz jaki jest jej wpływ na różnicę pomiędzy aktywnością sprzedażową, settlementem i bankiem, w takim zakresie, w jakim pozwalają na to dostępne dane.

Przy kolejnych cyklach trzeba następnie obserwować, jak zmienia się saldo rezerwy i czy wcześniej zatrzymane środki stają się dostępne do wypłaty. Nie zawsze będzie możliwe przewidzenie z góry dokładnego settlement ID, w którym określona kwota zostanie uwolniona, dlatego proces nie powinien opierać się na takim założeniu. Powinien natomiast pozwalać śledzić saldo przenoszone między cyklami i odróżniać środki zatrzymane od rzeczywistych braków. W ten sposób rezerwa staje się wyjaśnionym elementem rozrachunku, a nie kwotą, która przez kilka miesięcy pozostaje w księgach bez jasnego opisu.

Wyjaśnij chargebacki, korekty i kwoty przeniesione na kolejny okres

Chargebacki, adjustments i inne korekty mogą powodować, że saldo kolejnego settlementu zawiera pozycje odnoszące się do wcześniejszej aktywności. Nie należy jednak zakładać, że każdy chargeback automatycznie oznacza korektę sprzedaży albo VAT. Jest to zdarzenie związane z zakwestionowaniem płatności, a jego skutki księgowe i podatkowe trzeba ustalić na podstawie konkretnej sytuacji. To właśnie dlatego zamknięcie jednego miesiąca powinno pozostawiać możliwie dobrze opisane saldo. Jeżeli niewyjaśniona kwota z listopada zostanie po prostu przeniesiona do grudnia, a w grudniu dojdą do niej nowe refundacje, rezerwy i chargebacki, po kilku cyklach bardzo trudno będzie ustalić, z czego naprawdę wynika różnica.

Każda istotna pozycja przechodząca na kolejny okres powinna więc mieć opis, źródło i możliwy do śledzenia dalszy przebieg, nawet jeżeli w danym momencie nie można jeszcze wskazać dokładnej daty jej ostatecznego rozliczenia. Najważniejsza zasada na tym etapie jest prosta: to, że sprzedaż nie zgadza się z przelewem, jest normalne; problem zaczyna się wtedy, gdy nie potrafisz wyjaśnić różnicy. W dobrze zamkniętym miesiącu różnica między aktywnością sprzedażową a bankiem nie jest przypadkową kwotą. Da się wskazać, jaka część wynika z refundacji, jaka z prowizji i innych opłat, jaka z przewalutowania, jaka z rezerwy, a jaka z korekt lub pozycji przeniesionych między cyklami. Dopiero wtedy bank potwierdza settlement, zamiast służyć jako jego substytut.

Black Friday w praktyce — przykład zamknięcia listopada

Załóżmy uproszczony scenariusz, w którym listopadowa aktywność sprzedażowa daje 120 000 EUR wartości brutto transakcji z klientami, a w tej kwocie 20 000 EUR stanowi VAT według założeń przyjętych w przykładzie. Dla uproszczenia pokazujemy tutaj VAT zawarty w wartości transakcji klienckich; nie oznacza to, że cała ta kwota jest zawsze VAT-em rozliczanym przez sprzedawcę. W zależności od modelu konkretnej transakcji część obowiązków może spoczywać na sprzedawcy, a w określonych przypadkach na marketplace działającym jako deemed supplier. W rozrachunku pojawiają się następnie refundacje na 12 000 EUR, prowizje i opłaty FBA na 18 000 EUR, reklamy i pozostałe opłaty na 3 000 EUR oraz 5 000 EUR zatrzymane w rezerwie. Na rachunek bankowy wpływa ostatecznie 82 000 EUR. Każda z tych kwot opisuje inne zdarzenie, dlatego powinna pozostać widoczna jako osobna warstwa uzgodnienia.

Dlaczego przychodem nie jest 82 000 EUR?

Kwota 82 000 EUR jest w tym przykładzie wynikiem settlementu po uwzględnieniu refundacji, opłat i rezerwy, a nie prostym odpowiednikiem wartości transakcji z klientami. Gdyby firma potraktowała ją automatycznie jako listopadową sprzedaż lub przychód, połączyłaby w jednej liczbie kilka zdarzeń o zupełnie innym charakterze. Zniknęłaby informacja o wartości aktywności sprzedażowej, zwrotach, prowizjach, kosztach fulfillmentu, reklamach oraz środkach pozostających czasowo poza bieżącą wypłatą. Nie oznacza to jednocześnie, że pełne 120 000 EUR zawsze musi zostać zaprezentowane jako przychód sprzedawcy w rozumieniu rachunkowym. To wymaga uwzględnienia modelu działalności, zasad principal–agent oraz szczególnych przypadków podatkowych, w tym deemed supplier.

Dla reconciliation najważniejsze jest rozdzielenie wartości transakcji klientowskich od przychodu rachunkowego i od końcowej wypłaty. W tym przykładzie firma powinna być w stanie pokazać, że 82 000 EUR nie pojawiło się przypadkowo, lecz jest rezultatem konkretnych pozycji, które można prześledzić. Dzięki temu właściciel biznesu widzi jednocześnie skalę aktywności sprzedażowej, wpływ refundacji, koszt działania na marketplace oraz kwotę zatrzymaną w rezerwie. To pozwala analizować marżę i płynność bez mieszania wyniku biznesowego z mechaniką wypłat.

Gdzie trafia sprzedaż?

Punktem wyjścia jest 120 000 EUR wartości brutto transakcji z klientami. W modelowym równaniu 20 000 EUR tej kwoty stanowi VAT, a pozostałe 100 000 EUR odpowiada wartości netto transakcji klienckich przed dalszymi korektami. Nie należy jednak automatycznie przenosić tych wartości do ksiąg ani rozliczeń VAT bez sprawdzenia struktury transakcji. Trzeba ustalić, które sprzedaże były B2C, które B2B, z jakich krajów wysyłano towar, gdzie znajdował się nabywca, jakie stawki zastosowano oraz kto odpowiadał za rozliczenie podatku. Jeżeli część transakcji była objęta mechanizmem deemed supplier, sposób ich wykazania po stronie sprzedawcy może różnić się od zwykłej sprzedaży.

Dlatego 120 000 EUR należy traktować przede wszystkim jako warstwę aktywności sprzedażowej potrzebną do reconciliation, którą następnie rozbija się według właściwych parametrów. Dopiero po takim podziale można ustalić, jaka część transakcji trafia do lokalnych rozliczeń, jaka do OSS, jaka ma charakter B2B oraz które pozycje są objęte szczególnymi zasadami marketplace. Agregat brutto jest potrzebny do kontroli, ale sam nie kończy procesu. Jest punktem wyjścia do prawidłowej klasyfikacji podatkowej i rachunkowej.

Gdzie trafiają refundacje?

Refundacje w wysokości 12 000 EUR nie powinny zostać potraktowane jako ogólny koszt prowadzenia sprzedaży. Trzeba je powiązać z konkretnymi wcześniejszymi transakcjami i ustalić, czego dokładnie dotyczą. Część może obejmować pełne zwroty zamówień, część tylko jeden produkt z koszyka, a część inne korekty ceny. Dopiero po identyfikacji pierwotnej transakcji można ustalić właściwy sposób ujęcia korekty sprzedaży i VAT. Jeżeli zamówienie obejmowało towary opodatkowane różnymi stawkami, nie można automatycznie zastosować jednej proporcji do całej refundowanej kwoty. Korekta powinna odpowiadać temu elementowi sprzedaży, którego rzeczywiście dotyczy zwrot.

W praktyce 12 000 EUR powinno więc tworzyć osobną warstwę uzgodnienia. Firma powinna umieć przejść od tej kwoty do konkretnych order ID, dokumentów, stawek i krajów rozliczenia. Jeżeli część refundacji pojawiła się dopiero w grudniu, nie oznacza to automatycznie, że należy ją mechanicznie cofnąć do listopada. Trzeba zachować związek z pierwotną transakcją, a właściwy okres wykazania korekty ustalić według zasad mających zastosowanie do danego rodzaju sprzedaży i procedury VAT.

Gdzie trafiają prowizje i pozostałe opłaty?

Prowizje i opłaty FBA na 18 000 EUR oraz reklamy i pozostałe opłaty na 3 000 EUR powinny być zidentyfikowane oddzielnie od transakcji klientowskich. Z punktu widzenia banku po prostu zmniejszają kwotę wypłaty, ale dla analizy biznesowej ich rozdzielenie jest kluczowe. Prowizja sprzedażowa mówi coś innego o rentowności kanału niż magazynowanie, fulfillment czy reklama. Jeżeli wszystkie te elementy zostaną skompensowane z wartością transakcji bez odrębnej identyfikacji, firma traci możliwość rzetelnego porównania ekonomiki poszczególnych produktów, rynków i modeli realizacji.

Nie każda pozycja widoczna w settlementcie powinna jednak automatycznie trafić na konto kosztowe. Korekty i adjustments mogą mieć różny charakter, dlatego wymagają wcześniejszego rozpoznania. W przypadku usług należy również sprawdzić właściwe dokumenty, kontrahenta oraz sposób rozliczenia VAT. Dla polskiego przedsiębiorcy część usług zagranicznych może wiązać się z obowiązkiem rozliczenia importu usług, w tym VAT na zasadzie reverse charge. Settlement pokazuje więc, jak dana pozycja wpłynęła na saldo, ale nie zastępuje jej prawidłowej klasyfikacji podatkowej i księgowej.

Co dzieje się z rezerwą?

Kwota 5 000 EUR pozostająca w rezerwie nie powinna zostać potraktowana ani jako koszt, ani jako brakująca sprzedaż. Oznacza ona w tym przykładzie część środków, która zgodnie z obowiązującym mechanizmem rezerw nie jest w danym momencie dostępna do wypłaty. Rezerwa może mieć charakter dynamicznego salda i nie zawsze da się przypisać ją jeden do jednego do konkretnych wcześniejszych zamówień. Z punktu widzenia zamknięcia miesiąca ważniejsze jest to, aby firma potrafiła wskazać jej wartość i wyjaśnić, jaki ma wpływ na różnicę pomiędzy aktywnością transakcyjną, settlementem i kwotą widoczną na rachunku.

W kolejnych cyklach trzeba obserwować, jak saldo rezerwy się zmienia i czy wcześniej zatrzymane środki stają się dostępne do wypłaty. Nie należy zakładać z góry, że całe 5 000 EUR pojawi się później w jednym przelewie. Rezerwa może być częściowo zwalniana, a jednocześnie uzupełniana o nowe kwoty. Dlatego jej uzgodnienie polega przede wszystkim na śledzeniu salda i zmian pomiędzy okresami, a nie na oczekiwaniu przelewu dokładnie odpowiadającego wartości rezerwy z końca listopada.

Jak na końcu dochodzimy do kwoty widocznej na rachunku?

W uproszczonym przykładzie droga od aktywności sprzedażowej do banku wygląda następująco: 120 000 EUR – 12 000 EUR refundacji – 18 000 EUR prowizji i FBA – 3 000 EUR reklam i innych opłat – 5 000 EUR rezerwy = 82 000 EUR wypłaty. To równanie jest mostem uzgodnieniowym pomiędzy aktywnością transakcyjną a wypłatą, a nie schematem dekretacji. Każdy z jego elementów ma własny charakter i może wymagać odrębnego ujęcia rachunkowego lub podatkowego. Zadaniem równania jest wyjaśnienie, jak matematycznie powstała wartość payoutu, a nie zastąpienie szczegółowej analizy danych źródłowych.

Właśnie tutaj najlepiej widać sens całego procesu. Transakcje klientowskie pokazują aktywność biznesu, refundacje pokazują późniejsze korekty, opłaty pozwalają zrozumieć koszt kanału, rezerwa wyjaśnia część środków niedostępnych jeszcze do wypłaty, a bank potwierdza końcowy przepływ pieniężny. Jeżeli każdą z tych warstw da się odtworzyć, różnica między 120 000 EUR a 82 000 EUR nie jest sama w sobie problemem. Problem pojawia się wtedy, gdy firma nie potrafi wyjaśnić, dlaczego 38 000 EUR nie znalazło się w bieżącej wypłacie i z jakich kategorii ta różnica wynika.

Najczęstsze błędy przy zamykaniu miesiąca po Black Friday

Księgowanie wypłaty netto jako sprzedaży

Najbardziej podstawowy błąd polega na potraktowaniu kwoty wpływającej z marketplace jako wartości miesięcznej sprzedaży. Po Black Friday jest to szczególnie ryzykowne, ponieważ settlement może obejmować duży wolumen refundacji, opłat, rezerw i innych adjustments. Kwota wypłaty jest rezultatem tych wszystkich elementów, a nie prostym raportem aktywności sprzedażowej. Jeżeli księgowość rozpocznie miesiąc od banku i potraktuje wpływ jako sprzedaż, traci możliwość poprawnego rozdzielenia tego, co wydarzyło się na poziomie transakcji z klientami, od tego, co zostało później potrącone, skorygowane albo czasowo zatrzymane.

Taki skrót uderza również w analitykę zarządczą. Właściciel firmy może zobaczyć niższą wartość, którą interpretuje jako słabszą sprzedaż, podczas gdy faktycznie miesiąc był rekordowy, ale jednocześnie naliczono wysokie prowizje, refundacje i rezerwę. Przy planowaniu ekspansji łatwo wtedy błędnie ocenić potencjał rynku, marżę produktu albo efektywność promocji. Bank powinien zamykać proces reconciliation, a nie definiować miesięczną aktywność sprzedażową.

Kompensowanie sprzedaży, zwrotów i prowizji jedną kwotą

Drugim częstym błędem jest próba sprowadzenia całego miesiąca do jednej wartości netto. Matematycznie może się nawet zgadzać: aktywność sprzedażowa pomniejszona o refundacje, opłaty i inne potrącenia prowadzi do kwoty zbliżonej do wypłaty. Problem polega na tym, że znika struktura zdarzeń. Firma nie widzi już, jaka była wartość transakcji z klientami, ile zostało później skorygowane, ile kosztowało korzystanie z marketplace i jaka część salda pozostała w rezerwie. Zgodność końcowej liczby nie oznacza jeszcze poprawnego zamknięcia miesiąca.

Przy dużej skali takie kompensowanie utrudnia także kontrolę VAT i kosztów. Refundacja może odnosić się do wcześniejszej transakcji, prowizja może wymagać odrębnej analizy podatkowej, a rezerwa nie jest kosztem. Jeżeli wszystkie te wartości zostaną wrzucone do jednej kategorii, późniejsze odtworzenie prawidłowego sposobu rozliczenia wymaga ponownego przejścia przez dane źródłowe. Znacznie bezpieczniej jest zachować osobne warstwy od samego początku i uzgadniać je dopiero na końcu do settlementu.

Pomijanie refundacji z przełomu miesięcy

Black Friday kończy się w listopadzie, ale fala zwrotów nie. Część klientów odeśle towar dopiero w grudniu, a niektóre refundacje pojawią się jeszcze później. Jeżeli firma analizuje wyłącznie listopadowe settlementy, może uznać proces za zakończony bez zachowania mechanizmu, który pozwoli późniejsze refundacje prawidłowo powiązać z listopadowymi transakcjami. Nie chodzi o przewidywanie wszystkich przyszłych zwrotów ani o automatyczne korygowanie listopada z góry. Chodzi o to, aby późniejsza refundacja nie została oderwana od pierwotnej sprzedaży i potraktowana jako przypadkowe pomniejszenie bieżącego miesiąca.

Problem staje się szczególnie widoczny, gdy grudniowa refundacja zostaje błędnie przypisana do bieżącej sprzedaży bez wskazania, czego naprawdę dotyczy. Wtedy wynik obu miesięcy przestaje przedstawiać spójną historię transakcji. Poprawne reconciliation powinno zachować identyfikator zamówienia, dokument, pierwotną stawkę i kraj rozliczenia, a następnie zastosować właściwe zasady dotyczące okresu ujęcia korekty. Dzięki temu przełom miesiąca nie niszczy ciągłości danych, nawet jeśli refundacja pojawia się kilka tygodni po pierwotnym zakupie.

Traktowanie kosztów marketplace jak rabatu od sprzedaży

Prowizja, opłata za fulfillment czy magazynowanie nie stają się rabatem dla klienta tylko dlatego, że zostały potrącone przed wypłatą. Są odrębnymi elementami rozrachunku, które należy zidentyfikować i przypisać do odpowiedniej kategorii. Nie oznacza to automatycznie określonego sposobu prezentacji przychodu w księgach, ponieważ ten może zależeć od charakteru relacji principal–agent oraz innych okoliczności. Z punktu widzenia reconciliation kluczowe jest jednak to, aby opłaty nie znikały w jednej wartości netto razem z transakcjami klientowskimi.

Jednocześnie nie należy zakładać, że każda pozycja z minusem w settlementcie jest standardowym kosztem usługi. Mogą tam występować adjustments, zmiany rezerwy i inne korekty. Dlatego najpierw trzeba rozpoznać charakter pozycji, a dopiero potem decydować o jej ujęciu. W przypadku usług znaczenie mają także właściwe dokumenty i rzeczywisty charakter świadczenia, ponieważ od tego zależy sposób rozliczenia VAT, w tym ewentualnego importu usług.

Nieuwzględnianie środków zatrzymanych w rezerwie

Jeżeli część środków pozostaje w rezerwie, wypłata może być wyraźnie niższa od wartości, której przedsiębiorca spodziewa się na podstawie aktywności transakcyjnej i innych bieżących rozliczeń. Błędem jest wtedy uznanie różnicy za brakującą sprzedaż, niezaksięgowany koszt albo problem z bankiem bez wcześniejszego sprawdzenia mechanizmu rezerw. Rezerwa oznacza kwotę, która na dany moment nie jest dostępna do wypłaty i powinna być widoczna jako odrębny element uzgodnienia.

Równie problematyczne jest pozostawianie takiego salda bez dalszej kontroli. Rezerwa może zmieniać się z cyklu na cykl i mieć charakter dynamiczny, dlatego nie wystarczy raz zapisać jej wartości i uznać tematu za zamknięty. Trzeba śledzić, jak zmienia się saldo oraz czy wcześniej zatrzymane środki są później uwalniane. Dzięki temu można odróżnić normalne działanie mechanizmu rezerw od rzeczywistego błędu rozliczeniowego.

Brak powiązania zwrotu z pierwotną sprzedażą

Refundacja bez możliwego do odtworzenia związku z pierwotnym zamówieniem jest jedną z najbardziej problematycznych pozycji podczas zamknięcia. Sama kwota nie mówi, którego produktu dotyczyła, jaka była pierwotna stawka VAT, w którym kraju transakcja została rozliczona ani czy marketplace odpowiadał za VAT zgodnie z zasadami deemed supplier. Przy kilku tysiącach zwrotów brak takich informacji oznacza konieczność ręcznego odtwarzania historii sprzedaży, często długo po zakończeniu miesiąca.

Szczególnie niebezpieczne są częściowe refundacje. Jeżeli jedno zamówienie obejmuje kilka produktów o różnych stawkach VAT, nie można po prostu rozłożyć refundacji proporcjonalnie na całe zamówienie. Trzeba wiedzieć, którego elementu dotyczyła korekta i do jakich parametrów pierwotnej transakcji należy ją odnieść. Dlatego order ID, właściwy dokument i dane podatkowe transakcji nie są dodatkiem do reconciliation, lecz podstawą pozwalającą uniknąć błędów finansowych i podatkowych.

Założenie, że OSS eliminuje wszystkie zagraniczne obowiązki VAT

OSS znacząco upraszcza rozliczanie określonej sprzedaży B2C w UE, ale nie jest systemem, który przejmuje wszystkie obowiązki VAT związane z działalnością zagraniczną. Firma może korzystać z OSS dla części transakcji i jednocześnie mieć lokalne obowiązki podatkowe wynikające z innych zdarzeń. Dotyczy to szczególnie przedsiębiorstw korzystających z magazynów w kilku państwach, utrzymujących tam zapas lub przemieszczających własne towary pomiędzy krajami.

Dlatego założenie „mamy OSS, więc nie musimy już analizować poszczególnych krajów” jest ryzykowne. Przy zamknięciu miesiąca nadal trzeba wiedzieć, skąd towar został wysłany, dokąd trafił, jaki status miał klient i jaki model transakcji miał zastosowanie. OSS jest jedną z możliwych ścieżek rozliczenia, a nie zamiennikiem pełnej klasyfikacji sprzedaży i pozostałych zdarzeń VAT. Im więcej magazynów i rynków obejmuje ekspansja, tym ważniejsze staje się to rozróżnienie.

Pomijanie transferów własnych zapasów między magazynami i krajami

Przemieszczenie własnego zapasu nie wygląda jak sprzedaż, ponieważ nie ma zewnętrznego klienta ani klasycznej płatności. Właśnie dlatego łatwo je pominąć podczas reconciliation opartego głównie na zamówieniach i settlementach. W modelu FBA towar może jednak przemieszczać się między magazynami i państwami, a takie operacje mogą mieć odrębne konsekwencje VAT. Nie powinny być mieszane ze sprzedażą klientowską, ale również nie mogą zostać całkowicie pominięte tylko dlatego, że nie generują typowego payoutu.

Dla firmy planującej ekspansję ten błąd może być szczególnie kosztowny organizacyjnie. Nowy magazyn zagraniczny może poprawić czas dostawy i dostępność produktu, ale jednocześnie zwiększyć liczbę lokalnych zdarzeń wymagających kontroli podatkowej. Dlatego dane o ruchach własnego towaru powinny być analizowane obok sprzedaży, choć jako odrębna kategoria. W przeciwnym razie firma może mieć poprawnie uzgodniony bank i settlement, a jednocześnie niepełny obraz obowiązków VAT wynikających z lokalizacji i przemieszczania zapasu.

Checklista przed zamknięciem miesiąca po Black Friday

Po przejściu przez cały proces warto wykonać ostatnią kontrolę, która pokaże, czy listopad można rzeczywiście uznać za zamknięty. Nie chodzi o to, aby wszystkie raporty pokazywały identyczne kwoty, ponieważ sprzedaż, VAT, refundacje, settlement i bank opisują różne momenty i różne zdarzenia. Chodzi o to, aby każda istotna różnica miała konkretne wyjaśnienie i można było przejść od danych źródłowych do końcowego rozrachunku bez pozostawiania dużych kwot w kategorii „do sprawdzenia później”. Przy dużym wolumenie Black Friday taka kontrola jest szczególnie ważna, bo nawet drobny błąd w regule klasyfikacji może zostać powielony na setkach transakcji.

• Wartość transakcji sprzedażowych została uzgodniona według kraju, stawki VAT i właściwego modelu rozliczenia.
• Sprzedaż, refundacje, fizyczne zwroty i opłaty związane ze zwrotami są pokazane jako odrębne zdarzenia.
• Każda refundacja ma możliwe do odtworzenia powiązanie z pierwotnym order ID lub identyfikatorem transakcji oraz właściwym dokumentem.
• Częściowe refundacje zostały przypisane do właściwego elementu pierwotnej transakcji, zamiast automatycznie rozliczone proporcjonalnie do całego zamówienia.
• Prowizje, fulfillment, magazynowanie, reklamy i pozostałe opłaty zostały zidentyfikowane oddzielnie od wartości transakcji klientowskich.
• Faktury, noty korygujące i inne dokumenty dotyczące opłat zostały pobrane i zarchiwizowane.
• Transfery własnego zapasu pomiędzy magazynami i państwami zostały oddzielone od sprzedaży do klientów.
• Transakcje, w których marketplace odpowiada za VAT zgodnie z zasadami deemed supplier, zostały wyodrębnione od transakcji rozliczanych podatkowo przez sprzedawcę.
• Rezerwy, adjustments, chargebacki i inne pozycje wpływające na saldo zostały zidentyfikowane i opisane w takim zakresie, w jakim pozwalają na to dostępne dane.
• Kwoty pozostające do rozliczenia pomiędzy miesiącami są możliwe do prześledzenia i nie zostały potraktowane jako przypadkowe różnice.
• Settlement został uzgodniony z wypłatami na rachunku bankowym z uwzględnieniem dat i walut.
• Przewalutowania użyte przy wypłacie zostały oddzielone od kursów właściwych dla księgowości i VAT.
• Dane dotyczące numerów VAT, krajów wysyłki, lokalizacji zapasu i sposobu realizacji zamówień zostały sprawdzone przed zamknięciem okresu.

Jeżeli przy którymś z tych punktów odpowiedź brzmi „nie wiemy”, nie oznacza to automatycznie błędu podatkowego lub księgowego. Oznacza natomiast, że proces nie jest jeszcze w pełni uzgodniony. W okresie wysokiego wolumenu warto rozróżnić prawdziwy błąd od zwykłej różnicy czasowej, ale do tego potrzebujesz danych pozwalających udowodnić, z czego dana różnica wynika. To właśnie jest praktyczna wartość checklisty: nie ma doprowadzić wszystkich liczb do jednej sumy, lecz potwierdzić, że każda warstwa zamknięcia ma własne źródło i można ją połączyć z kolejnym etapem procesu.

Jak powinno wyglądać poprawnie zamknięte rozliczenie Black Friday?

Cztery warstwy, których nie należy ze sobą mylić

Poprawnie zamknięty miesiąc nie oznacza, że sprzedaż, VAT, settlement i przelew pokazują tę samą wartość. Wręcz przeciwnie: prawidłowo zbudowany proces zakłada, że opisują one inne etapy działalności i dlatego muszą być analizowane osobno. Pierwszą warstwą są transakcje sprzedażowe i wynikające z nich rozliczenia VAT. To tutaj ustalasz wartość aktywności klientowskiej, kraj wysyłki i dostawy, status B2B lub B2C, stawkę podatku oraz to, kto odpowiada za jego rozliczenie. Drugą warstwą są późniejsze zwroty i refundacje, które trzeba powiązać z pierwotnymi transakcjami i ująć według zasad właściwych dla danej sprzedaży. Trzecią tworzą prowizje, opłaty i inne pozycje związane z marketplace, które wpływają na rozrachunek, ale nie powinny znikać w jednej wartości netto.

Dopiero czwartą warstwą jest settlement i faktyczny przelew bankowy. To na tym poziomie wcześniejsze zdarzenia spotykają się w saldzie, które następnie zostaje wypłacone, pozostaje częściowo w rezerwie albo przechodzi do kolejnego cyklu. Schemat można więc przedstawić jako transakcje sprzedażowe i VAT zwroty i korekty prowizje, opłaty i inne adjustments settlement i bank. Nie jest to jednak prosty łańcuch, w którym każda kolejna liczba musi być niższa od poprzedniej. Część korekt może odnosić się do wcześniejszych okresów, rezerwa może zmieniać się dynamicznie, a przewalutowanie może tworzyć dodatkowe różnice. Celem jest nie zgodność wszystkich wartości, lecz możliwość logicznego przejścia między nimi.

Kontrola zaczyna się na poziomie pojedynczej transakcji

Najlepszym testem jakości zamknięcia jest możliwość wybrania konkretnego zamówienia i prześledzenia jego historii. Powinieneś być w stanie zobaczyć dane transakcji z klientem, ustalić kraj oraz model VAT, znaleźć odpowiedni dokument, sprawdzić późniejszą refundację, jeżeli wystąpiła, oraz zobaczyć, jak związane z transakcją pozycje wpłynęły na rozrachunek. Nie oznacza to, że każdy koszt marketplace musi dać się przypisać jeden do jednego do pojedynczego orderu. Niektóre opłaty, rezerwy czy korekty działają na innym poziomie. Ważne jest jednak zachowanie wystarczającego śladu, żeby przejść z danych źródłowych do miesięcznych sum i z miesięcznych sum do settlementu.

W firmie obsługującej kilka tysięcy zamówień taki test nie powinien wymagać ręcznego przeszukiwania kilkunastu plików. Jeżeli każda większa różnica oznacza wielogodzinne śledztwo, proces może działać przy obecnej skali, ale najprawdopodobniej nie będzie odporny na dalszą ekspansję. Dobrze zamknięty Black Friday powinien pozostawić po sobie uporządkowane dane, jasne saldo i możliwość szybkiego wyjaśnienia pozycji przechodzących na kolejny miesiąc. To daje kontrolę nie tylko księgowości, lecz również właścicielowi firmy, który może analizować wyniki bez obawy, że marża lub cash flow są zniekształcone przez nieuzgodnione potrącenia.

Sprzedaż na Amazonie po Black Friday: nie zamykaj miesiąca, dopóki nie potrafisz wyjaśnić różnicy

Wysoki obrót sam w sobie nie jest największym problemem po Black Friday. Problem zaczyna się wtedy, gdy wraz ze wzrostem liczby zamówień rośnie również liczba transakcji, których firma nie potrafi powiązać z refundacjami, opłatami, settlementami i bankiem. Przy jednym rynku kilka niewyjaśnionych pozycji może jeszcze zostać sprawdzonych ręcznie. Przy ekspansji do kolejnych państw dochodzą różne stawki VAT, statusy klientów, lokalizacje zapasu, procedury rozliczeniowe, waluty oraz dodatkowe dokumenty. Ten sam nieuporządkowany proces zaczyna wtedy generować coraz większą liczbę wyjątków, a zamknięcie miesiąca trwa coraz dłużej.

Sam przelew od Amazon nie odpowiada na pytanie, jaka była wartość sprzedaży w listopadzie ani jaki VAT powinien zostać wykazany przez sprzedawcę. Pokazuje przede wszystkim wynik określonego rozrachunku. Dlatego poprawne zamknięcie wymaga połączenia sprzedaży, VAT, zwrotów, kosztów, rozliczeń i banku, ale bez mieszania ich ze sobą. Sprzedaż trzeba analizować na podstawie danych transakcyjnych, VAT przypisywać według właściwych zasad i modelu transakcji, refundacje łączyć z pierwotną sprzedażą, opłaty identyfikować oddzielnie, a settlement na końcu dopasować do przepływów pieniężnych. Dopiero taki proces pozwala powiedzieć, że różnica między obrotem a wypłatą jest wyjaśniona, a nie tylko matematycznie „dopasowana”.

Dla firmy planującej dalszą ekspansję ma to jeszcze większe znaczenie. Dobry proces zamknięcia miesiąca powinien działać nie tylko wtedy, gdy sprzedajesz w Polsce i na jednym dodatkowym rynku, ale również wtedy, gdy dochodzą nowe magazyny, kraje i większy wolumen. Jeżeli obecnie każda zagraniczna rejestracja VAT, transfer zapasu lub niejasna refundacja wymaga osobnego ręcznego dochodzenia, dalszy wzrost będzie jedynie zwiększał ten problem. Właśnie dlatego warto uporządkować rozliczenia zanim kolejny Black Friday albo wejście na nowy rynek zwielokrotni liczbę transakcji wymagających kontroli.

Jeżeli sprzedajesz na Amazonie w kilku krajach i chcesz mieć pewność, że lokalne obowiązki VAT, OSS, zagraniczne rejestracje oraz dane potrzebne do miesięcznych rozliczeń są ze sobą spójne, amavat może wesprzeć Cię w uporządkowaniu tego procesu. Chodzi nie tylko o przygotowanie samego rozliczenia podatku, ale również o zbudowanie procesu, w którym wiadomo, jakie dane są potrzebne, które transakcje trafiają do poszczególnych rozliczeń i gdzie szukać przyczyny różnicy między sprzedażą, settlementem a bankiem. Przy ekspansji taka kontrola pozwala rozwijać sprzedaż bez dokładania równie szybko rosnącego problemu z VAT i zamknięciem miesiąca.