Księgowość e-commerce, Technologie i automatyzacja w e-commerce, VAT Compliance, VAT OSS i eksport

Marketplace, checkout czy kanał sprzedaży oparty o AI? Jak zakwalifikować Von Halsky/InPost Buy w księgowości sklepu internetowego

Na podstawie obecnie dostępnych informacji Von Halsky/InPost Buy można funkcjonalnie traktować jako nowy kanał sprzedaży oparty o AI, ale z perspektywy księgowej najważniejsza nie jest sama nazwa tego modelu. Rozwiązanie może być opisywane jako kanał sprzedaży, interfejs elektroniczny, platforma pośrednicząca, checkout albo nawet marketplace w szerokim rozumieniu tego pojęcia. Żadna z tych etykiet nie rozstrzyga jednak automatycznie, kto powinien wykazać przychód ze sprzedaży towaru, kto odpowiada za podatkowe udokumentowanie transakcji i kto rozlicza należny VAT. Decydujący jest rzeczywisty model współpracy wynikający z regulaminu, umowy ze sprzedawcą oraz faktycznego przebiegu zamówienia i rozliczeń. Obecnie dostępne informacje wskazują, że w podstawowym modelu sprzedawcą wobec klienta pozostaje sklep. Jeżeli potwierdzają to warunki umowne i sposób realizacji transakcji, sklep wykazuje przychód ze sprzedaży towaru, ujmuje sprzedaż w odpowiednich ewidencjach, odpowiada za wymagane prawem udokumentowanie lub zaewidencjonowanie transakcji oraz rozlicza należny VAT. Operator kanału wykazuje natomiast własne wynagrodzenie za świadczone usługi, którego charakter może obejmować udostępnienie kanału sprzedaży, obsługę technologiczną, prowizję, obsługę płatności, dostawę lub inne elementy wynikające z konkretnej umowy.

Spis treści

Dla średniej firmy e-commerce najważniejsze jest więc oddzielenie warstwy technologicznej od treści ekonomicznej transakcji. AI może zmienić sposób, w jaki klient znajduje produkt, porównuje oferty, podejmuje decyzję i finalizuje zakup, ale sama zmiana interfejsu nie musi oznaczać zmiany sprzedawcy ani zasad prezentowania przychodu. Klient może przejść przez znaczną część procesu zakupowego w zewnętrznej aplikacji, a mimo to stroną umowy sprzedaży nadal może pozostawać sklep. Również samo uznanie rozwiązania za marketplace nie oznacza, że operator staje się właścicielem towaru albo wykazuje całą wartość sprzedaży jako własny przychód. Na wielu platformach handlowych sprzedawcą wobec klienta pozostaje zewnętrzny merchant, natomiast operator zarabia na prowizji lub innych usługach. Dlatego punktem wyjścia nie powinno być pytanie, jak nazwać Von Halsky/InPost Buy, lecz kto w rzeczywistości kontroluje towar przed przekazaniem go klientowi, kto ponosi główne ryzyko związane ze sprzedażą i kto jest głównym wykonawcą zobowiązania wobec kupującego.

Dlaczego klasyfikacja Von Halsky/InPost Buy w ogóle ma znaczenie?

Nowy interfejs sprzedaży nie zawsze oznacza nowy model księgowy

Gdy w e-commerce pojawia się nowy sposób sprzedaży, naturalnym odruchem jest próba przypisania go do jednej ze znanych kategorii. Jeżeli klient kupuje poza klasyczną ścieżką na stronie sklepu, rozwiązanie może zostać uznane za marketplace. Jeżeli zewnętrzny system przejmuje część koszyka, płatności lub finalizacji zamówienia, może zostać potraktowany jako checkout. Jeżeli zamówienie ostatecznie trafia do systemu sklepu, pojawia się z kolei argument, że to po prostu kolejny kanał sprzedaży własnej. Każde z tych określeń może być częściowo trafne, ale żadne samo w sobie nie daje jeszcze odpowiedzi, jak ująć przychód, prowizję, płatność i VAT. W praktyce jeden model może jednocześnie pełnić kilka funkcji: pozyskiwać klienta, prezentować oferty wielu sprzedawców, prowadzić użytkownika przez proces zakupowy, przekazywać płatność i organizować dostawę. Dla księgowości ważniejsze od etykiety pozostaje jednak to, kto jest stroną sprzedaży i jaka jest ekonomiczna treść poszczególnych przepływów pieniężnych.

W przypadku Von Halsky/InPost Buy dodatkowym źródłem niepewności jest właśnie połączenie kilku warstw, które wcześniej częściej występowały osobno. Klient może wyszukać i porównać produkty przy pomocy AI, a następnie przejść do finalizacji zakupu w aplikacji. Sprzedawca konfiguruje jednak własny sklep, katalog produktów, wysyłki, zwroty i bramkę płatności, a zamówienia są przekazywane do dalszej obsługi przez niego lub wykorzystywany przez niego system integracyjny. Taki model wskazuje, że operator dostarcza technologię kanału sprzedaży oraz może świadczyć albo organizować usługi płatnicze, dostawę i obsługę ścieżki zwrotu, ale nie oznacza automatycznie, że przejmuje magazynowanie, pakowanie, fulfillment, odpowiedzialność za towar czy rolę sprzedawcy. Zakres obowiązków każdej strony trzeba ustalić na podstawie umowy i rzeczywistego przebiegu procesu. W rachunkowości operacje ujmuje się zgodnie z ich treścią ekonomiczną, a nie tylko z nazwą używaną w interfejsie, materiałach promocyjnych czy nawet w samym tytule usługi.

Szczególnie istotne jest tutaj rozróżnienie między sytuacją, w której sklep działa jako główny sprzedawca, a sytuacją, w której pełni wyłącznie rolę pośrednika. Jeżeli sklep jest principalem, czyli kontroluje towar przed przekazaniem go klientowi i ponosi zasadniczą odpowiedzialność za realizację sprzedaży, powinien co do zasady wykazać przychód w pełnej wartości sprzedaży towaru, koszt własny sprzedanych produktów oraz osobno prowizję i pozostałe opłaty operatora. Jeżeli natomiast sklep byłby tylko agentem, a głównym sprzedawcą wobec klienta byłby operator, przychodem sklepu mogłoby być jedynie wynagrodzenie lub marża należna za pośrednictwo. W obecnie opisywanym modelu dostępne informacje wskazują raczej na pierwszy wariant, ale dla przedsiębiorcy prowadzącego większy e-commerce nie powinno to być założenie przyjmowane bez sprawdzenia. Ostateczną odpowiedź powinny potwierdzić warunki umowne, odpowiedzialność stron i rzeczywisty sposób przepływu towaru, płatności oraz ryzyk.

Trzy pytania, od których powinien zacząć e-commerce

Pierwsze pytanie brzmi: kto jest faktycznym sprzedawcą wobec klienta? Odpowiedzi nie daje samo to, kto pokazuje produkt w aplikacji ani kto odpowiada za atrakcyjność interfejsu zakupowego. Trzeba sprawdzić, kto jest stroną umowy z konsumentem, czyja nazwa widnieje w regulaminie zamówienia, kto ponosi ryzyko zapasu i niesprzedanego towaru, kto odpowiada za zgodność produktu z umową, reklamacje i zwroty oraz kto może zaakceptować albo odrzucić zamówienie. Znaczenie ma również to, kto ustala finalną cenę i rabaty, kto ponosi ryzyko chargebacków i zwrotu płatności oraz czy operator otrzymuje jedynie prowizję lub opłatę za usługę, czy też sam kupuje i odsprzedaje towar. Kontrola nad opisem produktu lub ceną może być ważną wskazówką, ale nie powinna być traktowana jako jedyne kryterium. Dopiero łączna analiza tych elementów pozwala ocenić, kto jest głównym wykonawcą zobowiązania wobec klienta i czy sklep powinien prezentować przychód brutto ze sprzedaży towaru.

Drugie pytanie dotyczy tego, kto odpowiada za podatkowe udokumentowanie i zaewidencjonowanie sprzedaży oraz za rozliczenie VAT. Nie zawsze będzie to po prostu wystawienie faktury, ponieważ sposób dokumentowania sprzedaży B2C zależy od rodzaju transakcji i obowiązujących przepisów. W praktyce może wystąpić paragon fiskalny, faktura wystawiana obowiązkowo lub na żądanie, dokument elektroniczny albo ewidencja sprzedaży bez paragonu, jeżeli spełnione są warunki odpowiedniego zwolnienia z obowiązku stosowania kasy fiskalnej. Dlatego bezpieczniej analizować nie sam dokument, lecz odpowiedzialność za prawidłowe ujęcie transakcji w wymaganych ewidencjach i rozliczeniach podatkowych. Jeżeli to sklep odpowiada za te obowiązki i pozostaje stroną sprzedaży, jest to mocny argument za tym, że przychód ze sprzedaży towaru powinien zostać wykazany po jego stronie. Trzeba jednak pamiętać, że przy transakcjach zagranicznych sama obecność platformy lub aplikacji nie rozstrzyga sposobu opodatkowania. Osobnej analizy mogą wymagać miejsce rozpoczęcia i zakończenia transportu, status nabywcy, lokalizacja magazynu, WSTO, OSS, import oraz status i siedziba sprzedawcy.

Trzecie pytanie brzmi: za co dokładnie operator kanału pobiera opłatę? To kluczowe zarówno dla prawidłowego księgowania kosztów, jak i dla późniejszej analizy rentowności kanału. Prowizja liczona jako procent od wartości zamówień może być ujmowana jako koszt kanału sprzedaży lub prowizji handlowej. Abonament albo opłata za technologię może mieć charakter usługi IT lub innej usługi obcej. Koszt promowania ofert może zostać zakwalifikowany jako reklama i marketing, a przesyłki oraz zwroty jako koszty transportu lub logistyki. Opłaty związane z obsługą transakcji płatniczych mogą być z kolei traktowane jako koszty obsługi płatności. Ostateczna klasyfikacja powinna wynikać z umowy, faktury, faktycznie wykonanej usługi, przyjętej polityki rachunkowości oraz potrzeb analitycznych przedsiębiorstwa. Nie należy natomiast zakładać, że jedna zbiorcza opłata może zostać dowolnie przypisana do marketingu, logistyki albo usług obcych tylko dlatego, że wszystkie te elementy występują w ramach jednego ekosystemu.

Istotne jest również rozróżnienie między potrąceniem opłaty z wypłaty a sposobem ujęcia przychodu w księgach. Jeżeli operator przekazuje sklepowi kwotę pomniejszoną o prowizję, nie oznacza to automatycznie, że przychodem sklepu jest tylko otrzymana kwota netto. Jeżeli sklep działa jako principal i to on dokonuje sprzedaży towaru, co do zasady wykazuje pełną wartość sprzedaży jako przychód, a prowizję lub inną opłatę operatora ujmuje oddzielnie jako koszt. Mechanizm rozliczenia pieniężnego nie powinien być mylony z prezentacją ekonomicznej treści transakcji. Dla firm rozwijających sprzedaż wielokanałową ma to duże znaczenie, ponieważ niewłaściwe ujmowanie kwot netto może zniekształcić przychody, marżę i porównywalność wyników pomiędzy kanałami. Dlatego o sposobie księgowania nie powinno decydować to, ile pieniędzy ostatecznie wpłynęło na rachunek po potrąceniu opłat, lecz to, kto sprzedał towar, kto kontrolował go przed przekazaniem klientowi i za jakie konkretne świadczenie operator pobrał swoje wynagrodzenie.

Czym właściwie jest Von Halsky/InPost Buy z perspektywy sklepu internetowego?

AI-owy asystent sprzedaży, który prowadzi klienta do zakupu

Najprościej wyobrazić sobie Von Halsky/InPost Buy jako dodatkową warstwę pomiędzy klientem a sklepem internetowym. Użytkownik nie musi zaczynać zakupu od wpisania adresu sklepu, przechodzenia przez kategorię, filtry i wewnętrzną wyszukiwarkę. Zamiast tego może rozpocząć od rozmowy z asystentem AI, który pomaga zdefiniować potrzebę, wyszukać produkty, porównać dostępne opcje i przejść przez kolejne etapy prowadzące do finalizacji zamówienia. Z punktu widzenia klienta proces staje się bardziej konwersacyjny i mniej zależny od tradycyjnej nawigacji po sklepie. Z punktu widzenia sprzedawcy oznacza to pojawienie się nowego miejsca, w którym jego oferta może zostać odkryta i wybrana. Produkt nadal pochodzi z konkretnego sklepu, ale droga do tego produktu zaczyna się w innym środowisku. W praktyce można więc mówić o AI-owym asystencie sprzedaży lub doradcy zakupowym, który pomaga klientowi znaleźć właściwy towar i doprowadza go do transakcji, choć sam nie staje się przez to stroną umowy sprzedaży. To rozróżnienie jest ważne, ponieważ technologiczna obecność pośrednika w procesie zakupowym nie przesądza jeszcze o tym, kto ekonomicznie i prawnie sprzedaje towar.

Dla sklepu internetowego oznacza to przede wszystkim rozszerzenie procesu sprzedaży o dodatkowy kanał dostępu do klienta. Oferta może być prezentowana poza tradycyjnym interfejsem sklepu, a użytkownik może zostać przeprowadzony przez znaczną część procesu zakupowego bez klasycznej ścieżki wejścia na stronę merchanta. Nie oznacza to jednak automatycznie, że operator przejmuje odpowiedzialność za cały proces sprzedażowy. W obecnie opisywanym modelu sprzedawca nadal konfiguruje swój sklep, katalog produktów, sposób obsługi wysyłek i zwrotów oraz bramkę płatności, a zamówienia są następnie przekazywane do jego dalszej obsługi lub do systemu, który z nim współpracuje. Dlatego bardziej trafne jest traktowanie rozwiązania jako warstwy odkrywania, rekomendowania i prowadzenia klienta przez zakup niż jako podmiotu, który z definicji przejmuje sprzedaż. Operator zapewnia technologię kanału i może, w zależności od modelu, uczestniczyć w obsłudze płatności, dostawy oraz zwrotów, natomiast rzeczywisty zakres odpowiedzialności sklepu trzeba każdorazowo odczytywać z umowy i przebiegu procesu.

Co zmienia się biznesowo, a co nie?

Największa zmiana dotyczy sposobu, w jaki sklep dociera do klienta i w jaki klient porusza się po ofercie. W tradycyjnym e-commerce to sprzedawca projektuje niemal całą ścieżkę zakupową: od reklamy i wejścia na stronę, przez kategorię produktową, wyszukiwarkę i kartę produktu, aż po koszyk i finalizację zamówienia. W kanale opartym o AI część tej ścieżki przejmuje zewnętrzny interfejs, który może wyszukać produkt, zestawić go z innymi ofertami i pomóc klientowi wybrać rozwiązanie odpowiadające jego potrzebom. Zmienia się więc źródło ruchu, sposób odkrywania oferty, interfejs zakupowy oraz rola algorytmu w podejmowaniu decyzji przez klienta. Dla przedsiębiorcy oznacza to również nowe wyzwania analityczne. Trzeba wiedzieć, które zamówienia pochodzą z tego kanału, jaką mają wartość, jaki generują poziom zwrotów, ile kosztuje ich obsługa i czy po uwzględnieniu prowizji, płatności, dostaw i pozostałych opłat kanał rzeczywiście poprawia rentowność sprzedaży.

Nie wszystko musi się jednak zmieniać razem z interfejsem. Jeżeli sprzedawcą wobec klienta nadal pozostaje sklep, a operator nie przejmuje kontroli nad towarem przed jego przekazaniem kupującemu, podstawowy sposób prezentacji przychodu może pozostać taki sam jak w innych kanałach sprzedaży własnej. Podobnie może być z odpowiedzialnością za podatkowe udokumentowanie i zaewidencjonowanie transakcji oraz z rozliczeniem VAT. Sama obecność AI w procesie zakupowym nie tworzy nowego rodzaju podatku ani nowej kategorii przychodu. Nie oznacza to jednak, że sklep może zignorować specyfikę kanału. Trzeba nadal ustalić, kto jest stroną umowy z klientem, kto odpowiada za reklamacje i zwroty, kto ustala warunki sprzedaży, kto ponosi ryzyko chargebacków i w jaki sposób rozliczane są opłaty operatora. Zmienia się sposób dotarcia do sprzedaży, ale nie musi zmieniać się sama ekonomiczna istota sprzedaży. To właśnie dlatego analiza powinna zaczynać się od umowy i faktycznego przebiegu transakcji, a nie od tego, jak nowoczesny jest interfejs.

Nawet jeżeli sposób ujmowania przychodu pozostaje taki sam jak w innych kanałach sprzedaży, warto prowadzić odrębną analitykę dla sprzedaży generowanej przez Von Halsky/InPost Buy. Z perspektywy rachunkowości zarządczej liczy się bowiem nie tylko to, jak transakcja trafia do ksiąg, ale również czy firma potrafi ocenić ekonomiczną wartość nowego kanału. Odrębne oznaczenie źródła zamówienia pozwala mierzyć przychód, koszt pozyskania klienta, prowizje, rentowność działań promocyjnych, marżę, poziom zwrotów i konwersję bez konieczności zmiany podstawowych zasad rachunkowości finansowej. Dla średniego e-commerce planującego ekspansję jest to szczególnie ważne, ponieważ kanał, który dobrze wygląda pod względem wzrostu sprzedaży, może po uwzględnieniu wszystkich kosztów generować znacznie słabszą marżę niż sprzedaż bezpośrednia. Osobna analityka pozwala więc oddzielić pytanie „jak zaksięgować sprzedaż?” od pytania „czy ten kanał faktycznie zarabia?” i daje zarządowi oraz osobom odpowiedzialnym za finanse dane potrzebne do podejmowania decyzji o dalszym skalowaniu.

Marketplace, checkout czy kanał sprzedaży oparty o AI? Najważniejsze różnice

Marketplace — gdy platforma tworzy własny ekosystem handlowy

Marketplace jest przede wszystkim środowiskiem, w którym wielu sprzedawców oferuje produkty w ramach jednej platformy organizującej proces handlowy. Operator takiego środowiska może odpowiadać za prezentację ofert, mechanizmy wyszukiwania i porównywania, płatności, obsługę klienta, reklamacje, dostawy lub inne elementy procesu, a jego wynagrodzenie często ma postać prowizji albo zestawu opłat związanych ze sprzedażą. Nie oznacza to jednak, że każdy marketplace staje się właścicielem sprzedawanych towarów albo wykazuje pełną wartość wszystkich transakcji jako własny przychód. W typowym modelu zewnętrzny merchant nadal może być stroną umowy z klientem i sprzedawcą towaru, natomiast operator najczęściej rozpoznaje wyłącznie własne wynagrodzenie za pośrednictwo i pozostałe świadczone usługi. Z tego powodu samo użycie słowa „marketplace” nie daje jeszcze odpowiedzi na pytanie, jak księgować sprzedaż. Dla rachunkowości nadal trzeba ustalić, czy sklep działa jako principal, czy jako agent, kto kontroluje towar przed przekazaniem go klientowi i kto ponosi główną odpowiedzialność za wykonanie zobowiązania. Kontrola nad towarem przed jego przekazaniem klientowi jest przy tym jednym z kluczowych kryteriów wykorzystywanych również przy ocenie, czy przychód powinien być prezentowany brutto czy netto.

Dodatkowa ostrożność jest potrzebna w VAT, ponieważ przepisy przewidują określone sytuacje, w których interfejs elektroniczny może zostać uznany za dostawcę dla celów podatkowych. Nie jest to jednak ogólna zasada odnosząca się do każdej platformy ani każdej transakcji przechodzącej przez aplikację. Sama funkcja pośredniczenia w znalezieniu produktu, prezentowania oferty albo prowadzenia klienta przez zakup nie wystarcza, aby automatycznie uznać operatora za podatnika dokonującego dostawy. Znaczenie ma konkretny model transakcji i spełnienie warunków przewidzianych w przepisach. Dla sklepu internetowego praktyczny wniosek jest więc taki, że klasyfikacja rozwiązania jako marketplace’u może być użyteczna biznesowo lub operacyjnie, ale nie powinna zastępować analizy prawnej, podatkowej i księgowej. W firmie prowadzącej sprzedaż wielokanałową marketplace najczęściej wymaga osobnej analityki przychodów, prowizji, zwrotów i kosztów kanału, jednak to nadal nie przesądza, że sposób rozpoznawania przychodu musi być inny niż w sprzedaży własnej.

Checkout — gdy zewnętrzny podmiot obsługuje techniczną część zakupu

Model checkoutu koncentruje się przede wszystkim na technicznej warstwie finalizacji zakupu. Zewnętrzny podmiot może dostarczać koszyk, formularz danych, obsługę płatności, wybór dostawy albo wspólny interfejs, przez który klient kończy transakcję. Z perspektywy użytkownika może to oznaczać, że ostatni etap zakupu odbywa się poza standardowym środowiskiem sklepu, ale samo to nie musi zmieniać tożsamości sprzedawcy. Sklep nadal może być stroną umowy z klientem, odpowiadać za towar, reklamacje i zwroty oraz wykazywać pełny przychód ze sprzedaży. Dostawca checkoutu świadczy wtedy usługę technologiczną, płatniczą lub operacyjną i otrzymuje wynagrodzenie za własny zakres świadczeń. To rozróżnienie jest szczególnie ważne w sytuacji, gdy operator potrąca swoje opłaty przed przekazaniem środków sprzedawcy. Sam fakt, że na rachunek sklepu trafia kwota pomniejszona o prowizję lub opłatę technologiczną, nie oznacza jeszcze, że przychodem sklepu jest wyłącznie ta kwota.

Dla księgowości kluczowe pozostaje więc rozdzielenie wartości sprzedaży od wynagrodzenia podmiotów obsługujących proces. Jeżeli sklep pozostaje principalem i sprzedaje towar we własnym imieniu, co do zasady rozpoznaje przychód w pełnej wartości sprzedaży, a koszty związane z checkoutem, płatnościami lub obsługą transakcji ujmuje oddzielnie. Zewnętrzna warstwa techniczna może istotnie zmienić przepływ danych i pieniędzy, ale nie musi zmieniać ekonomicznej treści samej sprzedaży. W praktyce sklep powinien ustalić, jakie dokumenty otrzymuje od operatora, czy opłata jest naliczana jako abonament, stałe fee, procent od transakcji czy kombinacja kilku elementów oraz czy mechanizm rozliczeń pozwala łatwo uzgodnić pełną wartość zamówień z kwotami faktycznie wypłaconymi. Dla rosnącego e-commerce ma to duże znaczenie, ponieważ błędne utożsamienie wypłaty netto z przychodem może zniekształcać wyniki i utrudniać porównywanie rentowności kanałów.

Kanał sprzedaży oparty o AI — gdzie znajduje się Von Halsky/InPost Buy?

Najbardziej użyteczne biznesowo jest dziś traktowanie Von Halsky/InPost Buy jako kanału sprzedaży wykorzystującego AI do odkrywania produktów i prowadzenia klienta przez zakup. Technicznie rozwiązanie łączy kilka funkcji, które mogą przypominać zarówno marketplace, jak i checkout. Użytkownik może znaleźć i porównać produkty w jednym środowisku, a następnie zostać przeprowadzony przez kolejne etapy prowadzące do finalizacji zamówienia, podczas gdy oferta wielu sklepów może być dostępna z poziomu tej samej aplikacji. Jednocześnie sklep nadal konfiguruje własną ofertę i uczestniczy w dalszej obsłudze zamówienia. Z tego powodu próba wtłoczenia rozwiązania w jedną tradycyjną kategorię może być mniej użyteczna niż analiza jego poszczególnych funkcji. Funkcjonalnie jest to kanał sprzedaży oparty o AI. Technicznie jest to zewnętrzna warstwa rekomendacji, obsługi ścieżki zakupowej i przekazywania zamówień. Księgowo i podatkowo znaczenie ma natomiast to, czy sprzedawcą wobec klienta pozostaje sklep i czy operator otrzymuje wynagrodzenie za świadczone usługi, zamiast samemu kupować i odsprzedawać towar.

Na podstawie obecnie opisywanego modelu bardziej prawdopodobne jest właśnie takie ujęcie, ale nie powinno ono być traktowane jako automatyczne i niezmienne. Ostateczna kwalifikacja zależy od regulaminu, umowy sprzedawcy, odpowiedzialności stron i rzeczywistego sposobu rozliczeń. Jeżeli sklep pozostaje stroną umowy z klientem, kontroluje towar przed jego przekazaniem, ponosi zasadnicze ryzyko związane ze sprzedażą i odpowiada za wykonanie zobowiązania, to sprzedaż co do zasady pozostaje jego sprzedażą, niezależnie od tego, czy klient znalazł produkt na stronie sklepu, w aplikacji, przez interfejs elektroniczny czy przy pomocy asystenta AI. Operator może jednocześnie pobierać prowizję, świadczyć usługi technologiczne, a w zależności od modelu uczestniczyć w obsłudze płatności, dostawy i zwrotów, ale każdy z tych elementów powinien być ujmowany zgodnie z jego rzeczywistym charakterem. Najważniejsze pytanie nie brzmi więc: „gdzie klient kliknął Kup?”, lecz: „kto był stroną umowy z klientem, kto kontrolował towar przed jego wydaniem i kto ponosił odpowiedzialność za wykonanie sprzedaży?”. To właśnie odpowiedzi na te pytania decydują o sposobie ujęcia transakcji w księgach rachunkowych.

Jak zakwalifikować sprzedaż z Von Halsky/InPost Buy w księgowości?

Przychód ze sprzedaży — co faktycznie księguje sklep?

Jeżeli z regulaminu, umowy oraz faktycznego przebiegu transakcji wynika, że to sklep pozostaje sprzedawcą wobec klienta, sprzedaż wygenerowaną przez Von Halsky/InPost Buy należy co do zasady ujmować tak samo jak pozostałą sprzedaż towarów lub usług prowadzoną przez przedsiębiorstwo. Sam fakt, że klient został pozyskany przez kanał wykorzystujący AI, nie tworzy nowej kategorii przychodu i nie zmienia automatycznie sposobu jego prezentacji. Jeżeli sklep działa jako principal, czyli przede wszystkim kontroluje towar przed jego przekazaniem klientowi oraz ponosi główną odpowiedzialność za wykonanie zobowiązania wobec nabywcy, przychodem jest co do zasady pełna wartość wynagrodzenia należnego od klienta, z uwzględnieniem zasad właściwych dla prezentacji przychodów w rachunkowości. Wynagrodzenie operatora kanału powinno natomiast zostać rozpoznane odrębnie, zgodnie z charakterem świadczonej usługi. Ma to szczególne znaczenie wtedy, gdy operator potrąca prowizję lub inne opłaty przed przekazaniem środków. Kwota, która ostatecznie wpływa na rachunek bankowy, może być niższa od wartości rozliczenia z klientem, ale samo potrącenie nie oznacza jeszcze, że przychodem sklepu jest wyłącznie otrzymana kwota netto.

W praktyce zamówienie pochodzące z Von Halsky/InPost Buy może więc trafić na te same podstawowe konta przychodowe co sprzedaż wygenerowana bezpośrednio przez sklep internetowy, o ile przyjęta polityka rachunkowości nie przewiduje odrębnej analityki dla poszczególnych kanałów sprzedaży. Różnica pojawia się przede wszystkim na poziomie analityki. Firma może oznaczyć źródło zamówienia jako osobny kanał i dzięki temu śledzić jego przychody, marżę, koszty prowizji, zwroty, koszty dostawy oraz pozostałe wskaźniki zarządcze bez tworzenia sztucznie nowego rodzaju przychodu. Dla średniego e-commerce przygotowującego się do ekspansji jest to zwykle bardziej użyteczne niż przebudowywanie podstawowej struktury planu kont za każdym razem, gdy pojawia się nowy sposób pozyskiwania klienta. Księgowo sprzedaż może pozostać sprzedażą własną, a operacyjnie i zarządczo funkcjonować jako odrębny kanał. Taki podział pozwala zachować spójność sprawozdawczości finansowej, a jednocześnie dostarcza danych potrzebnych do oceny, czy sprzedaż wspierana przez AI rzeczywiście poprawia wynik firmy.

Sam sposób pozyskania zamówienia nie wpływa również automatycznie na moment ujęcia przychodu. Przychód rozpoznaje się zgodnie z zasadami właściwymi dla danej transakcji, przyjętymi zasadami rachunkowości oraz obowiązującymi przepisami, a nie dlatego, że zamówienie pojawiło się w aplikacji wykorzystującej AI. Moment złożenia zamówienia, przekazania go do systemu sklepu, dokonania płatności i realizacji dostawy mogą być odrębnymi etapami procesu, dlatego nie należy utożsamiać samego pojawienia się zamówienia w nowym kanale z automatycznym powstaniem przychodu. Sposób jego ujęcia powinien wynikać z tych samych zasad, które przedsiębiorstwo stosuje wobec porównywalnych transakcji sprzedaży realizowanych innymi kanałami. AI zmienia sposób dotarcia do klienta i może zmienić przepływ danych między systemami, ale nie tworzy własnego, odrębnego momentu rozpoznania przychodu.

Warto przy tym zachować ostrożność wobec uproszczonego założenia, że każdy nowy kanał automatycznie powinien korzystać z identycznego schematu księgowego. Jeżeli model współpracy w przyszłości się zmieni, operator przejmie dodatkowe obowiązki albo inaczej zostanie ułożony podział odpowiedzialności wobec klienta, sposób ujęcia przychodu również może wymagać ponownej oceny. Dlatego przedsiębiorstwo powinno dokumentować nie tylko nazwę kanału, ale przede wszystkim przyjęte założenia dotyczące tego, kto jest stroną umowy, kto kontroluje towar przed jego wydaniem, kto odpowiada za realizację sprzedaży i jak rozliczane są opłaty. W obecnie opisywanym modelu co do zasady nie ma potrzeby tworzenia całkowicie odrębnej kategorii przychodów wyłącznie dlatego, że klient trafił do sklepu za pośrednictwem AI. Nowy kanał sprzedaży może wymagać osobnego raportowania i bardziej szczegółowej analityki, ale nie musi oznaczać nowego rodzaju przychodu w księgach.

Kto jest sprzedawcą i kto powinien wystawić dokument sprzedaży?

Najważniejszy test: kto realizuje transakcję wobec klienta?

Najważniejszym krokiem jest ustalenie, kto faktycznie występuje wobec klienta jako sprzedawca i kto ponosi zasadniczą odpowiedzialność za wykonanie transakcji. Nie wystarczy sprawdzić, kto prezentuje produkt w aplikacji albo kto dostarcza interfejs, przez który klient przechodzi do zakupu. Trzeba przeanalizować cały podział odpowiedzialności pomiędzy sklepem a operatorem. Znaczenie ma to, kto jest stroną umowy z kupującym, kto ustala ofertę i finalną cenę, kto może zaakceptować albo odrzucić zamówienie, kto ponosi ryzyko związane z zapasem i niesprzedanym towarem oraz kto odpowiada za zgodność produktu z umową, reklamacje i zwroty. Ważne jest również, kto organizuje faktyczną realizację zamówienia, kto odpowiada za przygotowanie i wydanie towaru oraz kto ponosi ekonomiczne skutki niewykonania lub nieprawidłowego wykonania sprzedaży. Dopiero łączna analiza tych elementów pozwala ocenić, czy sklep jest principalem, który powinien co do zasady wykazywać przychód w ujęciu brutto właściwym dla własnej sprzedaży, czy też jego rola jest bardziej zbliżona do pośrednika.

Osobnym, ale powiązanym obszarem jest odpowiedzialność za podatkowe udokumentowanie i zaewidencjonowanie sprzedaży. Nie należy sprowadzać tego wyłącznie do pytania, kto wystawia fakturę, ponieważ w sprzedaży B2C sposób dokumentowania zależy od rodzaju transakcji i obowiązujących przepisów. W zależności od sytuacji może chodzić o paragon fiskalny, fakturę wystawianą obowiązkowo lub na żądanie, dokument elektroniczny albo odpowiednie ujęcie sprzedaży w ewidencji, jeżeli spełnione są warunki stosowania określonego zwolnienia. Dlatego właściwe pytanie brzmi szerzej: kto odpowiada za prawidłowe ujęcie transakcji w wymaganych ewidencjach oraz za rozliczenie podatku należnego. Jeżeli obowiązki te pozostają po stronie sklepu i są spójne z jego rolą jako sprzedawcy, wzmacnia to wniosek, że sprzedaż powinna być ujmowana jako jego własny przychód, a operator kanału rozlicza odrębnie wynagrodzenie za świadczone usługi.

Dlaczego to ważniejsze niż nazwa kanału?

Określenia takie jak „strefa zakupowa”, „asystent AI”, „kanał sprzedaży”, „checkout” czy „marketplace” są użyteczne w komunikacji biznesowej, ale same w sobie nie rozstrzygają o sposobie księgowania ani opodatkowania transakcji. Jedno rozwiązanie może jednocześnie pełnić kilka funkcji: pomagać klientowi znaleźć produkt, porównywać oferty, prowadzić go przez ścieżkę zakupu, przekazywać dane zamówienia, obsługiwać określone elementy płatności i organizować dostawę. Z punktu widzenia użytkownika może to wyglądać jak jeden spójny ekosystem. Z punktu widzenia księgowości każdą rolę trzeba jednak rozłożyć na części i ustalić, kto za co odpowiada. Nazwa nadana usłudze nie przesądza, kto kontroluje towar przed przekazaniem klientowi, kto ponosi główne ryzyko związane ze sprzedażą ani czy operator otrzymuje wyłącznie prowizję za pośrednictwo, czy sam staje się stroną dostawy. Właśnie dlatego dwa rozwiązania nazywane tak samo mogą wymagać odmiennego ujęcia księgowego.

Dla przedsiębiorcy najbezpieczniejsze jest więc przyjęcie zasady, że klasyfikacja zaczyna się od umowy, ekonomicznej treści transakcji i praktycznego modelu współpracy, a dopiero później od etykiety używanej w materiałach sprzedażowych. W praktyce warto sprawdzić regulamin obowiązujący klienta, umowę z operatorem, sposób przepływu zamówień i płatności, zasady odpowiedzialności za reklamacje oraz to, kto ponosi ryzyko ekonomiczne związane z towarem. Istotne jest także to, czy operator pobiera wyłącznie wynagrodzenie za własne usługi, czy w jakimkolwiek momencie kupuje towar i odsprzedaje go klientowi. Odpowiedzi na te pytania są znacznie bardziej przydatne niż próba rozstrzygnięcia, czy Von Halsky/InPost Buy „jest” albo „nie jest” marketplace’em. Dla księgowości liczy się ekonomiczna rola każdej strony w transakcji, ponieważ to ona wpływa na sposób prezentacji przychodu, ujęcie kosztów, dokumentowanie sprzedaży i rozliczenie podatku.

VAT przy sprzedaży przez Von Halsky/InPost Buy

Czy pojawienie się AI zmienia sposób rozliczenia VAT?

Sama obecność AI w procesie zakupowym nie tworzy nowego rodzaju transakcji dla celów VAT i nie zmienia automatycznie tego, kto jest podatnikiem zobowiązanym do rozliczenia sprzedaży. Dla podatku od towarów i usług nadal liczy się przede wszystkim charakter konkretnej dostawy lub świadczenia, status nabywcy, miejsce rozpoczęcia i zakończenia transportu, lokalizacja towaru oraz rola poszczególnych podmiotów uczestniczących w transakcji. Jeżeli polski sklep sprzedaje własny towar polskiemu konsumentowi, a Von Halsky/InPost Buy pełni funkcję kanału pozyskania zamówienia i technologicznego interfejsu prowadzącego klienta przez proces zakupu, sama obecność tego rozwiązania nie powinna zmieniać podstawowej konstrukcji rozliczenia VAT. Podobnie jest przy sprzedaży B2B, gdzie nadal znaczenie mają zasady właściwe dla danej transakcji, w tym status kontrahenta i miejsce opodatkowania. AI może wpływać na sposób odkrycia produktu i ścieżkę zakupową, ale nie zastępuje analizy podatkowej właściwej dla sprzedaży krajowej, wewnątrzunijnej czy transgranicznej.

Większej uwagi wymaga sprzedaż do klientów z innych państw, ponieważ wtedy o sposobie rozliczenia nie decyduje kanał sprzedaży, lecz konfiguracja całej transakcji. Trzeba ustalić, skąd fizycznie wysyłany jest towar, dokąd trafia, czy nabywcą jest konsument czy przedsiębiorca, gdzie znajduje się magazyn oraz czy dana sprzedaż podlega zasadom właściwym dla wewnątrzwspólnotowej sprzedaży towarów na odległość i rozliczeniu przez OSS. Osobnej analizy mogą wymagać także przypadki związane z importem lub sprzedażą prowadzoną przez podmiot spoza Unii Europejskiej. W unijnych regulacjach istnieją sytuacje, w których interfejs elektroniczny może zostać uznany za dostawcę dla celów VAT, ale nie jest to ogólna zasada dotycząca każdej aplikacji, platformy czy systemu wykorzystującego AI. Dlatego dla średniego e-commerce planującego ekspansję kluczowe pytanie nie brzmi, czy zamówienie pochodzi z Von Halsky/InPost Buy, lecz jaki jest podatkowy charakter konkretnej sprzedaży i jaką rolę faktycznie pełni operator w danym modelu.

Kiedy sytuacja mogłaby wyglądać inaczej?

Obecna kwalifikacja nie powinna być traktowana jako rozwiązanie raz przyjęte i obowiązujące niezależnie od dalszego rozwoju usługi. Jeżeli zmienią się warunki świadczenia, regulamin, model rozliczeń albo zakres odpowiedzialności operatora wobec klienta, konieczna może być ponowna analiza zarówno sposobu prezentowania przychodu, jak i zasad VAT. Istotna zmiana mogłaby nastąpić na przykład wtedy, gdy operator zacząłby przejmować większą kontrolę nad warunkami transakcji, działać we własnym imieniu wobec klienta, występować jako strona umowy, nabywać i odsprzedawać towary albo wykonywać funkcje, które na gruncie konkretnych przepisów prowadziłyby do przypisania mu szczególnej roli podatkowej. Znaczenie może mieć również zmiana sposobu przepływu płatności, odpowiedzialności za zwroty, reklamacje i chargebacki czy zasad ustalania ceny. Sama rozbudowa technologii nie musi zmieniać kwalifikacji, ale zmiana ekonomicznej treści współpracy już może.

Ponownej oceny może wymagać także sytuacja, w której zmienią się przepisy określające rolę platform i interfejsów elektronicznych albo firma zacznie wykorzystywać kanał w nowych modelach sprzedaży, na przykład z magazynów położonych w kilku państwach. W praktyce oznacza to, że przedsiębiorstwo nie powinno ograniczać się do jednorazowego wdrożenia schematu księgowego. Warto regularnie porównywać konfigurację systemów, aktualny regulamin, umowę z operatorem i sposób rozliczeń z tym, co zostało przyjęte w polityce rachunkowości oraz procedurach podatkowych. Dzisiejsza kwalifikacja nie jest decyzją raz na zawsze. Model usługi, zakres odpowiedzialności stron i sposób prowadzenia sprzedaży mogą zmieniać się szybciej niż wewnętrzne procedury finansowe, dlatego każda istotna zmiana warunków współpracy powinna uruchamiać ponowną analizę.

Jak księgować opłaty, prowizje i logistykę?

Koszt logistyki

Jeżeli operator świadczy usługę dostawy lub organizuje transport towaru do klienta, koszt takiej usługi powinien być ujmowany zgodnie z ekonomiczną treścią świadczonej usługi oraz zasadami przyjętymi w polityce rachunkowości przedsiębiorstwa. W praktyce może to oznaczać zakwalifikowanie go do kosztów usług transportowych, logistycznych albo innych usług obcych, zależnie od struktury planu kont i sposobu raportowania. Znaczenie ma również to, czy koszt dostawy jest ponoszony bezpośrednio przez sklep, przenoszony na klienta, częściowo dotowany przez sprzedawcę czy uwzględniany w szerszym modelu rozliczeń z operatorem. Sama obecność usługi logistycznej w tym samym ekosystemie co kanał sprzedaży AI nie oznacza, że należy łączyć ją księgowo z prowizją lub kosztem technologii. Jeżeli dokumenty i dane rozliczeniowe pozwalają na rozdzielenie tych świadczeń, takie rozdzielenie zwykle poprawia przejrzystość kosztów i późniejszą analizę rentowności.

Dla e-commerce rozwijającego sprzedaż wielokanałową szczególnie ważne jest zachowanie spójności między księgowością finansową a analityką zarządczą. Koszt dostawy może być księgowany na jednym podstawowym koncie syntetycznym, a jednocześnie przypisywany analitycznie do konkretnego kanału, rynku, typu przesyłki lub grupy klientów. Dzięki temu firma może ocenić nie tylko łączny poziom kosztów logistycznych, ale również sprawdzić, czy zamówienia pozyskane przez Von Halsky/InPost Buy mają inną strukturę kosztową niż sprzedaż bezpośrednia. Wraz ze wzrostem skali takie rozróżnienie staje się ważniejsze, ponieważ nawet niewielka różnica w koszcie dostawy lub zwrotu może istotnie wpływać na marżę całego kanału.

Opłata za dostęp do kanału sprzedaży

Opłata za korzystanie z kanału sprzedaży powinna być ujmowana zgodnie z tym, za co przedsiębiorstwo faktycznie płaci. Jeżeli wynagrodzenie dotyczy dostępu do technologii, integracji, infrastruktury lub funkcji wspierających proces zakupowy, może mieć charakter kosztu usług IT albo innych usług obcych. Jeżeli płatność dotyczy ekspozycji produktów, promowania ofert lub zwiększania widoczności w określonym środowisku zakupowym, jej ekonomiczna treść może być bliższa kosztom marketingu i reklamy. Z kolei opłata powiązana z obsługą sprzedaży może zostać ujęta jako koszt kanału dystrybucji lub obsługi handlowej. Nie należy jednak wybierać kategorii dowolnie ani tylko na podstawie nazwy widocznej na fakturze. Właściwe ujęcie powinno wynikać z umowy, zakresu faktycznie wykonanej usługi, dokumentu księgowego, przyjętej polityki rachunkowości oraz sposobu, w jaki firma analizuje koszty swoich kanałów sprzedaży.

W praktyce jeden operator może świadczyć kilka różnych usług jednocześnie, dlatego warto sprawdzić, czy rozliczenie pozwala je od siebie oddzielić. Jeżeli operator wystawia jedną fakturę obejmującą kilka rodzajów świadczeń, należy zweryfikować, czy sam dokument, załączona specyfikacja albo raport rozliczeniowy pozwalają przypisać poszczególne elementy do odpowiednich kategorii kosztowych. Jeżeli takie rozdzielenie nie jest możliwe, przedsiębiorstwo powinno przyjąć spójny sposób klasyfikacji zgodny z przyjętą polityką rachunkowości i stosować go konsekwentnie w kolejnych okresach. Nie zawsze oznacza to konieczność tworzenia wielu nowych kont księgowych. Często wystarczy dobrze zaprojektowana analityka, która pokaże, jaka część kosztów dotyczy samego dostępu do kanału, jaka prowizji, a jaka logistyki lub dodatkowych usług. Dzięki temu zarząd może ocenić nie tylko całkowity koszt współpracy z operatorem, ale również zrozumieć, które elementy modelu najmocniej wpływają na marżę.

Prowizja od sprzedaży, jeśli pojawi się w modelu rozliczeń

Prowizja naliczana od wartości zamówień co do zasady stanowi koszt usługi świadczonej przez operatora kanału i powinna być ujmowana odrębnie od przychodu ze sprzedaży towaru, o ile sklep pozostaje principalem. Jej konkretna klasyfikacja zależy od ekonomicznego charakteru świadczenia. Może być traktowana jako koszt prowizji handlowej, koszt kanału sprzedaży albo inny koszt usług obcych, jeżeli taki sposób najlepiej odpowiada treści umowy i przyjętej polityce rachunkowości. Kluczowe jest to, że procentowy sposób naliczania opłaty nie zmienia sam w sobie roli operatora w transakcji. Prowizja może być powiązana z wartością sprzedaży, ale nadal pozostawać wynagrodzeniem za pośrednictwo, technologię, dostęp do kanału lub inny zakres usług. Dlatego sposób jej księgowania powinien wynikać z dokumentacji i praktycznego modelu współpracy, a nie wyłącznie z tego, że została obliczona jako określony procent od zamówienia.

Dla kontroli finansowej ważne jest także właściwe uzgodnienie prowizji z poszczególnymi zamówieniami i wypłatami. Jeżeli operator potrąca swoje wynagrodzenie przed przekazaniem środków do sklepu, system księgowy powinien umożliwiać odtworzenie pełnej wartości sprzedaży, wartości potrąconej prowizji oraz kwoty faktycznie wypłaconej. Bez takiego rozdzielenia firma może mieć problem z uzgodnieniem raportów sprzedażowych, rachunku bankowego i zapisów księgowych, a także z oceną rentowności kanału. Wraz ze wzrostem liczby transakcji drobne różnice pomiędzy raportem zamówień a raportem wypłat mogą przekształcić się w istotny problem operacyjny, dlatego schemat rozliczeń warto zaprojektować zanim wolumen sprzedaży znacząco wzrośnie.

Dlaczego nie należy automatycznie pomniejszać przychodu?

Najczęstsze uproszczenie polega na utożsamieniu kwoty wypłaconej przez operatora z przychodem sklepu. Jeżeli klient zapłacił określoną kwotę, a operator potrącił swoją prowizję i przekazał sprzedawcy niższą wartość, intuicyjnie można uznać, że przychodem jest tylko to, co wpłynęło na rachunek bankowy. Przy modelu principal takie podejście może jednak prowadzić do nieprawidłowej prezentacji transakcji. Jeżeli to sklep sprzedał towar klientowi, co do zasady powinien wykazać przychód odpowiadający należnemu mu wynagrodzeniu z tytułu sprzedaży, z uwzględnieniem zasad właściwych dla rachunkowości i bez utożsamiania tej wartości z kwotą VAT należnego. Wynagrodzenie operatora jest natomiast odrębnym kosztem usługi. Potrącenie prowizji jest więc sposobem rozliczenia pieniężnego, a nie automatycznie podstawą do prezentowania przychodu w wartości pomniejszonej o koszt operatora.

Rozdzielenie tych dwóch wartości ma także duże znaczenie dla zarządzania firmą. Jeżeli przedsiębiorstwo zacznie księgować jako przychód wyłącznie kwotę po potrąceniu prowizji, może sztucznie obniżyć raportowaną skalę sprzedaży i utrudnić porównywanie wyników pomiędzy kanałami. Jednocześnie koszt operatora stanie się mniej widoczny, przez co zarząd może nie zauważyć, jak szybko rośnie koszt pozyskania i obsługi zamówień. Prawidłowy podział na przychód ze sprzedaży oraz osobno wykazany koszt prowizji, technologii, płatności czy logistyki pozwala znacznie lepiej ocenić marżę i efektywność kanału. Przepływ pieniędzy nie jest tym samym co ekonomiczna treść transakcji. To, ile środków wpłynęło po potrąceniach, nie przesądza jeszcze o tym, jaka kwota powinna zostać ujęta jako przychód, a jaka jako koszt usługi operatora.

W praktyce przedsiębiorstwo powinno mieć możliwość uzgodnienia czterech wartości: wartości zamówień, wartości sprzedaży ujętej w księgach, kosztów operatora oraz kwot faktycznie otrzymanych na rachunek bankowy. Nie wymaga to koniecznie rozbudowanego modelu księgowego, ale wymaga spójnych identyfikatorów transakcji, czytelnych raportów i możliwości powiązania danych sprzedażowych z rozliczeniami operatora oraz wyciągiem bankowym. Jeżeli system pozwala przeprowadzić takie uzgodnienie w sposób powtarzalny, późniejsze zamknięcia miesiąca, analiza rentowności kanału, wyjaśnianie różnic oraz ewentualna kontrola podatkowa stają się znacznie prostsze.

Tabela: Von Halsky/InPost Buy — jak ująć poszczególne elementy?

Poniższe zestawienie pokazuje podstawową logikę ujęcia poszczególnych elementów związanych ze sprzedażą przez Von Halsky/InPost Buy. Nie zastępuje ono analizy umowy, dokumentów rozliczeniowych ani przyjętej polityki rachunkowości, ale pomaga oddzielić samą sprzedaż od kosztów usług świadczonych przez operatora. Najważniejsze jest zachowanie rozróżnienia pomiędzy wartością sprzedaży realizowanej przez sklep, podatkiem należnym, źródłem pozyskania zamówienia oraz kosztami związanymi z obsługą kanału, płatnościami, logistyką i prowizjami. W praktyce jedno zamówienie może więc generować kilka różnych zapisów księgowych i analitycznych, mimo że z perspektywy klienta cały proces wygląda jak jedna spójna transakcja.

Zamówienie pozyskane przez kanał AI Klient kupuje produkt oferowany przez sklep, jeżeli to sklep pozostaje stroną sprzedaży Przychód ze sprzedaży towarów lub usług, ujmowany zgodnie z zasadami właściwymi dla danej transakcji, co do zasady w wartości netto, bez VAT należnego
Źródło zamówienia Sprzedaż pochodzi z dodatkowego kanału pozyskania klienta Odrębne oznaczenie analityczne, kod kanału, tag lub wymiar raportowy
Dostawa Operator świadczy lub organizuje usługę dostawy, zależnie od modelu współpracy Koszt usług transportowych, logistycznych albo innych usług obcych, zgodnie z ekonomiczną treścią świadczenia i przyjętą polityką rachunkowości
Opłata za kanał Sklep korzysta z technologii, integracji, promocji lub obsługi procesu sprzedaży Koszt usług IT, marketingowych, obsługi sprzedaży albo innych usług obcych, zależnie od faktycznego zakresu świadczenia
Prowizja Operator pobiera wynagrodzenie zależne od wartości sprzedaży lub zamówienia Co do zasady odrębny koszt usługi operatora, ujmowany zgodnie z umową, dokumentacją i ekonomiczną treścią świadczenia
VAT od sprzedaży Sklep pozostaje podatnikiem dokonującym sprzedaży, jeżeli wynika to z modelu transakcji Rozliczenie według zasad właściwych dla sprzedaży krajowej lub transgranicznej, z uwzględnieniem m.in. statusu nabywcy, miejsca dostawy, miejsca rozpoczęcia i zakończenia transportu, a w odpowiednich przypadkach także zasad WDT, WSTO i OSS
Wypłata środków Operator przekazuje kwotę po potrąceniach, korektach lub zwrotach Uzgodnienie pełnej wartości sprzedaży, VAT należnego, kosztów operatora, zwrotów, korekt i kwoty faktycznie otrzymanej

Tabela pokazuje również, dlaczego nie warto sprowadzać całego modelu do jednego pytania o to, na jakie konto zaksięgować „sprzedaż z AI”. W praktyce sklep nadal może rozpoznawać przychód według tych samych zasad co w innych kanałach, ale jednocześnie potrzebować dokładniejszej analityki kosztów, prowizji i źródła zamówienia. Jeżeli operator potrąca swoje wynagrodzenie przed wypłatą środków, system powinien pozwalać uzgodnić pełną wartość sprzedaży, VAT należny, koszty operatora, zwroty, chargebacki, korekty prowizji, refundacje kosztów dostawy oraz kwotę faktycznie otrzymaną na rachunek. W zależności od modelu rozliczeń znaczenie mogą mieć również środki czasowo zatrzymywane przez operatora lub inne pozycje przejściowe. Dzięki temu księgowość nie opiera się wyłącznie na przepływie pieniędzy, a controlling może ocenić ekonomiczną rentowność kanału na podstawie danych, które dają się ze sobą spójnie połączyć.

Warto również pamiętać, że opłata za dostawę pobrana od klienta i koszt usługi przewoźnika to dwa odrębne elementy transakcji. Sam fakt, że jedna kwota ekonomicznie „pokrywa” drugą, nie oznacza automatycznie, że powinny być ze sobą kompensowane w księgach. Sposób prezentacji zależy od modelu sprzedaży, przyjętych zasad rachunkowości i roli sklepu w transakcji. Dla analityki zarządczej można oczywiście zestawiać przychody związane z dostawą z kosztami logistycznymi, aby oceniać ich wpływ na marżę, ale nie powinno to zacierać odrębności przychodów, podatków i kosztów w ewidencji finansowej.

Osobny kanał w analityce — tak. Nowe konta syntetyczne — niekoniecznie

Jak oznaczyć Von Halsky/InPost Buy w systemie?

Najpraktyczniejszym podejściem jest potraktowanie Von Halsky/InPost Buy jako odrębnego źródła zamówień na poziomie analitycznym, bez automatycznego tworzenia zupełnie nowej logiki księgowania sprzedaży. W systemie sprzedażowym, ERP lub narzędziu integrującym zamówienia można wprowadzić osobny kod kanału, etykietę albo pole źródłowe, które pozwoli odróżnić sprzedaż bezpośrednią od zamówień pozyskanych przez zewnętrzne platformy, Von Halsky/InPost Buy i pozostałe źródła. Kluczowe jest nie tyle samo nazewnictwo, ile konsekwencja. Każde zamówienie powinno zachować informację o swoim pochodzeniu również po przejściu do kolejnych etapów procesu, takich jak wystawienie dokumentu sprzedaży, rozliczenie płatności, korekta, zwrot czy analiza marży. Jeżeli identyfikator kanału ginie po imporcie zamówienia do systemu finansowo-księgowego, późniejsze raportowanie szybko staje się ręczne i podatne na błędy.

W dobrze zaprojektowanym procesie identyfikator kanału powinien przechodzić również do korekt i zwrotów, raportów płatniczych, raportów prowizyjnych, dokumentów magazynowych oraz, o ile system na to pozwala, do raportów VAT i danych wykorzystywanych w księdze głównej. Bez tego pierwotna sprzedaż może zostać poprawnie przypisana do Von Halsky/InPost Buy, ale jej późniejsza korekta już nie, co zniekształci przychód, marżę, wskaźnik zwrotów i ocenę rentowności kanału. Wraz ze wzrostem skali problem staje się szczególnie widoczny, ponieważ brak ciągłości identyfikatora utrudnia później uzgodnienie raportów operacyjnych z księgowością i rozliczeniami pieniężnymi. Dla średniego e-commerce lepiej więc od początku zaprojektować jedno spójne oznaczenie, które pozostaje z transakcją przez cały jej cykl życia.

W firmie planującej dalszą ekspansję warto projektować taką strukturę z myślą o kolejnych kanałach, a nie tylko o jednym konkretnym wdrożeniu. Dobrze zaprojektowany model danych powinien pozwalać dodawać nowe źródła sprzedaży bez przebudowy całego planu kont i bez tworzenia osobnych procesów księgowych dla każdego nowego interfejsu. Von Halsky/InPost Buy może więc funkcjonować jako osobna wartość w polu „kanał sprzedaży”, podobnie jak sklep internetowy, sprzedaż przez zewnętrzne platformy czy inne źródła. Pozwala to zachować wspólną logikę rachunkową, a jednocześnie analizować wyniki każdego kanału osobno. Dla zarządu ważne jest bowiem nie tylko to, ile firma sprzedała łącznie, ale także skąd przyszły zamówienia, ile kosztowała ich obsługa i czy poszczególne kanały rozwijają się w sposób rentowny.

Co warto rozdzielić analitycznie?

Odrębna analityka powinna przede wszystkim pozwalać odpowiedzieć na pytanie, czy kanał faktycznie tworzy wartość dla firmy. W tym celu warto śledzić liczbę zamówień, przychód, średnią wartość koszyka, zwroty, koszty obsługi kanału, koszty dostawy, prowizje, marżę oraz końcową rentowność. W zakresie, w jakim dane są dostępne i można je wiarygodnie przypisać do kanału, można również analizować konwersję, koszt pozyskania klienta, udział nowych i powracających kupujących czy poziom reklamacji. Nie każdy wskaźnik będzie jednak równie łatwy do policzenia. Przykładowo klasyczny CAC może być trudniejszy do ustalenia, jeżeli sklep nie ponosi bezpośredniego kosztu pozyskania użytkownika, ale płaci prowizję dopiero od zrealizowanej transakcji. W takim przypadku większe znaczenie może mieć koszt kanału w relacji do sprzedaży, marży lub liczby zamówień niż próba sztucznego dopasowania wszystkich danych do jednego standardowego wskaźnika.

Nie chodzi przy tym o to, aby każda analizowana wartość trafiała na osobne konto księgowe. Znacznie ważniejsze jest, aby dane można było połączyć na poziomie zamówienia, kanału albo okresu i dzięki temu ocenić pełny ekonomiczny efekt sprzedaży. Kanał, który generuje szybko rosnący przychód, niekoniecznie musi być najbardziej rentowny, jeżeli jednocześnie wiąże się z wyższą prowizją, droższą logistyką lub większym poziomem zwrotów. Dla controllingu szczególnie istotne jest więc oddzielenie wskaźników sprzedażowych od wyniku po kosztach. Sam przychód z Von Halsky/InPost Buy może wyglądać atrakcyjnie, ale dopiero po uwzględnieniu prowizji, kosztów obsługi, płatności, logistyki, zwrotów i innych obciążeń można ocenić realny wkład kanału w wynik przedsiębiorstwa.

Niezależnie od zakresu analityki dane raportowe powinny dać się uzgodnić z księgą główną, ewidencją VAT, raportami sprzedażowymi oraz rozliczeniami pieniężnymi. Kanał może być szczegółowo analizowany zarządczo, ale suma danych analitycznych powinna pozostawać zgodna z wartościami ujętymi w księgach. Jest to szczególnie ważne wtedy, gdy dane do raportowania pochodzą z kilku systemów, na przykład platformy sprzedażowej, systemu ERP, operatora płatności i systemu księgowego. Im bardziej rozbudowana analityka, tym większe znaczenie ma jednoznaczne ustalenie źródła danych i zasad uzgadniania różnic. Rozbudowany dashboard nie zastępuje spójnej ewidencji; powinien być jej rozwinięciem.

Co może pozostać wspólne?

Podstawowe konta syntetyczne dotyczące sprzedaży towarów lub usług mogą co do zasady pozostać wspólne dla różnych kanałów, o ile przyjęta polityka rachunkowości nie przewiduje innego rozwiązania. Jeżeli ekonomiczna treść sprzedaży jest taka sama, a sklep pozostaje sprzedawcą, nie ma automatycznej potrzeby tworzenia nowego konta przychodowego tylko dlatego, że zamówienie zostało pozyskane przez Von Halsky/InPost Buy. Rozdzielenie może odbywać się na poziomie kont analitycznych, centrów odpowiedzialności, wymiarów raportowych, tagów lub danych przechowywanych w systemie sprzedażowym. Taki model pozwala zachować przejrzystość księgi głównej, a jednocześnie dostarcza informacji potrzebnych do zarządzania poszczególnymi kanałami. Im więcej źródeł sprzedaży posiada firma, tym ważniejsze staje się unikanie niekontrolowanego rozbudowywania planu kont o kolejne pozycje tworzone wyłącznie na potrzeby pojedynczych integracji.

W praktyce nowy kanał oparty o AI jest więc przede wszystkim wyzwaniem dla jakości danych, integracji i controllingu, a niekoniecznie dla samej konstrukcji księgowości finansowej. Firma musi wiedzieć, skąd pochodzi zamówienie, jakie koszty zostały z nim powiązane i czy wszystkie wartości można później uzgodnić z zapisami w księgach, ewidencją VAT oraz przepływami pieniężnymi. Nie oznacza to jednak, że każdy nowy sposób sprzedaży wymaga przebudowy całego planu kont. Znacznie częściej wystarczy zachować wspólne zasady ujmowania przychodów i kosztów, a różnice pomiędzy kanałami pokazać w dobrze zaprojektowanej analityce. Nowy kanał AI może wymagać nowego wymiaru raportowania, ale nie musi wymagać nowych kont syntetycznych.

Jak opisać Von Halsky/InPost Buy w polityce rachunkowości i instrukcji księgowej?

Proponowana kwalifikacja

W polityce rachunkowości warto opisać przede wszystkim ogólne zasady ujmowania sprzedaży i kosztów związanych z zewnętrznymi kanałami pozyskiwania oraz obsługi zamówień, natomiast szczegółowy sposób oznaczania i rozliczania Von Halsky/InPost Buy lepiej uregulować w instrukcji księgowej albo procedurze operacyjnej. Polityka rachunkowości powinna obejmować kwestie istotne z punktu widzenia prowadzenia ksiąg i sporządzania sprawozdań finansowych, takie jak sposób prezentacji przychodu, zasady ujmowania prowizji i innych kosztów operatora czy wykorzystanie kont syntetycznych i analitycznych. Instrukcja księgowa jest natomiast właściwszym miejscem na opis kodu kanału, obiegu raportów, sposobu importu zamówień, uzgadniania wypłat, przypisywania zwrotów i korekt oraz odpowiedzialności konkretnych osób za poszczególne etapy procesu. Takie rozdzielenie pozwala uniknąć sytuacji, w której polityka rachunkowości staje się zbiorem szczegółów technicznych wymagających aktualizacji przy każdej zmianie integracji lub modelu operacyjnego.

Z tego samego powodu nie warto nadmiernie uzależniać samej polityki rachunkowości od jednej nazwy handlowej. Zamiast wpisywać wyłącznie Von Halsky/InPost Buy, bardziej trwałe może być posługiwanie się kategorią taką jak zewnętrzne kanały pozyskiwania i obsługi zamówień, w których jednostka pozostaje sprzedawcą wobec klienta. W instrukcji księgowej lub załączniku można następnie wskazać, że do tej kategorii, według aktualnego stanu, zalicza się także Von Halsky/InPost Buy. Dzięki temu zmiana nazwy usługi, sposobu jej komunikowania albo dodanie kolejnego kanału nie wymaga automatycznie przebudowy podstawowego dokumentu opisującego zasady rachunkowości. Sama kwalifikacja powinna przy tym opierać się nie na marketingowej nazwie kanału, lecz na tym, czy z umowy i faktycznego przebiegu transakcji wynika, że jednostka kontroluje towar przed jego przekazaniem klientowi i ponosi główną odpowiedzialność za wykonanie sprzedaży.

Co warto opisać w polityce rachunkowości?

W polityce rachunkowości warto określić ogólną zasadę, według której sprzedaż realizowana z wykorzystaniem zewnętrznych kanałów jest ujmowana jako sprzedaż jednostki, jeżeli to przedsiębiorstwo pozostaje stroną umowy z klientem, kontroluje towar przed jego przekazaniem oraz ponosi główną odpowiedzialność za wykonanie zobowiązania wobec nabywcy. Dokument powinien również wskazywać, że przychód ujmuje się zgodnie z zasadami właściwymi dla danego rodzaju sprzedaży, niezależnie od tego, czy operator przekazuje całą należność, czy potrąca wcześniej prowizje i inne opłaty. Osobno warto określić zasadę ujmowania wynagrodzenia operatora, tak aby prowizje, opłaty technologiczne, płatnicze, logistyczne i inne świadczenia były prezentowane zgodnie z ich ekonomiczną treścią, a nie automatycznie kompensowane z przychodem ze sprzedaży.

W tym dokumencie można także wskazać, że poszczególne kanały sprzedaży są identyfikowane w ewidencji analitycznej, bez konieczności tworzenia nowych kont syntetycznych dla każdego nowego źródła zamówień. Nie ma natomiast potrzeby wpisywania do polityki pełnej listy zdarzeń operacyjnych, które powinny uruchamiać ponowną analizę modelu. Wystarczy zasada, że klasyfikacja podlega ponownej ocenie w przypadku istotnej zmiany warunków umownych, zakresu odpowiedzialności stron lub sposobu rozliczeń. Szczegółowe przypadki, takie jak zmiana regulaminu, struktury prowizji, przepływu pieniędzy czy rozpoczęcie sprzedaży z nowych krajów i magazynów, lepiej opisać w procedurze księgowej lub kontrolnej.

Przykładowy zapis może brzmieć następująco:

„Sprzedaż realizowana z wykorzystaniem zewnętrznych kanałów pozyskiwania i obsługi zamówień, w tym kanałów wykorzystujących rozwiązania sztucznej inteligencji, ujmowana jest jako sprzedaż jednostki, jeżeli z warunków umownych oraz faktycznego przebiegu transakcji wynika, że jednostka pozostaje stroną umowy z klientem, kontroluje towar przed jego przekazaniem oraz ponosi główną odpowiedzialność za wykonanie sprzedaży. Przychód ujmuje się zgodnie z zasadami właściwymi dla danego rodzaju sprzedaży, niezależnie od sposobu przekazania płatności przez operatora kanału. Prowizje, opłaty technologiczne, płatnicze, logistyczne i inne wynagrodzenia operatora ujmuje się odrębnie, zgodnie z ekonomiczną treścią świadczeń. Poszczególne kanały identyfikowane są w ewidencji analitycznej. Klasyfikacja modelu podlega ponownej ocenie w przypadku istotnej zmiany warunków umownych, odpowiedzialności stron lub sposobu rozliczeń.”

Co warto opisać w instrukcji księgowej lub procedurze operacyjnej?

Instrukcja księgowa powinna przełożyć ogólne zasady na konkretny proces. To tutaj warto wskazać, jaki kod otrzymują zamówienia z Von Halsky/InPost Buy, jak dane są importowane do systemu, skąd pobierane są raporty, jak przypisywane są prowizje, koszty dostawy, zwroty i korekty oraz w jaki sposób uzgadnia się rozliczenia operatora z księgą główną, ewidencją VAT i rachunkiem bankowym. Dokument powinien również określać, kto odpowiada za sprawdzenie kompletności raportów, kto wyjaśnia różnice pomiędzy sprzedażą a wypłatami i kto monitoruje zmiany w modelu współpracy. Przy większej skali warto opisać także kontrole wykonywane przy zamknięciu miesiąca, tak aby uzgadnianie kanału nie zależało wyłącznie od wiedzy jednej osoby.

W procedurze można też wskazać konkretne zdarzenia uruchamiające ponowną analizę. Może to być zmiana regulaminu, nowa struktura opłat, zmiana kraju podmiotu wystawiającego fakturę, rozszerzenie zakresu odpowiedzialności operatora, nowy sposób obsługi płatności, rozpoczęcie sprzedaży z zagranicznego magazynu albo zmiana procesu reklamacji i zwrotów. Dzięki temu firma nie musi każdorazowo przebudowywać polityki rachunkowości, ale nadal posiada mechanizm pozwalający wychwycić moment, w którym dotychczasowy sposób ujęcia przestaje odpowiadać ekonomicznej treści współpracy.

Czy Twój sklep jest gotowy księgowo i operacyjnie na Von Halsky/InPost Buy?

To rozwiązanie może wymagać szczególnej uwagi, jeśli…

Von Halsky/InPost Buy może być interesującym dodatkowym źródłem zamówień, ale im bardziej rozbudowany jest obecny model operacyjny firmy, tym większego znaczenia nabiera przygotowanie procesów finansowych i danych. Jeżeli prowadzisz sprzedaż wielokanałową, korzystasz z automatycznego importu zamówień, obsługujesz kilka metod płatności i masz już wiele źródeł sprzedaży, nowy kanał nie powinien być traktowany wyłącznie jako kolejna integracja techniczna. Każde nowe źródło zamówień dokłada kolejną warstwę raportów, korekt, zwrotów, prowizji i wypłat, które trzeba później poprawnie połączyć. Jeżeli identyfikator kanału nie przechodzi przez cały cykl życia transakcji albo nie da się uzgodnić rozliczenia operatora z zamówieniami i księgami, problemy mogą pozostać niewidoczne przy małym wolumenie, ale szybko ujawnią się wraz ze wzrostem skali.

Szczególnej uwagi wymaga sprzedaż zagraniczna. Jeżeli sklep sprzedaje do kilku państw, korzysta z różnych magazynów albo rozlicza transakcje wymagające precyzyjnego przypisania kraju, statusu nabywcy i modelu VAT, nowe źródło zamówień musi dostarczać dane pozwalające na prawidłową kwalifikację sprzedaży. Samo korzystanie z OSS nie rozwiązuje wszystkich problemów związanych z ekspansją. Jeżeli kanał będzie obsługiwał sprzedaż z magazynów położonych w innych państwach, trzeba odrębnie ocenić obowiązek lokalnej rejestracji VAT, ponieważ OSS nie obejmuje wszystkich zdarzeń związanych z przemieszczaniem i magazynowaniem towarów. Równie ważne jest ustalenie, kto świadczy poszczególne usługi na rzecz sklepu i z jakiego kraju wystawia fakturę, ponieważ zakup usług od podmiotu zagranicznego może rodzić odrębne konsekwencje w VAT, w tym konieczność rozliczenia importu usług.

Zadaj sobie te pytania przed uruchomieniem kanału

Przed wdrożeniem warto sprawdzić, czy firma potrafi odpowiedzieć na kilka podstawowych pytań:

Czy mój system potrafi jednoznacznie oznaczyć źródło zamówienia i zachować tę informację również przy zwrotach, korektach i rozliczeniach?
Czy wiem, kto w tym modelu odpowiada za podatkowe udokumentowanie i zaewidencjonowanie sprzedaży?
Czy wiem, w jaki sposób będą dokumentowane prowizje, opłaty technologiczne, płatnicze i inne koszty operatora?
Czy wiem, kto jest dostawcą poszczególnych usług i z jakiego kraju będzie wystawiana faktura?
Czy potrafię oddzielić koszt obsługi kanału od kosztów dostawy, zwrotów i pozostałej logistyki?
Czy moje raporty pokażą nie tylko przychód, lecz także marżę i rzeczywistą rentowność kanału?
Czy sprzedaż zagraniczna zostanie poprawnie rozpoznana pod względem kraju, statusu nabywcy, miejsca magazynowania i właściwego modelu VAT?
Czy potrafię uzgodnić każde rozliczenie operatora z zamówieniami, korektami, zwrotami, VAT i kwotą wpływającą na rachunek?
Czy w firmie jest wskazana osoba lub funkcja odpowiedzialna za monitorowanie zmian regulaminu, umowy i sposobu rozliczeń?

Jeżeli na kilka z tych pytań odpowiedź brzmi „nie wiem”, nie musi to oznaczać, że kanał jest dla firmy niewłaściwy. Pokazuje raczej, że przed jego skalowaniem trzeba uporządkować architekturę danych, przepływ dokumentów i sposób uzgadniania transakcji. W praktyce problemem rzadko jest samo AI. Znacznie częściej problem zaczyna się wtedy, gdy zamówienia trafiają do systemu szybciej, niż firma potrafi poprawnie przypisać im źródło, podatki, koszty i płatności. Przy małej skali takie braki można jeszcze uzupełniać ręcznie. Przy kilku tysiącach transakcji miesięcznie zaczynają generować trwałe różnice, błędne raporty i coraz większy koszt zamknięcia miesiąca.

Dla średniego e-commerce przygotowującego się do ekspansji właściwe pytanie nie powinno więc brzmieć wyłącznie: „czy warto uruchomić Von Halsky/InPost Buy?”. Równie ważne jest pytanie, czy firma potrafi obsłużyć kolejny kanał bez utraty kontroli nad danymi finansowymi. Jeżeli system pozwala oznaczyć źródło zamówienia, połączyć sprzedaż z kosztami operatora, prawidłowo rozpoznać transakcje zagraniczne i uzgodnić dane z księgą główną, ewidencją VAT oraz przepływami pieniężnymi, nowy kanał można rozwijać bez tworzenia odrębnego świata księgowego. Jeżeli tych mechanizmów brakuje, wdrożenie Von Halsky/InPost Buy może jedynie ujawnić problemy, które wcześniej istniały już w sprzedaży wielokanałowej. Brak odpowiedzi na podstawowe pytania o dane i rozliczenia jest sygnałem, że firma potrzebuje lepszej architektury finansowej, a niekoniecznie rezygnacji z nowego kanału.

Co się stanie, jeśli źle zakwalifikujesz ten kanał?

Możesz zacząć raportować przychód w niewłaściwy sposób

Pierwsze ryzyko pojawia się wtedy, gdy firma nie rozdziela wartości sprzedaży od kosztów związanych z obsługą kanału. Jeżeli operator potrąca prowizję, opłatę technologiczną, koszt obsługi płatności albo inne należności przed przekazaniem środków do sklepu, łatwo zacząć traktować kwotę wpływającą na rachunek jako przychód. Jeżeli jednak sklep działa jako principal — a więc w ujęciu ekonomicznym jest głównym wykonawcą świadczenia wobec klienta i przede wszystkim kontroluje towar przed jego przekazaniem — powinien co do zasady prezentować sprzedaż odrębnie od wynagrodzenia operatora. Przychód ze sprzedaży, z wyłączeniem VAT należnego, prowizja operatora, koszt logistyki i pozostałe opłaty mają odmienną ekonomiczną treść i nie powinny być łączone tylko dlatego, że występują w ramach jednego zamówienia. W przeciwnym razie firma może nie tylko zniekształcić obraz skali sprzedaży i kosztów kanału, lecz także niewłaściwie ująć samą transakcję w księgach.

Problem staje się jeszcze większy, gdy różne kanały są rozliczane według niespójnych zasad. Sprzedaż bezpośrednia może być raportowana według pełnej wartości wynagrodzenia należnego z tytułu sprzedaży, z wyłączeniem VAT należnego, podczas gdy sprzedaż z nowego kanału trafia do raportów dopiero po potrąceniu prowizji i innych opłat. Wtedy porównanie przychodów, marży i rentowności przestaje być miarodajne, a w modelu, w którym sklep powinien prezentować sprzedaż i koszty operatora odrębnie, nieprawidłowość może dotyczyć również samych zapisów księgowych i sprawozdawczości finansowej. Zarząd zaczyna podejmować decyzje na podstawie danych, które nie są porównywalne, a controlling musi później ręcznie odtwarzać ekonomiczną treść transakcji. Przy większej skali różnice mogą dotyczyć już nie pojedynczych zamówień, lecz całych miesięcy sprzedaży, dlatego właściwe rozdzielenie przychodu, VAT i kosztów operatora powinno zostać zaprojektowane przed uruchomieniem większego wolumenu.

Możesz stracić kontrolę nad VAT

Błędna klasyfikacja kanału może również prowadzić do problemów z VAT, zwłaszcza wtedy, gdy sklep sprzedaje równolegle do klientów z kilku państw i korzysta z różnych źródeł zamówień. Sam fakt, że sprzedaż została pozyskana przez Von Halsky/InPost Buy, nie odpowiada jeszcze na pytanie, gdzie transakcja podlega opodatkowaniu i jakie obowiązki ma sprzedawca. Trzeba nadal prawidłowo ustalić status nabywcy, miejsce rozpoczęcia i zakończenia transportu, lokalizację magazynu oraz model konkretnej sprzedaży. Jeżeli te dane nie przechodzą poprawnie z zamówienia do systemu finansowego i podatkowego, transakcja może zostać przypisana do niewłaściwego kraju albo rozliczona według nieodpowiednich zasad. Przy sprzedaży krajowej błąd może dotyczyć stawki VAT, momentu powstania obowiązku podatkowego, fiskalizacji, dokumentowania lub ujęcia w ewidencji. Przy ekspansji zagranicznej dochodzą zasady dotyczące odpowiednio WDT w transakcjach B2B, WSTO i OSS w sprzedaży B2C oraz obowiązki wynikające z lokalizacji zagranicznych magazynów.

Największym zagrożeniem jest brak jednej spójnej logiki pomiędzy kanałami. Sklep może prawidłowo rozliczać sprzedaż z własnej strony, ale inaczej klasyfikować zamówienia pochodzące z zewnętrznego interfejsu tylko dlatego, że proces zakupowy wygląda inaczej z perspektywy klienta. Tymczasem VAT nie powinien być ustalany na podstawie wyglądu ścieżki zakupowej, lecz według zasad właściwych dla konkretnej dostawy. Jeżeli firma nie potrafi jednoznacznie połączyć zamówienia z krajem wysyłki, krajem nabywcy, statusem klienta, lokalizacją magazynu i sposobem realizacji, ryzyko rośnie wraz z każdym kolejnym rynkiem. Samo korzystanie z OSS nie rozwiązuje wszystkich obowiązków, zwłaszcza gdy towary są magazynowane lub przemieszczane pomiędzy państwami. Problemy mogą ujawnić się dopiero przy uzgadnianiu deklaracji, analizie obowiązków rejestracyjnych albo podczas kontroli, kiedy trzeba odtworzyć, dlaczego konkretna sprzedaż została rozliczona w określony sposób.

Możesz nie wiedzieć, czy nowy kanał w ogóle zarabia

Rosnąca sprzedaż nie zawsze oznacza rosnący wynik. Kanał może generować coraz więcej zamówień, a jednocześnie podnosić koszt pozyskania sprzedaży, zwiększać poziom prowizji, powodować wyższe koszty dostawy albo przyciągać klientów o większej skłonności do zwrotów. Jeżeli firma śledzi wyłącznie przychód, może uznać wdrożenie za sukces, mimo że po uwzględnieniu wszystkich kosztów marża jest wyraźnie niższa niż w innych kanałach. Bez osobnej analityki trudno ocenić, czy dodatkowa sprzedaż rzeczywiście poprawia wynik, czy jedynie zwiększa obrót i obciążenie operacyjne. W przypadku szybko rosnącego e-commerce taka różnica ma duże znaczenie, ponieważ kanał o wysokim wolumenie może pochłaniać coraz więcej pracy magazynu, obsługi klienta i finansów, choć jego wkład w zysk pozostaje ograniczony.

Dlatego sprzedaż z Von Halsky/InPost Buy warto analizować nie tylko przez pryzmat liczby zamówień i wartości przychodów, lecz także kosztów operatora, logistyki, zwrotów, płatności i innych obciążeń możliwych do wiarygodnego przypisania do kanału. Dobrze zaprojektowana analityka pozwala porównać wynik z innymi źródłami sprzedaży na tych samych zasadach. Bez niej nowy kanał może przez wiele miesięcy wyglądać atrakcyjnie w raportach wzrostu, podczas gdy jego rentowność systematycznie spada. To szczególnie niebezpieczne wtedy, gdy decyzje o dalszym skalowaniu, integracjach lub ekspansji podejmowane są na podstawie samej dynamiki sprzedaży, bez pełnego obrazu prowizji, zwrotów, logistyki i kosztów obsługi każdego zamówienia.

Możesz odkryć problem dopiero przy zamknięciu miesiąca lub kontroli

Najbardziej niebezpieczny scenariusz nie wygląda jak awaria systemu. Zamówienia wpływają, dokumenty są generowane, paczki wychodzą, klienci płacą, a środki trafiają na rachunek. Operacyjnie wszystko może sprawiać wrażenie, że działa poprawnie. Problem pojawia się dopiero wtedy, gdy trzeba uzgodnić sprzedaż z raportami operatora, ewidencją VAT, prowizjami, zwrotami i przelewami bankowymi. Jeżeli nikt wcześniej nie zaprojektował sposobu przepływu danych, okazuje się, że część korekt nie ma identyfikatora kanału, zwroty nie łączą się z pierwotnymi zamówieniami, raport wypłat pokazuje kwoty po potrąceniach, a system sprzedażowy i księgowy przedstawiają inne wartości. Zamknięcie miesiąca zaczyna polegać na ręcznym odtwarzaniu transakcji zamiast na kontrolowanym i powtarzalnym uzgodnieniu danych.

Przy kontroli podatkowej lub audycie problem jest jeszcze bardziej widoczny, ponieważ firma musi nie tylko wykazać końcowe liczby, lecz także pokazać, z czego one wynikają. Powinna zachować możliwą do odtworzenia ścieżkę audytową od zamówienia, przez dokument sprzedaży i zapis w ewidencji VAT, po rozliczenie prowizji, korektę lub zwrot oraz wpływ środków. Jeżeli nie można przejść od pojedynczej transakcji do wszystkich tych elementów, wyjaśnienie różnic staje się czasochłonne i ryzykowne. Największym zagrożeniem nie jest więc to, że AI „zepsuje księgowość”. Znacznie większym ryzykiem jest potraktowanie nowego modelu sprzedaży jak starego procesu bez sprawdzenia, kto jest stroną transakcji, kto pobiera opłaty, jak rozliczane są pieniądze i w jaki sposób dane przechodzą przez kolejne systemy. Im wcześniej te zasady zostaną zaprojektowane, tym mniejsze ryzyko, że pozornie niewielkie niespójności zamienią się w problem widoczny dopiero przy zamknięciu miesiąca, sporządzaniu sprawozdania albo kontroli.

Checklista księgowa przed uruchomieniem Von Halsky/InPost Buy

Przed uruchomieniem kanału warto sprawdzić cztery obszary: model samej transakcji, przepływ danych i uzgodnienia, VAT i koszty oraz mechanizmy kontroli. Sama integracja techniczna nie wystarcza, jeżeli firma nie wie, jak później połączyć sprzedaż z podatkami, kosztami operatora i przepływem pieniędzy.

Model transakcji

Ustal, kto jest stroną umowy z klientem, kto kontroluje towar przed jego przekazaniem i kto ponosi główną odpowiedzialność za wykonanie sprzedaży.
Sprawdź, kto odpowiada za podatkowe udokumentowanie i zaewidencjonowanie transakcji, w tym za wystawienie paragonu lub faktury, gdy wymagają tego przepisy.
Zweryfikuj, czy sprzedaż i wynagrodzenie operatora powinny być prezentowane odrębnie, czy też charakter modelu uzasadnia inne ujęcie.

Dane i uzgodnienia

Nadaj Von Halsky/InPost Buy jednoznaczny identyfikator kanału i zadbaj, aby przechodził on do zwrotów, korekt, raportów płatniczych, raportów prowizyjnych i, o ile system na to pozwala, do danych księgowych i podatkowych.
Ustal sposób importu zamówień oraz reguły uzgadniania danych pomiędzy systemem sprzedażowym, ERP, księgą główną, ewidencją VAT i rachunkiem bankowym.
Zaprojektuj uzgodnienie pozwalające połączyć wartość zamówień, sprzedaż ujętą w księgach, VAT należny, prowizje i inne opłaty, zwroty, korekty oraz kwoty faktycznie otrzymane.

VAT i koszty

Rozdziel przychód ze sprzedaży, VAT należny, prowizje, opłaty technologiczne, koszty płatności, dostawy i pozostałe wynagrodzenia operatora zgodnie z ekonomiczną treścią poszczególnych świadczeń.
Sprawdź, kto jest rzeczywistym usługodawcą, z jakiego kraju działa, jaki jest rodzaj świadczonej usługi, gdzie znajduje się miejsce jej świadczenia i kto powinien rozliczyć VAT. Jeżeli usługę świadczy podmiot zagraniczny, zweryfikuj możliwość wystąpienia importu usług.
Zweryfikuj zasady VAT dla wszystkich obsługiwanych rynków, uwzględniając odpowiednio sprzedaż krajową, WDT w transakcjach B2B, WSTO i OSS w sprzedaży B2C oraz obowiązki wynikające z lokalizacji zagranicznych magazynów.

Kontrola

Zapisz ogólne zasady ujmowania sprzedaży i kosztów w polityce rachunkowości, a szczegółowy obieg danych, raportów i kontroli w instrukcji księgowej lub procedurze operacyjnej.
Wyznacz właściciela procesu odpowiedzialnego za monitorowanie kompletności danych, uzgodnienia oraz zmiany w modelu współpracy.
Zdefiniuj zdarzenia uruchamiające ponowną ocenę, takie jak istotna zmiana warunków umownych, odpowiedzialności stron, struktury opłat, sposobu przepływu pieniędzy albo modelu sprzedaży na nowych rynkach.

Dobrze wdrożony kanał nie powinien tworzyć w księgowości odrębnego, zamkniętego świata. Każda transakcja powinna być możliwa do prześledzenia od zamówienia, przez przychód i VAT, po koszty operatora, zwrot oraz końcowy przepływ pieniężny. Jeżeli takie uzgodnienie jest powtarzalne, udokumentowane i nie wymaga ręcznego odtwarzania danych, ryzyko księgowe, podatkowe i operacyjne znacząco maleje. Jeżeli nie jest możliwe, proces należy uporządkować przed zwiększeniem wolumenu — wraz ze skalą rośnie bowiem nie tylko liczba zamówień, ale również finansowy koszt każdego błędu w danych i rozliczeniach.

Przykład: jak może wyglądać jedno zamówienie od kliknięcia do księgowania?

Etap 1: Klient znajduje produkt przy pomocy AI

Proces zaczyna się od tego, że klient korzysta z asystenta AI, aby znaleźć produkt odpowiadający określonej potrzebie. Z perspektywy sklepu najważniejszą informacją na tym etapie jest źródło pozyskania zamówienia. Klient nie musiał wejść bezpośrednio na stronę sklepu, zobaczyć reklamy prowadzącej do konkretnej karty produktu ani rozpocząć zakupów od tradycyjnej wyszukiwarki. Jego kontakt z ofertą został zainicjowany w zewnętrznym kanale wspieranym przez AI. Nie zmienia to jeszcze sposobu księgowania sprzedaży, ponieważ samo miejsce odkrycia produktu nie przesądza o tym, kto będzie stroną późniejszej transakcji. Powinno jednak zostać zachowane jako informacja analityczna, ponieważ pozwala później przypisać sprzedaż, zwrot, prowizję i inne koszty do właściwego źródła. Jeżeli identyfikator kanału zostanie utracony już na początku procesu, odtworzenie rentowności sprzedaży po kilku miesiącach może wymagać ręcznego łączenia danych z kilku systemów.

Etap 2: Klient składa zamówienie

Po przejściu przez kolejne etapy procesu zakupowego zamówienie trafia do systemu sklepu lub do rozwiązania integracyjnego, z którego korzysta sprzedawca. W tym momencie szczególnie ważne jest zachowanie danych pozwalających nie tylko zrealizować zamówienie, ale również prawidłowo je zaklasyfikować. System powinien wiedzieć, z jakiego kanału pochodzi sprzedaż, jaki produkt został zamówiony, jaki jest status nabywcy, do jakiego kraju ma trafić przesyłka i z jakiej lokalizacji zostanie wysłana. Jeżeli firma prowadzi sprzedaż międzynarodową, te informacje mogą być potrzebne do ustalenia właściwego sposobu rozliczenia VAT. Samo pojawienie się zamówienia w systemie nie oznacza jednak automatycznie, że w tym samym momencie powstaje przychód. Moment jego ujęcia należy ustalić według zasad właściwych dla danego rodzaju sprzedaży i przyjętych zasad rachunkowości, a nie na podstawie tego, że klient zakończył określony etap w aplikacji wykorzystującej AI. W praktyce moment powstania przychodu rachunkowego i moment powstania obowiązku podatkowego w VAT nie zawsze są tożsame i powinny być oceniane według właściwych przepisów.

Etap 3: Sklep realizuje sprzedaż

Jeżeli zgodnie z umową i faktycznym przebiegiem transakcji to sklep pozostaje stroną umowy z klientem, kontroluje towar przed jego przekazaniem i ponosi główną odpowiedzialność za wykonanie sprzedaży, dalsza realizacja zamówienia pozostaje elementem jego działalności handlowej. Sklep przygotowuje towar do wydania, odpowiada za zgodność zamówienia i wykonuje obowiązki związane z realizacją świadczenia wobec nabywcy, nawet jeżeli część czynności technicznych lub logistycznych wykonują zewnętrzni usługodawcy. To właśnie na tym poziomie widać różnicę pomiędzy kanałem, przez który klient został pozyskany, a podmiotem, który faktycznie realizuje sprzedaż. AI może pomóc znaleźć produkt i przeprowadzić klienta przez ścieżkę zakupową, a operator może dostarczać infrastrukturę technologiczną, ale nie oznacza to automatycznie przejęcia przez niego roli sprzedawcy.

Etap 4: Sprzedaż zostaje prawidłowo udokumentowana i ujęta

Jeżeli sklep pozostaje sprzedawcą, odpowiada również za prawidłowe podatkowe udokumentowanie i zaewidencjonowanie transakcji zgodnie z zasadami właściwymi dla konkretnej sprzedaży. W zależności od modelu może to oznaczać wystawienie paragonu, faktury, innego wymaganego dokumentu albo ujęcie transakcji w odpowiedniej ewidencji. Przychód jest rozpoznawany jako przychód ze sprzedaży sklepu według zasad stosowanych do porównywalnych transakcji, a nie jako specjalna kategoria „przychodu z AI”. Jeżeli sprzedaż podlega VAT, przychodem rachunkowym jest co do zasady wartość sprzedaży bez VAT należnego. Jednocześnie należy zachować identyfikator kanału, aby sprzedaż mogła być później przypisana do Von Halsky/InPost Buy w raportach zarządczych. Dzięki temu księgowość finansowa pozostaje spójna z zasadami stosowanymi w firmie, a controlling nadal może analizować wyniki nowego źródła zamówień osobno.

Etap 5: Operator świadczy dodatkowe usługi

Równolegle do samej sprzedaży mogą pojawić się usługi świadczone przez operatora lub inne podmioty uczestniczące w procesie. Mogą one dotyczyć technologii, obsługi kanału, płatności, dostawy, zwrotów albo prowizji powiązanej z wartością zamówienia. Każdy z tych elementów powinien być analizowany zgodnie z rzeczywistym charakterem świadczenia, dokumentacją oraz przyjętą polityką rachunkowości. Jeżeli operator potrąca swoją należność przed przekazaniem środków, nie należy automatycznie traktować otrzymanej wypłaty jako przychodu sklepu. W modelu, w którym sklep powinien prezentować sprzedaż i koszty operatora odrębnie, konieczne jest uzgodnienie wartości sprzedaży, VAT, poszczególnych opłat, zwrotów i kwoty faktycznie otrzymanej. Dzięki temu można odtworzyć pełną ścieżkę finansową transakcji i uniknąć sytuacji, w której prowizja lub koszt logistyki znika w różnicy pomiędzy wartością zamówienia a przelewem.

Etap 6: Kanał zostaje ujęty w analityce

Na końcu procesu informacja o źródle zamówienia powinna pozostać dostępna w raportowaniu zarządczym i, w zakresie możliwości systemu, również w danych wykorzystywanych do uzgadniania ksiąg. Dzięki temu firma może śledzić sprzedaż wygenerowaną przez Von Halsky/InPost Buy, przypisywać do niej prowizje, koszty logistyczne, zwroty i inne obciążenia oraz oceniać rzeczywistą rentowność kanału. Nie wymaga to tworzenia nowego rodzaju przychodu ani osobnego świata księgowego. Wystarczy, że kanał zostanie potraktowany jako odrębny wymiar analityczny, a jego dane pozostaną spójne z księgą główną, ewidencją VAT, raportami sprzedażowymi i rozliczeniami pieniężnymi. W praktyce właśnie taki model daje największą elastyczność: firma zachowuje wspólne zasady rachunkowości, ale jednocześnie może szybko sprawdzić, czy sprzedaż wspierana przez AI zwiększa marżę, czy jedynie podnosi obrót i koszty obsługi.

Prosty przykład liczbowy: dlaczego wypłata od operatora nie musi być przychodem

Załóżmy, że sklep sprzedaje produkt za 1 230 zł brutto. Wartość sprzedaży netto wynosi 1 000 zł, a VAT należny 230 zł. Operator potrąca 80 zł prowizji oraz 25 zł kosztu dostawy, a na rachunek sklepu trafia 1 125 zł. Jeżeli sklep pozostaje sprzedawcą i powinien prezentować sprzedaż oraz koszty operatora odrębnie, kwota wpływająca na rachunek nie jest automatycznie równa przychodowi rachunkowemu.

Sprzedaż netto 1 000 zł
VAT należny 230 zł
Zapłata klienta 1 230 zł
Prowizja operatora 80 zł
Koszt dostawy 25 zł
Kwota faktycznie otrzymana 1 125 zł

W tym uproszczonym przykładzie przychodem ze sprzedaży jest co do zasady 1 000 zł, VAT należny wynosi 230 zł, prowizja operatora stanowi odrębny koszt, a koszt dostawy również jest ujmowany oddzielnie zgodnie z przyjętymi zasadami rachunkowości. Kwota 1 125 zł jest wynikiem przepływu pieniężnego po potrąceniu określonych należności i nie powinna być automatycznie utożsamiana z przychodem. 1 125 zł wpływu na rachunek nie oznacza 1 125 zł przychodu. Właśnie dlatego system powinien pozwalać przejść od wartości zamówienia przez VAT i koszty operatora do kwoty faktycznie otrzymanej.

Najczęstsze błędy przy księgowaniu nowych kanałów sprzedaży opartych o AI

Błąd 1: „Zakup odbywa się poza moją stroną, więc to na pewno marketplace w rozumieniu księgowym”

To jeden z najbardziej naturalnych skrótów myślowych. Jeżeli klient nie przechodzi przez klasyczną ścieżkę zakupową na stronie sklepu, łatwo uznać, że sprzedaż została przeniesiona na marketplace i powinna być rozliczana według jakiegoś odrębnego schematu. Problem polega na tym, że miejsce, w którym klient odkrył produkt lub zakończył proces zakupowy, nie przesądza samo w sobie o roli poszczególnych stron. Rozwiązanie może być biznesowo określane jako marketplace, kanał sprzedaży, interfejs elektroniczny lub platforma pośrednicząca, a mimo to sprzedawcą wobec klienta nadal może pozostawać sklep. Również sam status marketplace’u nie oznacza automatycznie, że operator wykazuje pełną wartość sprzedaży jako własny przychód. Dlatego zamiast zaczynać od etykiety, trzeba sprawdzić, kto jest stroną umowy, kto kontroluje towar przed przekazaniem klientowi i kto ponosi główną odpowiedzialność za wykonanie sprzedaży.

Błędne założenie na początku może pociągnąć za sobą kolejne nieprawidłowości. Firma może stworzyć niepotrzebnie odrębny schemat księgowania, zacząć raportować przychód w inny sposób niż w porównywalnych kanałach albo niewłaściwie interpretować rolę operatora dla celów VAT. Tymczasem dwa rozwiązania, które z perspektywy użytkownika wyglądają podobnie, mogą mieć zupełnie inny podział odpowiedzialności i przepływ pieniędzy. Dlatego kwalifikacja powinna wynikać z umowy, regulaminu, rzeczywistego modelu współpracy i faktycznego przebiegu transakcji, a nie tylko z tego, gdzie klient zobaczył przycisk finalizujący zakup.

Błąd 2: „AI uczestniczy w zakupie, więc potrzebujemy zupełnie nowego modelu księgowego”

Drugim błędem jest traktowanie obecności AI jako wydarzenia, które samo w sobie wymaga stworzenia nowej kategorii przychodów, nowych zasad VAT i osobnego planu kont. Z perspektywy technologicznej zmiana może być rzeczywiście duża. Klient nie musi już samodzielnie przeglądać katalogu i porównywać produktów, ponieważ część tej pracy wykonuje asystent AI. Z perspektywy rachunkowości nadal jednak liczy się rzeczywisty charakter transakcji. Jeżeli sklep pozostaje sprzedawcą, kontroluje towar przed przekazaniem klientowi i ponosi główną odpowiedzialność za wykonanie sprzedaży, samo wykorzystanie nowego interfejsu nie tworzy odrębnego rodzaju przychodu. Podobnie w VAT: AI nie zmienia automatycznie miejsca opodatkowania, statusu nabywcy, lokalizacji magazynu ani zasad właściwych dla sprzedaży krajowej i transgranicznej. AI jest elementem sposobu zawarcia transakcji, a nie nową kategorią zdarzenia gospodarczego.

Nie oznacza to, że nowy kanał można całkowicie zignorować w systemie finansowym. Może wymagać dodatkowej analityki, nowych raportów, sposobu uzgadniania wypłat oraz procedury przypisywania kosztów operatora. To jednak co innego niż budowanie od podstaw nowego modelu księgowego. Najczęściej większym wyzwaniem staje się jakość danych i ich przepływ pomiędzy systemami niż sama konstrukcja księgowania. Firma powinna więc rozdzielić dwa pytania: czy sposób ujmowania transakcji faktycznie się zmienił oraz czy potrzebujemy dokładniejszych danych o nowym kanale. Bardzo często odpowiedź brzmi: zasady rachunkowości pozostają podobne, ale analityka musi stać się bardziej szczegółowa.

Błąd 3: Brak oznaczenia źródła zamówienia

Brak trwałego identyfikatora kanału często nie powoduje problemu w pierwszych tygodniach działania. Zamówień jest niewiele, zespół wie, skąd pochodzą, a ewentualne różnice można wyjaśnić ręcznie. Problem pojawia się wraz ze wzrostem skali. Jeżeli informacja o źródle zamówienia nie przechodzi do korekt, zwrotów, raportów płatniczych, prowizyjnych i dokumentów magazynowych, firma zaczyna tracić możliwość wiarygodnego przypisania wyniku do kanału. Pierwotna sprzedaż może być oznaczona jako Von Halsky/InPost Buy, ale zwrot po kilku tygodniach zostanie już zaksięgowany bez tej informacji. W rezultacie raport kanału pokazuje zawyżony przychód i zaniżony poziom zwrotów, mimo że księgi na poziomie całej firmy mogą zawierać prawidłowe wartości.

Dlatego identyfikator kanału powinien towarzyszyć transakcji przez cały jej cykl życia. Nie chodzi wyłącznie o raport marketingowy, lecz o możliwość połączenia zamówienia z dokumentem sprzedaży, korektą, płatnością, prowizją i końcowym przepływem pieniężnym. Im więcej systemów uczestniczy w procesie, tym łatwiej tę informację zgubić. W praktyce dobrze zaprojektowany kod źródła zamówienia jest jednym z najprostszych narzędzi pozwalających ograniczyć późniejszą pracę ręczną i zachować spójność pomiędzy księgowością a controllingiem. Bez niego firma może wiedzieć, ile sprzedała łącznie, ale nie będzie potrafiła wiarygodnie odpowiedzieć, który kanał rzeczywiście wygenerował przychód, koszt i zwrot.

Błąd 4: Łączenie kosztów kanału z kosztami logistyki

Nowy kanał może generować kilka rodzajów kosztów jednocześnie, ale nie oznacza to, że wszystkie powinny trafiać do jednej zbiorczej kategorii. Prowizja od sprzedaży, opłata technologiczna, koszt promowania oferty, obsługa płatności i transport mają inny rzeczywisty charakter, nawet jeżeli są rozliczane przez tego samego operatora. Łączenie ich w jedną pozycję „koszt kanału” może uprościć księgowanie, ale utrudnić późniejszą ocenę rentowności i zrozumienie, co faktycznie wpływa na wynik. Kanał może być rentowny przy obecnym poziomie prowizji, lecz tracić marżę przez wysokie koszty zwrotów. Może też wyglądać na drogi tylko dlatego, że w jednej kategorii ujęto jednocześnie usługi technologiczne i logistyczne, których nie da się porównać z kosztami innych kanałów.

Właściwe podejście nie polega jednak na automatycznym tworzeniu osobnego konta dla każdej opłaty. Kluczowe jest ustalenie, czy umowa, faktura lub specyfikacja pozwalają rozdzielić poszczególne świadczenia oraz czy takie rozdzielenie jest istotne dla rachunkowości i zarządzania. Nie zawsze będzie ono możliwe, jeżeli operator fakturuje jedno kompleksowe świadczenie i brak jest wiarygodnych danych pozwalających przypisać jego elementy do odrębnych kategorii kosztowych. W takim przypadku firma powinna przyjąć spójny sposób klasyfikacji zgodny z polityką rachunkowości i stosować go konsekwentnie. Najgorszym rozwiązaniem jest mechaniczne księgowanie całej faktury do przypadkowej kategorii bez sprawdzenia, za co przedsiębiorstwo faktycznie płaci i czy przyjęty sposób prezentacji odpowiada istocie świadczenia.

Błąd 5: Brak ponownej analizy po zmianie regulaminu lub sposobu naliczania opłat

Model działający poprawnie dzisiaj nie musi być taki sam za rok. Operator może zmienić regulamin, strukturę prowizji, sposób przepływu płatności, zakres odpowiedzialności za klienta albo zasady obsługi zwrotów. Może również rozszerzyć usługę o nowe funkcje, które zmienią podział obowiązków pomiędzy sklepem a platformą. Jeżeli firma przyjęła sposób księgowania przy wdrożeniu i nigdy do niego nie wraca, istnieje ryzyko, że ewidencja przestanie odzwierciedlać aktualny model współpracy. To szczególnie istotne wtedy, gdy operator zacznie działać we własnym imieniu wobec klienta, zmieni się kontrola nad towarem, odpowiedzialność za wykonanie sprzedaży albo sposób rozliczania wynagrodzenia.

Ponowna analiza nie musi oznaczać przebudowy całego procesu po każdej drobnej aktualizacji regulaminu. Firma powinna jednak mieć określone zdarzenia, które uruchamiają weryfikację. Może to być istotna zmiana warunków umownych, nowy model opłat, zmiana podmiotu wystawiającego faktury, rozpoczęcie sprzedaży z zagranicznych magazynów albo modyfikacja sposobu rozliczania płatności i zwrotów. Dzięki temu księgowość nie pozostaje w tyle za modelem biznesowym. Najbardziej niebezpieczny błąd nie polega na tym, że firma źle sklasyfikuje nowy kanał pierwszego dnia, lecz na tym, że nigdy nie sprawdzi, czy przyjęta klasyfikacja nadal odpowiada temu, jak kanał rzeczywiście działa.

Autorem artykułu jest zespół amavat®

amavat® jest jedną z wiodących kancelarii świadczącą usługi kompleksowej księgowości dla polskich firm z branży e-commerce oraz VAT Compliance w całej Unii Europejskiej, w Wielkiej Brytanii i Szwajcarii. Firma oferuje również autorską innowacyjną aplikację, łącząc księgowość z rozwiązaniami IT, pozwalającymi na optymalizację procesów księgowych oraz na integracje z największymi marketplace'ami takimi jak Allegro i Kaufland oraz integratorem jak BaseLinker.

Zadaj pytanie »

Niniejsza publikacja ma charakter niewiążącej informacji i służy ogólnym celom informacyjnym. Przedstawione informacje nie stanowią doradztwa prawnego, podatkowego ani w zakresie zarządzania, jak również nie zastępują indywidualnego doradztwa. Przy opracowaniu niniejszej publikacji dołożono należytej staranności, jednak bez przejęcia odpowiedzialności za prawidłowość, aktualność i kompletność prezentowanych informacji. Treści w niej zawarte nie stanowią samodzielnej podstawy do działania i nie mogą zastąpić konkretnego doradztwa w indywidualnej sprawie. Odpowiedzialność autorów lub amavat® jest wyłączona. W razie potrzeby uzyskania wiążącej opinii prosimy o bezpośredni kontakt z nami. Treść niniejszej publikacji stanowi własność intelektualną amavat® lub firm partnerskich i podlega ochronie z tytułu praw autorskich. Osoby korzystające z tych informacji mogą pobierać, drukować i kopiować treść publikacji wyłącznie na własne potrzeby.

Baza wiedzy: Księgowość e-commerce i VAT Compliance