Kahekordse kirjendamise pearaamatu API-d turuplatside raamatupidamises

Enamik turupulatse saab oma raamatupidamisprobleemist teada ühel ja samal viisil: ettevõttesse palgatakse finantsspetsialist, kes avab väljamaksete arvutustabeli ja küsib, kes kurat tegelikult kajastab müüja ees olevat kohustust hetkest, mil ostja maksab, kuni hetkeni, mil raha platvormi kontolt lahkub. Arendusmeeskond viitab tabelile transactions. Finantsspetsialist märgib seevastu, et sündmuste tabel ei ole raamatupidamine. Just selle lünga sündmusaandmete ja päris raamatupidamise vahel aitabki kahekordse kirjendamise pearaamatu API täita.

See on tehniline küsimus, millel on tõsised regulatiivsed tagajärjed. Turuplatsid hoiavad teiste inimeste raha, arvutavad käibemaksu eri jurisdiktsioonide vahel ja esitavad arveid müüjate nimel. Kodukootud tehingutabeliga toimib see seni, kuni audiitor, maksuhaldur või tõsine ostja küsib tõendeid.

Mis on kahekordse kirjendamise pearaamatu API tegelikult

Kahekordse kirjendamise pearaamatu API on programmeeritav raamatupidamismootor, mis on kättesaadav HTTP kaudu. Iga finantssündmus, mille teie platvorm registreerib, kirjutatakse tasakaalus kandeahelana: vähemalt üks deebet ja üks kreedit, mis on kogusummas võrdsed ja kantakse kontoplaani nimikontodele. API tagab selle tasakaalu kirjutamise hetkel ning salvestab kanded viisil, mida ei saa hiljem salaja muuta.

Kahekordse kirjendamise („double-entry“) osa tuleneb neljasaja aasta vanusest raamatupidamisreeglist, mille kohaselt mõjutab iga tehing vähemalt kahte kontot. API osa tähendab, et funktsiooni kutsub esile teie toode, mitte inimsoost raamatupidaja. Muutumatu („immutable“) tähendab, et parandused tehakse tagasikannete, mitte ajaloo muutmise teel. Need kolm omadust muudavad tulemusena valmivad dokumendid auditivalmiks, mitte lihtsalt korrapäraseks.

Kasulik töömääratlus:

Kahekordse kirjendamise pearaamatu API võtab teie rakendusest vastu finantssündmusi, teisendab iga sündmuse tasakaalustatud kandeahelaks vastavalt määratletud kontoplaanile, salvestab need kanded muutumatult ning teeb saadud pearaamatu, ammendava saldodetabeli ja finantsaruanded kättesaadavaks prognoositavate otspunktide kaudu.

Nordlet on üles ehitatud täpselt sellele ideele: päris raamatupidamine API kaudu, kus pearaamatu, käibemaksu loogika, arveldamise ja vastavusse viimise juurde pääseb samade otspunktide kaudu, mida teie toode juba kasutab.

Miks turuplatsid seda konkreetselt vajavad

Üheainsa kaupmehe tarkvarateenus (SaaS) pääseb sageli sellest, et sünkroonib andmed üldise raamatupidamistööriistaga kord päevas. Turuplatsid seda teha ei saa, ja seda kolmel põhjusel.

Esiteks on nad raha liikumise keskmes. Ostja maksab platvormile, platvorm hoiab vahendeid ja maksab seejärel müüjatele tasud maha arvestades. Iga selline liikumine on eraldiseisev raamatupidamissündmus, mis mõjutab erinevaid kontosid: raha, müüjate tasumata arved, platvormi tulud, tasumisele kuuluv käibemaks, tagasimaksete reservid. Veeru status abil loodud tabel payments seda ei kajasta.

Teiseks tegutsevad nad mitmes maksujurisdiktsioonis. EL-i turuplats, mille müüjad asuvad Leedus, Saksamaal ja Poolas ning ostjad üle kogu liidu, peab rakendama tehingupõhiselt õiget käibemaksurežiimi, valideerima müüjate käibemaksunumbreid VIES-i kaudu ja esitama aruandeid, mis vastavad iga kohaliku asutuse nõuetele. Selle õige tegemine rakenduse koodis ja selle hilisem vastavusse viimine eraldiseisva raamatupidamissüsteemiga on koht, kus enamik turupulatse märkamatult hätta jääb.

Kolmandaks on maht käsitsi raamatupidamiseks liiga suur. Platvorm, mis teeb kümme tuhat tellimust kuus, genereerib kümneid tuhandeid kandeid. See peab olema algusest lõpuni automatiseeritud, muidu muutub finantsmeeskond kasvule pudelikaelaks.

Kuidas API samm-sammult töötab

Selle mehaanika on vähem eksootiline, kui kõlab. Tüüpiline voog turuplatsi tellimuse jaoks näeb välja järgmine:

1. Teie platvorm edastab finantssündmuse. Ostja viib kassas ostu lõpule. Teie taustsüsteem kutsub pearaamatu API-d välja selliste andmetega nagu tellimuse ID, ostja, müüja, kogusumma, käibemaksumäär, platvormi vahendustasu, valuuta ja idempotentne võti.

2. Pearaamat koostab kande. API tõlgendab selle sündmuse deebetiteks ja kreedititeks. Otsese turuplatsi müügi puhul võib see tähendada teel oleva raha konto deebetit, müüja võlgnevuste konto kreeditit netosummas, platvormi tulukonto kreeditit vahendustasu osas ja käibemaksukohustuse konto kreeditit maksusumma osas. Kõik on tasakaalus. Kõik postitatakse aatomiliselt.

3. Kandele kirjutatakse muutumatult. Pärast postitamist on kandel identifikaator ja ajatempel ning seda ei saa muuta. Kui midagi on valesti, postitate tagasikande ja korrigeeritud kande. Audiitori jälgitavus ongi siin peamine eesmärk.

4. Alamaruanded uuenevad reaalajas. Saldodetabel, müüjate võlgnevuste saldod, käibemaksu kokkuvõtted ja kasumiaruanne kajastavad uut kannet viivitamatult. Puuduvad öised protsessid, eksport ja vastavusse viimise aknad, kus numbrid alles „loksuvad paika“.

5. Veebikonksud teavitavad teie süsteemi. Teie otspunktidesse saadetakse sündmused nagu sale_invoice.paid või bank_transaction.matched, et teie toode saaks reageerida ilma päringuid tegemata. Koos identsete võtmetega tähendab see, et korduskutsed on turvalised ja võrgu tõrgete korral ei teki duplikaate.

Oluline disainipõhimõte: pearaamat on finantsilises mõttes tõeallikas selle kohta, mis juhtus. Teie rakenduse andmebaas on tõeallikas toote oleku kohta. Mõlemad süsteemid viiakse vastavusse seetõttu, et pearaamat kirjutatakse rakenduse sündmuste põhjal, mitte vastupidi.

Kontoplaan on koht, kus tehakse peamine disainitöö

Suurem osa intellektuaalsest vaevast turuplatsi pearaamatu seadistamisel kulub kontoplaanile. See on nimekiri nimikontodest, kuhu deebetid ja kreeditid jõuavad: pangakontode kaupa sularahakontod, müüjate võlgnevuste kontod (sageli üks müüja kohta või koondkontod alamraamatutega), platvormi tulud kategooriate kaupa, käibemaksukohustused riigiti, tagasimaksete reservid, tagasinõuete reservid ja nii edasi.

Mõned mustrid, mis turuplatsidel korduvad:

• Müüjate raha on kohustus, mitte tulu. Raha, mida hoiate müüjate nimel, on võlgnevus. Selle käsitlemine tuluna ja väljamakse hilisem kuludesse kandmine on klassikaline viga, mis tuleb ilmsiks hoolsusauditi (due diligence) käigus.
• Käibemaks on riigiti eraldi kohustus. Kui tegutsete EL-i jurisdiktsioonides, soovite selgeid käibemaksukohustuse kontosid riikide kaupa, et aruanded saaksid puhtalt kaardistatud.
• Tasud tuleb modelleerida nende teenimise hetkel, mitte siis, kui need välja makstakse. Tekkepõhine raamatupidamine ei ole siin vabatahtlik.
• Tagasimaksed, tagasinõuded ja vaidlused vajavad igaüks oma kontot, et kasumiaruanne kajastaks tegelikkust, mitte positiivsete ja negatiivsete müükide segadikku.

Hea pearaamatu API võimaldab teil selle struktuuri ühekordselt määratleda ja seejärel enesekindlalt kandeid teha, selle asemel et leiutada raamatupidamisloogikat uuesti oma ostukorvikoodis.

Muutumatus, perioodide lukustamine ja miks audiitoreid see huvitab

Muutumatus kõlab nagu andmebaasi tehniline detail. Tegelikult on see vahe raamatupidamise vahel, millele audiitor annab oma heakskiidu, ja sellise vahel, millele ta seda ei tee.

Kui turuplats saab eelmise kvartali kandeid salaja muuta, ei ole eelmise kvartali numbrid raamatupidamislikus mõttes teadaolevad. Muutumatu pearaamat jõustab reegli, et ajalugu on ajalugu. Parandused on nähtavad parandustena. Perioodide lukustamine laiendab seda: kui kuu on suletud, ei saa sellesse perioodi siseneda uusi kandeid ega muudatusi ilma selgesõnalise avamistoiminguta, mis ise logitakse.

Platvormide jaoks, mis plaanivad tulevikus kaasata rahastust, müüa ettevõtte või seista silmitsi maksuauditiga, ei ole see lihtsalt tore lisa. See on asi, mis muudab raamatupidamise kaitstavaks. Nordleti pearaamat on vaikimisi sellele üles ehitatud, kusjuures muutumatu kahekordse kirjendamise struktuur ja perioodide lukustamine on sisse ehitatud, mitte hiljem külge poogitud.

EL-i käibemaks: osa, mis kulutab arendusaega

Käibemaks on valdkond, kus enamik turupulatse oma raamatupidamiprojektidega ajahätta jääb. Reeglid ei seisne lihtsalt protsendi rakendamises. Need sõltuvad sellest, kus asub ostja, kus asub müüja, mida müüakse, kas müüja on käibemaksukohuslane, kas turuplats on 2021. aasta e-kaubanduse reeglite alusel käsitletav maksukohustuslasest edasimüüjana (deemed supplier) ning milline aruandlusrežiim kohapeal kehtib.

Tõsine EL-i turule mõeldud pearaamatu API haldab vähemalt järgmist:

• VIES-i valideerimine müüja ja ostja käibemaksunumbritele, ideaalis tulemuste vahemällu salvestamise ja tehingule templi lisamisega;
• riigipõhine käibemaksumäärade loogika, sealhulgas soodusmäärad ja erandid;
• i.SAF-i registri genereerimine Leedu aruandluse jaoks ja vastavad struktureeritud väljundid, kui teised liikmesriigid neid nõuavad;
• Peppol BIS 3.0 e-arveldus jurisdiktsioonide jaoks, mis lähevad üle kohustuslikule e-arveldusele;
• OSS/IOSS-i käitlemine piiriüleste B2C-müükide puhul.

Selle tegemine rakenduse koodis riikide kaupa on terve arendusmeeskonna mahukas töö, mis ei saa tegelikult kunagi valmis, sest reeglid muutuvad pidevalt. Selle lükkamine pearaamatu kihti on pragmaatiline valik.

Vastavusse viidavus on koht, kus ilmneb ajasääst

Kui pearaamat on tõeallikas, lakkab pangakonto andmete vastavusse viimine olemast igakuine piin. Väljavõtted saabuvad, pearaamat teab juba, mis seal peaks olema, ja vastavusse viimine on suuresti automaatne.

Selle realistlik versioon ei ole „null käsitsitööd“, vaid „erandid toodavad end ise pinnale“. Ühe klõpsuga vastavusse viimise voog 90 protsendi tehingute jaoks, mis klapivad puhtalt, pluss nende 10 protsendi järjekord, mis vajavad inimese otsust, on ligikaudu see, mida hästi disainitud vastavusse viimise API pakub. Nutikas maksete sobitamine käsitleb osalisi makseid, enammakseid ja makseid, mis katavad mitu arvet ilma, et inimene peaks igale juhtumile reegleid kirjutama.

SEPA eksport (pain.001 formaat) tarnijate ja müüjate väljamakseteks sulgeb väljamineva poole tsükli. Te kiidate oma tootes väljamaksed heaks, pearaamat genereerib SEPA faili, teie pank töötleb selle ja tulemusena tekkinud liikumine viiakse automaatselt vastavusse.

Ehita vs osta vs integreeri

Turuplatsi meeskonnad kipuvad kaaluma kolme teed. Siin on nende võrdlus oluliste kriteeriumide alusel.

Lähenemine	Aeg tootmiskeskkonnani	Auditivalmidus	EL-i käibemaksu käitlemine	Sobib teie toote sisse
Ehitage oma pearaamat	12 kuni 24+ kuud	Sõltub täielikult teie meeskonnast	Ehitate ise, riigiti	Jah
Sünkroniseerige Xero/QuickBooksiga	Nädalad	Hea raamatupidamise poole pealt, nõrk turuplatsi spetsiifiliste voogude jaoks	Osaliselt, nõuab lisamooduleid	Ei, elab eraldi tööriistas
Integreerige pearaamatu API (nt Nordlet)	Nädalad	Sisseehitatud tänu muutumatule pearaamatule ja perioodide lukustamisele	Sisseehitatud EL-i jaoks, sh VIES ja i.SAF	Jah, API ja SDK-de kaudu

Oma süsteemi ehitamine on põhjendatud juhul, kui raamatupidamine on teie toode. Kõigi teiste jaoks matemaatika harva klapib. Sünkroniseerimine traditsioonilise raamatupidamistööriistaga sobib ühe ettevõttega ärimudelitele, kuid annab järele turuplatsi voogude all: poolitatud maksed, müüjate alamraamatud, riigipõhine käibemaks ja platvormi kui maksukohustuslasest edasimüüja stsenaariumid ei sobitu puhtalt ühe ettevõtte raamatupidamisele mõeldud tööriistadega.

API-keskse pearaamatu integreerimine on suund, millele enamik kaasaegseid platvorme liigub. Raamatupidamine elab teie toote kasutajakogemuses, müüjad näevad oma finantse teie kasutajaliideses ja nõuetele vastavuse raske töö tehakse ära taristu kihis.

Mida silmas pidada pearaamatu API hindamisel

Lühike kontroll-leht, mida müüjatega suhtlemisel lahti hoida:

• Muutumatu kahekordse kirjendamise salvestus tagasikannetega parandustega, mitte muudetavate ridadega;
• perioodide lukustamine logitud avamistoimingutega;
• idempotentsed võtmed igal kirjutamise otspunktil;
• veebikonksud sündmuste jaoks, millele teie toode peab reageerima, mitte ainult päringute tegemise API;
• tüübistatud SDK-d keeltes, mida teie meeskond tegelikult kasutab;
• riigipõhine käibemaksu loogika, sealhulgas VIES, i.SAF või samaväärsed ning OSS/IOSS;
• mitme ettevõtte tugi, kui tegutsete mitme juriidilise isikuga või plaanite seda teha;
• rollipõhine juurdepääs, mis on piisavalt peeneteraline arendajate, raamatupidajate ja vaatajate eraldamiseks;
• aruannete eksport XLSX-, PDF- ja JSON-formaadis koos veebikonksu teavitustega, kui suured aruanded on valmis;
• liivakast (sandbox), mis peegeldab tootmiskeskkonna käitumist, mitte kärbitud demokeskkonda.

Kui müüja ei suuda tehnilisel kõnel esimesi kolme punkti demonstreerida, ei ole ülejäänul enam tähtsust.

Mida ma teeksin esimesena

Kui turuplats alustab seda tööd nullist, siis järjestus, mis säästab kõige rohkem vaeva:

1. Kaardistage tegelikud rahavood tahvlil enne ühegi koodirea kirjutamist. Kes on kellele võlgu, mis hetkel, mis valuutas, millise käibemaksurežiimiga.
2. Visandage selle kaardi põhjal kontoplaan. Müüjate võlgnevused, platvormi tulud, tasumisele kuuluv käibemaks riigiti, reservid. Laske raamatupidajal see enne tootmisesse minekut üle vaadata.
3. Valige pearaamatu kiht. Ehitage, sünkroniseerige või integreerige. Olge aus selles osas, mida teie meeskond suudab tegelikult tarnida ja hooldada.
4. Rakendage üks voog algusest lõpuni: tellimusest arveni, väljamakseni ja vastavusse viimiseni. Tõestage, et see on tasakaalus. Seejärel skaleerige.
5. Lülitage perioodide lukustamine sisse kohe, kui esimene kuu on puhtalt suletud. Distsipliin hakkab end ära tasuma.

Meeskonnad, kes teevad selle õigesti, käsitlevad pearaamatut põhitaristuna, mitte aruandluse tagantjärele lisatud osana. See ongi muutus, mis teeb finantsvestluse audiitori, investori või maksuhalduriga lühikeseks, mitte pikaks.

FAQ

Kas kahekordse kirjendamise pearaamatu API on sama mis raamatupidamise integratsioon?

Ei. Integratsioon sünkroniseerib andmed teie tootest välisesse raamatupidamistööriista, tavaliselt viivitusega. Pearaamatu API on raamatupidamissüsteem ise, kuhu kirjutatakse otse ja reaalajas. See vahe on oluline, sest integratsioonid kaotavad servades täpsuse: osalised maksed, mitu valuutat, turuplatsi jaotused. Pearaamatu API salvestab need algupäraselt.

Kas me ei saa lihtsalt kasutada Stripe'i või Adyeni aruandlust?

Makseprotsessori aruanded ütlevad teile, mis protsessori kaudu liikus. Need ei ole kahekordse kirjendamise raamatupidamine. Need ei tea midagi teie müüjate võlgnevustest, mida pole veel välja makstud, teie käibemaksukohustustest eri riikides ega kuludest, mis ei käi makseprotsessori kaudu. Need on üks sisend pearaamatusse, mitte selle asendaja.

Kui muutumatu on muutumatu praktikas?

Kandeid ei saa muuta. Parandused on uued kanded, mis viitavad algsele. See on disaini-, mitte tehnoloogiaotsus. Iga pädev pearaamat jõustab seda. Põhjus, miks sellest hoolida, on see, et „me muutsime seda, et see klapiks pangaga“, on täpselt muster, mis muudab raamatupidamise ebausaldusväärseks.

Kuidas on lood väljaspool EL-i asuvate turuplatsidega?

Kahekordse kirjendamise mehaanika on universaalne. Maksuloogika mitte. EL-i käibemaksu jaoks optimeeritud pearaamatu API saab EL-i kesksete toimingutega hästi hakkama ja toetab ka EL-i väliseid tehinguid, kuid kui teie peamine turg on USA müügimaks või Ladina-Ameerika e-arveldusrežiimid, kontrollige enne otsuse tegemist konkreetset nõuetele vastavuse ulatust.

Kui kaua rakendamine tegelikult aega võtab?

Puhast sündmuste mudelit kasutava turuplatsi jaoks on pearaamatu API integreerimine ühe voo algusest lõpuni käivitamiseni tavaliselt mõne nädala pikkune arendustöö. Täielik migreerimine pärastsüsteemist, sealhulgas ajaloolised andmed, võtab kauem aega. Muutujaks on peaaegu alati olemasolevate andmete seisukord, mitte API ise.