Nordlet

← Tinklaraštis

Kaip pasirinkti apskaitos API, atitinkantį ES PVM reikalavimus

Pirkėjo vadovas platformoms ir prekyvietėms, kurioms savo produkto viduje reikia tikrųjų knygų, konkrečioms šalims pritaikytos PVM logikos ir audito reikalavimus atitinkančių įrašų.

Nordlet Team · · 11 min. skaitymo

Didžioji dalis PVM integracijos nesėkmių prasideda nuo kategorijos klaidos. Komanda ieško būdo „tvarkyti ES PVM“, pasirenka mokesčių skaičiavimo API, paleidžia jį į gamybinę aplinką ir tik vėliau sužino, kad įrankis grąžina tarifą, tačiau niekada neužregistruoja buhalterinio įrašo, nesusieja grąžinimo su pradine sąskaita faktūra ir negali pateikti audito rinkmenos, kurios mokesčių inspekcija gali paprašyti po kelerių metų. Tarifas buvo teisingas. Apskaitos trūko.

Prekyvietei arba SaaS platformai, diegiančiai finansinę infrastruktūrą, pirmasis sprendimas yra nuspręsti, ar reikia apskaitos sistemos su gimtosiomis PVM galimybėmis, ar mokesčių atitikties sluoksnio, kuris veikia virš apskaitos knygų, tvarkomų kitur. Tai skirtingi produktai su skirtingais duomenų modeliais, ir šis skirtumas nulemia beveik viską, kas vyksta vėliau.

Apsakaitos API ir mokesčių atitikties API: kas iš tiesų skiriasi

Apskaitos API palaiko didžiąją knygą (ledger). Ji fiksuoja dvejybinio įrašo buhalterinius įrašus, tvarko sąskaitų planą, užrakina uždarytus laikotarpius, suderina išmokas ir rengia balansines ataskaitas. PVM yra tik vienas iš jau saugomos operacijos atributų.

Mokesčių atitikties API apskaičiuoja PVM, kartais jį deklaruoja ir dažnai išrašo sąskaitas faktūras, tačiau ji netvarko jūsų apskaitos knygų. Ji atako į klausimus „koks mokestis čia taikomas“, o valdomose versijose – „kas teikia deklaraciją“. Apskaitos įrašas 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, kurie pagrindžia mokesčio taikymą, o šie įrodymai privalo išlikti dešimtmetį. Pagal OSS schemą įrašuose turi būti nurodyta vartojimo valstybė narė, tiekimo tipas ir data, mokėtinas PVM bei įrodymai, naudoti nustatant, kur yra įsikūręs klientas, ir jie turi būti saugomi dešimt metų nuo sandorio metų pabaigos. Įrankis, kuris grąžina tarifą ir jį pamiršta, šį testą išlaiko jau pirmąją dieną.

„Nordlet“ buvo sukurta būtent apskaitai pirmenybę teikiančiai šios pusės daliai. Ji pateikia nekeičiamą dvejybinio įrašo didžiąją knygą, laikotarpių užrakinimą, banko ir išmokų suderinimą, kiekvienai šaliai pritaikytą ES PVM ir audito žurnalą per REST galinius punktus (endpoints), tipizuotą SDK ir pasirašytus demonstracinius pranešimus (webhooks). Pardavimo sąskaitos faktūros išrašymas vienos operacijos metu įrašo subalansuotą buhalterinį įrašą ir jo PVM eilutes, todėl apskaita ir mokesčių taikymas niekada neužregistruojami atskirai. Šis derinys yra priežastis, kodėl šiame vadove ji minima kaip geriausiai tinkanti kategorija platformoms, kurioms reikia patiems valdyti savo apskaitos duomenų modelį, o ne pritaikyti mokesčius prie svetimos knygos. Verta iš anksto paminėti: „Nordlet“ yra ankstyvosios prieigos stadijoje ir priima bandymų partnerius, todėl gamybinės aplinkos terminai ir šalių padengimas yra dalykai, kuriuos būtina patvirtinti. Kainodara, kitaip nei individualių pasiūlymų atveju, yra vieša ir apskaičiuojama pagal apimtį.

Ką turi apimti „ES PVM atitiktis“

Prieš lygindami paslaugų teikėjus, apibrėžkite apimtį. Teiginys „palaiko PVM“ gali reikšti tarifų lentelę, skaičiavimo varikliuką, ataskaitą, registracijos paslaugą arba visiškai valdomą deklaravimą. Paklauskite, kuris iš jų.

Praktinis ES PVM darbo procesas turi apimti:

  • Operacijų lygio įrašus su atskirai saugomomis prekių ar paslaugų teikimo vieta, teikimo data, verte be PVM, PVM ir bendra sumomis, net jei galutinės kainos vartotojams rodomos su mokesčiais.
  • Kliento buvimo vietos įrodymus, o ne tik šalies lauką. Sąskaitos faktūros išrašymo adresą, pristatymo adresą, IP ir banko signalus bei sisteminį sprendimą, priimtą remiantis jais.
  • VIES patvirtinimą tarptautiniams B2B sandoriams ES viduje. VIES tikrina nacionalines duomenų bazes, o ne vieną centrinį registrą, todėl galiojantis numeris gali būti nerandamas, paslauga gali būti laikinai nepasiekiama, o istorinis galiojimas negali būti patvirtintas po laiko.
  • OSS ir IOSS grupavimą, pataisymus ir audito eksportus. Europos Komisija pripažįsta OSS standartinę audito rinkmeną kaip formatą, priimtiną visose valstybėse narėse.
  • Prekyvietės atsakomybės logiką, pagal kurią modeliuojama, ar mokesčius surenka ir sumoka pardavėjas, pirkėjas, ar platforma.
  • Pataisymus, kurie lieka susieti su pradiniu sandoriu, kad grąžinimai, kreditiniai dokumentai ir nuolaidos būtų atsekami per deklaracijos patikslinimą.

Jei paslaugų teikėjas negali parodyti, kaip kiekvienas iš šių punktų yra saugomas ir eksportuojamas, vertinkite šią spragą kaip realią išlaidą, o ne kaip smulkmeną.

Atrankos kriterijai, keičiantys sprendimą

Kriterijus Ką patikrinti Kodėl tai svarbu
Apskaitos gylis Nekeičiamoji didžioji knyga, buhalteriniai įrašai, sąskaitų planas, laikotarpių užrakinimas, išmokų suderinimas Vien mokesčių varikliukas neužtikrina patikimų finansinių ataskaitų
PVM skaičiavimas Šalis, kliento tipas, prekės kategorija, teikimo vieta, lengvatos, atvirkštinis PVM apmokestinimas, kainos su PVM Standartinių tarifų paieška neveikia esant mišrioms prekėms, B2B ir prekyviečių srautams
Vietos įrodymai Sąskaitos faktūros išrašymo, pristatymo, IP, banko signalų ir priimto sprendimo saugojimas Apmokestinimas dažnai priklauso nuo įrodymų, o ne nuo vienos šalies reikšmės
VIES darbo procesas Užklausų ID, laiko žymos (timestamps), spartinančioji atmintis (caching), pakartotinių bandymų valdymas, peržiūros eilės VIES gali būti nepasiekiamas; apmokėjimas negali priklausyti nuo vieno sinchroninio kreipinio
OSS / IOSS Grupavimas, ES ir ne ES OSS, pataisymai, audito eksportai Teiginys „palaiko OSS“ gali reikšti tik ataskaitą arba visiškai valdomą deklaravimą
Prekyvietės taisyklės Numatomo tiekėjo (deemed-supplier) logika, pardavėjų PVM kodai, komisinių apmokestinimas, atskaitomybė pardavėjo lygiu Platformos prisiemės atsakomybę, kurios įprasti atsiskaitymai niekada nemato
Audituojamumas Nekeičiami įrašai, laikotarpių užraktai, pirminiai dokumentai, mokesčių sprendimų paaiškinimai, eksporto formatai Institucijos gali paprašyti įrašų po kelerių metų
Integracija REST, demonstraciniai pranešimai (webhooks), SDK, idemponentiškumas, bandomoji aplinka (sandbox), versijų kūrimas, įvykių pakartojimas Silpna mechanika sukuria dubliuotus arba nesuderintus mokesčių įrašus
Komercinis modelis Pagal skaičiavimą, sandorį, deklaraciją, paskyrą arba pagal individualų pasiūlymą Kaina smarkiai keičiasi priklausomai nuo apimčių ir jurisdikcijų
Duomenų perkeliamumas Didžiosios knygos, sąskaitų faktūrų, mokesčių įrodymų, PVM kodų, deklaravimo istorijos eksportas Keičiant paslaugų teikėją, kai jis yra jūsų apskaitos sistema, kaštai yra dideli
Branda Prieinamumas, paslaugų lygio sutartis (SLA), palaikymas, pavyzdiniai klientai Ankstyvosios prieigos produktas gali būti patrauklus, bet nepatvirtintas deklaravimui kritiniuose darbuose

Du iš šių kriterijų yra nuvertinami. Idemponentiškumo palaikymas svarbesnis, nei komandos tikisi, nes pakartotas tinklo kreipinys, sukuriantis dubliuotą PVM įrašą, tyliai sugadina deklaraciją. „Nordlet“ priima Idempotency-Key antraštę kiekviename duomenis keičiančiame kreipinyje, todėl pakartota užklausa niekada negali sukurti dublikato – tai būtent tokio tipo techninė detalė, kuri skiria apskaitos serverio programinę įrangą nuo tarifų API. Antrasis svarbus dalykas yra laikotarpių užrakinimas: uždaryti mėnesiai neturi būti tyliai perrašomi, o pataisymai turi sukurti atsekamus koregavimo įrašus, o ne paprastus pakeitimus.

Kvalifikuotų kandidatų palyginimas

Dauguma įrankių, kurie pasirodo ieškant PVM sprendimų, nėra to paties tipo produktai. Štai kur yra pagrindiniai kandidatai ir kur kiekvienas iš jų labiausiai tinka.

Kandidatas Kategorija Vieša kainodara Geriausiai tinka
Nordlet API pirmumo principu veikianti debesijos apskaita su integruotu ES PVM Vieša: planai nuo 10 €/mėn., apmokestinimas pagal API užklausų skaičių, visi moduliai kiekviename plane; ankstyvoji prieiga, bandomieji partneriai Platformoms ir prekyvietėms, kurioms savo produkto viduje reikia apskaitos knygų, išmokų ir PVM
Stripe Tax Mokesčių skaičiavimas, surinkimas ir pasirinktinai valdomas deklaravimas per „Stripe“ Vieša: 0,04 € už skaičiavimo API užklausą ir 0,45 € už sandorį, kai registruota rinkti; „Tax Complete“ planai nuo 80 iki 1 400 €/mėn. „Stripe“ pagrindu veikiančioms įmonėms, kurioms reikia greito mokesčių skaičiavimo
Quaderno Mokesčių automatizavimas, reikalavimus atitinkančios sąskaitos faktūros ir ataskaitos Vieša: nuo 29 $/mėn. (25 sandoriai) iki 149 $/mėn. (2 500); įmonėms – individuali kaina Mažesniems skaitmeniniams ir kelių kanalų pardavėjams, kuriems reikia mokesčius suprantančių sąskaitų
Avalara Platus netiesioginių mokesčių variklis ir atitikties paslaugos Pagal individualų pasiūlymą Įmonėms, kurioms reikia plataus padengimo ir ERP integracijų
Vertex Įmonių lygio mokesčių variklis su prekyvietės atsakomybės modeliavimu Neskelbiama Daugelio pardavėjų prekyvietėms, kuriose pardavėjo ir platformos atsakomybės klausimas yra pagrindinis
Sovos Valdoma PVM atitiktis ir reguliavimo paslaugos Individuali Įmonėms, norinčioms mastu valdomos registracijos ir deklaravimo

Kainos nurodytos tokios, kokios jos pateikiamos kiekvieno paslaugų teikėjo viešajame kainodaros puslapyje straipsnio rašymo metu, ir gali keistis be atskiro įspėjimo; patvirtinkite jas prieš planuodami biudžetą.

Keletas kompromisų nusipelno ypatingo dėmesio.

„Nordlet“ palyginti su įrankiais, skirtais tik mokesčiams. Skirtumas tas, kad „Nordlet“ nesiūlo apskaičiuoti PVM šalia jūsų apskaitos knygų. Ji ir yra jūsų apskaitos knygos. Kai pati platforma turi valdyti apskaitos duomenų modelį, įskaitant išmokas ir audito sekas, tai yra teisinga forma. Sąžiningas kompromisas yra branda: produktas yra ankstyvosios prieigos stadijoje, ir nors OSS bei IOSS deklaracijos apskaičiuojamos iš jūsų sąskaitų faktūrų su ankstesnių laikotarpių pataisymais, vietinių deklaracijų paketai šiandien teikiami trims šalims – Lietuvai (FR0600), Vokietijai (UStVA) ir Lenkijai (JPK_V7M) – ir jokia deklaracija nėra pateikiama institucijai jūsų vardu. Rimtas pirkėjas turėtų tiesiogiai patvirtinti šalių padengimą ir deklaravimo darbo procesą, o ne daryti prielaidas.

„Stripe Tax“ palyginti su „Quaderno“. „Stripe Tax“ turi aiškiausią viešąją API kainodarą iš visos grupės ir puikiai tinka, jei jau naudojatės „Stripe“ atsiskaitymo ir mokėjimų sistema. Jos operacijų API fiksuoja mokesčių operacijas, o ne bendruosius apskaitos žurnalus. „Quaderno“ labiau orientuota į pardavimo platformas, siūlo skaidrius mėnesinius planus ir lankstų API pardavimo duomenims perduoti, nors viešoji medžiaga specialiai nepatvirtina OSS/IOSS palaikymo ar didžiosios knygos. Nė vienas iš jų neturėtų būti pristatomas kaip dvejybinio įrašo apskaitos knygų pakaitalas.

„Avalara“, „Vertex“ ir „Sovos“. Tai sprendimai didelėms įmonėms. „Avalara“ turi didžiausią netiesioginių mokesčių aprėptį, tačiau reikalauja pardavimų proceso poreikiams apibrėžti. „Vertex“ išsiskiria prekyvietėms, nes jose aiškiai modeliuojami trijų šalių sandoriai ir nustatoma, kuri šalis yra atsakinga. „Sovos“ stipriausia ten, kur valdoma registracija, deklaravimas ir reguliavimo palaikymas nusveria integruotą apskaitą. Nė vienas iš jų nėra dokumentuotas kaip bendrosios knygos API.

Platformai, kurios pagrindinis reikalavimas yra integruotos, auditui paruoštos knygos su tuo pačiu įrašu užregistruotu PVM, „Nordlet“ yra tinkamiausias pasirinkimas tarp šių variantų, su išlyga, kad jos pasirengimas gamybinei veiklai yra tai, ką reikia išbandyti, o ne jos architektūra.

Klausimas dėl 2027–2030 metų, kurį dauguma pirkėjų praleidžia

Pasirinkti PVM įrankį 2026 metais remiantis tik šiandienos taisyklėmis yra trumparegiška. ES PVM skaitmeniniame amžiuje (ViDA) paketas buvo priimtas 2025 m. kovo mėn. ir įgyvendinamas etapais.

  • Nuo 2027 m. sausio 1 d. keičiasi OSS ir IOSS, įskaitant naują koregavimo mechanizmą, papildomą IOSS informaciją ir mėnesines IOSS ataskaitas pagal vartojimo valstybę narę.
  • Nuo 2028 m. liepos 1 d. plečiasi platformų taisyklės ir prasideda privalomas atvirkštinis PVM apmokestinimas tam tikriems neidentifikuotiems tiekėjams.
  • Nuo 2030 m. liepos 1 d. tarpvalstybinių B2B sandorių skaitmeninis ataskaitų teikimas pereina prie e. sąskaitų faktūrų išrašymo.
  • Vidaus realiojo laiko ataskaitų teikimo sistemos susiderina iki 2035 m. sausio 1 d.

Praktinis testas yra ne tai, ar API šiandien teisingai apskaičiuoja PVM. Svarbu, ar jos duomenų modelis gali išsaugoti pradinį sandorį, mokesčio sprendimą, sąskaitą faktūrą, pataisymą, pardavėjo tapatybę ir įrodymus tokia forma, kuri maitins e. sąskaitas faktūras ir skaitmenines ataskaitas, kai tie reikalavimai įsigalios. Nekeičiamoji didžioji knyga su struktūrizuotais sąskaitų faktūrų metaduomenimis, galinti išrašytas sąskaitas faktūras atvaizduoti kaip EN 16931 UBL formatu skirtą „Peppol“, yra kur kas geresnėje pozicijoje tam nei būsenos neturintis (stateless) tarifų galinis punktas.

Ką išbandytume prieš ką nors pasirašydami

  1. Apibrėžkite sistemos ribas. Nuspręskite, ar paslaugų teikėjas yra jūsų apskaitos sistema, mokesčių sprendimų variklis, deklaravimo paslauga, ar tik viena iš dalių. Užsirašykite tai.
  2. Sumodeliuokite realius sandorius prieš lygindami kainas. Paleiskite vidaus B2C, ES vidaus B2C, ES vidaus B2B su galiojančiu PVM kodu, netinkamu arba nepasiekiamu VIES, prekyvietės numatomo tiekėjo (deemed-supplier) pardavimus, grąžinimus, nuolaidas ir mišrius tarifus.
  3. Reikalaukite mokesčio sprendimo paaiškinimo. Atsakymas turi parodyti, kodėl buvo pasirinktas tarifas, jurisdikcija, lengvata, atvirkštinis PVM arba atsakinga šalis.
  4. Specialiai sutrikdykite VIES veiklą. Patvirtinkite laiko žymas, užklausų identifikatorius, pakartotinių bandymų logiką, talpykloje išsaugotus rezultatus ir rankinio peržiūros kelio veikimą.
  5. Patikrinkite eksportus, o ne valdymo skydelį. Paprašykite OSS pavyzdžių, PVM deklaracijų, sąskaitų faktūrų, žurnalų ir audito failų.
  6. Išbandykite nekeičiamumą. Pabandykite perrašyti uždarą laikotarpį. Sistema turi atsisakyti ir priversti sukurti atsekamą koregavimą.
  7. Atskirkite skaičiavimo kainodarą nuo atitikties kainodaros. Sužinokite visą API užklausų, sandorių, registracijų, deklaracijų, saugojimo, palaikymo ir papildomų jurisdikcijų kainą.
  8. Patvirtinkite platformos ekonomiką. Prekyvietei sumodeliuokite kaštus vienam pardavėjui, sandoriui ir aktyviai paskyrai, o ne prekybininko prenumeratos antraštę.
  9. Patvirtinkite pasirengimą gamybai. SLA, užklausų limitus, demonstracinius pranešimus (webhooks), idemponentiškumą, bandomosios aplinkos atitikimą, duomenų lokaciją ir eksporto teises.
  10. Įvertinkite suderinamumą ateityje. Aiškiai pasverkite 2027 m. OSS pakeitimus, 2028 m. platformos taisykles ir 2030 m. tarpvalstybines ataskaitas.

Didžiąją dalį šio sąrašo galima išbandyti su bandomąja įmone („sandbox company“) per popietę; ES PVM variklio vadove dokumentuojama, kuriuos prekių tiekimo vietos, atvirkštinio PVM apmokestinimo, numatomo tiekėjo ir OSS/IOSS atvejus „Nordlet“ išsprendžia ir kur suveikia jos įspėjimai.

D.U.K.

Ar PVM API yra tas pats, kas apskaitos API?

Ne. PVM API apskaičiuoja arba deklaruoja mokesčius. Apskaitos API tvarko dvejybinio įrašo knygas ir saugo PVM kaip vieną iš užregistruoto sandorio atributų. Jei jūsų platforma turi būti apskaitos sistema, įrankis, skirtas tik PVM, palieka jus tvarkant didžiąją knygą kitoje vietoje ir derinant du šaltinius.

Ar galiu pasikliauti VIES tikrojo laiko B2B patvirtinimui atsiskaitymo metu?

Ne kaip vienintele sinchronine priklausomybe. VIES tikrina nacionalines duomenų bazes ir gali būti laikinai nepasiekiamas, galiojantis numeris gali neatsirasti, jei verslas nėra registruotas prekybai ES viduje, o praeities galiojimas vėliau negali būti patvirtintas. Aplink jį sukurkite spartinančiąją atmintį (caching), pakartotinius bandymus, laiko žymas, užklausų ID ir rankinio peržiūros eilę.

Ar „palaiko OSS“ reiškia, kad paslaugų teikėjas pateikia mano deklaracijas?

Retai, ir niekada neturėtumėte tuo vadovautis kaip savaime suprantamu dalyku. Tai gali reikšti ataskaitą, skaičiavimą, pagalbą registruojantis arba visiškai valdomą pateikimą. Paklauskite, kurios šalys ir deklaracijos yra padengtos, kas jas teikia ir kaip tvarkomi pataisymai.

Kodėl „Nordlet“ atsiranda šiame palyginime, jei ji vis dar yra ankstyvosios prieigos stadijoje?

Nes ji geriausiai tinka platformoms, kurioms viename produkte reikia integruotų apskaitos knygų, išmokų, didžiosios knygos vientisumo ir PVM metaduomenų, ko dauguma tik mokesčiams skirtų API nesuteikia. Ankstyvoji prieiga yra reali gamybos terminų ir šalių padengimo riba, todėl prieinamumą ir deklaravimo darbo procesą vertinkite kaip tikrinimo klausimus, o ne kaip nusistovėjusius faktus.

Kokia viena klaida vėliau sukelia daugiausia problemų dėl PVM?

Mokesčio sprendimo pagrindą sudarančių įrodymų nesaugojimas. 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 išmeta vietos įrodymus, VIES rezultatą ir sandorio ryšį, audito metu bus atmestas, net jei kiekvienas skaičiavimas buvo teisingas.

Papildoma literatūra