Marketplace Seller Subledgers: Revenue vs Payables
A practitioner's guide to separating customer cash, platform commission, seller payables, reserves, and payouts with balanced journal entries and a working order-to-payout data model.
Najčešća pogreška u računovodstvu internetskih tržnica (marketplace) jest tretitanje bruto uplate kupca kao prihoda platforme. Kupac plati 100 EUR, taj iznos sjeda na račun procesora plaćanja, a netko cijeli iznos proknjiži kao prihod od prodaje. Poslovne knjige se nakratko slažu, prihod izgleda odlično, a onda revizor pita gdje je obveza prema prodavatelju. Obveze nema jer iznos prodavatelja od 90 EUR nikada nije evidentiran kao novac koji se duguje.
Rješenje je strukturno, a ne kozmetičko. Tržnica treba model glavne knjige (ledger) koji od prvog knjiženja odvaja pet zasebnih fondova: novac kupaca u tijeku naplate, prihod od provizije platforme, obveze prema prodavateljima, naknade i rezerve. Isplate su šesti događaj kojim se podmiruje obveza, a same po sebi nisu ni prihod ni rashod. U ovom su vodiču prikazana uravnotežena knjiženja i podatkovni model koji te fondove drže odvojenima.
Počnite sa zaključkom o ulozi nalogodavca ili posrednika (principal-versus-agent)
Prije nego što struktura konta postane važna, platforma mora odlučiti što točno prodaje. Prema standardu ASC 606, to se procjenjuje za svako pojedinačno dobro ili uslugu, a odgovor određuje jesu li prihodi iskazani u bruto ili neto iznosu. Platforma može biti nalogodavac (principal) za jedan tijek novca, a posrednik (agent) za drugi.
Za tipičnu prodaju putem tržnice koja uključuje robu prodavatelja, platforma je obično posrednik. Ona organizira isporuku proizvoda prodavatelja kupcu, ne preuzima rizik zaliha, a njezina naknada je provizija. Deloitteove smjernice za odnos nalogodavca i posrednika prema standardu ASC 606 temelje test na kontroli: odgovornost za ispunjenje obećanja, rizik zaliha i sloboda određivanja cijena pokazatelji su, a ne kontrolni popis koji ima prednost nad temeljnom procjenom kontrole.
Razlog zašto ovo mora biti dio dizajna glavne knjige, a ne samo interne bilješke, jest taj što taj zaključak potiče svako naknadno knjiženje. Ako je platforma posrednik, udio prodavatelja je obveza onog trenutka kada je zarađen. Ako je nalogodavac za uslugu ispunjenja narudžbe (fulfillment) ili jamstva, taj dio predstavlja prihod platforme. Spremite zaključak kao podatke:
principal_agent_rolespecified_good_or_servicecommission_rule_idcontrol_assessment_versioneffective_from/effective_to
Revizor koji dvije godine kasnije pregledava stavku neto provizije mora moći vidjeti zašto nije korišten bruto iznos. Kako BillingPlatform navodi u vezi sa standardom ASC 606 za nalogodavce i posrednike, naziv "tržnica" ne rješava to pitanje. Analiza kontrole rješava.
Definirajte saldo prodavatelja prije nego što napišete ijedno pravilo za knjiženje
"Saldo prodavatelja" nije samo jedan broj. Prodavatelj može imati odličan ukupni saldo poslovanja, a na raspolaganju za isplatu ništa jer je novac još u statusu obrade ili se drži u rezervi. Ako spojite ta stanja, pogrešno ćete prikazati što prodavatelj može podići, a što platforma još uvijek duguje.
Minimalno pratite sljedeće:
- U obradi (Pending): zarađeno ili naplaćeno, još nije ispunjava uvjete za isplatu
- Dostupno (Available): ispunjava uvjete za isplatu prema pravilima platforme
- U rezervi (Reserved): zadržano za pokriće očekivanih povrata, sporova ili povrata sredstava (chargeback)
- Isplaćeno (Paid out): preneseno ili predano na namiru
- Negativno (Negative): iznos koji prodavatelj duguje, a naplativ je iz budućih prihoda
- Prijelazni račun (Suspense): primljeno, ali prodavatelj ili postupak još nisu utvrđeni
Pružatelji usluga plaćanja već primjenjuju ovu razliku. Stripe odvaja svaki povezani račun na saldo u obradi i raspoloživi saldo te zadržava saldo rezerve na razini platforme za određene negativne salde prodavatelja. Ako procesor odvaja te stavke, to mora učiniti i glavna knjiga, inače se usklađivanje nikada neće poklopiti.
Kontni plan i dimenzije koje su važne
Funkcionalna početna struktura drži prijelazne račune, obveze i prihode odvojenima te nosi dimenziju prodavatelja uz svako značajno knjiženje.
| Svrha | Konto ili dimenzija | Tretman |
|---|---|---|
| Sredstva kod procesora koja čekaju namiru | Prijelazni račun procesora plaćanja | Prijelazna imovina |
| Isplaćeno s procesora na bankovni račun | Banka | Imovina |
| Zarada prodavatelja koja je ostvarena, ali nije plaćena | Obveze prema prodavateljima | Obveza |
| Podaci na razini prodavatelja | Dimenzija seller_id |
Detalj obveze, a ne prihod |
| Provizija platforme | Prihod od provizije | Prihod |
| PDV ili porez na promet | Obveze za porez | Obveza |
| Naknade procesora | Rashodi obrade plaćanja | Rashod |
| Rezerve prodavatelja | Obveza po osnovi rezervi | Ovisno o ugovoru |
| Povrati | Korekcija prihoda ili povrati | Poništava izvorni tretman |
| Povrati sredstava (chargeback) | Gubitak, potraživanje ili naplata od prodavatelja | Ovisno o tome tko snosi gubitak |
| Isplate koje čekaju potvrdu banke | Prijelazni račun isplata prodavateljima | Prijelazni račun |
| Neraspoređeni iznosi | Prijelazni račun (Suspense) | Privremena iznimka |
Svako značajno knjiženje mora sadržavati prodavatelja, narudžbu, grupu isplata (batch), procesor, valutu, pravnu osobu, porezni tretman, vrstu događaja, vanjsku referencu i sve povezane stornirane stavke. Bez toga pomoćna knjiga (subledger) prodavatelja ne može dokazati pojedinačni saldo, a glavna knjiga ne može dokazati ukupni iznos.
Pomoćnu knjigu možete implementirati kao jedan konto obveza po prodavatelju, jedan zbirni konto obveza s dimenzijom seller_id ili kao razdiobu na obveze, rezerve i prijelazni račun isplata. Pristup sa zbirnim kontom i dimenzijama bolje se skalira kada prijeđete prag od nekoliko desetaka prodavatelja. Odaberite model u dogovoru sa svojim računovođom jer pravila zaštite sredstava i lokalni propisi o plaćanju mogu utjecati na način na koji se sredstva moraju prikazivati. Što se tiče mehanike koja stoji iza knjiženja, naš tekst o API-jima dvostavnog knjigovodstva za računovodstvo internetskih tržnica obuhvaća temeljne elemente glavne knjige na kojima počiva ovaj model.
Knjiženje prodaje s odvojenim stavkama prodavatelja i platforme
Uzmimo prodaju putem posrednika: kupac plaća 100 EUR, provizija platforme je 10 EUR, prodavatelj zarađuje 90 EUR. U trenutku kada su provizija i pravo prodavatelja zarađeni:
| Konto | Duguje | Potražuje |
|---|---|---|
| Prijelazni račun procesora plaćanja | 100 EUR | |
| Obveze prema prodavateljima – Prodavatelj A | 90 EUR | |
| Prihod od provizije | 10 EUR |
Važna kontrolna točka: 90 EUR se knjiži na potražnu stranu obveza, a ne prihoda. Platforma priznaje prihod od 10 EUR. To je ishod koji primjer tržnice u standardu ASC 606 predviđa za posrednika, gdje platforma iskazuje svoju proviziju, a ne cjelokupni iznos prodaje prodavatelja.
Ako se porez naplaćuje zasebno, dodajte stavku obveze za porez i umanjite iznos prodavatelja ili platforme u skladu s poreznim zaključkom. Nemojte radi lakšeg snalaženja stapati porez u proviziju ili obvezu prema prodavatelju.
Odvojite naknade procesora od matematike prihoda i obveza
Tri se stvari neprestano miješaju: provizija platforme, naknada procesora i iznos isplate. One su različite i pogađaju različite kontose.
Kupac plaća 100 EUR, provizija je 10 EUR, procesor zadržava 3 EUR.
- Prihod od provizije ostaje 10 EUR ako je tako ugovoreno.
- Naknada procesora od 3 EUR predstavlja rashod.
- Obveza prema prodavatelju iznosi 90 EUR, osim ako ugovor s prodavateljem ne propisuje da prodavatelj snosi trošak obrade plaćanja. Tek se u tom slučaju iznos smanjuje na 87 EUR uz odgovarajući trošak od 3 EUR koji se tereti prodavatelja.
Knjiženjem samo neto iznosa od 97 EUR koji sjeda na bankovni račun jednim potezom brišete bruto prodaju, proviziju i naknadu. Naša referenca za usklađivanje plaćanja ističe istu stvar: rastavite namiru na sastavne dijelove, tretirajte naknade procesora kao rashode i nikada nemojte dopustiti da neto polog zamjenjuje prihod.
Raspoloživost, rezerve i isplate modelirajte kao zasebne događaje
Novac mijenja status nekoliko puta između naplate i namire u gotovini. Svaka promjena zaslužuje vlastito knjiženje, a rezerva nikada nije neobjašnjivo smanjenje prihoda.
Kada raspoloživa sredstva prelaze u rezervu:
| Konto | Duguje | Potražuje |
|---|---|---|
| Obveze prema prodavateljima – Prodavatelj A | 15 EUR | |
| Obveza za rezerve prodavatelja | 15 EUR |
Kada se rezerve oslobode, stornirajte to knjiženje. Ukupna obveza prema prodavatelju se nije promijenila, promijenio se samo njen status. Stripe dokumentira transakcije rezervi koje povećavaju i oslobađaju rezerve, uz prijenose naplate za dugotrajne negativne salde, i zato su za to potrebni prepoznatljivi kontosi umjesto jednostavnog prebijanja stavki.
Isplate imaju svoj dvostupanjski tretman. Prilikom odobrenja:
| Konto | Duguje | Potražuje |
|---|---|---|
| Obveze prema prodavateljima – Prodavatelj A | 90 EUR | |
| Prijelazni račun isplata prodavateljima | 90 EUR |
Prilikom potvrđene namire u banci:
| Konto | Duguje | Potražuje |
|---|---|---|
| Prijelazni račun isplata prodavateljima | 90 EUR | |
| Banka | 90 EUR |
Ako isplata ne uspije, stornirajte prijelazni račun natrag na obveze prema prodavatelju. Isplata predstavlja namiru obveze, a ne rashod. Tretiranje isplate kao rashoda značilo bi dvostruko obračunavanje u odnosu na prodaju kojom je obveza već evidentirana. Stripe odvaja status isplate (pending, in_transit, paid, failed, canceled) i očekivani datum prispijeća od same inicijacije, a ti se datumi ne smiju sažeti u jednu vremensku oznaku.
Podatkovni model od narudžbe do isplate
Pomoćna knjiga radi na temelju događaja, a ne trenutačnog statusa narudžbe u aplikaciji. Svaki događaj koji utječe na prodavatelja ima isti oblik (envelope):
seller_id,event_id,order_idevent_type(prodaja, povrat, povrat sredstava/chargeback, zadržavanje rezerve, oslobađanje rezerve, isplata, korekcija)effective_date,posting_datecurrency,direction,gross,commission,fees,reserverefund_ref/dispute_refpayout_batch_idreversal_ofsource_status,idempotency_key
Iz tih događaja izračunavate zaključni saldo umjesto pohranjivanja promjenjivog polja:
Zaključni saldo prodavatelja
= početni saldo
+ potražne stavke prodavatelja
− dugovne stavke prodavatelja
− isplate
± kretanja rezervi
± korekcije
Svaki vanjski događaj treba imati pouzdan ključ idempotentnosti (idempotency key) kako ponovljeni pokušaji (retries) i dvostruki webhook pozivi ne bi ponovno odobrili sredstva prodavatelju ili izvršili dvostruku isplatu. Uzorci koji funkcioniraju:
- Događaj u dnevniku knjiženja prodavatelja:
seller_id:order_id:event_type:version - Grupa isplata:
processor:payout_id - Događaj procesora:
processor:event_type:processor_event_id
Vlastite smjernice Stripea za webhooke upozoravaju da se dvostruki događaji događaju, stoga otkrivanje dupliciranja nije opcionalno. Proknjižene stavke ostaju nepromjenjive (immutable). Korekcije se provode kroz storno knjiženje uz ispravno knjiženje, a vaš vlastiti oblik događaja nosi poveznicu reversal_of i razlog. Glavna knjiga sadrži knjiženja, a ne tu poveznicu: Nordlet u svojoj API referenci nudi funkcije stvaranja, dohvaćanja i popisa transakcija u dnevniku knjiženja, bez mogućnosti ažuriranja ili brisanja, tako da je korekcija uvijek nova transakcija, a ne uređivanje postojeće.
Povrati i povrati sredstava (chargebacks) uvijek su povezani, nikada ne lebde u zraku
Povrat koji se pojavi u isplati sljedećeg tjedna nikada ne smije postati nova negativna prodaja pridružena toj isplati. Povežite ga s izvornom transakcijom i sačuvajte izvornu raspodjelu sredstava prodavatelju. Ovisno o ugovoru:
- Stornirajte proviziju ako ugovor propisuje da je podložna povratu
- Teretite obveze prema prodavatelju ako prodavatelj snosi trošak povrata
- Teretite konto gubitka platforme ako ga platforma snosi
- Povećajte rezervu dok je spor otvoren, a oslobodite ju ili iskoristite prilikom rješenja
Povrati sredstava (chargebacks) nakon isplate situacija su u kojoj se pojavljuju negativni saldi. Novac prodavatelja već je otišao, pa ga platforma ili naplaćuje iz budućih prihoda ili preuzima gubitak na sebe. Model mora dopuštati negativne salde prodavatelja i definirati pravilo naplate. Izvještavanje Adyena za tržnice prikazuje povrate i povrate sredstava kao zasebne dugovne retke po imatelju računa, što je razina detalja kojoj treba težiti.
Usklađujte po isplatama, a ne mjesečno
Rastavite svaku namiru procesora prije knjiženja i usklađujte svaku isplatu umjesto da zbrajate mjesečne iznose:
Bruto naplate
− povrati
− naknade procesora
− povrati sredstava (chargeback)
± rezerve i korekcije
= neto isplata procesora
Zatim dokažite da se četiri salda slažu za svakog prodavatelja i svaku valutu: pomoćna knjiga prodavatelja, saldo prodavatelja kod procesora, izvještaj o isplati i prijelazni bankovni račun. Kada se razlikuju, klasificirajte razliku (vremenski pomak, nedostajući događaj, dvostruki unos, pogrešna atribucija, kriva valuta, neuspjela isplata, povrat sredstava proknjižen na krive podatke). Prebijanje razlika izravnavanjem način je na koji se pogreške međusobno poništavaju i preživljavaju do sljedećeg zaključka.
Zbrajanje cijelog mjeseca omogućuje vremenskim razlikama da se poništavaju i skriva stvarne propuste. Usklađivanje po isplatama, temeljeno na ID-u isplate i referenci transakcije, umjesto na iznosu i datumu, otkriva te propuste.
Uobičajeni uzroci pogrešaka
| Vrsta pogreške | Zašto je štetna | Kontrolna mjera |
|---|---|---|
| Bruto uplata kupca knjižena kao prihod | Povećava prihod, skriva obvezu prema prodavatelju | Odvojite obvezu i proviziju u trenutku nastanka zarade |
| Knjiženi samo neto depoziti | Gubi se bruto iznos, naknade, povrati, rezerve | Rastavite svaku namiru na sastavne dijelove |
| Isplata proknjižena kao rashod | Pogrešno prikazuje namiru obveze | Teretite obveze prema prodavatelju prilikom isplate |
| Samo jedno polje za saldo prodavatelja | Miješa iznose u obradi, dostupne, rezervirane i isplaćene | Strogo pratite stanja salda |
| Provizija obračunata u trenutku isplate | Prihod prati raspored isplata | Priznajte prihod od provizije kada je zarađen |
| Rezerva tretirana kao smanjenje prihoda | Zamagljuje vremenski raspored i rizik | Zasebno pratite zadržavanje, oslobađanje i iskorištenje |
| Povrat primijenjen na najnoviju isplatu | Remeti povezivanje s narudžbom | Povežite povrat s izvornom transakcijom |
| Uređivanje proknjiženih stavki | Uništava revizijski trag | Stornirajte i ponovno proknjižite |
| Ponovljeni webhook pozivi | Dvostruka odobrenja i isplate | Ključevi idempotentnosti, otkrivanje dupliciranja |
| Usklađivanje samo po iznosu i datumu | Različite stavke se poklapaju | Usklađujte po ID-u isplate, ID-u transakcije, prodavatelju i valuti |
Što bih učinio najprije
Mapirajte tijek novca prije nego što uopće dotaknete kontni plan. Zapišite svaki događaj od naplate sredstava do oslobađanja rezerve i označite koji stvaraju prihod, koji stvaraju obvezu, a koji samo mijenjaju status.
Zatim izgradite jedan cjeloviti tijek i dokažite da je uravnotežen: uobičajena prodaja, djelomični povrat, povrat sredstava nakon isplate, zadržana i oslobođena rezerva te neuspjela isplata. Pokrenite ih s poznatim očekivanim saldima. Ako je kontrolni konto obveza prema prodavateljima jednak zbroju pomoćne knjige, prijelazni račun procesora se slaže s izvještajem o namiri, a bankovni polog se slaže s ID-om isplate, imate funkcionalnu okosnicu.
Uključite zaključavanje razdoblja tek nakon što se prvi mjesec uredno zaključi s nultim saldom prijelaznog računa. Preuranjeno zaključavanje samo zaleđuje pogreške.
Nordlet automatski knjiži namire na ovaj način: provizija platforme ide na prihod od provizije, udio prodavatelja na obveze prema prodavatelju, naknade procesora na rashode obrade plaćanja, a sve što još nije pripisano ide na prijelazni račun. Razdoblja glavne knjige ostaju otvorena sve dok ih izričito ne zaključate, tako da se prvi mjesec može zatvoriti tek kada je prijelazni račun prazan. Stranica s mogućnostima navodi što je sve uključeno.
FAQ
Je li uplata kupca ikada prihod platforme?
Samo za specifična dobra ili usluge kod kojih je platforma nalogodavac (principal). Za prodaju na tržnici gdje je platforma posrednik za robu prodavatelja, prihod je provizija, a udio prodavatelja je obveza. Platforma može biti nalogodavac za uslugu ispunjenja (fulfillment), a posrednik za pripadajuću robu u istoj narudžbi, stoga se procjena vrši po pojedinačnom dobru ili usluzi, a ne po tvrtki.
Trebaju li rezerve smanjivati prihod?
Ne. Rezerva je alokacija vremenskog rasporeda i rizika, a ne korekcija prihoda. Premjestite sredstva s obveza prema prodavateljima na obvezu za rezerve kada ih zadržite i stornirajte kada ih oslobodite. Prihodi i provizije ne ovise o tome je li novac prodavatelja trenutačno u rezervi.
Kako spriječiti dvostruke isplate uzrokovane ponovljenim webhook pozivima?
Pridružite ključ idempotentnosti svakom vanjskom događaju, kao što je processor:payout_id za grupe isplata, i otkrijte dvostruke događaje prilikom zapisivanja. Pružatelji usluga izričito upozoravaju da dolazi do dvostruke isporuke webhook poziva, stoga glavna knjiga mora odbiti drugi pokušaj umjesto da ga ponovno proknjiži.
Može li saldo prodavatelja postati negativan?
Da, i model to mora dopuštati. Povrat sredstava koji pristigne nakon što je prodavatelj već plaćen ostavlja platformi ili potraživanje od prodavatelja ili gubitak koji sama snosi. Suzbijanje negativnih salda samo skriva neevidentiranu obvezu.
Zašto usklađivati svaku isplatu umjesto mjesečnog ukupnog iznosa?
Zato što se vremenske razlike i pogreške poništavaju kada zbrojite mjesec, pa se ukupni iznosi mogu podudarati iako su pojedinačne transakcije pogrešne. Usklađivanje po isplatama, usklađeno prema ID-u isplate i transakcije, otkriva nedostajuće događaje, dvostruka knjiženja i pogrešno pripisane povrate sredstava prije zaključenja.