Marketplace Seller Subledgers: Revenue vs Payables
Praktická príručka pre oddelenie zákazníckej hotovosti, provízie platformy, záväzkov voči predajcom, rezerv a výplat prostredníctvom vyrovnaných účtovných zápisov a funkčného dátového modelu od objednávky po výplatu.
Najčastejšou chybou v účtovníctve pre trhoviská (marketplace) je zaobchádzanie s hrubou platbou kupujúceho ako s tržbou platformy. Zákazník zaplatí 100 EUR, táto suma pristane v účte platobnej brány a niekto zaúčtuje celú sumu do tržieb. Účtovníctvo chvíľu sedí, tržby vyzerajú skvele, a potom sa audítor spýta, kde je záväzok voči predajcovi. Žiadny tam nie je, pretože 90 EUR pre predajcu nebolo nikdy zaevidované ako dlžná suma.
Riešenie je štrukturálne, nie kozmetické. Trhovisko potrebuje model hlavnej knihy, ktorý od prvej položky oddeľuje päť rôznych peňažných fondov: zákaznícku hotovosť na ceste, tržby z provízií platformy, záväzky voči predajcom, poplatky a rezervy. Výplaty sú šiestou udalosťou, ktorá vyrovnáva záväzok, pričom samy o sebe nie sú výnosovou ani nákladovou udalosťou. Táto príručka ukazuje vyrovnané účtovné zápisy a dátový model, ktoré udržiavajú tieto fondy oddelené.
Začnite záverom o pozícii hlavného účastníka verzus sprostredkovateľa
Skôr než záleží na akejkoľvek štruktúre účtov, platforma musí rozhodnúť, čo vlastne predáva. Podľa štandardu ASC 606 sa to posudzuje pre každý špecifikovaný tovar alebo službu osobitne a tento záver určí, či sú tržby vykazované v hrubom alebo čistom. Platforma môže vystupovať ako hlavný účastník (principal) pre jeden peňažný tok a ako sprostredkovateľ (agent) pre iný.
Pri bežnom predaji na trhovisku, kde ide o tovar predajcu, je platforma zvyčajne sprostredkovateľom. Zabezpečuje, aby sa produkt predajcu dostal ku kupujúcemu, nenese riziko spojené so zásobami a jej odmenou je provízia. Metodika spoločnosti Deloitte k posúdeniu hlavného účastníka verzus sprostredkovateľa podľa ASC 606 stavia toto posúdenie na koncepcii kontroly: zodpovednosť za splnenie záväzku, riziko zásoby a cenová diskrécia sú indikátormi, nie kontrolným zoznamom, ktorý by mal nahradiť primárne posúdenie kontroly.
Dôvod, prečo to patrí do návrhu účtovnej knihy a nielen do internej poznámky, spočíva v tom, že tento záver poháňa každý následný účtovný zápis. Ak je platforma sprostredkovateľom, podiel predajcu je záväzkom v momente, keď naň vznikne nárok. Ak vystupuje ako hlavný účastník pri plnení alebo záručnej službe, táto časť predstavuje tržbu platformy. Uložte tento záver ako dáta:
principal_agent_rolespecified_good_or_servicecommission_rule_idcontrol_assessment_versioneffective_from/effective_to
Kontrolór, ktorý sa po dvoch rokoch pozrie na riadok s čistou províziou, musí vidieť, prečo sa nepoužila hrubá suma. Ako poznamenáva spoločnosť BillingPlatform k téme ASC 606 principal vs agent, označenie „trhovisko“ (marketplace) túto otázku nevyrieši. Vyrieši ju analýza kontroly.
Zadefinujte zostatok predajcu skôr, než napíšete čo i len jedno účtovné pravidlo
„Zostatok predajcu“ nie je jedno číslo. Predajca môže mať výborný celkový zostatok za celú dobu existencie účtu a zároveň nula prostriedkov k dispozícii na výplatu, pretože peniaze sú stále v riešení alebo zadržané v rezerve. Ak tieto stavy zlúčite, budete nesprávne vykazovať, čo si predajca môže vybrať a čo platforma stále dlhuje.
Minimálne sledujte:
- Neuplatnené / čakajúce (Pending): zarobené alebo vyzbierané, ešte nespĺňajúce podmienky na výplatu
- Dostupné (Available): spôsobilé na výplatu podľa pravidiel platformy
- Zadržané / rezervované (Reserved): zadržané proti očakávaným vrátením platieb, sporom alebo spätným platbám (chargebacks)
- Vyplatené (Paid out): prevedené alebo predložené na vyrovnanie
- Záporné (Negative): suma, ktorú predajca dlhuje a je vymáhateľná z budúcich príjmov
- Prechodný účet (Suspense): prijaté, ale predajca alebo spôsob zaúčtovania ešte nie sú určené
Poskytovatelia platieb toto rozlíšenie už používajú. Stripe oddeľuje každý pripojený účet na čakajúci a dostupný zostatok a pre určité záporné zostatky predajcov udržiava rezervný zostatok na úrovni platformy. Ak to platobná brána oddeľuje, účtovná kniha to musí robiť tiež, inak sa odsúhlasenie nikdy neuzavrie.
Účtovná osnova a dôležité dimenzie
Funkčná počiatočná štruktúra udržiava klíringové účty, záväzky a tržby oddelene a prenáša dimenziu predajcu na každý podstatný účtovný zápis.
| Účel | Účet alebo dimenzia | Postup |
|---|---|---|
| Prostriedky v platobnej bráne čakajúce na vyrovnanie | Klíringový účet platobnej brány | Klíringové aktívum |
| Výplata z brány pripísaná na bankový účet | Banka | Aktívum |
| Zarobená, ale nezaplatená suma predajcu | Záväzky voči predajcom | Záväzok |
| Detail na úrovni predajcu | Dimenzia seller_id |
Detail záväzku, nie výnos |
| Provízia platformy | Tržby z provízií | Výnos |
| DPH alebo daň z predaja | Záväzok vo dph / daňový záväzok | Záväzok |
| Poplatky platobnej brány | Náklady na spracovanie platieb | Náklad |
| Rezervy predajcov | Záväzok z rezerv | Závislé od zmluvy |
| Vrátenia platieb (refundácie) | Znižujúce tržby (contra-revenue) alebo refundácie | Zvracia pôvodné zaúčtovanie |
| Spätné platby (chargebacks) | Strata, pohľadávka alebo vymáhanie od predajcu | Závisí od toho, kto znáša stratu |
| Výplaty čakajúce na potvrdenie bankou | Klíringový účet výplat predajcom | Klíringový účet |
| Nezaradené sumy | Prechodný účet (Suspense) | Dočasná výnimka |
Každý podstatný záznam by mal obsahovať predajcu, objednávku, dávku výplat, platobnú bránu, menu, právnickú osobu, daňový režim, typ udalosti, externý odkaz a akýkoľvek odkaz na storno. Bez týchto údajov podvojná analytika predajcu nedokáže preukázať individuálny zostatok a hlavná kniha nedokáže preukázať celkovú sumu.
Podvojnú analytiku (subledger) môžete implementovať ako jeden účet záväzkov na predajcu, jeden súhrnný účet záväzkov s dimenziou seller_id alebo rozdelením na záväzky, rezervy a klíring výplat. Prístup so súhrnným účtom a dimenziami lepšie škáluje, akonáhle prekročíte niekoľko desiatok predajcov. Vyberte si model so svojím účtovníkom, pretože pravidlá ochrany finančných prostriedkov a miestna platobná regulácia môžu ovplyvniť spôsob vykazovania prostriedkov. Mechaniku za týmito zápismi podrobne opisuje náš článok API pre podvojné účtovníctvo v účtovníctve pre trhoviská, na ktorého základoch tento model stojí.
Zaúčtujte predaj so samostatnými riadkami pre predajcu a platformu
Predstavte si sprostredkovateľský predaj: zákazník zaplatí 100 EUR, provízia platformy je 10 EUR, predajca zarobí 90 EUR. V momente, keď vznikne nárok na províziu a pre predajcu:
| Účet | Má dať (Debit) | Dal (Credit) |
|---|---|---|
| Klíringový účet platobnej brány | 100 EUR | |
| Záväzky voči predajcom – Predajca A | 90 EUR | |
| Tržby z provízií | 10 EUR |
Kľúčová kontrola: 90 EUR ide v prospech záväzku, nie výnosov. Platforma vykáže výnos 10 EUR. Toto je výsledok, ktorý dosahuje príklad trhoviska v štandarde ASC 606 pre sprostredkovateľa, kde platforma vykazuje svoju províziu namiesto plnej sumy predaja daného predajcu.
Ak sa daň vyberá osobitne, pridajte riadok daňového záväzku a primerane upravte sumu pre predajcu alebo platformu podľa daňového posúdenia. Nespaájajte daň do provízie alebo záväzkov voči predajcovi len z dôvodu pohodlnosti.
Nezahŕňajte poplatky platobnej brány do výpočtu tržieb a záväzkov
Tri veci sa neustále pletú: provízia platformy, poplatok platobnej brány a suma výplaty. Sú to rôzne položky a smerujú na rôzne účty.
Zákazník zaplatí 100 EUR, provízia je 10 EUR, platobná brána si ponechá 3 EUR.
- Tržby z provízií zostávajú na úrovni 10 EUR, ak to tak stanovuje zmluva.
- Poplatok platobnej brány vo výške 3 EUR je náklad.
- Záväzok voči predajcovi je 90 EUR, pokiaľ zmluva neustanovuje, že poplatok za spracovanie platby znáša predajca. Až vtedy klesne na 87 EUR so zodpovedajúcim poplatkom 3 EUR účtovaným predajcovi.
Zaúčtovaním iba čistej sumy 97 EUR, ktorá dorazí do banky, jedným ťahom vymažete hrubý predaj, províziu aj poplatok. Naša príručka k zmierovaniu platieb (rekoncilácii) zdôrazňuje to isté: rozložte vyrovnanie na drobné, poplatky platobnej brány považujte za náklady a nikdy nedovoľte, aby čistý vklad nahradil tržby.
Modelujte dostupnosť, rezervy a výplaty ako samostatné udalosti
Peniaze menia svoj status medzi inkasom a skutočným vyrovnaním niekoľkokrát. Každý prechod si zaslúži vlastný záznam a rezerva nie je v žiadnom prípade nevysvetleným znížením tržieb.
Keď sa dostupné prostriedky presunú do rezervy:
| Účet | Má dať (Debit) | Dal (Credit) |
|---|---|---|
| Záväzky voči predajcom – Predajca A | 15 EUR | |
| Záväzok z rezervy pre predajcu | 15 EUR |
Keď sa rezerva uvoľní, zaúčtujte opačný zápis. Celkový záväzok voči predajcovi sa nezmenil, zmenil sa len jeho stav. Spoločnosť Stripe dokumentuje transakcie s rezervami, ktoré rezervy zvyšujú a uvoľňujú, spolu s prevodmi na úhradu dlhodobých záporných zostatkov, a preto si to vyžaduje identifikovateľné účty namiesto jediného zápisu čistou sumou.
Výplaty majú vlastný dvojkrokový proces. Pri schválení:
| Účet | Má dať (Debit) | Dal (Credit) |
|---|---|---|
| Záväzky voči predajcom – Predajca A | 90 EUR | |
| Klíringový účet výplat predajcom | 90 EUR |
Pri potvrdení bankového prevodu:
| Účet | Má dať (Debit) | Dal (Credit) |
|---|---|---|
| Klíringový účet výplat predajcom | 90 EUR | |
| Banka | 90 EUR |
Ak výplata zlyhá, stornujte klíringový zápis späť do záväzkov voči predajcovi. Výplata je vyrovnaním záväzku, nie nákladom. Ak by ste ju považovali za náklad, došlo by k duplicitnému zaúčtovaniu oproti predaju, ktorý už záväzok zaevidoval. Stripe oddeľuje stav výplaty (pending, in_transit, paid, failed, canceled) a očakávaný dátum príchodu od samotnej iniciácie, pričom tieto dátumy by sa nemali zlúčiť do jednej časovej pečiatky.
Dátový model od objednávky po výplatu
Analytika funguje na základe udalostí, nie aktuálneho stavu objednávky v aplikácii. Každá udalosť ovplyvňujúca predajcu nesie rovnakú štruktúru:
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
Z týchto udalostí vypočítate konečný zostatok namiesto ukladania meniteľného (mutable) poľa:
Konečný zostatok predajcu
= počiatočný zostatok
+ kredity predajcu
− debety predajcu
− výplaty
± pohyby rezerv
± korekcie
Každá externá udalosť potrebuje stabilný identifikačný kľúč pre zaistenie idempotencie (idempotency key), aby opakovania a duplicitné webhooky nezaznamenali duplicitný kredit predajcovi alebo duplicitnú výplatu. Osvedčené vzory:
- Účtovná udalosť predajcu:
seller_id:order_id:event_type:version - Dávka výplat:
processor:payout_id - Udalosť platobnej brány:
processor:event_type:processor_event_id
Vlastná dokumentácia webhookov spoločnosti Stripe varuje, že duplicitné udalosti sa stávajú, takže detekcia duplicít nie je voliteľná. Zaúčtované položky zostávajú nemenné (immutable). Korekcie prechádzajú cez stornovací zápis plus opravený zápis a práve váš vlastný obal udalosti nesie odkaz reversal_of a dôvod. Hlavná kniha uchováva účtovné zápisy, nie tento odkaz: Nordlet poskytuje operácie vytvorenia, získania a zoznamu pre denníkové transakcie vo svojej API dokumentácii a neponúka žiadnu úpravu ani vymazanie, takže korekcia je vždy novou transakciou namiesto úpravy.
Vrátenie platieb (refundácie) a spätné platby (chargebacks) sa spätne odkazujú, nikdy nie sú vo vzduchu
Refundácia, ktorá sa objaví v budúcotýždňovej výplate, sa nikdy nesmie stať čerstvým záporným predajom pripojeným k tejto výplate. Prepojte ju s pôvodnou transakciou a zachovajte pôvodné rozdelenie pre predajcu. V závislosti od zmluvy:
- Stornujte províziu, ak zmluva stanovuje, že je vrátiteľná
- Zaúčtujte debet na záväzky voči predajcovi, ak refundáciu znáša predajca
- Zaúčtujte debet na účet strát platformy, ak ju znáša platforma
- Zvýšte rezervu počas trvania sporu, uvoľnite ju alebo ju použite pri vyriešení
Spätné platby (chargebacks) po výplate sú miestom, kde vznikajú záporné zostatky. Peniaze predajcu sú už preč, takže platforma ich buď vymáhá z budúcich výnosov, alebo absorbuje stratu. Model musí umožňovať záporné zostatky predajcov a definovať pravidlo pre ich vymáhanie. Reportovanie trhoviska Adyen ukazuje refundácie a spätné platby vytvárajúce samostatné riadky so zostatkom Má dať pre každého držiteľa účtu, čo je úroveň podrobnosti, ktorú treba dosiahnuť.
Robte rekonciláciu na úrovni každej výplaty, nie mesačne
Pred zaúčtovaním rozložte každé vyrovnanie platobnej brány na drobné a odsúhlaste každú výplatu namiesto agregácie za celý mesiac:
Hrubé platby
− refundácie
− poplatky platobnej brány
− spätné platby (chargebacks)
± rezervy a úpravy
= čistá výplata od platobnej brány
Následne overte, či pre každého predajcu a menu súhlasia štyri zostatky: analytika predajcu, zostatok predajcu u platobnej brány, výplatný report a bankový klíring. Keď sa líšia, klasifikujte rozdiel (časový nesúlad, chýbajúca udalosť, duplikát, nesprávne priradenie, nesprávna mena, zlyhaná výplata, spätná platba zaúčtovaná nesprávnej strane). Vzájomné vyrovnávanie rozdielov spôsobuje, že chyby sa navzájom maskujú a prežijú až do ďalšej uzávierky.
Agregácia celého mesiaca umožňuje, aby sa časové rozdiely vyrovnali a skryli skutočné výpadky. Párovanie na úrovni jednotlivých výplat, spárované pomocou ID výplaty a transakčného odkazu namiesto sumy a dátumu, tieto chyby odhalí.
Bežné chybové režimy
| Chybový režim | Prečo je to problém | Kontrola / Riešenie |
|---|---|---|
| Hrubá platba zákazníka zaúčtovaná ako tržba | Umelo navyšuje tržby, skrýva záväzok voči predajcovi | Oddelte záväzok a províziu v momente vzniku nároku |
| Zaúčtované iba čisté vklady | Stráca sa hrubá suma, poplatky, refundácie, rezervy | Rozložte každé vyrovnanie na jednotlivé zložky |
| Výplata zaúčtovaná ako náklad | Nesprávne vykazuje vyrovnanie záväzku | Zaúčtujte Má dať na záväzky voči predajcovi pri výplate |
| Jediné pole pre zostatok predajcu | Mieša čakajúce, dostupné, rezervované a vyplatené prostriedky | Sledujte stavy zostatkov explicitne |
| Provízia vypočítaná v čase výplaty | Tržby sa riadia harmonogramom výplat | Zaúčtujte províziu v momente, keď vznikne nárok |
| Rezerva považovaná za zníženie tržieb | Skresľuje načasovanie a riziko | Sledujte zadržanie, uvoľnenie a spotrebovanie oddelene |
| Refundácia aplikovaná na najnovšiu výplatu | Naruší priradenie k objednávke | Prepojte refundáciu s pôvodnou transakciou |
| Úprava už zaúčtovaných položiek | Ničí auditnú stopu | Stornujte a zaúčtujte znovu |
| Opakované webhooky | Duplicitné kredity a výplaty | Identifikačné kľúče (idempotency keys), detekcia duplicít |
| Párovanie iba podľa sumy a dátumu | Rôzne položky sa zhodujú náhodou | Párujte podľa ID výplaty, ID transakcie, predajcu a meny |
Čo by som urobil ako prvé
Pred dotykom s účtovnou osnovou si namapujte peňažný tok. Zapíšte si každú udalosť od zachytenia platby až po uvoľnenie rezervy a označte, ktoré vytvárajú tržby, ktoré vytvárajú záväzok a ktoré iba menia stav.
Potom vytvorte jeden komplexný tok od začiatku do konca a overte, že sa vyrovná: bežný predaj, čiastočná refundácia, spätná platba po výplate, zadržaná a uvoľnená rezerva a zlyhaná výplata. Spustite ich so známymi očakávanými zostatkami. Ak kontrolný účet záväzkov voči predajcom sa rovná súčtu analytiky, klíring platobnej brány sedí so settlement reportom a bankový vklad sedí s ID výplaty, máte funkčnú kostru.
Uzamykanie období zapnite až po tom, čo sa prvý mesiac čistým spôsobom uzavrie s nulovým zostatkom na prechodnom účte. Príliš skoré uzamknutie chyby len zakonzervuje.
Nordlet štandardne účtuje vyrovnania presne týmto spôsobom: provízia platformy ide do tržieb z provízií, podiel predajcu do záväzkov voči predajcom, poplatky platobnej brány do nákladov na spracovanie platieb a čokoľvek nepriradené na prechodný účet (suspense). Účtovné obdobia zostávajú otvorené, kým ich explicitne neuzamknete, takže prvý mesiac možno zatvoriť až po vyprázdnení prechodného účtu. Stránka s funkciami uvádza prehľad toho, čo je zahrnuté.
FAQ
Je platba kupujúceho niekedy tržbou platformy?
Iba pre konkrétny tovar alebo služby, kde platforma vystupuje ako hlavný účastník (principal). Pri sprostredkovateľskom predaji tovaru predajcu na trhovisku sú tržbami provízia a podiel predajcu je záväzkom. Platforma môže vystupovať ako hlavný účastník pre doručovaciu službu a ako sprostredkovateľ pre samotný tovar v rámci tej istej objednávky, takže posúdenie sa vykonáva pre každý špecifikovaný tovar alebo službu, nie pre spoločnosť ako celok.
Mali by rezervy znižovať tržby?
Nie. Rezerva je časovým a rizikovým rozdelením, nie úpravou tržieb. Presuňte finančné prostriedky zo záväzkov voči predajcovi do záväzku z rezervy, keď ich zadržíte, a stornujte ich pri uvoľnení. Tržby a provízie nie sú ovplyvnené tým, či sú peniaze predajcu aktuálne rezervované.
Ako zabránim duplicitným výplatám z opakovaní webhookov?
Pripojte identifikačný kľúč (idempotency key) ku každej externej udalosti, napríklad processor:payout_id pre dávky výplat, a detegujte duplicitné udalosti pri zápise. Poskytovatelia výslovne varujú, že dochádza k duplicitnému doručovaniu webhookov, takže účtovná kniha musí druhý pokus odmietnuť namiesto jeho opätovného zaúčtovania.
Môže byť zostatok predajcu záporný?
Áno, a model to musí umožňovať. Spätná platba (chargeback), ktorá dorazí po tom, čo bol predajcovi vyplatený, zanecháva platformu buď s pohľadávkou voči predajcovi, alebo so stratou, ktorú absorbuje. Potlačenie záporných zostatkov iba skrýva nezaevidovaný záväzok.
Prečo robiť rekonciláciu pre každú výplatu namiesto mesačného súčtu?
Pretože pri agregácii za mesiac sa časové rozdiely a chyby navzájom vyrovnajú, takže súčty môžu sedieť, zatiaľ čo jednotlivé transakcie sú nesprávne. Rekoncilácia na úrovni jednotlivých výplat, spárovaná podľa ID výplat a transakcií, odhalí chýbajúce udalosti, duplikáty a nesprávne priradené spätné platby ešte pred uzávierkou.