Marketplace eladói alszámlák: Bevételek és kötelezettségek
Gyakorlati útmutató az ügyfelek pénzének, a platform jutalékának, az eladói kötelezettségeknek, a tartalékoknak és a kifizetéseknek a szétválasztásához kiegyensúlyozott könyvelési tételekkel és egy működő megrendeléstől kifizetésig terjedő adatmodellel.
A piactéri (marketplace) könyvelés leggyakoribb hibája, amikor a vevő bruttó fizetését platformbevételként kezelik. Egy ügyfél kifizet 100 eurót, az az 100 euró megérkezik a fizetési szolgáltató (payment processor) számlájára, valaki pedig az egészet az árbevételbe könyveli. A könyvek egy ideig egyensúlyban vannak, a bevétel jól néz ki, aztán egy auditor megkérdezi, hol van az eladóval szembeni kötelezettség. Ilyen azonban nincs, mert az eladót megillető 90 eurót sosem rögzítették tartozásként.
A probléma orvoslása szerkezeti, nem pedig kozmetikai jellegű. Egy piactérnek olyan főkönyvi modellre van szüksége, amely már az első tételtől kezdve elkülönít öt különböző pénzalapot: az úton lévő ügyfélelőleget vagy -pénzt, a platform jutalékból származó bevételét, az eladói kötelezettségeket, a díjakat és a tartalékokat. A kifizetések egy hatodik eseményt jelentenek, amely a kötelezettséget rendezi, önmagában viszont nem bevétel- vagy ráfordítás-esemény. Ez az útmutató bemutatja azokat a kiegyensúlyozott tételeket és azt az adatmmodellt, amelyekkel ezek az alapok tisztán elkülöníthetők.
Kezdje a principális és ügynök besorolással
Mielőtt bármilyen számlaszerkezet számítana, a platformnak el kell döntenie, mit is árusít. Az ASC 606 előírásai szerint ezt meghatározott árukra vagy szolgáltatásokra lebontva kell vizsgálni, és a válasz határozza meg, hogy a bevétel bruttó vagy nettó módon kerül-e kimutatásra. Előfordulhat, hogy egy platform az egyik tranzakciótípusnál principális (principal), a másiknál pedig ügynök (agent)ként jár el.
Egy eladó áruit értékesítő tipikus piactér esetében a platform általában ügynök. Gondoskodik arról, hogy az eladó terméke eljusson a vevőhöz, de nem vállal készletkockázatot, a bevétele pedig jutalékból áll. A Deloitte ASC 606 szerinti principális-ügynök útmutatója az ellenőrzés (control) fogalma köré építi a vizsgálatot: az ígéret teljesítéséért való felelősség, a készletkockázat és az árak meghatározásának szabadsága mind mutatók, nem pedig egy olyan ellenőrzőlista elemei, amely felülírja a mögöttes ellenőrzési értékelést.
Ennek a megállapításnak nemcsak egy belső feljegyzésben, hanem a főkönyv tervezésében is szerepelnie kell, mivel ez határoz meg minden további könyvelési tételt. Ha a platform ügynök, az eladót megillető rész azon a napon kötelezettségként jelentkezik, amikor az megérdemelten jár neki. Ha viszont teljesítési vagy garanciális szolgáltatás nyújtásában principális, akkor az a rész a platform bevétele lesz. Tárolja ezt a megállapítást adatként is:
principal_agent_rolespecified_good_or_servicecommission_rule_idcontrol_assessment_versioneffective_from/effective_to
Ha egy ellenőr két év múlva megnézi a nettó jutalék sorát, látnia kell, miért nem a bruttó összeget használták. Ahogy a BillingPlatform az ASC 606 szerinti principális vs. ügynök kérdésről megjegyzi, a „piactér” címke önmagában nem dönti el a kérdést. Az ellenőrzési elemzés teszi azt meg.
Határozza meg az eladói egyenleget, mielőtt egyetlen könyvelési szabályt is leírna
Az „eladói egyenleg” nem egyetlen szám. Előfordulhat, hogy egy eladónak kiváló az eddigi összesített egyenlege, mégsem tud mit kifizetésként kérni, mert a pénz még függőben van vagy tartalékolás alatt áll. Ha ezeket az állapotokat összemosztja, tévesen fogja jelenteni, hogy az eladó mekkora összeget vehet fel, és a platform mennyi pénzzel tartozik még.
Legalább az alábbiakat kövesse nyomon:
- Függő (Pending): megszerezve vagy beszedve, de kifizetésre még nem jogosult
- Elérhető (Available): a platform szabályai szerint kifizetésre jogosult
- Tartalékolt (Reserved): a várt visszatérítések, viták vagy visszaterhelések (chargebacks) ellenében visszatartva
- Kifizetett (Paid out): átutalva vagy elszámolásra benyújtva
- Negatív (Negative): az eladó által tartozásként fennálló összeg, amely a jövőbeni bevételekből behajtható
- Függő elszámolású (Suspense): beérkezett, de az eladó vagy a jogcím még nem tisztázott
A fizetési szolgáltatók már eleve így modellezik ezt a megkülönböztetést. A Stripe minden csatlakoztatott számlát függő és elérhető egyenlegre bont, és a platform szintjén is tart egy tartalék egyenleget bizonyos negatív eladói egyenlegek kezelésére. Ha a feldolgozó (processor) különválasztja ezeket, a főkönyvnek is ezt kell tennie, különben az egyeztetés sosem fog stimmelni.
A számlatükör és a fontos dimenziók
A működőképes kiinduló szerkezet külön tartja az átvezető (clearing) számlákat, a kötelezettségeket és a bevételeket, ráadásul minden jelentős tételnél rögzíti az eladói dimenziót is.
| Cél | Számla vagy dimenzió | Kezelés |
|---|---|---|
| Elszámolásra váró pénzeszközök a fizetési szolgáltatónál | Fizetési szolgáltató átvezető számlája | Átvezető eszköz |
| Bankba megérkezett kifizetés | Bank | Eszköz |
| Megszerzett, de még ki nem fizetett eladói összeg | Eladói kötelezettségek | Kötelezettség |
| Eladói szintű részletek | seller_id dimenzió |
Kötelezettség részletei, nem bevétel |
| Platform jutalék | Jutalékbevétel | Bevétel |
| ÁFA vagy forgalmi adó | Fizetendő adó | Kötelezettség |
| Fizetési szolgáltató díjai | Tranzakciós díjak ráfordítása | Ráfordítás |
| Eladói tartalékok | Tartalék kötelezettség | Szerződésfüggő |
| Visszatérítések | Bevételcsökkentő tétel vagy visszatérítés | Megfordítja az eredeti kezelést |
| Visszaterhelések (Chargebacks) | Veszteség, követelés vagy eladói behajtás | Attól függ, ki viseli a veszteséget |
| Banki jóváhagyásra váró kifizetések | Eladói kifizetési átvezető | Átvezető számla |
| Nem allokált összegek | Függő elszámolás | Ideiglenes kivétel |
Minden jelentős tételnek tartalmaznia kell az eladót, a rendelést, a kifizetési tételt, a fizetési szolgáltatót, a pénznemet, a jogi személyt, az adózási kezelést, az esemény típusát, a külső hivatkozást és az esetleges sztornó hivatkozást. Ezek nélkül az eladói alszámla nem tudja igazolni az egyedi egyenleget, a főkönyv pedig a teljes összeget.
Az alszámlát megvalósíthatja eladónként egy kötelezettségi számlával, egy összesített kötelezettségi számlával a seller_id dimenzió használatával, vagy a kötelezettség, a tartalék és a kifizetési átvezetés szétbontásával. Az összesített plusz dimenziós megközelítés jobban skálázódik, ha már túljutott néhány tucat eladón. Beszélje meg a modellt a könyvelőjével, mivel a pénzvédelemi szabályok (safeguarding rules) és a helyi fizetési előírások befolyásolhatják a pénzeszközök kimutatási módját. A könyvelési tételek hátteréről a kettős könyvelésű főkönyvi API-król szóló cikkünkben olvashat, amely azon a főkönyvi alapon nyugszik, amire ez a modell épül.
Könyvelje le az eladást külön eladói és platform sorokkal
Vegyünk egy ügynöki értékesítést: az ügyfél kifizet 100 eurót, a platform jutaléka 10 euró, az eladó bevétele pedig 90 euró. Abban a pillanatban, amikor a jutalék és az eladó követelése keletkezik:
| Számla | Tartozik | Követel |
|---|---|---|
| Fizetési szolgáltató átvezető számlája | €100 | |
| Eladói kötelezettség – A. Eladó | €90 | |
| Jutalékbevétel | €10 |
A lényeges ellenőrzési pont: a 90 euró egy kötelezettséget növel (követel oldalon), nem pedig bevételt. A platform 10 eurót ismer el bevételként. Ez az az eredmény, amelyet az ASC 606 piactéri példája is elér egy ügynök esetében, ahol a platform nem az eladó teljes eladási összegét, hanem a saját jutalékát ismeri el.
Ha az adót külön szedik be, adja hozzá a fizetendő adó sort, és az adózási megállapítás függvényében csökkentse az eladói vagy a platform összegét. Ne mossa össze az adót a jutalékkal vagy az eladói kötelezettséggel pusztán kényelmi okokból.
Tartsa távol a fizetési szolgáltató díjait a bevételi és kötelezettségi számításoktól
Három dolgot szoktak állandóan összekeverni: a platform jutalékát, a fizetési szolgáltató díját és a kifizetési összeget. Ezek különbözőek, és különböző számlákat érintenek.
Az ügyfél kifizet 100 eurót, a jutalék 10 euró, a fizetési szolgáltató pedig megtart 3 eurót.
- A jutalékbevétel 10 euró marad, ha így szól a szerződés.
- A 3 eurós szolgáltatói díj ráfordítás.
- Az eladói kötelezettség 90 euró, kivéve ha az eladói szerződés úgy rendelkezik, hogy a tranzakciós díjat az eladó viseli. Csak ebben az esetben csökken az összeg 87 euróra, a terhelendő 3 euró ellentételével.
Ha csak a bankba megérkező nettó 97 eurót könyvelik le, azzal egy mozdulattal eltüntetik a bruttó eladást, a jutalékot és a díjat is. A fizetés-egyeztetési útmutatónk ugyanezt hangsúlyozza: bontsa le az elszámolást, kezelje a szolgáltatói díjakat ráfordításként, és soha ne engedje, hogy a nettó betét átvegye a bevétel helyét.
A rendelkezésre állás, a tartalékok és a kifizetések kezelése külön eseményként
A pénz a beszedés és a kifizetett készpénz közötti úton többször is státuszt vált. Minden egyes átmenet megérdemli a saját könyvelési tételét, és a tartalék sosem egy megmagyarázhatatlan bevételcsökkenés.
Amikor az elérhető pénzeszközök tartalékba kerülnek:
| Számla | Tartozik | Követel |
|---|---|---|
| Eladói kötelezettség – A. Eladó | €15 | |
| Eladói tartalék kötelezettség | €15 |
Amikor a tartalék felszabadul, fordítsa meg a tételt. Az eladó teljes tartozása nem változott meg, csupán a státusza. A Stripe dokumentációja részletezi a tartalék-tranzakciókat, amelyek növelik és felszabadítják a tartalékokat, valamint a régebbi negatív egyenlegek rendezésére szolgáló behajtási átutalásokat – ez az oka annak, hogy itt egyetlen összevont nettósítás helyett azonosítható számlákra van szükség.
A kifizetések külön, kétlépcsős kezelést kapnak. Jóváhagyáskor:
| Számla | Tartozik | Követel |
|---|---|---|
| Eladói kötelezettség – A. Eladó | €90 | |
| Eladói kifizetési átvezető | €90 |
A megerősített banki elszámoláskor:
| Számla | Tartozik | Követel |
|---|---|---|
| Eladói kifizetési átvezető | €90 | |
| Bank | €90 |
Ha a kifizetés sikertelen, könyvelje vissza az összeget az átvezetőről az eladói kötelezettségre. A kifizetés egy kötelezettség rendezése, nem pedig ráfordítás. Ha ráfordításként kezelik, azzal duplán könyvelik le a költséget a már korábban rögzített eladás ellenében. A Stripe különválasztja a kifizetés státuszát (pending, in_transit, paid, failed, canceled) és a várható érkezési dátumot az indítástól, és ezeket a dátumokat nem szabad egyetlen időbélyegbe összevonni.
A megrendeléstől kifizetésig terjedő adatmodell
Az alszámla eseményeken alapul, nem pedig az alkalmazás aktuális rendelési státuszán. Minden eladót érintő esemény ugyanazt a burkolatot (envelope) hordozza:
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
Ezekből az eseményekből kell kiszámítani a záróegyenleget, ahelyett hogy egy módosítható mezőt tárolnának:
Eladói záróegyenleg
= nyitó egyenleg
+ eladói jóváírások
− eladói terhelések
− kifizetések
± tartalékmozgások
± helyesbítések
Minden külső eseményhez tartós idempotencia-kulcs (idempotency key) szükséges, hogy az újrapróbálkozások és a duplikált webhookok ne eredményezzenek duplán jóváírt eladót vagy dupla kifizetést. Működő minták:
- Eladói naplóesemény:
seller_id:order_id:event_type:version - Kifizetési köteg:
processor:payout_id - Szolgáltatói esemény:
processor:event_type:processor_event_id
A Stripe saját webhook-útmutatója is figyelmeztet arra, hogy előfordulnak duplikált események, így a duplikációk kiszűrése kötelező. A lekönyvelt tételek immutálhatók (nem módosíthatók) maradnak. A helyesbítések egy sztornó tételen és egy helyesbített tételen keresztül történnek, és a reversal_of hivatkozást, valamint az okot maga az eseményburkolat tartalmazza. A főkönyv a könyvelési tételeket tárolja, nem pedig ezt a hivatkozást: a Nordlet API-dokumentációja a naplótételekhez létrehozási, lekérdezési és listázási funkciókat biztosít, módosítást vagy törlést viszont nem, így egy helyesbítés mindig új tranzakciónak számít a szerkesztés helyett.
A visszatérítések és visszaterhelések visszahivatkoznak, sosem lógnak a levegőben
Egy visszatérítésnek, amely a következő heti kifizetésben jelenik meg, sosem szabad új, az adott kifizetéshez kapcsolódó negatív eladásként megjelennie. Csatolja az eredeti tranzakcióhoz, és őrizze meg az eredeti eladói allokációt. A szerződéstől függően:
- Sztornírozza a jutalékot, ha a szerződés azt visszatéríthetővé teszi
- Terhelje az eladói kötelezettséget, ha a visszatérítést az eladó viseli
- Terhelje a platform veszteségszámláját, ha azt a platform viseli
- Növelje a tartalékot nyitott vita esetén, majd szabadítsa fel vagy vonja le a lezáráskor
A kifizetés utáni visszaterhelések (chargebacks) azok az esetek, amikor a negatív egyenlegek megjelennek. Az eladó pénze már nincs ott, így a platform vagy behajtja azt a jövőbeni bevételekből, vagy lenyeli a veszteséget. A modellnek engednie kell a negatív eladói egyenlegeket, és meghatározza a behajtási szabályt. Az Adyen piactéri jelentései azt mutatják, hogy a visszatérítések és visszaterhelések számlatulajdonosonként külön terhelési sorokat eredményeznek, ami az elérendő részletesség.
Egyeztessen kifizetésenként, ne havonta
Minden egyes szolgáltatói kifizetést bontson le a könyvelés előtt, és a havi összesítés helyett kifizetésenként végezze el az egyeztetést:
Bruttó terhelések
− visszatérítések
− fizetési szolgáltatói díjak
− visszaterhelések
± tartalékok és helyesbítések
= nettó szolgáltatói kifizetés
Ezután ellenőrizze, hogy eladónként és pénznemenként négy egyenleg megegyezik-e: az eladói alszámla, a fizetési szolgáltató eladói egyenlege, a kifizetési jelentés és a banki átvezetés. Ha eltérések vannak, sorolja be őket (időzítési eltérés, hiányzó esemény, duplikáció, rossz hozzárendelés, rossz pénznem, sikertelen kifizetés, rossz félre könyvelt visszaterhelés). Az eltérések nettósítása pontosan az a módszer, amellyel a hibák kioltják egymást, és túlélnek a következő zárásig.
Egy teljes hónap összesítése elrejti az időzítési eltéréseket, és eltünteti a valós hibákat. A kifizetésenkénti párosítás – amely az összeg és dátum helyett a kifizetési azonosítóra és tranzakciós hivatkozásra támaszkodik – ezeket kiszűri.
Gyakoribb hibaforrások
| Hibaforrás | Miért ártalmas? | Ellenőrzési pont |
|---|---|---|
| Bruttó ügyfélfizetés bevételként könyvelve | Felfújja a bevételt, elrejti az eladói kötelezettséget | Válassza szét a kötelezettséget és a jutalékot a megszerzés eseményénél |
| Csak a nettó betétek könyvelése | Elveszíti a bruttót, a díjakat, a visszatérítéseket és a tartalékokat | Bontson le minden egyes elszámolást |
| Ráfordításként könyvelt kifizetés | Hibásan mutatja ki a kötelezettség rendezését | Terhelje az eladói kötelezettséget kifizetéskor |
| Egyetlen eladói egyenleg mező | Összemosja a függő, elérhető, tartalékolt és kifizetett összegeket | Kövesse nyomon kifejezetten az egyenlegállapotokat |
| Kifizetéskor kiszámított jutalék | A bevétel a kifizetési ütemezést követi | Akkor ismerje el a jutalékot, amikor az megszületett |
| Tartalék bevételcsökkentőként kezelve | Elhomályosítja az időzítést és a kockázatot | Tartsa külön nyilván a visszatartást, felszabadítást és felhasználást |
| Legutolsó kifizetésre alkalmazott visszatérítés | Megszakítja a rendelési hozzárendelést | Kösse a visszatérítést az eredeti tranzakcióhoz |
| Lefoglalt tételek szerkesztése | Megsemmisíti a könyvvizsgálati nyomvonalat | Sztornírozza és könyvelje újra |
| Újrajátszott webhookok | Dupla jóváírások és kifizetések | Idempotencia-kulcsok, duplikáció-szűrés |
| Kizárólag összeg és dátum szerinti egyeztetés | A különböző tételek összeütköznek | Egyeztessen kifizetési azonosító, tranzakcióazonosító, eladó és pénznem alapján |
Mit tennék először?
Térképezze fel a pénz áramlását, mielőtt hozzáérne a számlatükörhöz. Írja le a fizetés beszedésétől a tartalék felszabadításáig tartó összes eseményt, és jelölje meg, melyek hoznak létre bevételt, melyek kötelezettséget, és melyek azok, amelyek csak státuszt váltanak.
Ezután építsen fel egy teljes körű folyamatot, és bizonyítsa be, hogy egyensúlyban van: egy normál eladás, egy részleges visszatérítés, egy kifizetés utáni visszaterhelés, egy visszatartott és felszabadított tartalék, valamint egy sikertelen kifizetés. Futtassa le ezeket ismert elvárt egyenlegekkel. Ha az eladói kötelezettségi ellenőrzési számla egyenlő az alszámlák összegével, a szolgáltatói átvezetés stimmel az elszámolási jelentéssel, a banki betét pedig a kifizetési azonosítóval, akkor van egy működő gerince.
Csak azután kapcsolja be az időszak lezárását (period locking), hogy az első hónap tisztán, üres függő egyenleggel zárult. A túl korai lezárás csak befagyasztja a hibákat.
A Nordlet a fenti elvek alapján alapértelmezés szerint kezeli az elszámolásokat: a platform jutaléka a jutalékbevételbe, az eladó része az eladói kötelezettségbe, a fizetési szolgáltató díjai a tranzakciós díjak ráfordításába, minden még hozzá nem rendelt tétel pedig a függő elszámolási számlára kerül. A főkönyvi időszakok addig nyitva maradnak, amíg kifejezetten le nem zárja őket, így az első hónap lezárható, amint a függő egyenleg kiürült. A funkciók oldalon részletesen megtalálható a benne foglaltak listája.
FAQ
A vevő fizetése valaha is a platform bevétele?
Csak azokra a specifikus árukra vagy szolgáltatásokra vonatkozóan, ahol a platform a principális. Egy eladó áruit értékesítő ügynöki piactér esetében a bevétel a jutalék, az eladó része pedig kötelezettség. Előfordulhat, hogy egy platform egy és ugyanazon rendelésen belül a teljesítési szolgáltatás tekintetében principális, míg a mögöttes áruk tekintetében ügynök, így az értékelést nem vállalatanként, hanem megadott árunként vagy szolgáltatásonként kell elvégezni.
Csökkenteniük kell-a tartalékok a bevételt?
Nem. A tartalék időzítési és kockázatkezelési allokáció, nem pedig bevételi helyesbítés. Amikor visszatartja a pénzt, vigye át az összeget az eladói kötelezettségből egy tartalék kötelezettségi számlára, felszabadításkor pedig fordítsa meg. A bevételt és a jutalékot egyáltalán nem befolyásolja, hogy az eladó pénze jelenleg tartalékolva van-e.
Hogyan akadályozhatom meg a duplikált kifizetéseket a webhook-újrapróbálkozásokból?
Minden külső eseményhez csatoljon egy idempotencia-kulcsot, például processor:payout_id formátumban a kifizetési kötegeknél, és íráskor szűrje ki a duplikált eseményeket. A szolgáltatók kifejezetten figyelmeztetnek arra, hogy a webhookok duplikált kézbesítése előfordulhat, így a főkönyvnek el kell utasítania a második kísérletet ahelyett, hogy azt újra lekönyvelné.
El lehet negatívba az eladói egyenleg?
Igen, és a modellnek ezt engednie kell. Egy olyan visszaterhelés, amely azután érkezik be, hogy az eladót már kifizették, a platform számára vagy az eladóval szembeni követelést, vagy egy általa lenyelt veszteséget eredményez. A negatív egyenlegek elrejtése csak egy be nem jegyzett kötelezettséget maszkol.
Miért érdemes kifizetésenként egyeztetni a havi összesítés helyett?
Mivel az időzítési eltérések és a hibák az összesítés során kioltják egymást, így az összegek stimmelhetnek annak ellenére, hogy az egyes tranzakciók hibásak. A kifizetésenkénti, kifizetési és tranzakciós azonosítók alapján párosított egyeztetés még a zárás előtt felszínre hozza a hiányzó eseményeket, a duplikációkat és a rosszul hozzárendelt visszaterheléseket.