Turupõhise müüja alamraamatud: tulu vs. ostvõlad
Praktiku juhend kliendi raha, platvormi vahendustasu, müüjate ostuvõlgade, reservide ja väljamaksete eraldamiseks tasakaalus kannete ning toimiva tellimusest-väljamseni andmemudeli abil.
Kõige levinum viga turuplatvormi raamatupidamises on ostja kogumakse käsitlemine platvormi tuluna. Klient maksab 100 eurot, see 100 eurot laekub makseteenuse pakkuja kontole ja keegi kirjendab kogu summa müügiks. Raamatupidamine on mõnda aega tasakaalus, tulunumbrid näevad head välja ja siis küsib audiitor, kus on müüja kohustus. Seda pole, sest müüjale kuuluvat 90 eurot ei kajastatud kunagi võlgnevusena.
Lahendus on struktuurne, mitte kosmeetiline. Turuplats vajab pearaamatu mudelit, mis eraldab esimesest kandest alates viis eraldi fondi: transiidis olev kliendi raha, platvormi vahendustasust teenitud tulu, müüjate ostuvõlad, teenustasud ja reservid. Väljamaksed on kuues sündmus, mis likvideerib ostuvõla, olemata ise tulu- või kuluandmed. See juhend näitab tasakaalus kandeid ja andmemudelit, mis hoiavad need fondid üksteisest lahus.
Alustage põhimõtte ja agendi rolli analüüsist
Enne kui ükski kontostruktuur loeb, peab platvorm otsustama, mida ta müüb. Standardi ASC 606 kohaselt hinnatakse seda iga määratletud kauba või teenuse kaupa ning vastus määrab, kas tulu kajastatakse brutona või netona. Platvorm võib ühe rahavoo puhul olla põhimõte (principal) ja teise puhul agent.
Tüüpilise turuplatsi müügi korral, kus müüakse müüja kaupa, on platvorm tavaliselt agent. Ta korraldab müüja toote jõudmise ostjani, ei võta endale laoriski ning tema tasuks on vahendustasu. Deloitte'i juhend põhimõtte ja agendi rolli kohta standardi ASC 606 alusel seab testi keskmesse kontrolli: vastutus lubaduse täitmise eest, laorisk ja hinnakujunduse vabadus on indikaatorid, mitte kontroll-leht, mis kirjutaks üle tegeliku kontrolli hindamise.
Põhjus, miks see kuulub pearaamatu disaini, mitte ainult märgukirja, on see, et see järeldus mõjutab kõiki järgnevaid kandeid. Kui platvorm on agent, on müüja osa kohustus kohe, kui see on teenitud. Kui platvorm on täitmise või garantiiteenuse puhul põhimõte, on see osa platvormi tulu. Salvestage see järeldus andmetena:
principal_agent_rolespecified_good_or_servicecommission_rule_idcontrol_assessment_versioneffective_from/effective_to
Kontrollija, kes vaatab kaks aastat hiljem netovahendustasu rida, peaks nägema, miks brutosummat ei kasutatud. Nagu BillingPlatform märgib ASC 606 põhimõtte ja agendi rolli kohta, ei otsusta küsimust silt „turuplats“ (marketplace), vaid kontrolli analüüs.
Määratlege müüja saldo enne ühegi raamatupidamiskande reegli kirjutamist
„Müüja saldo“ ei ole üksainus number. Müüjal võib olla tugev ajalooline saldo, kuid Väljamakseks ei pruugi midagi saadaval olla, kuna raha on endiselt ootel või reservis. Kui need olekud ühte sulatada, kajastate valesti seda, mida müüja saab välja võtta ja mida platvorm endiselt võlgneb.
Jälgige vähemalt järgmist:
- Ootel (Pending): teenitud või sisse nõutud, kuid väljamakseks veel kõlbmatu
- Saadaval (Available): platvormi reeglite kohaselt väljamakseks kõlblik
- Reserveeritud (Reserved): kinni peetud oodatavate tagasimaksete, vaidluste või tagasinõuete (chargeback) katteks
- Välja makstud (Paid out): üle antud või arveldamiseks esitatud
- Negatiivne: summa, mida müüja võlgneb ja mis on tulevastest laekumistest sissenõutav
- Kontrollkonto / ebamäärane (Suspense): laekunud, kuid müüja või käsitlemisviis on alles määramisel
Makseteenuse pakkujad eristavad seda vahet juba praegu. Stripe eristab iga ühendatud konto puhul ootel ja saadaolevaid saldosid ning hoiab teatud negatiivsete müüjasaldode katteks platvormi tasemel reservsaldo. Kui makseteenuse pakkuja need eristab, peab seda tegema ka pearaamat, muidu ei lähe vastavusse viimine (reconciliation) kunagi klappima.
Kontoplaan ja olulised dimensioonid
Toimiv algstruktuuri hoidja hoiab arvelduskontod (clearing accounts), kohustused ja tulud lahus ning kannab igal olulisel kandel müüja dimensiooni.
| Eesmärk | Konto või dimensioon | Käsitlemine |
|---|---|---|
| Arveldamist ootavad makseteenuse pakkuja vahendid | Makseteenuse pakkuja arvelduskonto | Nõue / arveldusvara |
| Panka laekunud makseteenuse pakkuja väljamakse | Pank | Vara |
| Teenitud, kuid maksmata müüja summa | Müüjate ostuvõlad | Kohustus |
| Müügipõhine detail | seller_id dimensioon |
Kohustuse detail, mitte tulu |
| Platvormi vahendustasu | Vahendustasust teenitud tulu | Tulu |
| Käibemaks või müügimaks | Maksuvõlg | Kohustus |
| Makseteenuse pakkuja tasud | Maksete töötlemise kulu | Kulu |
| Müüja reservid | Reservkohustus | Lepingust sõltuv |
| Tagasimaksed | Tulukorrigeerimine või tagasimaksed | Pöörab esialgse käsitluse ümber |
| Tagasinõuded (chargeback) | Kahjum, nõue või müüjalt sissenõudmine | Sõltub sellest, kes kannab kahjumi |
| Pangakinnitust ootavad väljamaksed | Müüja väljamaksete arvelduskonto | Arvelduskonto |
| Jaotamata summad | Kontrollkonto (Suspense) | Ajutine erand |
Iga oluline kanne peab sisaldama müüjat, tellimust, väljamakse partiid, makseteenuse pakkujat, valuutat, juriidilist isikut, maksustamise viisi, sündmuse tüüpi, välisviidet ja kõiki tagasipööramise linke. Ilma nendeta ei saa müüja alamraamat tõestada üksikut saldot ja pearaamat ei saa tõestada kogusummat.
Alamraamatu saab rakendada ühe kohustuste kontona iga müüja kohta, ühe koond-ostuvõlgade kontona, kus seller_id on dimensioon, või jagatuna ostuvõla, reservi ja väljamaksete arvelduskonto vahel. Koondkontode ja dimensioonide lähenemine skaleerub paremini, kui teil on juba mitukümmend müüjat. Valige mudel koos oma raamatupidajaga, kuna turvareeglid ja kohalikud maksemäärused võivad mõjutada seda, kuidas vahendeid tuleb esitleda. Kandeid puudutava mehaanika jaoks vaadake meie artiklit kahekordse kirjendamise alamraamatu API-de kohta turuplatsi raamatupidamises, millel see mudel põhineb.
Kirjendage müük eraldi müüja ja platvormi ridadega
Võtame agendimüügi: klient maksab 100 eurot, platvormi vahendustasu on 10 eurot, müüja teenib 90 eurot. Vahendustasu ja müüja nõude teenimise hetkel:
| Konto | Deebet | Kreedit |
|---|---|---|
| Makseteenuse pakkuja arvelduskonto | €100 | |
| Müüja ostuvõlg – Müüja A | €90 | |
| Vahendustasust teenitud tulu | €10 |
Oluline kontroll: 90 eurot kreeditseeritakse kohustusena, mitte tuluna. Platvorm kajastab tulu 10 eurot. See on tulemus, milleni ASC 606 turuplatsi näide agendi puhul jõuab, kus platvorm kajastab oma vahendustasu, mitte müüja kogu müügisummat.
Kui maksu kogutakse eraldi, lisage maksuvõla rida ja vähendage müüja või platvormi summat vastavalt maksualasele järeldusele. Ärge suruge maksu mugavuse huvides vahendustasusse või müüja ostuvõlgnikesse.
Hoidke makseteenuse pakkuja tasud tulu- ja ostuvõla matemaatikast eemal
Kolme asja aetakse pidevalt segamini: platvormi vahendustasu, makseteenuse pakkuja tasu ja väljamakse summa. Need on erinevad ja mõjutavad erinevaid kontosid.
Klient maksab 100 eurot, vahendustasu on 10 eurot, makseteenuse pakkuja peab kinni 3 eurot.
- Vahendustasust teenitud tulu jääb 10 euroks, kui see on lepingus nii ette nähtud.
- 3-eurone makseteenuse pakkuja tasu on kulu.
- Müüja ostuvõlg on 90 eurot, välja arvatud juhul, kui müügileping sätestab, et müüja kannab töötlemistasu. Ainult siis langeb see 87 eurole koos vastava 3-eurose müüjalt debiteeritud tasuga.
Ainult panka laekunud netosumma (97 eurot) kirjendamine kustutab üheainsa liigutusega brutomüügi, vahendustasu ja tasu. Meie maksete vastavusse viimise viide toob välja sama punkti: jagage arveldus osadeks, käsitlege makseteenuse pakkuja tasusid kuludena ja ärge kunagi laske netolaekumisel asendada tulu.
Käsitlege saadavust, reserve ja väljamakseid eraldi sündmustena
Raha vahetab kätt mitu korda enne kinnitatud sularajaks või kontoraha saamist. Iga üleminek väärib oma kannet ja reserv ei ole kunagi põhjendamatu kärbe tuludest.
Kui saadaolevad vahendid liiguvad reservi:
| Konto | Deebet | Kreedit |
|---|---|---|
| Müüja ostuvõlg – Müüja A | €15 | |
| Müüja reservikohustus | €15 |
Kui reserv vabastatakse, pöörake kanne ümber. Müüja kogukohustus ei ole muutunud, vaid selle staatus on muutunud. Stripe dokumenteerib reservitehinguid, mis suurendavad ja vabastavad reserve, lisaks kogumiskandeid pikaajaliste negatiivsete saldode jaoks, mistõttu on vaja eristatavaid kontosid, mitte ühteainsat tasaarvelduse kannet.
Väljamaksetel on oma kahe etapi käsitlus. Kinnitamisel:
| Konto | Deebet | Kreedit |
|---|---|---|
| Müüja ostuvõlg – Müüja A | €90 | |
| Müüja väljamaksete arvelduskonto | €90 |
Kinnitatud pangaarvelduse korral:
| Konto | Deebet | Kreedit |
|---|---|---|
| Müüja väljamaksete arvelduskonto | €90 | |
| Pank | €90 |
Kui väljamakse ebaõnnestub, pöörake arvelduskonto kanne tagasi müüja ostuvõlaks. Väljamakse on kohustuse kustutamine, mitte kulu. Selle käsitlemine kuluna topeltarvestab müüki, mille puhul ostuvõlg oli juba kajastatud. Stripe eristab väljamakse staatust (pending, in_transit, paid, failed, canceled) ja eeldatavat saabumiskuupäeva algatamisest ning need kuupäevad ei tohiks sulanduda üheks ajatempliks.
Tellimusest-väljamakseni andmemudel
Alamraamat toimib sündmuste, mitte rakenduse praeguse tellimuse staatuse alusel. Iga müüjat mõjutav sündmus kannab endas sama ümbrikku:
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
Nendest sündmustest arvutatakse lõppsaldot, mitte ei salvestata muudetavat välja:
Müüja lõppsaldo
= algsaldo
+ müüja kreeditid
− müüja deebetid
− väljamaksed
± reservi liikumised
± parandused
Iga väline sündmus vajab kordumatut identsusvõtit (idempotency key), et korduskatsed ja dubleeritud veebikonksud (webhooks) ei krediteeriks müüjat topelt ega teeks topeltväljamakset. Mustrid, mis töötavad:
- Müüja raamatupidamiskande sündmus:
seller_id:order_id:event_type:version - Väljamakse partii:
processor:payout_id - Makseteenuse pakkuja sündmus:
processor:event_type:processor_event_id
Stripe'i enda veebikonksu juhised hoiatavad, et duplikaatsündmused on tavalised, mistõttu duplikaatide tuvastamine ei ole vabatahtlik. Postitatud kanded jäävad muutumatuks. Parandused tehakse tagasipööramise kande ja parandatud kande kaudu ning just teie sündmuse ümbrik kannab endas reversal_of viidet ja põhjust. Pearaamat hoiab kandeid, mitte seda viidet: Nordlet pakub oma API viiteseadistuses pearaamatukannete loomist, pärimist ja loetlemist ning ei võimalda nende muutmist ega kustutamist, mistõttu parandus on alati uus tehing, mitte olemasoleva muutmine.
Tagasimaksed ja tagasinõuded viitavad algsele tehingule, need ei hõlju kunagi eikellegimaal
Tagasimakse, mis ilmub järgmise nädala väljamakses, ei tohi kunagi muutuda uueks negatiivseks müügiks, mis on selle väljamakse külge seotud. Linkige see algsele tehingule ja säilitage algne müüja jaotus. Sõltuvalt lepingust:
- Pöörake vahendustasu ümber, kui leping näeb ette selle tagastamise võimaluse
- Debiteerige müüja ostuvõlga, kui tagasimakse kulud kannab müüja
- Debiteerige platvormi kahjumikontot, kui platvorm kannab selle
- Suurendage vaidluse ajal reservi, vabastage või kasutage see vaidluse lahendamisel
Tagasinõuded (chargebacks) pärast väljamakset on koht, kus tekivad negatiivsed saldod. Müüja raha on juba läinud, nii et platvorm kas nõuab selle sisse tulevastest vahenditest või neelab kahjumi alla. Mudel peab lubama negatiivseid müüjasaldosid ja määratlema sissenõudmise reegli. Adyeni turuplatseraportid näitavad tagasimakseid ja tagasinõudeid loomas eraldi deebetridu kontoomaniku kohta, mis ongi sihtpunktiks olev detailsuse tase.
Viige vastavusse iga väljamakse, mitte iga kuu kaupa
Jaotage iga makseteenuse pakkuja arveldus enne postitamist osadeks ja viige vastavusse iga väljamakse eraldi, selle asemel et koondada terve kuu:
Brutolaekumised
− tagasimaksed
− makseteenuse pakkuja tasud
− tagasinõuded
± reservid ja korrektsioonid
= netomakseteenuse pakkuja väljamakse
Seejärel tõestage, et iga müüja ja valuuta puhul klapivad neli saldot: müüja alamraamat, makseteenuse pakkuja müüjasaldo, väljamaksete raport ja panga arvelduskonto. Nende erinevuste ilmnemisel liigitage need (ajastus, puuduv sündmus, duplikaat, vale omistamine, vale valuuta, ebaõnnestunud väljamakse, valele osapoolele postitatud tagasinõue). Erinevuste lihtne tasaarveldamine on viis, kuidas vead üksteist kompenseerivad ja elavad edasi järgmise perioodi lõpuni.
Terve kuu koondamine võimaldab ajastusvigadel üksteist nullida ja varjab tõelisi vajakajäämisi. Väljamaksepõhine sobitamine, mis põhineb väljamakse ID-l ja tehinguviitel, mitte summal ja kuupäeval, aitab need üles leida.
Tavalised veamustrid
| Veamuster | Miks see on kahjulik | Kontroll |
|---|---|---|
| Kliendi brutomakse postitatud tuluna | Paisutab tulu, varjab müüja kohustust | Eraldage ostuvõlg ja vahendustasu teenimise hetkel |
| Postitatud on ainult netolaekumised | Kaotab brutomüügi, tasud, tagasimaksed, reservid | Jaotage iga arveldus osadeks |
| Väljamakse kajastatud kuluna | Kajastab kohustuse kustutamist valesti | Debiteerige väljamakse korral müüja ostuvõlga |
| Üksainus müüja saldo väli | Segab ootel, saadaval, reserveeritud ja makstud summad | Jälgige saldo olekuid eraldi |
| Vahendustasu arvutatud väljamakse hetkel | Tulu järgib väljamaksete graafikut | Kajastage vahendustasu selle teenimise hetkel |
| Reservi käsitletud tulukärkena | Varjab ajastust ja riski | Jälgige hoidmist, vabastamist ja kasutamist eraldi |
| Tagasimakse rakendatud viimasele väljamaksele | Lõhub tellimuse seosed | Linkige tagasimakse algsele tehingule |
| Postitatud kannete muutmine | Hävitab auditeeritavuse jälje | Pöörake ümber ja postitage uuesti |
| Korduvsaadetud veebikonksud | Topeltkrediidid ja -väljamaksed | Identsusvõtmed, duplikaatide tuvastamine |
| Sobitamine ainult summa ja kuupäeva alusel | Erinevad kaubad põrkuvad kokku | Sobitage väljamakse ID, tehingu ID, müüja ja valuuta alusel |
Mida ma teeksin esimesena
Kaardistage rahavoog enne kontoplaani puudutamist. Kirjutage üles iga sündmus alates makse laekumisest kuni reservi vabastamiseni ja märkige üles, millised loovad tulu, millised kohustuse ja millised liigutavad ainult staatust.
Seejärel ehitage üles üks otsast lõpuni kulgev voog ja tõestage, et see on tasakaalus: tavaline müük, osaline tagasimakse, tagasinõue pärast väljamakset, kinni peetud ja vabastatud reserv ning ebaõnnestunud väljamakse. Käivitage need teadaolevate oodatud saldodega. Kui müüja ostuvõla kontrollkonto võrdub alamraamatute summaga, makseteenuse pakkuja arveldus seostub arveldusaruandega ja pangadeposiit seostub väljamakse ID-ga, on teil olemas toimiv selgroog.
Lülitage perioodi lukustamine sisse alles siis, kui esimene kuu on puhtalt suletud ja kontrollkontol pole jääke. Liiga vara lukustamine lihtsalt külmutab vead.
Nordlet postitab arveldused nende põhimõtete kohaselt karbist välja: platvormi vahendustasu läheb vahendustasutuludesse, müüja osa müüja ostuvõlaks, makseteenuse pakkuja tasud maksete töötlemise kuludesse ja kõik, mida pole veel omistatud, kontrollkontole. Pearaamatu perioodid püsivad avatuna seni, kuni te need selgesõnaliselt lukustate, nii et esimese kuu saab sulgeda kohe, kui kontrollkontol pole jääke. Funktsioonide leht loetleb kaasasolevad võimalused.
FAQ
Kas kliendi makse on kunagi platvormi tulu?
Ainult teatud kaupade või teenuste puhul, kus platvorm on põhimõte (principal). Müüja kaupade agendipõhise turuplatsi müügi korral on tulu vahendustasu ja müüja osa on kohustus. Platvorm võib olla samas tellimuses täitmisteenuse puhul põhimõte ja aluskauba puhul agent, seega tehakse hinnang määratletud kauba või teenuse, mitte ettevõtte kohta.
Kas reservid peaksid tulusid vähendama?
Ei. Reserv on ajastuse ja riski jaotamine, mitte tulude korrigeerimine. Kui summad kinni peetakse, kantakse vahendid müüja ostuvõlast reservikohustusse ja vabastamisel pööratakse see ümber. Tulu ja vahendustasu ei mõjuta see, kas müüja raha on praegu reserveeritud.
Kuidas peatada veebikonksude korduskatsetest tulenevad topeltväljamaksed igale väljamaksele?
Lisage igale välisele sündmusele identsusvõti (idempotency key), näiteks processor:payout_id väljamakse partiide jaoks, ja tuvastage duplikaatsündmused kirjutamisel. Teenusepakkujad hoiatavad selgesõnaliselt, et veebikonksude topeltkättetoimetamisi esineb, mistõttu peab pearaamat teise katse tagasi lükkama, selle asemel et seda uuesti postitada.
Kas müüja saldo võib minna negatiivseks?
Jah, ja mudel peab seda lubama. Tagasinõue (chargeback), mis saabub pärast müüjale tasumist, jätab platvormile kas nõude müüja vastu või kahjumi, mille platvorm peab katma. Negatiivsete saldode varjamine lihtsalt peidab raamatupidamises kajastamata kohustust.
Miks teha vastavusse viimine iga väljamakse, mitte igakuise kogusumma järgi?
Kuna ajastuse erinevused ja vead nullivad kuu koondamisel üksteist ära, võivad summad klappida, kuigi üksikud tehingud on valed. Väljamaksepõhine vastavusse viimine, mis on seotud väljamakse ja tehingu ID-dega, toob puuduvad sündmused, duplikaadid ja valesti omistatud tagasinõuded enne sulgemist nähtavale.