Podrozvahy prodejců na tržištích: Tržby vs. závazky
Praktický průvodce oddělením zákaznické hotovosti, provize platformy, závazků vůči prodejcům, rezerv a výplat pomocí vyrovnaných účetních zápisů a funkčního datového modelu od objednávky k výplatě.
Nejčastější chybou v účetnictví tržišť (marketplaces) je považovat hrubou platbu od kupujícího za tržbu platformy. Zákazník zaplatí 100 EUR, tato částka přistane na účtu platební brány a někdo zaúčtuje celou částku do výnosů. Účetnictví chvíli sedí, tržby vypadají skvěle, a pak se auditor zeptá, kde je závazek vůči prodejci. Žádný tam není, protože 90 EUR prodejce nebylo nikdy zaúčtováno jako dluh.
Náprava je strukturální, nikoliv kosmetická. Tržiště potřebuje model hlavní knihy (ledger), který od prvního zápisu odděluje pět různých položek: zákaznickou hotovost drženou v tranzitu, výnosy z provizí platformy, závazky vůči prodejcům, poplatky a rezervy. Výplaty jsou šestou událostí, která vypořádává závazek, nikoliv samostatnou událostí představující výnos nebo náklad. Tento průvodce ukazuje vyrovnané zápisy a datový model, které tyto položky udržují oddělené.
Začněte posouzením role hlavního aktéra (principal) vs. zprostředkovatele (agent)
Než začnete řešit strukturu účtů, platforma si musí ujasnit, co vlastně prodává. Podle standardu ASC 606 se toto posuzuje pro každé jednotlivé zboží nebo službu a výsledek určí, zda jsou výnosy vykazovány v hrubé, nebo čisté výši. Platforma může vystupovat jako hlavní aktér u jednoho typu transakcí a jako zprostředkovatel u jiného.
U běžného prodeje zboží prodejce prostřednictvím tržiště vystupuje platforma obvykle jako zprostředkovatel (agent). Zajišťuje, že se produkt prodejce dostane ke kupujícímu, nenese riziko spojené se zásobami a její odměnou je provize. Metodika společnosti Deloitte k posouzení role hlavního aktéra a zprostředkovatele podle ASC 606 staví test na kontrole: odpovědnost za splnění závazku, riziko spojené se zásobami a volnost při stanovení ceny jsou indikátory, nikoliv rigidní kontrolní seznam, který by nahrazoval posouzení skutečné kontroly.
Důvodem, proč toto patří přímo do návrhu účetního rozvrhu a nejen do interní poznámky, je fakt, že tento závěr ovlivňuje každý navazující zápis. Pokud je platforma zprostředkovatelem, podíl prodejce je závazkem od okamžiku, kdy na něj vznikne nárok. Pokud je hlavním aktérem u zajištění dopravy nebo záručního servisu, tato část představuje výnos platformy. Uložte si tento závěr jako data:
principal_agent_rolespecified_good_or_servicecommission_rule_idcontrol_assessment_versioneffective_from/effective_to
Auditor, který se na řádek s čistou provizí podívá o dva roky později, by měl mít možnost snadno zjistit, proč se nepoužila hrubá částka. Jak uvádí BillingPlatform ve svém článku o ASC 606 pro hlavní aktéry a zprostředkovatele, samotné označení „tržiště“ problém neřeší. Rozhodující je analýza kontroly.
Definujte zůstatek prodejce dříve, než napíšete jediné účetní pravidlo
„Zůstatek prodejce“ není jedno jediné číslo. Prodejce může mít skvělou celkovou bilanci, ale k výplatě nemá k dispozici nic, protože peníze jsou stále v řešení nebo v rezervě. Pokud tyto stavy sloučíte do jednoho, budete vykazovat zkreslené informace o tom, co si prodejce může vybrat a co platforma stále dluží.
Minimálně sledujte tyto stavy:
- Čekající (Pending): vydělané nebo inkasované, avšak dosud nezpůsobilé k výplatě
- Dostupné (Available): způsobilé k výplatě podle pravidel platformy
- Rezervované (Reserved): zadržené pro případ očekávaných vrácení peněz (refundací), sporů nebo stornolvých poplatků (chargebacks)
- Vyplacené (Paid out): převedené nebo odeslané k vypořádání
- Záporné (Negative): částka, kterou prodejce dluží a kterou lze vymoci z budoucích příjmů
- Nezařazené (Suspense): přijaté, ale prodejce nebo způsob zpracování ještě nebyly určeni
Poskytovatelé platebních služeb toto rozlišení již běžně používají. Stripe odděluje zůstatky každého propojeného účtu na čekající a dostupné a pro určité záporné zůstatky prodejců drží rezervovaný zůstatek na úrovni platformy. Pokud to platební brána odděluje, hlavní kniha to musí dělat také, jinak se vám nikdy nepodaří provést odsouhlasení (reconciliaci).
Účetní rozvrh a dimenze, na kterých záleží
Funkční počáteční struktura udržuje clearingové účty, závazky a výnosy odděleně a u každého významného zaúčtování nese dimenzi prodejce.
| Účel | Účet nebo dimenze | Způsob zaúčtování |
|---|---|---|
| Prostředky u platební brány čekající na vypořádání | Clearing platební brány | Clearingové aktivum |
| Vyplacené prostředky na bankovním účtu | Banka | Aktivum |
| Částka prodejce, na kterou vznikl nárok, ale nebyla vyplacena | Závazky vůči prodejcům | Závazek |
| Detail na úrovni prodejce | Dimenze seller_id |
Detail závazku, nikoliv výnos |
| Provize platformy | Výnosy z provizí | Výnos |
| DPH nebo obratová daň | Závazky z daní | Závazek |
| Poplatky platební brány | Náklady na zpracování plateb | Náklad |
| Rezervy prodejců | Závazek z rezerv | Závislé na smlouvě |
| Vrácení peněz (refundace) | Snížení výnosů nebo refundace | Zvrácení původního zaúčtování |
| Chargebacky | Ztráta, pohledávka nebo vymáhání po prodejci | Závisí na tom, kdo nese ztrátu |
| Výplaty čekající na potvrzení bankou | Clearing výplat prodejcům | Clearingový účet |
| Nezařazené částky | Dohadný účet / Suspense | Dočasná výjimka |
Každý významný zápis by měl obsahovat prodejce, objednávku, dávku výplat, platební bránu, měnu, právní subjekt, daňový režim, typ události, externí referenci a případný odkaz na storno. Bez těchto údajů nedokáže podrozvaha prodejce doložit jednotlivý zůstatek a hlavní kniha nedokáže doložit celkový souhrn.
Podrozvahu (subledger) můžete implementovat jako jeden účet závazků na prodejce, jeden agregovaný účet závazků s dimenzí seller_id nebo jako rozdělení na závazky, rezervy a clearing výplat. Přístup založený na agregovaném účtu s dimenzí lépe škáluje, jakmile překročíte několik desítek prodejců. Zvolte vhodný model se svým účetním, protože pravidla pro ochranu finančních prostředků a místní platná regulace platebních služeb mohou ovlivnit způsob vykazování těchto peněz. Podrobnosti o mechanismech účetních zápisů najdete v našem článku o API pro podvojné účetnictví pro tržiště, kde popisujeme základní prvky hlavní knihy, na kterých tento model staví.
Zaúčtujte prodej se samostatnými řádky pro prodejce a platformu
Vezměme si prodej přes zprostředkovatele: zákazník zaplatí 100 EUR, provize platformy je 10 EUR, prodejce vydělá 90 EUR. V okamžiku, kdy vznikne nárok na provizi a podíl prodejce:
| Účet | Má dáti (Debit) | Dal (Credit) |
|---|---|---|
| Clearing platební brány | 100 EUR | |
| Závazek vůči prodejci – Prodejce A | 90 EUR | |
| Výnosy z provizí | 10 EUR |
Klíčová kontrola: 90 EUR se připisuje ve prospěch závazku, nikoliv výnosů. Platforma vykazuje výnos 10 EUR. To je výsledek, ke kterému dospívá příklad tržiště podle standardu ASC 606 pro zprostředkovatele, kde platforma vykazuje svou provizi namísto plné prodejní ceny zboží prodejce.
Pokud je daň vybírána samostatně, přidejte řádek závazku z daní a snižte částku prodejce nebo platformy v souladu s daňovým posouzením. Neumísťujte daň do provize nebo závazku vůči prodejci jen kvůli zjednodušení.
Oddělte poplatky platební brány od matematiky výnosů a závazků
Tři věci se neustále zaměňují: provize platformy, poplatek platební brány a částka k výplatě. Jsou to různé položky a ovlivňují různé účty.
Zákazník zaplatí 100 EUR, provize je 10 EUR, platební brána si ponechá 3 EUR.
- Výnosy z provizí zůstávají na hodnotě 10 EUR, pokud tak stanoví smlouva.
- Poplatek platební brány ve výši 3 EUR je nákladem.
- Závazek vůči prodejci činí 90 EUR, pokud smlouva s prodejcem nestanoví, že poplatek za zpracování platby nese prodejce. Teprve v takovém případě klesne na 87 EUR s odpovídajícím poplatkem 3 EUR naúčtovaným prodejci.
Zaúčtování pouze čisté částky 97 EUR, která dorazí na bankovní účet, jedním tahem vymaže hrubý prodej, provizi i poplatek. Naše příručka pro odsouhlasení plateb zdůrazňuje totéž: rozeberte vypořádání na jednotlivé složky, poplatky platební brány považujte za náklady a nikdy nedovolte, aby čistý vklad nahradil tržby.
Modelujte dostupnost, rezervy a výplaty jako samostatné události
Peníze mění svůj stav mezi okamžikem přijetí platby a vypořádanou hotovostí hned několikrát. Každý přechod si zaslouží vlastní zápis a rezerva nesmí být nikdy nevysvětleným snížením výnosů.
Když se dostupné prostředky přesunou do rezervy:
| Účet | Má dáti (Debit) | Dal (Credit) |
|---|---|---|
| Závazek vůči prodejci – Prodejce A | 15 EUR | |
| Závazek z rezervy prodejců | 15 EUR |
Když se rezerva uvolní, proveďte opačný zápis. Celkový závazek vůči prodejci se nezměnil, změnil se pouze jeho stav. Stripe dokumentuje transakce s rezervami, které rezervy navyšují a uvolňují, spolu s převody pro úhradu dlouhodobých záporných zůstatků, a proto tyto operace vyžadují jednoznačně identifikovatelné účty namísto jediného síťového zápisu (netting).
Výplaty mají vlastní dvoukrokový proces. Při schválení:
| Účet | Má dáti (Debit) | Dal (Credit) |
|---|---|---|
| Závazek vůči prodejci – Prodejce A | 90 EUR | |
| Clearing výplat prodejcům | 90 EUR |
Při potvrzeném vypořádání bankou:
| Účet | Má dáti (Debit) | Dal (Credit) |
|---|---|---|
| Clearing výplat prodejcům | 90 EUR | |
| Banka | 90 EUR |
Pokud výplata selže, stornujte položku z clearingu zpět do závazků vůči prodejci. Výplata představuje vypořádání závazku, nikoliv náklad. Pokud byste ji zaúčtovali jako náklad, došlo by k duplicitnímu započtení proti prodeji, který již závazek zaúčtoval. Stripe odděluje stav výplaty (pending, in_transit, paid, failed, canceled) a očekávané datum doručení od jejího zadání a tato data by se neměla slévat do jednoho časového razítka.
Datový model od objednávky k výplatě
Podrozvaha funguje na základě událostí (events), nikoliv podle aktuálního stavu objednávky v aplikaci. Každá událost ovlivňující prodejce nese stejnou strukturu:
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 událostí se konečný zůstatek vypočítává, namísto ukládání měnitelného pole (mutable field):
Konečný zůstatek prodejce
= počáteční zůstatek
+ kreditní položky prodejce
− debetní položky prodejce
− výplaty
± pohyby rezerv
± opravy
Každá externí událost vyžaduje trvanlivý idempotentní klíč (idempotency key), aby opakované pokusy a duplicitní webhooky nezapsaly prodejci duplicitní kredit nebo neprovedly dvojí výplatu. Osvědčené vzory:
- Událost v deníku prodejce:
seller_id:order_id:event_type:version - Dávka výplat:
processor:payout_id - Událost platební brány:
processor:event_type:processor_event_id
Pokyny pro webhooky od společnosti Stripe varují, že duplicitní události se stávají, takže detekce duplicit je povinná. Zaúčtované položky zůstávají neměnné. Opravy probíhají formou stornovacího zápisu a následného opraveného zápisu, přičemž právě vaše vlastní struktura událostí nese odkaz reversal_of a důvod. Hlavní kniha uchovává záznamy o zaúčtování, nikoliv tento odkaz: Nordlet poskytuje operace vytvoření, získání a seznamu pro transakce v deníku ve své API dokumentaci a nepodporuje aktualizaci ani mazání, takže oprava je vždy novou transakcí, nikoliv pouhou úpravou existujícího záznamu.
Refundace a chargebacky na sebe odkazují, nikdy neplují volně
Vrácení peněz (refundace), které se objeví v příštím týdenním vyúčtování výplat, se nesmí stát novým záporným prodejem připojeným k této výplatě. Propojte ho s původní transakcí a zachovejte původní alokaci prodejci. V závislosti na smlouvě:
- Stornujte provizi, pokud smlouva stanoví, že je vratná.
- Zaúčtujte debet na závazek vůči prodejci, pokud refundaci nese prodejce.
- Zaúčtujte debet na účet ztrát platformy, pokud ji nese platforma.
- Zvětšete rezervu, dokud je spor otevřený, a při jeho vyřešení ji uvolněte nebo vyčerpejte.
Chargebacky po provedené výplatě jsou okamžikem, kdy vznikají záporné zůstatky. Peníze prodejce jsou již pryč, takže platforma je buď vymůže z budoucích příjmů, nebo absorbuje ztrátu. Model musí povolit záporné zůstatky prodejců a definovat pravidlo pro jejich vyrovnání. Reporty tržiště od společnosti Adyen ukazují, že refundace a chargebacky vytvářejí samostatné debetní řádky pro každého držitele účtu, což je úroveň detailu, kterou byste měli sledovat.
Odsouhlaste každou výplatu zvlášť, ne až na konci měsíce
Před zaúčtováním rozeberte každé vypořádání od platební brány na jednotlivé složky a odsouhlaste každou výplatu zvlášť, namísto agregace za celý měsíc:
Hrubé platby
− refundace
− poplatky platební brány
− chargebacky
± rezervy a úpravy
= čistá výplata od platební brány
Poté ověřte, že se pro každého prodejce a měnu shodují čtyři zůstatky: podrozvaha prodejce, zůstatek prodejce u platební brány, přehled výplat a bankovní clearing. Pokud se liší, rozdíl klasifikujte (časový posun, chybějící událost, duplicita, špatné přiřazení, nesprávná měna, neúspěšná výplata, chargeback zaúčtovaný nesprávné straně). Ignorování rozdílů pouhým síťovým vyrovnáním vede k tomu, že se chyby navzájem maskují a přenášejí se do další závěrky.
Agregace za celý měsíc umožňuje, aby se časové rozdíly navzájem vyrušily, což zakrývá reálné nesrovnalosti. Párování pro každou výplatu zvlášť, založené na ID výplaty a referenci transakce namísto pouhé částky a data, tyto chyby odhalí.
Časté chyby a selhání
| Typ selhání | Proč to škodí | Kontrola |
|---|---|---|
| Hrubá platba zákazníka zaúčtovaná jako tržba | Uměle navyšuje tržby, skrývá závazek vůči prodejci | Oddělte závazek a provizi v okamžiku vzniku nároku |
| Zaúčtovány pouze čisté vklady | Ztrácí přehled o hrubých prodejích, poplatcích, refundacích a rezervách | Rozeberte každé vypořádání na složky |
| Výplata zaúčtována jako náklad | Nesprávně vykazuje vypořádání závazku | Zaúčtujte debet na závazek vůči prodejci při výplatě |
| Jediné pole pro zůstatek prodejce | Míchá čekající, dostupné, rezervované a vyplacené prostředky | Sledujte stavy zůstatků explicitně |
| Provize vypočtená v okamžiku výplaty | Výnosy se pak řídí harmonogramem výplat | Zaúčtujte provizi v okamžiku, kdy na ni vznikne nárok |
| Rezerva považovaná za snížení výnosů | Zamlžuje časování a riziko | Sledujte zadržení, uvolnění a čerpání odděleně |
| Refundace aplikovaná na nejbližší výplatu | Porušuje přiřazení k objednávce | Propojte refundaci s původní transakcí |
| Úprava již zaúčtovaných položek | Ničí auditní stopu | Použijte storno a nové zaúčtování |
| Opakovaně doručené webhooky | Duplicitní kredity a výplaty | Idempotentní klíče a detekce duplicit |
| Párování pouze podle částky a data | Dochází ke kolizím různých položek | Párujte podle ID výplaty, ID transakce, prodejce a měny |
Co bych udělal jako první
Než vůbec sáhnete do účetního rozvrhu, namapujte si tok peněz. Zapište si každou událost od přijetí platby až po uvolnění rezervy a označte, které z nich vytvářejí výnos, které závazek a které pouze mění stav.
Poté sestavte jeden kompletní tok od začátku do konce a ověřte, že se vyrovná: běžný prodej, částečná refundace, chargeback po výplatě, zadržená a uvolněná rezerva a neúspěšná výplata. Prožeďte tyto scénáře s předem známými očekávanými zůstatky. Pokud kontrolní účet závazků vůči prodejcům odpovídá součtu podrozvahy, clearing platební brány sedí s reportem vypořádání a bankovní vklad odpovídá ID výplaty, máte funkční základ.
Uzamykání účetních období zapněte až po prvním měsíci, který se uzavře čistě a s nulovým dohadným zůstatkem. Příliš brzké uzamčení chyby pouze zafixuje.
Nordlet provádí zaúčtování vypořádání podle těchto principů automaticky: provize platformy jde do výnosů z provizí, podíl prodejce do závazků vůči prodejcům, poplatky platební brány do nákladů na zpracování plateb a cokoliv, co nebylo přiřazeno, jde na dohadný účet. Účetní období zůstávají otevřená, dokud je výslovně neuzamknete, takže první měsíc lze uzavřít, jakmile je dohadný účet prázdný. Stránka s funkcemi uvádí přehled toho, co je součástí systému.
FAQ
Je platba od kupujícího někdy výnosem platformy?
Pouze u specifického zboží nebo služeb, kde platforma vystupuje jako hlavní aktér (principal). U prodeje zboží prodejce prostřednictvím zprostředkovatelského tržiště jsou výnosem provize a podíl prodejce je závazkem. Platforma může u stejné objednávky vystupovat jako hlavní aktér u zajištění dopravy a jako zprostředkovatel u samotného zboží, takže posouzení se provádí pro každé konkrétní zboží nebo službu, nikoliv za celou společnost.
Měly by rezervy snižovat výnosy?
Ne. Rezerva představuje časové rozlišení a alokaci rizika, nikoliv úpravu výnosů. Při zadržení prostředků převeďte peníze ze závazků vůči prodejci do závazků z rezerv a při uvolnění proveďte opačný zápis. Výnosy a provize nejsou nijak ovlivněny tím, zda jsou peníze prodejce aktuálně rezervovány.
Jak zabránit duplicitním výplatám způsobeným opakováním webhooků?
Připojte ke každé externí události idempotentní klíč, například processor:payout_id pro dávky výplat, a při zápisu detekujte duplicitní události. Poskytovatelé výslovně varují, že k doručování duplicitních webhooků dochází, takže hlavní kniha musí druhý pokus odmítnout, namísto jeho opětovného zaúčtování.
Může zůstatek prodejce klesnout do záporných hodnot?
Ano, a model to musí umožňovat. Chargeback, který dorazí poté, co již byl prodejce vyplacen, zanechává platformu buď s pohledávkou za prodejcem, nebo se ztrátou, kterou musí absorbovat. Potlačování záporných zůstatků pouze skrývá nezaúčtovaný závazek.
Proč provádět odsouhlasení pro každou výplatu zvlášť namísto měsíčního součtu?
Protože časové rozdíly a chyby se při agregaci za celý měsíc navzájem vyruší, takže celkové součty mohou sedět, přičemž jednotlivé transakce jsou chybné. Párování na úrovni jednotlivých výplat, spárované podle ID výplaty a transakce, odhalí chybějící události, duplicity a nesprávně přiřazené chargebacky ještě před uzávěrkou.