Księgowość platformy typu marketplace ze Stripe Connect

Q: Co się dzieje z wierszem Stripe, którego kategorii moduł importu nie rozpoznaje?

Trafia on na konto przejściowe rozliczeń, domyślnie 4440, a odpowiedź na zapytanie o księgowanie zwraca ostrzeżenie wymieniające kategorie, które tam trafiły. Rezerwy i nietypowe korekty zazwyczaj trafiają w ten sposób, co jest zamierzone: pieniądze pozostają widoczne, a dziennik pozostaje zbilansowany, dopóki ktoś nie zdecyduje, dokąd należą.

Q: Jak obsłużyć zwroty, które rozliczają się w późniejszej wypłacie?

Pojawiają się one jako wiersz refund w raporcie szczegółowym późniejszej wypłaty i są dopasowywane z powrotem do oryginalnego obciążenia za pomocą pola chargeid wcześniej dopasowanego obciążenia. Zwrot syntetyzowany z eksportu płatności na poziomie obciążeń jest w tym przypadku jedynie przybliżeniem, dlatego raport ze szczegółami jest bezpieczniejszym źródłem.

Praktyczny przewodnik po księgowaniu obciążeń, prowizji, transferów, zwrotów, sporów oraz rezerw w księdze głównej marketplace, która bezproblemowo się uzgadnia.

Większość problemów księgowych na platformach typu marketplace wynika z jednego błędu: traktowania wypłaty ze Stripe jak przychodu. Wypłata to czysta pozostałość po dziesiątkach odrębnych zdarzeń gospodarczych, a zaksięgowanie jej jako pojedynczej pozycji przychodowej zaciera prowizję platformy, zobowiązanie wobec sprzedawcy oraz wszelkie opłaty i spory wewnątrz niej. Prawidłowy proces rozliczeniowy rozkłada wypłatę na czynniki pierwsze, zanim cokolwiek trafi do księgi głównej.

Niniejszy przewodnik prowadzi przez każdą kategorię transakcji bilansowej w Stripe Connect, przypisując ją do właściwego konta księgowego: należności, przychodów z prowizji, zobowiązań wobec sprzedawców, kosztów obsługi płatności oraz konta przejściowego. Wykorzystuje on udokumentowane endpointy importu i rozliczeń Nordlet jako mechanizm księgowania, zawiera przykład kompletnego rozliczenia oraz kończy się listą kontrolną uzgodnień, którą można wykonać przed każdym zamknięciem okresu.

Określ model obciążeń Connect przed zaprojektowaniem czegokolwiek

Nie można sformułować reguł księgowych, dopóki nie wiesz, jakiego modelu obciążeń używa dany przepływ płatności. Model ten decyduje, na czyim saldzie w Stripe pojawia się obciążenie, kto ponosi opłaty oraz gdzie w pierwszej kolejności trafiają zwroty i spory.

Model Connect	Obciążenie tworzone na	Ponosi opłaty Stripe	Zwroty/spory pomniejszają	Konsekwencja księgowa
Obciążenia bezpośrednie (Direct charges)	Koncie powiązanym (Connected account)	Konfigurowalne dla każdej ze stron	Saldo konta powiązanego	Platforma księguje swoją opłatę za obsługę (application fee) jako przychód; aktywność płatnicza sprzedawcy dotyczy głównie księgi konta powiązanego
Obciążenia docelowe (Destination charges)	Platformie, z natychmiastowym transferem na jedno konto powiązane	Platformie	Platformie	Platforma księguje należność od klienta oraz opłatę Stripe; udział sprzedawcy to zobowiązanie, a nie przychód
Odrębne obciążenia i transfery (Separate charges and transfers)	Obciążeniu platformy, a następnie jednym lub wielu odrębnych transferach	Platformie	Platformie	Obciążenie i transfery do sprzedawcy to odrębne zdarzenia; zobowiązanie wobec sprzedawcy jest śledzone niezależnie od obciążenia klienta

Oficjalne wytyczne Stripe dotyczące sposobu działania obciążeń w integracji Connect potwierdzają, że w przypadku obciążeń docelowych oraz odrębnych obciążeń i transferów saldo platformy pokrywa opłaty za płatności, zwroty i obciążenia zwrotne (chargeback). W przypadku obciążeń bezpośrednich konto powiązane otrzymuje obciążenie, a opłaty mogą być pobierane z salda każdej ze stron.

Praktyczna zasada: nie mów, że „wypłata ze Stripe to przychód sprzedawcy” ani że „sprzedawca płaci opłaty”, dopóki nie spiszesz modelu obciążeń dla każdego przepłyvu. Przechowuj ten model wraz z każdą transakcją. Łączenie obciążeń bezpośrednich i docelowych pod jedną regułą księgowania to najszybsza droga do błędnego wykazania zarówno przychodów, jak i zobowiązań.

Ten przewodnik zakłada stosowanie obciążeń docelowych lub odrębnych obciążeń i transferów, ponieważ to w tych modelach saldo platformy dźwiga ciężar księgowy i to dla nich budowana jest większość ksiąg marketplace.

Odwzoruj przepływ środków przed zaimportowaniem choćby jednego wiersza

Zanim przystąpisz do importu, sporządź jednostronicowy schemat transakcji dla każdego przepłyvu:

Płatność klienta
  -> Obciążenie Stripe / transakcja bilansowa płatności
  -> Opłata Stripe
  -> Opłata za obsługę platformy (prowizja)
  -> Transfer na konto powiązane
  -> Zwrot lub spór (jeśli dotyczy)
  -> Wypłata ze Stripe
  -> Wpływ na rachunek bankowy

Każda strzałka to osobna transakcja bilansowa z własnym identyfikatorem, kategorią, kwotą i datami. Traktuj saldo Stripe jak rachunek rozliczeniowy przypominający konto bankowe: wpłynięcia z obciążeń wpływają do środka, opłaty i transfery wypływają, a wypłata przenosi resztę środków do prawdziwego banku. Dokumentacja importu bankowego i płatności w Nordlet zaleca dokładnie takie podejście do standardowej aktywności w Stripe.

Wybierz właściwy raport źródłowy ze Stripe

W przypadku automatycznych partii wypłat (payout settlement batches) skorzystaj z raportu Stripe Uzgodnienie wypłat, ze szczegółami (Payout reconciliation, itemized). Daje on jeden wiersz na transakcję bilansową, grupuje wiersze według pola reporting_category, powiązuje każdy z nich z identyfikatorem automatic_payout_id oraz dostarcza sumy brutto, opłat i kwot netto. Przewodnik po wyborze raportów Stripe dokumentuje ten raport i potwierdza, że charge_id, connected_account_id oraz destination_payment_id są dostępnymi polami Connect.

Tam, gdzie wypłaty automatyczne nie są włączone (niektóre układy z wypłatami ręcznymi), zamiast tego użyj raportu salda (Balance report). Nie traktuj podsumowania wypłat z panelu (Dashboard) jako wystarczającego dowodu do zaksięgowania. Podsumowanie udowadnia jedynie sumę partii; wyłącznie raport ze szczegółami wyjaśnia jej poszczególne składowe.

Stripe zaleca klasyfikowanie według pola reporting_category zamiast starszego pola type, a każdy wiersz zawiera identyfikator source, który łączy się z obiektem źródłowym. Zwróć uwagę na ograniczenie czasowe: Stripe podaje, że codzienne dane raportowe są zazwyczaj dostępne do południa następnego dnia, a wypłaty natychmiastowe (instant payouts) nie mogą być czysto przypisane do poszczególnych transakcji, przez co wymagają osobnego uzgodnienia historii transakcji.

Sklasyfikuj każdą transakcję bilansową według kategorii

Użyj reporting_category jako głównego klasyfikatora, a następnie przeanalizuj source_id, charge_id oraz opisy. Kluczowe mapowanie:

Aktywność w Stripe	Kategoria raportowa (reporting_category)	Interpretacja księgowa
Obciążenie klienta, karta lub lokalna metoda płatności	`charge`	Należność finansowana przez klienta lub rozliczenie sprzedaży
Zwrot środków	`refund`	Korekta pierwotnej płatności klienta
Opłata za przetwarzanie potrącona przez Stripe	`fee`	Koszt obsługi płatności
Prowizja platformy	`platform_earning`	Przychód ze sprzedaży prowizji
Zwrócona prowizja platformy	`platform_earning_refund`	Zmniejszenie przychodów z prowizji
Transfer na konto powiązane	`transfer`	Zmniejszenie zobowiązania wobec sprzedawcy
Cofnięty transfer	`transfer_reversal`	Odzyskanie środków od konta powiązanego
Obciążenie zwrotne (chargeback)	`dispute`	Strata z tytułu chargebacku; sprawdź źródłowy obiekt sporu
Wygrany lub cofnięty chargeback	`dispute_reversal`	Odzyskanie wcześniej zaksięgowanego chargebacku
Wypłata na rachunek bankowy	`payout`	Przepływ bankowy, a nie przychód
Cofnięta wypłata	`payout_reversal`	Zwrot środków na saldo Stripe
Zatrzymana rezerwa	`connect_reserved_funds` / `risk_reserved_funds`	Środki zastrzeżone, domyślnie niebędące kosztem
Pobranie zaległego ujemnego salda	`connect_collection_transfer`	Zdarzenie finansowania lub windykacji wymagające polityki ryzyka

Jedna uwaga terminologiczna: starsze pole typu transakcji bilansowej (type) używa innych etykiet dla tych samych zdarzeń, w tym payment, application_fee oraz adjustment. Dokumentacja typów transakcji bilansowych w Stripe wymienia oba słowniki. Nie mieszaj wartości z pola type z regułą opartą na reporting_category ani nie wymyślaj kategorii takich jak dispute_loss, których Stripe nie eksportuje. Jeśli eksport zawiera etykietę, której nie rozpoznajesz, zachowaj wyeksportowaną wartość i zweryfikuj ją z obiektem źródłowym.

Zaksięguj standardową aktywność marketplace do księgi

Dla platformy korzystającej z obciążeń docelowych lub odrębnych obciążeń i transferów, koncepcyjne zapisy wyglądają następująco.

Obciążenie klienta (pieniądze klienta wchodzą na saldo rozliczeniowe Stripe):

Wn Rachunek rozliczeniowy Stripe    Brutto obciążenia klienta
    Ma Należności handlowe           Brutto obciążenia klienta

Opłata za przetwarzanie Stripe:

Wn Koszty prowizji Stripe           Opłata Stripe
    Ma Rachunek rozliczeniowy Stripe Opłata Stripe

Nie kompensuj opłaty Stripe z przychodem, chyba że Twoja polityka rachunkowości wyraźnie tego wymaga i dopuszcza prezentację netto.

Prowizja platformy (Twój przychód, wydzielony z kwoty, która w przeciwnym razie należałaby się sprzedawcy):

Wn Zobowiązania wobec sprzedawców   Kwota prowizji
    Ma Przychody ze sprzedaży prowizji Kwota prowizji

Transfer do sprzedawcy (rozliczenie należnych środków, a nie koszt):

Wn Zobowiązania wobec sprzedawców   Kwota transferu
    Ma Rachunek rozliczeniowy Stripe Kwota transferu

Transfer nigdy automatycznie nie jest kosztem. Udział sprzedawcy staje się zobowiązaniem w momencie pojawienia się obciążenia, a transfer to zobowiązanie wygasza. Zasady księgowania rozliczeń w Nordlet postępują zgodnie z tym schematem: wiersze platform_earning trafiają na przychody z prowizji, podczas gdy wiersze transfer zmniejszają zobowiązanie wobec sprzedawcy. Udokumentowane domyślne klucze księgowania to settlements.commissionRevenue (domyślnie 5001), settlements.sellerPayable (domyślnie 4499), settlements.fees (domyślnie 6800) oraz settlements.suspense (domyślnie 4440), z których każdy może być nadpisany dla każdej spółki poprzez reguły księgowania w API Nordlet.

Obsłuż zwroty względem oryginalnej sprzedaży, a nie jako luźne pozycje bankowe

Zwrot jest powiązany z oryginalnym obciążeniem lub fakturą. Koncepcyjnie:

Wn Zwroty / korekty sprzedaży       Kwota zwrotu
    Ma Należności handlowe           Kwota zwrotu

Właściwy zapis zależy od tego, czy sprzedaż została ujęta w przychodach, czy należy skorygować podatek VAT oraz czy zwrócono prowizję platformy. Pojedynczy zwrot może skutkować korektą należności, korektą podatku, zwrotem prowizji, cofnięciem transferu lub zmniejszeniem zobowiązania wobec sprzedawcy oraz skutkiem w opłatach Stripe, który należy sprawdzić, zamiast zakładać w ciemno.

Pułapka czasowa: zwrot często rozlicza się w wypłacie przypadającej później niż oryginalne obciążenie. Przedkładaj szczegółowy raport uzgodnienia wypłat nad zwrot syntetyzowany z eksportu na poziomie obciążeń. Dokumentacja Nordlet ostrzega wprost, że zwrot syntetyzowany z eksportu płatności jest jedynie przybliżeniem, gdy zwrot rozlicza się później. Modulet importu rozliczeń potrafi wczytać wiersz zwrotu, dopasować go do oryginalnej sprzedaży i skorygować należność w momencie zaksięgowania partii.

Traktuj spory niezależnie od zwrotów

Spór to roszczenie zgłoszone przez posiadacza karty lub bank wydający, a Stripe może obciążyć saldo platformy zarówno sporną kwotą, jak i opłatą za spór jeszcze przed jego rozstrzygnięciem. W przypadku obciążeń docelowych oraz odrębnych obciążeń i transferów Stripe obciąża saldo platformy obiema kwotami, zgodnie ze swoimi wytycznymi dotyczącymi zwrotów i sporów. Platforma może próbować odzyskać środki poprzez cofnięcie transferu do sprzedawcy.

Przegrany spór z perspektywy platformy:

Wn Strata z tytułu chargeback / ponowne otwarcie należności  Sporna kwota
Wn Koszty opłat spornych                                     Opłata za spór
    Ma Rachunek rozliczeniowy Stripe                         Łączna kwota

Jeśli sprzedawca ponosi stratę i potwierdzono odzyskanie środków:

Wn Zobowiązania wobec sprzedawców / konto windykacji         Kwota do odzyskania
    Ma Odzyskanie środków z tytułu chargeback               Kwota do odzyskania

Nie księguj odzyskania środków od sprzedawcy tylko dlatego, że zażądano cofnięcia transferu. Zweryfikuj, czy cofnięcie zostało utworzone, powiodło się i widnieje w saldzie Stripe. Jeśli spór zostanie wygrany, Stripe zwraca sporną kwotę za pomocą wiersza dispute_reversal; skoryguj stratę z tytułu chargebacku i osobno obsłuż wszelkie opłaty sporne, których Stripe nie zwraca. Nordlet dopasowuje wiersze chargebacku za pomocą identyfikatora charge_id wcześniej dopasowanego obciążenia, z tego samego pliku lub z wcześniejszego importu.

Przykład kompletnego rozliczenia

Weźmy jedną partię wypłat automatycznych. Raport ze szczegółami zawiera:

Wiersz charge: brutto 100.00, opłata Stripe 3.20, netto 96.80
Wiersz platform_earning: 15.00, prowizja platformy
Wiersz transfer: 81.80 do powiązanego sprzedawcy
Wiersz refund z wcześniejszej sprzedaży: brutto 20.00, rozliczany w tej partii
Wiersz payout: suma partii trafiająca do banku

Struktura wypłaty, zgodnie z tożsamością rozliczeniową Stripe:

Obciążenia brutto            100.00
- zwroty                      20.00
- opłaty Stripe                3.20
- transfery                   81.80
= netto na saldzie platformy  -5.00

Wiersz platform_earning nie przemieszcza pieniędzy po raz drugi. Wskazuje on kwotę 15.00, która pozostaje na saldzie platformy po potrąceniu opłaty i transferu do sprzedawcy, dzięki czemu platforma może rozpoznać przychód z prowizji zamiast go wyznaczać na oko.

W tym przypadku transfer do sprzedawcy oraz zwrot przewyższają wpływy z bieżących obciążeń, przez co partia daje niewielki ujemny wynik netto i pomniejsza kolejną wypłatę lub pobiera środki z salda. Zaksiegowany zapis koryguje zwróconą należność, rozpoznaje 15.00 przychodu z prowizji, rejestruje koszt opłat w wysokości 3.20, zmniejsza zobowiązanie wobec sprzedawcy o kwotę transferu oraz księguje korektę zwrotu. Pozycja bankowa zgadza się z kwotą netto, która dociera na rachunek. Żadna pojedyncza cyfra nie jest równa „przychód”, o co właśnie chodzi.

Import i księgowanie przez endpoint rozliczeń Nordlet

W celu uzgodnienia na poziomie wypłat użyj:

POST /v1/bank/settlements/import

z dostawcą Stripe i plikiem CSV ze szczegółami. Nordlet grupuje wiersze według pola automatic_payout_id, zamienia każdą wypłatę w partię rozliczeniową z sumami brutto, opłat i netto, pomija ponowne importy już zaksiegowanej wypłaty, pomija wiersze payout ze struktury rozliczenia oraz automatycznie dopasowuje wiersze obciążeń, zwrotów i sporów za pomocą zamówień, faktur, obiektów PaymentIntent, obciążeń, źródeł lub odnośników metadanych. Stripe dzieli raport szczegółowy na jeden plik na sekcję, więc importuj pliki obciążeń, zwrotów i opłat razem: wiersze należące do wypłaty, która została już zaimportowana, ale jeszcze nie zaksiegowana, łączą się z istniejącą partią. Jest to przepływ polegający na imporcie i księgowaniu sterowany plikami i endpointami rozliczeniowymi, a nie działający na żywo łącznik ze Stripe; strona funkcji wymienia zakres obsługiwanych funkcji bankowych i rozliczeniowych.

Dopasowuj w kolejności: obciążenia do faktur, zwroty do oryginalnych obciążeń, spory do oryginalnych obciążeń, wiersze prowizji do traktowania prowizyjnego. Trzymaj opłaty Stripe, korekty, rezerwy i wiersze wypłat z dala od dopasowywania faktur. Słownik uzgodnień płatności Nordlet stwierdza, że linie opłat i korekt z założenia nie podlegają dopasowaniu do faktur; kieruj nierozliczone pozycje finansowe na konto przejściowe (suspense). Ręczna korekta wykorzystuje bank/settlements/match { lineId, invoiceId }, przy czym null dla invoiceId służy do cofnięcia dopasowania.

Następnie zaksęguj jedną zbilansowaną partię:

POST /v1/bank/settlements/post

Tworzy to jeden zbilansowany dziennik, rozlicza dopasowane faktury, obciąża konto księgowe rachunku bankowego kwotą wypłaty netto, obciąża koszty opłat, uznaje należności z tytułu obciążeń, koryguje należności w przypadku zwrotów i chargebacków, dzieli niedopasowane obciążenia marketplace między przychody z prowizji a zobowiązania wobec sprzedawców, gdy podano commissionPercent, oraz przesyła nierozliczone kwoty na konto przejściowe. Każda nierozpoznana kategoria również trafia na konto przejściowe, a odpowiedź wymienia te kategorie w ostrzeżeniu zamiast po cichu je wchłaniać.

Lista kontrolna uzgodnień

Wykonaj te asercje przed każdym zamknięciem okresu:

Brak duplikatów balance_transaction_id
Brak duplikatów partii rozliczeniowej (provider, payout_id)
Suma wartości net w wierszach jest równa wartości netto partii
Wartość netto partii jest równa wypłacie bankowej, z uwzględnieniem czasu realizacji i polityki walutowej
Każdy zwrot posiada oryginalne obciążenie lub zarejestrowany wyjątek
Każdy spór posiada odnośnik do sporu lub obciążenia
Każdy transfer posiada identyfikator konta powiązanego
Każdy wiersz platform_earning ma zdefiniowane traktowanie prowizyjne
Konto przejściowe ma saldo zerowe lub zostało w pełni przeanalizowane, w tym uwzględniono wszelkie nierozpoznane kategorie wymienione w ostrzeżeniu o księgowaniu
Zobowiązania wobec sprzedawców nie są ujemne bez zatwierdzonej zaliczki lub polityki windykacji
Zaksiegowane partie nie mogą być potajemnie importowane lub księgowane ponowanie
Wypłata w walucie innej niż waluta bazowa spółki jest przeliczana po kursie z dnia wypłaty, a różnica względem własnego kursu każdej faktury jest księgowana jako zrealizowany zysk lub strata kursowa; wypłata łącząca wiele walut jest odrzucana podczas importu

Uzgadniaj na trzech poziomach: wiersza (każda transakcja ma zachowany identyfikator, kategorię, kwotę, walutę, źródło), wypłaty (sumy netto ze szczegółów są równe wypłacie ze Stripe i wpływowi bankowemu) oraz księgi (zaksiegowany dziennik bilansuje się i generuje zamierzone pozycje przychodów, kosztów, należności, zobowiązań wobec sprzedawców oraz konta przejściowego). W odniesieniu do sald sprzedawców sprawdź w szczególności, czy początkowe zobowiązanie wobec sprzedawcy plus nowy udział sprzedawcy, pomniejszone o transfery i prawidłowe korekty, daje końcowe zobowiązanie wobec sprzedawcy.

Powtarzającym się błędem w każdej księdze marketplace jest dokładnie to samo, od czego zaczęto: sprowadzenie ustrukturyzowanej wypłaty do pojedynczej liczby. Trzymaj składowe osobno, zakotwicz każdą z nich do stabilnego identyfikatora Stripe i pozwól, aby konto przejściowe zatrzymało wszystko, czego jeszcze nie potrafisz wyjaśnić. Czyste zamknięcie okresu to coś, czemu audytor zaufa.

FAQ

Czy wypłata ze Stripe to przychód platformy?

Nie. Wypłata to kwota netto składająca się z obciążeń, zwrotów, opłat za przetwarzanie, transferów do sprzedawców, sporów i korekt, które rozliczyły się w tej samej partii. Zaksiegowanie jej jako pojedynczej pozycji przychodowej zaciera zobowiązanie wobec sprzedawcy oraz ukryty w środku koszt obsługi. W przypadku marketplace'u o charakterze agencyjnym przychodem jest prowizja, którą identyfikują wiersze platform_earning.

Z jakim raportem Stripe powinienem dokonywać uzgodnień?

Z raportem Uzgodnienie wypłat, ze szczegółami (Payout reconciliation, itemized), ponieważ daje on jeden wiersz na transakcję bilansową z polem reporting_category, identyfikatorem automatic_payout_id oraz kwotami brutto, opłat i netto. Podsumowanie wypłat z panelu dowodzi jedynie łącznej kwoty partii. Tam, gdzie wypłaty automatyczne nie są włączone, zamiast tego skorzystaj z raportu salda (Balance report).

Czy transfer do sprzedawcy powinien być księgowany jako koszt?

Nie. Udział sprzedawcy staje się zobowiązaniem w momencie, gdy obciążenie klienta trafia do systemu, a transfer to zobowiązanie wygasza. Księgowanie transferów jako kosztów powoduje podwójne liczenie kosztów i sprawia, że zobowiązanie wobec sprzedawcy pozostaje trwale zawyżone.

Co się dzieje z wierszem Stripe, którego kategorii moduł importu nie rozpoznaje?

Trafia on na konto przejściowe rozliczeń, domyślnie 4440, a odpowiedź na zapytanie o księgowanie zwraca ostrzeżenie wymieniające kategorie, które tam trafiły. Rezerwy i nietypowe korekty zazwyczaj trafiają w ten sposób, co jest zamierzone: pieniądze pozostają widoczne, a dziennik pozostaje zbilansowany, dopóki ktoś nie zdecyduje, dokąd należą.

Jak obsłużyć zwroty, które rozliczają się w późniejszej wypłacie?

Pojawiają się one jako wiersz refund w raporcie szczegółowym późniejszej wypłaty i są dopasowywane z powrotem do oryginalnego obciążenia za pomocą pola charge_id wcześniej dopasowanego obciążenia. Zwrot syntetyzowany z eksportu płatności na poziomie obciążeń jest w tym przypadku jedynie przybliżeniem, dlatego raport ze szczegółami jest bezpieczniejszym źródłem.