Kas ir divkāršā ieraksta virsgrāmatas API tirgiem?

Tirgpusē (marketplace) var šķist viss kārtībā, raugoties uz tabulu orders, taču dati par naudas līdzekļiem var izrādīties nepareizi. Pasūtījuma statuss vēsta "apmaksāts". Pārdevēja informācijas panelis rāda atlikumu. Tomēr nekas šajā tabulā nepierāda, cik daudz skaidras naudas platforma patiesībā glabā, cik tā ir parādā katram pārdevējam, cik liela maksājuma daļa ir komisijas ieņēmumi vai cik liels PVN tagad ir maksājams valsts budžetā. Divkāršā ieraksta virsgrāmatas API pastāv tieši tāpēc, lai pareizi reģistrētu šīs finansiālās sekas, pa vienam sabalansētam darījumam reizē.

Vienkārši sakot: divkāršā ieraksta virsgrāmatas API ir programmējama grāmatvedības sistēma. Jūsu lietotne nosūta tai finansiālu notikumu, piemēram, iekasētu maksājumu vai apstiprinātu izmaksu, un virsgrāmata ieraksta šo notikumu kā žurnālu ar vienādiem debetiem un kredītiem attiecīgajos kontos. Tā nepārvieto naudu. Tā reģistrē patiesību par naudu, kas ir pārvietojusies citviet.

Ko šeit nozīmē "divkāršā ieraksta virsgrāmata"

Virsgrāmata ir kontu izmaiņu reģistrs, nevis tabula, kurā glabājas tikai jaunākais atlikums. Darbspējīgai virsgrāmatai ir trīs savstarpēji saistītas idejas:

• Konts (account): nosaukta finansiālā pozīcija, piemēram, debeti par maksājumu apstrādātāju pakalpojumiem, parādi pārdevējiem, komisijas ieņēmumi vai maksājamais PVN.
• Darījums jeb žurnāla ieraksts (transaction/journal): viens atomārs finansiāls notikums, kas satur vairākas sabalansētas rindas.
• Ieraksts jeb grāmatojums (entry/posting): viena debeta vai kredīta rinda šajā darījumā.

Invariantas princips, kas tur kopā visu arhitektūru, ir vienkāršs: kopējiem debetiem ir jābūt vienādiem ar kopējiem kredītiem katram darījumam un katrai valūtai. Virsgrāmatas API parasti noraida nesabalansētu ierakstu, pirms tas nonāk datu glabātuvē. Modern Treasury dokumentācija definē virsgrāmatas darījumu kā tādu, kas ietver divus vai vairākus kontus ar vismaz vienu debetu un vienu kredītu ar vienādām kopsummām, un izturas pret grāmatotu darījumu kā pret nemainīgu (immutable).

Divkāršais ieraksts nenozīmē precīzi divas rindas. Vienam tirgus puses darījumam bieži vien ir nepieciešams viens debets un vairāki kredīti. Tā ir daļa, ko cilvēki pārprot visbiežāk.

Kāpēc tirgiem ir nepieciešama virsgrāmata, nevis tikai maksājumu tabula

Tirgus vienlaikus uztur vairākas finansiālās attiecības. Pircējs samaksā. Apstrādātājs veic norēķinu. Platforma var īslaicīgi kontrolēt līdzekļus. Pārdevējs nopelna savu daļu. Platforma patur komisiju. Nodoklis kļūst maksājams. Var tikt ieturēta rezerve. Vēlāk izmaksa pārvieto naudu ārā, un atmaksas vai maksājumu atgriešanas (chargeback) procedūras daļu no tā atsauc.

Tabula payments var pastāstīt par pasūtījuma komerciālo statusu. Tā nevar droši pateikt:

• cik liels ir debets no maksājumu apstrādātāja vai cik daudz skaidras naudas ir pieejams
• cik ir parādā katram pārdevējam
• cik lieli ieņēmumi pieder platformai
• cik liels PVN ir maksājams un kurā valstī
• kas ir rezervēts pret atmaksām vai strīdiem
• vai izmaksa samazināja pareizo pārdevēja saistību summu
• vai apstrādātāja norēķini sakrīt ar platformas gaidīto

Nordlet ceļvedis par divkāršā ieraksta virsgrāmatas API tirgus grāmatvedībai skaidri novelk robežu: lietotnes tabulas apraksta produkta stāvokli, savukārt virsgrāmata reģistrē šī stāvokļa finansiālās sekas. Tajā ir arī izteikts pieminēšanas vērts secinājums, ka maksājumu apstrādātāja pārskati ir ievaddati saskaņošanai, nevis pilnīgas divkāršā ieraksta grāmatas.

Veiksmīgs tirgus puses darījuma piemērs

Pieņemsim, ka pircējs samaksā 100 €, pārdevējam pienākas 85 €, un platformas komisija ir 15 €. Skaidrības labad ignorēsim PVN un apstrādātāja komisijas maksas.

Konts	Debets	Kredīts	Iemesls
Maksājumu apstrādātāja debets (receivable)	100 €		Apstrādātājs ir parādā platformai iekasēto maksājumu
Saistības pret pārdevēju (payable)		85 €	Platforma ir parādā pārdevējam
Komisijas ieņēmumi		15 €	Platforma nopelnīja savu komisiju
Kopā	100 €	100 €	Līdzsvars

Svarīga klasifikācija šeit ir tāda, ka pārdevējam pienākošies 85 € ir saistības, nevis platformas ieņēmumi. Saskaņā ar IFRS koncepcijas ietvaru saistības ir pašreizējs pienākums nodot ekonomisko resursu. Tirgum nevajadzētu uzrādīt pārdevēja pilno pārdošanas ieņēmumu summu kā savus ienākumus tikai tāpēc, ka pircējs maksāja caur to. Tas, vai jūs esat aģents, principals vai uzskatāms par preces piegādātāju (deemed supplier), maina attieksmi, bet virsgrāmatas mehānisms paliek nemainīgs.

Kad pārdevējs kļūst tiesīgs saņemt izmaksu, jauni ieņēmumi netiek atzīti. Jūs nsedzat saistības:

Konts	Debets	Kredīts
Saistības pret pārdevēju	85 €
Banka vai izmaksu norēķinu konts		85 €
Kopā	85 €	85 €

Ja apstrādātājs pirms norēķina veikšanas ietur 3 € komisijas maksu, naudas kustība kļūst par trīs rindu žurnālu: 97 € nonāk bankas kontā, 3 € ir apstrādes izmaksas, 100 € tiek norakstīti no maksājumu apstrādātāja debeta. Katrai pozīcijas maiņai ir avots un galamērķis.

Kā API darbojas soli pa solim

1. Jūsu lietotne nosaka biznesa notikumu. Maksājums tiek iekasēts, pasūtījums izpildīts, izmaksa apstiprināta, veikta atmaksa, atvērts maksājumu strīds, saņemts norēķins. Jūsu datubāze joprojām pārvalda operacionālo stāvokli. Virsgrāmata reģistrē monetāro efektu.

2. Jūs nosūtāt strukturētu pieprasījumu. Tas parasti satur notikuma veidu, summu un valūtu, pasūtījuma vai maksājuma ID, pircēja un pārdevēja identifikatorus, komisijas maksu, nodokļu datus, iesaistītos kontus, spēkā stāšanās un grāmatošanas datumus, idempotences atslēgu (idempotency key), kā arī metadatus, kas saistīti ar apstrādātāja un produkta ierakstiem. Nordlet publiskais API piemērs parāda konceptuālu pārdošanas pieprasījumu ar pārdevēja ID, pārdošanas veidu, summu, valūtu, kā arī PVN valsti un likmi.

3. API veic validāciju. Tā pārbauda, vai debeti un kredīti ir sabalansēti, vai konti eksistē un tajos var veikt grāmatojumus, vai valūta tiek atbalstīta, vai summa izmanto precīzu mazo vienību (minor-unit) apstrādi, vai idempotences atslēga nav atkārtoti izmantota citam rezultātam, vai periods ir atvērts un vai ir klāt nepieciešamie metadati. Neizdevusies pārbaude neatstāj aiz sevis daļēju žurnāla ierakstu.

4. Grāmatošana notiek atomāri. Pilns darījums tiek ierakstīts kā viena vienība. Nekad nedrīkst būt iespējams reģistrēt debetu, kamēr atbilstošais kredīts neizdodas. Tirgum daļējs sadalījums varētu radīt šķietamu pārdevēja atlikumu bez tam atbilstošas skaidras naudas vai iegrāmatot komisijas maksu bez pārdevēja saistībām.

5. Atlikumi un atskaites tiek atvasināti no virsgrāmatas. Pēc grāmatošanas jūs varat nolasīt kontu atlikumus, pārdevēja gaidāmos un pieejamos atlikumus, apgrozījuma pārskatu (trial balance), virsgrāmatas aktivitāti, PVN kopsavilkumus un vēsturi uz iepriekšējo datumu. Pārdevēja atlikumam jābūt atjaunojamam no grāmatojumiem, nevis uzticamies mainīgam laukam.

6. Webhook paziņojumi informē jūsu produktu. Notikumi, piemēram, sale_invoice.paid, iegrāmatots žurnāls, pieejama izmaksa vai saskaņošanas izņēmums, tiek nosūtīti jums. Apstrādājiet tos idempotenti. Webhook ir paziņojums, nevis atļauja lietot finansiālo notikumu otro reizi. API konvencijas detalizēti aplūko darbības jomas (scopes), idempotences atslēgas, kļūdu formas un webhook parakstīšanu.

Pārdevēju atlikumi nav viena vienīga skaitlis

Lielākā daļa tirgu iekļūst nepatikšanās, uztverot pārdevēja atlikumu kā vienu rādītāju. Naudai vajadzētu atrasties vairākos stāvokļos:

Stāvoklis	Nozīme
Gaidāms (Pending)	Pārdevējs var būt tiesīgs, bet izmaksas nosacījumi nav izpildīti
Pieejams (Available)	Derīgs izmaksai
Rezervēts (Reserved)	Ieturēts pret atmaksām, atgriešanu vai strīdiem
Izmaksāts (Paid out)	Saistības nokārtotas ar pārskaitījumu
Negatīvs (Negative)	Atmaksas, strīdi vai komisijas maksas pārsniedz pieejamos līdzekļus

Apstrādātāju modeļi atspoguļo šo pieeju. Stripe atsevišķo maksājumu un pārsūtījumu plūsma ļauj platformai iekasēt maksājumu savā kontā un pēc tam pārsūtīt daļas uz saistītajiem kontiem, komisijas maksām, atmaksām un strīdiem nonākot platformas bilancē. Adyen tirgus modelis atšķir lietotāju bilances kontus, kuros līdzekļi tiek glabāti līdz izmaksai, no saistību bilances konta, kas var absorbēt negatīvas bilances no atmaksām vai strīdiem. Šie ir noderīgi ievaddati jūsu virsgrāmatai. Tie nav jūsu pilnīgais grāmatvedības modelis.

Izmaksas un pārdevēja ienākumi notiek dažādos laika momentos

Pārdevējs var nopelnīt pirmdien un saņemt samaksu nākamajā pirmdienā. Laika posmā starp šiem punktiem pasūtījums tiek izpildīts, tiek ieturēta rezerve, tiek sagatavota izmaksu pakete, apstrādātājs veic norēķinu, atskaitot komisijas maksas, un ienāk bankas depozīts. Virsgrāmatai ir jāsaglabā katrs posms, nevis jāpārraksta pasūtījums ar galīgo "apmaksāts". Tas ir tas, kas ļauj izskaidrot laika atšķirības starp pasūtījumu aktivitāti, pārdevēja tiesībām, norēķinu, izmaksas uzsākšanu un bankas ieņēmumiem.

Atmaksas un strīdi: atsauciet, nepārrakstiet

Atmaksas un strīdi ir jauni notikumi, kas saistīti ar sākotnējo maksājumu. Nemainīgā virsgrāmatā jūs labojat ar pretēju (reversing) ierakstu, kam seko labots ieraksts, lai oriģināls paliktu redzams revīzijai. Modern Treasury izturas pret grāmatotiem darījumiem kā pret nemainīgiem un atbalsta idempotences atslēgas, lai atkārtotas izpildes gadījumā novērstu dubultus objektus.

Atmaksa parasti samazina skaidru naudu vai pircēja debetu, atceļ saistības pret pārdevēju, var atcelt daļu no komisijas atbilstoši politikai, koriģē nodokli un var izmantot atmaksas rezervi. Strīds (chargeback) samazina skaidru naudu vai apstrādātāja debetu, var atkārtoti atvērt pārdevēja vai platformas parāda summu, reģistrē strīda izdevumus un apstrādātāja komisiju, kā arī pārvieto līdzekļus caur rezerves kontu.

Saskaņošana: virsgrāmatas savienošana ar reālu naudu

Virsgrāmata var būt iekšēji sabalansēta, bet joprojām kļūdaina attiecībā uz ārpasauli. Saskaņošana salīdzina iekšējos ierakstus ar ārējiem pierādījumiem: apstrādātāja norēķinu pārskatiem, bankas izrakstiem, izmaksu failiem, atmaksu un strīdu ierakstiem.

Strādājoša cikla piemērs:

1. Importējiet norēķinu vai bankas partiju.
2. Saskariet katru rindu ar pasūtījumu, maksājumu, atmaksu, komisiju, izmaksu vai strīdu.
3. Salīdziniet sagaidāmos bruto ieņēmumus, atskaitījumus, rezerves un neto summu.
4. Iegrāmatojiet apstiprinātās kustības virsgrāmatā.
5. Nosūtiet nesaskaņotās pozīcijas uz nosaukumu starpkontu (suspense account).
6. Izpētiet izņēmumus.
7. Slēdziet periodu.

Nordlet saskaņošanas materiāls apraksta tieši šo procesu, importējot norēķinu partijas, saskaņojot maksājumu un atmaksu rindas, kā arī novirzot nesaskaņotos ieņēmumus uz starpkontu, nevis minot rēķinu. Svarīgas ir divas pārbaudes, un neviena no tām neaizstāj otru: divkāršā ieraksta validācija jautā, vai katrs žurnāls sabalansējas, un saskaņošana jautā, vai tas sakrīt ar apstrādātāju, banku un biznesa notikumu.

Dizaina detaļas, kas nosaka, vai jums izdosies to paveikt pareizi

Idempotence. Piesaistiet atslēgu stabilam notikumam, piemēram, payment_captured:pi_123. Atkārtots pieprasījums atgriež oriģinālo rezultātu, nevis otru žurnālu.

Atomaritāte. Visām viena notikuma rindām ir jāgrāmatojas kopā vai nevienai.

Nemainīgums un atsaukumi. Grāmatotā vēsture nav labojama, izmantojot parastos atjauninājumus. Labojumi rada saistītus ierakstus, kas saglabā sākotnējo summu, datumu, klasifikāciju, iemeslu un autoru.

Precīza nauda. Nekādu bināro peldošo komatu (floating point). Izmantojiet veselu skaitļu mazās vienības vai precīzus decimāldaļskaitļus, nepārprotamu valūtu un deterministisku noapaļošanas likmi sadalījumiem. Sadalot 100 € starp pārdevējiem un komisijas maksām bez tās, klaiņojošs cents izjauks jūsu bilanci.

Spēkā stāšanās un grāmatošanas datumi. Datums, kad pircējs samaksāja, kad pārdevējs nopelnīja, kad banka norēķinājās un kad ieraksts tika iegrāmatots, ir dažādi datumi. To sajaukšana padara perioda pārskatus un nodokļu laika grafikus neuzticamus.

Valūtu daudzveidība. Debetiem un kredītiem ir jāsabalansējas vienas valūtas ietvaros. Konvertācijai ir nepieciešams nepārprotams kursa notikums ar kontiem komisijas maksai, noapaļošanai un jebkādiem valūtas kursa ieņēmumiem vai zaudējumiem. Laukuma currency pieņemšana nepadara virsgrāmatu par valūtas maiņas dzinēju.

Ko virsgrāmatas API jūsu labā nedarīs

Tā neizlems jūsu kontu plānu (chart of accounts). Jums pašiem joprojām ir jānosaka, vai esat principals vai aģents, kad komisija tiek nopelnīta, kura puse sedz apstrādātāja komisijas maksas, kā atmaksas ietekmē komisiju un kā PVN tiek aprēķināts un uzrādīts. Nordlet pašu ieteikums ir vispirms kartēt naudas plūsmas, sagatavot kontu plāna melnrakstu, lūgt grāmatvedim to pārskatīt un pēc tam ieviest vienu pilnu plūsmu no pasūtījuma līdz izmaksai un saskaņošanai, pirms mēroga palielināšanas.

Tā neatrisinās nodokļu jautājumus. PVN ir atkarīgs no pircēja un pārdevēja atrašanās vietas, produkta veida, reģistrācijas statusa un uzskatāmā piegādātāja noteikumiem; ES PVN ceļvedis nosaka, ko sistēma atvasina un ko tā atzīmē cilvēka pārbaudei. Nordlet PVN pārklājums ir vērsts uz ES un EEZ, tāpēc tas neattiecas uz ASV tirdzniecības nodokli vai Latīņamerikas e-rēķiniem. Tā arī neatrisinās operacionālo nenoteiktību – vai preces atgriešanas termiņš ir beidzies, vai izmaksai vajadzētu būt bloķētai, vai maksājums ir krāpniecisks. Tie ir jūsu lēmumi. Virsgrāmata reģistrē to finansiālo rezultātu.

Kur iekļaujas Nordlet

Nordlet ir grāmatvedības API, kas izstrādāta platformām un tirgiem, ar nemainīgu divkāršā ieraksta virsgrāmatu, izmaksām, ES PVN apstrādi, REST galapunktiem (endpoints), tipizētiem SDK un webhook paziņojumiem, kas pieejami caur vienu saskarni. Tās atšķirīgā iezīme ir iestrādāta grāmatvedība pašas produktā, nevis trešās puses norēķinu risinājums. Šī raksta tapšanas brīdī produkts ir agrīnās piekļuves stadijā ar smilškasti dizaina partneriem, tāpēc uztveriet to kā spēcīgu šīs kategorijas piemēru un pirms apņemšanās novērtējiet ražošanas gatavību (production maturity), darbspējas laiku un jurisdikcijas pārklājumu savam gadījumam.

Tirgus un platformu izstrādātājiem noderīgais domāšanas modelis ir sadalījums starp naudas kustību un finansiālo patiesību. Jūsu apstrādātājs pārvieto naudu. Divkāršā ieraksta virsgrāmatas API reģistrē, kam un cik ir parādā, ko jūs nopelnījāt, kādus nodokļus un rezerves jūs uzturat un vai ārpasaulē dati saskan ar jūsu grāmatām.

FAQ

Vai divkāršā ieraksta virsgrāmatas API ir tas pats, kas maksājumu apstrādātājs?

Nē. Apstrādātājs autorizē, iekasē, veic norēķinus un dažreiz izmaksā līdzekļus. Virsgrāmatas API reģistrē šo notikumu grāmatvedības sekas. Lielākā daļa tirgu izmanto abus – apstrādātāju, piemēram, Stripe vai Adyen, naudas kustībai un virsgrāmatu grāmatām.

Vai es varu vienkārši izmantot sava apstrādātāja informācijas paneli kā virsgrāmatu?

Jūs varat mēģināt, taču tas galu galā izgāzīs revīziju. Apstrādātāja pārskati rāda maksas, komisijas maksas, pārsūtījumus un norēķinus, taču tie parasti neatspoguļo jūsu pilnas pārdevēja saistības, nodokļu saistības, ar apstrādātāju nesaistītus izdevumus vai grāmatvedības korekcijas. Uzskatiet to par ievaddatu saskaņošanai.

Vai sabalansēta virsgrāmata nozīmē, ka manas grāmatas ir pareizas?

Tikai to, ka jūsu ieraksti atbilst debeta un kredīta noteikumam. Perfekti sabalansētu darījumu joprojām var iegrāmatot nepareizā kontā, nepareizam pārdevējam vai ar nepareizu nodokļu attieksmi. Līdzsvars ir nepieciešams, bet ne pietiekams. Saskaņošana ir tas, kas noķer pārējo.

Ja virsgrāmata ir nemainīga, kā es laboju kļūdas?

Jūs iegrāmatojat pretēju (reversing) ierakstu un pēc tam labotu. Oriģināls paliek redzams, kas arī ir galvenais mērķis. Nemainīgums aizsargā revīzijas izsekojamību, tas neiesprosto jūsu kļūdas.

Vai grāmatvedības API automātiski padara mani atbilstošu noteikumiem?

Nē. Tā nodrošina grāmatvedības struktūru un rada lietojamus ierakstus. Juridiskā atbilstība joprojām ir atkarīga no jūsu jurisdikcijas, līgumiskās lomas, nodokļu režīma, maksājumu noteikumiem, KYC un AML procesiem, kā arī ziņošanas pienākumiem.

Papildu lasāmviela

• Double-entry ledger APIs for marketplace accounting
• Defining double-entry ledgers, Formance