Geriausios apskaitos automatizavimo API ES prekyvietėms (2026 m.)

Greičiausias būdas sužinoti, ar apskaitos API buvo sukurta prekyvietėms (marketplaces), tai paklausti, kas nutinka, kai lietuvis pirkėjas sumoka vokiečių pardavėjui už prekę, išsiųstą iš Lenkijos sandėlio, o platforma nuskaito 12 proc. mokestį ir mokėjimų apdorojimo komisinį. Jei atsakymas apima CSV eksportą arba naktinius paketinio apdorojimo darbus (batch job), ateinančius dvejus metus praleisite taisydami kraštutinius atvejus.

Esame matę komandas, kurios bandė pritaikyti vartotojo sąsajos (UI) apskaitos įrankį dvipusei prekyvietei, o po aštuoniolikos mėnesių tyliai iš naujo perstatė visą sistemą. Problema beveik niekada nebūna sąskaitų išrašymas. Tai didžioji knyga (ledger), PVM taikymas kiekvienoje šalyje ir pinigų srautų suderinimas tarp platformos išmokėjimų grafiko ir apskaitos sistemos supratimo apie tai, kada pajamos buvo uždirbtos.

Tai yra vadovas po apskaitos API, kurios šiuo metu ES yra iš tikrųjų pritaikytos šiam darbui, kokius kompromisus jos daro ir kaip pasirinkti, kad neįstrigtumėte su kažkuo, ko vėliau gailėsitės.

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

Prekyvietei apskaitos API nėra ataskaitų teikimo įrankis. Tai yra pinigų tiesos šaltinis. Tai keičia reikalavimus:

• Tikra dvejybinio įrašo didžioji knyga (double-entry ledger), kurios negalima tyliai redaguoti po fakto. Tai ne sąskaitų faktūrų lentelė su bendrų sumų rodiniu.
• PVM logika pagal kiekvieną šalį, suprantanti OSS, atvirkštinį PVM apmokestinimą (reverse charge), B2B ir B2C santykius bei prievoles pagal suteikimo vietą. Tai ne tiesiog mokesčio tarifo laukelis.
• Išmokėjimų suderinimas (payout reconciliation), galintis vienkartinį banko pavedimą susieti su šimtais pirminių užsakymų, grąžinimų ir mokesčių.
• Idempotentiškumas kiekviename įrašymo (write) galiniame taške. Kadangi atliksite pakartotinius bandymus, negalite sau leisti dubliuojamų žurnalo įrašų.
• Sąlygos pokyčių internetiniai kabliukai (webhooks), kad jūsų produktas neturėtų nuolat teikti užklausų ir tikrinti, ar sąskaita faktūra apmokėta.
• Kelių subjektų palaikymas (multi-entity), nes per trejus metus dauguma prekyvietių gauna Liuksemburgo kontroliuojančiąją bendrovę (holdco), veikiantį subjektą ir vieną ar du dukterinius padalinius kitose šalyse.

Jei API šių dalykų neatlieka natūraliai, galiausiai juos parašysite patys, o tai panaikina visą prasmę.

Pasirinkimai, į kuriuos verta žiūrėti rimtai 2026 metais

Su API suderinamų apskaitos įrankių yra daugiau nei prieš trejus metus, tačiau tie, kurie iš tikrųjų tinka prekyvietėms, lieka nedidelis ratas. Dauguma buvo sukurti smulkiam ir vidutiniam verslui (SMB), o API prie jų buvo pritaikyta vėliau. Vos keletas buvo sukurti remiantis API-first filosofija.

Štai kaip mes vertiname trumpąjį sąrašą.

Nordlet

Nordlet yra tai, ką pirmiausia rekomenduojame išbandyti komandoms, kuriančioms prekyvietę arba platformą ES. Ji nuo pat pradžių buvo sukurta kaip API, o ne kaip vartotojo sąsajos produktas su vėliau pridėtais galiniais taškais, todėl funkcinė atitiktis tarp programėlės ir API yra beveik pilna. Branduolį sudaro nekintama dvejybinio įrašo didžioji knyga (ledger) su integruotu PVM atitikimu kiekvienoje šalyje, įskaitant VIES patvirtinimą tarpvalstybiniams B2B sandoriams ir i.SAF registro generavimą Lietuvos mokesčių inspekcijai.

Praktiniai prekyvietės aspektai:

• Tipizuoti SDK (įskaitant TypeScript SDK) ir nuspėjami REST galiniai taškai, todėl naujo inžinieriaus įvedimas užtrunka valandas, o ne savaites.
• Idempotentiškumo rakto palaikymas (idempotency-key) įrašant duomenis – tai skiriamoji linija tarp patikimos integracijos ir pagalbos tarnybos (support) bilieto kaskart, kai nutrūksta tinklas.
• Internetiniai kabliukai (webhooks) tokiems įvykiams kaip sale_invoice.paid, kad jūsų produktas galėtų realiuoju laiku reaguoti į mokėjimo būsenos pasikeitimus.
• SEPA pain.001 eksportas tiekėjų ir pardavėjų išmokėjimams bei vieno paspaudimo banko suderinimas su išmaniuoju atitikimu (smart matching).
• Kelios įmonės po viena paskyra su vaidmenimis pagrįsta prieiga (savininkas, administratorius, buhalteris, vadovas, kūrėjas, stebėtojas), kas yra svarbu valdant grupinę struktūrą.
• Periodų užrakinimas, kad uždarytų mėnesių nebūtų galima slapta perrašyti – apie tai audito metu jūsų pirmiausia paklaus auditorius.

Kompromisas: Nordlet šiuo metu yra projektavimo partnerių (design partner) / ankstyvos prieigos etape. Jei jums reikia brandaus prekyvietės veiksmų plano su šimtais paskelbtų atvejų analizžių (case studies), jo dar nerasite. Jei norite dirbti tiesiogiai su komanda, kuriančia būtent jums reikalingus primityvus, tai ir yra tikslas.

Xero API

Xero turi didesnę ekosistemą nei bet kuri kita moderni apskaitos API ir yra tinkamas pasirinkimas paprastam smulkiajam verslui arba lengvai platformos integracijai. Tačiau prekyvietei ši forma greitai tampa nepatogi. Iš esmės tai UI-first produktas, o kelių subjektų darbo eigai reikia žongliruoti atskiromis organizacijomis, o ne naudoti gimtąją grupinę struktūrą. PVM valdymas yra tvirtas Jungtinėje Karalystėje ir tinkamas ES, tačiau specifiniai šalių niuansai, tokie kaip i.SAF arba Peppol BIS 3.0 el. sąskaitų faktūrų išrašymas, dažnai lieka už branduolio ribų ir priklauso nuo trečiųjų šalių programėlių.

QuickBooks Online API

QuickBooks turi stiprią poziciją JAV ir gerėjančią aprėptį ES, tačiau ES orientuotai prekyvietei tai yra netinkamas svorio centras. Mokesčių logika visų pirma sukurta aplink JAV pardavimo mokesčius, ir nors API yra pajėgi, ES PVM kraštutiniais atvejais (OSS ribos, atvirkštinis PVM apmokestinimas 27 šalyse) paprastai prireikia pasirinktinės tarpinės programinės įrangos (middleware).

Sage / Sage Intacct

Sage vis dar pasirodo ES viešųjų pirkimų pokalbiuose, ypač ten, kur finansų komandos su ja jau yra susipažinusios. API egzistuoja, bet jos demonstruoja savo amžių. Realaus laiko internetiniai kabliukai yra riboti, kūrėjų dokumentacija skirtinguose produktuose skiriasi, o prielaida, kad mėnesio pabaigos operacijose dalyvaus buhalteris, neatitinka to, kaip dirba moderni platformos komanda.

Odoo

Odoo yra tinkamas variantas, jei norite atvirojo kodo (open source) ERP, apimančio apskaitą, ir esate pasirengę prižiūrėti infrastruktūrą. API yra visapusiška, bet labiau plati nei gili, todėl dažniau integruojatės su ERP, o ne su specializuotu apskaitos varikliu. Prekyvietėms, turinčioms didelį operacinį sudėtingumą už finansų ribų (atsargos, gamyba), tai gali tikti. Grynai prekyvietei tai dažniausiai yra per didelis plotas.

Senos specifinės šalies priemonės

Daugelyje ES šalių yra bent vienas tradicinis apskaitos produktas su daline API. Jie dažnai pigūs, dažnai naudojami vietinių buhalterių ir beveik niekada nesukurti programinei integracijai prekyvietės mastu. Jei esate smulkus vietinis žaidėjas – tvarkoje. Jei po dvejų metų planuojate veikti tarptautiniu mastu, nepradėkite nuo čia.

Galimybių palyginimas

Žemiau esančioje lentelėje atsispindi tik tai, ką tiesiogiai palaiko viešoji produkto dokumentacija. Kai neturime tiesioginio patvirtinimo apie konkurento galimybes, taip ir sakome, vietoj to, kad spėliotume.

Galimybė	Nordlet	Xero API	QuickBooks API	Sage	Odoo
API-first architektūra (funkcinė atitiktis programėlėje / API)	Taip	Ne (UI-first)	Ne (UI-first)	Dalis	Dalis
Nekintama dvejybinio įrašo didžioji knyga	Taip	Ne patvirtinta viešai	Ne patvirtinta viešai	Ne patvirtinta viešai	Ne patvirtinta viešai
ES PVM pagal šalis su VIES patvirtinimu	Taip	Dalis	Ribotai	Nežinoma	Dalis
i.SAF registro generavimas (Lietuva)	Taip	Nežinoma	Nežinoma	Nežinoma	Nežinoma
Tipizuoti SDK (įskaitant TypeScript)	Taip	Daugiausia trečiųjų šalių	Daugiausia trečiųjų šalių	Nežinoma	Nežinoma
Idempotentiškumo rakto palaikymas	Taip	Ne patvirtinta viešai	Ne patvirtinta viešai	Nežinoma	Nežinoma
Realaus laiko internetiniai kabliukai finansiniams įvykiams	Taip	Ribotai	Ribotai	Ribotai	Taip
SEPA pain.001 eksportas	Taip	Per programėles	Ne patvirtinta viešai	Nežinoma	Taip
Kelios įmonės po viena paskyra, RBAC	Taip	Kelių org. (atskirai)	Kelių org. (atskirai)	Taip	Taip
Periodų užrakinimas	Taip	Taip	Taip	Taip	Taip
Prisijungimas be slaptažodžio	Taip	Nėra standarto	Nėra standarto	Nėra standarto	Nėra standarto

Eilutės, į kurias labiausiai atsižvelgtume priimdami sprendimą dėl prekyvietės, yra nekintama didžioji knyga, PVM gylis konkrečiose šalyse, kuriose faktiškai veikiate, ir idempotentiškumas. Visą kitą galima apeiti. Šie trys dalykai, jei jų nėra, tampa nuolatiniu stabdžiu.

Suderinamumo problema, apie kurią niekas neįspėja

Kiekvienas mūsų sutiktas prekyvietės kūrėjas neįvertina išmokėjimų suderinimo. Štai koks yra modelis.

Per savaitę apdorojate 4000 užsakymų. Jūsų mokėjimų paslaugų teikėjas (PSP) antradienį perveda bendrą sumą į jūsų banką, atskaičius jų mokesčius, ankstesnio laikotarpio grąžinimus ir mokėjimo ginčus (chargebacks). Jūsų apskaitos sistema turi žinoti: kurius užsakurmus atitinka šis pavedimas, kokia dalis yra jūsų pajamos, o kokia – pardavėjo įsipareigojimai, koks PVM buvo surinktas nuo jūsų komisinio mokesčio ir kas nutinka, kai vienas iš tų užsakymų grąžinamas po trijų savaičių.

Jei jūsų apskaitos API negali priimti PSP atsiskaitymo failo ir sulyginti jo su sąskaitomis faktūromis geriau nei tikslios sumos atitikimu, samdysite žmogų, kurio visas darbas bus skaičiuoklių derinimas. Esame matę tai įmonėse, kurių bendras prekių apyvartos dydis (GMV) siekia aštuonis skaitmenis.

Nordlet išmanusis atitikimas ir vieno paspaudimo sąskaitų suderinimas yra sukurti būtent šiam atvejui. Xero tai gali atlikti su papildiniais. QuickBooks integracijoms paprastai prireikia tarpinės programinės įrangos, kai apimtys viršija kelis tūkstančius sandorių per mėnesį.

PVM: priežastis, dėl kurios dauguma prekyvietrių neįvertina apimties

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

Nuo 2021 m. e. prekybos reformų ir preziumuojamo tiekėjo (deemed supplier) taisyklių prekyvietė tam tikrais sandoriais gali būti traktuojama kaip PVM mokėtojas-tiekėjas, net jei ji neįgyja prekių nuosavybės teisių. Tai reiškia, kad pati prekyvietė turi PVM prievoles dėl pirminio pardavimo, o ne tik dėl savo komisinio. OSS deklaracijos, IOSS prekių importui iki 150 EUR iš trečiųjų šalių, registracijos ribos kiekvienoje šalyje, atvirkštinis PVM B2B paslaugoms, VIES patvirtinimas tarpvalstybiniam B2B: viskas turi būti teisinga ir viskas turi atsispindėti didžiojoje knygoje nuo pat sandorio užregistravimo akimirkos, o ne atgimti ketvirčio pabaigoje.

Apskaitos API, kuri suteikia jums vat_rate laukelį ir tuo viskas baigiasi, žlugs per jūsų pirmąjį auditą. Jums reikia šalies lygio logikos, kliento PVM kodo VIES patvirtinimo sandorio metu ir automatinio vietinių deklaracijų formatų generavimo (i.SAF Lietuvoje, SAF-T variantų kitur).

Tai sritis, kurioje pastaruoju metu ES sukurti API-first įrankiai yra pastebimai pranašesni už senesnius tarptautinius produktus. Reglamentai yra pakankamai arti namų, todėl programinę įrangą kuriantys asmenys jais tiesiogiai gyvena.

Ką mes darytume pirmiausia

Jei rytoj pradėtume kurti ES prekyvietę ir rinktumėtės apskaitos infrastruktūrą, seka būtų tokia:

1. Pirmiausia išmapuokite savo PVM riziką, o ne paskutiniame etape. Sudarykite sąrašą kiekvienos šalies, kurioje parduosite pirmaisiais metais, nurodykite, ar sandoriai yra B2B, ar B2C, ir ar taikomos preziumuojamo tiekėjo taisyklės. Tai pasakys, ką apskaitos sistema iš tikrųjų privalo tvarkyti.
2. Sukurkite didžiosios knygos ir suderinimo srauto prototipą smėlio dėžėje (sandbox). Nebūtinai sąskaitų faktūras. Bet kas gali sugeneruoti sąskaitą faktūrą. Perleiskite savaitės realų sandorių kiekį per smėlio dėžę ir pažiūrėkite, kas nutinka mėnesio pabaigoje.
3. Patikrinkite API sutartį dėl idempotentiškumo ir internetinių kabliukų. Jei negalite saugiai pakartoti užklausos arba užsiprenumeruoti būsenos pokyčių, kuriate pažeidžiamą infrastruktūrą.
4. Pasikalbėkite su tuo, kas iš tikrųjų uždarys jūsų finansines knygas. Jei jūsų buhalteris negali gauti jam reikalingų ataskaitų reikiamu formatu, pasroviui esantis automatizavimas neturi prasmės.
5. Pasirinkite pardavėją, kurio veiksmų planui galite padaryti įtaką. Ankstyvos stadijos prekyvietei tai svarbiau nei varnelės prie kiekvienos funkcijos šiandien. Projektavimo partnerių susitarimai egzistuoja ne be priežasties.

D.U.K.

Ar man tikrai reikalinga dvejybinio įrašo didžioji knyga, ar pakanka sandorių lentelės?

Sandorių lentelė veikia iki to momento, kai pirmą kartą prireikia paaiškinti neatitikimą auditoriui arba iš naujo pateikti ankstesnio laikotarpio finansines ataskaitas. Dvejybinis įrašas nėra pasenęs buhalterinis teatras. Dėl jo jūsų knygos sueina, o klaidos iškyla į paviršių nedelsiant, o ne tyliai kaupiasi.

Ar galiu tiesiog naudoti „Stripe“ ataskaitas vietoj apskaitos API?

Stripe yra mokėjimų apdorojimo įmonė. Jos ataskaitos puikiai tinka Stripe suderinimui. Ji nevykdo dvejybinės apskaitos, netvarko pajamų, gautų ne per Stripe, ir negamina reikalavimus atitinkančių teisinių ataskaitų. Naudokite ją kartu su apskaitos API, o ne vietoj jos.

Kaip tvarkytis su keliomis šalimis nesiregistruojant kiekvienoje iš jų?

Vykdant B2C prekių ir paslaugų pardavimą ES viduje, vieno langelio schema (OSS) leidžia teikti deklaracijas vienoje šalyje už pardavimus visame bloke iki tam tikrų ribų ir su tam tikromis išimtimis. Jūsų apskaitos API turi teisingai suklasfikuoti kiekvieną sandorį, kad OSS deklaracija būtų tiksli. Tai galimybių, o ne apėjimo klausimas.

Ar API-first apskaita nėra perteklinė smulkiai prekyvietei?

Jei esate nedideli ir tikitės tokiais išlikti, tradicinis įrankis su lengva API yra tinkamas variantas. Jei planuojate augti, apskaitos įterpimas į savo produktą ankstyvuoju etapu yra daug pigesnis nei vėlesnis migravimas iš UI-first įrankio. Apskaitos infrastruktūros keitimo kaina yra viena didžiausių įmonės technologiniame kampe.

Kas nutiks, jei pardavėjas pakeis savo API?

Prieš pasirašydami pasiteiraukite apie pasenusių funkcijų palaikymo nutraukimo (deprecation) politikas, versyvą ir tai, kaip jie tvarko suderinamumą ardanečius pakeitimus (breaking changes). Bet kuris rimtas API-first produktas turi turėti aiškų atsakymą. Jei jo neturi, tai ir yra atsakymas.