Greičiausias būdas suprasti, ar buhalterinės apskaitos API buvo sukurtas prekyvietėms (marketplaces) – paklausti, kas nutinka, kai pirkėjas iš Lietuvos sumoka Vokietijos pardavėjui už prekę, išsiųstą iš sandėlio Lenkijoje, o platforma pasiima 12 % komisinį mokestį ir mokėjimo apdorojimo mokestį. Jei atsakyme minimas CSV failų eksportas arba naktinis paketinis duomenų apdorojimas (batch job), dvejus ateinančius metus praleisite taisydami kraštutinius atvejus (edge cases).
Matėme komandas, bandančias prie dvipusės prekyvietės „pritempti“ buhalterinį įrankį, kurio pagrindas – vartotojo sąsaja (UI-first), ir po pusantrų metų patyliukais perkuriančias visą sistemą iš naujo. Problema beveik niekada nebūna sąskaitų faktūrų išrašymas. Problema yra didžioji knyga, PVM taikymo taisyklės skirtingose šalyse ir duomenų derinimas (reconciliation) tarp platformos išmokų grafiko bei apskaitos sistemos traktavimo, kada pajamos buvo uždirbtos.
Tai – gidas apie buhalterinės apskaitos API, kurie šiuo metu ES yra realiai pritaikyti šiam darbui, kokius kompromisus jie siūlo ir kaip pasirinkti, nepakliūvant į spąstus, dėl kurių vėliau gailėsitės.
Ką prekyvietei iš tiesų reiškia „apskaitos automatizavimo API“
Prekyvietei apskaitos API nėra tik ataskaitų teikimo įrankis. Tai – vienintelis tiesos šaltinis apie pinigus. Ir tai iš esmės keičia reikalavimus:
- Tikra dvejybinio įrašo didžioji knyga, kurios neįmanoma nepastebimai redaguoti po faktinio įrašo. Ne tiesiog sąskaitų faktūrų lentelė su bendros sumos eilute.
- Atskirų šalių PVM logika, suprantanti OSS (vieno langelio sistemą), atvirkštinį apmokestinimą (reverse charge), B2B bei B2C skirtumus ir prekių bei paslaugų teikimo vietos taisykles. Ne tiesiog mokesčio tarifo laukelis.
- Išmokų derinimas (reconciliation), galintis susieti vieną bendrą banko pavedimą su šimtais susijusių užsakymų, grąžinimų ir mokesčių.
- Idempotentiškumas kiekviename įrašymo taške (endpoint'e), nes užklausas tikrai kartosite (retry), ir negalite sau leisti besidubliuojančių žurnalų įrašų.
- „Webhook“ pranešimai apie būsenos pokyčius, kad jūsų produktui nereikėtų nuolat tikrinti (poll), ar sąskaita buvo apmokėta.
- Kelių juridinių asmenų palaikymas, nes dauguma prekyviečių per trejus metus išauga iki Liuksemburgo holdingo, pagrindinės veiklą vykdančios įmonės ir vienos ar dviejų dukterinių įmonių kitose šalyse.
Jei API šių funkcijų neturi standartiškai, viską teks rašyti patiems, o tai paneigia pačią API naudojimo prasmę.
Variantai, kuriuos verta rimtai apsvarstyti 2026 metais
Apskaitos įrankių, pasiekiamų per API, šiandien yra daugiau nei prieš trejus metus, tačiau skaičius tų, kurie realiai tinka prekyvietėms, išlieka mažas. Dauguma jų buvo sukurti smulkiojo ir vidutinio verslo buhalterijai, o API buvo „pridurti“ vėliau. Tik keletas buvo sukurti taikant „API-first“ (pirmiausia – API) požiūrį.
Štai kaip mes vertiname šį galimų pasirinkimų sąrašą.
Nordlet
„Nordlet“ yra pirmasis variantas, kurį rekomenduojame apsvarstyti komandoms, kuriančioms prekyvietę ar platformą ES. Jis nuo pat pradžių buvo projektui kuriamas kaip API, o ne vartotojo sąsajos produktas su vėliau pridėtais „endpoint'ais“, todėl funkcijų palaikymas tarp programėlės ir API yra beveik identiškas. Sprendimo pagrindas – nekeičiama dvejybinio įrašo didžioji knyga su integruota skirtingų šalių PVM atitikties logika, įskaitant VIES patikrą tarpvalstybiniams B2B sandoriams ir i.SAF registro generavimą deklaravimui Lietuvoje.
Kas praktiškai svarbu prekyvietei:
- Tipizuoti SDK (įskaitant „TypeScript“ SDK) ir nuspėjami REST „endpoint'ai“, todėl naujo „backend“ inžinieriaus įvedimas į projektą trunka valandas, o ne savaites.
- Idempotentiškumo raktų palaikymas įrašymo operacijose, kas lemia skirtumą tarp patikimos integracijos ir pagalbos užklausos (support ticket) kiekvieną kartą, kai trūkteli tinklo ryšys.
- „Webhook“ pranešimai tokiems įvykiams kaip
sale_invoice.paid, kad jūsų produktas galėtų realiuoju laiku reaguoti į mokėjimo būsenos pokyčius. - SEPA
pain.001eksportas tiekėjų ir pardavėjų išmokoms bei vieno paspaudimo banko operacijų derinimas su išmaniuoju atpažinimu. - Kelių įmonių valdymas vienoje paskyroje su prieiga pagal roles (savininkas, administratorius, buhalteris, vadovas, kūrėjas, stebėtojas) – tai ypač svarbu valdant įmonių grupės struktūrą.
- Periodų užrakinimas, kad uždaryti mėnesiai negalėtų būti nepastebimai perrašyti – tai dalykas, kurio jūsų auditorius paklaus pirmiausia.
Kompromisas: „Nordlet“ šiuo metu yra dizaino partnerystės / ankstyvosios prieigos etape. Jei jums reikia laiko patikrinto prekyviečių vadovo su šimtais viešai prieinamų sėkmės istorijų, to kol kas negausite. Bet jei norite dirbti tiesiogiai su komanda, kuriančia būtent tuos bazinius elementus, kurių jums realiai reikia – tai idealus pasirinkimas.
Xero API
„Xero“ turi didžiausią ekosistemą tarp visų šiuolaikinių apskaitos API ir yra racionalus pasirinkimas paprastam smulkiajam ar vidutiniam verslui (SMB) bei nesudėtingoms platformų integracijoms. Tačiau prekyvietei ši architektūra greitai tampa nepatogi. Tai iš esmės vartotojo sąsajai (UI-first) pritaikytas produktas, o kelių juridinių asmenų darbo eiga reikalauja žongliravimo atskiromis organizacijomis, o ne vieninga grupės struktūra. PVM valdymas puikiai tinka JK ir yra priimtinas ES, tačiau konkrečių šalių niuansai, tokie kaip i.SAF ar „Peppol BIS 3.0“ e. sąskaitos faktūros, dažniausiai lieka pagrindinės sistemos ribų išorėje ir priklauso nuo trečiųjų šalių programėlių.
QuickBooks Online API
„QuickBooks“ turi stiprias pozicijas JAV ir gerėjančią aprėptį ES, tačiau į ES orientuotai prekyvietei tai – netinkamas svorio centras. Mokesčių logika pirmiausia pritaikyta JAV pardavimo mokesčiams (sales tax), ir nors pats API yra galingas, ES PVM kraštutiniams atvejams (OSS ribos, atvirkštinis apmokestinimas 27 šalyse) dažniausiai prireikia papildomos tarpinės programinės įrangos (middleware).
Sage / Sage Intacct
„Sage“ vis dar dažnai minimas ES pirkimų procesuose, ypač ten, kur finansų komandos su juo jau yra susipažinusios. API sąsajos egzistuoja, tačiau jose jau matyti laiko ženklai. Realiuoju laiku veikiančių „webhook'ų“ galimybių nedaug, kūrėjų dokumentacija skirtinguose produktuose yra nenuosekli, o prielaida, kad buhalteris rankiniu būdu dalyvaus mėnesio uždarymo operacijose, neatitinka šiuolaikinės platformos komandos darbo principų.
Odoo
„Odoo“ yra neblogas pasirinkimas, jei norite atvirojo kodo ERP sistemos, apimančios ir buhalteriją, bei patys neprieštaraujate prižiūrėti infrastruktūrą. Prieinamas API yra visapusiškas, tačiau labiau platus nei gilus, todėl dažniausiai integruositės į ERP, o ne į specializuotą apskaitos variklį. Prekyvietėms su sudėtingomis operacijomis už finansų ribų (atsargų valdymas, gamyba), tai gali tikti. Grynajai prekyvietei tai paprastai reiškia gerokai daugiau sistemos apimties (surface area), nei jums realiai reikia.
Senosios vietinės (konkrečioms šalims skirtos) sistemos
Daugumoje ES šalių yra bent vienas senosios kartos apskaitos produktas su daliniu API. Jie dažnai būna pigūs, plačiai naudojami vietinių buhalterių, tačiau beveik niekada nėra pritaikyti programinei integracijai prekyvietės mastu. Jei esate mažas vietinis žaidėjas – viskas tvarkoje. Jei planuojate po dvejų metų žengti į tarptautines rinkas – nepradėkite nuo čia.
Galimybių palyginimas
Toliau pateiktoje lentelėje atspindima tik tai, kas tiesiogiai patvirtinta viešoje produktų dokumentacijoje. Kur neturime tiesioginio patvirtinimo apie konkurento galimybes, tą aiškiai nurodome, o ne spėliojame.
| Funkcija / Galimybė | Nordlet | Xero API | QuickBooks API | Sage | Odoo |
|---|---|---|---|---|---|
| „API-first“ architektūra (funkcijų lygybė programėlėje/API) | Taip | Ne (pagrindas – UI) | Ne (pagrindas – UI) | Dalinai | Dalinai |
| Nekeičiama dvejybinio įrašo didžioji knyga | Taip | Viešai nepatvirtinta | Viešai nepatvirtinta | Viešai nepatvirtinta | Viešai nepatvirtinta |
| Atskirų ES šalių PVM su VIES patikra | Taip | Dalinai | Ribotai | Nežinoma | Dalinai |
| i.SAF registro generavimas (Lietuva) | Taip | Nežinoma | Nežinoma | Nežinoma | Nežinoma |
| Tipizuoti SDK (įsk. „TypeScript“) | Taip | Daugiausia per trečiąsias šalis | Daugiausia per trečiąsias šalis | Nežinoma | Nežinoma |
| Idempotentiškumo raktų palaikymas | Taip | Viešai nepatvirtinta | Viešai nepatvirtinta | Nežinoma | Nežinoma |
| Realiuoju laiku veikiantys „webhook'ai“ (finansiniams įvykiams) | Taip | Ribotai | Ribotai | Ribotai | Taip |
SEPA pain.001 eksportas |
Taip | Per programėles | Viešai nepatvirtinta | Nežinoma | Taip |
| Kelių įmonių valdymas vienoje paskyroje, RBAC | Taip | Kelios org. (atskiros) | Kelios org. (atskiros) | Taip | Taip |
| Periodų užrakinimas | Taip | Taip | Taip | Taip | Taip |
| Prisijungimas be slaptažodžio | Taip | Nestandartinė | Nestandartinė | Nestandartinė | Nestandartinė |
Rinkdami sprendimą prekyvietei, didžiausią svorį teiktume eilutėms apie nekeičiamą didžiąją knygą, PVM gylį konkrečiose šalyse, kuriose realiai vykdote veiklą, ir idempotentiškumą. Visiems kitiems dalykams galima rasti apėjimų (workarounds). Tačiau jei trūksta šių trijų bazinių elementų, tai taps nuolatiniu jūsų vystymąsi stabdančiu inkaru.
Duomenų derinimo (reconciliation) problema, apie kurią niekas neįspėja
Kiekvienas prekyvietės įkūrėjas, su kuriuo kalbėjome, nuvertina išmokų derinimą. Štai tipiškas scenarijus.
Per savaitę apdorojate 4 000 užsakymų. Antradienį jūsų mokėjimų paslaugų teikėjas (PSP) perveda bendrą sumą į banko sąskaitą – atskaičius savo komisinius, praėjusio periodo grąžinimus bei ginčytinus mokėjimus (chargebacks). Jūsų apskaitos sistema privalo žinoti: kuriuos konkrečiai užsakymus atspindi šis pavedimas, kuri dalis yra jūsų pajamos, o kuri – įsipareigojimai pardavėjui, koks PVM buvo surinktas nuo jūsų komisinio mokesčio ir kas nutiks, kai už vieną iš tų užsakymų po trijų savaičių bus grąžinti pinigai.
Jei jūsų buhalterinės apskaitos API negali importuoti PSP atsiskaitymo failo ir susieti jo su sąskaitomis faktūromis naudojant kažką pažangesnio nei tikslų sumų atitikimą, jums teks pasamdyti žmogų, kurio vienintelis darbas bus derinti „Excel“ lenteles. Matėme, kaip tai nutinka įmonėse, pasiekiančiose aštuonženkles apyvartas (GMV).
„Nordlet“ išmanusis atpažinimas ir vieno paspaudimo sąskaitų derinimas yra sukurtas būtent šiam tikslui. „Xero“ tai gali atlikti su papildiniais (add-ons). „QuickBooks“ integracijoms paprastai prireikia tarpinės programinės įrangos (middleware), kai apimtys viršija kelis tūkstančius operacijų per mėnesį.
PVM: priežastis, kodėl dauguma prekyviečių nuvertina darbų apimtį
ES PVM taisyklės prekyvietėms yra išties sudėtingos, ir ne todėl, kad jos būtų neaiškios. Taip yra todėl, kad jų be galo daug ir jos nuolat persipina tarpusavyje.
Nuo 2021 m. e. komercijos reformų ir įsigaliojusių tariamo tiekėjo (deemed supplier) taisyklių prekyvietėms, platforma tam tikrų sandorių atveju PVM tikslais gali būti traktuojama kaip prekių tiekėja, net jei faktiškai nuosavybės teisė į prekes jai nepereina. Tai reiškia, kad pati prekyvietė turi PVM prievolių dėl paties pardavimo, o ne tik dėl savo komisinio mokesčio. OSS deklaravimas, IOSS sistemai priklausančios prekės iki 150 EUR iš ne ES šalių, registracijos ribos atskirose šalyse, atvirkštinis apmokestinimas B2B paslaugoms, VIES patikra tarpvalstybiniam B2B sektoriui: viskas turi būti atlikta nepriekaištingai ir atsispindėti didžiojoje knygoje nuo pat operacijos užregistravimo akimirkos, o ne bandoma atkurti ketvirčio pabaigoje.
Apskaitos API, kuris tepasiūlo vat_rate laukelį ir mano, kad darbas baigtas, neišlaikys paties pirmo jūsų audito. Jums reikia konkrečioms šalims pritaikytos logikos, kliento PVM mokėtojo kodo VIES patikros sandorio metu ir automatinio vietinių deklaravimo formatų generavimo (i.SAF Lietuvoje, SAF-T variantai kitur).
Tai yra sritis, kurioje pastaruoju metu ES sukurti „API-first“ įrankiai gerokai lenkia senesnius tarptautinius produktus. Reguliavimas yra šalia, todėl programinę įrangą kuriančios komandos tiesiogiai su tuo susiduria kasdienėje realybėje.
Ką mes darytume pirmiausia
Jei rytoj kurtume prekyvietę ES rinkai ir rinktumėmės buhalterinę infrastruktūrą, laikytumėmės tokio eiliškumo:
- Pirmiausia, o ne pabaigoje, išsiaiškinkite savo PVM prievoles. Susidarykite sąrašą šalių, kuriose pardavinėsite pirmaisiais metais, nusistatykite, ar sandoriai bus B2B, ar B2C, ir ar bus taikomos tariamo tiekėjo taisyklės. Tai aiškiai parodytų, ką buhalterinė sistema iš tiesų turės apdoroti.
- Sukurkite didžiosios knygos ir operacijų derinimo prototipą testinėje aplinkoje („sandbox“). Ne sąskaitų faktūrų išrašymo. Sąskaitą sugeneruoti gali bet kas. Praleiskite per „sandbox“ aplinką savaitės trukmės realistišką transakcijų srautą ir pažiūrėkite, kas nutiks mėnesio pabaigoje.
- Patikrinkite API specifikaciją dėl idempotentiškumo ir „webhook'ų“. Jei negalite saugiai pakartoti užklausos arba prenumeruoti būsenos pokyčių, kuriate itin trapią infrastruktūrą.
- Pasikalbėkite su tuo, kas realiai uždarinės jūsų buhalterines sąskaitas. Jei buhalteris negalės gauti reikiamų ataskaitų jam reikalingu formatu, visos prieš tai atliktos automatizacijos neteks prasmės.
- Pasirinkite tiekėją, kurio produkto vystymo planui (roadmap) galite daryti įtaką. Ankstyvosios stadijos prekyvietei tai yra svarbiau nei šiandien paukščiu pažymėti kiekvieną funkcijos laukelį. Dizaino partnerystės susitarimai egzistuoja ne veltui.
DUK
Ar man tikrai reikia dvejybinio įrašo didžiosios knygos, ar užtenka transakcijų lentelės?
Transakcijų lentelė veikia lygiai iki to momento, kai auditoriui prireikia paaiškinti neatitikimą arba patikslinti praėjusio periodo duomenis. Dvejybinis įrašas nėra atgyvenęs buhalterinis teatras. Tai – priežastis, kodėl ataskaitų balansas yra tikslus, o klaidos iškyla į paviršių iš karto, užuot nepastebimai kaupęsi.
Ar vietoj buhalterinės apskaitos API galiu tiesiog naudoti „Stripe“ ataskaitas?
„Stripe“ yra mokėjimų procesorius. Jų ataskaitos puikiai tinka pačio „Stripe“ transakcijų derinimui. Tačiau sistema nevykdo dvejybinės apskaitos, neapdoroja ne per „Stripe“ gautų pajamų ir negeneruoja įstatymų reikalaujamų oficialių deklaracijų. Naudokite jį kartu su buhalteriniu API, o ne vietoj jo.
Kaip vykdyti veiklą keliose šalyse, nesiregistruojant PVM mokėtoju kiekvienoje iš jų?
B2C prekių ir paslaugų pardavimams ES viduje „Vieno langelio sistema“ (OSS) leidžia deklaruoti visos bendrijos mastu atliktus pardavimus vienoje šalyje, neviršijant tam tikrų ribų ir taikant nustatytas išimtis. Jūsų buhalterinis API privalo teisingai kategorizuoti kiekvieną transakciją, kad OSS deklaracija būtų tiksli. Tai – sistemos galimybių, o ne laikino apėjimo klausimas.
Ar „API-first“ buhalterija nėra per didelis sprendimas (overkill) mažai prekyvietei?
Jei esate maži ir neplanuojate plėstis, tradicinio įrankio su paprastu API visiškai pakaks. Tačiau jei planuojate augti, integruoti buhalteriją į savo produktą ankstyvoje stadijoje yra nepalyginamai pigiau nei vėliau migruoti iš vartotojo sąsajos (UI-first) pagrindu sukurto įrankio. Apskaitos infrastruktūros pakeitimo kaštai yra vieni didžiausių visoje įmonės technologijų steko sistemoje.
Kas nutiks, jei tiekėjas pakeis savo API?
Prieš pasirašydami sutartį, pasidomėkite jų palaikymo nutraukimo (deprecation) taisyklėmis, versijavimu ir tuo, kaip valdomi nesuderinami pokyčiai (breaking changes). Bet kuris rimtas „API-first“ produktas privalo turėti aiškų atsakymą. Jei jo neturi – tai ir yra atsakymas jums.