Rozliczanie prowizji marketplace - jak policzyć realną marżę na zamówieniu

Jak przypisać opłaty marketplace do zamówienia

Po pobraniu historii billingowej każdy wpis trzeba zaklasyfikować i przypisać. W praktyce opłaty dzielą się na trzy grupy, które obsługuje się inaczej:

• opłaty z identyfikatorem zamówienia - np. prowizja od sprzedaży; przypisuje się je bezpośrednio do zamówienia, a jeśli zamówienie ma kilka pozycji, rozdziela się je na pozycje według wartości,

• opłaty z identyfikatorem oferty, ale bez zamówienia - np. opłaty za wystawienie lub wyróżnienie; przypisuje się je do oferty, a potem rozkłada na zamówienia z tej oferty w danym okresie,

• opłaty na poziomie konta - np. abonamenty i usługi dodatkowe; rozdziela się je według klucza, np. proporcjonalnie do przychodu netto w miesiącu, albo pokazuje osobno jako koszt stały.

Klucz podziału kosztów bez zamówienia to decyzja biznesowa, a nie techniczna. Warto ją podjąć z osobą, która odpowiada za finanse, i zapisać w dokumentacji raportu. Ważne, żeby raport pokazywał osobno marżę przed i po rozdzieleniu kosztów wspólnych. Wtedy łatwo odróżnić produkt, który nie zarabia na prowizji, od produktu, który zarabia, ale nie pokrywa kosztów stałych konta.

Mając wszystkie koszty przypisane do zamówienia, marżę liczy się według prostego wzoru. Diagram pokazuje go na przykładowych, umownych kwotach:

[#chart:wpr72b]

Netto, brutto i VAT w opłatach marketplace

Częstym źródłem rozbieżności jest mieszanie kwot netto i brutto. Przychód ze sprzedaży w panelu marketplace'u zwykle widać brutto, a opłaty platformy są na fakturze z podatkiem VAT. Wpisy w historii billingowej Allegro zawierają informację o stawce podatku, co pozwala przeliczyć je na netto. Dla przejrzystości marżę najlepiej liczyć konsekwentnie w kwotach netto po obu stronach: przychód bez VAT i koszty bez VAT podlegającego odliczeniu. Sposób ujęcia opłat w księgach i rozliczenie podatku ustal z księgowym, bo zależy od sytuacji firmy.

Wysyłka, reklama i promowanie w rachunku marży z marketplace

Prowizja od sprzedaży to zwykle największa, ale nie jedyna opłata. W historii rozliczeń marketplace'u pojawiają się też opłaty za usługi dostawy realizowane przez platformę, wyróżnienia ofert i kampanie reklamowe. Część z nich ma powiązanie z zamówieniem lub ofertą, część jest naliczana zbiorczo, np. za kampanię w danym okresie. Koszty wysyłek nadawanych własnym kurierem nie pojawią się w ogóle w danych platformy, tylko na fakturach przewoźnika, więc trzeba je pobrać z integracji kurierskiej albo przypisać według stawki z umowy.

W raporcie warto rozdzielić koszty na grupy: prowizje, logistyka, promowanie i reklama, korekty oraz koszty wspólne konta. Dzięki temu widać, czy spadek marży wynika z wyższych prowizji, droższych wysyłek, czy z kampanii, która przestała się zwracać. Mapowanie typów operacji z API na te grupy to jednorazowa praca, ale trzeba ją przeglądać, gdy platforma doda nowy typ opłaty. Nieznany typ powinien trafiać do osobnej kategorii i wywoływać powiadomienie, a nie znikać z raportu.

Zagraniczne wersje serwisu i waluty

Sprzedawcy obecni na zagranicznych wersjach Allegro dostają opłaty w podziale na serwisy. Dokumentacja wskazuje parametr marketplaceId, którym pobiera się historię rozliczeń dla konkretnego serwisu, a domyślnie zwracany jest serwis bazowy konta. Każdy wpis ma kwotę z walutą, więc raport musi przeliczać ją do waluty raportowej według jednej, stałej zasady, uzgodnionej z księgowym, i zapisywać zastosowany kurs przy wpisie (stan na wrzesień 2026 - sprawdź aktualną dokumentację Allegro API).

Jak często pobierać dane rozliczeń

Do raportu marży wystarczy zwykle pobieranie raz dziennie, w nocy, z okresu kilku tygodni wstecz. Historia rozliczeń w Allegro jest stronicowana: według dokumentacji jedno zapytanie zwraca domyślnie i maksymalnie 100 wpisów, a kolejne strony pobiera się parametrem offset (stan na wrzesień 2026 - sprawdź aktualną dokumentację Allegro API). Przy dużej liczbie zamówień warto dzielić okres na krótsze przedziały dat i pilnować limitów zapytań, żeby skrypt raportowy nie konkurował o nie z integracją obsługującą zamówienia.

Korekty, zwroty prowizji i opóźnione naliczenia

Raport marży z marketplace'u nigdy nie jest zamknięty w dniu sprzedaży. Według dokumentacji Allegro opłaty są naliczane w cyklach 10-dniowych, więc część kosztów zamówienia pojawia się w historii billingowej z opóźnieniem (stan na wrzesień 2026 - sprawdź aktualną dokumentację Allegro API). Do tego dochodzą korekty rachunku oraz zwroty prowizji, o które sprzedawca może wnioskować m.in. po zwrocie towaru, na zasadach opisanych w pomocy Allegro.

Dla integracji oznacza to, że nie wystarczy pobierać wpisów z ostatniego dnia. Bezpieczniej jest przy każdym uruchomieniu pobierać okres z kilku poprzednich tygodni, rozpoznawać wpisy po identyfikatorze, żeby ich nie dublować, i przeliczać marżę zamówień, do których doszły nowe wpisy. Zamówienie zwrócone powinno w raporcie pokazywać zarówno pierwotną prowizję, jak i ewentualny zwrot, a nie znikać.

[#uwaga] Jeśli raport marży zasila decyzje cenowe, np. reguły repricingu, opóźnione naliczenia mogą sprawić, że świeże zamówienia wyglądają na bardziej opłacalne, niż są. Warto oznaczać w raporcie, które dni są jeszcze niekompletne, i podejmować decyzje na danych z zamkniętych okresów.

Jak zbudować raport realnej marży krok po kroku

Rozliczanie prowizji marketplace można zbudować w kilku krokach. Kolejność jest ważna, bo każdy etap zależy od jakości poprzedniego:

[#chart:wpr72c]

Koszt towaru to element, który w wielu firmach jest najsłabszy. Jeśli w ERP lub integratorze nie ma aktualnych cen zakupu, raport pokaże marżę tylko na papierze. Przed budową raportu warto sprawdzić, skąd brać koszt zakupu, jak traktować dostawy po różnych cenach i kto aktualizuje te dane. Dopiero potem ma sens dokładne liczenie prowizji. Przykład raportowania marży per kanał w gotowym integratorze opisujemy we wpisie o tym, jak działają raporty sprzedaży i marży per kanał w Apilo.

Gdzie przechowywać dane rozliczeń

Przy kilkuset zamówieniach miesięcznie wystarczy arkusz zasilany skryptem. Przy większej skali lepiej sprawdza się baza danych lub hurtownia danych, w której przechowuje się surowe wpisy billingowe, słownik typów i tabelę przypisań do zamówień. Surowe dane warto zachować, bo przy zmianie klucza podziału kosztów można wtedy przeliczyć historię bez ponownego pobierania wszystkiego z API. Ułatwia to też wyjaśnianie rozbieżności z fakturą od platformy, bo każdą pozycję raportu da się odtworzyć do pojedynczego wpisu.

Najczęstsze błędy w rozliczaniu prowizji marketplace

Poniżej błędy, które najczęściej znajdujemy w raportach marży budowanych przez sprzedawców samodzielnie lub w gotowych narzędziach:

1. marża liczona z cennika prowizji zamiast z rzeczywistych naliczeń,

2. pobieranie tylko nowych wpisów bez korekt i zwrotów z poprzednich okresów,

3. mieszanie kwot netto i brutto po stronie przychodu i kosztów,

4. pomijanie opłat bez identyfikatora zamówienia, przez co marża jest zawyżona,

5. brak kosztu wysyłki i pakowania albo liczenie go raz na zamówienie przy kilku paczkach,

6. koszt zakupu towaru z nieaktualnego cennika dostawcy.

Każdy z tych błędów osobno zmienia wynik o niewiele, ale razem potrafią sprawić, że produkty uznawane za najbardziej dochodowe w rzeczywistości ledwo wychodzą na zero. Jeśli ceny w kanałach są ustalane regułami, błędna marża przenosi się od razu na ceny, o czym piszemy we wpisie o synchronizacji cen w wielu kanałach sprzedaży.

[#checklista] Zanim zaufasz raportowi marży z marketplace, sprawdź: czy opłaty pochodzą z historii rozliczeń, a nie z cennika; czy każdy typ operacji ma przypisaną kategorię kosztu; czy opłaty bez zamówienia są rozdzielane według zapisanego klucza; czy przychód i koszty są liczone w netto; czy integracja pobiera dane kilka tygodni wstecz i nie dubluje wpisów; czy zwroty prowizji trafiają do pierwotnych zamówień; czy koszt towaru i wysyłki jest aktualny; czy suma opłat w raporcie za zamknięty miesiąc zgadza się z fakturą od platformy.

Jak Vinson pomaga w rozliczaniu prowizji marketplace

Programiści Vinson budują integracje, które pobierają rzeczywiste opłaty z API Allegro i innych marketplace'ów, przypisują je do zamówień, rozdzielają koszty wspólne według ustalonego klucza i łączą wszystko z kosztem towaru z ERP lub integratora. Przygotowujemy raporty marży w arkuszach, bazach danych i Looker Studio, z obsługą korekt, zwrotów prowizji i opóźnionych naliczeń. Pomagamy też sprawdzić, czy istniejący raport liczy marżę poprawnie. Szczegóły znajdziesz na stronie Wsparcie programistyczne dla e-commerce.

Najczęściej zadawane pytania

Jak policzyć realną marżę na zamówieniu z Allegro?

Od przychodu netto z zamówienia odejmij koszt towaru netto, rzeczywiste opłaty Allegro przypisane do zamówienia, koszt wysyłki i pakowania oraz udział w kosztach wspólnych, np. reklam. Opłaty najlepiej pobierać z historii operacji billingowych w API Allegro, a nie liczyć z cennika.

Czy z API Allegro można pobrać prowizję dla konkretnego zamówienia?

Tak. Zasób GET /billing/billing-entries pozwala filtrować wpisy m.in. po identyfikatorze zamówienia, a prowizja od sprzedaży ma osobny typ operacji. Część opłat nie ma jednak przypisanego zamówienia, więc trzeba je rozdzielić według własnego klucza.

Dlaczego marża z raportu różni się od faktury z marketplace?

Najczęściej raport liczy prowizję z cennika, pomija opłaty bez zamówienia albo nie uwzględnia korekt i zwrotów prowizji naliczonych później. Rozbieżność daje też mieszanie kwot netto i brutto. Raport oparty na historii billingowej i aktualizowany wstecz powinien zgadzać się z fakturą.

Jak uwzględnić zwrot prowizji po zwrocie towaru?

Zwrot prowizji pojawia się w historii rozliczeń jako osobny wpis, często w innym okresie niż sprzedaż. Integracja powinna przypisać go do pierwotnego zamówienia i przeliczyć jego marżę, a raport pokazywać zarówno prowizję, jak i zwrot.

Czy do rozliczania prowizji wystarczy integrator?

Część integratorów ma raporty marży per kanał, które wystarczą małemu sprzedawcy. Przy kilku marketplace'ach, kosztach wspólnych i potrzebie łączenia danych z ERP zwykle potrzebny jest własny raport lub hurtownia danych zasilana przez API.

Rozliczanie prowizji marketplace to podstawa decyzji o cenach, asortymencie i kanałach sprzedaży. Raport oparty na rzeczywistych naliczeniach, z korektami, zwrotami i kosztem towaru, pokazuje marżę, której można użyć w praktyce. Jeśli chcesz zbudować taki raport albo sprawdzić obecny, zajrzyj na stronę wsparcie programistyczne Vinson.