Mis on kahekordse kirjendiga pearaamatu API turgude jaoks?
Kahekordse kirjendiga pearaamatu API salvestab turuplatsi rahavood tasakaalustatud ja muutumatute kandeandmetena, et teaksite alati täpselt, kellele ja miks raha võlgnetakse.
Turuplats võib oma tellimuste tabelis (orders) näida täiesti korras, kuid finantsandmetes võib siiski valitseda segadus. Tellimus ütleb „makstud“. Müüja töölaual on saldo. Kuid miski selles tabelis ei tõenda, kui palju sularaha platvorm tegelikult hoiab, kui palju ta igale müüjale võlgneb, kui suur osa maksest on vahendustasust saadud tulu või kui suur käibemaks kuulub tasumisele. Kahekordse kirjendiga pearaamatu API (double-entry ledger API) on loodud selleks, et neid finantstagajärgi korrektselt salvestada - üks tasakaalustatud tehing korraga.
Otse öeldes on kahekordse kirjendiga pearaamatu API programmeeritav raamatupidamissüsteem. Teie rakendus saadab sellele finantssündmuse, näiteks laekunud makse või kinnitatud väljamakse, ning pearaamat kirjutab selle sündmuse üles kande kujul, millel on nimetatud kontode vahel võrdsed deebet- ja kreeditread. See ei liiguta raha. See salvestab tõe raha kohta, mis liikus kusagi mujal.
Mida „kahekordse kirjendiga pearaamatu“ mõiste siinkohal tähendab
Pearaamat on kontode muutuste ajalugu, mitte tabel, mis hoiab lihtsalt viimast saldot. Töötaval pearaamatul on kolm omavahel seotud ideed:
- konto (account): nimetatud finantspositsioon, näiteks makseteenuse pakkuja nõue, müüjale makstavad summad, vahendustasu tulu või tasumisele kuuluv käibemaks.
- tehing / kanne (transaction / journal): üks aatomi tasemel finantssündmus, mis sisaldab mitut tasakaalustatud rida.
- kirje / postitus (entry / posting): üksik deebet- või kreeditrida selle tehingu sees.
Invariant, mis hoiab kogu arhitektuuri koos, on lihtne: deebetkogum peab igas tehingus ja iga valuuta puhul võrduma kreeditkogumiga. Pearaamatu API-d lükkavad tasakaalustamata kirjutuskatsed tavaliselt tagasi enne, kui need üldse salvestusse jõuavad. Modern Treasury dokumentatsioon määratleb pearaamatu tehingu kui midagi, mis hõlmab kahte või enamat kontot, kus on vähemalt üks deebet- ja üks kreeditkiri võrdsete summadega, ning käsitleb postitatud tehingut muutumatuna.
Kahekordne kirjend ei tähenda täpselt kahte rida. Üksainus turuplatsi müük vajab sageli ühte deebetit ja mitut kreeditit. Just sellest saavad inimesed kõige sagedamini valesti aru.
Miks turuplatsid vajavad pearaamatut, mitte ainult maksete tabelit
Turuplats haldab mitut finantssuhet üheaegselt. Ostja maksab. Makseteenuse pakkuja teeb arvelduse. Platvorm võib vahendeid ajutiselt kontrollida. Müüja teenib osa summast. Platvorm jätab endale vahendustasu. Maks muutub tasumisele kuuluvaks. Osa vahenditest võidakse kinni pidada reservina. Hiljem liigutab väljamakse raha välja ning tagasimaksed või tagasinõuded (chargebacks) pööravad osad neist toimingutest ümber.
Maksete tabel (payments) võib teile öelda tellimuse ärilise staatuse. Kuid see ei suuda usaldusväärselt öelda:
- kui suur on makseteenuse pakkuja nõue või sularahajääk
- kui palju võlgnetakse igale müüjale
- kui suur tulu kuulub platvormile
- kui palju on käibemaksu tasuda ja millises riigis
- mis on tagasimaksete või vaidluste katteks reserveeritud
- kas väljamakse vähendas õiget müüjakohustust
- kas makseteenuse pakkuja arveldused vastavad platvormi ootustele
Nordleti juhend turuplatsi raamatupidamise kahekordse kirjendiga pearaamatu API-de kohta tõmbab selge piiri: rakenduste tabelid kirjeldavad toote olekut, samas kui pearaamat salvestab selle oleku finantstagajärjed. Samuti tasub korrata tõdemust, et makseteenuse pakkujate aruanded on sisendiks vastavuskontrollile, mitte täielikud kahekordse kirjendiga raamatupidamisraamatud.
Tehtud näide turuplatsi müügist
Oletame, et ostja maksab 100 €, müüjal on õigus saada 85 € ja platvormi vahendustasu on 15 €. Selguse huvides jätame käibemaksu ja teenustasud arvestamata.
| Konto | Deebet | Kreedit | Põhjus |
|---|---|---|---|
| Makseteenuse pakkuja nõue | 100 € | Makseteenuse pakkuja võlgneb platvormile laekunud makse | |
| Müüjale makstavad summad | 85 € | Platvorm võlgneb müüjale | |
| Vahendustasu tulu | 15 € | Platvorm teenis oma vahendustasu | |
| Kokku | 100 € | 100 € | Tasakaalus |
Siin on oluline klassifikatsioon see, et müüjale võlgnetav 85 € on kohustus, mitte platvormi tulu. Rahvusvaheliste raamatupidamisstandardite (IFRS) kontseptuaalse raamistiku kohaselt on kohustus praegune kohustus loovutada majanduslik ressurss. Turuplats ei tohiks kajastada müüja täielikku müügitulu oma sissetulekuna pelgalt seetõttu, et ostja maksis selle kaudu. See, kas tegutsete vahendaja (agent), põhimüüja (principal) või käibemaksuseaduse mõistes kauba saajana (deemed supplier), muudab kajastamist, kuid pearaamatu mehhanism jääb samaks.
Kui müüjal tekib õigus väljamaksele, uut tulu ei kajastata. Te arveldate kohustuse:
| Konto | Deebet | Kreedit |
|---|---|---|
| Müüjale makstavad summad | 85 € | |
| Pank või väljamaksete arvelduskonto | 85 € | |
| Kokku | 85 € | 85 € |
Kui makseteenuse pakkuja võtab enne arveldamist 3 € tasu, muutub rahavoog kolmerealiseks kandeks: 97 € pangakontole sularahana, 3 € töötlemiskuludesse, 100 € välja makseteenuse pakkuja nõudest. Igal positsiooni muutusel on allikas ja sihtkoht.
Kuidas API samm-sammult toimib
1. Teie rakendus tuvastab ärisündmuse. Makse on laekunud, tellimus on täidetud, väljamakse on kinnitatud, tagasimakse on tehtud, tagasinõue on algatatud, arveldus on laekunud. Teie andmebaas haldab endiselt operatiivset olekut. Pearaamat salvestab rahalise mõju.
2. Saadate struktureeritud päringu. Tavaliselt sisaldab see sündmuse tüüpi, summat ja valuutat, tellimuse või makse ID-d, ostja ja müüja identifikaatoreid, vahendustasu, maksuandmeid, kaasatud kontosid, tehingu- ja postitamiskuupäevi, idempotentsevõtit (idempotency key) ning metaandmeid, mis viitavad tagasi teenusepakkuja ja toote kirjetele. Nordleti avaliku API näide illustreerib kontseptuaalset müügipäringut, mis sisaldab müüja ID-d, müügi tüüpi, summat, valuutat ning käibemaksumäära ja -riiki.
3. API teostab valideerimise. See kontrollib, kas deebet ja kreedit on tasakaalus, kas kontod on olemas ja neile saab postitada, kas valuuta on toetatud, kas summas kasutatakse täpseid väiksemate ühikute käsitlemise reegleid, kas idempotentsevõtit ei ole teise tulemuse saamiseks uuesti kasutatud, kas arveldusperiood on avatud ja kas vajalikud metaandmed on olemas. Ebaõnnestunud kontroll ei jäta maha osalisi kandeid.
4. Postitamine toimib aatomina (atomically). Kogu tehing kirjutatakse ühtse tervikuna. Teil ei tohiks kunagi olla võimalik salvestada deebetit nii, et vastav kreedit ebaõnnestub. Turuplatsi puhul võib osaline jagunemine luua näilise müüjasaldo ilma vastava sularahata või kajastada vahendustasu ilma müüjakohustuseta.
5. Saldod ja aruanded tuletatakse pearaamatust. Pärast postitamist saate lugeda kontode saldosid, müüja ootel ja saadaolevaid saldosid, proovibilanssi, pearaamatu tegevust, käibemaksu kokkuvõtteid ja ajalugu varasema kuupäeva seisuga. Müüjasaldo peaks olema postitustest üles ehitatav, mitte toetuma muudetavale väljale.
6. Veebikonksud (webhooks) teavitavad teie toodet. Sündmused nagu sale_invoice.paid, postitatud kanne, saadaolev väljamakse või vastavuskontrolli erand edastatakse teile. Töötle neid idempotentse loogikaga. Veebikonks on teade, mitte luba rakendada finantssündmust teist korda. API konventsioonid katavad üksikasjalikult ulatusi, idempotentsevõtmeid, veakujusid ja veebikonksude allkirjastamist.
Müüjasaldod ei ole üksainus number
Enamik turuplatse satub raskustesse müüjasaldo käsitlemisega üheainsa numbrina. Raha peaks paiknema erinevates olekutes:
| Olek | Tähendus |
|---|---|
| Ootel (Pending) | Müüjal võib olla õigus saada, kuid vabastamise tingimused pole täidetud |
| Saadaval (Available) | Kõlblik väljamakseks |
| Reserveeritud (Reserved) | Kinni peetud tagasimaksete, tagastuste või vaidluste katteks |
| Välja makstud (Paid out) | Kohustus on ülekandega rahuldatud |
| Negatiivne (Negative) | Tagasimaksed, tagasinõuded või tasud ületavad olemasolevaid vahendeid |
Makseteenuse pakkuja mudelid peegeldavad seda. Stripe'i eraldiseisvad tehingute ja ülekannete vood võimaldavad platvormil laadida oma kontot ja kanda seejärel osi ühendatud kontodele, kusjuures tasud, tagasimaksed ja tagasinõuded maanduvad platvormi saldol. Adyeni turuplatsi mudel eristab kasutajate saldo kontosid, mis hoiavad vahendeid kuni väljamikkeni, kohustuste saldo kontost, mis suudab absorbeerida tagasimaksetest või tagasinõuetest tulenevaid negatiivseid saldosid. Need on kasulikud sisendid teie pearaamatu jaoks, kuid need ei ole teie täielik raamatupidamismudel.
Väljamaksed ja müüja teenitud tulud toimuvad erinevatel aegadel
Müüja võib teenida tulu esmaspäeval ja saada raha järgmisel esmaspäeval. Nende punktide vahel täidetakse tellimus, hoitakse kinni reserv, koostatakse väljamaksete pakett, makseteenuse pakkuja teeb arvelduse, millest on tasud maha arvatud, ja saabub pangasissemakse. Pearaamat peab säilitama iga etapi, selle asemel et kirjutada tellimus üle lõpliku märkega „makstud“. See võimaldab teil selgitada ajalisi erinevusi tellimuste tegevuse, müüja õigustatud nõude, arvelduse, väljamakse algatamise ja pangalaekumise vahel.
Tagasimaksed ja tagasinõuded: pöörake ümber, ärge kirjutage üle
Tagasimaksed ja tagasinõuded on uued sündmused, mis on seotud algse maksega. Muutumatus pearaamatus parandate olukorda ümberpöörava kande ja sellele järgneva parandatud kandega, nii et algne kanne jääb auditi jaoks nähtavaks. Modern Treasury käsitleb postitatud tehinguid muutumatutena ja toetab idempotentsevõtmeid, et vältida korduvaid objekte korduskatsete korral.
Tagasimakse vähendab tavaliselt sularaha või ostja nõuet, pöörab ümber müüjale makstava summa, võib sõltuvalt reeglitest tagasi pöörata osa vahendustasust, korrigeerib makse ja võib kulutada tagasimaksete reservi. Tagasinõue vähendab sularaha või makseteenuse pakkuja nõuet, võib taasavada müüja või platvormi võlgnetava summa, salvestab vaidluskulu ja teenusepakkuja tasu ning liigutab vahendeid reservkontode kaudu.
Vastavuskontroll (reconciliation): pearaamatu sidumine päris rahaga
Pearaamat võib olla sisemiselt tasakaalus, kuid välismaailma suhtes siiski vale. Vastavuskontroll võrdleb sisemisi andmeid väliste tõenditega: makseteenuse pakkuja arveldusaruannete, pangaväljavõtete, väljamaksete failide ning tagasimaksete ja vaidluste kirjetega.
Toimiv tsükkel näeb välja selline:
- Importige arveldus- või pangapakett.
- Sobitage iga rida tellimuse, makse, tagasimakse, tasu, väljamakse või vaidlusega.
- Võrrelge oodatud kogusummat, mahaarvamisi, reservasid ja netosummat.
- Postitage kinnitatud liikumised pearaamatusse.
- Suunake sobimatud kirjed nimetatud vahekontole (suspense account).
- Uurige erandeid.
- Lukustage periood.
Nordleti vastavuskontrolli materjalid kirjeldavad täpselt seda protsessi, importides arvelduspakette, sobitades laekumiste ja tagasimaksete ridu ning suunates sobimatud laekumised vahekontole, selle asemel et arvet arvata. Kaksi kontrolli on olulised ja kumbki ei asenda teist: kahekordse kirjendi valideerimine küsib, kas iga kanne on tasakaalus, ja vastavuskontroll küsib, kas see on kooskõlas makseteenuse pakkuja, panga ja ärisündmusega.
Disaini üksikasjad, mis otsustavad, kas teete selle õigesti
Identsus (Idempotency). Siduge võti stabiilse sündmusega, näiteks payment_captured:pi_123. Korduskatse tagastab algse tulemuse, mitte teise kande.
Aatomilisus (Atomicity). Kõik ühe sündmuse read postitatakse koos või ei postitata ühtegi.
Muutumatus ja ümberpööramised (Immutability and reversals). Postitatud ajalugu ei ole tavaliste uuenduste kaudu muudetav. Parandused loovad seotud kirjed, mis säilitavad algse summa, kuupäeva, klassifikatsiooni, põhjuse ja autori.
Täpne raha. Ei mingeid kahendsüsteemi ujukomaarveid (floating point). Kasutage täisarvulisi väiksemaid ühikuid või täpseid kümnendkohti, selgesõnalist valuutat ja deterministlikku ümardusreeglit jagamistel. Jagage 100 € müüjate ja tasude vahel ilma selleta ning üksik sent rikkub teie saldo.
Tehingu- ja postitamiskuupäevad (Effective vs posting dates). Aeg, millal ostja maksis, millal müüja teenis, millal pank aruandluse tegi ja millal kirje postitati, on erinevad kuupäevad. Nende segiajamine muudab perioodiaruandluse ja maksude ajastuse ebausaldusväärseks.
Mitme valuuta tugi. Deebet ja kreedit peavad olema tasakaalus ühe valuuta piires. Konverteerimine nõuab selgesõnalist kursi sündmust koos kontodega tasu, ümardamise ning võimaliku valuutakursi kasumi või kahjumi jaoks. Valuoksa currency välja aktsepteerimine ei tee pearaamatust veel valuutavahetusmootorit.
Mida pearaamatu API teie heaks ei tee
See ei otsusta teie kontoplaani (chart of accounts) üle. Peate siiski ise määrama, kas olete vahendaja või põhimüüja, millal vahendustasu teenitakse, kumb pool kannab makseteenuse pakkuja tasusid, kuidas tagasimaksed mõjutavad vahendustasu ning kuidas käibemaksu arvutatakse ja deklareeritakse. Nordleti enda juhis on kaardistada esmalt rahavood, koostada kontoplaani projekt, lasta raamatupidajal see üle vaadata ning seejärel rakendada üks täielik voog tellimusest väljamakse ja vastavuskontrollini enne mastaabikadu.
See ei lahenda maksuküsimusi. Käibemaks sõltub ostja ja müüja asukohast, toote tüübist, registreerimisstaatusest ja kauba saaja reeglitest; EL käibemaksu juhend määratleb, mida mootor tuletab ja mida see inimese jaoks märgistab. Nordleti käibemaksu katvus on suunatud EL-ile ja EPsü-le, mistõttu see ei laiene USA müügimaksule ega Ladina-Ameerika e-arveldusele. Samuti ei lahenda see operatiivset ebaselgust – kas tagastusperiood on lõppenud, kas väljamakse tuleks blokeerida, kas makse on pettus. Need on teie otsused. Pearaamat salvestab nende finantstulemuse.
Kuhu Nordlet sobitub
Nordlet on raamatupidamise API, mis on ehitatud platvormidele ja turgudele, sisaldades muutumatut kahekordse kirjendiga pearaamatut, väljamakseid, EL käibemaksu käsitlemist, REST lõpp-punkte, tüübistatud SDK-sid ja veebikonsepte, mis on kättesaadavad üheainsa liidese kaudu. Selle eristuvaks valikuks on sisseehitatud raamatupidamisarhitektuur otse teie tootes, mitte kolmanda osapoole kassalahendus. Artikli kirjutamise ajal on toode varajases juurdepääsus liivakastiga disainipartneritele, seega käsitlege seda selle kategooria tugeva näitena ning hinnake enne pühendumist tootmisküpsust, töökindlust ja jurisdiktsiooni katvust oma juhtumi jaoks.
Turuplatsi- ja platvormiarendajate jaoks on kasulikuks vaimseks mudeliks maksete liikumise ja finantstõe eristamine. Teie makseteenuse pakkuja liigutab raha. Kahekordse kirjendiga pearaamatu API salvestab selle, kellele mida võlgnetakse, mida te teenisite, milliseid makse ja reservasid kannate ning kas välismaailm ühtib teie raamatupidamisega.
FAQ
Kas kahekordse kirjendiga pearaamatu API on sama mis makseteenuse pakkuja?
Ei. Makseteenuse pakkuja autoriseerib, kogub, teeb arveldusi ja maksab mõnikord vahendeid välja. Pearaamatu API salvestab nende sündmuste raamatupidanduslikud tagajärjed. Enamik turuplatse kasutab mõlemat: makseteenuse pakkuja, nagu Stripe või Adyen, liikumiseks ja pearaamat raamatupidamise jaoks.
Kas ma saan lihtsalt kasutada oma makseteenuse pakkuja töölauda pearaamatuna?
Võite proovida, kuid see kukub auditis varem või hiljem läbi. Teenusepakkuja aruanded näitavad tasusid, makseid, ülekandeid ja arveldusi, kuid tavaliselt ei esinda need teie täielikke müüjakohustusi, maksukohustusi, muid kui teenusepakkuja kulusid ega raamatupidamislikke korrigeerimisi. Käsitlege seda vastavuskontrolli sisendina.
Kas tasakaalus pearaamat tähendab, et mu raamatupidamine on õige?
Ainult seda, et teie kirjed vastavad deebet-kreedit reeglile. Täiesti tasakaalus tehingu võib siiski postitada valele kontole, valele müüjale või vale maksustamisega. Tasakaal on vajalik, kuid mitte piisav. Vastavuskontroll on see, mis püüab kinni ülejäänu.
Kui pearaamat on muutumatu, kuidas ma siis vead parandan?
Te postitate ümberpöörava kande ja seejärel parandatud kande. Originaal jääb nähtavaks, mis ongi kogu asja mõte. Muutumatus kaitseb auditijälge, see ei hoia teie vigu lõksus.
Kas raamatupidamise API muudab mu ettevõtte automaatselt nõuetele vastavaks?
Ei. See tagab raamatupidamisliku struktuuri ja toodab kasutatavaid kirjeid. Õiguslik vastavus sõltub endiselt teie jurisdiktsioonist, lepingulisest rollist, maksustamisest, makse-eeskirjadest, KYC ja AML protsessidest ning aruandluskohustustest.