Kas yra prekyviečių dvejybinės apskaitos didžiosios knygos API?
Dvejybinės apskaitos didžiosios knygos API registruoja pinigų judėjimą prekyvietėje kaip subalansuotus, nekeičiamus žurnalo įrašus, kad visada tiksliai žinotumėte, kas kam ir už ką skolingas.
Prekyvietė (marketplace) gali atrodyti finansiškai sveika savo orders (užsakymų) lentelėje, tačiau jos finansiniai duomenys vis tiek gali būti klaidingi. Užsakymo statusas rodo „apmokėta“. Pardavėjo skydelyje matomas likutis. Tačiau jokia šios lentelės eilutė neįrodo, kiek grynųjų pinigų šiuo metu turi platforma, kiek ji skolinga kiekvienam pardavėjui, kiek gauto mokėjimo sudaro komisinis atlyginimas arba kiek PVM dabar reikia sumokėti. Dvejybinės apskaitos didžiosios knygos (double-entry ledger) API skirta tam, kad šios finansinės pasekmės būtų užregistruotos teisingai – po vieną subalansuotą operaciją vienu metu.
Paprastai tariant, dvejybinės apskaitos didžiosios knygos API yra programuojama apskaitos sistema. Jūsų programa jai perduoda finansinį įvykį, pavyzdžiui, nuskaitytą mokėjimą arba patvirtintą išmokėjimą, o knyga įrašo šį įvykį žurnale kaip vienodus debeto ir kredito įrašus atitinkamose sąskaitose. Ji neperkelia pinigų. Ji tik registruoja teisybę apie pinigus, kurie buvo perkelti kitur.
Ką čia reiškia „dvejybinės apskaitos didžioji knyga“
Didžioji knyga (ledger) yra sąskaitų pokyčių istorija, o ne paprasta lentelė, kurioje saugomas tik paskutinis likutis. Veikianti didžioji knyga remiasi trimis tarpusavyje susijusiomis sąvokomis:
- Sąskaita (account): įvardyta finansinė pozicija, pavyzdžiui, gautinos sumos iš mokėjimų apdorojimo paslaugų teikėjo, mokėtinos sumos pardavėjams, komisinis atlyginimas arba mokėtinas PVM.
- Operacija (žurnalo įrašas / transaction): vienas atominis finansinis įvykis, apimantis kelias subalansuotas eilutes.
- Įrašas (posting): viena debeto arba kredito eilutė šios operacijos viduje.
Invariantas, palaikantis visą šią architektūrą, yra paprastas: bendra debeto suma turi būti lygi bendrai kredito sumai kiekvienoje operacijoje ir kiekviena valiuta. Didžiosios knygos API paprastai atmeta nesubalansuotą įrašą dar prieš jam patenkant į saugyklą. „Modern Treasury“ dokumentacijoje didžiosios knygos operacija apibrėžiama kaip apimanti dvi ar daugiau sąskaitų su bent vienu debeto ir vienu kredito įrašais, kurių bendros sumos yra lygios, o įregistruota operacija laikoma nekeičiama (immutable).
Dvejybinis įrašas nereiškia lygiai dviejų eilučių. Vienam prekyvietės pardavimui dažnai reikia vieno debeto ir kelių kreditų. Būtent tai žmonės supranta neteisingai dažniausiai.
Kodėl prekyvietėms reikia didžiosios knygos, o ne tik mokėjimų lentelės
Prekyvietė vienu metu palaiko kelis finansinius santykius. Pirkėjas sumoka. Mokėjimų apdorojimo paslaugų teikėjas atlieka atsiskaitymą. Platforma gali laikinai valdyti lėšas. Pardavėjas uždirba savo dalį. Platforma pasilieka komisinį atlyginimą. Atsiranda prievolė mokėti mokesčius. Gali būti sulaikytas rezervas. Vėliau išmokėjimas išjudina pinigus, o grąžinimai arba ginčai (chargebacks) dalį šių operacijų atšaukia.
payments lentelė gali parodyti komercinį užsakymo statusą. Tačiau ji negali patikimai atsakyti į klausimus:
- kiek gautinų sumų ar grynųjų pinigų turime pas paslaugų teikėją
- kiek esame skolingi kiekvienam pardavėjui
- kiek pajamų priklauso pačiai platformai
- kiek PVM ir kurioje šalyje reikia sumokėti
- kiek lėšų rezervuota galimiems grąžinimams ar ginčams
- ar išmokėjimas sumažino būtent tą pardavėjo įsiskolinimą, kurį reikėjo
- ar paslaugų teikėjų atsiskaitymai sutampa su platformos lūkesčiais
„Nordlet“ vadovas apie dvejybinės apskaitos didžiosios knygos API prekyviečių apskaitai brėžia aiškią ribą: programų lentelės aprašo produktų būseną, o didžioji knyga registruoja finansines tos būsenos pasekmes. Jame taip pat pabrėžiamas dalykas, kurį verta pakartoti: mokėjimų apdorojimo paslaugų teikėjų ataskaitos yra duomenys suderinimui, o ne pilnavertė dvejybinės apskaitos knyga.
Realaus prekyvietės pardavimo pavyzdys
Tarkime, pirkėjas sumoka 100 €, pardavėjui priklauso 85 €, o platformos komisinis atlyginimas yra 15 €. Aiškumo dėlei PVM ir paslaugų teikėjo mokesčius čia praleisime.
| Sąskaita | Debetas | Kreditas | Priežastis |
|---|---|---|---|
| Gautinos sumos iš mokėjimų teikėjo | 100 € | Teikėjas skolintas platformai už nuskaitytą mokėjimą | |
| Mokėtinos sumos pardavėjui | 85 € | Platforma skolinga pardavėjui | |
| Komisinių pajamos | 15 € | Platforma užsidirbo komisinį atlyginimą | |
| Iš viso | 100 € | 100 € | Subalansuota |
Svarbus klasifikavimo aspektas čia yra tas, kad pardavėjui mokėtina 85 € suma yra įsipareigojimas (pasyvas), o ne platformos pajamos. Pagal TFAS (IFRS) koncepcinį rėmą, įsipareigojimas yra esama prievolė perleisti ekonominį ištekliuką. Prekyvietė neturėtų registruoti visų pardavėjo pajamų kaip savo uždarbio vien dėl to, kad pirkėjas sumokėjo per jos sistemą. Apskaitos traktuotė gali skirtis priklausomai nuo to, ar veikiate kaip tarpininkas (agentas), pagrindinis šalis (principal), ar pripažintas tiekėjas (deemed supplier), tačiau pats didžiosios knygos mechanizmas lieka toks pat.
Kai pardavėjas įgyja teisę į išmokėjimą, jokių naujų pajamų nepripažįstama. Jūs tiesiog padengiate įsipareigojimą:
| 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 € mokesčio, pinigų judėjimas virsta trijų eilučių žurnalo įrašu: 85 € į banko sąskaitą, 3 € į apdorojimo sąnaudas, o iš gautinų sumų išskaitoma 100 €. Kiekvienas pozicijos pokytis turi šaltinį ir paskirties vietą.
Kaip API veikia žingsnis po žingsnio
1. Jūsų programa aptinka verslo įvykį. Nuskaitytas mokėjimas, įvykdytas užsakymas, patvirtintas išmokėjimas, išmokėtas grąžinimas, atidarytas ginčas, gautas atsiskaitymas. Operacinę būseną ir toliau valdo jūsų duomenų bazė, o didžioji knyga registruoja piniginį poveikį.
2. Siunčiate struktūrizuotą užklausą. Paprastai joje nurodomas įvykio tipas, suma ir valiuta, užsakymo arba mokėjimo ID, pirkėjo ir pardavėjo identifikatoriai, komisiniai, mokesčių duomenys, susijusios sąskaitos, operacijos ir registravimo datos, idempotentiškumo raktas (idempotency key) bei metaduomenys, susiejantys įrašą su mokėjimų teikėjo ir produkto įrašais. „Nordlet“ viešosios API pavyzdyje rodoma koncepcinė pardavimo užklausa su pardavėjo ID, pardavimo tipo, suma, valiuta bei PVM šalimi ir tarifu.
3. API atlieka patikrą. Ji patikrina, ar debetas ir kreditas sutampa, ar sąskaitos egzistuoja ir į jas galima registruoti, ar palaikoma valiuta, ar suma naudoja tikslų mažiausiųjų valiutos vienetų (minor units) formatą, ar idempotentiškumo raktas nėra panaudotas pakartotinai kitam rezultatui, ar finansinis laikotarpis yra atviras ir ar pateikti visi reikalingi metaduomenys. Nepavykus patikrai, jokie daliniai įrašai nepaliekami.
4. Registravimas atliekamas atominiu būdu. Visa operacija įrašoma kaip vienas nedalomas vienetas. Niekada negali taip nutikti, kad debetas įrašomas, o atitinkamas kreditas – ne. Prekyvietei dalinis įrašas reikštų iš piršto laužtą pardavėjo balansą be jokių jam padengti skirtų grynųjų pinigų arba užregistruotas komisinio pajamas be atitinkamos prievolės pardavėjui.
5. Likučiai ir ataskaitos sudaromi remiantis didžiąja knyga. Įregistravę įrašą, galite nuskaityti sąskaitų likučius, pardavėjų laukiančius (pending) ir pasiekiamus (available) likučius, bandomąjį balansą (trial balance), didžiosios knygos judėjimą, PVM suvestines bei istoriją pasirinktai praeities datei. Pardavėjo likutis privalo būti atkuriamas iš įrašų, o ne skaitomas iš keičiamo lauko duomenų bazėje.
6. Žiniatinklio kabliukai (webhooks) praneša jūsų produktui. Jūs gaunate pranešimus apie tokius įvykius kaip sale_invoice.paid, įregistruotą žurnalą, paruoštą išmokėjimą arba suderinimo neatitikimą. Apdorokite juos laikydamiesi idempotentiškumo principo. Žiniatinklio kabliukas yra tik pranešimas, o ne leidimas pritaikyti finansinį įvykį antrą kartą. API konvencijose išsamiai aprašytos sritys (scopes), idempotentiškumo raktai, klaidų formatai ir kabliukų pasirašymas.
Pardavėjų likučiai nėra viena vienintelė suma
Daugelis prekyviečių susiduria su problemomis, nes pardavėjo balansą laiko viena vienintele pinigų suma. Pinigai turėtų būti skirstomi pagal būsenas:
| Būsena | Reikšmė |
|---|---|
| Laukia (Pending) | Pardavėjas gali turėti teisę gauti lėšas, tačiau neišpildytos jų išlaivinimo sąlygos |
| Pasiekiama (Available) | Galima išmokėti |
| Rezervuota (Reserved) | Sulaikyta grąžinimams, prekių grąžinimams ar ginčams padengti |
| Išmokėta (Paid out) | Prievolė įvykdyta pervedimu |
| Neigiama (Negative) | Grąžinimai, ginčai arba mokesčiai viršija turimas lėšas |
Mokėjimų teikėjų modeliai atspindi šią logiką. „Stripe“ atskiros operacijų (charges) ir pervedimų (transfers) srautai leidžia platformai įkrauti savo paskyrą, o tada dalis lėšų pervesti į prijungtas sąskaitas, mokesčiams, grąžinimams ir ginčams nusėdant platformos balanse. „Adyen“ prekyvietės modelis skiria naudotojų balanso sąskaitas, kuriose lėšos saugomos iki išmokėjimo, ir atsakomybės balanso sąskaitą, galinčią sugerti neigiamus likučius dėl grąžinimų ar ginčų. Tai naudingi įvesties duomenys jūsų didžiajai knygai, tačiau tai nėra visas jūsų apskaitos modelis.
Išmokėjimai ir pardavėjo uždarbis vyksta skirtingu metu
Pardavėjas gali užsidirbti pinigų pirmadienį, o išmokėjimą gauti kitą pirmadienį. Per tą laiką užsakymas įvykdomas, sulaikomas rezervas, suformuojamas išmokėjimų paketas, paslaugų teikėjas atlieka atsiskaitymą atskaitęs savo mokesčius ir įplaukia banko pavedimas. Didžioji knyga privalo išsaugoti kiekvieną šį etapą, o ne perrašyti užsakymą galutiniu statusu „apmokėta“. Tai leidžia paaiškinti laiko skirtumus tarp užsakymų aktyvumo, pardavėjo teisės į pinigus, atsiskaitymo, išmokėjimo inicijavimo ir pinigų gavimo banke.
Grąžinimai ir ginčai: atšaukite, o ne perrašykite
Grąžinimai ir ginčai yra nauji įvykiai, susieti su pradiniu mokėjimu. Nekeičiamoje didžiojoje knygoje klaidas ištaisote sukurdami atvirkštinį (reversing) įrašą, po kurio seka teisingas įrašas, todėl pradinė operacija išlieka matoma audito tikslais. „Modern Treasury“ traktuoja įregistruotas operacijas kaip nekeičiamas ir palaiko idempotentiškumo raktus, kad pakartotinių bandymų metu nebūtų sukurti dubliuojantys objektai.
Grąžinimas paprastai sumažina pinigų arba gautinų sumų iš pirkėjo likutį, anuliuoja mokėtiną sumą pardavėjui, priklausomai nuo taisyklėms gali anuliuoti dalį komisinių, pakoreguoja mokesčius ir gali pasinaudoti grąžinimų rezervu. Ginčas sumažina pinigus arba gautinas sumas iš mokėjimų teikėjo, gali vėl atidaryti pardavėjo arba platformos įsiskolinimą, registruoja ginčo sąnaudas bei teikėjo mokestį ir perkelia lėšas per rezervo sąskaitą.
Suderinimas (reconciliation): didžiosios knygos susiejimas su realiais pinigais
Didžioji knyga gali būti subalansuota savo viduje, tačiau vis tiek klaidingai atspindėti realų pasaulį. Suderinimas lygina vidinius įrašus su išoriniais įrodymais: mokėjimų teikėjų atsiskaitymo ataskaitomis, banko išrašais, išmokėjimų failais, grąžinimų ir ginčų įrašais.
Veikiantis derinimo ciklas atrodo taip:
- Importuokite atsiskaitymo arba banko paketą.
- Sugretinkite kiekvieną eilutę su užsakymu, mokėjimu, grąžinimu, mokesčiu, išmokėjimu arba ginču.
- Palyginkite numatomą bendrą sumą, atskaitymus, rezervus ir grynąją sumą.
- Įregistruokite patvirtintus judėjimus didžiojoje knygoje.
- Nesuderintas eilutes nukreipkite į specialią laukimo (suspense) sąskaitą.
- Ištirkite neatitikimus.
- Užrakinkite finansinį laikotarpį.
„Nordlet“ suderinimo medžiaga apibūdina būtent tai: atsiskaitymo paketų importavimą, mokesčių bei grąžinimo eilučių sugretinimą ir nesuderintų įplaukų nukreipimą į laukimo sąskaitą, vietoj spėliojimo pagal sąskaitą faktūrą. Svarbūs du patikrinimai, ir nei vienas iš jų nepakeičia kito: dvejybinės apskaitos patikra klausia, ar kiekvienas žurnalo įrašas subalansuotas, o suderinimas klausia, ar jis sutampa su mokėjimų teikėjo, banko ir verslo įvykio duomenimis.
Architektūros niuansai, lemiantys sėkmę
Idempotentiškumas. Susiekite raktą su stabiliu įvykiu, pavyzdžiui, payment_captured:pi_123. Pakartotinis bandymas grąžina pradinį rezultatą, o ne sukuria antrą žurnalo įrašą.
Atomumas. Visos vieno įvykio eilutės įregistruojamos kartu arba neįregistruojamos jokios.
Nekeičiamumas ir atšaukimai. Įregistruotos istorijos negalima redaguoti paprastais atnaujinimais. Pataisymai sukuria susijusius įrašus, kurie išsaugo pradinę sumą, datą, klasifikaciją, priežastį ir autorių.
Tiksli pinigų išraiška. Jokių slankiojo kablelio dvejetainių skaičių (binary floating point). Naudokite mažiausiuosius sveikųjų skaičių valiutos vienetus arba tikslias dešimtaines trupmenas, aiškiai nurodytą valiutą ir deterministines apvalinimo taisykles paskirstymui. Paskirsčius 100 € tarp pardavėjų ir mokesčių be šių taisyklių, paklydęs centas sugadins visą balansą.
Operacijos data ir registravimo data. Data, kada pirkėjas sumokėjo, kada pardavėjas užsidirbo, kada bankas atsiskaitymo operaciją užbaigė ir kada įrašas buvo patvirtintas didžiojoje knygoje, dažnai skiriasi. Šių datų painiojimas padaro atskaitomybę pagal laikotarpius ir mokesčių mokėjimo terminus nepatikimus.
Kelių valiutų palaikymas. Debetas ir kreditas turi susibalansuoti tos pačios valiutos ribose. Valiutos konvertavimui reikalingas aiškus valiutos keitimo įvykis su sąskaitomis mokesčiui, apvalinimui ir bet kokiam valiutos kurso pelnui ar nuostoliui registruoti. Valiutos (currency) lauko priėmimas dar nepadaro didžiosios knygos valiutos keitimo varikliu.
Ko didžiosios knygos API už jus nepadarys
Ji nenuspręs, koks turi būti jūsų sąskaitų planas (chart of accounts). Jūs vis tiek turite patys nuspręsti, ar veikiate kaip pagrindinė šalis (principal), ar kaip tarpininkas (agent), kada uždirbamas komisinis atlyginimas, kuri šalis padengia paslaugų teikėjo mokesčius, kaip grąžinimai veikia komisinius ir kaip apskaičiuojamas bei deklaruojamas PVM. „Nordlet“ rekomendacija yra pirmiausia išsiaiškinti pinigų srautus, paruošti sąskaitų plano juodraštį, perduoti jį peržiūrėti buhalteriui ir tik tada įgyvendinti vieną pilną ciklą nuo užsakymo iki išmokėjimo ir suderinimo prieš plečiant mastelį.
Ji neišspręs mokesčių klausimų. PVM priklauso nuo pirkėjo ir pardavėjo vietos, prekės tipo, registracijos statuso ir pripažinto tiekėjo taisyklių; ES PVM vadovas nurodo, ką sistema pati apskaičiuoja, o ką pažymi kaip reikalaujančio žmogaus įsikišimo. „Nordlet“ PVM palaikymas orientuotas į ES ir EEE, todėl jis netaikomas JAV pardavimo mokesčiams ar Lotynų Amerikos el. sąskaitų faktūrų teikimui. Ji taip pat neišspręs operacinių neaiškumų: ar baigėsi prekių grąžinimo langas, ar išmokėjimas turi būti sustabdytas, ar mokėjimas yra sukčiavimo atvejis. Tai yra jūsų sprendimai. Didžioji knyga tik registruoja jų finansinį rezultatą.
Kur dera „Nordlet“
„Nordlet“ yra apskaitos API, sukurta platformoms ir prekyvietėms, turinti nekeičiamą dvejybinės apskaitos didžiąją knygą, išmokėjimus, ES PVM valdymą, REST galinius punktus (endpoints), tipizuotus SDK ir žiniatinklio kabliukus, pasiekamus per vieną sąsają. Jos išskirtinis bruožas yra integruota apskaita jūsų pačių produkte, o ne trečiosios šalies atsiskaitymo langas. Šio rašymo metu produktas yra ankstyvosios prieigos stadijoje su smėlio dėže (sandbox) dizaino partneriams, todėl vertinkite jį kaip puikų šios kategorijos pavyzdį ir prieš įsipareigodami įvertinkite gamybinį brandumą, veikimo laiką (uptime) bei jurisdikcijos padengimą savo konkrečiu atveju.
Prekyviečių ir platformų kūrėjams naudingas mentalinis modelis yra atskirtis tarp pinigų judėjimo ir finansinės tiesos. Jūsų mokėjimų teikėjas perkelia pinigus. Dvejybinės apskaitos didžiosios knygos API registruoja, kas kam skolingas, ką uždirbote, kokius mokesčius ir rezervus turite bei ar išorinis pasaulis sutampa su jūsų knygomis.
D.U.K.
Ar dvejybinės apskaitos didžiosios knygos API yra tas pats, kas mokėjimų apdorojimo paslaugų teikėjas?
Ne. Teikėjas autorizuoja, nuskaito, atlieka atsiskaitymus ir kartais išmoka lėšas. Didžiosios knygos API registruoja šių įvykių apskaitos pasekmes. Dauguma prekyviečių naudoja abu įrankius: teikėją, pavyzdžiui, „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, tačiau galiausiai neatlaikysite audito. Teikėjo ataskaitose rodomi mokesčiai, rinkliavos, pervedimai ir atsiskaitymai, tačiau jose paprastai nėra visų jūsų įsipareigojimų pardavėjams, mokesčių prievolių, su mokėjimų teikėjais nesusijusių sąnaudų ar apskaitos koregavimų. Traktuokite tai tik kaip duomenis suderinimui.
Ar subalansuota didžioji knyga reiškia, kad mano apskaita yra teisinga?
Tai reiškia tik tai, kad jūsų įrašai atitinka debeto ir kredito taisyklę. Tobulai subalansuota operacija vis tiek gali būti įregistruota ne į tą sąskaitą, ne tam pardavėjui arba pritaikant neteisingus mokesčius. Balansas yra būtina, bet nepakankama sąlyga. Visa kita aptinkama atliekant suderinimą.
Jei didžioji knyga yra nekeičiamas, kaip ištaisyti klaidas?
Jūs įregistruojate atvirkštinį įrašą ir po jo – teisingą. Pradinis įrašas lieka matomas, ir tame esmė. Nekeičiamumas saugo audito pėdsaką, o ne įkalina jus jūsų klaidose.
Ar apskaitos API automatiškai užtikrina atitiktį teisės aktams?
Ne. Ji užtikrina apskaitos struktūrą ir sukuria naudojimui tinkamus įrašus. Teisinė atitiktis vis tiek priklauso nuo jūsų jurisdikcijos, sutartinio vaidmens, mokesčių traktuotės, mokėjimų reglamentų, pinigų plovimo prevencijos (KYC/AML) procesų ir teisinių atskaitomybės prievolių.