Nordlet

← Blog

Stripe Connect piactér számviteli folyamat

Gyakorlati útmutató a terhelések, díjak, átutalások, visszatérítések, viták és tartalékok könyveléséhez egy olyan piactér-főkönyvben, amely zökkenőmentesen egyeztethető.

Nordlet Team · · 12 perc olvasás

A legtöbb piactéri számviteli probléma egyetlen hibára vezethető vissza: arra, ha a Stripe banki kifizetést bevételként kezelik. A kifizetés tucatnyi különálló gazdasági esemény nettó maradványa, és ha ezt egyetlen bevételezési tételként könyveljük, az elfedi a platform jutalékát, az eladó felé fennálló tartozást, valamint az abban elrejtett összes díjat és vitás ügyet. A helyes folyamat a kifizetést még a főkönyvbe kerülés előtt összetevőire bontja.

Ez az útmutató bemutatja az egyes Stripe Connect egyenlegtranzakciós kategóriák megfelelő számviteli helyét: követelések, jutalékbevételek, eladói kötelezettségek, feldolgozási költségek és függő számlák. A könyvelési mechanizmushoz a Nordlet dokumentált import- és elszámolási végpontjait használja, tartalmaz egy kidolgozott elszámolási példát, és egy olyan egyeztetési ellenőrzőlistával zárul, amelyet minden könyvelési zárás előtt elvégezhet.

A Connect terhelési modell azonosítása a tervezés előtt

Számviteli szabályokat nem lehet írni anélkül, hogy ismernék az egyes fizetési folyamatok mögött álló terhelési modellt. A modell határozza meg, hogy melyik Stripe-egyenleget terheli az összeg, ki viseli a díjakat, és hová futnak be először a visszatérítések és a vitás ügyek.

Connect modell Terhelés helye Stripe díjak viselője Visszatérítések/viták csökkentik: Számviteli következmény
Közvetlen terhelések (Direct charges) Kapcsolt fiók Felek szerint konfigurálható Kapcsolt fiók egyenlege A platform a közvetítői díját bevételként könyveli; az eladó fizetési tevékenysége túlnyomórészt a kapcsolt fiók főkönyvében szerepel
Célállomás szerinti terhelések (Destination charges) Platform, azonnali átutalással egy kapcsolt fiókba Platform Platform A platform rögzíti a vevői követelst és a Stripe díjat; az eladó részesedése kötelezettség, nem bevétel
Külön terhelések és átutalások (Separate charges and transfers) Platform terhelés, majd egy vagy több külön átutalás Platform Platform A terhelés és az eladói átutalások külön események; az eladói kötelezettség a vevői terheléstől függetlenül kerül nyomon követésre

A Stripe saját útmutatója arról, hogy hogyan működnek a terhelések egy Connect-integrációban, megerősíti, hogy a célállomás szerinti terhelések, valamint a külön terhelések és átutalások esetén a platform egyenlege viseli a fizetési díjakat, a visszatérítéseket és a visszterheléseket. Közvetlen terhelések esetén a kapcsolt fiók kapja a terhelést, a díjak pedig bármelyik féltől levonhatók.

A gyakorlati szabály: ne állítsa azt, hogy „a Stripe-kifizetés az eladó bevétele”, vagy hogy „az eladó fizeti a díjakat”, amíg le nem írta az egyes folyamatok terhelési modelljét. Tárolja ezt a modellt minden tranzakció mellett. A közvetlen és a célállomás szerinti terhelések keverése egyetlen könyvelési szabály alatt a leggyorsabb út a bevétel és a kötelezettség helytelen feltüntetéséhez.

Ez az útmutató a célállomás szerinti terheléseket, illetve a külön terheléseket és átutalásokat feltételezi, mivel ezekben az esetekben a platform egyenlege hordozza a számviteli súlyt, és a legtöbb piactéri főkönyvet is erre építik.

Az pénzmozgási folyamat leképezése az első sor importálása előtt

Mielőtt hozzákezdene az importáláshoz, rajzoljon egyoldalas tranzakciós térképet minden egyes folyamathoz:

Vevői fizetés
  -> Stripe terhelés / fizetési egyenlegtranzakció
  -> Stripe díj
  -> platform közvetítői díja (jutalék)
  -> átutalás a kapcsolt fiókba
  -> visszatérítés vagy vitás ügy (ha alkalmazandó)
  -> Stripe kifizetés
  -> banki jóváírás

Minden egyes nyíl egy különálló egyenlegtranzakciót jelöl saját azonosítóval, kategóriával, összeggel és dátumokkal. A Stripe-egyenleget kezelje bankjellegű technikai (clearing) számlaként: a terhelések befelé áramlanak, a díjak és az átutalások kifelé, a kifizetés pedig a fennmaradó összeget a valódi bankba mozgatja. A Nordlet banki és fizetési importálási dokumentációja pontosan ezt a kezelést javasolja a szokásos Stripe-tevékenységekhez.

A megfelelő Stripe forrásjelentés kiválasztása

Az automatikus kifizetési elszámolási tételekhez használja a Stripe Kifizetés-egyeztetés, részletezett (Payout reconciliation, itemized) jelentését. Ez egyenlegtranzakciónként egy sort ad, a sorokat reporting_category szerint csoportosítja, mindegyiket egy automatic_payout_id-hoz rendeli, valamint bruttó, díj- és nettó összesítést biztosít. A Stripe jelentéskiválasztási útmutatója dokumentálja ezt a jelentést, és megerősíti a charge_id, a connected_account_id és a destination_payment_id mezőket elérhető Connect-mezőkként.

Ahol az automatikus kifizetések nincsenek engedélyezve (egyes manuális kifizetési megállapodások esetén), a helyett az egyenlegjelentést (Balance report) használja. Ne tekintse a Vezérlőpult (Dashboard) kifizetési összegzését elegendő bizonyítéknak a könyveléshez. Az összegzés csak a tétel összesített összegét igazolja, de az összetevőket kizárólag a részletezett jelentés magyarázza el.

A Stripe javasolja a besorolást a reporting_category alapján a régebbi type mező helyett, és minden sor tartalmaz egy source azonosítót, amely összekapcsolja az alapul szolgáló objektummal. Vegye figyelembe az időzítési korlátot: a Stripe nyilatkozata szerint a napi jelentési adatok általában a következő nap délig állnak rendelkezésre, az azonnali kifizetések pedig nem rendelhetők tisztán az egyes tranzakciókhoz, így azok külön tranzakciótörténeti egyeztetést igényelnek.

Minden egyenlegtranzakció kategória szerinti besorolása

Használja a reporting_category mezőt elsődleges besorolási szempontként, majd vizsgálja meg a source_id, a charge_id és a leírásokat. A fontosabb leképezések:

Stripe tevékenység Jelentési kategória (reporting category) Számviteli értelmezés
Vevői terhelés, kártyás vagy helyi fizetési mód charge Vevői finanszírozású követelés vagy értékesítési elszámolás
Visszatérítés refund Az eredeti vevői fizetés sztornírozása
A Stripe által visszatartott feldolgozási díj fee Fizetésfeldolgozási költség
Platform közvetítői díja platform_earning Jutalékbevétel
Visszatérített közvetítői díj platform_earning_refund Jutalékbevétel csökkenése
Átutalás a kapcsolt fiókba transfer Eladói kötelezettség csökkenése
Sztornírozott átutalás transfer_reversal Visszafizetés a kapcsolt fiókból
Visszterhelés (Chargeback) dispute Visszterhelési veszteség; vizsgálja meg a forrás vitás objektumot
Megnyert vagy sztornírozott visszterhelés dispute_reversal Korábban lekönyvelt visszterhelés megtérülése
Kifizetés a bankba payout Banki pénzmozgás, nem bevétel
Sztornírozott kifizetés payout_reversal Pénzeszközök visszakerülése a Stripe-egyenlegre
Visszatartott tartalék connect_reserved_funds / risk_reserved_funds Korlátozott pénzeszközök, alapértelmezés szerint nem költség
Húzódó negatív egyenleg rendezése connect_collection_transfer Finanszírozási vagy behajtási esemény, amely kockázatkezelési szabályzatot igényel

Egy terminológiai figyelmeztetés: a régebbi egyenlegtranzakciós type mező eltérő címkéket használ ugyanazokra az eseményekre, többek között a payment, az application_fee és az adjustment értékeket. A Stripe egyenlegtranzakció-típusok dokumentációja mindkét szójegyzéket felsorolja. Ne keverje a type értékét a reporting_category szabállyal, és ne találjon ki olyan kategóriát, mint a dispute_loss, amit a Stripe nem exportál. Ha egy export olyan címkét tartalmaz, amelyet nem ismer fel, tartsa meg az exportált értéket, és ellenőrizze azt a forrásobjektum alapján.

Normál piactéri tevékenység könyvelése a főkönyvbe

A célállomás szerinti terhelésekkel vagy külön terhelésekkel és átutalásokkal dolgozó platformok esetében a koncepcionális tételek a következők.

Vevői terhelés (vevői pénz érkezik a Stripe technikai egyenlegére):

Dr Stripe technikai egyenleg (clearing)   Bruttó vevői terhelés
    Cr Vevői követelések                  Bruttó vevői terhelés

Stripe feldolgozási díj:

Dr Stripe díj költség                   Stripe díj
    Cr Stripe technikai egyenleg          Stripe díj

Ne nettózza a Stripe díjat a bevétellel, kivéve, ha a számviteli politikája kifejezetten megköveteli és támogatja a nettó bemutatást.

Platform jutalék (az Ön bevétele, levonva abból, amit egyébként az eladónak kellene fizetni):

Dr Eladói kötelezettség                 Jutalék összege
    Cr Jutalékbevétel                   Jutalék összege

Eladói átutalás (a tartozás rendezése, nem költség):

Dr Eladói kötelezettség                 Átutalás összege
    Cr Stripe technikai egyenleg          Átutalás összege

Az átutalás önmagában soha nem költség. Az eladó részesedése a terhelés megérkezésekor válik kötelezettséggé, az átutalás pedig megszünteti ezt a kötelezettséget. A Nordlet elszámolás-könyvelési szabályai ezt követik: a platform_earning sorok a jutalékbevétel javára könyvelődnek, míg a transfer sorok csökkentik az eladói kötelezettséget. A dokumentált alapértelmezett könyvelési kulcsok a következők: settlements.commissionRevenue (alapértelmezés szerint 5001), settlements.sellerPayable (alapértelmezés szerint 4499), settlements.fees (alapértelmezés szerint 6800) és settlements.suspense (alapértelmezés szerint 4440), amelyek mindegyike vállalatonként felülírható a Nordlet API könyvelési szabályain keresztül.

Visszatérítések kezelése az eredeti értékesítéssel szemben, nem pedig laza banki tételként

A visszatérítés az eredeti terheléshez vagy számlához kapcsolódik. Koncepcionálisan:

Dr Visszatérítések / árbevétel-helyesbítések   Visszatérítés összege
    Cr Vevői követelések                       Visszatérítés összege

A valós könyvelési tétel attól függ, hogy az értékesítést elismerték-e, az adót sztornírozni kell-e, és hogy a platform közvetítői díját visszatérítették-e. Egyetlen visszatérítés eredményezhet követelés-sztornót, adósztornót, közvetítői díj-visszatérítést, átutalási sztornót vagy eladói kötelezettségcsökkenést, valamint egy Stripe-díj vonzatot, amelyet ellenőrizni kell ahelyett, hogy feltételeznénk.

Az időzítési csapda: a visszatérítés gyakran egy későbbi kifizetés során rendeződik, mint az eredeti terhelés. Részesítse előnyben a részletezett kifizetés-egyeztetési jelentést a terhelés-szintű exportból származó szintetizált visszatérítéssel szemben. A Nordlet dokumentációja kifejezetten arra figyelmeztet, hogy a Fizetések (Payments) exportból szintetizált visszatérítés csak becslés, ha a visszatérítés később rendeződik. Az elszámolási importáló be tudja olvasni a visszatérítési sort, párosítani tudja az eredeti értékesítéssel, és a tétel könyvelésekor sztornírozhatja a követelést.

Vitás ügyek kezelése a visszatérítéstől függetlenül

A vitás ügy kártyabirtokosi vagy kibocsátó banki követelés, és a Stripe a vitatott összeget és a vitás díjat is levonhatja a lezárás előtt. Célállomás szerinti terhelések, valamint külön terhelések és átutalások esetén a Stripe mindkettőt levonja a platform egyenlegéből, a visszatérítésekre és vitás ügyekre vonatkozó útmutatója szerint. A platform az eladói átutalás visszavonásával kísérelheti meg a megtérítést.

Elvesztett vitás ügy a platform oldaláról:

Dr Visszterhelési veszteség / újranyitott követelés   Vitatott összeg
Dr Vitás díj költsége                                Vitás díj
    Cr Stripe technikai egyenleg                     Kombinált összeg

Ha az eladó viseli a veszteséget, és a megtérülés megerősítést nyert:

Dr Eladói kötelezettség / behajtási számla         Megtéríthető összeg
    Cr Visszterhelés megtérülése                     Megtéríthető összeg

Ne könyveljen el eladói megtérítést csak azért, mert az átutalás visszavonását kérelmezték. Ellenőrizze, hogy a visszavonás létrejött-e, sikeres היה, és szerepel-e a Stripe-egyenlegen. Ha a vitás ügyet megnyerik, a Stripe visszatéríti a vitatott összeget egy dispute_reversal soron keresztül; sztornírozza a visszterhelési veszteséget, és kezelje külön azt a vitás díjat, amelyet a Stripe nem fizet vissza. A Nordlet egy korábban párosított terhelés charge_id-je alapján párosítja a visszterhelési sorokat, ugyanabból a fájlból vagy egy korábbi importból.

Kidolgozott elszámolási példa

Vegyünk egy automatikus kifizetési tételt. A részletezett jelentés a következőket tartalmazza:

  • Egy charge sor: bruttó 100.00, Stripe díj 3.20, nettó 96.80
  • Egy platform_earning sor: 15.00, a platform jutaléka
  • Egy transfer sor: 81.80 a kapcsolt eladó részére
  • Egy refund sor egy korábbi értékesítésből: bruttó 20.00, ebben a tételben rendeződik
  • Egy payout sor: a bankba áramló tétel összesen

A kifizetés összetétele, a Stripe elszámolási azonossága alapján:

Bruttó terhelések             100.00
- visszatérítések              20.00
- Stripe díjak                  3.20
- átutalások                   81.80
= nettó a platform egyenlegére -5.00

A platform_earning sor nem mozgat pénzt másodszor. Megnevezi azt a 15.00-t, amely a platform egyenlegén marad, miután a díj és az eladói átutalás levonásra került, így a platform jutalékbevételként könyvelheti el ahelyett, hogy azt következtetéssel állapítaná meg.

Itt az eladói átutalás plusz a visszatérítés meghaladja a nettó terhelési tevékenységet, így a tétel nettó eredménye kis negatív összeg lesz, amely csökkenti a következő kifizetést vagy az egyenleget terheli. A lekönyvelt napló sztornírozza a visszatérített követelést, 15.00 összegű jutalékbevételt ismer el, 3.20 összegű díjköltséget rögzít, az átutalással csökkenti az eladói kötelezettséget, és lekönyyeli a visszatérítés sztornóját. A banki tétel megegyezik a számlára érkező nettó összeggel. Egyetlen szám sem egyenlő "a" bevétellel, és ez a lényeg.

Importálás és könyvelés a Nordlet elszámolási végpontján keresztül

A kifizetés szintű egyeztetéshez használja a következő végpontot:

POST /v1/bank/settlements/import

a Stripe szolgáltatóval és a részletezett CSV-fájllal. A Nordlet az automatic_payout_id alapján csoportosítja a sorokat, minden egyes kifizetést bruttó, díj- és nettó összesítéssel rendelkező elszámolási tételsorrá alakít át, kihagyja a már lekönyvelt kifizetések újbóli importálását, kihagyja a payout sorokat az elszámolás összetételéből, és automatikusan párosítja a terhelési, visszatérítési és vitás sorokat rendelés, számla, PaymentIntent, terhelés, forrás vagy metaadat-hivatkozások alapján. A Stripe a részletezett jelentést szakaszonként egy-egy fájlra osztja, ezért a terhelési, visszatérítési és díjfájlokat egyszerre importálja: a már importált, de még le nem könyvelt kifizetéshez tartozó sorok egyesülnek a meglévő tétellel. Ez egy fájlokon és elszámolási végpontokon alapuló importálási és könyvelési folyamat, nem pedig egy valós idejű Stripe-összekötő; a funkciók oldala felsorolja, hogy a banki és elszámolási oldal mit fed le.

Párosítson a következő sorrendben: terhelések a számlákhoz, visszatérítések az eredeti terhelésekhez, vitás ügyek az eredeti terhelésekhez, jutalék sorok a jutalékkezeléshez. Tartsa távol a Stripe díjakat, kiigazításokat, tartalékokat és kifizetési sorokat a számlapárosítástól. A Nordlet fizetés-egyeztetési szójegyzéke kijelenti, hogy a díj- és kiigazítási sorok tervezés szerint nem párosíthatók számlákhoz; a fel nem oldott pénzmozgási tételeket irányítsa a függő számlára. A kézi helyesbítés a bank/settlements/match { lineId, invoiceId } használatával történik, ahol a null értékű invoiceId megszünteti a párosítást.

Ezután könyveljen le egy egyensúlyban lévő tételt:

POST /v1/bank/settlements/post

Ez létrehoz egy egyensúlyban lévő naplót, elszámolja a párosított számlákat, megterheli a bankszámla főkönyvi számláját a nettó kifizetéssel, megterheli a díjakat, jóváírja a követeléseket a terhelésekért, sztornírozza a követeléseket a visszatérítésekért és visszterhelésekért, megosztja a nem párosított piactéri terheléseket a jutalékbevétel és az eladói kötelezettség között, ha a commissionPercent meg van adva, és a fel nem oldott összegeket a függő számlára küldi. Bármilyen kategória, amelyet nem ismer fel, szintén a függő számlára kerül, és a válasz egy figyelmeztetésben megnevezi ezeket a kategóriákat ahelyett, hogy csendben elnyelné őket.

Egyeztetési ellenőrzőlista

Végezze el ezeket az ellenőrzéseket minden zárás előtt:

  • Nincs duplikált balance_transaction_id
  • Nincs duplikált (provider, payout_id) elszámolási tétel
  • A sorok net összege megegyezik a tétel nettó összegével
  • A tétel nettó összege megegyezik a banki kifizetéssel, figyelembe véve az időzítési és devizapolitikai szabályokat
  • Minden visszatérítéshez tartozik eredeti terhelés vagy naplózott kivétel
  • Minden vitás ügyhöz tartozik vitás vagy terhelési hivatkozás
  • Minden átutaláshoz tartozik egy kapcsolt fiók azonosítója
  • Minden platform_earning sorhoz tartozik meghatározott jutalékkezelés
  • A függő számla egyenlege nulla vagy teljesen átvizsgált, beleértve a könyvelési figyelmeztetésben megnevezett minden ismeretlen kategóriát
  • Az eladói kötelezettség nem negatív jóváhagyott előleg vagy behajtási politika nélkül
  • A lekönyvelt tételek nem importálhatók vagy könyvelhetők újra csendben
  • A vállalat aldevizájától eltérő devizában történő kifizetés a kifizetés napi árfolyamán konvertálódik, az egyes számlák saját árfolyamától való eltérés realizált árfolyamnyereségként vagy veszteségként kerül könyvelésre; a devizákat keverő kifizetés az importálás során elutasításra kerül

Egyeztetzen három szinten: sor szinten (minden tranzakció megőrzött azonosítóval, kategóriával, összeggel, devizával, forrással rendelkezik), kifizetés szinten (a részletezett nettók megegyeznek a Stripe-kifizetéssel és a banki jóváírással), valamint főkönyvi szinten (a lekönyvelt napló egyensúlyban van, és létrehozza a tervezett bevétel-, díj-, követelés-, eladói kötelezettség- és függő pozíciókat). Kifejezetten az eladói egyenlegek tekintetében ellenőrizze, hogy a nyitó eladói kötelezettség plusz az új eladói részesedés, csökkentve az átutalásokkal és az érvényes sztornókkal, megegyezik-e a záró eladói kötelezettséggel.

Az összes piactéri főkönyvben visszatérő hiba ugyanaz, amivel kezdődött: egy strukturált kifizetés összevonása egyetlen számmá. Tartsa külön az összetevőket, rögzítse mindegyiket egy stabil Stripe-azonosítóhoz, és hagyja, hogy a függő számla tartsa azt, amit még nem tud megmagyarázni. A tiszta zárás az, amiben egy könyvvizsgáló megbízik.

FAQ

A Stripe-kifizetés a platform bevétele?

Nem. A kifizetés a terhelések, visszatérítések, feldolgozási díjak, eladói átutalások, viták és kiigazítások nettója, amelyek történetesen ugyanabban a tételben rendeződtek. Ha ezt egyetlen bevételezési tételként könyveljük, az elfedi az eladói kötelezettséget és a benne rejlő feldolgozási költséget. Egy közvetítői piactér esetében a bevétel a jutalék, amelyet a platform_earning sorok azonosítanak.

Melyik Stripe-jelentéssel kell egyeztetnem?

A Kifizetés-egyeztetés, részletezett (Payout reconciliation, itemized) jelentéssel, mivel egyenlegtranzakciónként egy sort ad reporting_category-val, automatic_payout_id-val, valamint bruttó, díj- és nettó összegekkel. A Vezérlőpult kifizetési összegzése csak a tétel összesített összegét igazolja. Ahol az automatikus kifizetések nincsenek engedélyezve, a helyett az egyenlegjelentést használja.

Könyvelni kell az eladónak szóló átutalást költségként?

Nem. Az eladó részesedése a vevői terhelés megérkezésekor válik kötelezettséggé, az átutalás pedig megszünteti ezt a kötelezettséget. Ha az átutalásokat költségként könyvelik, az duplán számolja el a költséget, és az eladói kötelezettséget tartósan túlértékelve hagyja.

Mi történik egy olyan Stripe-sorral, amelynek kategóriáját az importáló nem ismeri fel?

Az elszámolási függő számlára (alapértelmezés szerint 4440) könyvelődik, és a könyvelési válasz egy figyelmeztetést ad vissza, amely megnevezi az oda került kategóriákat. A tartalékok és a szokatlan kiigazítások általában így végzik, ami szándékos: a pénz látható marad, és a napló egyensúlyban marad, amíg valaki el nem dönti, hová tartozik.

Hogyan kell kezelni a későbbi kifizetés során rendeződő visszatérítéseket?

Ezek refund sorként érkeznek a későbbi kifizetés részletezett jelentésében, és a korábban párosított terhelés charge_id-jén keresztül visszakapcsolódnak az eredeti terheléshez. A terhelés-szintű Fizetések (Payments) exportból szintetizált visszatérítés ebben az esetben csak becslés, így a részletezett jelentés a biztonságosabb forrás.

További olvasnivalók