Nordlet

← Tinklaraštis

Stripe Connect Marketplace Accounting Workflow

Praktinis gidas, padedantis teisingai registruoti Stripe Connect prekyvietės įplaukas, mokesčius, pervedimus, grąžinimus, ginčus ir rezervus į didžiąją knygą, kad atskaitomybė būtų tvarkinga.

Nordlet Team · · 12 min. skaitymo

Daugelis su prekyviečių apskaita susijusių problemų kyla dėl vienos pagrindinės klaidos: kai „Stripe“ bankinis išmokėjimas traktuojamas kaip pajamos. Išmokėjimas yra dešimčių atskirų ekonominių įvykių grynasis likutis, todėl jo registravimas kaip vienos pajamų eilutės panaikina platformos komisinį atlyginimą, pardavėjo prievoles bei visus išmokėjime paslėptus mokesčius ir ginčus. Teisingas darbo procesas išskaido išmokėjimą į sudedamąsias dalis dar prieš pateikiant duomenis į didžiąją knygą.

Šiame vadove parodyta, kaip kiekviena „Stripe Connect“ balansinių operacijų kategorija (balance-transaction) nukreipiama į jai priklausančią apskaitos sritį: gautinas sumas, komisinių pajamas, pardavėjo įsipareigojimus, apdorojimo sąnaudas ir laukiančias sumas (suspense). Procesas remiasi dokumentuotais „Nordlet“ importo ir atsiskaitymų galiniais punktais (endpoints), jame pateikiamas praktinis atsiskaitymo pavyzdys bei suderinimo kontrolinis sąrašas, kurį galima atlikti prieš kiekvieną uždarymą.

Prieš ką nors kuriant, nustatykite „Connect“ mokėjimo modelį

Apskaitos taisyklių negalima parašyti tol, kol nežinote, kurį mokėjimo srauto modelį naudoja kiekviena operacija. Modelis apibrėžia, kurioje „Stripe“ sąskaitoje registruojamas mokėjimas, kas padengia mokesčius ir kur pirmiausia nukreipiami pinigų grąžinimai bei ginčai.

„Connect“ modelis Mokėjimas sukuriamas Mokesčius padengia Grąžinimai / ginčai sumažina Pasekmės apskaitai
Tiesioginiai mokėjimai (Direct charges) Susietoje paskyroje Nustatoma kiekvienai šaliai atskirai Susietos paskyros balansą Platforma registruoja savo taikomą mokestį kaip pajamas; pardavėjo mokėjimų operacijos daugiausia registruojamos susietos paskyros didžiojoje knygoje
Paskirties mokėjimai (Destination charges) Platformoje, nedelsiant pervedant vienai susietai paskyrai Platformoje Platformoje Platforma registruoja kliento gautiną sumą ir „Stripe“ mokestį; pardavėjo dalis yra mokėtina suma, o ne pajamos
Atskiri mokėjimai ir pervedimai (Separate charges and transfers) Platformos mokėjimas, po kurio atliekamas vienas ar keli atskiri pervedimai Platformoje Platformoje Mokėjimas ir pardavėjo pervedimai yra atskiri įvykiai; pardavėjo įsipareigojimai sekami atskirai nuo kliento mokėjimo

Oficialios „Stripe“ gairės dėl to, kaip veikia mokėjimai „Connect“ integracijoje, patvirtina, kad naudojant paskirties mokėjimus bei atskirus mokėjimus ir pervedimus, platformos balansu dengiami mokėjimo mokesčiai, pinigų grąžinimai ir pinigų grąžinimo reikalavimai (chargebacks). Naudojant tiesioginius mokėjimus, mokėjimą gauna susieta paskyra, o mokesčiai gali būti nurašomi nuo bet kurios šalies.

Praktinė taisyklė: nesakykite, kad „Stripe“ išmokėjimas yra pardavėjo pajamos“ arba „pardavėjas moka mokesčius“ tol, kol neužsirašėte kiekvieno srauto mokėjimo modelio. Šį modelį saugokite kartu su kiekviena operacija. Tiesioginių ir paskirties mokėjimų maišymas taikant vieną registravimo taisyklę yra greičiausias būdas neteisingai parodyti tiek pajamas, tiek įsipareigojimus.

Šiame vadove daroma prielaida, kad naudojami paskirties mokėjimai arba atskiri mokėjimai ir pervedimai, nes būtent tada platformos balansui tenka apskaitinė naštos dalis ir būtent šiems atvejams kuriama didžioji prekyvietės knyga.

Prieš importuojant bent vieną eilutę, susidarykite lėšų srauto žemėlapį

Prieš prisiekiant prie importavimo, kiekvienam srautui nusipieškite vieno puslapio operacijų žemėlapį:

Kliento mokėjimas
  -> „Stripe“ mokėjimo / balanso operacija
  -> „Stripe“ mokestis
  -> platformos taikomas mokestis (komisinis)
  -> pervedimas susietai paskyrai
  -> pinigų grąžinimas arba ginčas (jei taikoma)
  -> „Stripe“ išmokėjimas
  -> įplauka banke

Kiekviena rodyklė yra atskira balansinė operacija, turinti savo ID, kategoriją, sumą ir datas. „Stripe“ balansą vertinkite kaip į banko panašią tarpinę (clearing) sąskaitą: lėšos įplaukia, mokesčiai ir pervedimai išplaukia, o išmokėjimas perkelia likutį į tikrąjį banką. „Nordlet“ bankinių ir mokėjimų importavimo dokumentacija rekomenduoja būtent tokį įprastos „Stripe“ veiklos tvarkymą.

Pasirinkite tinkamą „Stripe“ šaltinio ataskaitą

Automatinio išmokėjimo atsiskaitymo paketams naudokite „Stripe“ išmokėjimų suderinimo detaliąją ataskaitą (Payout reconciliation, itemized). Joje pateikiama po vieną eilutę kiekvienai balanso operacijai, eilutės grupuojamos pagal lauką reporting_category, kiekviena jų susiejama su automatic_payout_id ir pateikiamos bendrosios, mokesčių bei grynosios sumos. Oficialiame „Stripe“ ataskaitų pasirinkimo vadove dokumentuojama ši ataskaita ir patvirtinama, kad charge_id, connected_account_id bei destination_payment_id yra galimi „Connect“ laukai.

Jei automatiniai išmokėjimai neįgalinti (taikomi kai kurie rankinio išmokėjimo susitarimai), vietoj to naudokite balanso ataskaitą. Nelaikykite Valdymo skydelio (Dashboard) išmokėjimų suvestinės pakankamu įrodymu įrašams sukurti. Suvestinė įrodo tik paketo bendrą sumą, o komponentus paaiškina tik detali ataskaita.

„Stripe“ rekomenduoja klasifikuoti pagal lauką reporting_category, o ne pagal senesnį lauką type, ir kiekviena eilutė turi šaltinio (source) ID, kuris susiejamas su pagrindiniu objektu. Atkreipkite dėmesį į laiko apribojimą: „Stripe“ nurodo, kad kasdienės ataskaitos duomenys paprastai pasiekiami kitą dieną iki vidurdienio, o momentinių išmokėjimų negalima švariai priskirti individualioms operacijoms, todėl joms reikia atskiros operacijų istorijos suderinimo.

Klasifikuokite kiekvieną balanso operaciją pagal kategoriją

Kaip pagrindinį klasifikatorių naudokite reporting_category, tuomet peržiūrėkite source_id, charge_id ir aprašymus. Svarbiausia susiejimo schema:

„Stripe“ veikla Ataskaitos kategorija (reporting_category) Apskaitinis traktavimas
Kliento mokėjimas, kortelė arba vietinis mokėjimo būdas charge Kliento finansuojama gautina suma arba pardavimo suderinimas
Pinigų grąžinimas refund Pirminio kliento mokėjimo atšaukimas
„Stripe“ sulaikytas apdorojimo mokestis fee Mokėjimų apdorojimo sąnaudos
Platformos taikomas mokestis platform_earning Komisinės pajamos
Grąžintas platformos mokestis platform_earning_refund Komisinių pajamų sumažinimas
Pervedimas susietai paskyrai transfer Pardavėjo įsipareigojimo sumažinimas
Atšauktas pervedimas transfer_reversal Lėšų susigrąžinimas iš susietos paskyros
Pinigų grąžinimo reikalavimas (chargeback) dispute Nuostolis dėl ginčo; patikrinkite pirminį ginčo objektą
Laimėtas arba atšauktas ginčo reikalavimas dispute_reversal Anksčiau užregistruoto ginčo nuostolio atgavimas
Išmokėjimas į banką payout Lėšų judėjimas banke, o ne pajamos
Atšauktas išmokėjimas payout_reversal Lėšų grįžimas į „Stripe“ balansą
Sulaikytas rezervas connect_reserved_funds / risk_reserved_funds Apribotos lėšos, pagal nutylėjimą – ne sąnaudos
Ilgai delstojo neigiamo balanso surinkimas connect_collection_transfer Finansavimo arba susigrąžinimo įvykis, kuriam reikia rizikos politikos

Vienas terminologinis perspėjimas: senesniame balanso operacijų lauke type tiems patiems įvykiams naudojami kiti pavadinimai, tarp jų payment, application_fee ir adjustment. „Stripe“ balanso operacijų tipų dokumentacijoje pateikiami abu žodynai. Nemaišykite type reikšmės taisyklėje, skirtai reporting_category, ir nekurkite tokios kategorijos kaip dispute_loss, kurios „Stripe“ eksporte nėra. Jei eksportuojamame faile yra jūsų neatpažįstamas pavadinimas, išsaugokite eksportuotą reikšmę ir patikrinkite ją su pirminiu objektu.

Įregistruokite įprastą prekyvietės veiklą didžiojoje knygoje

Platformai, naudojančiai paskirties mokėjimus arba atskirus mokėjimus ir pervedimus, konceptualūs įrašai yra šie.

Kliento mokėjimas (kliento lėšos patenka į „Stripe“ tarpinę sąskaitą):

Dt Stripe tarpinė sąskaita (Stripe clearing)    Bendra kliento mokėjimo suma
    Kt Prekybos gautinos sumos (Trade receivables) Bendra kliento mokėjimo suma

„Stripe“ apdorojimo mokestis:

Dt Stripe mokesčių sąnaudos (Stripe fee expense) „Stripe“ mokestis
    Kt Stripe tarpinė sąskaita                    „Stripe“ mokestis

Neatskaitykite „Stripe“ mokesčio iš pajamų grynąja verte (net presentation), nebent jūsų apskaitos politika tam pritaria ir tai pagrindžia.

Platformos komisinis atlyginimas (jūsų pajamos, išskaičiuotos iš to, kas kitu atveju būtų mokėtina pardavėjui):

Dt Pardavėjo mokėtinos sumos (Seller payable) Komisinio suma
    Kt Komisinės pajamos (Commission revenue)      Komisinio suma

Pardavėjo pervedimas (skolos sumokėjimas, o ne sąnaudos):

Dt Pardavėjo mokėtinos sumos                  Pervedimo suma
    Kt Stripe tarpinė sąskaita                    Pervedimo suma

Pervedimas niekada automatiškai nėra sąnaudos. Pardavėjo dalis tampa įsipareigojimu, kai įplaukia mokėjimas, o pervedimas šį įsipareigojimą padengia. „Nordlet“ atsiskaitymo registravimo taisyklės remiasi tuo: platform_earning eilutės registruojamos komisinėse pajamose, o transfer eilutės sumažina pardavėjo įsipareigojimus. Dokumentuoti numatytieji registravimo raktai yra settlements.commissionRevenue (numatytoji vertė 5001), settlements.sellerPayable (numatytoji vertė 4499), settlements.fees (numatytoji vertė 6800) ir settlements.suspense (numatytoji vertė 4440). Kiekvieną iš jų galima individualiai nustatinėti kiekvienai įmonei per registravimo taisykles Nordlet API.

Tvarkykite pinigų grąžinimus susiedami su pradiniu pardavimu, o ne kaip atskirus banko elementus

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

Dt Grąžinimai / pardavimų atšaukimai (Refunds / sales reversals) Grąžinimo suma
    Kt Prekybos gautinos sumos                                        Grąžinimo suma

Tikrasis įrašas priklauso nuo to, ar pardavimas buvo pripažintas, ar reikia atšaukti PVM ir ar buvo grąžintas platformos komisinis mokestis. Vienas pinigų grąžinimas gali sukelti gautinos sumos atšaukimą, PVM atšaukimą, komisinio mokesčio grąžinimą, pervedimo atšaukimą arba pardavėjo įsipareigojimo sumažinimą, taip pat „Stripe“ mokesčio pasekmę, kurią privaloma patikrinti, o ne spėlioti.

Laiko spąstai: grąžinimas dažnai įvyksta vėlesniame išmokėjime nei pradinis mokėjimas. Pirmenybę teikite detaliajai išmokėjimų suderinimo ataskaitai, o ne apibendrintam grąžinimui iš mokėjimų lygio eksporto. „Nordlet“ dokumentacijoje aiškiai įspėjama, kad iš mokėjimų eksporto sudarytas grąžinimas tėra apytikslis, kai grąžinimas įvyksta vėliau. Atsiskaitymų importavimo įrankis gali priimti grąžinimo eilutę, priskirti ją pradiniam pardavimui ir atšaukti gautiną sumą, kai paketas užregistruojamas.

Ginčus vertinkite atskirai nuo pinigų grąžinimų

Ginčas yra kortelės turėtojo arba išduodančiojo banko pretenzija, ir „Stripe“ iki ginčo išsprendimo gali nurašyti tiek ginčijamą sumą, tiek ginčo mokestį. Naudojant paskirties mokėjimus bei atskirus mokėjimus ir pervedimus, „Stripe“ nurašo abu šiuos dydžius nuo platformos balanso, kaip nurodyta pinigų grąžinimų ir ginčų gairėse. Platforma gali bandyti atgauti lėšas atšaukdama pervedimą pardavėjui.

Pralaimėtas ginčas platformos požiūriu:

Dt Ginčo nuostolis / iš naujo atidaryta gautina suma (Chargeback loss / receivable reopened) Ginčijama suma
Dt Ginčo mokesčio sąnaudos (Dispute-fee expense)                                             Ginčo mokestis
    Kt Stripe tarpinė sąskaita                                                               Bendras suma

Jei nuostolį prisiima pardavėjas ir lėšų atgavimas patvirtintas:

Dt Pardavėjo mokėtinos sumos / susigrąžinimo sąskaita (Seller payable / recovery account) Atgautina suma
    Kt Ginčo lėšų atgavimas (Chargeback recovery)                                           Atgautina suma

Neregistruokite lėšų susigrąžinimo iš pardavėjo vien todėl, kad buvo paprašyta atšaukti pervedimą. Patikrinkite, ar atšaukimas buvo sukurtas, sėkmingai įvykdytas ir matomas „Stripe“ balanse. Jei ginčas laimėtas, „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“ suderina ginčo eilutes naudodama anksčiau suderinto mokėjimo charge_id – iš to paties failo arba iš ankstesnio importo.

Praktinis atsiskaitymo pavyzdys

Paimkite vieną automatinio išmokėjimo paketą. Detalioje ataskaitoje yra:

  • charge eilutė: bendra suma 100,00, „Stripe“ mokestis 3,20, grynoji suma 96,80
  • platform_earning eilutė: 15,00 (platformos komisinis)
  • transfer eilutė: 81,80 susietam pardavėjui
  • refund eilutė iš ankstesnio pardavimo: bendra suma 20,00, atsiskaitoma šiame pakete
  • payout eilutė: paketo suma, iškeliaujanti į banką

Išmokėjimo sudėtis, remiantis „Stripe“ atsiskaitymo tapatybe:

Bendri mokėjimai                 100,00
- grąžinimai                      20,00
- „Stripe“ mokesčiai               3,20
- pervedimai                      81,80
= grynoji suma platformos balanse   -5,00

platform_earning eilutė neperkelia pinigų antrą kartą. Ji nurodo 15,00 sumą, kuri lieka platformos balanse išskaičiavus mokestį ir pardavėjo pervedimą, kad platforma galėtų pripažinti komisiniines pajamas, o ne jas spėlioti.

Čia pardavėjo pervedimas ir grąžinimas viršija grynųjų mokėjimų veiklą, todėl paketo bendras rezultatas yra nedidelis neigiamas likutis, kuris sumažina kitą išmokėjimą arba nuspaudžiamas nuo balanso. Užregistruotas žurnalo įrašas anuliuoja grąžintą gautiną sumą, pripažįsta 15,00 komisinių pajamų, užregistruoja 3,20 mokesčio sąnaudas, sumažina pardavėjo mokėtinas sumas pervedimo suma ir įrašo grąžinimo anuliavimą. Banko eilutė sutampa su į sąskaitą atkeliaujančia grynąja suma. Nė viena atskira suma nepasako, kas yra „pajamos“, o tai ir yra esmė.

Importavimas ir registravimas per „Nordlet“ atsiskaitymo galinį punktą

Išmokėjimų lygio suderinimui naudokite:

POST /v1/bank/settlements/import

su „Stripe“ teikėju ir detaliuoju CSV failu. „Nordlet“ sugrupuoja eilutes pagal automatic_payout_id, paverčia kiekvieną išmokėjimą atsiskaitymo paketu su bendromis, mokesčių bei grynosiomis sumomis, praleidžia pakartotinį jau užregistruoto išmokėjimo importavimą, praleidžia payout eilutes iš atsiskaitymo sudėties ir automatiškai suderina mokesčio, grąžinimo bei ginčo eilutes naudodama užsakymų, sąskaitų faktūrų, PaymentIntent, mokėjimų, šaltinio arba metaduomenų nuorodas. „Stripe“ išskiria detaliąją ataskaitą į po vieną failą kiekvienai skiltiai, todėl importuokite mokesčio, grąžinimo ir rinkliavų failus kartu: eilutės, priklausančios išmokėjimui, kuris jau importuotas, bet dar neužregistruotas, susilieja į esamą paketą. Tai importavimo ir registravimo procesas, valdomas failais ir atsiskaitymų galiniais punktais, o ne tiesioginis „Stripe“ jungiamasis įtaisas; funkcijų puslapyje nurodyta, ką apima banko ir atsiskaitymų dalis.

Suderinkite tokia tvarka: mokėjimus su sąskaitomis faktūromis, grąžinimus su pradiniais mokėjimais, ginčus su pradiniais mokėjimais, komisinių eilutes su komisinių traktavimu. Laikykite „Stripe“ mokesčius, koregavimus, rezervus ir išmokėjimų eilutes toliau nuo sąskaitų faktūrų suderinimo. „Nordlet“ mokėjimų suderinimo žodyne teigiama, kad mokesčių ir koregavimo eilutės pagal paskirtį nėra suderinamos su sąskaitomis faktūromis; neatpažintus lėšų elementus nukreipkite į laukiančių sumų (suspense) sąskaitą. Rankinis taisymas atliekamas per bank/settlements/match { lineId, invoiceId }, nurodant null reikšmę invoiceId, jei norima atšaukti suderinimą.

Tuomet užregistruokite vieną subalansuotą paketą:

POST /v1/bank/settlements/post

Tai sukuria vieną subalansuotą žurnalo įrašą, sudengia suderintas sąskaitas faktūras, debetuoja banko sąskaitos didžiąją knygą grynajam išmokėjimui, debetuoja mokesčius, kredituoja gautinas sumas už mokėjimus, atšaukia gautinas sumas už grąžinimus ir ginčus, padalija nesuderintus prekyvietės mokėjimus tarp komisinių pajamų ir pardavėjo mokėtinų sumų, kai nurodytas laukas commissionPercent, o neišspręstas sumas išsiunčia į laukiančių sumų sąskaitą. Visos jos neatpažintos kategorijos taip pat patenka į laukiančių sumų sąskaitą, o atsakyme šios kategorijos įvardijamos įspėjime, o ne tyliai paslepiamos.

Suderinimo kontrolinis sąrašas

Prieš kiekvieną uždarymą patikrinkite šiuos teiginius:

  • Nėra pasikartojančių balance_transaction_id
  • Nėra pasikartojančių (provider, payout_id) atsiskaitymo paketų
  • Eilučių grynųjų sumų (net) suma lygi paketo gryonajai sumai
  • Paketo grynoji suma lygi banko išmokėjimui, atsižvelgiant į laiko ir valiutos politiką
  • Kiekvienas grąžinimas turi pradinį mokėjimą arba registruotą išimtį
  • Kiekvienas ginčas turi ginčo arba mokėjimo nuorodą
  • Kiekvienas pervedimas turi susietos paskyros ID
  • Kiekviena platform_earning eilutė turi apibrėžtą komisinį traktavimą
  • Laukiančių sumų sąskaitos (suspense) likutis yra nulinis arba visiškai peržiūrėtas, įskaitant visas neatpažintas kategorijas, nurodytas registravimo įspėjime
  • Pardavėjo mokėtinos sumos nėra neigiamos be patvirtinto avanso arba lėšų atgavimo politikos
  • Užregistruotų paketų negalima tyliai importuoti iš naujo arba registruoti pakartotinai
  • Išmokėjimas valiuta, nesutampančia su įmonės bazine valiuta, konvertuojamas pagal išmokėjimo dienos kursą, o skirtumas, lyginant su kiekvienos sąskaitos faktūros asmeniniu kursu, registruojamas kaip realizuotas valiutos kurso pelnas arba nuostolis; išmokėjimas, kuriame sumaišytos valiutos, importuojant atmetamas

Suderinimą atlikite trimis lygiais: eilutės (kiekviena operacija turi išsaugotą ID, kategoriją, sumą, valiutą, šaltinį), išmokėjimo (detalieji grynieji likučiai lygūs „Stripe“ išmokėjimui ir banko įplaukai) ir didžiosios knygos (užregistruotas žurnalas subalansuotas ir sukuria norimas pajamų, mokesčių, gautinų sumų, pardavėjo įsipareigojimų ir laukiančių sumų pozicijas). Kalbant konkrečiai apie pardavėjų balansus, patikrinkite, ar pradinės pardavėjo mokėtinos sumos plius nauja pardavėjo dalis, atėmus pervedimus ir galiojančius atšaukimus, yra lygios baigiamosioms pardavėjo mokėtinoms sumoms.

Pasikartojanti problema kiekvienoje prekyvietės didžiojoje knygoje yra ta pati, nuo kurios ir pradėta: struktūrizuoto išmokėjimo sutraukimas į vieną skaičių. Laikykite komponentus atskirai, kiekvieną jų pririškite prie stabilaus „Stripe“ identifikatoriaus, o laukiančių sumų sąskaitoje palikite tai, ko dar negalite paaiškinti. Tvarkingas laikotarpio uždarymas yra tai, kuo pasitikės auditorius.

D.U.K.

Ar „Stripe“ išmokėjimas yra platformos pajamos?

Ne. Išmokėjimas yra tame pačiame pakete atsidūrusių mokėjimų, grąžinimų, apdorojimo mokesčių, pardavėjų pervedimų, ginčų ir koregavimų grynasis rezultatas. Jo registravimas kaip vienos pajamų eilutės panaikina pardavėjo įsipareigojimą ir jame paslėptas apdorojimo sąnaudas. Agentinės prekyvietės atveju pajamos yra komisinis mokestis, kurį identifikuoja platform_earning eilutės.

Su kuria „Stripe“ ataskaita turėčiau atlikti suderinimą?

Su detaliąja išmokėjimų suderinimo ataskaita (Payout reconciliation, itemized), nes joje pateikiama po vieną eilutę kiekvienai balanso operacijai su nurodyta reporting_category, automatic_payout_id bei bendromis, mokesčių ir grynomis sumomis. Valdymo skydelio išmokėjimų suvestinė įrodo tik paketo bendrą sumą. Jei automatiniai išmokėjimai neįgalinti, vietoj to naudokite balanso ataskaitą.

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

Ne. Pardavėjo dalis tampa įsipareigojimu tą akimirką, kai įplaukia kliento mokėjimas, o pervedimas šį įsipareigojimą padengia. Registruojant pervedimus kaip sąnaudas, išlaidos padvigubinamos, o pardavėjo mokėtinos sumos lieka nepagrįstai išpūstos.

Kas nutinka su „Stripe“ eilute, kurios importavimo įrankis neatpažįsta?

Ji patenka į atsiskaitymų laukiančių sumų (suspense) sąskaitą (numatytoji vertė 4440), o registravimo atsake grąžinamas įspėjimas, kuriame įvardijamos ten patekusios kategorijos. Rezervai ir neįprasti koregavimai paprastai patenka būtent taip, ir tai daroma sąmoningai: pinigai išlieka matomi, o žurnalas lieka subalansuotas, kol kas nors nusprendžia, kur jiems vieta.

Kaip tvarkomi pinigų grąžinimai, kurie įvyksta vėlesniame išmokėjime?

Jie atkeliauja kaip refund eilutė vėlesnio išmokėjimo detalsiojoje ataskaitoje ir yra suderinami su pradiniu mokėjimu per anksčiau suderinto mokėjimo charge_id. Iš mokėjimų lygio eksporto sudarytas grąžinimas šiuo atveju yra tik apytikslis, todėl detalioji ataskaita yra saugesnis šaltinis.

Papildomas skaitymas