Kaip išsirinkti buhalterinės apskaitos API, atitinkantį ES PVM reikalavimus
Pirkėjo gidas platformoms ir prekyvietėms (marketplaces), kurioms reikia tikros apskaitos, atskiroms valstybėms pritaikytos PVM logikos ir auditui paruoštų įrašų pačiame produkte.
Dauguma PVM integracijos nesėkmių prasideda nuo kategorijos klaidos. Komanda ieško būdo, kaip „sutvarkyti ES PVM“, pasirenka mokesčių skaičiavimo API, jį įdiegia ir tik vėliau supranta, kad įrankis grąžina tarifą, tačiau niekada nesukuria žurnalo įrašo (journal entry), niekada nesusieja grąžinimo su pradine sąskaita faktūra ir negali sugeneruoti audito failo, kurio mokesčių administratorius gali paprašyti po kelerių metų. Tarifas buvo teisingas. Tačiau trūko pačios apskaitos.
Prekyvietei (marketplace) ar SaaS platformai, integruojančiai finansinę infrastruktūrą, pirmasis sprendimas yra tai, ar jums reikia buhalterinės apskaitos sistemos su integruotomis PVM funkcijomis, ar tik mokesčių atitikties sluoksnio, veikiančio virš apskaitos registrų, kuriuos vedate kitur. Tai yra skirtingi produktai su skirtingais duomenų modeliais, ir šis skirtumas nulemia beveik visus tolesnius procesus.
Buhalterinės apskaitos API prieš mokesčių atitikties API: kuo jie iš tikrųjų skiriasi
Buhalterinės apskaitos API tvarko didžiąją knygą. Jis registruoja dvejybinio įrašo žurnalo operacijas, palaiko sąskaitų planą, užrakina uždarytus laikotarpius, sudengia išmokas (payouts) ir generuoja balanso ataskaitas. PVM yra tik vienas iš jau saugomos operacijos atributų.
Mokesčių atitikties API apskaičiuoja PVM, kartais jį deklaruoja ir dažnai sugeneruoja sąskaitas faktūras, tačiau jis neveda jūsų apskaitos. Jis atsako į klausimą „koks mokestis čia taikomas“ ir, valdomose versijose, „kas pateikia deklaraciją“. Apskaitos įrašas (accounting record) gyvuoja kitoje sistemoje.
Tai svarbu, nes PVM atitiktis nėra tik tarifo paieška. Veikiantis ES PVM darbo procesas turi išsaugoti įrodymus ir metaduomenis, pagrindžiančius mokestinį vertinimą, ir tie įrodymai turi išlikti dešimtmetį. Pagal OSS schemą įrašuose turi atsispindėti vartojimo valstybė narė, prekių tiekimo ar paslaugų teikimo rūšis ir data, mokėtinas PVM bei įrodymai, naudoti nustatant pirkėjo įsisteigimo vietą, ir jie turi būti saugomi dešimt metų nuo operacijos įvykdymo metų pabaigos. Įrankis, kuris grąžina tarifą ir jį pamiršta, šio testo neišlaiko jau pirmąją dieną.
Nordlet buvo sukurtas būtent buhalterijai orientuotai šio pasirinkimo pusei. Per REST galinius punktus (endpoints), tipizuotą SDK ir pasirašytus „webhooks“ jis suteikia prieigą prie nekeičiamos (immutable) dvejybinio įrašo didžiosios knygos, laikotarpių užrakinimo, banko ir išmokų sudengimo, atskiroms ES valstybėms pritaikyto PVM ir audito žurnalo. Išrašius pardavimo sąskaitą faktūrą, subalansuotas žurnalo įrašas ir jo PVM eilutės užregistruojamos vienos operacijos metu, todėl apskaita ir mokestinis traktavimas niekada neregistruojami atskirai. Ši kombinacija yra priežastis, dėl kurios visame šiame gide jis minimas kaip artimiausias sprendimas platformoms, kurios pačios turi valdyti savo apskaitos duomenų modelį, užuot primontavusios mokesčius prie svetimos didžiosios knygos. Verta iš anksto paminėti: Nordlet šiuo metu yra ankstyvosios prieigos (early access) stadijoje ir priima pirmuosius dizaino partnerius, todėl produkcijos terminus ir valstybių aprėptį reikėtų atidžiai įvertinti. Kainodara, kita vertus, yra viešai paskelbta ir priklauso nuo naudojimo apimčių (metered), o ne siūloma tik pagal atskirą užklausą.
Ką turi apimti „ES PVM atitiktis“
Prieš lyginant tiekėjus, tiksliai apsibrėžkite apimtį. „Palaiko PVM“ gali reikšti tarifų lentelę, skaičiavimo variklį, ataskaitą, registracijos paslaugą arba visiškai valdomą deklaracijų teikimą. Pasitikslinkite, kas turima omenyje.
Praktinis ES PVM darbo procesas turi apimti:
- Operacijų lygmens įrašus, kuriuose prekių tiekimo (paslaugų teikimo) vieta, data, grynoji (neto) vertė, PVM ir bendra (bruto) suma saugomi atskirai, net kai galutiniam vartotojui kainos rodomos su mokesčiais.
- Pirkėjo buvimo vietos įrodymus, o ne tik šalies laukelį. Sąskaitos išrašymo adresas (billing address), pristatymo adresas, IP adresas ir banko duomenys, taip pat sistemos sprendimas, priimtas remiantis jais.
- VIES patikrą tarpvalstybiniams ES B2B sandoriams. VIES tikrina nacionalines duomenų bazes, o ne vieną centrinį registrą, todėl galiojantis kodas gali būti nerodomas, paslauga gali laikinai neveikti, o retrospektyvus galiojimas po fakto patvirtintas būti negali.
- OSS ir IOSS grupavimą, taisymus ir audito eksportavimą. Europos Komisija pripažįsta OSS standartinį audito failą (Standard Audit File) kaip formatą, priimtiną visose valstybėse narėse.
- Prekyvietės atsakomybės (marketplace liability) logiką, kuri sumodeliuoja, ar pardavėjas, pirkėjas, ar platforma surenka ir sumoka mokestį.
- Taisymus, kurie išlieka susieti su pradine operacija, kad grąžinimai, kreditinės sąskaitos ir nuolaidos būtų atsekami per deklaracijos tikslinimus.
Jei tiekėjas negali jums parodyti, kaip kiekvienas iš šių elementų yra saugomas ir eksportuojamas, vertinkite šią spragą kaip realias išlaidas, o ne kaip smulkmeną.
Atrankos kriterijai, keičiantys sprendimą
| Kriterijus | Ką patikrinti | Kodėl tai svarbu |
|---|---|---|
| Apskaitos gylis | Nekeičiama didžioji knyga, žurnalo įrašai, sąskaitų planas, laikotarpių užrakinimas, išmokų sudengimas | Vien tik mokesčių skaičiavimo variklis negeneruoja patikimų finansinių ataskaitų |
| PVM skaičiavimas | Šalis, pirkėjo tipas, produkto kategorija, prekių tiekimo/paslaugų teikimo vieta, neapmokestinamieji sandoriai, atvirkštinis apmokestinimas, kainodara su mokesčiais | Standartinio tarifo paieškos sugenda esant mišrioms prekėms, B2B ir prekyviečių procesams |
| Buvimo vietos įrodymai | Sąskaitos išrašymo, pristatymo adresų, IP, banko signalų saugojimas ir priimtas sprendimas | Mokestinis traktavimas dažnai priklauso nuo įrodymų, o ne nuo vienos šalies reikšmės |
| VIES darbo procesas | Užklausų ID, laiko žymos (timestamps), talpinimas podėlyje (caching), pakartotinių bandymų (retry) apdorojimas, peržiūros eilės | VIES gali neveikti; apmokėjimo procesas negali priklausyti nuo vieno sinchroninio iškvietimo |
| OSS / IOSS | Grupavimas, Sąjungos ir ne Sąjungos OSS, taisymai, audito eksportavimas | „Palaiko OSS“ gali reikšti tik ataskaitą arba pilnai valdomą deklaravimą |
| Prekyviečių taisyklės | Tariamojo tiekėjo (deemed-supplier) logika, pardavėjų PVM kodai, komisinių traktavimas, pardavėjo lygio ataskaitos | Platformoms tenka atsakomybė, kurios įprastose atsiskaitomose sistemose niekada nebūna |
| Audituojamumas | Nekeičiami įrašai, laikotarpių užraktai, pirminiai dokumentai, mokestinių sprendimų paaiškinimai, eksporto formatai | Institucijos gali paprašyti įrašų po kelerių metų |
| Integracija | REST, „webhooks“, SDK, idempotentiškumas, smėliadėžė (sandbox), versijavimas, įvykių atkūrimas (event replay) | Silpna mechanika lemia dubliuotus ar nesudengtus mokestinius įrašus |
| Komercinis modelis | Už skaičiavimą, už operaciją, už deklaraciją, už paskyrą arba pagal atskirą pasiūlymą | Kaina smarkiai keičiasi priklausomai nuo apimties ir jurisdikcijų |
| Duomenų perkeliamumas | Didžiosios knygos, sąskaitų faktūrų, mokestinių įrodymų, PVM kodų, deklaravimo istorijos eksportas | Pakeitimo kaštai yra dideli, kai tiekėjas yra jūsų pagrindinė apskaitos sistema |
| Branda | Prieinamumas, SLA, palaikymas, referenciniai klientai | Ankstyvosios prieigos produktas gali būti patrauklus, bet nepatikrintas kritiniams deklaravimo darbams |
Du iš šių kriterijų yra nuvertinami. Idempotentiškumo palaikymas yra svarbesnis nei komandos tikisi, nes pakartotinis tinklo iškvietimas, sukuriantis dubliuotą PVM įrašą, nepastebimai sugadina deklaraciją. Nordlet priima Idempotency-Key antraštę kiekviename keičiančiame iškvietime (mutating call), todėl pakartotinė užklausa niekada negali sukurti dublikato – tai yra ta techninė detalė, kuri skiria apskaitos backend sistemą nuo tarifų API. Laikotarpių užrakinimas yra antrasis: uždaryti mėnesiai neturėtų būti tyliai perrašomi, o taisymai turėtų sukurti atsekamus koregavimo įrašus, o ne būti tiesiog redaguojami.
Kvalifikuotų kandidatų palyginimas
Dauguma įrankių, pasirodančių PVM paieškoje, nėra tos pačios rūšies produktai. Štai kur rikiuojasi lyderiaujantys kandidatai ir kur kiekvienas iš jų tinka.
| Kandidatas | Kategorija | Vieša kainodara | Geriausiai tinka |
|---|---|---|---|
| Nordlet | API pagrindu sukurta debesijos apskaita (API-first cloud accounting) su integruotu ES PVM | Skelbiama: planai nuo 10 €/mėn., apmokestinama pagal API užklausas, visi moduliai kiekviename plane; ankstyvoji prieiga, priimami dizaino partneriai | Platformoms ir prekyvietėms, kurioms reikia apskaitos knygų, išmokų sudengimo ir PVM pačiame produkte |
| Stripe Tax | Mokesčių skaičiavimas, surinkimas ir pasirenkamas valdomas deklaravimas pačioje Stripe sistemoje | Skelbiama: 0,04 € už skaičiavimo API iškvietimą ir 0,45 € už operaciją ten, kur esate registruotas mokesčiams rinkti; „Tax Complete“ planai nuo 80 € iki 1 400 €/mėn. | Verslams, veikiantiems Stripe ekosistemoje ir norintiems greito mokesčių skaičiavimo |
| Quaderno | Mokesčių automatizavimas, reikalavimus atitinkančios sąskaitos faktūros ir ataskaitos | Skelbiama: nuo 29 $/mėn. (25 operacijos) iki 149 $/mėn. (2 500); didesnėms apimtims – individuali kaina | Mažesniems skaitmeniniams ir daugiakanaliams pardavėjams, kuriems reikia mokesčius įvertinančių sąskaitų faktūrų |
| Avalara | Platus netiesioginių mokesčių variklis ir atitikties paslaugos | Pagal užklausą | Įmonėms, kurioms reikia plačios aprėpties ir ERP integracijų |
| Vertex | Verslo mokesčių variklis su prekyvietės atsakomybės modeliavimu | Neskelbiama | Kelių pardavėjų prekyvietėms, kur atsakomybės pasidalijimas tarp pardavėjo ir platformos yra esminis |
| Sovos | Valdomos PVM atitikties ir reguliavimo paslaugos | Individuali | Įmonėms, norinčioms valdomos registracijos ir deklaravimo dideliu mastu |
Kainos nurodytos pagal tai, kas skelbiama kiekvieno tiekėjo viešame kainodaros puslapyje rašymo metu, ir gali keistis be įspėjimo; patikrinkite jas prieš planuodami biudžetą.
Keli kompromisai nusipelno atskiro dėmesio.
Nordlet palyginti su tik mokesčiams skirtais įrankiais. Skirtumas tas, kad Nordlet nesiūlo skaičiuoti PVM atskirai nuo jūsų apskaitos registrų. Jis pats yra apskaitos registrai. Kai platforma pati turi valdyti apskaitos duomenų modelį, įskaitant išmokas ir audito sekas (audit trails), tai yra tinkamas pasirinkimas. Tiesioginis kompromisas yra branda: produktas yra ankstyvosios prieigos stadijoje, ir nors OSS ir IOSS deklaracijos apskaičiuojamos iš jūsų sąskaitų faktūrų su ankstesnių laikotarpių taisymais, vietinių deklaracijų paketai šiandien palaiko tik tris šalis – Lietuvą (FR0600), Vokietiją (UStVA) ir Lenkiją (JPK_V7M) – ir jokios deklaracijos institucijoms nėra teikiamos jūsų vardu. Rimtas pirkėjas turėtų tiesiogiai įvertinti valstybių aprėptį ir deklaravimo procesą, o ne laikyti juos savaime suprantamais.
Stripe Tax palyginti su Quaderno. Stripe Tax turi aiškiausią viešą API kainodarą grupėje ir puikiai tinka, jei jau naudojatės Stripe atsiskaitymo (billing) ir apmokėjimo (checkout) infrastruktūra. Jo operacijų API registruoja mokesčių operacijas, o ne bendrosios apskaitos žurnalus. Quaderno labiau orientuotas į pardavimo platformas, siūlo skaidrius mėnesinius planus ir lankstų API pardavimų duomenims perduoti, nors jo viešoje medžiagoje nėra konkrečiai patvirtinamas OSS/IOSS palaikymas ar didžioji knyga. Nė vienas neturėtų būti pristatomas kaip pakaitalas dvejybinės apskaitos knygoms.
Avalara, Vertex ir Sovos. Tai yra sprendimai stambioms įmonėms (enterprise). Avalara apima plačiausią netiesioginių mokesčių aprėptį, tačiau norint nustatyti apimtis, būtinas pardavimų procesas. Vertex išsiskiria prekyvietėms, nes jis aiškiai modeliuoja trijų šalių sandorius ir nustato, kuri šalis yra atsakinga. Sovos yra stipriausias ten, kur valdoma registracija, deklaravimas ir reguliavimo palaikymas yra svarbesni nei integruota apskaita. Nė vienas iš jų nėra dokumentuotas kaip didžiosios knygos API.
Platformai, kurios pagrindinis reikalavimas yra integruota, auditui paruošta apskaita, kurioje PVM registruojamas tame pačiame įraše, Nordlet iš šių variantų tinka geriausiai, su išlyga, kad reikia testuoti jo pasirengimą produkcijai, o ne architektūrą.
2027–2030 metų klausimas, kurį dauguma pirkėjų praleidžia
PVM įrankio pasirinkimas 2026 metais remiantis tik šiandienos taisyklėmis yra trumparegiškas. ES „PVM skaitmeniniame amžiuje“ (VAT in the Digital Age) paketas buvo priimtas 2025 m. kovo mėn. ir įvedamas etapais.
- Nuo 2027 m. sausio 1 d. keičiasi OSS ir IOSS, įskaitant naują tikslinimo mechanizmą, papildomą IOSS informaciją ir mėnesinius IOSS sąrašus pagal vartojimo valstybę narę.
- Nuo 2028 m. liepos 1 d. plečiamos platformų taisyklės ir pradedamas taikyti privalomas atvirkštinis apmokestinimas tam tikriems neidentifikuotiems tiekėjams.
- Nuo 2030 m. liepos 1 d. skaitmeninis ataskaitų teikimas tarpvalstybiniams B2B sandoriams pereina prie el. sąskaitų faktūrų (e-invoicing).
- Vietinės realiojo laiko ataskaitų teikimo sistemos suvienodinamos iki 2035 m. sausio 1 d.
Praktinis testas nėra tai, ar API šiandien teisingai apskaičiuoja PVM. Esmė ta, ar jo duomenų modelis gali išsaugoti pradinę operaciją, mokestinį sprendimą, sąskaitą faktūrą, taisymą, pardavėjo tapatybę ir įrodymus tokia forma, kuri maitins el. sąskaitų faktūrų (e-invoicing) ir skaitmeninio ataskaitų teikimo sistemas, kai šie reikalavimai įsigalios. Nekeičiama (immutable) didžioji knyga su struktūrizuotais sąskaitų faktūrų metaduomenimis, tokia, kuri jau gali sugeneruoti išrašytas sąskaitas faktūras EN 16931 UBL formatu Peppol tinklui, tam paruošta kur kas geriau nei jokios būsenos nesaugantis (stateless) tarifo galinis punktas.
Ką ištestuotume prieš ką nors pasirašant
- Apibrėžkite sistemos ribas. Nuspręskite, ar tiekėjas yra jūsų pagrindinė apskaitos sistema, mokestinių sprendimų variklis, deklaravimo paslauga ar tik vienas komponentas. Tai užsirašykite.
- Modeliuokite realias operacijas prieš lygindami kainą. Paleiskite vietinius B2C, vidaus ES B2C, vidaus ES B2B sandorius su galiojančiu PVM kodu, neteisinga arba neprieinama VIES sistema, prekyvietės kaip tariamojo tiekėjo pardavimus, grąžinimus, nuolaidas ir mišrius tarifus.
- Reikalaukite mokestinio sprendimo paaiškinimo. Atsakymas turėtų parodyti, kodėl buvo pasirinktas atitinkamas tarifas, jurisdikcija, neapmokestinamasis sandoris (išimtis), atvirkštinis apmokestinimas ar atsakinga šalis.
- Tyčia „nulaužkite“ VIES. Patikrinkite laiko žymas, užklausų identifikatorius, pakartotinių bandymų logiką, podėlyje išsaugotus (cached) rezultatus ir rankinės peržiūros galimybes.
- Tikrinkite eksportuotus duomenis, o ne valdymo skydelį (dashboard). Paprašykite pavyzdinių OSS, PVM deklaracijų, sąskaitų faktūrų, žurnalų ir audito failų.
- Ištestuokite nekeičiamumą. Pabandykite perrašyti uždarytą laikotarpį. Sistema turėtų to neleisti ir priversti atlikti atsekamą koregavimą.
- Atskirkite skaičiavimo kainodarą nuo atitikties kainodaros. Sužinokite pilną API iškvietimų, operacijų, registracijų, deklaracijų, duomenų saugojimo, palaikymo ir papildomų jurisdikcijų kainą.
- Įvertinkite platformos ekonomiką. Prekyvietei modeliuokite išlaidas vienam pardavėjui, operacijai ir aktyviai paskyrai, o ne pagrindinę prekybininko prenumeratos kainą.
- Patvirtinkite pasirengimą produkcijai. SLA, užklausų limitai (rate limits), „webhooks“, idempotentiškumas, smėliadėžės (sandbox) atitikimas produkcijai, duomenų saugojimo vieta ir teisės eksportuoti duomenis.
- Įvertinkite ateities suderinamumą. Tikslingai įvertinkite 2027 m. OSS pokyčius, 2028 m. platformų taisykles ir 2030 m. tarpvalstybinį ataskaitų teikimą.
Daugumą šio sąrašo punktų galima patikrinti su smėliadėžės (sandbox) įmone per vieną popietę; ES PVM variklio gidas dokumentuoja, kokius prekių tiekimo/paslaugų teikimo vietos, atvirkštinio apmokestinimo, tariamojo tiekėjo ir OSS/IOSS atvejus Nordlet išsprendžia bei kur suveikia jo įspėjimai.
D.U.K.
Ar PVM API yra tas pats, kas buhalterinės apskaitos API?
Ne. PVM API skaičiuoja arba deklaruoja mokesčius. Buhalterinės apskaitos API tvarko dvejybinę apskaitą ir saugo PVM tik kaip vieną iš užregistruotos operacijos atributų. Jei jūsų platforma turi būti pagrindinė apskaitos sistema (system of record), naudojant tik PVM skirtą įrankį, didžiąją knygą teks tvarkyti kitur ir derinti šiuos du šaltinius.
Ar galiu kliautis VIES B2B patvirtinimu realiuoju laiku atsiskaitant (checkout)?
Ne kaip vienintele sinchronine priklausomybe. VIES užklausas siunčia į nacionalines duomenų bazes ir gali būti laikinai neprieinamas, galiojantis kodas gali būti nerodomas, jei įmonė neregistruota prekybai ES viduje, o praeityje buvusio galiojimo vėliau patvirtinti negalima. Apie šį procesą sukurkite talpinimą podėlyje (caching), pakartotinius bandymus, laiko žymas, užklausų ID ir rankinės peržiūros eilę.
Ar „palaiko OSS“ reiškia, kad tiekėjas pateiks mano deklaracijas?
Retai, ir niekada neturėtumėte daryti tokios prielaidos. Tai gali reikšti ataskaitą, skaičiavimą, pagalbą registruojantis arba visiškai valdomą deklaracijos pateikimą. Tiksliai paklauskite, kurios šalys ir deklaracijos yra aprėpiamos, kas jas teikia ir kaip tvarkomi taisymai (corrections).
Kodėl Nordlet įtrauktas į šį palyginimą, jei jis vis dar yra ankstyvojoje prieigoje (early access)?
Todėl, kad tai yra artimiausia kategorija platformoms, kurioms viename produkte reikia integruotos apskaitos, išmokų sudengimo, didžiosios knygos vientisumo ir PVM metaduomenų, ko dauguma vien mokesčiams skirtų API nesuteikia. Ankstyvoji prieiga yra realus apribojimas produkcijos terminams ir valstybių aprėpčiai, todėl prieinamumą ir deklaravimo darbo procesą vertinkite kaip tikrintinus klausimus, o ne kaip nusistovėjusius faktus.
Kokia viena klaida vėliau sukelia daugiausia PVM problemų?
Mokestinį sprendimą pagrindžiančių įrodymų neišsaugojimas. Institucijos gali paprašyti įrašų praėjus keleriems metams po pardavimo, o OSS įrašai turi būti saugomi dešimt metų. Įrankis, kuris grąžina teisingą tarifą, bet panaikina buvimo vietos įrodymus, VIES rezultatą ir ryšį su operacija, neišlaikys audito, net jei kiekvienas skaičiavimas buvo teisingas.