„Stripe Connect“ prekyvietės apskaitos darbo eiga

Dauguma prekyvietės (marketplace) apskaitos problemų kyla dėl vienos klaidos: „Stripe“ banko išmokos (payout) traktavimo kaip pajamų. Išmoka yra dešimčių atskirų ekonominių įvykių grynasis likutis, ir jos registravimas kaip vienos pajamų eilutės panaikina platformos komisinius, pardavėjo įsipareigojimus ir kiekvieną joje paslėptą mokestį bei ginčą. Teisinga darbo eiga išskaido išmoką prieš jai patenkant į didžiąją knygą.

Šiame vadove kiekviena „Stripe Connect“ balanso operacijų (balance transaction) kategorija priskiriama tinkamai apskaitos vietai: gautinoms sumoms (receivables), komisinių pajamoms, pardavėjų įsipareigojimams, apdorojimo sąnaudoms ir tarpinėms sąskaitoms (suspense). Čia naudojami „Nordlet“ dokumentuoti importo ir atsiskaitymų API galiniai taškai (endpoints) kaip registravimo mechanizmas, pateikiamas praktinis atsiskaitymo pavyzdys, o pabaigoje – suderinimo kontrolinis sąrašas, kurį galite atlikti prieš kiekvieną laikotarpio uždarymą.

Prieš ką nors planuojant, nustatykite „Connect“ mokėjimų modelį

Apskaitos taisyklių negalima sukurti, kol nežinote, kokį mokėjimų (charge) modelį naudoja kiekvienas mokėjimų srautas. Modelis lemia, kieno „Stripe“ balanse atsispindi mokėjimas, kam tenka mokesčiai ir kieno sąskaitą pirmiausia paliečia grąžinimai bei ginčai (disputes).

„Connect“ modelis	Mokėjimas sukuriamas	Padengia „Stripe“ mokesčius	Grąžinimai / ginčai sumažina	Apskaitos pasekmė
Tiesioginiai mokėjimai (Direct charges)	Susietoje paskyroje (Connected account)	Konfigūruojama kiekvienai šaliai	Susietos paskyros balansą	Platforma registruoja savo taikomąjį mokestį (application fee) kaip pajamas; pardavėjo mokėjimų veikla dažniausiai atsispindi susietos paskyros didžiojoje knygoje
Paskirties mokėjimai (Destination charges)	Platformoje, su nedelsiamu pervedimu į vieną susietą paskyrą	Platforma	Platformos balansą	Platforma registruoja pirkėjo gautiną sumą ir „Stripe“ mokestį; pardavėjo dalis yra mokėtina suma (payable), o ne pajamos
Atskiri mokėjimai ir pervedimai (Separate charges and transfers)	Platformos mokėjimas, po kurio seka vienas ar daugiau atskirų pervedimų	Platforma	Platformos balansą	Mokėjimas ir pardavėjo pervedimai yra atskiri įvykiai; pardavėjo įsipareigojimai sekami nepriklausomai nuo pirkėjo mokėjimo

Pačios „Stripe“ gairės apie kaip veikia mokėjimai „Connect“ integracijoje patvirtina, kad paskirties mokėjimų ir atskirų mokėjimų bei pervedimų atveju, platformos balansas padengia mokėjimų mokesčius, grąžinimus (refunds) bei pinigų grąžinimus po ginčų (chargebacks). Tiesioginių mokėjimų atveju, susieta paskyra gauna mokėjimą, o mokesčiai gali būti nuskaičiuoti nuo bet kurios šalies.

Praktinė taisyklė: nesakykite „Stripe išmoka yra pardavėjo pajamos“ arba „pardavėjas moka mokesčius“, kol nesate aiškiai apsibrėžę kiekvieno srauto mokėjimų modelio. Išsaugokite šį modelį prie kiekvienos operacijos. Tiesioginių ir paskirties mokėjimų sumaišymas pagal vieną registravimo taisyklę yra greičiausias būdas iškraipyti tiek pajamas, tiek įsipareigojimus.

Šiame vadove daroma prielaida, kad naudojami paskirties mokėjimai arba atskiri mokėjimai ir pervedimai, nes būtent čia platformos balansas neša visą apskaitos svorį ir būtent tokiam modeliui dažniausiai kuriamos prekyvietės didžiosios knygos.

Nubraižykite lėšų srautą prieš importuodami bent vieną eilutę

Prieš pradedant importuoti, nubraižykite vieno puslapio operacijų žemėlapį kiekvienam srautui:

Customer payment
  -> Stripe charge / payment balance transaction
  -> Stripe fee
  -> platform application fee (commission)
  -> transfer to connected account
  -> refund or dispute (if applicable)
  -> Stripe payout
  -> bank receipt

Kiekviena rodyklė yra atskira balanso operacija su savo ID, kategorija, suma ir datomis. Traktuokite „Stripe“ balansą kaip į banką panašią tarpinę (clearing) sąskaitą: mokėjimai įplaukia, mokesčiai ir pervedimai išplaukia, o išmoka likutį perveda į tikrą banką. „Nordlet“ banko ir mokėjimų importo dokumentacija rekomenduoja būtent taip elgtis su įprasta „Stripe“ veikla.

Pasirinkite tinkamą „Stripe“ šaltinio ataskaitą

Automatiškai išmokamiems atsiskaitymų paketams (automatic-payout settlement batches) naudokite „Stripe“ Payout reconciliation, itemized ataskaitą. Ji pateikia po vieną eilutę kiekvienai balanso operacijai, grupuoja eilutes pagal reporting_category, susieja kiekvieną su automatic_payout_id ir pateikia bruto, mokesčių bei neto sumas. „Stripe“ ataskaitų pasirinkimo gidas dokumentuoja šią ataskaitą ir patvirtina, kad charge_id, connected_account_id ir destination_payment_id yra prieinami „Connect“ laukai.

Ten, kur automatinės išmokos neįjungtos (kai kuriuose rankinių išmokų nustatymuose), naudokite „Balance“ ataskaitą. Netraktuokite prietaisų skydelio (Dashboard) išmokų suvestinės kaip pakankamo įrodymo registravimui apskaitoje. Suvestinė įrodo tik paketo bendrą sumą; tik detalizuota ataskaita paaiškina komponentus.

„Stripe“ rekomenduoja klasifikuoti pagal reporting_category, o ne pagal senesnį type lauką, o kiekviena eilutė turi source ID, kuris susieja ją su pagrindiniu objektu. Atkreipkite dėmesį į laiko apribojimą: „Stripe“ nurodo, kad kasdienių ataskaitų duomenys paprastai būna prieinami kitos dienos vidurdienį, o momentinės išmokos (instant payouts) negali būti švariai priskirtos atskiroms operacijoms, todėl joms reikalingas atskiras operacijų istorijos suderinimas.

Klasifikuokite kiekvieną balanso operaciją pagal kategoriją

Naudokite reporting_category kaip pagrindinį klasifikatorių, tada tikrinkite source_id, charge_id ir aprašymus. Svarbiausi atitikmenys:

„Stripe“ veikla	Ataskaitos kategorija	Apskaitos interpretacija
Pirkėjo mokėjimas, kortele arba vietiniu mokėjimo metodu	charge	Pirkėjo finansuojama gautina suma arba pardavimo atsiskaitymas
Grąžinimas	refund	Pradinio pirkėjo mokėjimo atšaukimas
„Stripe“ išskaičiuotas apdorojimo mokestis	fee	Mokėjimų apdorojimo sąnaudos
Platformos taikomasis mokestis (application fee)	platform_earning	Komisinių pajamos
Grąžintas taikomasis mokestis	platform_earning_refund	Komisinių pajamų sumažinimas
Pervedimas į susietą paskyrą	transfer	Pardavėjo įsipareigojimų sumažinimas
Atšauktas pervedimas	transfer_reversal	Lėšų atgavimas iš susietos paskyros
Ginčijamas mokėjimas (Chargeback)	dispute	Nuostolis dėl ginčo; patikrinkite šaltinio ginčo objektą
Laimėtas arba atšauktas ginčas	dispute_reversal	Anksčiau užregistruoto ginčo nuostolio atgavimas
Išmoka į banką	payout	Lėšų judėjimas banke, ne pajamos
Atšaukta išmoka	payout_reversal	Lėšų grįžimas į „Stripe“ balansą
Sulaikytas rezervas	connect_reserved_funds / risk_reserved_funds	Apribotos lėšos, pagal nutylėjimą ne sąnaudos
Ilgalaikio neigiamo balanso išieškojimas	connect_collection_transfer	Finansavimo ar atgavimo įvykis, kuriam reikalinga rizikos valdymo politika

Vienas terminologijos įspėjimas: senesniame balanso operacijų lauke type tiems patiems įvykiams naudojamos kitokios etiketės, tarp jų payment, application_fee ir adjustment. „Stripe“ balanso operacijų tipų dokumentacija pateikia abu žodynus. Nemaišykite type reikšmės į reporting_category taisyklę ir nekurkite tokios kategorijos kaip dispute_loss, kurios „Stripe“ neeksportuoja. Jei eksporte yra etiketė, kurios neatpažįstate, išsaugokite eksportuotą reikšmę ir patikrinkite ją pagal šaltinio objektą.

Įprastos prekyvietės veiklos registravimas didžiojoje knygoje

Platformai, naudojančiai paskirties mokėjimus (destination charges) arba atskirus mokėjimus ir pervedimus (separate charges and transfers), konceptualūs dvejybiniai įrašai yra šie.

Pirkėjo mokėjimas (pirkėjo pinigai patenka į „Stripe“ tarpinę / clearing sąskaitą):

Dr Stripe clearing        Gross customer charge
    Cr Trade receivables   Gross customer charge

„Stripe“ apdorojimo mokestis:

Dr Stripe fee expense      Stripe fee
    Cr Stripe clearing     Stripe fee

Neišskaičiuokite „Stripe“ mokesčio iš pajamų (netting), nebent jūsų apskaitos politika to aiškiai reikalauja ir palaiko grynąjį atvaizdavimą.

Platformos komisiniai (jūsų pajamos, atskirtos nuo to, kas kitu atveju priklausytų pardavėjui):

Dr Seller payable          Commission amount
    Cr Commission revenue   Commission amount

Pervedimas pardavėjui (atsiskaitymas už skolą, o ne sąnaudos):

Dr Seller payable          Transfer amount
    Cr Stripe clearing      Transfer amount

Pervedimas niekada nėra automatiškai sąnaudos. Pardavėjo dalis tampa įsipareigojimu, kai atliekamas mokėjimas, o pervedimas šį įsipareigojimą padengia. „Nordlet“ atsiskaitymų registravimo taisyklės vadovaujasi šiuo principu: platform_earning eilutės registruojamos kaip komisinių pajamos, o transfer eilutės mažina pardavėjo įsipareigojimus. Dokumentuoti numatytieji registravimo raktai yra settlements.commissionRevenue (numatytasis 5001), settlements.sellerPayable (numatytasis 4499), settlements.fees (numatytasis 6800) ir settlements.suspense (numatytasis 4440), kuriuos kiekvienai įmonei galima perrašyti per registravimo taisykles Nordlet API.

Registruokite grąžinimus susiejant juos su pradiniu pardavimu, o ne kaip pavienes banko operacijas

Grąžinimas susiejamas su pradiniu mokėjimu arba sąskaita faktūra. Konceptualiai:

Dr Refunds / sales reversals    Refund amount
    Cr Trade receivables         Refund amount

Realus įrašas priklauso nuo to, ar pardavimas buvo pripažintas, ar mokesčiai turi būti atšaukti, ir ar platformos taikomasis mokestis buvo grąžintas. Vienas grąžinimas gali lemti gautinos sumos atšaukimą, mokesčių atšaukimą, taikomojo mokesčio grąžinimą, pervedimo atšaukimą arba pardavėjui mokėtinos sumos sumažinimą, ir „Stripe“ mokesčių pasekmes, kurias reikia atidžiai patikrinti, o ne tiesiog daryti prielaidas.

Laiko spąstai: grąžinimas dažnai atsiskaitomas vėlesnėje išmokoje nei pradinis mokėjimas. Teikite pirmenybę detalizuotai išmokų suderinimo ataskaitai, o ne sintetintam grąžinimui iš mokėjimų lygio eksporto. „Nordlet“ dokumentacijoje aiškiai įspėjama, kad grąžinimas, sintetintas iš mokėjimų eksporto, yra tik apytikslis, kai grąžinimas atsiskaitomas vėliau. Atsiskaitymų importuotojas gali priimti grąžinimo eilutę, susieti ją su pradiniu pardavimu ir atšaukti gautiną sumą, kai paketas yra užregistruojamas.

Ginčus (disputes) traktuokite atskirai nuo grąžinimų

Ginčas yra kortelės turėtojo ar kortelę išdavusio banko pretenzija, ir „Stripe“ gali nuskaičiuoti tiek ginčijamą sumą, tiek ginčo mokestį (dispute fee) dar prieš priimant sprendimą. Paskirties mokėjimų ir atskirų mokėjimų bei pervedimų atveju „Stripe“ nuskaičiuoja abi sumas nuo platformos balanso, kaip nurodyta grąžinimų ir ginčų gairėse. Platforma gali bandyti atgauti lėšas atšaukdama pervedimą pardavėjui.

Pralaimėtas ginčas iš platformos pusės:

Dr Chargeback loss / receivable reopened   Disputed amount
Dr Dispute-fee expense                      Dispute fee
    Cr Stripe clearing                      Combined amount

Jei nuostolį prisiima pardavėjas ir atgavimas patvirtintas:

Dr Seller payable / recovery account   Recoverable amount
    Cr Chargeback recovery              Recoverable amount

Neregistruokite pardavėjo lėšų atgavimo vien todėl, kad buvo paprašyta atšaukti pervedimą. Įsitikinkite, kad atšaukimas buvo sukurtas, pavyko ir atsispindi „Stripe“ balanse. Jei ginčas laimimas, „Stripe“ grąžina ginčijamą sumą per dispute_reversal eilutę; atšaukite ginčo nuostolį ir atskirai sutvarkykite bet kokį ginčo mokestį, kurio „Stripe“ negrąžina. „Nordlet“ susieja ginčų eilutes naudodama anksčiau susieto mokėjimo charge_id iš to paties failo arba iš ankstesnio importo.

Praktinis atsiskaitymo pavyzdys

Paimkime vieną automatinių išmokų paketą. Detalizuotoje ataskaitoje yra:

• charge eilutė: bruto 100.00, „Stripe“ mokestis 3.20, neto 96.80
• platform_earning eilutė: 15.00, platformos komisiniai
• transfer eilutė: 81.80 susietam pardavėjui
• refund eilutė iš ankstesnio pardavimo: bruto 20.00, atsiskaitoma šiame pakete
• payout eilutė: paketo bendra suma, pervedama į banką

Išmokos sudėtis, vadovaujantis „Stripe“ atsiskaitymo formule:

Gross charges                100.00
- refunds                     20.00
- Stripe fees                  3.20
- transfers                   81.80
= net to platform balance     -5.00

platform_earning eilutė neperveda pinigų antrą kartą. Ji tik nurodo tuos 15.00, kurie lieka platformos balanse po to, kai išskaičiuojamas mokestis ir pardavėjo pervedimas, kad platforma galėtų pripažinti komisinių pajamas, o ne jas bandytų išvesti (infer).

Čia pardavėjo pervedimas kartu su grąžinimu viršija grynųjų mokėjimų aktyvumą, todėl paketo grynasis rezultatas yra šiek tiek neigiamas ir sumažina kitą išmoką arba panaudoja balanso likutį. Užregistruotas žurnalas atšaukia grąžintą gautiną sumą, pripažįsta 15.00 komisinių pajamų, užregistruoja 3.20 mokesčių sąnaudų, sumažina pardavėjui mokėtiną sumą pervedimu ir užregistruoja grąžinimo atšaukimą. Banko eilutė atitinka grynąją sumą, pasiekiančią sąskaitą. Nė vienas atskiras skaičius neatitinka „pajamų“, ir tai yra esmė.

Importas ir registravimas per „Nordlet“ atsiskaitymų API (endpoint)

Išmokos lygio suderinimui naudokite:

POST /v1/bank/settlements/import

su „Stripe“ tiekėju ir detalizuotu CSV. „Nordlet“ grupuoja eilutes pagal automatic_payout_id, kiekvieną išmoką paverčia atsiskaitymo paketu su bruto, mokesčių ir neto sumomis, praleidžia jau užregistruotų išmokų pakartotinius importus, praleidžia payout eilutes iš atsiskaitymo sudėties ir automatiškai susieja mokėjimų, grąžinimų bei ginčų eilutes naudodama užsakymų, sąskaitų faktūrų, „PaymentIntent“, mokėjimo, šaltinio ar metaduomenų nuorodas. „Stripe“ išskaido detalizuotą ataskaitą į atskirus failus kiekvienai sekcijai, todėl importuokite mokėjimų, grąžinimų ir mokesčių failus kartu: eilutės, priklausančios išmokai, kuri jau importuota, bet dar neužregistruota, susijungia į esamą paketą. Tai yra importavimo ir registravimo darbo eiga, paremta failais ir atsiskaitymų API galiniais taškais, o ne tiesioginė „Stripe“ integracija; funkcijų puslapyje nurodoma, ką apima banko ir atsiskaitymų pusė.

Susiekite iš eilės: mokėjimus su sąskaitomis faktūromis, grąžinimus su pradiniais mokėjimais, ginčus su pradiniais mokėjimais, komisinių eilutes su komisinių traktavimu. Neįtraukite „Stripe“ mokesčių, koregavimų, rezervų ir išmokų eilučių į sąskaitų faktūrų susiejimą. „Nordlet“ mokėjimų suderinimo žodynas nurodo, kad mokesčių ir koregavimų eilutės nėra susiejamos su sąskaitomis faktūromis pagal dizainą; nukreipkite neišspręstas pinigines operacijas į tarpines sąskaitas (suspense). Rankiniam koregavimui naudojama bank/settlements/match { lineId, invoiceId }, kur nurodžius null invoiceId atliekamas atsiejimas.

Tada užregistruokite vieną subalansuotą paketą:

POST /v1/bank/settlements/post

Tai sukuria vieną subalansuotą žurnalą, sudengia susietas sąskaitas faktūras, debetuoja banko sąskaitos didžiosios knygos sąskaitą neto išmokai, debetuoja mokesčius, kredituoja gautinas sumas už mokėjimus, atšaukia gautinas sumas už grąžinimus ir ginčus, padalina nesusietus prekyvietės mokėjimus tarp komisinių pajamų ir pardavėjui mokėtinų sumų, kai pateikiamas commissionPercent, ir nusiunčia neišspręstas sumas į tarpinę sąskaitą. Bet kokia kategorija, kurios sistema neatpažįsta, taip pat patenka į tarpinę sąskaitą, o atsake šios kategorijos įvardijamos įspėjime, užuot jas tyliai „prarijus“.

Suderinimo kontrolinis sąrašas

Prieš kiekvieną (laikotarpio) uždarymą patikrinkite šiuos teiginius:

• Nėra besidubliuojančių balance_transaction_id
• Nėra besidubliuojančio (provider, payout_id) atsiskaitymo paketo
• Eilučių net suma lygi paketo gryniajai (net) sumai
• Paketo grynoji suma lygi banko išmokai, atsižvelgiant į laiką ir valiutų politiką
• Kiekvienas grąžinimas turi pradinį mokėjimą arba užregistruotą išimtį
• Kiekvienas ginčas turi ginčo arba mokėjimo nuorodą
• Kiekvienas pervedimas turi susietos paskyros (connected-account) ID
• Kiekviena platform_earning eilutė turi apibrėžtą komisinių traktavimą
• Tarpinė sąskaita (suspense) lygi nuliui arba yra visiškai peržiūrėta, įskaitant visas neatpažintas kategorijas, įvardytas registravimo įspėjime
• Pardavėjui mokėtina suma nėra neigiama, nebent taikoma patvirtinta avanso arba išieškojimo politika
• Užregistruoti paketai negali būti tyliai iš naujo importuoti ar iš naujo užregistruoti
• Išmoka kita nei įmonės bazine valiuta konvertuojama pagal išmokos dienos kursą, o skirtumas, palyginti su kiekvienos sąskaitos faktūros kursu, registruojamas kaip realizuotas valiutos keitimo pelnas arba nuostolis; išmoka, kurioje maišomos valiutos, yra atmetama importuojant

Suderinkite trimis lygiais: eilutės (kiekviena operacija turi išsaugotą ID, kategoriją, sumą, valiutą, šaltinį), išmokos (detalizuotos neto sumos atitinka „Stripe“ išmoką ir banko įplaukas) ir didžiosios knygos (užregistruotas žurnalas subalansuoja ir sukuria numatytas pajamų, mokesčių, gautinų sumų, pardavėjo įsipareigojimų ir tarpinių sąskaitų pozicijas). Kalbant konkrečiai apie pardavėjų balansus, patikrinkite, ar pradinė pardavėjui mokėtina suma plius nauja pardavėjo dalis, atėmus pervedimus ir galiojančius atšaukimus, atitinka galutinę pardavėjui mokėtiną sumą.

Besikartojanti klaida kiekvienoje prekyvietės didžiojoje knygoje yra ta pati, nuo kurios ir pradėjome: struktūruotos išmokos sutraukimas į vieną skaičių. Laikykite komponentus atskirai, susiekite kiekvieną su stabiliu „Stripe“ identifikatoriumi ir leiskite tarpinei sąskaitai laikyti viską, ko dar negalite paaiškinti. Švarus (laikotarpio) uždarymas yra tai, kuo pasitikės auditorius.

D.U.K.

Ar „Stripe“ išmoka yra platformos pajamos?

Ne. Išmoka yra mokėjimų, grąžinimų, apdorojimo mokesčių, pervedimų pardavėjams, ginčų ir koregavimų, kurie buvo sudengti tame pačiame pakete, grynasis rezultatas. Jos registravimas kaip vienos pajamų eilutės panaikina joje esantį pardavėjo įsipareigojimą ir apdorojimo sąnaudas. Prekyvietei veikiant kaip tarpininkui (agent), pajamos yra komisiniai, kuriuos identifikuoja platform_earning eilutės.

Pagal kurią „Stripe“ ataskaitą turėčiau atlikti suderinimą?

Pagal „Payout reconciliation, itemized“ ataskaitą, nes ji pateikia po vieną eilutę kiekvienai balanso operacijai su reporting_category, automatic_payout_id ir bruto, mokesčių bei neto sumomis. Prietaisų skydelio (Dashboard) išmokų suvestinė įrodo tik bendrą paketo sumą. Ten, kur automatinės išmokos neįjungtos, naudokite „Balance“ ataskaitą.

Ar pervedimas pardavėjui turėtų būti registruojamas kaip sąnaudos?

Ne. Pardavėjo dalis tampa įsipareigojimu tuo momentu, kai gaunamas pirkėjo mokėjimas, o pervedimas šį įsipareigojimą padengia. Pervedimų registravimas kaip sąnaudų dvigubai skaičiuoja išlaidas ir palieka pardavėjui mokėtiną sumą nuolatos dirbtinai padidintą.

Kas nutinka „Stripe“ eilutei, kurios kategorijos importuotojas neatpažįsta?

Ji registruojama į atsiskaitymų tarpinę sąskaitą (suspense account), numatytąją 4440, o registravimo atsakyme grąžinamas įspėjimas, nurodantis ten patekusias kategorijas. Rezervai ir neįprasti koregavimai paprastai patenka būtent taip, ir tai daroma tyčia: pinigai išlieka matomi, o žurnalas lieka subalansuotas tol, kol kas nors nusprendžia, kur jie priklauso.

Kaip tvarkomi grąžinimai, kurie atsiskaitomi vėlesnėje išmokoje?

Jie gaunami kaip refund eilutė vėlesnės išmokos detalizuotoje ataskaitoje ir yra susiejami su pradiniu mokėjimu per anksčiau susieto mokėjimo charge_id. Grąžinimas, sintetintas iš mokėjimų lygio „Payments“ eksporto, šiuo atveju yra tik apytikslis, todėl detalizuota ataskaita yra saugesnis šaltinis.

Papildoma literatūra

• Banko ir mokėjimų importas, įskaitant „Stripe“ atsiskaitymų suderinimą
• Mokėjimų suderinimas: mokėjimų paslaugų teikėjo (PSP) išmokų susiejimas su didžiąja knyga
• Prekyvietės pardavėjų analitinė apskaita: pajamos prieš mokėtinas sumas
• Kaip veikia mokėjimai „Connect“ integracijoje („Stripe“)