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.
Dažniausia apskaitos klaida prekyvietėse (marketplaces) yra pirkėjo bendros sumos mokėjimo traktavimas kaip platformos pajamų. Klientas sumoka 100 €, šie pinigai pateka į mokėjimų apdorojimo sistemos sąskaitą, o kas nors visą sumą užregistruoja kaip pardavimus. Knygos kurį laiką sutampa, pajamos atrodo puikiai, o tuomet auditorius paklausia, kur yra įsipareigojimas pardavėjui. Jo nėra, nes pardavėjo 90 € niekada nebuvo užregistruoti kaip gautina ar mokėtiną suma.
Šią problemą reikia spręsti struktūriškai, o ne kosmetiškai. Prekyvietei reikalingas didžiosios knygos (ledger) modelis, kuris nuo pat pirmojo įrašo atskirtų penkias skirtingas pinigų srauto grupes: tranzite esančius klientų pinigus, platformos komisinių pajamas, mokėtinas sumas pardavėjams, mokesčius ir rezervus. Išmokos (payouts) yra šeštasis įvykis, kuris padengia mokėtiną sumą, tačiau pats savaime nėra pajamų ar sąnaudų įvykis. Šiame vadove pateikiami subalansuoti dvejybiniai įrašai ir duomenų modelis, padedantis išlaikyti šias grupes atskiras.
Pradėkite nuo principo ir agento vertinimo
Prieš pradedant galvoti apie bet kokią sąskaitų struktūrą, platforma turi nuspręsti, ką ji parduoda. Pagal ASC 606 standartą tai vertinama kiekvienai konkrečiai prekei ar paslaugai, ir nuo šio atsakymo priklauso, ar pajamos bus skaičiuojamos bendrąja (gross), ar grynąja (net) verte. Platforma vienam srautui gali būti principolas, o kitam – agentas.
Tipinio prekyvietės sandorio, kai parduodami kito asmens daiktai, atveju platforma paprastai yra agentas. Ji pasirūpina, kad pardavėjo prekė pasiektų pirkėją, neprisiima atsargų rizikos, o jos atlygis yra komisinis mokestis. „Deloitte“ principolo ir agento gairės pagal ASC 606 vertinimą grindžia kontrole: atsakomybė už pažado įvykdymą, atsargų rizika ir kainodaros laisvė yra požymiai, o ne kontrolinis sąrašas, pakeičiantis pagrindinį kontrolės vertinimą.
Priežastis, kodėl ši išvada turi būti įtraukta į didžiosios knygos dizainą, o ne tik į vidaus atmintinę, yra ta, kad ji lemia kiekvieną vėlesnį įrašą. Jei platforma yra agentas, pardavėjo dalis tampa įsipareigojimu nuo pat jos uždirbimo momento. Jei platforma yra principolas vykdymo (fulfillment) arba garantijos paslaugose, ši dalis yra platformos pajamos. Išsaugokite šią išvadą kaip duomenis:
principal_agent_rolespecified_good_or_servicecommission_rule_idcontrol_assessment_versioneffective_from/effective_to
Auditorius, po dvejų metų žiūrėdamas į grynojo komisinio mokesčio eilutę, turi matyti, kodėl nebuvo naudojama bendroji suma. Kaip pažymi „BillingPlatform“ straipsnyje apie ASC 606 principolą ir agentą, etiketė „prekyvietė“ neišsprendžia klausimo. Jį išsprendžia kontrolės analizė.
Apibrėžkite pardavėjo balansą prieš rašydami nors vieną žurnalo taisyklę
„Pardavėjo balansas“ nėra vienas skaičius. Pardavėjas gali turėti gerą istoradinį balansą, bet neturėti jokių lėšų išmokėjimui, nes pinigai vis dar yra laukiami arba laikomi rezerve. Sujungę šias būsenas į vieną, klaidingai ataskaitose parodysite, ką pardavėjas gali atsiimti ir ką platforma jam vis dar skolinga.
Bent jau sekite šias būsenas:
- Laukiančios (Pending): uždirbtos arba surinktos, bet dar netinkamos išmokėjimui
- Galimos (Available): tinkamos išmokėjimui pagal platformos taisykles
- Rezervuotos (Reserved): sulaikytos numatomiems pinigų grąžinimams, ginčams ar pretenzijoms (chargebacks)
- Išmokėtos (Paid out): pervesttos arba pateiktos atsiskaitymui
- Neigiamos (Negative): suma, kurią pardavėjas skolingas, išieškoma iš būsimų įplaukų
- Laikinos (Suspense): gautos, bet pardavėjas ar apskaitos būdas dar nenustatyti
Mokėjimų paslaugų teikėjai šį skirstymą jau naudoja savo modeliuose. „Stripe“ kiekvieną prijungtą paskyrą dalija į laukiančią ir galimą balansus, o tam tikriems neigiamiems pardavėjų balansams palaiko platformos lygio rezervinį balansą. Jei mokėjimų apdorojimo sistema jas skiria, didžioji knyga taip pat turi jas skirti, antraip suderinimo operacijos niekada nesutaps.
Sąskaitų planas ir svarbūs analitiniai požymiai (dimensions)
Tinkama pradinė struktūra atskiria lėšų kliringo sąskaitas, įsipareigojimus ir pajamas bei kiekviename svarbiame įraše priskiria pardavėjo požymį.
| Paskirtis | Sąskaita arba požymis | Traktavimas |
|---|---|---|
| Mokėjimų tarpininko lėšos, laukiančios atsiskaitymo | Mokėjimų tarpininko kliringas | Kliringo turtas |
| Banke gautas tarpininko išmokėjimas | Bankas | Turtas |
| Pardavėjo uždirbama, bet nesumokėta suma | Mokėtinos sumos pardavėjams | Įsipareigojimas |
| Pardavėjo lygmens detalizacija | seller_id požymis |
Įsipareigojimo detalė, ne pajamos |
| Platformos komisinis mokestis | Komisinės pajamos | Pajamos |
| PVM arba pardavimo mokestis | Mokėtinas PVM | Įsipareigojimas |
| Tarpininko mokesčiai | Mokėjimų apdorojimo sąnaudos | Sąnaudos |
| Pardavėjų rezervai | Rezervo įsipareigojimas | Priklauso nuo sutarties |
| Pinigų grąžinimai | Kontra-pajamos arba grąžinimai | Panaikina pradinį įrašą |
| Ginčai (chargebacks) | Nuostolis, gautina suma arba išieškojimas iš pardavėjo | Priklauso, kas prisiima nuostolį |
| Išmokos, laukiančios banko patvirtinimo | Pardavėjų išmokų kliringas | Kliringo sąskaita |
| Nepaskirstytos sumos | Laikinoji sąskaita | Laikina išimtis |
Kiekvienas svarbus įrašas turėtų turėti šiuos atributus: pardavėją, užsakymą, išmokų paketą, tarpininką, valiutą, juridiniu subjektu, mokesčių taikymą, įvykio tipą, išorinį numerį ir nuorodą į bet kokį panaikinimą. Be jų pardavėjų subliudžeris negali pagrįsti atskiro balanso, o didžioji knyga negali pagrįsti bendros sumos.
Subliudžerį galite įgyvendinti kaip vieną įsipareigojimų sąskaitą kiekvienam pardavėjui, vieną bendrą mokėtinų sumų sąskaitą su seller_id požymiu arba paskirstydami tarp mokėtinų sumų, rezervų ir išmokų kliringo. Agreguotas metodas su požymiais geriau plečiasi, kai pasiekiate kelis dešimtmečius pardavėjų. Pasirinkite modelį kartu su savo buhalteriu, nes lėšų apsaugos taisyklės ir vietiniai mokėjimų reglamentai gali turėti įtakos tam, kaip lėšos privalo būti atvaizduotos. Įrašu mechaniką aprašo mūsų straipsnis dvejybinės didžiosios knygos API prekyvietių apskaitai, apimantis pagrindinius knygos elementus, kuriais remiasi šis modelis.
Užregistruokite pardavimą atskiromis pardavėjo ir platformos eilutėmis
Paimkime agento sandorį: klientas sumoka 100 €, platformos komisinis mokestis yra 10 €, pardavėjas uždirba 90 €. Momentu, kai komisinis mokestis ir pardavėjo teisė į lėšas yra uždirbami:
| Sąskaita | Debetas | Kreditas |
|---|---|---|
| Mokėjimų tarpininko kliringas | 100 € | |
| Mokėtinos sumos pardavėjui – A pardavėjas | 90 € | |
| Komisinės pajamos | 10 € |
Svarbi kontrolė: 90 € kredituoja įsipareigojimą, o ne pajamas. Platforma pripažįsta 10 €. Tai yra rezultatas, kurį pasiekia ASC 606 prekyvietės pavyzdys agentui, kai platforma pripažįsta savo komisinį mokestį, o ne visą pardavėjo pardavimų sumą.
Jei mokesčiai surenkami atskirai, pridėkite mokėtinų mokesčių eilutę ir sumažinkite pardavėjo arba platformos sumą pagal mokesčių teisinį vertinimą. Nesuplakite mokesčių į komisinį mokestį ar pardavėjo mokėtiną sumą dėl patogumo.
Laikykite tarpininko mokesčius atskirai nuo pajamų ir mokėtinų sumų matematikos
Trys dalykai nuolat painiojami: platformos komisinis mokestis, tarpininko mokestis ir išmokos suma. Jie yra skirtingi ir patenka į skirtingas sąskaitas.
Klientas sumoka 100 €, komisinis mokestis yra 10 €, tarpininkas pasilieka 3 €.
- Komisinės pajamos išlieka 10 €, jei toks yra susitarimas sutartyje.
- 3 € tarpininko mokestis yra sąnaudos.
- Mokėtina suma pardavėjui yra 90 €, nebent sutartyje numatyta, kad tarpininko mokestį dengia pardavėjas. Tik tokiu atveju ji sumažėja iki 87 €, pridedant atitinkamą 3 € mokestį, nurašytą pardavėjui.
Registruojant tik grynąją 90 € sumą, kuri atkeliauja į banką, vienu ypu panaikinamas bendras pardavimas, komisinis mokestis ir mokestis. Mūsų mokėjimų suderinimo vadovas nurodo tą patį: išskaidykite atsiskaitymą, traktuokite tarpininko mokesčius kaip sąnaudas ir niekada neleiskite gryniajam indėliui atstoti pajamų.
Modeliuokite lėšų prieinamumą, rezervus ir išmokas kaip atskirus įvykius
Pinigų statusas pasikeičia kelis kartus nuo jų gavimo iki galutinio atsiskaitymo. Kiekvienas perėjimas nusipelno savo įrašo, o rezervas niekada nėra nepaaiškintas pajamų sumažinimas.
Kai galimos lėšos perkeliamos į rezervą:
| Sąskaita | Debetas | Kreditas |
|---|---|---|
| Mokėtinos sumos pardavėjui – A pardavėjas | 15 € | |
| Pardavėjo rezervo įsipareigojimas | 15 € |
Kai rezervas atšaukiamas, atlikite atvirkštinį įrašą. Pardavėjo bendras įsipareigojimas nepasikeitė, pasikeitė tik jo statusas. „Stripe“ dokumentuoja rezervo operacijas, kurios didina ir atleidžia rezervus, bei lėšų surinkimo pervedimus ilgalaikiams neigiamiems balansams padengti, todėl tam reikia atpažįstamų sąskaitų, o ne vieno bendro užskaitos įrašo.
Išmokoms taikomas dviejų žingsnių procesas. Patvirtinimo metu:
| Sąskaita | Debetas | Kreditas |
|---|---|---|
| Mokėtinos sumos pardavėjui – A pardavėjas | 90 € | |
| Pardavėjų išmokų kliringas | 90 € |
Patvirtinus atsiskaitymą banke:
| Sąskaita | Debetas | Kreditas |
|---|---|---|
| Pardavėjų išmokų kliringas | 90 € | |
| Bankas | 90 € |
Jei išmoka nepavyksta, grąžinkite kliringo sumą atgal į mokėtinas sumas pardavėjui. Išmoka yra įsipareigojimo padengimas, o ne sąnaudos. Traktavimas kaip sąnaudų dvigubai atskaičiuotų sumą nuo pardavimo, kuris jau užregistravo mokėtiną sumą. „Stripe“ skiria išmokos statusą (pending, in_transit, paid, failed, canceled) ir numatomą gavimo datą nuo inicijavimo, ir šios datos neturėtų būti sujungiamos į vieną laiko žymą.
Užsakymo iki išmokos duomenų modelis
Subliudžeris veikia remdamasis įvykiais, o ne programos dabartine užsakymo būsena. Kiekvienas pardavėją veikiantis įvykis turi tą pačią struktūrą:
seller_id,event_id,order_idevent_type(sale, refund, chargeback, reserve_hold, reserve_release, payout, adjustment)effective_date,posting_datecurrency,direction,gross,commission,fees,reserverefund_ref/dispute_refpayout_batch_idreversal_ofsource_status,idempotency_key
Pagal šiuos įvykius apskaičiuojate uždarymo balansą, o ne saugote keičiamą lauką:
Pardavėjo uždarymo balansas
= atidarymo balansas
+ pardavėjo kreditai
− pardavėjo debetai
− išmokos
± rezervo judėjimai
± koregavimai
Kiekvienas išorinis įvykis turi turėti patvarų pasikartojimo raktą (idempotency key), kad pakartotiniai bandymai ir pasikartojantys internetiniai pranešimai (webhooks) dukart nekredituotų pardavėjo ir dukart neišmokėtų pinigų. Veikiantys šablonai:
- Pardavėjo žurnalo įvykis:
seller_id:order_id:event_type:version - Išmokų paketas:
processor:payout_id - Tarpininko įvykis:
processor:event_type:processor_event_id
„Stripe“ žiniatinklio pranešimų rekomendacijos įspėja, kad pasikartojantys įvykiai nutinka, todėl dublikatų aptikimas nėra pasirinktinis. Paskelbti įrašai lieka nekintami. Koregavimai atliekami per atvirkštinį įrašą ir pataisytą įrašą, o jūsų paties įvykio struktūra neša reversal_of nuorodą bei priežastį. Didžioji knyga saugo įrašus, o ne tą nuorodą: „Nordlet“ teikia žurnalo operacijų kūrimo, gavimo ir sąrašo funkcijas savo API dokumentacijoje ir neturi atnaujinimo ar ištrynimo funkcijų, todėl koregavimas visada yra nauja operacija, o ne redagavimas.
Pinigų grąžinimai ir ginčai yra susiję, jie niekada nebūna „pakibę“
Pinigų grąžinimas, pasirodantis kitos savaitės išmokoje, niekada neturėtų tapti nauju neigiamu pardavimu, priskirtu tai išmokai. Susiekite jį su pradine operacija ir išsaugokite pradinį pardavėjo paskirstymą. Priklausomai nuo sutarties:
- Panaikinkite komisinį mokestį, jei sutartis numato jo grąžinimą
- Debetuokite mokėtiną sumą pardavėjui, jei grąžinimą dengia pardavėjas
- Debetuokite platformos nuostolių sąskaitą, jei ją dengia platforma
- Padidinkite rezervą, kol ginčas atidartas, o jį išsprendus atleiskite arba panaudokite
Ginčai po išmokėjimo yra momentas, kai atsiranda neigiami balansai. Pardavėjo pinigų jau nebėra, todėl platforma arba išieško juos iš būsimų įplaukų, arba prisiima nuostolį. Modelis privalo leisti neigiamus pardavėjų balansus ir apibrėžti išieškojimo taisyklę. „Adyen“ prekyvietės atskaitomybė rodo, kad pinigų grąžinimai ir ginčai sugeneruoja atskiras debeto eilutes kiekvienam paskyros turėtojui – tai yra tas detalumo lygis, į kurį reikėtų orientuotis.
Suderinkite pagal kiekvieną išmoką, o ne kas mėnesį
Prieš registruodami išskaidykite kiekvieną tarpininko atsiskaitymą ir suderinkite kiekvieną išmoką, o ne sumuokite visą mėnesį:
Bendri mokesčiai
− grąžinimai
− tarpininko mokesčiai
− ginčai (chargebacks)
± rezervai ir koregavimai
= grynoji tarpininko išmoka
Tuomet įrodykite, kad kiekvienam pardavėjui ir valiutai sutampa keturi balansai: pardavėjo subliudžeris, tarpininko pardavėjo balansas, išmokos ataskaita ir banko kliringas. Kai jie skiriasi, klasifikuokite skirtumą (laiko neatitikimas, trūkstamas įvykis, dublikatas, klaidingas priskyrimas, neteisinga valiuta, nepavykęs išmokėjimas, ginčas, priskirtas netam asmeniui). Skirtumų užskaitymas yra būdas, kaip klaidos kompensuoja viena kitą ir išgyvena iki kito uždarymo.
Pilno mėnesio sumavimas leidžia laiko skirtumams panaikinti vienas kitą ir paslepia tikrus lūžius. Atitinkantis išmokų derinimas, paremtas išmokos ID ir operacijos nuoroda, o ne suma ir data, juos pagauna.
Dažniausios gedimo formos
| Gedimo forma | Kodėl tai kenkia | Kontrolė |
|---|---|---|
| Bendras kliento mokėjimas užregistruotas kaip pajamos | Dirbtinai padidina pajamas, paslepia pardavėjo įsipareigojimą | Uždirbimo metu atskirkite mokėtiną sumą ir komisinį mokestį |
| Užregistruoti tik grynieji indėliai | Prarandamos bendros sumos, mokesčiai, grąžinimai, rezervai | Išskaidykite kiekvieną atsiskaitymą |
| Išmoka įtraukta į sąnaudas | Neteisingai atvaizduoja įsipareigojimo padengimą | Debetuokite mokėtiną sumą pardavėjui išmokant |
| Vienas pardavėjo balanso laukas | Sumaišo laukiančius, galimus, rezervuotus, išmokėtus | Aiškiai sekite balanso būsenas |
| Komisinis mokestis apskaičiuojamas išmokėjimo metu | Pajamos seka išmokėjimo grafiką | Pripažinkite komisinį mokestį jam užsidirbus |
| Rezervas traktuojamas kaip pajamų sumažinimas | Užtemdo laiką ir riziką | Sulaikymą, atleidimą ir sunaudojimą sekite atskirai |
| Grąžinimas pritaikytas vėliausiai išmokai | Pažeidžia užsakymo priskirimą | Susiekite grąžinimą su pradine operacija |
| Paskelbtų įrašų redagavimas | Sunaikina audito pėdsaką | Atlikite atvirkštinį ir pakartotinį įrašą |
| Pakartoti internetiniai pranešimai (webhooks) | Dubliuoti kreditai ir išmokos | Pasikartojimo raktai, dublikatų aptikimas |
| Suderinta tik pagal sumą ir datą | Skirtingi elementai susiduria | Derinkite pagal išmokos ID, operacijos ID, pardavėją, valiutą |
Ką daryčiau pirmiausia
Nubraižykite pinigų srautą prieš liesdami sąskaitų planą. Užsirašykite kiekvieną įvykį nuo pinigų gavimo iki rezervo atleidimo ir pažymėkite, kurie sukuria pajamas, kurie sukuria įsipareigojimą, o kurie tik perkelia statusą.
Tuomet sukurkite vieną pilną ciklą nuo pradžios iki pabaigos ir įrodykite, kad jis subalansuotas: įprastą pardavimą, dalinį grąžinimą, ginčą po išmokėjimo, sulaikytą ir atleistą rezervą bei nepavykusį išmokėjimą. Paleiskite juos su žinomais tikėtinais balansais. Jei mokėtinų sumų pardavėjams kontrolinė sąskaita lygia subliudžerių sumai, tarpininko kliringas sutampa su atsiskaitymo ataskaita, o banko indėlis sutampa su išmokos ID, turite veikiantį stuburą.
Įjunkite laikotarpio užrakinimą tik po to, kai pirmasis mėnuo užsidaro švariai su tuščia laikinąja sąskaita. Per ankstyvas užrakinimas tik užšaldo klaidas.
„Nordlet“ registruoja atsiskaitymus pagal šiuos principus automatiškai: platformos komisinis mokestis keliauja į komisinių pajamas, pardavėjo dalis – į mokėtinas sumas pardavėjui, tarpininko mokesčiai – į mokėjimų apdorojimo sąnaudas, o viskas, kas nepriskirta – į laikinąją sąskaitą. Didžiosios knygos laikotarpiai lieka atviri, kol jų aiškiai neužrakinate, todėl pirmąjį mėnesį galima uždaryti, kai laikinoji sąskaita tampa tuščia. Funkcijų puslapyje pateikiamas funkcijų sąrašas.
D.U.K.
Ar pirkėjo mokėjimas kada nors yra platformos pajamos?
Tik už konkrečias prekes ar paslaugas, kuriose platforma yra principolas. Agento prekyvietės pardavimo pardavėjo prekėms atveju pajamos yra komisinis mokestis, o pardavėjo dalis yra įsipareigojimas. Platforma tame pačiame užsakyme vykdymo paslaugoms gali būti principolas, o pagrindinėms prekėms – agentas, todėl vertinimas atliekamas kiekvienai konkrečiai prekei ar paslaugai, o ne visai įmonei iš karto.
Ar rezervai turėtų sumažinti pajamas?
Ne. Rezervas yra laiko ir rizikos paskirstymas, o ne pajamų koregavimas. Kai sulaikote lėšas, perkelkite jas iš mokėtinų sumų pardavėjui į rezervo įsipareigojimą, o jas atleisdami – atlikite atvirkštinį įrašą. Pajamoms ir komisiniams neturi įtakos tai, ar pardavėjo pinigai šiuo metu yra rezervuoti.
Kaip sustabdyti pasikartojančias išmokas dėl pakartotinių žiniatinklio pranešimų bandymų?
Kiekvienam išoriniam įvykiui priskirkite pasikartojimo raktą (idempotency key), pavyzdžiui, processor:payout_id išmokų paketams, ir įrašant aptikkite pasikartojančius įvykius. Teikėjai aiškiai įspėja, kad pasikartojantys žiniatinklio pranešimai nutinka, todėl didžioji knyga turi atmesti antrąjį bandymą, o ne registruoti jį iš naujo.
Ar pardavėjo balansas gali tapti neigiamas?
Taip, ir modelis privalo tai leisti. Ginčas (chargeback), kuris pasiekia sistemą po to, kai pardavėjui jau buvo sumokėta, palieka platformą arba su gautina suma iš pardavėjo, arba su nuostoliu, kurį ji prisiima. Neigiamų balansų slėpimas tiesiog paslepia neužregistruotą prievolę.
Kodėl verta derinti kiekvieną išmoką atskirai, o ne mėnesio sumą?
Nes sumuojant mėnesį laiko skirtumai ir klaidos susinaikina, todėl bendros sumos gali sutapti, nors atskiros operacijos yra neteisingos. Išmokų derinimas pagal išmokos ir operacijos ID iškelia į paviršių trūkstamus įvykius, dublikatus ir neteisingai priskirtus ginčus dar prieš uždarymą.