Geriausi buhalterinės apskaitos automatizavimo API ES prekyvietėms (2026)

Greičiausias būdas sužinoti, ar buhalterinės apskaitos API buvo sukurtas prekyvietėms (marketplaces), yra paklausti, kas nutinka, kai pirkėjas iš Lietuvos sumoka pardavėjui Vokietijoje už prekę, siunčiamą iš sandėlio Lenkijoje, o platforma pasiima 12 % komisinį mokestį bei mokėjimo apdorojimo mokestį. Jei atsakymas susijęs su CSV eksportavimu ar naktiniu paketiniu apdorojimu (batch job), ateinančius dvejus metus praleisite taisydami išimtinius atvejus (edge cases).

Matėme, kaip komandos bando pritaikyti į vartotojo sąsają orientuotą (UI-first) apskaitos įrankį dvipusei prekyvietei, o po aštuoniolikos mėnesių tyliai viską perkuria iš naujo. Problema beveik niekada nebūna sąskaitų faktūrų išrašymas. Tikrieji iššūkiai yra didžioji knyga, skirtingas PVM traktavimas kiekvienoje šalyje ir likučių derinimas (reconciliation) tarp platformos išmokėjimų grafiko bei apskaitos sistemos fiksuojamo pajamų uždirbimo momento.

Tai gidas apie apskaitos API, kurie šiuo metu ES yra iš tikrųjų sukurti šiam darbui, apie jų trūkumus ir kaip pasirinkti, kad netaptumėte priklausomi nuo sprendimo, dėl kurio vėliau gailėsitės.

Ką iš tiesų prekyvietei reiškia „apskaitos automatizavimo API“

Prekyvietei apskaitos API nėra tik ataskaitų įrankis. Tai – pagrindinis finansinių duomenų šaltinis (source of truth). Dėl to keičiasi ir reikalavimai:

• Tikra dvejybinio įrašo didžioji knyga, kurios negalima tyliai redaguoti po laiko. O ne sąskaitų faktūrų lentelė su sumų rodiniu.
• Kiekvienai šaliai pritaikyta PVM logika, apimanti OSS, atvirkštinį apmokestinimą (reverse charge), B2B ir B2C bei prekių ar paslaugų teikimo vietos taisykles. O ne tiesiog mokesčio tarifo laukelis.
• Išmokėjimų derinimas, galintis susieti vieną bendrą banko pavedimą su šimtais susijusių užsakymų, grąžinimų ir mokesčių.
• Idempotentiškumas kiekviename įrašymo (write) galiniame taške. Nes jūs kartosite užklausas, ir negalite leisti sau besidubliuojančių žurnalo įrašų.
• „Webhook“ (tinklo gaudyklės) būsenos pasikeitimams, kad jūsų produktui nereikėtų nuolat tikrinti (poll), ar sąskaita faktūra buvo apmokėta.
• Kelių įmonių palaikymas (multi-entity), nes dauguma prekyviečių per trejus metus atsiduria situacijoje, kai turi kontroliuojančiąją įmonę (holdco) Liuksemburge, pagrindinę veiklos įmonę ir vieną ar kelias dukterines įmones kitose šalyse.

Jei API šių funkcijų nepalaiko natūraliai (natively), galiausiai teks jas rašyti patiems, o tai paneigia pačio API prasmę.

Verti dėmesio pasirinkimai 2026 metais

Šiuo metu apskaitos įrankių su API prieiga yra daugiau nei prieš trejus metus, tačiau tikrai tinkamų prekyvietėms vis dar nedaug. Dauguma jų buvo sukurti smulkiojo ir vidutinio verslo (SMB) buhalterijai, o API buvo „priklijuotas“ vėliau. Tik keli buvo kuriami pagal „API-first“ (pirmiausia API) principą.

Štai kaip mes vertiname atrinktus variantus.

Nordlet

Nordlet – tai įrankis, kurį rekomenduojame komandoms įvertinti pirmiausia, jei jos kuria prekyvietę ar platformą ES. Jis nuo pat pradžių buvo kuriamas kaip API, o ne kaip vartotojo sąsajos produktas su vėliau pridėtais galiniais taškais (endpoints), ir funkcijų atitikimas tarp programos bei API yra beveik šimtaprocentinis. Pagrindas – tai nekintama (immutable) dvejybinio įrašo didžioji knyga, kurioje integruota atskirų šalių PVM atitiktis, įskaitant VIES tikrinimą tarptautiniams B2B sandoriams ir i.SAF registrų generavimą VMI deklaravimui Lietuvoje.

Kas prekyvietei svarbu praktiškai:

• Griežto tipizavimo SDK (įskaitant TypeScript SDK) ir nuspėjami REST galiniai taškai, todėl naujo „backend“ inžinieriaus įvedimas trunka valandas, o ne savaites.
• Idempotentiškumo raktų palaikymas įrašant, o tai yra skirtumas tarp patikimos integracijos ir palaikymo užklausos (support ticket) kaskart, kai atsiranda tinklo trikdžių.
• „Webhook“ funkcionalumas tokiems įvykiams kaip sale_invoice.paid, leidžiantis jūsų produktui realiuoju laiku reaguoti į mokėjimų būsenos pasikeitimus.
• SEPA pain.001 eksportavimas tiekėjų bei pardavėjų išmokėjimams ir vieno paspaudimo banko likučių derinimas su išmaniuoju susiejimu (smart matching).
• Kelių įmonių valdymas vienoje paskyroje su vaidmenimis grįsta prieiga (savininkas, administratorius, buhalteris, vadovas, kūrėjas, stebėtojas), o tai ypač svarbu valdant įmonių grupės struktūrą.
• Periodų uždarymas, užtikrinantis, kad uždaryti mėnesiai nebūtų nepastebimai perrašyti – tai pirmas dalykas, kurio paklaus jūsų auditorius.

Kompromisas: Nordlet šiuo metu yra projektavimo partnerių (design partner) / išankstinės prieigos (early access) etape. Jei jums reikia brandaus prekyviečių sprendimo su šimtais viešai publikuotų sėkmės istorijų, to dar negausite. Tačiau, jei norite tiesiogiai dirbti su komanda, kuri kuria jums iš tiesų reikalingus bazinius elementus (primitives) – tai yra būtent tai.

Xero API

Xero turi didžiausią ekosistemą iš visų modernių apskaitos API ir yra logiškas pasirinkimas paprastam SMB ar lengvai platformos integracijai. Visgi prekyvietei ši struktūra greitai tampa nepatogi. Iš esmės tai „UI-first“ produktas, o kelių įmonių valdymas reiškia atskirų organizacijų žongliravimą, o ne vientisą grupės struktūrą. PVM valdymas yra solidus JK ir pritaikomas ES, tačiau specifiniai atskirų šalių niuansai, tokie kaip i.SAF ar Peppol BIS 3.0 e. sąskaitos faktūros, paprastai lieka už sistemos branduolio ribų ir priklauso nuo trečiųjų šalių programėlių.

QuickBooks Online API

QuickBooks užima stiprias pozicijas JAV ir gerina aprėptį ES, bet į ES orientuotai prekyvietei tai nėra tinkamas sprendimas. Mokesčių logika pirmiausia pritaikyta JAV pardavimo mokesčiui, ir, nors API yra pajėgus, dėl ES PVM specifinių atvejų (OSS ribos, atvirkštinis apmokestinimas visose 27 šalyse) dažniausiai prireikia kurti tarpinę programinę įrangą (middleware).

Sage / Sage Intacct

Sage vis dar pasitaiko ES viešųjų pirkimų ir sistemų pasirinkimo diskusijose, ypač kai finansų komandos su juo jau yra susipažinusios. API egzistuoja, tačiau atspindi savo amžių. Realaus laiko „webhook“ užklausos yra ribotos, kūrėjų dokumentacija skirtinguose produktuose nevienoda, o prielaida, kad buhalteris būtinai dalyvaus uždarant mėnesį, neatitinka modernios platformos komandos darbo principų.

Odoo

Odoo yra geras pasirinkimas, jei norite atvirojo kodo ERP, apimančios buhalterinę apskaitą, ir nebijote patys prižiūrėti infrastruktūros. API yra platus, tačiau ne labai gilus, todėl dažnai integruojatės labiau su ERP sistema nei su specializuotu apskaitos varikliu. Prekyvietėms su dideliu operaciniu sudėtingumu už finansų ribų (atsargų valdymas, gamyba), tai gali tikti. Grynajai prekyvietei dažniausiai tai pernelyg sudėtinga ir perteklinė sistema.

Senosios kartos, konkrečioms šalims skirti įrankiai

Daugumoje ES šalių yra bent po vieną įsitvirtinusį apskaitos produktą su daliniu API. Jie dažnai būna pigūs, juos mėgsta vietiniai buhalteriai, bet jie beveik niekada nėra sukurti programinei integracijai prekyvietės mastu. Jei esate nedidelis vietinis žaidėjas – puiku. Bet jei per dvejus metus planuojate plėstis į tarptautinę rinką, nuo čia nepradėkite.

Funkcionalumų palyginimas

Žemiau esančioje lentelėje atspindima tik tai, kas tiesiogiai patvirtinta viešoje produkto dokumentacijoje. Tais atvejais, kai neturime tiesioginio konkurento galimybių patvirtinimo, tai ir nurodome, užuot spėlioję.

Funkcionalumas	Nordlet	Xero API	QuickBooks API	Sage	Odoo
„API-first“ architektūra (funkcijų atitikimas tarp programos ir API)	Taip	Ne (UI-first)	Ne (UI-first)	Iš dalies	Iš dalies
Nekintama dvejybinio įrašo didžioji knyga	Taip	Viešai nepatvirtinta	Viešai nepatvirtinta	Viešai nepatvirtinta	Viešai nepatvirtinta
Kiekvienos šalies ES PVM su VIES tikrinimu	Taip	Iš dalies	Ribota	Nežinoma	Iš dalies
i.SAF registrų generavimas (Lietuva)	Taip	Nežinoma	Nežinoma	Nežinoma	Nežinoma
Griežto tipizavimo SDK (įskaitant TypeScript)	Taip	Dažniausiai trečiųjų šalių	Dažniausiai trečiųjų šalių	Nežinoma	Nežinoma
Idempotentiškumo raktų palaikymas	Taip	Viešai nepatvirtinta	Viešai nepatvirtinta	Nežinoma	Nežinoma
Realaus laiko „webhook“ finansiniams įvykiams	Taip	Ribota	Ribota	Ribota	Taip
SEPA pain.001 eksportavimas	Taip	Per programėles	Viešai nepatvirtinta	Nežinoma	Taip
Kelių įmonių valdymas vienoje paskyroje, RBAC	Taip	Kelios org. (atskirtos)	Kelios org. (atskirtos)	Taip	Taip
Periodų uždarymas	Taip	Taip	Taip	Taip	Taip
Prisijungimas be slaptažodžio	Taip	Nestandartinė	Nestandartinė	Nestandartinė	Nestandartinė

Priimant sprendimą prekyvietei, didžiausią svorį teiktume šiems aspektams: nekintamai didžiajai knygai, PVM specifikos palaikymui šalyse, kuriose faktiškai veikiate, ir idempotentiškumui. Visus kitus trūkumus galima apeiti. Tačiau šių trijų nebuvimas tampa nuolatine kliūtimi.

Likučių derinimo problema, apie kurią niekas neįspėja

Kiekvienas prekyvietės įkūrėjas, su kuriuo teko kalbėtis, nuvertina išmokėjimų derinimą. Štai kaip viskas paprastai vyksta.

Per savaitę apdorojate 4 000 užsakymų. Antradienį jūsų mokėjimų paslaugų teikėjas (PSP) perveda vieną bendrą sumą į jūsų banko sąskaitą, išskaičiavęs savo mokesčius, praėjusio laikotarpio grąžinimus bei ginčijamus mokėjimus (chargebacks). Jūsų apskaitos sistemai reikia žinoti: kuriems užsakymams atstovauja šis pavedimas, kokia dalis yra jūsų pajamos, o kokia – įsipareigojimai pardavėjui, koks PVM buvo surinktas nuo jūsų komisinio mokesčio, ir kas nutiks, jei vienas iš tų užsakymų bus grąžintas po trijų savaičių.

Jei jūsų apskaitos API negali importuoti PSP atsiskaitymų failo ir susieti jo su sąskaitomis faktūromis kokiu nors geresniu būdu nei tiesiog pagal tikslią sumą, teks pasamdyti žmogų, kurio visas darbas bus derinti „Excel“ lenteles. Esame matę, kaip tai nutinka įmonėse, kurios generuoja aštuonženklę bendrą prekių vertę (GMV).

Nordlet išmanusis susiejimas ir vieno paspaudimo sąskaitų faktūrų derinimas yra sukurtas būtent šiam procesui. Xero tai gali padaryti su papildiniais. QuickBooks integracijoms dažniausiai prireikia tarpinės programinės įrangos, kai apimtys viršija kelis tūkstančius operacijų per mėnesį.

PVM: priežastis, dėl kurios dauguma prekyviečių nuvertina darbų apimtį

ES PVM prekyvietėms yra iš tiesų sudėtingas dalykas, ir ne todėl, kad taisyklės būtų neaiškios. Taip yra todėl, kad jų daug ir jos sąveikauja tarpusavyje.

Nuo 2021 m. e. prekybos reformos ir prekyvietėms taikomų tariamo tiekėjo (deemed supplier) taisyklių įsigaliojimo, platforma tam tikrais sandoriais gali būti traktuojama kaip tiekėjas PVM tikslais, net jei ji netampa prekių savininke. Tai reiškia, kad pati prekyvietė turi PVM įsipareigojimų už pagrindinį pardavimą, o ne tik už savo komisinį mokestį. OSS deklaracijos, IOSS prekėms iki 150 EUR iš ne ES šalių, registravimosi PVM mokėtoju ribos atskirose šalyse, atvirkštinis apmokestinimas B2B paslaugoms, VIES tikrinimas tarptautiniams B2B sandoriams: visa tai turi būti teisinga ir atspindėta didžiojoje knygoje nuo pat operacijos užregistravimo momento, o ne atkurta ketvirčio pabaigoje.

Apskaitos API, kuris pateikia tik vat_rate laukelį ir tuo apsiriboja, neišlaikys jūsų pirmojo audito. Jums reikia kiekvienai šaliai pritaikytos logikos, kliento PVM kodo VIES tikrinimo sandorio metu ir automatinio vietinių deklaravimo formatų (i.SAF Lietuvoje, SAF-T variantų kitur) generavimo.

Tai yra sritis, kurioje naujai ES sukurti „API-first“ įrankiai dažniausiai smarkiai lenkia senesnius tarptautinius produktus. Reguliavimas yra pakankamai artimas ir pažįstamas, todėl programinę įrangą kuriančios komandos su juo gyvena kasdien.

Ką mes darytume pirmiausia

Jei rytoj kurtume ES prekyvietę ir rinktumėmės buhalterinės apskaitos infrastruktūrą, laikytumėmės tokios sekos:

1. Pirmiausia, o ne paskiausiai, išsiaiškinkite savo PVM prievoles. Susidarykite sąrašą visų šalių, į kurias parduosite pirmaisiais metais, nustatykite, ar sandoriai yra B2B, ar B2C, ir ar taikomos tariamo tiekėjo (deemed supplier) taisyklės. Tai parodys, ką iš tiesų turės apdoroti jūsų apskaitos sistema.
2. Sukurkite didžiosios knygos ir likučių derinimo prototipą testinėje aplinkoje (sandbox). Ne sąskaitų faktūrų išrašymo. Išrašyti sąskaitą faktūrą gali bet kas. Perleiskite realistinės savaitės apimties operacijas per testinę aplinką ir pažiūrėkite, kas nutiks mėnesio pabaigoje.
3. Patikrinkite API dokumentaciją dėl idempotentiškumo ir „webhook“ funkcijų. Jei negalite saugiai pakartoti užklausos arba prenumeruoti būsenos pasikeitimų, jūs kuriate trapią infrastruktūrą.
4. Pasikalbėkite su tuo, kas realiai uždarinės jūsų buhalterinius periodus. Jei jūsų buhalteris negali gauti reikiamų ataskaitų norimu formatu, pradiniai automatizavimo veiksmai praranda prasmę.
5. Pasirinkite tiekėją, kurio produktų vystymo planui (roadmap) galite daryti įtaką. Ankstyvosios stadijos prekyvietei tai svarbiau nei visų funkcijų turėjimas jau šiandien. Projektavimo partnerių susitarimai (design partner arrangements) egzistuoja ne be priežasties.

D.U.K.

Ar man tikrai reikia dvejybinio įrašo didžiosios knygos, ar pakanka operacijų lentelės?

Operacijų lentelė veikia iki pirmo karto, kai auditoriui prireikia paaiškinti neatitikimus arba pakoreguoti ankstesnį periodą. Dvejybinis įrašas nėra pasenęs buhalterijos teatras. Tai priežastis, dėl kurios jūsų apskaitos knygos balancuoja, o klaidos iškyla į paviršių iš karto, užuot tyliai kaupusios.

Ar galiu tiesiog naudoti Stripe ataskaitas vietoj apskaitos API?

Stripe yra mokėjimų procesorius. Jo ataskaitos puikiai tinka derinti paties Stripe mokėjimus. Tačiau jis nevykdo dvejybinio įrašo, neapdoroja ne per Stripe gautų pajamų ir negeneruoja teisės aktus atitinkančių deklaracijų. Naudokite jį kartu su apskaitos API, o ne vietoje jo.

Kaip tvarkytis su daugybe šalių nesiregistruojant visur?

B2C prekių ir paslaugų pardavimams ES viduje One Stop Shop (OSS) sistema leidžia deklaruoti pardavimus visoje ES vienoje šalyje, atsižvelgiant į tam tikras ribas ir išimtis. Jūsų apskaitos API turi teisingai kategorizuoti kiekvieną operaciją, kad OSS deklaracija būtų tiksli. Tai yra sistemos pajėgumo, o ne apėjimo (workaround) klausimas.

Ar „API-first“ buhalterija nėra per daug perteklinis sprendimas mažai prekyvietei?

Jei esate maži ir planuojate tokie likti, tradicinis įrankis su lengvu API bus puikus. Tačiau, jei planuojate augti, ankstyvas apskaitos integravimas į jūsų produktą atsieis kur kas pigiau nei vėlesnis perėjimas nuo „UI-first“ įrankio. Apskaitos infrastruktūros keitimo išlaidos yra vienos didžiausių visame įmonės technologijų steke.

Kas nutiks, jei tiekėjas pakeis savo API?

Prieš pasirašydami sutartį pasiteiraukite apie palaikymo nutraukimo (deprecation) politiką, versijavimą (versioning) ir kaip jie tvarkosi su drastiškais pakeitimais (breaking changes). Bet koks rimtas „API-first“ produktas turės aiškų atsakymą. Jei jo neturi – tai ir yra atsakymas.