Dvejybinio įrašo didžiosios knygos API, skirti prekyviečių apskaitai
Techninis vadovas apie tai, kaip veikia nekeičiami dvejybinio įrašo didžiosios knygos API, kodėl jie būtini prekyvietėms ir į ką atkreipti dėmesį integruojant apskaitą į savo platformą.
Dauguma prekyviečių (marketplaces) apie turimas apskaitos problemas sužino vienodai: ateina naujas finansų specialistas, atsidaro išmokėjimų skaičiuoklę ir paklausia, kas iš tikrųjų užregistruoja įsipareigojimą pardavėjams nuo to momento, kai pirkėjas sumoka, iki tol, kol lėšos palieka platformos sąskaitą. Inžinierių komanda parodo į lentelę transactions. Finansų specialistas pastebi, kad įvykių lentelė nėra apskaitos knygos. Šis atotrūkis tarp įvykių duomenų ir tikrosios apskaitos yra būtent tai, ką dvejybinio įrašo didžiosios knygos API yra sukurtas užpildyti.
Tai techninis klausimas, turintis rimtų teisinių pasekmių. Prekyvietės laiko svetimus pinigus, skaičiuoja PVM skirtingose jurisdikcijose ir išrašo sąskaitas faktūras pardavėjų vardu. Daryti tai naudojant savadarbę operacijų lentelę tinka tol, kol auditorius, mokesčių administratorius ar rimtas pirkėjas nepaprašo įrodymų.
Kas iš tikrųjų yra dvejybinio įrašo didžiosios knygos API
Dvejybinio įrašo didžiosios knygos API yra programuojamas apskaitos variklis, pasiekiamas per HTTP. Kiekvienas jūsų platformoje užfiksuotas finansinis įvykis įrašomas kaip balansuojantis žurnalo įrašas: bent vienas debetas ir vienas kreditas, kurių bendros sumos yra lygios, priskirti konkrečioms sąskaitoms iš sąskaitų plano. API užtikrina šį balansą įrašymo metu ir saugo įrašus taip, kad vėliau jų nebūtų galima tyliai pakeisti.
„Dvejybinio įrašo“ dalis remiasi keturių šimtų metų senumo apskaitos taisykle, kad kiekviena operacija paveikia bent dvi sąskaitas. „API“ dalis reiškia, kad kreipimąsi vykdo jūsų produktas, o ne žmogus – buhalteris. „Nekeičiamumo“ (immutable) dalis reiškia, kad taisymai atliekami per stornuojančius (atvirkštinius) įrašus, o ne keičiant istoriją. Kartu šios trys savybės lemia, kad suformuotos knygos yra paruoštos auditui, o ne tiesiog tvarkingos.
Naudingas darbinis apibrėžimas:
Dvejybinio įrašo didžiosios knygos API priima finansinius įvykius iš jūsų programinės įrangos, paverčia kiekvieną iš jų į balansuojantį žurnalo įrašą pagal apibrėžtą sąskaitų planą, saugo tuos įrašus nekeičiamai ir pateikia sugeneruotą didžiąją knygą, bandomąjį balansą bei finansines ataskaitas per nuspėjamus galinius punktus (endpoints).
Nordlet yra sukurtas būtent remiantis šia idėja: tikros apskaitos knygos kaip API, kur didžioji knyga, PVM logika, sąskaitų faktūrų išrašymas ir sutikrinimas yra pasiekiami per tą patį galinių punktų rinkinį, su kuriuo jūsų produktas jau bendrauja.
Kodėl būtent prekyvietėms to reikia
Vieno prekybininko SaaS įmonė dažnai gali išsiversti kartą per dieną sinchronizuodama duomenis su bendru apskaitos įrankiu. Prekyvietės to daryti negali dėl trijų priežasčių.
Pirma, jos stovi pinigų srautų viduryje. Pirkėjas sumoka platformai, platforma laiko lėšas, tada sumoka pardavėjams, atskaičiusi komisinius. Kiekvienas iš šių judėjimų yra atskiras apskaitos įvykis, darantis įtaką skirtingoms sąskaitoms: pinigams, mokėtinoms sumoms pardavėjams, platformos pajamoms, mokėtinam PVM, grąžinimų atidėjiniams. Lentelė payments su stulpeliu status to neatspindi.
Antra, jos veikia skirtingose mokesčių jurisdikcijose. ES prekyvietė, kurios pardavėjai yra Lietuvoje, Vokietijoje ir Lenkijoje, o pirkėjai – visoje Bendrijoje, turi pritaikyti teisingą PVM traktavimą kiekvienai operacijai, patikrinti pardavėjų PVM mokėtojų kodus VIES sistemoje ir parengti deklaracijas, kurios tenkintų kiekvienos vietinės institucijos reikalavimus. Bandant tai teisingai įgyvendinti programos kode ir po to sutikrinti su atskira apskaitos sistema, dauguma prekyviečių tyliai palūžta.
Trečia, apimtys nėra tinkamos rankinei buhalterijai. Platforma, apdorojanti dešimt tūkstančių užsakymų per mėnesį, sukuria dešimtis tūkstančių žurnalo įrašų. Tai turi būti visiškai automatizuota nuo pradžios iki galo, antraip finansų komanda tampa stabdžiu įmonės augimui.
Kaip veikia API, žingsnis po žingsnio
Mechanika yra mažiau egzotiška, nei skamba. Įprastas prekyvietės užsakymo srautas atrodo taip:
1. Jūsų platforma sugeneruoja finansinį įvykį. Pirkėjas užbaigia apmokėjimą. Jūsų vidinė sistema (backend) kreipiasi į didžiosios knygos API, pateikdama, pavyzdžiui: užsakymo ID, pirkėją, pardavėją, bruto sumą, PVM tarifą, platformos komisinį mokestį, valiutą ir idempotentiškumo raktą.
2. Didžioji knyga suformuoja žurnalo įrašą. API paverčia šį įvykį į debeto ir kredito įrašus. Paprastam prekyvietės pardavimui tai gali reikšti „Pinigai kelyje“ sąskaitos debetavimą, mokėtinų sumų pardavėjui sąskaitos kreditavimą grynajai sumai, platformos pajamų sąskaitos kreditavimą komisiniams ir mokėtino PVM sąskaitos kreditavimą mokesčio daliai. Viskas subalansuota. Viskas užregistruota atomiškai (atomically).
3. Įrašas išsaugomas nekeičiamai. Sukūrus įrašą, jam suteikiamas identifikatorius bei laiko žyma, ir jo nebegalima redaguoti. Jei kažkas negerai, registruojamas stornuojantis įrašas ir naujas, teisingas įrašas. Audito seka čia yra svarbiausia.
4. Susijusios ataskaitos atsinaujina realiuoju laiku. Bandomasis balansas, mokėtinos sumos pardavėjams, PVM suvestinės ir pelno bei nuostolių ataskaita (P&L) nedelsiant atspindi naują įrašą. Nereikia jokių naktinių užduočių, eksportų ar sutikrinimo langų, kai skaičiai dar „nusistovi“.
5. „Webhooks“ informuoja jūsų sistemą. Tokie įvykiai kaip sale_invoice.paid arba bank_transaction.matched išsiunčiami į jūsų galinius punktus, kad jūsų produktas galėtų reaguoti be nuolatinio apklausimo. Kartu su idempotentiškumo raktais tai reiškia, kad pakartotiniai bandymai yra saugūs ir tinklo sutrikimų metu neatsiranda dublikatų.
Svarbus architektūrinis aspektas: didžioji knyga yra vienintelis teisingas šaltinis apie tai, kas įvyko finansine prasme. Jūsų programos duomenų bazė yra šaltinis apie produkto būseną. Dvi sistemos yra suderinamos, nes didžioji knyga pildoma iš programos įvykių, o ne atvirkščiai.
Sąskaitų planas yra ten, kur vyksta projektavimo darbai
Didžiausios intelektualinės pastangos konfigūruojant didžiąją knygą prekyvietei tenka sąskaitų planui. Tai yra sąrašas pavadintų „kibirų“, į kuriuos krenta debetai ir kreditai: pinigų sąskaitos pagal bankus, mokėtinos sumos pardavėjams (dažnai viena kiekvienam pardavėjui arba viena bendra su sub-knygomis), platformos pajamos pagal kategorijas, mokėtinas PVM pagal šalis, grąžinimų atidėjiniai, ginčijamų operacijų (chargebacks) atidėjiniai ir t. t.
Keletas modelių, pasikartojančių prekyvietėse:
- Pardavėjų lėšos yra įsipareigojimas, o ne pajamos. Lėšos, kurias laikote pardavėjų vardu, yra mokėtina suma. Jų traktavimas kaip pajamų ir vėlesnis išmokėjimo registravimas kaip „išlaidų“ yra klasikinė klaida, kuri išryškėja per išsamų patikrinimą (due diligence).
- PVM yra atskiras įsipareigojimas kiekvienai šaliai. Jei vykdote veiklą skirtingose ES jurisdikcijose, jums reikia atskirų mokėtino PVM sąskaitų kiekvienai šaliai, kad mokesčių deklaracijos būtų sklandžiai susietos.
- Mokesčiai turi būti apskaitomi tuo momentu, kai jie uždirbami, o ne tada, kai jie išmokami. Kaupimo principas čia nėra pasirenkamas dalykas.
- Grąžinimai, pinigų grąžinimo reikalavimai ir ginčai reikalauja atskirų sąskaitų, kad pelno ir nuostolių ataskaita atspindėtų realybę, o ne tiesiog teigiamų ir neigiamų pardavimų mišinį.
Geras didžiosios knygos API leidžia vieną kartą apibrėžti šią struktūrą ir tada užtikrintai siųsti į ją duomenis, užuot išradinėjus apskaitos logiką apmokėjimo kode.
Nekeičiamumas, laikotarpio uždarymas ir kodėl tai rūpi auditoriams
Nekeičiamumas skamba kaip duomenų bazės detalė. Iš tiesų, tai yra skirtumas tarp knygų, kurias auditorius patvirtins, ir tų, kurių nepatvirtins.
Jei prekyvietė gali tyliai redaguoti praėjusio ketvirčio įrašus, tada praėjusio ketvirčio skaičiai, apskaitos prasme, yra nežinomi. Nekeičiama didžioji knyga užtikrina taisyklę, kad istorija yra istorija. Taisymai matomi kaip taisymai. Laikotarpio uždarymas (period locking) tai praplečia: kai mėnuo uždaromas, į tą laikotarpį negali patekti nauji įrašai ar pakeitimai be aiškaus atidarymo veiksmo, kuris pats taip pat registruojamas.
Platformoms, kurios ilgainiui pritrauks finansavimą, bus parduodamos arba susidurs su mokestiniu patikrinimu, tai nėra tik „gražus priedas“. Tai yra tai, kas daro apskaitos knygas apginamas. Nordlet didžioji knyga yra sukurta būtent šiuo principu kaip numatytuoju – nekeičiama dvejybinio įrašo struktūra ir laikotarpio uždarymas yra įdiegti į patį branduolį, o ne prirašyti vėliau.
ES PVM: dalis, kuri ryja inžinierių laiką
PVM yra ta sritis, kur dauguma prekyviečių apskaitos projektų viršija numatytą laiką ir biudžetą. Taisyklės nėra tiesiog „pritaikyti procentą“. Jos priklauso nuo to, kur yra pirkėjas, kur yra pardavėjas, kas yra parduodama, ar pardavėjas registruotas PVM mokėtoju, ar prekyvietė laikoma numanomu tiekėju (deemed supplier) pagal 2021 m. e. prekybos taisykles, ir koks atskaitomybės režimas taikomas vietoje.
Rimtas didžiosios knygos API, skirtas ES, apdoroja bent šiuos dalykus:
- Pardavėjų ir pirkėjų PVM mokėtojų kodų VIES validacija, idealiai – išsaugant rezultatus podėlyje ir priskiriant juos prie operacijos
- PVM tarifų logika pagal šalį, įskaitant lengvatinius tarifus ir neapmokestinamuosius atvejus
- i.SAF registro generavimas Lietuvos deklaracijoms ir lygiaverčiai struktūruoti duomenys ten, kur to reikalauja kitos valstybės narės
- Peppol BIS 3.0 el. sąskaitų faktūrų išrašymas jurisdikcijoms, pereinančioms prie privalomų elektroninių sąskaitų faktūrų
- OSS/IOSS tvarkymas tarptautiniams B2C pardavimams
Programuojant tai programos kode kiekvienai šaliai atskirai, sukuriama pilnos inžinierių komandos darbo apimtis, kuri niekada iš tikrųjų nesibaigia, nes taisyklės nuolat keičiasi. Tai perkelti į didžiosios knygos lygmenį yra pragmatiškas sprendimas.
Sutikrinimas yra tai, kur pasimato sutaupytas laikas
Kai didžioji knyga tampa vieninteliu teisingu šaltiniu, banko operacijų sutikrinimas nustoja būti kasmėnesine kančia. Gaunami banko išrašai, didžioji knyga jau žino, kas ten turėtų būti, ir sutapatinimas daugiausia vyksta automatiškai.
Realistiška to versija nėra „nulis rankinio darbo“. Tai – „išimtys iškyla pačios“. Vieno paspaudimo sutikrinimo srautas devyniasdešimčiai procentų operacijų, kurios sutampa sklandžiai, plius eilė tų dešimties procentų, kuriems reikia žmogaus sprendimo – tai iš esmės yra tai, ką suteikia gerai suprojektuotas sutikrinimo API. Išmanus mokėjimų sutapatinimas apdoroja dalinius mokėjimus, permokas ir mokėjimus, kurie padengia kelias sąskaitas faktūras, be poreikio žmogui kurti taisykles kiekvienam atvejui.
SEPA eksportas (pain.001 formatu) tiekėjų ir pardavėjų išmokėjimams uždaro ciklą išlaidų pusėje. Jūs patvirtinate išmokėjimus savo produkte, didžioji knyga sugeneruoja SEPA failą, jūsų bankas jį apdoroja, ir atitinkamas lėšų judėjimas automatiškai sutikrinamas atgalinėje grandinėje.
Kurti, pirkti ar integruoti
Prekyviečių komandos dažniausiai svarsto tris kelius. Štai kaip jie lyginami pagal svarbiausius kriterijus.
| Požiūris | Laikas iki paleidimo | Pasirengimas auditui | ES PVM tvarkymas | Tinka jūsų produkte |
|---|---|---|---|---|
| Nuosavos didžiosios knygos kūrimas | 12-24+ mėnesiai | Priklauso tik nuo jūsų komandos | Kuriate jūs, kiekvienai šaliai atskirai | Taip |
| Sinchronizacija su Xero/QuickBooks | Savaitės | Gerai apskaitos pusei, silpna prekyvietėms specifiniams procesams | Dalinis, reikia papildinių | Ne, gyvena atskirame įrankyje |
| Didžiosios knygos API integravimas (pvz., Nordlet) | Savaitės | Įdiegta per nekeičiamą didžiąją knygą ir laikotarpio uždarymą | Įdiegta ES, įskaitant VIES ir i.SAF | Taip, per API ir SDK |
Nuosavo sprendimo kūrimas yra pateisinamas, jei apskaita yra jūsų produktas. Visiems kitiems matematika retai atsiperka. Sinchronizacija su tradiciniu apskaitos įrankiu tinka vieno juridinio asmens verslams, bet neatlaiko apkrovos taikant prekyviečių srautus: skaidyti mokėjimai (split payments), pardavėjų sub-knygos, PVM pagal šalis ir platformos kaip numanomo tiekėjo scenarijai nėra lengvai pritaikomi įrankiams, sukurtiems vienos įmonės apskaitai.
Integruojama didžioji knyga, kurioje API yra pirmoje vietoje, yra tai, link ko krypsta dauguma modernių platformų. Knygos gyvena jūsų produkto aplinkoje, pardavėjai mato savo finansinius duomenis jūsų vartotojo sąsajoje, o sunkiausi atitikties darbai sutvarkomi infrastruktūros lygmeniu.
Į ką atkreipti dėmesį vertinant didžiosios knygos API
Trumpas kontrolinis sąrašas, kurį verta turėti po ranka per pokalbius su tiekėjais:
- Nekeičiama dvejybinio įrašo saugykla su stornuojančiais įrašais taisymams, o ne redaguojamomis eilutėmis
- Laikotarpio uždarymas su registruojamais atidarymo veiksmais
- Idempotentiškumo raktai kiekviename įrašymo galiniame punkte
- „Webhooks“ įvykiams, į kuriuos jūsų produktas turi reaguoti, o ne tik apklausimo API
- Tipizuoti SDK kalbomis, kurias iš tikrųjų naudoja jūsų komanda
- PVM logika pagal šalį, įskaitant VIES, i.SAF ar jų atitikmenis bei OSS/IOSS
- Kelių įmonių palaikymas, jei vykdote (arba planuojate vykdyti) veiklą per kelis juridinius asmenis
- Prieigos kontrolė pagal roles, pakankamai detali, kad atskirtų kūrėjus, buhalterius ir peržiūros teisę turinčius asmenis
- Ataskaitų eksportas XLSX, PDF ir JSON formatais su webhook pranešimais, kai didelės ataskaitos yra paruoštos
- Smėliadėžė (sandbox), kuri atspindi gamybinės aplinkos elgseną, o ne apkarpytą demonstracinę versiją
Jei tiekėjas negali pademonstruoti pirmųjų trijų techninio skambučio metu, visa kita nebesvarbu.
Ką daryčiau pirmiausia
Jei prekyvietė pradeda šį darbą nuo nulio, veiksmų seka, kuri sutaupo daugiausiai vargo:
- Prieš rašant bet kokį kodą, lentoje nubraižykite realius pinigų srautus. Kas kam skolingas, kuriuo momentu, kokia valiuta ir kaip tai traktuojama PVM atžvilgiu.
- Remdamiesi šia schema, parenkite sąskaitų planą. Mokėtinos sumos pardavėjams, platformos pajamos, mokėtinas PVM pagal šalį, atidėjiniai. Prieš paleidžiant tai į gamybą, paprašykite buhalterio jį patikrinti.
- Pasirinkite didžiosios knygos sluoksnį. Kurkite, sinchronizuokite arba integruokite. Būkite atviri sau apie tai, ką jūsų komanda realiai gali sukurti ir palaikyti.
- Įdiekite vieną srautą nuo pradžios iki galo: nuo užsakymo iki sąskaitos faktūros, išmokėjimo ir sutikrinimo. Įrodykite, kad jis balansuojamas. Tada skaluokite.
- Įjunkite laikotarpio uždarymą iškart, kai tik tvarkingai užsidaro pirmas mėnuo. Disciplina atsiperka su kaupu.
Komandos, kurios tai padaro teisingai, žiūri į didžiąją knygą kaip į pagrindinę infrastruktūrą, o ne kaip į ataskaitų priedą, apie kurį pagalvojama paskiausiai. Tai yra esminis lūžis, lemiantis, kad finansinis pokalbis su auditoriumi, investuotoju ar mokesčių administratoriumi būtų trumpas, o ne ilgas.
D.U.K.
Ar dvejybinio įrašo didžiosios knygos API yra tas pats, kas apskaitos integracija?
Ne. Integracija sinchronizuoja duomenis iš jūsų produkto į išorinį apskaitos įrankį, dažniausiai su vėlavimu. Didžiosios knygos API yra apskaitos sistema, į kurią įrašoma tiesiogiai, realiuoju laiku. Šis skirtumas yra svarbus, nes integracijos praranda tikslumą pakraščiuose: daliniai mokėjimai, kelių valiutų naudojimas, prekyvietės skaidyti mokėjimai. Didžiosios knygos API šiuos dalykus registruoja natūraliai.
Ar negalime tiesiog naudoti Stripe arba Adyen ataskaitų?
Mokėjimų apdorojimo įmonių ataskaitos parodo, kas perėjo per jų sistemas. Tai nėra dvejybinio įrašo knygos. Jos nežino apie jūsų įsipareigojimus pardavėjams, kurie dar nebuvo išmokėti, jūsų PVM įsipareigojimus skirtingose šalyse ar apie išlaidas, kurios nebuvo apdorotos per mokėjimų sistemą. Tai yra tik vienas iš duomenų šaltinių didžiajai knygai, o ne jos pakaitalas.
Kiek nekeičiamas yra „nekeičiamas“ praktikoje?
Įrašų redaguoti negalima. Taisymai yra nauji įrašai, kurie nukreipia į originalųjį (stornavimas). Tai yra architektūrinis sprendimas, o ne technologinis. Bet kuri kompetentinga didžioji knyga tai užtikrins. Priežastis, kodėl tai svarbu, yra ta, kad būtent praktika „mes tai pataisėme, kad atitiktų banką“ daro apskaitos knygas nepatikimomis.
Ką daryti prekyvietėms, esančioms ne ES?
Dvejybinio įrašo mechanika yra universali. Mokesčių logika – ne. Didžiosios knygos API, pritaikytas ES PVM, puikiai susitvarkys su operacijomis, kuriose dominuoja ES, ir gali palaikyti ne ES operacijas, tačiau jei jūsų pagrindinė rinka yra JAV pardavimo mokestis ar Lotynų Amerikos el. sąskaitų faktūrų režimai, prieš įsipareigodami, patikrinkite konkretų atitikties palaikymą.