Podknjižbe prodajalcev na tržnici: Prihodki proti obveznostiam
Praktični vodnik za ločevanje denarja kupcev, provizije platforme, obveznosti do prodajalcev, rezervacij in izplačil z uravnoteženimi temeljnicami in delujočim podatkovnim modelom od naročila do izplačila.
Najpogostejša napaka v računovodstvu spletnih tržnic je obravnava celotnega plačila kupca kot prihodka platforme. Kupec plača 100 €, ta znesek sede na račun procesorja in nekdo celoten znesek knjiži v prihodke od prodaje. Knjige se nekaj časa ujemajo, prihodki so videti odlično, nato pa revizor vpraša, kje je obveznost do prodajalca. Je ni, ker 90 € prodajalca nikoli ni bilo zabeleženih kot dolgovan znesek.
Rešitev je strukturna, ne le kozmetična. Tržnica potrebuje model glavne knjige, ki že s prvo knjižbo ločuje pet različnih skupin: denar kupcev v pretoku, prihodke od provizije platforme, obveznosti do prodajalcev, provizije in rezervacije. Izplačila so šesti dogodek, ki poravna obveznost, ne pa samostojen prihodek ali odhodek. Ta vodnik prikazuje uravnotežene temeljnice in podatkovni model, ki ohranjata te skupine ločene.
Začnite s sklepom o vlogi glavnega naročnika ali posrednika (principal-versus-agent)
Preden je katera koli kontna struktura pomembna, mora platforma določiti, kaj pravzaprav prodaja. V skladu z MSRP 15 (ASC 606) se to presoja za vsako posamezno blago ali storitev posebej, odgovor pa določa, ali se prihodki knjižijo v bruto ali neto znesku. Platforma je lahko za en tok poslovanja glavni naročnik (principal), za drugega pa posrednik (agent).
Pri tipični prodaji prek tržnice, ko gre za blago prodajalca, je platforma običajno posrednik. Poskrbi, da izdelek prodajalca doseže kupca, ne prevzema tveganja zaloge, njeno nadomestilo pa je provizija. Deloitteova smernica o razmejitvi med glavnim naročnikom in posrednikom po MSRP 15 (ASC 606) presojo opira na nadzor: odgovornost za izpolnitev obljube, tveganje zaloge in svoboda pri določanju cen so kazalniki, ne pa kontrolni seznam, ki bi prevladal nad dejansko presojo nadzora.
Razlog, zakaj to sodi v zasnovo knjigovodstva in ne le v interni dopis, je v tem, da ta sklep narekuje vsako nadaljnje knjižbo. Če je platforma posrednik, je delež prodajalca obveznost v trenutku, ko je prislužen. Če je glavni naročnik za storitev dostave ali garancije, je ta del prihodek platforme. Sklep shranite kot podatke:
principal_agent_rolespecified_good_or_servicecommission_rule_idcontrol_assessment_versioneffective_from/effective_to
Pregledovalec, ki bo čez dve leti gledal neto postavko provizije, mora videti, zakaj se ni uporabil bruto znesek. Kot BillingPlatform opozarja glede presoje po MSRP 15 (ASC 606), oznaka »tržnica« ne reši vprašanja. Analiza nadzora ga reši.
Opredelite stanje prodajalca, preden napišete eno samo pravilo za temeljnice
»Stanje prodajalca« ni ena sama številka. Prodajalec ima lahko odlično skupno stanje, hkrati pa nima ničesar na voljo za izplačilo, ker denar še ni potrjen ali pa je zadržan v rezervi. Če ta stanja zlijete v eno, boste napačno poročali o tem, kaj lahko prodajalec dvigne in kaj platforma še dolguje.
Vsaj sledite naslednjemu:
- V teku (Pending): prisluženo ali zbrano, še ni upravičeno do izplačila
- Na voljo (Available): upravičeno do izplačila v skladu s pravili platforme
- Rezervirano (Reserved): zadržano za kritje pričakovanih vračil, sporov ali zavrnitev plačil (chargebacks)
- Izplačano (Paid out): preneseno ali oddano v poravnavo
- Negativno (Negative): znesek, ki ga prodajalec dolguje in se poravna iz prihodnjih prejemkov
- Prehodni račun (Suspense): prejeto, vendar prodajalec ali obravnava še nista določena
Ponudniki plačilnih storitev to razlikovanje že uporabljajo. Stripe vsak povezani račun ločuje na stanja v teku in razpoložljiva stanja ter ohranja rezervirano stanje na ravni platforme za določena negativna stanja prodajalcev. Če to ločuje procesor, mora to ločevati tudi glavna knjiga, sicer se usklajevanje ne bo nikoli izšlo.
Kontni načrt in dimenzije, ki štejejo
Delujoča začetna struktura ločuje prehodne konte, obveznosti in prihodke ter nosi dimenzijo prodajalca pri vsakem pomembnem knjiženju.
| Namen | Konto ali dimenzija | Obravnava |
|---|---|---|
| Sredstva procesorja, ki čakajo na poravnavo | Prehodni konto plačilnega procesorja | Prehodno sredstvo |
| Izplačilo procesorja na banki | Banka | Sredstvo |
| Znesek prodajalca, ki je zaslužen, but neplačan | Obveznosti do prodajalcev | Obveznost |
| Podrobnosti na ravni prodajalca | Dimenzija seller_id |
Podrobnost obveznosti, ne prihodka |
| Provizija platforme | Prihodki od provizij | Prihodek |
| DDV ali davek na promet | Obveznosti za davek | Obveznost |
| Stroški procesorja | Stroški plačilnega prometa | Odhodek |
| Rezervacije prodajalcev | Obveznosti iz rezervacij | Odvisno od pogodbe |
| Vračila | Zmanjšanje prihodkov ali vračila | Razveljavi prvotno obravnavo |
| Zavrnitve plačil (chargebacks) | Izguba, terjatev ali izterjava od prodajalca | Odvisno od tega, kdo nosi izgubo |
| Izplačila, ki čakajo na potrditev banke | Prehodni konto izplačil prodajalcem | Prehodni konto |
| Nerazporejeni zneski | Prehodni konto (Suspense) | Začasna izjema |
Vsaka pomembna knjižba mora vsebovati prodajalca, naročilo, serijo izplačil, procesor, valuto, pravno osebo, davčno obravnavo, vrsto dogodka, zunanjo sklicno številko in povezavo do storno knjižbe. Brez tega pomožna knjiga prodajalcev ne more dokazati posameznega stanja, glavna knjiga pa ne more dokazati celote.
Pomožno knjigo lahko implementirate kot en konto obveznosti na prodajalca, en zbirni konto obveznosti z dimenzijo seller_id ali pa kot razdelitev na obveznosti, rezervacije in prehodni konto izplačil. Pristop z zbirnim kontom in dimenzijo se bolje obnese, ko prestopite število nekoliko ducat prodajalcev. Model izberite skupaj s svojim računovodjem, saj lahko pravila o varstvu sredstev in lokalna plačilna zakonodaja vplivajo na način izkazovanja sredstev. Mehanika za knjiženji je opisana v našem prispevku o API-jih za dvostavno knjigovodstvo za računovodstvo na spletnih tržnicah, na katerem temelji ta model.
Knjiženje prodaje z ločenimi postavkami za prodajalca in platformo
Vzemimo prodajo prek posrednika: kupec plača 100 €, provizija platforme je 10 €, prodajalec zasluži 90 €. V trenutku, ko sta provizija in upravičenost prodajalca prisluženi:
| Konto | V debet | V kredit |
|---|---|---|
| Prehodni konto plačilnega procesorja | 100 € | |
| Obveznosti do prodajalcev – Prodajalec A | 90 € | |
| Prihodki od provizij | 10 € |
Nadzor, ki šteje: 90 € se knjiži v dobro obveznosti, ne prihodkov. Platforma pripozna 10 €. To je rezultat, ki ga primer tržnice v standardu MSRP 15 (ASC 606) določa za posrednika, kjer platforma pripozna svojo provizijo in ne celotnega zneska prodaje prodajalca.
Če se davek obračuna posebej, dodajte postavko obveznosti za davek in zmanjšajte znesek prodajalca ali platforme v skladu z davčno presojo. Davka ne vključujte v provizijo ali obveznost do prodajalca zaradi poenostavitve.
Ločite stroške procesorja od matematike prihodkov in obveznosti
Tri stvari se nenehno mešajo: provizija platforme, strošek procesorja in znesek izplačila. So različne in bremenijo različne konte.
Kupec plača 100 €, provizija je 10 €, procesor zadrži 3 €.
- Prihodek od provizije ostane 10 €, če tako določa pogodba.
- Strošek procesorja v višini 3 € je odhodek.
- Obveznost do prodajalca je 90 €, razen če pogodba s prodajalcem določa, da stroške obdelave plačil nosi prodajalec. Šele takrat se znesek zniža na 87 €, ob tem pa se prodajalcu zaračuna ustrezen znesek 3 €.
Če knjižite samo neto znesek 97 €, ki prispede na banko, s tem z enim mahom izbrišete bruto prodajo, provizijo in strošek. Naša referenca za usklajevanje plačil poudarja isto: razčlenite poravnavo, stroške procesorja obravnavajte kot odhodke in nikoli ne dovolite, da neto priliv nadomesti prihodek.
Modelirajte razpoložljivost, rezervacije in izplačila kot ločene dogodke
Denar med zajemom in poravnano gotovino večkrat spremeni status. Vsak prehod si zasluži svojo knjižbo, rezervacija pa ni nikoli nepojasnjeno znižanje prihodkov.
Ko se razpoložljiva sredstva premaknejo v rezervacijo:
| Konto | V debet | V kredit |
|---|---|---|
| Obveznosti do prodajalcev – Prodajalec A | 15 € | |
| Obveznosti iz rezervacij za prodajalce | 15 € |
Ko se rezervacija sprosti, jo stornirajte. Celotna obveznost do prodajalca se ni spremenila, spremenil se je njen status. Stripe dokumentira transakcije z rezervacijami, ki povečujejo in sproščajo rezervacije, ter prenose sredstev za pokrivanje dolgotrajnih negativnih stanj. Zato je treba uporabiti prepoznavne konte namesto enotne neto knjižbe.
Izplačila zahtevajo dvstopenjsko obravnavo. Ob odobritvi:
| Konto | V debet | V kredit |
|---|---|---|
| Obveznosti do prodajalcev – Prodajalec A | 90 € | |
| Prehodni konto izplačil prodajalcem | 90 € |
Ob potrjeni bančni poravnavi:
| Konto | V debet | V kredit |
|---|---|---|
| Prehodni konto izplačil prodajalcem | 90 € | |
| Banka | 90 € |
Če izplačilo ni uspešno, prehodni konto stornirajte nazaj med obveznosti do prodajalcev. Izplačilo je poravnava obveznosti, ne odhodek. Če ga obravnavate kot odhodek, pomeni podvojeno knjiženje glede na prodajo, ki je obveznost že evidentirala. Stripe ločuje status izplačila (pending, in_transit, paid, failed, canceled) in pričakovani datum prihoda od sprožitve, ti datumi pa se ne smejo združiti v en sam časovni žig.
Podatkovni model od naročila do izplačila
Pomožna knjiga deluje na podlagi dogodkov in ne trenutnega stanja naročila v aplikaciji. Vsak dogodek, ki vpliva na prodajalca, nosi isto ovojnico:
seller_id,event_id,order_idevent_type(prodaja, vračilo, zavrnitev plačila, zadržanje rezervacije, sprostitev rezervacije, izplačilo, popravek)effective_date,posting_datecurrency,direction,gross,commission,fees,reserverefund_ref/dispute_refpayout_batch_idreversal_ofsource_status,idempotency_key
Iz teh dogodkov izračunate zaključno stanje in ne shranjujete spremenljivega polja:
Zaključno stanje prodajalca
= začetno stanje
+ dobroimetja prodajalca
− bremenitve prodajalca
− izplačila
± premiki rezervacij
± popravki
Vsak zunanji dogodek potrebuje trajni ključ za preprečevanje podvajanja (idempotency key), da ponovni poskusi in podvojeni spletni kavlji (webhooks) ne pripišejo dobropisa prodajalcu dvakrat ali izvedejo dvojnega izplačila. Vzorci, ki delujejo:
- Dogodek dnevnika prodajalca:
seller_id:order_id:event_type:version - Serija izplačil:
processor:payout_id - Dogodek procesorja:
processor:event_type:processor_event_id
Stripova lastna navodila za spletne kavlje opozarjajo, da prihaja do podvojenih dogodkov, zato zaznavanje podvajanj ni izbirno. Objave v dnevniku ostanejo nespremenljive. Popravki gredo skozi storno knjižbo in popravljeno knjižbo, pri čemer ravno vaša ovojnica dogodka nosi povezavo reversal_of in razlog. Knjiga hrani knjižbe in ne te povezave: Nordlet v svoji tehnični dokumentaciji API-ja ponuja ustvarjanje, pridobivanje in izpis dnevniških transakcij brez možnosti posodabljanja ali brisanja, zato je popravek vedno nova transakcija in ne urejanje obstoječe.
Vračila in zavrnitve plačil se vežejo nazaj in nikoli ne lebdijo v zraku
Vračilo, ki se pojavi v naslednjem tedenskem izplačilu, ne sme nikoli postati sveža negativna prodaja, pripeta na to izplačilo. Povežite ga z izvirno transakcijo in ohranite prvotno dodelitev prodajalcu. Odvisno od pogodbe:
- Stornirajte provizijo, če pogodba določa, da je vračljiva.
- Obremenite obveznosti do prodajalca, če vračilo nosi prodajalec.
- Obremenite konto platformskih izgub, če ga nosi platforma.
- Povečajte rezervacijo, dokler je spor odprt, jo sprostite ali porabite ob rešitvi.
Zavrnitve plačil po izplačilu so trenutek, ko se pojavijo negativna stanja. Denar prodajalca je že izginil, zato platforma ali izterja znesek iz prihodnjih prejemkov ali pa prevzame izgubo. Model mora omogočati negativna stanja prodajalcev in določati pravilo izterjave. Poročila tržnic Adyen prikazujejo vračila in zavrnitve plačil kot ločene bremepisne vrstice na imetnika računa, kar je stopnja podrobnosti, ki jo je treba doseči.
Usklajujte glede na vsako izplačilo in ne mesečno
Razčlenite vsako poravnavo procesorja pred knjiženjem in uskladite vsako izplačilo posebej namesto mesečnega seštevanja:
Bruto bremenitve
− vračila
− stroški procesorja
− zavrnitve plačil (chargebacks)
± rezervacije in popravki
= neto izplačilo procesorja
Nato dokažite, da se štiri stanja ujemajo za vsakega prodajalca in valuto: pomožna knjiga prodajalca, stanje prodajalca pri procesorju, poročilo o izplačilih in bančni prehodni konto. Ko se razlikujejo, razvrstite razliko (časovni zamik, manjkajoč dogodek, podvojitev, napačna pripisava, napačna valuta, neuspešno izplačilo, zavrnitev plačila, knjižena napačni stranki). Medsebojno izničevanje razlik je način, kako napake ostanejo skrite in preživijo do naslednjega zaključka.
Mesečno seštevanje omogoča, da se časovne razlike izničijo, kar prikrije resnične primanjkljaje. Usklajevanje po posameznih izplačilih, vezano na ID izplačila in sklic transakcije ter ne na znesek in datum, te napake odkrije.
Pogoste napake
| Napaka | Zakaj škoduje | Nadzor |
|---|---|---|
| Bruto plačilo kupca knjiženo kot prihodek | Povečuje prihodke, prikriva obveznosti do prodajalca | Ločite obveznost in provizijo ob nastanku |
| Knjižena samo neto nakazila | Izguba podatkov o bruto znesku, provizijah, vračilih in rezervacijah | Razčlenite vsako poravnavo |
| Izplačilo knjiženo kot odhodek | Napačno prikazuje poravnavo obveznosti | Ob izplačilu obremenite obveznosti do prodajalca |
| Eno samo polje za stanje prodajalca | Meša stanja v teku, razpoložljiva, rezervirana in izplačana | Izrecno sledite stanjem salda |
| Provizija izračunana ob izplačilu | Prihodki sledijo urniku izplačil | Pripoznajte provizijo, ko je zaslužena |
| Rezervacija obravnavana kot znižanje prihodkov | Zamegljuje časovni vidik in tveganje | Ločeno sledite zadržanju, sprostitvi in porabi |
| Vračilo uporabljeno pri zadnjem izplačilu | Poruši povezavo z naročilom | Povežite vračilo z izvirno transakcijo |
| Urejanje knjiženih vnosov | Uničuje revizijsko sled | Stornirajte in ponovno knjižite |
| Ponovljeni spletni kavlji (webhooks) | Podvojeni dobropisi in izplačila | Ključi za preprečevanje podvajanja, zaznavanje dvojnikov |
| Ujemanje samo po znesku in datumu | Trčenje različnih postavk | Ujemajte po ID-ju izplačila, ID-ju transakcije, prodajalcu in valuti |
Kaj bi storil najprej
Prej ko se dotaknete kontnega načrta, narišite tok denarja. Zapišite vsak dogodek od zajema plačila do sprostitve rezervacije in označite, kateri ustvarjajo prihodke, kateri obveznosti in kateri le premikajo status.
Nato zgradite en celovit cikel in dokažite, da se izide: običajna prodaja, delno vračilo, zavrnitev plačila po izplačilu, zadržana in sproščena rezervacija ter neuspešno izplačilo. Preizkusite jih z znanimi pričakovanimi stanji. Če je nadzorni konto obveznosti do prodajalcev enak vsoti pomožne knjige, se prehodni konto procesorja ujema s poročilom o poravnavi, bančni polog pa z ID-jem izplačila, imate delujočo hrbtenico.
Zaklepanje obdobja vklopite šele, ko se prvi mesec čisto zaključi z ničelnim stanjem prehodnega konta. Prehitro zaklepanje le zamrzne napake.
Nordlet knjiži poravnave po teh načelih že takoj iz škatle: provizija platforme gre med prihodke od provizij, delež prodajalca med obveznosti do prodajalcev, stroški procesorja med stroške plačilnega prometa, vse, kar še ni razporejeno, pa na prehodni konto. Obdobja v glavni knjigi ostanejo odprta, dokler jih izrecno ne zaklenete, tako da lahko prvi mesec zaprete, ko je prehodni konto prazen. Stran s funkcijami navaja, kaj je vključeno.
FAQ
Ali je plačilo kupca kdaj prihodek platforme?
Samo za tisto specifično blago ali storitve, pri katerih je platforma glavni naročnik (principal). Pri posredniški prodaji blaga prodajalca prek tržnice je prihodek provizija, delež prodajalca pa obveznost. Platforma je lahko glavni naročnik za storitev dostave in hkrati posrednik za osnovno blago v istem naročilu, zato se presoja nanaša na posamezno blago ali storitev in ne na podjetje kot celoto.
Ali naj rezervacije zmanjšujejo prihodke?
Ne. Rezervacija je časovna razporeditev in razporeditev tveganja, ne pa prilagoditev prihodkov. Ko sredstva zadržite, jih prenesite iz obveznosti do prodajalca na obveznosti iz rezervacij, ob sprostitvi pa jih obrnite. Na prihodke in provizijo ne vpliva dejstvo, da je denar prodajalca trenutno rezerviran.
Kako preprečim dvojna izplačila zaradi ponovitev spletnih kavljev (webhooks)?
Vsakemu zunanjemu dogodku dodajte ključ za preprečevanje podvajanja (idempotency key), kot je processor:payout_id za serije izplačil, in ob zapisovanju zaznajte podvojene dogodke. Ponudniki izrecno opozarjajo, da prihaja do dvojne dostave spletnih kavljev, zato mora glavna knjiga zavrniti drugi poskus, namesto da bi ga ponovno knjižila.
Lahko stanje prodajalca postane negativno?
Da, in model to mora omogočati. Zavrnitev plačila (chargeback), ki prispeta po tem, ko je bil prodajalec že izplačan, pusti platformi bodisi terjatev do prodajalca bodisi izgubo, ki jo mora prevzeti. Prikrivanje negativnih stanj samo skriva neevidentirano obveznost.
Zakaj usklajevati vsako izplačilo namesto mesečnega seštevka?
Ker se časovne razlike in napake pri mesečnem seštevanju med seboj izničijo, kar pomeni, da se lahko skupni zneski ujemajo, čeprav so posamezne transakcije napačne. Usklajevanje po posameznih izplačilih, usklajeno z ID-ji izplačil in transakcij, odkrije manjkajoče dogodke, dvojnike in napačno pripisane zavrnitve plačil pred zaključkom obdobja.