Dvigubo įrašo Didžiosios knygos API prekyviečių buhalterijai

Dauguma prekyviečių (marketplaces) supranta turinčios apskaitos problemą tuo pačiu būdu: įmonėje pradeda dirbti finansininkas, atidaro išmokų lentelę ir paklausia, kas iš tikrųjų registruoja įsipareigojimą pardavėjams tuo laikotarpiu nuo pirkėjo apmokėjimo iki lėšų išėjimo iš platformos sąskaitos. Inžinieriai parodo į transactions lentelę. Finansininkas primena, kad įvykių lentelė nėra apskaitos knyga. Šią spragą tarp įvykių duomenų ir realios apskaitos padeda panaikinti dvigubo įrašo Didžiosios knygos (ledger) API.

Tai techninis klausimas, turintis ir teisinį svorį. Prekyvietės laiko svetimus pinigus, skaičiuoja PVM įvairiose jurisdikcijose ir išrašo sąskaitas faktūras pardavėjų vardu. Daryti tai naudojant pačių sukurtoje aplikacijoje esančią operacijų lentelę veikia tol, kol auditorius, mokesčių institucija arba stambus pirkėjas paprašo įrodymų.

Kas iš tikrųjų yra dvigubo įrašo Didžiosios knygos API

Dvigubo įrašo Didžiosios knygos API yra programuojamas apskaitos variklis, pasiekiamas per HTTP. Kiekvienas jūsų platformos užfiksuotas finansinis įvykis įrašomas kaip subalansuotas žurnalo įrašas: bent vienas debetas ir vienas kreditas, kurių bendros sumos sutampa, įtraukti į sąskaitų plane (chart of accounts) nurodytas sąskaitas. API užtikrina šį balansą įrašymo metu ir saugo įrašus taip, kad vėliau jų negalima būtų nepastebimai pakeisti.

„Dvigubo įrašo“ dalis remiasi keturių šimtų senumo apskaitos taisykle, pagal kurią kiekviena operacija paveikia bent dvi sąskaitas. „API“ dalis reiškia, kad užklausas siunčia jūsų produktas, o ne žmogus buhalteris. „Nekintamumo“ (immutable) dalis reiškia, kad korekcijos atliekamos per anuliuojančius įrašus, o ne keičiant istoriją. Kartu šios trys savybės paverčia sukurtą apskaitą tinkama auditui, o ne tik tvarkinga.

Naudingas darbinis apibrėžimas:

Dvigubo įrašo Didžiosios knygos API priima finansinius įvykius iš jūsų programėlės, kiekvieną jų paverčia subalansuotu žurnalo įrašu pagal nustatytą sąskaitų planą, nekintamai saugo šiuos įrašus ir pateikia gautą Didžiąją knygą, bandomąjį balansą (trial balance) bei finansines ataskaitas per nuspėjamus galinius punktus (endpoints).

„Nordlet“ sukurta remiantis būtent šia idėja: tikra apskaita per API, kurioje Didžioji knyga, PVM logika, sąskaitų faktūrų išrašymas ir suderinimas yra pasiekiami iš tų pačių galinių punktų, su kuriais jūsų produktas jau sąveikauja.

Kodėl to konkrečiai reikia prekyvietėms

Vienam pardavėjui skirtas SaaS dažnai gali apsieiti su duomenų sinchronizavimu į bendrą apskaitos įrankį kartą per dieną. Prekyvietės negali, ir tam yra trys priežastys.

Pirma, jos stovi pinigų srauto viduryje. Pirkėjas sumoka platformai, platforma laiko lėšas, o tada sumoka pardavėjams atskaičiusi mokesčius. Kiekvienas iš šių judesių yra atskiras apskaitos įvykis, veikiantis skirtingas sąskaitas: grynuosius pinigus, mokėtinas sumas pardavėjams, platformos pajamas, mokėtiną PVM, grąžinimų rezervus. payments lentelė su status stulpeliu to neužfiksuoja.

Antra, jos veikia įvairiose mokesčių jurisdikcijose. ES prekyvietė, kurios pardavėjai yra Lietuvoje, Vokietijoje ir Lenkijoje, o pirkėjai iš visos bendrijos, privalo taikyti teisingą PVM tvarką kiekvienai operacijai, tikrinti pardavėjų PVM mokėtojo kodus per VIES ir teikti ataskaitas, tenkinančias kiekvienos vietos institucijos reikalavimus. Tai teisingai įgyvendinti programinės įrangos kode, o vėliau sulyginti su atskira apskaitos sistema, yra vieta, kur dauguma prekyviečių nepastebimai susiduria su problemomis.

Trečia, mastas yra per didelis rankinei buhalterijai. Platforma, atliekanti dešimt tūkstančių užsakymų per mėnesį, sugeneruoja dešimtis tūkstančių žurnalo įrašų. Tai turi būti automatizuota nuo pradžios iki pabaigos, antraip finansų komanda taps augimo stabdžiu.

Kaip veikia API, žingsnis po žingsnio

Mechanika yra mažiau egzotiška, nei skamba. Tipinis prekyvietės užsakymo srautas atrodo taip:

1. Jūsų platforma sugeneruoja finansinį įvykį. Pirkėjas baigia pirkimą. Jūsų programėlės galinė dalis (backend) iškviečia Didžiosios knygos API perduodama tokius duomenis kaip: užsakymo ID, pirkėjas, pardavėjas, bendra suma, PVM tarifas, platformos komisinis mokestis, valiuta ir operacijos vienetinio pasiekiamumo (idempotency) raktas.

2. Didžioji knyga sugeneruoja žurnalo įrašą. API paverčia šį įvykį debetais ir kreditais. Tiesioginio prekyvietės pardavimo atveju tai gali reikšti pinigų kelyje (cash-in-transit) sąskaitos debetavimą, mokėtinų sumų pardavėjui sąskaitos kreditavimą už grynąją sumą, platformos pajamų sąskaitos kreditavimą už komisinį mokestį ir mokėtiną PVM sąskaitos kreditavimą už mokesčio dalį. Viskas subalansuota. Viskas įrašyta atmeniškai.

3. Įrašas įrašomas nekintamai. Įrašas, kai jis paskelbiamas, gauna identifikatorių bei laiko žymą ir negali būti keičiamas. Jei kažkas negerai, paskelbiate anuliuojantį įrašą ir koreguotą naują. Auditui reikalingas sekimas būtent tuo ir remiasi.

4. Ataskaitos atsinaujina realiuoju laiku. Bandomasis balansas, mokėtinų sumų pardavėjams likučiai, PVM suvestinės ir pelno (nuostolio) ataskaita naują įrašą atspindi nedelsiant. Nėra jokių naktinių užduočių, eksportavimo ar suderinimo langų, kuriuose skaičiai „nusistovėtų“.

5. „Webhook“ pranešimai informuoja jūsų sistemą. Tokie įvykiai kaip sale_invoice.paid arba bank_transaction.matched išsiunčiami į jūsų galinius punktus, todėl jūsų produktas gali reaguoti be nuolatinio užklausų siuntimo (polling). Kartu su vienetinio pasiekiamumo raktais tai reiškia, kad pakartotiniai bandymai yra saugūs, o pasitaikius tinklo trikdžiams dublikatai neprasprūsta.

Svarbus architektūrinis sprendimas: Didžioji knyga yra tiesos šaltinis apie tai, kas nutiko finasine prasme. Jūsų programėlės duomenų bazė yra tiesos šaltinis apie produkto būseną. Šios dvi sistemos susiderina todėl, kad Didžioji knyga rašoma iš programėlės įvykių, o ne atvirkščiai.

Sąskaitų planas yra vieta, kur atliekamas visas projektavimo darbas

Didžioji dalis intelektinio darbo kuriant Didžiąją knygą prekyvietei tenka sąskaitų planui. Tai sąrašas pavadintų talpyklų, į kurias patenka debetai ir kreditai: grynųjų pinigų sąskaitos kiekviename banke, mokėtinų sumų pardavėjams sąskaitos (dažnai po vieną pardavėjui arba viena bendra su subliogeriais), platformos pajamos pagal kategorijas, mokėtinas PVM pagal šalis, grąžinimų rezervai, sukčiavimo (chargeback) rezervai ir t. t.

Keletas modelių, kurie kartojasi įvairiose prekyvietėse:

• Pardavėjų lėšos yra įsipareigojimas, o ne pajamos. Pinigai, kuriuos laikote pardavėjų vardu, yra mokėtina suma. Laikyti juos pajamomis, o išmokėjimą vėliau priskirti sąnaudoms – klasikinė klaida, pastebima patikrinimų metu.
• PVM yra atskiras įsipareigojimas kiekvienai šaliai. Jei veikiate keliose ES jurisdikcijose, norite turėti atskiras mokėtinojo PVM sąskaitas pagal šalis, kad ataskaitos būtų lengvai suderinamos.
• Mokesčiai turi būti apskaitomi tuo metu, kai jie uždirbami, o ne tada, kai jie išmokami. Kaupimo principo apskaita čia nėra pasirinkimas.
• Grąžinimams, sukčiavimo atvejams ir ginčams reikia atskirų sąskaitų, kad pelno (nuostolio) ataskaita atspindėtų realybę, o ne teigiamų ir neigiamų pardavimų sumaištį.

Gera Didžiosios knygos API leidžia šią struktūrą apibrėžti vieną kartą ir po to užtikrintai į ją rašyti įrašus, vietoj to, kad iš naujo išrastumėte apskaitos logiką savo pirkimo srauto kode.

Nekintamumas, periodų užrakinimas ir kodėl tai rūpi auditoriams

Nekintamumas skamba kaip duomenų bazės detalė. Iš tikrųjų tai yra skirtumas tarp knygų, kurias auditorius patvirtins, ir tų, kurių nepatvirtins.

Jei prekyvietė gali slapta redaguoti praėjusio ketvirčio įrašus, praėjusio ketvirčio skaičiai apskaitos prasme yra nežinomi. Nekintama Didžioji knyga užtikrina taisyklę, kad istorija yra istorija. Korekcijos matomos kaip korekcijos. Periodo užrakinimas pratęsia šią taisyklę: kai mėnuo uždaromas, jokie nauji įrašai ar pakeitimai negali patekti į tą laikotarpį be aiškaus atidarymo veiksmo, kuris pats yra registruojamas.

Platformoms, kurios ateityje pritrauks lėšų, bus parduodamos arba susidurs su mokesčių auditu, tai nėra „malonus priedas“. Tai dalykas, kuris apskaitą padeda pagrįsti. „Nordlet“ Didžioji knyga sukurta remiantis tuo pagal nutylėjimą, o nekintama dvigubo įrašo struktūra ir periodų užrakinimas yra įmontuoti, o ne pritaikyti papildomai.

ES PVM: dalis, kuri eikvoja inžinierių laiką

PVM yra sritis, kurioje dauguma prekyvietės apskaitos projektų viršija biudžetus. Taisyklės nėra tiesiog „pritaikyti procentą“. Jos priklauso nuo to, kur yra pirkėjas, kur yra pardavėjas, kas parduodama, ar pardavėjas yra PVM mokėtojas, ar prekyvietė laikoma prievolių vykdytoja pagal 2021 m. e. prekybos taisykles ir kuris ataskaitų teikimo režimas taikomas vietoje.

Rimta ES skirta Didžiosios knygos API tvarko bent šiuos dalykus:

• VIES patikrą pardavėjo ir pirkėjo PVM mokėtojo kodams, idealiu atveju rezultatus išsaugant talpykloje (cache) ir priskiriant operacijai.
• PVM tarifo logiką pagal šalis, įskaitant lengvatinius tarifus ir išimtis.
• i.SAF registro generavimą Lietuvos deklaracijoms ir lygiaverčius struktūrizuotus formatus kitoms valstybėms narėms, jei to reikalaujama.
• Peppol BIS 3.0 e. sąskaitų faktūrų išrašymą jurisdikcijoms, pereinančioms prie privalomo elektroninio sąskaitų faktūrų išrašymo.
• OSS/IOSS valdymą tarpvalst B2C pardavimams.

Atlikti tai programėlės kode, kiekvienai šaliai atskirai, yra pilnos inžinierių komandos vertas darbas, kuris niekada nesibaigia, nes taisyklės nuolat keičiasi. Šią naštą perkelti į Didžiosios knygos lygmenį yra pragmatiškas sprendimas.

Suderinimas yra vieta, kur pasimato laiko taupymas

Kai Didžioji knyga tampa tiesos šaltiniu, banko suderinimas nustoja būti kas mėnesį vykstančia kančia. Banko išrašai gaunami, Didžioji knyga jau žino, kas juose turėtų būti, ir suderinimas dažniausiai vyksta automatiškai.

Realistiškas šio proceso variantas nėra „nulinis rankinis darbas“. Tai „išimtys pačios iškyla į paviršių“. Vieno paspaudimo suderinimo srautas devyniasdešimčiai procentų sklandžiai sutampančių operacijų ir dešimties procentų eilė, reikalaujanti žmogiškojo sprendimo, yra maždaug tai, ką teikia gerai suprojektuota suderinimo API. Išmanus mokėjimų sulyginimas apdoroja dalinius mokėjimus, permokas ir mokėjimus, apimančius kelias sąskaitas faktūras, be būtinybės žmogui rašyti taisykles kiekvienam atvejui.

SEPA eksportas (pain.001 formatas) tiekėjų ir pardavėjų išmokoms uždaro ratą pinigų išėjimo pusėje. Jūs patvirtinate išmokas savo produkte, Didžioji knyga sugeneruoja SEPA failą, jūsų bankas jį apdoroja, o gautas judėjimas automatiškai suderinamas atgal.

Kurti patiems, pirkti ar įdەti (Build vs. Buy vs. Embed)

Prekyviečių komandos dažniausiai svarsto tris kelius. Štai kaip jie lyginami pagal svarbius kriterijus:

Požiūris	Laikas iki gamybinės aplinkos	Pasirengimas auditui	ES PVM valdymas	Telpa į jūsų produktą
Kurti savo Didžiąją knygą	Nuo 12 iki 24+ mėnesių	Priklauso tik nuo jūsų komandos	Kuriate patys, kiekvienai šaliai	Taip
Sinchronizuoti su Xero / QuickBooks	Savaitės	Geras apskaitos pusei, silpnas specifiniams prekyvietės srautams	Dalinis, reikia priedų	Ne, gyvena atskirame įrankyje
Įdėti Didžiosios knygos API (pvz., Nordlet)	Savaitės	Įmontuota per nekintamą knygą ir periodų užrakinimą	Įmontuota ES, įskaitant VIES ir i.SAF	Taip, per API ir SDK

Savo sistemos kūrimas yra pateisinamas, jei apskaita yra jūsų produktas. Visiems kitiems matematika retai kada pasiteisina. Sinchronizavimas su tradiciniu apskaitos įrankiu tinka vienos įmonės verslams, tačiau stringa susidūrus su prekyvietės srautais: padalintais mokėjimais, pardavėjų subliogeriais, PVM pagal šalis ir platformos kaip prievolių vykdytojos scenarijais, kurie netelpa į įrankius, sukurtus vienos įmonės buhalterijai.

Dauguma šiuolaikinių platformų renkasi API pagrindu sukurto Didžiosios knygos įterpimą. Apskaita gyvena jūsų produkto patirtyje, pardavėjai mato savo finansus jūsų vartotojo sąsajoje, o sudėtingas atitikties reikalavimų valdymas atliekamas infrastruktūros lygmenyje.

Į ką atsižvelgti vertinant Didžiosios knygos API

Trumpas kontrolinis sąrašas, kurį verta turėti po ranka kalbant su teikėjais:

• Nekintamas dvigubo įrašo saugojimas su anuliuojančio įrašo korekcijomis, o ne redaguojamomis eilutėmis.
• Periodų užrakinimas su registruotais atidarymo veiksmais.
• Vienetinio pasiekiamumo raktai (idempotency keys) kiekviename įrašymo galiniame punkte.
• „Webhook“ pranešimai įvykiams, į kuriuos jūsų produktas turi reaguoti, o ne tik užklausų API.
• Tipizuoti SDK kalbomis, kurias jūsų komanda iš tikrųjų naudoja.
• PVM logika pagal šalis, įskaitant VIES, i.SAF ar lygiaverčius formatus bei OSS/IOSS.
• Kelių įmonių palaikymas, jei valdote kelias įmones arba planuojate tai daryti.
• Rolėmis pagrįsta prieiga, pakankamai detali kūrėjams, buhalteriams ir peržiūrai atskirti.
• Ataskaitų eksportas XLSX, PDF ir JSON formatais su „webhook“ pranešimais, kai didelės ataskaitos paruoštos.
• Smėlio dėžė (sandbox), atspindinti gamybinės aplinkos elgseną, o ne sumažintos apimties demonstracinė versija.

Jei tiekėjas techninio pokalbio metu negali pademonstruoti pirmųjų trijų punktų, visa kita neturi reikšmės.

Ką daryčiau pirmiausia

Jei prekyvietė šį darbą pradeda nuo nulio, seka, taupanti daugiausiai nervų:

1. Ant lentos nupieškite tikruosius pinigų srautus prieš rašydami bet kokį kodą. Kas kam skolingą, kurią akimirką, kokia valiuta, su kokiu PVM apmokestinimu.
2. Iš šio žemėlapio sudarykite sąskaitų planą. Mokėtinos sumos pardavėjams, platformos pajamos, mokėtinas PVM pagal šalis, rezervai. Prieš paleidžiant į gamybinę aplinką, paprašykite buhalterio jį peržiūrėti.
3. Pasirinkite Didžiosios knygos lygmenį. Kurkite, sinchronizuokite arba įterpkite. Būkite atviri sau, ką jūsų komanda iš tikrųjų gali sukurti ir palaikyti.
4. Įgyvendinkite vieną srautą nuo pradžios iki pabaigos: užsakymas iki sąskaitos faktūros, išmokos ir suderinimo. Įrodykite, kad jis subalansuotas. Tada plėskitės.
5. Įjunkite periodų užrakinimą vos tik pirmasis mėnuo užsidaro sklandžiai. Ši drausmė kaupia naudą.

Komandos, kurios tai atlieka teisingai, Didžiąją knygą laiko pagrindine infrastruktūra, o ne ataskaitų priedu. Tai ir yra pokytis, dėl kurio pokalbis su auditoriumi, investuotoju ar mokesčių inspekcija tampa trumpas, o ne varginantis.

D.U.K.

Ar dvigubo įrašo Didžiosios knygos API yra tas pats, kas apskaitos integracija?

Ne. Integracija sinchronizuoja duomenis iš jūsų produkto į išorinį apskaitos įrankį, paprastai su vėlavimu. Didžiosios knygos API yra pati apskaitos sistema, į kurią rašoma tiesiogiai ir realiuoju laiku. Šis skirtumas svarbus, nes integracijos praranda tikslumą kraštutiniais atvejais: daliniai mokėjimai, kelios valiutos, prekyvietės padalinimai. Didžiosios knygos API visa tai registruoja natūraliai.

Ar negalime tiesiog naudoti „Stripe“ arba „Adyen“ ataskaitų?

Mokėjimų apdorojimo ataskaitos parodo, kas judėjo per apdorojimo sistemą. Jos nėra dvigubo įrašo knygos. Jos nežino apie jūsų mokėtinas sumas pardavėjams, kurios dar nebuvo išmokėtos, jūsų PVM įsipareigojimus skirtingose šalyse arba išlaidas, nesusijusias su mokėjimų apdorojimu. Jos yra tik vienas iš duomenų šaltinių Didžiajai knygai, o ne jos pakaitalas.

Kiek nekintamas yra nekintamumas praktikoje?

Įrašai negali būti redaguojami. Korekcijos yra nauji įrašai, nurodantys į originalą. Tai projektavimo sprendimas, o ne technologinis. Bet kuri kompetentinga Didžioji knyga to reikalaus. Priežastis, kodėl tai svarbu, yra ta, kad „mes jį pakoregavome, kad atitiktų banką“ yra būtent tas modelis, dėl kurio apskaita tampa nepatikima.

O kaip ne ES prekyvietės?

Dvigubo įrašo mechanika yra universali. Mokesčių logika – ne. ES PVM pritaikyta Didžiosios knygos API puikiai susidoros su operacijomis ES viduje ir gali palaikyti ne ES operacijas, tačiau jei jūsų pagrindinė rinka yra JAV pardavimo mokestis arba Lotynų Amerikos e. sąskaitų faktūrų išrašymo režimai, prieš įsipareigodami patikrinkite specifinį atitikties palaikymą.

Kiek laiko iš tikrųjų užtrunka įgyvendinimas?

Prekyvietei su švariu įvykių modeliu įterpti Didžiosios knygos API iki vieno pilno srauto paleidimo nuo pradžios iki pabaigos paprastai užtrunka kelias savaites inžinerinio darbo. Pilna migracija iš senosios sistemos, įskaitant istorinius duomenis, užtrunka ilgiau. Kintamasis beveik visada yra esamų duomenų būklė, o ne pati API.