Kas yra dvejybinio įrašo didžiosios knygos API prekyvietėms?
Dvejybinio įrašo didžiosios knygos API registruoja prekyvietės pinigų judėjimą kaip subalansuotus, nekintamus žurnalo įrašus, todėl visada žinote, kam ir kiek esate skolingi ir kodėl.
Prekyvietė savo orders lentelėje gali atrodyti puikiai ir vis tiek klysti dėl savo pinigų. Užsakymo būsena rodo „apmokėta“. Pardavėjo skydelyje matomas likutis. Tačiau niekas toje lentelėje neįrodo, kiek pinigų platforma iš tikrųjų turi, kiek yra skolinga kiekvienam pardavėjui, kokia mokėjimo dalis yra komisinių pajamos ir kiek PVM dabar tapo mokėtinas. Dvejybinio įrašo didžiosios knygos API kaip tik ir egzistuoja tam, kad teisingai užregistruotų šias finansines pasekmes — po vieną subalansuotą operaciją.
Paprastai tariant, dvejybinio įrašo didžiosios knygos API yra programuojama apskaitos sistema. Jūsų programa siunčia jai finansinį įvykį, pavyzdžiui, nuskaitytą mokėjimą ar patvirtintą išmokėjimą, o didžioji knyga užrašo tą įvykį kaip žurnalo operaciją su lygiais debetais ir kreditais įvardytose sąskaitose. Ji pati pinigų neperveda. Ji registruoja tiesą apie pinigus, kurie pajudėjo kitur.
Ką čia reiškia „dvejybinio įrašo didžioji knyga“
Didžioji knyga yra sąskaitų pokyčių įrašas, o ne lentelė, kurioje saugomas paskutinis likutis. Veikianti didžioji knyga remiasi trimis tarpusavyje susijusiomis sąvokomis:
- Sąskaita: įvardyta finansinė pozicija, pavyzdžiui, gautinos sumos iš mokėjimų paslaugų teikėjo, mokėtinos sumos pardavėjui, komisinių pajamos arba mokėtinas PVM.
- Operacija (žurnalo įrašas): vienas atominis finansinis įvykis, sudarytas iš kelių subalansuotų eilučių.
- Įrašas (registravimas): viena debeto arba kredito eilutė toje operacijoje.
Invariantas, ant kurio laikosi visa konstrukcija, yra paprastas: bendra debetų suma lygi bendrai kreditų sumai — kiekvienoje operacijoje ir kiekvienoje valiutoje. Didžiosios knygos API paprastai atmeta nesubalansuotą įrašą dar prieš jam pasiekiant saugyklą. „Modern Treasury“ dokumentacijoje didžiosios knygos operacija apibrėžiama kaip apimanti dvi ar daugiau sąskaitų su bent vienu debetu ir vienu kreditu, kurių sumos lygios, o užregistruota operacija laikoma nekintama.
Dvejybinis įrašas nereiškia lygiai dviejų eilučių. Vienam prekyvietės pardavimui dažnai reikia vieno debeto ir kelių kreditų. Būtent šią detalę žmonės supranta neteisingai dažniausiai.
Kodėl prekyvietėms reikia didžiosios knygos, o ne tik mokėjimų lentelės
Prekyvietė tuo pačiu metu palaiko kelis finansinius santykius. Pirkėjas sumoka. Mokėjimų paslaugų teikėjas atsiskaito. Platforma kurį laiką gali valdyti lėšas. Pardavėjas uždirba savo dalį. Platforma pasilieka komisinius. Atsiranda mokėtinas mokestis. Gali būti sulaikomas rezervas. Vėliau išmokėjimas išveda pinigus, o grąžinimai ar mokėjimų ginčijimai (chargeback) dalį to atsuka atgal.
payments lentelė gali pasakyti komercinę užsakymo būseną. Ji negali patikimai pasakyti:
- kiek yra gautinų sumų iš mokėjimų teikėjo arba grynųjų pinigų
- kiek skolinga kiekvienam pardavėjui
- kiek pajamų priklauso pačiai platformai
- kiek PVM yra mokėtina ir kurioje šalyje
- kiek sulaikyta rezerve grąžinimams ar ginčams
- ar išmokėjimas sumažino teisingą įsipareigojimą pardavėjui
- ar mokėjimų teikėjo atsiskaitymai sutampa su tuo, ko platforma tikėjosi
Nordlet dvejybinio įrašo didžiosios knygos API vadovas prekyviečių apskaitai šią ribą nubrėžia aiškiai: programos lentelės aprašo produkto būseną, o didžioji knyga registruoja tos būsenos finansines pasekmes. Jame taip pat pakartojama mintis, kurią verta įsidėmėti: mokėjimų paslaugų teikėjo ataskaitos yra duomenų derinimo šaltinis, o ne pilnavertė dvejybinio įrašo apskaita.
Prekyvietės pardavimo pavyzdys
Tarkime, pirkėjas sumoka 100 €, pardavėjui priklauso 85 €, o platformos komisiniai — 15 €. Aiškumo dėlei PVM ir mokėjimų teikėjo mokesčių neskaičiuojame.
| Sąskaita | Debetas | Kreditas | Priežastis |
|---|---|---|---|
| Gautinos sumos iš mokėjimų teikėjo | 100 € | Teikėjas skolingas platformai nuskaitytą mokėjimą | |
| Mokėtinos sumos pardavėjui | 85 € | Platforma skolinga pardavėjui | |
| Komisinių pajamos | 15 € | Platforma uždirbo savo komisinius | |
| Iš viso | 100 € | 100 € | Subalansuota |
Svarbiausia klasifikacijos detalė čia ta, kad pardavėjui priklausantys 85 € yra įsipareigojimas, o ne platformos pajamos. Pagal TFAS konceptualiąją sistemą įsipareigojimas yra esama prievolė perduoti ekonominį išteklių. Prekyvietė neturėtų rodyti viso pardavėjo pardavimo kaip savo pajamų vien todėl, kad pirkėjas sumokėjo per ją. Tai, ar veikiate kaip agentas, pardavėjas savo vardu, ar tariamas tiekėjas, keičia apskaitos traktavimą, tačiau didžiosios knygos mechanika lieka ta pati.
Kai pardavėjui atsiranda teisė gauti išmokėjimą, jokios naujos pajamos nepripažįstamos. Padengiamas įsipareigojimas:
| Sąskaita | Debetas | Kreditas |
|---|---|---|
| Mokėtinos sumos pardavėjui | 85 € | |
| Bankas arba išmokėjimų tarpinė sąskaita | 85 € | |
| Iš viso | 85 € | 85 € |
Jei mokėjimų teikėjas prieš atsiskaitymą nuskaito 3 € mokestį, pinigų judėjimas tampa trijų eilučių žurnalo įrašu: 97 € į banko sąskaitą, 3 € į mokėjimų apdorojimo sąnaudas, 100 € iš gautinų sumų iš teikėjo. Kiekvienas pozicijos pokytis turi šaltinį ir paskirtį.
Kaip API veikia, žingsnis po žingsnio
1. Jūsų programa aptinka verslo įvykį. Nuskaitomas mokėjimas, įvykdomas užsakymas, patvirtinamas išmokėjimas, grąžinami pinigai, pradedamas mokėjimo ginčijimas, gaunamas atsiskaitymas. Jūsų duomenų bazė ir toliau valdo operacinę būseną. Didžioji knyga registruoja piniginį poveikį.
2. Siunčiate struktūrizuotą užklausą. Joje paprastai nurodomas įvykio tipas, suma ir valiuta, užsakymo ar mokėjimo ID, pirkėjo ir pardavėjo identifikatoriai, komisiniai, mokesčių duomenys, susijusios sąskaitos, įsigaliojimo ir registravimo datos, idempotentiškumo raktas bei metaduomenys, siejantys įrašą su teikėjo ir produkto duomenimis. Viešame Nordlet API pavyzdyje matomas apibendrintas pardavimo užklausos pavidalas su pardavėjo ID, pardavimo tipu, suma, valiuta bei PVM šalimi ir tarifu.
3. API patikrina duomenis. Tikrinama, ar debetai ir kreditai subalansuoti, ar sąskaitos egzistuoja ir į jas galima registruoti, ar valiuta palaikoma, ar suma tvarkoma tiksliai mažiausiais valiutos vienetais, ar idempotentiškumo raktas nenaudojamas pakartotinai kitam rezultatui, ar laikotarpis atviras ir ar pateikti privalomi metaduomenys. Nepavykus patikrai, jokio dalinio žurnalo įrašo nelieka.
4. Įrašoma atomiškai. Visa operacija įrašoma kaip vienas vienetas. Neturi būti įmanoma užregistruoti debeto, kai atitinkamas kreditas nepavyksta. Prekyvietėje dalinis įrašas sukurtų tariamą pardavėjo likutį be atitinkamų pinigų arba užregistruotų komisinius be įsipareigojimo pardavėjui.
5. Likučiai ir ataskaitos išvedami iš didžiosios knygos. Užregistravus galima nuskaityti sąskaitų likučius, pardavėjo laukiančias ir prieinamas sumas, bandomąjį balansą, didžiosios knygos judėjimus, PVM suvestines ir istoriją bet kuriai praėjusiai datai. Pardavėjo likutis turi būti atkuriamas iš įrašų, o ne pasitikimas kaip kintamas laukelis.
6. „Webhook“ pranešimai informuoja jūsų produktą. Įvykiai, tokie kaip sale_invoice.paid, užregistruotas žurnalo įrašas, atsiradęs galimas išmokėjimas ar derinimo neatitikimas, atsiunčiami jums. Apdorokite juos idempotentiškai. „Webhook“ pranešimas yra pranešimas, o ne leidimas pritaikyti finansinį įvykį antrą kartą. API susitarimai išsamiai aprašo apimtis (scopes), idempotentiškumo raktus, klaidų formatą ir „webhook“ parašus.
Pardavėjo likutis nėra vienas skaičius
Dauguma prekyviečių įklimpsta būtent todėl, kad pardavėjo likutį traktuoja kaip vieną skaičių. Pinigai turėtų būti skirstomi į būsenas:
| Būsena | Ką ji reiškia |
|---|---|
| Laukia (Pending) | Pardavėjui gali priklausyti, bet išleidimo sąlygos dar neįvykdytos |
| Prieinamas (Available) | Tinkamas išmokėti |
| Rezervuotas (Reserved) | Sulaikyta grąžinimams, prekių grąžinimui ar ginčams |
| Išmokėtas (Paid out) | Įsipareigojimas padengtas pervedimu |
| Neigiamas (Negative) | Grąžinimai, ginčijimai ar mokesčiai viršija turimas lėšas |
Mokėjimų teikėjų modeliai tai atkartoja. „Stripe“ atskirų mokėjimų ir pervedimų (separate charges and transfers) schema leidžia platformai nuskaityti mokėjimą į savo sąskaitą, o tada pervesti dalis į prijungtas sąskaitas, kai mokesčiai, grąžinimai ir ginčijimai atsiduria platformos likutyje. „Adyen“ prekyviečių modelyje atskiriamos naudotojų likučių sąskaitos, kuriose lėšos laikomos iki išmokėjimo, ir atsakomybės likučio sąskaita, galinti padengti neigiamus likučius dėl grąžinimų ar ginčijimų. Tai naudingi jūsų didžiosios knygos duomenų šaltiniai. Tai nėra jūsų pilnas apskaitos modelis.
Išmokėjimai ir pardavėjo uždarbis įvyksta skirtingu metu
Pardavėjas gali uždirbti pirmadienį, o pinigus gauti kitą pirmadienį. Tarp šių taškų užsakymas įvykdomas, sulaikomas rezervas, suformuojama išmokėjimų partija, teikėjas atsiskaito atėmęs mokesčius, ir galiausiai į banką ateina įplauka. Didžioji knyga turi išsaugoti kiekvieną etapą, o ne perrašyti užsakymą galutine „apmokėta“ būsena. Būtent tai leidžia paaiškinti laiko skirtumus tarp užsakymų srauto, pardavėjo teisės į lėšas, atsiskaitymo, išmokėjimo inicijavimo ir lėšų gavimo banke.
Grąžinimai ir ginčijimai: stornuokite, o ne perrašykite
Grąžinimai ir mokėjimų ginčijimai yra nauji įvykiai, susieti su pirminiu mokėjimu. Nekintamoje didžiojoje knygoje taisoma stornuojančiu įrašu, po kurio seka pataisytas įrašas, todėl pirminis įrašas lieka matomas auditui. „Modern Treasury“ užregistruotas operacijas laiko nekintamomis ir naudoja idempotentiškumo raktus, kad pakartotinės užklausos nesukurtų dublikatų.
Grąžinimas paprastai sumažina pinigus arba gautinas sumas iš pirkėjo, atsuka mokėtinas sumas pardavėjui, priklausomai nuo politikos gali atsukti dalį komisinių, koreguoja mokestį ir gali sunaudoti grąžinimų rezervą. Ginčijimas sumažina pinigus arba gautinas sumas iš teikėjo, gali atkurti pardavėjo ar platformos skolą, užregistruoja ginčo sąnaudas ir teikėjo mokestį bei perveda lėšas per rezervo sąskaitą.
Duomenų derinimas: didžiosios knygos sujungimas su tikrais pinigais
Didžioji knyga gali būti vidiniškai subalansuota ir vis tiek klysti dėl išorinio pasaulio. Derinimas lygina vidinius įrašus su išoriniais įrodymais: teikėjo atsiskaitymų ataskaitomis, banko išrašais, išmokėjimų failais, grąžinimų ir ginčų duomenimis.
Veikianti seka atrodo taip:
- Importuokite atsiskaitymo arba banko partiją.
- Susiekite kiekvieną eilutę su užsakymu, mokėjimu, grąžinimu, mokesčiu, išmokėjimu ar ginču.
- Palyginkite laukiamą bendrą sumą, atskaitymus, rezervus ir grynąją sumą.
- Užregistruokite patvirtintus judėjimus didžiojoje knygoje.
- Nesusietas eilutes nukreipkite į įvardytą tarpinę (suspense) sąskaitą.
- Ištirkite neatitikimus.
- Užrakinkite laikotarpį.
Nordlet duomenų derinimo medžiagoje aprašomas būtent toks procesas: atsiskaitymų partijų importas, mokėjimo ir grąžinimo eilučių susiejimas ir nesusietų įplaukų nukreipimas į tarpinę sąskaitą, užuot spėliojus, kuriai sąskaitai faktūrai jos priklauso. Svarbios dvi patikros, ir viena nepakeičia kitos: dvejybinio įrašo patikra klausia, ar kiekvienas žurnalo įrašas subalansuotas, o derinimas klausia, ar jis sutampa su teikėjo, banko ir verslo įvykio duomenimis.
Techninės detalės, nulemiančios, ar viskas veiks teisingai
Idempotentiškumas. Susiekite raktą su stabiliu įvykiu, pavyzdžiui, payment_captured:pi_123. Pakartota užklausa grąžina pirminį rezultatą, o ne sukuria antrą žurnalo įrašą.
Atomiškumas. Visos vieno įvykio eilutės registruojamos kartu arba nė viena.
Nekintamumas ir stornavimai. Užregistruota istorija neredaguojama įprastais atnaujinimais. Taisymai sukuria susietus įrašus, išsaugančius pirminę sumą, datą, klasifikaciją, priežastį ir autorių.
Tikslūs pinigai. Jokių dvejetainių slankiojo kablelio skaičių. Naudokite sveikuosius skaičius mažiausiais valiutos vienetais arba tikslius dešimtainius skaičius, aiškiai nurodytą valiutą ir determinuotą apvalinimo taisyklę dalijimams. Padalykite 100 € tarp pardavėjų ir mokesčių be tokios taisyklės, ir vienas nuklydęs centas sugriaus balansą.
Įsigaliojimo ir registravimo datos. Kada pirkėjas sumokėjo, kada pardavėjas uždirbo, kada bankas atsiskaitė ir kada įrašas buvo užregistruotas — tai skirtingos datos. Jas sulyginus, laikotarpių ataskaitos ir mokesčių terminai tampa nepatikimi.
Kelios valiutos. Debetas ir kreditas turi subalansuoti tos pačios valiutos ribose. Konvertavimui reikia atskiro kurso įvykio su sąskaitomis mokesčiui, apvalinimui ir bet kokiam valiutų kurso pelnui ar nuostoliui. Tai, kad API priima currency lauką, dar nepadaro jos valiutų keitimo varikliu.
Ko didžiosios knygos API už jus nepadarys
Ji nenuspręs jūsų sąskaitų plano. Jums vis tiek reikės nustatyti, ar veikiate kaip agentas, ar kaip pardavėjas savo vardu, kada uždirbami komisiniai, kuri šalis padengia mokėjimų teikėjo mokesčius, kaip grąžinimai veikia komisinius ir kaip skaičiuojamas bei deklaruojamas PVM. Pati Nordlet rekomendacija yra pirmiausia išsiaiškinti pinigų srautus, tada parengti sąskaitų planą, duoti jį peržiūrėti buhalteriui ir tik tada įgyvendinti vieną pilną srautą nuo užsakymo iki išmokėjimo ir derinimo, prieš plečiant apimtį.
Ji neišspręs mokestinių klausimų. PVM priklauso nuo pirkėjo ir pardavėjo vietos, prekės tipo, registracijos statuso ir tariamo tiekėjo taisyklių; ES PVM vadove aprašyta, ką variklis išveda pats ir ką pažymi žmogaus peržiūrai. Nordlet PVM aprėptis orientuota į ES ir EEE, todėl ji neapima JAV pardavimo mokesčio ar Lotynų Amerikos e. sąskaitų faktūrų. Ji taip pat neišspręs operacinių dviprasmybių: ar pasibaigė grąžinimo terminas, ar reikia blokuoti išmokėjimą, ar mokėjimas yra apgaulingas. Tai jūsų sprendimai. Didžioji knyga registruoja jų finansinį rezultatą.
Kur tinka Nordlet
Nordlet yra apskaitos API, sukurta platformoms ir prekyvietėms, su nekintama dvejybinio įrašo didžiąja knyga, išmokėjimais, ES PVM tvarkymu, REST galiniais taškais, tipizuotais SDK ir „webhook“ pranešimais viename paviršiuje. Ją išskiria pasirinkimas įterpti apskaitą į jūsų pačių produktą, o ne naudoti trečiosios šalies atsiskaitymo langą. Šio teksto rašymo metu produktas yra ankstyvosios prieigos etape su testine aplinka dizaino partneriams, todėl vertinkite jį kaip gerą šios kategorijos pavyzdį ir prieš įsipareigodami patikrinkite gamybinę brandą, veikimo patikimumą ir jurisdikcijų aprėptį pagal savo poreikius.
Prekyviečių ir platformų kūrėjams naudingiausias mąstymo modelis yra skirtis tarp pinigų judėjimo ir finansinės tiesos. Jūsų mokėjimų teikėjas perveda pinigus. Dvejybinio įrašo didžiosios knygos API registruoja, kam ir kiek esate skolingi, ką uždirbote, kokius mokesčius ir rezervus turite ir ar išorinis pasaulis sutampa su jūsų apskaita.
D.U.K.
Ar dvejybinio įrašo didžiosios knygos API yra tas pats, kas mokėjimų paslaugų teikėjas?
Ne. Teikėjas autorizuoja, nuskaito, atsiskaito ir kartais išmoka lėšas. Didžiosios knygos API registruoja apskaitines tų įvykių pasekmes. Dauguma prekyviečių naudoja abu: teikėją, tokį kaip „Stripe“ ar „Adyen“, pinigų judėjimui ir didžiąją knygą apskaitai.
Ar galiu tiesiog naudoti mokėjimų teikėjo skydelį kaip didžiąją knygą?
Galite pabandyti, bet anksčiau ar vėliau tai neatlaikys audito. Teikėjo ataskaitos rodo mokėjimus, mokesčius, pervedimus ir atsiskaitymus, tačiau paprastai neatspindi visų jūsų įsipareigojimų pardavėjams, mokestinių prievolių, su mokėjimais nesusijusių sąnaudų ar apskaitos koregavimų. Traktuokite tai kaip duomenų derinimo šaltinį.
Ar subalansuota didžioji knyga reiškia, kad apskaita teisinga?
Tai reiškia tik tiek, kad jūsų įrašai atitinka debeto ir kredito taisyklę. Puikiai subalansuota operacija vis tiek gali būti užregistruota ne į tą sąskaitą, ne tam pardavėjui ar su netinkamu mokestiniu traktavimu. Balansas yra būtina, bet nepakankama sąlyga. Visa kita pagauna duomenų derinimas.
Jei didžioji knyga nekintama, kaip taisyti klaidas?
Užregistruojate stornuojantį įrašą, o tada pataisytą. Pirminis įrašas lieka matomas — būtent tame ir esmė. Nekintamumas saugo audito seką, o ne įkalina jūsų klaidas.
Ar apskaitos API automatiškai užtikrina atitiktį reikalavimams?
Ne. Ji užtikrina apskaitos struktūrą ir sukuria tinkamus įrašus. Teisinė atitiktis vis tiek priklauso nuo jūsų jurisdikcijos, sutartinio vaidmens, mokestinio traktavimo, mokėjimų reguliavimo, KYC ir AML procesų bei ataskaitų teikimo prievolių.