Prekyvietės pardavėjų analitinė apskaita: pajamos ir įsipareigojimai

Praktinis vadovas, kaip atskirti klientų pinigus, platformos komisinius, pardavėjų įsipareigojimus, rezervus ir išmokėjimus, naudojant subalansuotus žurnalo įrašus bei veikiantį „nuo užsakymo iki išmokėjimo“ duomenų modelį.

Dažniausia klaida prekyvietės (marketplace) apskaitoje yra pirkėjo bruto mokėjimo traktavimas kaip platformos pajamų. Klientas sumoka €100, tie €100 įkrenta į mokėjimų apdorotojo sąskaitą ir kažkas visą šią sumą užregistruoja kaip pardavimą. Knygose kurį laiką viskas sutampa, pajamos atrodo puikiai, o tada auditorius paklausia, kur yra įsipareigojimai pardavėjui. Jų nėra, nes pardavėjo €90 niekada nebuvo užregistruoti kaip mokėtina suma.

Sprendimas yra struktūrinis, o ne kosmetinis. Prekyvietei reikalingas didžiosios knygos modelis, kuris nuo pat pirmojo įrašo atskiria penkis skirtingus srautus: tranzite laikomus klientų pinigus, platformos komisinių pajamas, įsipareigojimus pardavėjams, mokesčius ir rezervus. Išmokėjimai (payouts) yra šeštasis įvykis, kuris apmoka įsipareigojimą, o ne atskiras pajamų ar sąnaudų įvykis. Šiame vadove parodomi subalansuoti dvejybiniai įrašai ir duomenų modelis, padedantis šiuos srautus išlaikyti atskirus.

Pradėkite nuo sprendimo: pagrindinis atstovas ar tarpininkas (principal versus agent)

Prieš pradedant planuoti sąskaitų struktūrą, platforma turi nuspręsti, ką ji parduoda. Pagal ASC 606, tai vertinama kiekvienai konkrečiai prekei ar paslaugai, o atsakymas lemia, ar pajamos yra bruto, ar neto. Platforma gali būti pagrindinis atstovas (principal) viename sraute ir tarpininkas (agent) kitame.

Tipiško pardavimo prekyvietėje atveju, kai parduodamos pardavėjo prekės, platforma paprastai yra tarpininkas. Ji suorganizuoja pardavėjo produkto pristatymą pirkėjui, neprisiima atsargų rizikos, o jos atlygis yra komisiniai. Deloitte principal-versus-agent guidance under ASC 606 šį testą apibrėžia per kontrolės prizmę: atsakomybė už pažado įvykdymą, atsargų rizika ir kainodaros laisvė yra tik indikatoriai, o ne kontrolinis sąrašas, nustelbiantis esminį kontrolės vertinimą.

Tai turi atsispindėti didžiosios knygos dizaine, o ne tik atmintinėje, nes šis sprendimas nulemia kiekvieną tolesnį įrašą. Jei platforma yra tarpininkas, pardavėjo dalis tampa įsipareigojimu tą akimirką, kai ji uždirbama. Jei platforma yra pagrindinis atstovas vykdymo ar garantinio aptarnavimo paslaugai, ši dalis yra platformos pajamos. Saugokite šį sprendimą kaip duomenis:

principal_agent_role
specified_good_or_service
commission_rule_id
control_assessment_version
effective_from / effective_to

Tikrintojas, po dvejų metų žiūrėdamas į neto komisinių eilutę, turėtų matyti, kodėl nebuvo naudotas bruto metodas. Kaip pažymi BillingPlatform notes on ASC 606 principal vs agent, vien „prekyvietės“ etiketė neatsako į šį klausimą. Atsakymą duoda kontrolės analizė.

Prieš kurdami žurnalo taisykles, apibrėžkite pardavėjo balansą

„Pardavėjo balansas“ nėra vienas skaičius. Pardavėjas per visą laikotarpį gali turėti puikų balansą, tačiau neturėti lėšų, kurias būtų galima išmokėti, nes pinigai vis dar laukia patvirtinimo arba yra rezervuoti. Sutraukus šias būsenas į vieną, iškraipysite duomenis apie tai, kiek pardavėjas gali išsiimti ir kiek platforma vis dar skoloje.

Mažiausiai turėtumėte sekti šias sumas:

Pending: uždirbta arba surinkta, bet dar negalima išmokėti
Available: galima išmokėti pagal platformos taisykles
Reserved: sulaikyta dėl numatomų grąžinimų, ginčų ar ginčijamų lėšų nuskaitymų (chargebacks)
Paid out: pervesta arba pateikta apmokėjimui (settlement)
Negative: suma, kurią pardavėjas skolingas, išskaitoma iš būsimų pajamų
Suspense: gauta, bet pardavėjas ar apdorojimo būdas dar nenustatytas

Mokėjimų paslaugų teikėjai jau modeliuoja šį skirtumą. Stripe atskiria kiekvienos prijungtos sąskaitos laukiančius (pending) ir turimus (available) likučius, taip pat išlaiko rezervuotą balansą platformos lygmeniu tam tikriems neigiamiems pardavėjų likučiams. Jei mokėjimų procesorius juos atskiria, didžioji knyga privalo daryti tą patį, kitaip suderinimas niekada nesutaps.

Sąskaitų planas ir svarbiausios dimensijos

Veikianti pradinė struktūra laiko tarpines sąskaitas (clearing accounts), įsipareigojimus ir pajamas atskirai, o kiekvienam reikšmingam įrašui priskiria pardavėjo dimensiją.

Paskirtis	Sąskaita ar dimensija	Traktavimas
Procesoriaus lėšos, laukiančios apmokėjimo	Mokėjimų procesoriaus tarpinė sąskaita	Tarpinis turtas
Banke gautas išmokėjimas iš procesoriaus	Bankas	Turtas
Pardavėjo uždirbta, bet neišmokėta suma	Mokėtinos sumos pardavėjams	Įsipareigojimas
Pardavėjo lygio detalizacija	`seller_id` dimensija	Įsipareigojimo detalizacija, ne pajamos
Platformos komisiniai	Komisinių pajamos	Pajamos
PVM arba pardavimo mokestis	Mokėtini mokesčiai	Įsipareigojimas
Procesoriaus mokesčiai	Mokėjimų apdorojimo sąnaudos	Sąnaudos
Pardavėjo rezervai	Rezervų įsipareigojimai	Priklauso nuo sutarties
Grąžinimai	Pajamas mažinanti sąskaita (contra-revenue) arba grąžinimai	Anuliuoja pirminį traktavimą
Ginčijami mokėjimai (chargebacks)	Nuostolis, gautina suma arba išskaitoma iš pardavėjo	Priklauso nuo to, kam tenka nuostolis
Išmokėjimai, laukiantys banko patvirtinimo	Pardavėjų išmokėjimų tarpinė sąskaita	Tarpinė sąskaita
Nepriskirtos sumos	Neaiškių sumų sąskaita (suspense)	Laikinoji išimtis

Kiekvienas reikšmingas įrašas turėtų turėti pardavėjo, užsakymo, išmokėjimų paketo, procesoriaus, valiutos, juridinio asmens, mokesčių traktavimo, įvykio tipo, išorinės nuorodos ir bet kokios atšaukimo nuorodos dimensijas. Be šių duomenų pardavėjų analitinė apskaita (subledger) negalės įrodyti individualaus balanso, o didžioji knyga – bendros sumos.

Analitinę apskaitą galite realizuoti kaip atskirą įsipareigojimų sąskaitą kiekvienam pardavėjui, vieną bendrą mokėtinų sumų sąskaitą su seller_id kaip dimensija, arba padalinti tarp mokėtinų sumų, rezervų ir išmokėjimų tarpinių sąskaitų. Bendros sąskaitos su dimensija metodas geriau mastelizuojasi, kai peržengiate kelių dešimčių pardavėjų ribą. Modelį pasirinkite kartu su savo buhalteriu, nes lėšų apsaugos (safeguarding) taisyklės ir vietiniai mokėjimų reglamentai gali turėti įtakos tam, kaip lėšos turi būti pateikiamos. Daugiau informacijos apie įrašų mechaniką rasite mūsų straipsnyje double-entry ledger APIs for marketplace accounting, kur aprašomi didžiosios knygos primityvai, kuriais remiasi šis modelis.

Registruokite pardavimą atskiriant pardavėjo ir platformos eilutes

Imkime pardavimą per tarpininką: klientas sumoka €100, platformos komisiniai yra €10, pardavėjas uždirba €90. Momentu, kai uždirbami komisiniai ir atsiranda pardavėjo teisė į lėšas:

Sąskaita	Debetas	Kreditas
Mokėjimų procesoriaus tarpinė sąskaita	€100
Mokėtinos sumos pardavėjui — Pardavėjas A		€90
Komisinių pajamos		€10

Svarbiausias kontrolės aspektas: €90 kredituoja įsipareigojimą, o ne pajamas. Platforma pripažįsta €10. Būtent tokį rezultatą tarpininkui numato ASC 606 prekyvietės pavyzdys, kai platforma pripažįsta savo komisinius, o ne visą pardavėjo pardavimo sumą.

Jei mokesčiai renkami atskirai, pridėkite mokėtinų mokesčių eilutę ir atitinkamai sumažinkite pardavėjo ar platformos sumą, remdamiesi mokestiniu vertinimu. Neprijunkite mokesčių prie komisinių ar mokėtinų sumų pardavėjui vien dėl patogumo.

Neįtraukite procesoriaus mokesčių į pajamų ir mokėtinų sumų skaičiavimus

Nuolat painiojami trys dalykai: platformos komisiniai, procesoriaus mokesčiai ir išmokama suma. Jie yra skirtingi ir registruojami skirtingose sąskaitose.

Klientas sumoka €100, komisiniai yra €10, procesorius pasilieka €3.

Komisinių pajamos lieka €10, jei taip numatyta sutartyje.
€3 procesoriaus mokestis yra sąnaudos.
Mokėtina suma pardavėjui yra €90, nebent pardavėjo sutartyje nurodyta, kad jis apmoka apdorojimo mokestį. Tik tuomet suma sumažėja iki €87, priskiriant pardavėjui €3 mokestį.

Užregistravus tik neto sumą – į banką įkrentančius €97, vienu ypu sunaikinamas bruto pardavimas, komisiniai ir mokestis. Mūsų payment reconciliation reference pabrėžia tą patį: išskaidykite apmokėjimą (settlement), traktuokite procesoriaus mokesčius kaip sąnaudas ir niekada nelaikykite neto indėlio pajamomis.

Modeliuokite lėšų prieinamumą, rezervus ir išmokėjimus kaip atskirus įvykius

Tarp lėšų nuskaitymo ir faktinio apmokėjimo (settled cash), pinigų statusas keičiasi kelis kartus. Kiekvienas perėjimas nusipelno atskiro įrašo, o rezervas niekada neturi būti tiesiog nepaaiškinamas pajamų sumažinimas.

Kai prieinamos lėšos perkeliamos į rezervą:

Sąskaita	Debetas	Kreditas
Mokėtinos sumos pardavėjui — Pardavėjas A	€15
Pardavėjo rezervų įsipareigojimai		€15

Kai rezervas atleidžiamas, anuliuokite jį. Bendra įsipareigojimų pardavėjui suma nepasikeitė – pasikeitė tik jos statusas. Stripe dokumentacijoje aprašomos rezervo operacijos, kurios padidina ir atleidžia rezervus, bei lėšų surinkimo pervedimai esant ilgalaikiams neigiamiems likučiams, todėl tam būtinos atpažįstamos sąskaitos, o ne vienas užskaitos (netting) įrašas.

Išmokėjimams (payouts) taikomas atskiras dviejų žingsnių procesas. Patvirtinimo metu:

Sąskaita	Debetas	Kreditas
Mokėtinos sumos pardavėjui — Pardavėjas A	€90
Pardavėjų išmokėjimų tarpinė sąskaita		€90

Patvirtinus bankinį apmokėjimą:

Sąskaita	Debetas	Kreditas
Pardavėjų išmokėjimų tarpinė sąskaita	€90
Bankas		€90

Jei išmokėjimas nepavyksta, grąžinkite tarpinės sąskaitos įrašą atgal į mokėtinas sumas pardavėjui. Išmokėjimas yra įsipareigojimo padengimas, o ne sąnaudos. Jo traktavimas kaip sąnaudų reikštų dvigubą skaičiavimą, nes jis jau buvo užregistruotas kaip mokėtina suma pardavimo metu. Stripe atskiria išmokėjimo statusą (pending, in_transit, paid, failed, canceled) ir numatomą gavimo datą nuo iniciavimo datos, ir šios datos neturėtų būti suplaktos į vieną laiko žymą.

„Nuo užsakymo iki išmokėjimo“ duomenų modelis

Analitinė apskaita veikia remiantis įvykiais, o ne dabartiniu užsakymo statusu programoje. Kiekvienas su pardavėju susijęs įvykis turi tą patį karkasą:

seller_id, event_id, order_id
event_type (sale, refund, chargeback, reserve_hold, reserve_release, payout, adjustment)
effective_date, posting_date
currency, direction, gross, commission, fees, reserve
refund_ref / dispute_ref
payout_batch_id
reversal_of
source_status, idempotency_key

Remdamiesi šiais įvykiais skaičiuojate pabaigos likutį, užuot saugoję jį kaip keičiamą lauką:

Seller closing balance
= opening balance
+ seller credits
− seller debits
− payouts
± reserve movements
± corrections

Kiekvienam išoriniam įvykiui reikalingas ilgalaikis idempotencijos raktas, kad dėl pakartotinių bandymų ir pasikartojančių „webhook“ užklausų pardavėjas nebūtų kredituojamas dukart ir išmokėjimas nebūtų atliktas du kartus. Veikiantys šablonai:

Pardavėjo žurnalo įvykis: seller_id:order_id:event_type:version
Išmokėjimų paketas: processor:payout_id
Procesoriaus įvykis: processor:event_type:processor_event_id

Pati Stripe „webhook“ dokumentacija įspėja, kad pasikartojantys įvykiai nutinka, todėl dublikatų aptikimas nėra pasirinktinas dalykas. Užregistruoti įrašai lieka nekintami. Korekcijos atliekamos per anuliuojantį įrašą ir patikslintą įrašą, o reversal_of nuorodą bei priežastį saugo jūsų pačių įvykio karkasas. Didžiojoje knygoje saugomi įrašai, o ne ta nuoroda: Nordlet savo API reference leidžia sukurti, gauti ir atvaizduoti žurnalo operacijas, bet ne jas atnaujinti ar ištrinti, todėl korekcija visada yra nauja operacija, o ne redagavimas.

Grąžinimai ir ginčijami mokėjimai susiejami, jie niekada „neplaukioja“

Pinigų grąžinimas, kuris atsiranda kitos savaitės išmokėjime, niekada neturėtų tapti nauju, su tuo išmokėjimu susietu, neigiamu pardavimu. Susiekite jį su pradine operacija ir išsaugokite pradinį pardavėjo priskyrimą. Priklausomai nuo sutarties:

Anuliuokite komisinius, jei pagal sutartį jie yra grąžinami
Debetuokite mokėtinas sumas pardavėjui, jei grąžinimo išlaidas padengia pardavėjas
Debetuokite platformos nuostolių sąskaitą, jei tai padengia platforma
Padidinkite rezervą, kol ginčas atviras, ir jį atleiskite arba panaudokite išsprendus ginčą

Po išmokėjimo įvykstantys ginčijami mokėjimai (chargebacks) yra ta vieta, kur atsiranda neigiami likučiai. Pardavėjo pinigai jau išmokėti, todėl platforma juos išskaito iš būsimų pajamų arba prisiima nuostolį. Modelis turi leisti neigiamus pardavėjų likučius ir apibrėžti išieškojimo taisyklę. Adyen prekyvietės ataskaitose pinigų grąžinimai ir ginčijami mokėjimai atvaizduojami kaip atskiros debeto eilutės kiekvienam sąskaitos turėtojui – būtent tokio detalumo ir reikėtų siekti.

Suderinkite kiekvieną išmokėjimą atskirai, o ne visą mėnesį

Prieš registruodami išskaidykite kiekvieną procesoriaus apmokėjimą ir suderinkite kiekvieną išmokėjimą, užuot agregavę viso mėnesio duomenis:

Gross charges
− refunds
− processor fees
− chargebacks
± reserves and adjustments
= net processor payout

Tuomet įsitikinkite, kad keturi likučiai kiekvienam pardavėjui ir valiutai sutampa: pardavėjo analitinė apskaita, procesoriaus pateikiamas pardavėjo balansas, išmokėjimų ataskaita ir banko tarpinės operacijos (clearing). Kai jie skiriasi, klasifikuokite skirtumą (laiko neatitikimas, trūkstamas įvykis, dublikatas, neteisingas priskyrimas, neteisinga valiuta, nepavykęs išmokėjimas, ginčijamas mokėjimas, priskirtas ne tai šaliai). Skirtumų užskaitymas tėra būdas paslėpti klaidas, kurios persikelia į kitą apskaitos uždarymo periodą.

Viso mėnesio sumų agregavimas leidžia laiko neatitikimams vienam kitą panaikinti ir paslepia tikras klaidas. Suderinimas pagal atskirus išmokėjimus, susietas su išmokėjimo ID ir operacijos nuoroda, o ne pagal sumą ir datą, padeda jas aptikti.

Dažniausios klaidų situacijos

Klaidos situacija	Kodėl tai kenkia	Kontrolė
Bruto kliento mokėjimas užregistruotas kaip pajamos	Dirbtinai padidina pajamas, paslepia įsipareigojimus pardavėjui	Išskaidykite mokėtinas sumas ir komisinius uždirbimo įvykio metu
Užregistruojami tik neto indėliai	Prarandama informacija apie bruto sumas, mokesčius, grąžinimus, rezervus	Išskaidykite kiekvieną apmokėjimą
Išmokėjimas užregistruotas kaip sąnaudos	Iškraipo įsipareigojimų apmokėjimą	Debetuokite mokėtinas sumas pardavėjui išmokėjimo metu
Vienas pardavėjo balanso laukas	Suplaka laukiančias, turimas, rezervuotas ir išmokėtas sumas	Tiksliai sekite balanso būsenas
Komisiniai skaičiuojami išmokėjimo metu	Pajamų pripažinimas priklauso nuo išmokėjimų tvarkaraščio	Pripažinkite komisinius, kai jie uždirbami
Rezervas traktuojamas kaip pajamų sumažinimas	Paslepia laiko ir rizikos aspektus	Atskirai sekite sulaikymą, atleidimą, panaudojimą
Pinigų grąžinimas pritaikytas vėliausiam išmokėjimui	Sugriauna priskyrimą užsakymui	Susiekite pinigų grąžinimą su pradine operacija
Užregistruotų įrašų redagavimas	Sunaikina audito seką	Anuliuokite ir užregistruokite iš naujo
Pakartotinai atsiųsti „webhook“	Dvigubi kreditavimai ir išmokėjimai	Idempotencijos raktai, dublikatų aptikimas
Suderinimas tik pagal sumą ir datą	Susiduria skirtingi elementai	Derinkite pagal išmokėjimo ID, operacijos ID, pardavėją, valiutą

Ką padaryčiau pirmiausia

Prieš liesdami sąskaitų planą, susidarykite pinigų srautų žemėlapį. Surašykite kiekvieną įvykį nuo mokėjimo nuskaitymo iki rezervo atleidimo ir pažymėkite, kurie iš jų sukuria pajamas, kurie sukuria įsipareigojimą, o kurie tik keičia statusą.

Tada sukurkite vieną pilną eigą ir įsitikinkite, kad ji subalansuota: normalus pardavimas, dalinis pinigų grąžinimas, ginčijamas mokėjimas po išmokėjimo, rezervo sulaikymas ir atleidimas bei nepavykęs išmokėjimas. Paleiskite juos naudodami žinomus tikėtinus likučius. Jei pardavėjų mokėtinų sumų kontrolinė sąskaita sutampa su analitinės apskaitos knygos (subledger) suma, procesoriaus tarpinė sąskaita atitinka apmokėjimų ataskaitą, o banko indėlis susietas su išmokėjimo ID, vadinasi, turite veikiantį pagrindą.

Periodų užrakinimą įjunkite tik po to, kai pirmasis mėnuo švariai uždaromas su nuliniu neaiškių sumų sąskaitos (suspense) likučiu. Per ankstyvas užrakinimas tiesiog užfiksuos klaidas.

Nordlet standartinėje versijoje registruoja apmokėjimus pagal šiuos principus: platformos komisiniai keliauja į komisinių pajamas, pardavėjo dalis – į mokėtinas sumas pardavėjui, procesoriaus mokesčiai – į mokėjimų apdorojimo sąnaudas, o visa kita, kas dar nepriskirta, – į neaiškių sumų sąskaitą. Didžiosios knygos periodai lieka atviri, kol jų patys aiškiai neužrakinate, todėl pirmąjį mėnesį galima uždaryti, kai neaiškių sumų sąskaita yra tuščia. features page sąraše rasite, kas įtraukta į sistemą.

D.U.K.

Ar pirkėjo mokėjimas kada nors yra platformos pajamos?

Tik už tas konkrečias prekes ar paslaugas, kuriose platforma yra pagrindinis atstovas (principal). Pardavimo per prekyvietę kaip tarpininką (agent) atveju, pajamos yra komisiniai, o pardavėjo dalis yra įsipareigojimas. Platforma tame pačiame užsakyme gali būti pagrindinis atstovas vykdymo paslaugai ir tarpininkas pačioms prekėms, todėl vertinimas atliekamas pagal konkrečią prekę ar paslaugą, o ne pagal įmonę.

Ar rezervai turėtų mažinti pajamas?

Ne. Rezervas yra laikotarpio ir rizikos paskirstymas, o ne pajamų koregavimas. Perkelkite lėšas iš mokėtinų sumų pardavėjui į rezervų įsipareigojimus, kai jas sulaikote, ir atšaukite įrašą, kai jas atleidžiate. Pajamoms ir komisiniams neturi įtakos tai, ar pardavėjo pinigai šiuo metu yra rezervuoti.

Kaip išvengti dublikuotų išmokėjimų dėl pakartotinių „webhook“ bandymų?

Kiekvienam išoriniam įvykiui priskirkite idempotencijos raktą, pvz., processor:payout_id išmokėjimų paketams, ir rašymo metu aptikite pasikartojančius įvykius. Paslaugų teikėjai aiškiai įspėja, kad pasitaiko pasikartojančių „webhook“ pristatymų, todėl didžioji knyga privalo atmesti antrąjį bandymą, o ne vėl jį užregistruoti.

Ar pardavėjo balansas gali tapti neigiamas?

Taip, ir modelis privalo tai leisti. Ginčijamas mokėjimas (chargeback), atsirandantis po to, kai pardavėjui jau buvo išmokėta, palieka platformai gautiną sumą iš pardavėjo arba jos prisiimamą nuostolį. Neigiamų likučių slėpimas tiesiog paslepia neužregistruotą įsipareigojimą.

Kodėl derinti kiekvieną išmokėjimą, o ne mėnesio sumą?

Todėl, kad agreguojant mėnesį laiko neatitikimai ir klaidos vienas kitą panaikina, tad bendros sumos gali sutapti, nors atskiros operacijos yra neteisingos. Kiekvieno išmokėjimo suderinimas, susietas su išmokėjimo ir operacijos ID, padeda atskleisti trūkstamus įvykius, dublikatus ir neteisingai priskirtus ginčijamus mokėjimus dar prieš uždarant apskaitos periodą.