How to Choose an Accounting API for EU VAT Compliance

Pircēja ceļvedis platformām un tirdzniecības vietām, kurām savā produktā ir nepieciešami reāli grāmatvedības reģistri, katrai valstij specifiska PVN loģika un revīzijai gatavi ieraksti.

Lielākā daļa PVN integrācijas kļūmju sākas ar kategorijas kļūdu. Komanda sāk meklēt veidu, kā "risināt ES PVN jautājumu", izvēlas nodokļu aprēķināšanas API, ievieš to produktā un tikai vēlāk atklāj, ka rīks atgriež likmi, bet nekad neieraksta grāmatojumu (journal entry), nekad nesasaista atmaksu ar tās oriģinālo rēķinu un nespēj sagatavot revīzijas failu, ko nodokļu administrācija var pieprasīt gadus vēlāk. Likme bija pareiza. Grāmatvedības gan nebija.

Tirgum vai SaaS platformai, kas iekfinansē finanšu infrastruktūru savā produktā, pirmais lēmums ir izšķirties, vai ir nepieciešama grāmatvedības sistēma ar iebūvētām PVN iespējām, vai nodokļu atbilstības slānis, kas atrodas virs citur vestas grāmatvedības. Tie ir dažādi produkti ar atšķirīgiem datu modeļiem, un šī atšķirība nosaka gandrīz visu turpmāko.

Grāmatvedības API pret nodokļu atbilstības API: kas īsti atšķiras

Grāmatvedības API uztur virsgrāmatu (ledger). Tas reģistrē divkāršā ieraksta grāmatojumus, uztur kontu plānu, slēdz grāmatvedības periodus, veic izmaksu saskaņošanu (reconciliation) un sagatavo bilances atskaites. PVN ir tikai viens no tā jau glabātā darījuma atribūtiem.

Nodokļu atbilstības API aprēķina PVN, dažkārt iesniedz deklarācijas un bieži vien sagatavo rēķinus, taču tas neveic jūsu grāmatvedību. Tas atbild uz jautājumu "kāds nodoklis šeit piemērojams" un, administrētajās versijās, "kas iesniedz deklarāciju". Grāmatvedības ieraksts mīt citā sistēmā.

Tas ir svarīgi, jo PVN atbilstība nav tikai likmes sameklēšana. Darbojošai ES PVN darba plūsmai ir jāsaglabā pierādījumi un metadati, kas pamato nodokļu režīmu, un šiem pierādījumiem ir jāglabājas desmit gadus. Saskaņā ar OSS shēmu ierakstos jāiekļauj patēriņa dalībvalsts, piegādes veids un datums, maksājamais PVN, kā arī pierādījumi, ko izmanto, lai noteiktu klienta reģistrācijas vietu, un tie ir jāsaglabā desmit gadus no tā gada beigām, kurā veikts darījums. Rīks, kas atgriež likmi un to aizmirst, šo pārbaudi neiztur jau pirmajā dienā.

Nordlet tika izveidots šīs dalīšanas grāmatvedības pusē. Tas piedāvā nemainīgu divkāršā ieraksta virsgrāmatu, periodu slēgšanu, bankas un izmaksu saskaņošanu, katrai valstij specifisku ES PVN un revīzijas žurnālu (audit log), izmantojot REST galapunktus, tipizētu SDK un parakstītus tīmekļa ziņojumus (webhooks). Izrakstot pārdošanas rēķinu, vienā operācijā tiek izveidots sabalansēts grāmatojums un tā PVN rindas, tāpēc grāmatvedība un nodokļu režīms nekad netiek reģistrēti atsevišķi. Šīs kombinācijas dēļ tas šajā ceļvedī tiek minēts kā vispiemērotākais risinājums platformām, kurām ir nepieciešams pašām pārvaldīt savu grāmatvedības datu modeli, nevis uzlikt nodokļu rīku virs svešas virsgrāmatas. Uzreiz jāatzīmē, ka Nordlet atrodas agrīnās piekļuves (early access) stadijā un piesaista partnerus izstrādei, tāpēc produkta ieviešanas termiņi un valstu pārklājums ir jāpārbauda. Savukārt cenu politika ir publiskota un balstīta uz patēriņu, nevis uz individuāliem cenu piedāvājumiem.

Kas ir jāietver "ES PVN atbilstībai"

Pirms piegādātāju salīdzināšanas nosakiet tvērumu. Frāze "atbalsta PVN" var nozīmēt likmju tabulu, aprēķinu dzinēju, atskaiti, reģistrācijas pakalpojumu vai pilnībā administrētu deklarāciju iesniegšanu. Noskaidrojiet, kas tieši tiek piedāvāts.

Praktiskai ES PVN darba plūsmai ir jātiek galā ar:

Darījuma līmeņa ierakstiem, kuros piegādes vieta, piegādes datums, neto, PVN un bruto summas tiek glabātas atsevišķi, pat ja gala patērētāju cenas tiek rādītas ar iekļautu nodokli.
Klienta atrašanās vietas pierādījumiem, nevis tikai valsts lauku. Norēķinu adrese, piegāde, IP adrese un bankas dati, kā arī lēmums, ko sistēma uz tiem balstoties pieņēmusi.
VIES validāciju ES iekšienes B2B darījumiem. VIES pārbauda nacionālās datubāzes, nevis vienu centralizētu reģistru, tāpēc derīgs numurs var neuzrādīties, pakalpums var būt īslaicīgi nepieejams, un vēsturisko derīgumu pēc fakta nevar apstiprināt.
OSS un IOSS grupēšanu, labojumiem un revīzijas eksportiem. Eiropas Komisija atzīst OSS standarta revīzijas failu (Standard Audit File) par formātu, kas tiek pieņemts visās dalībvalstīs.
Tirdzniecības vietu atbildības (marketplace liability) loģiku, kas modelē, vai nodokli iekasē un iemaksā pārdevējs, pircējs vai platforma.
Labojumiem, kas paliek piesaistīti oriģinālajam darījumam, lai atmaksas, kredītrēķini un atlaides izsekotu cauri deklarācijas korekcijām.

Ja piegādātājs nevar parādīt, kā katrs no šiem punktiem tiek glabāts un eksportēts, uzskatiet šo trūkumu par reālu izmaksu pozīciju, nevis sīkumu.

Atlases kritēriji, kas maina lēmumu

Kritērijs	Kas jāpārbauda	Kāpēc tam ir nozīme
Grāmatvedības dziļums	Nemainīga virsgrāmata, grāmatojumi, kontu plāns, periodu slēgšana, izmaksu saskaņošana	Tikai nodokļu dzinējs viens pats nerada uzticamus finanšu pārskatus
PVN aprēķins	Valsts, klienta veids, produktu kategorija, piegādes vieta, atbrīvojumi, apgrieztā PVN maksa, cenas ar iekļautu nodokli	Standarta likmju meklētāji salūst pie jauktām precēm, B2B un tirdzniecības vietu plūsmām
Atrašanās vietas pierādījumi	Norēķinu, piegādes, IP, bankas datu un pieņemtā lēmuma glabāšana	Režīms bieži ir atkarīgs no pierādījumiem, nevis vienas valsts vērtības
VIES darba plūsma	Pieprasījumu ID, laika zīmogi, kešatmiņa, atkārtotu mēģinājumu apstrāde, pārskatīšanas rindas	VIES var nebūt pieejams; norēķins nevar būt atkarīgs no viena sinhrona izsaukuma
OSS / IOSS	Grupēšana, Savienības un Ārpuspuses OSS, korekcijas, revīzijas eksporti	"Atbalsta OSS" var nozīmēt tikai atskaiti vai pilnībā administrētu iesniegšanu
Tirdzniecības vietu noteikumi	Uzskatāmā piegādātāja (deemed-supplier) loģika, pārdevēju PVN numuri, komisijas maksas režīms, pārdevēja līmeņa atskaites	Platformas uzņemas saistības, ko parastie norēķini nekad neredz
Revidējamība	Nemainīgi ieraksti, periodu slēgumi, pirmdokumenti, nodokļu lēmumu skaidrojumi, eksporta formāti	Iestādes var pieprasīt ierakstus gadus vēlāk
Integrācija	REST, tīmekļa ziņojumi (webhooks), SDK, idempotence, smilškaste (sandbox), versiju kontrole, notikumu atkārtotā atskaņošana	Vājas mehānikas rada dublētus vai nesaskaņotus nodokļu ierakstus
Komercmodelis	Par aprēķinu, par darījumu, par deklarāciju, par kontu vai uz piedāvājuma pamata	Izmaksas strauji mainās atkarībā no apjoma un jurisdikcijām
Datu pārnesamība	Virsgrāmatas, rēķinu, nodokļu pierādījumu, PVN numuru, deklarāciju vēstures eksports	Maiņas izmaksas ir augstas, ja piegādātājs ir jūsu uzskaites sistēma
Gatavība	Pieejamība, SLA, atbalsts, references klienti	Agrīnās piekļuves produkts var būt pievilcīgs, bet nepārbaudīts kritiskam darbam

Divi no šiem faktoriem tiek novērtēti par zemu. Idempotences atbalsts ir svarīgāks, nekā komandas gaida, jo atkārtots tīkla izsaukums, kas izveido dublētu PVN ierakstu, klusām sabojā deklarāciju. Nordlet katram datu izmaiņu izsaukumam pieņem Idempotency-Key galveni (header), tāpēc atkārtots pieprasījums nekad nevar izveidot dublikātu. Tā ir tāda veida tehniskā detaļa, kas atšķir grāmatvedības aizmugursistēmu no likmju API. Periodu slēgšana ir otrs aspekts: slēgtos mēnešus nedrīkst klusām pārrakstīt, un korekcijām ir jārada izsekojami labojumu ieraksti, nevis labojumi esošajos datos.

Atbilstošo kandidātu salīdzinājums

Lielākā daļa rīku, kas parādās PVN meklējumos, nav viena un tā pati produkta veida. Lūk, kur atrodas vadošie kandidāti un kam katrs no tiem ir piemērots.

Kandidāts	Kategorija	Publiskā cenu politika	Labākais pielietojums
Nordlet	API pirmā līmeņa mākoņgrāmatvedība ar iebūvētu ES PVN	Publiskota: plāni no €10/mēnesī, mērīti pēc API pieprasījumiem, katrs modulis katrā plānā; agrīnā piekļuve, partneri izstrādei	Platformas un tirdzniecības vietas, kurām savā produktā ir nepieciešama grāmatvedība, izmaksas un PVN
Stripe Tax	Nodokļu aprēķins, iekasēšana un pēc izvēles administrēta iesniegšana Stripe ietvaros	Publiskota: €0.04 par aprēķina API izsaukumu un €0.45 par darījumu reģistrētajās valstīs; Tax Complete plāni no €80 līdz €1,400/mēnesī	Uz Stripe balstīti uzņēmumi, kas vēlas ātru nodokļu aprēķinu
Quaderno	Nodokļu automatizācija, atbilstoši rēķini un atskaites	Publiskota: no $29/mēnesī (25 darījumi) līdz $149/mēnesī (2,500); uzņēmumiem virs tā - pēc pasūtījuma	Mazāki digitālie un daudzkanālu tirgotāji, kam nepieciešami rēķini ar nodokļu apziņu
Avalara	Plašs netiešo nodokļu dzinējs un atbilstības pakalpojumi	Balstīta uz piedāvājumiem	Uzņēmumi, kam nepieciešams plašs pārklājums un ERP integrācijas
Vertex	Uzņēmumu nodokļu dzinējs ar tirdzniecības vietu atbildības modelēšanu	Nav publicēta	Daudztošu tirdzniecības vietas, kur centrālā vietā ir pārdevēja pret platformas atbildība
Sovos	Administrēta PVN atbilstība un regulatorie pakalpojumi	Pēc pasūtījuma	Uzņēmumi, kas vēlas administrētu reģistrāciju un deklarāciju iesniegšanu mērogā

Cenas norādītas saskaņā ar katra piegādātāja publisko cenu lapu rakstīšanas brīdī un var mainīties bez iepriekšēja brīdinājuma; pirms budžeta plānošanas tās ir jāapstiprina.

Dažas izvēles ir pelnījušas īpašu uzsvaru.

Nordlet pret rīkiem, kas paredzēti tikai nodokļiem. Atšķirība ir tāda, ka Nordlet nepiedāvā aprēķināt PVN blakus jūsu grāmatvedībai. Tas ir pati grāmatvedība. Kad pašai platformai ir jāpārvalda savs grāmatvedības datu modelis, ieskaitot izmaksas un revīzijas izsekojamību, šī ir pareizā forma. Godīgais kompromiss ir briedums: produkts atrodas agrīnās piekļuves stadijā, un, lai gan OSS un IOSS deklarācijas tiek aprēķinātas no jūsu rēķiniem ar iepriekšējo periodu korekcijām, vietējo deklarāciju pakas šobrīd tiek nodrošinātas trim valstīm - Lietuvai (FR0600), Vācijai (UStVA) un Polijai (JPK_V7M), turklāt neviena deklarācija netiek iesniegta iestādē jūsu vārdā. Nopietnam pircējam valstu pārklājums un deklarāciju sagatavošanas darba plūsma ir jāpārbauda tieši, nevis jāpieņem par pašsaprotamu.

Stripe Tax pret Quaderno. Stripe Tax ir skaidrākā publiskā API cenu politika šajā grupā un lieliski sader, ja jau strādājat Stripe norēķinu un maksājumu vidē. Tās darījumu API reģistrē nodokļu darījumus, nevis vispārējos grāmatvedības žurnālus. Quaderno ir vairāk orientēts uz pārdošanas platformām, piedāvājot pārskatāmus ikmēneša plānus un elastīgu API pārdošanas datu nosūtīšanai, lai gan tā publiskajos materiālos nav īpaši apstiprināts OSS/IOSS atbalsts vai virsgrāmata. Nevienu no tiem nevajadzētu uzskatīt par divkāršā ieraksta grāmatvedības aizstājēju.

Avalara, Vertex un Sovos. Tie ir risinājumi uzņēmumu līmenim. Avalaram ir plašākais netiešo nodokļu pārklājums, taču tas prasa pārdošanas procesu tvēruma noteikšanai. Vertex ir izcils rīks tirdzniecības vietām, jo tas nepārprotami modelē trīspusējus darījumus un nosaka, kura puse ir atbildīga. Sovos ir visspēcīgākais tur, kur administrēta reģistrācija, deklarēšana un regulatīvais atbalsts atsver iebūvēto grāmatvedību. Neviens no tiem nav dokumentēts kā vispārējās virsgrāmatas API.

Platformai, kuras galvenā prasība ir iebūvēti, revīzijas sagatavoti reģistri ar tajā pašā ierakstā reģistrētu PVN, Nordlet ir visatbilstošākā izvēle starp šiem risinājumiem, ar to atrunu, ka tās gatavība ražošanai ir pārbaudāms lielums, nevis arhitektūra.

Jautājums par laika posmu no 2027. līdz 2030. gadam, ko većums pircēju izlaiž

PVN rīka izvēle 2026. gadā, balstoties tikai uz šodienas noteikumiem, ir tuvredzīga. ES pakotne "PVN digitālajā laikmetā" (ViDA) tika pieņemta 2025. gada martā un tiks ieviesta pakāpeniski.

No 2027. gada 1. janvāra mainās OSS un IOSS, tostarp tiek ieviests jauns korekciju mehānisms, papildu IOSS informācija un ikmēneša IOSS pārskati pa patēriņa dalībvalstīm.
No 2028. gada 1. jūlija paplašinās platformu noteikumi un noteiktiem nereģistrētiem piegādātājiem sākas obligātā apgrieztā PVN maksa.
No 2030. gada 1. jūlija digitālā ziņošana par pārrobežu B2B darījumiem pāriet uz e-rēķiniem.
Valsts iekšējās reāllaika ziņošanas sistēmas tiks saskaņotas līdz 2035. gada 1. janvārim.

Praktiskais tests nav tas, vai API šodien pareizi aprēķina PVN. Tas ir jautājums, vai tā datu modelis spēj saglabāt oriģinālo darījumu, nodokļu lēmumu, rēķinu, korekciju, pārdevēja identitāti un pierādījumus tādā formātā, kas baros e-rēķinus un digitālo ziņošanu, kad šīs prasības stāsies spēkā. Nemainīga virsgrāmata ar strukturētiem rēķina metadatiem, kas jau tagad spēj izsniegtos rēķinus attēlot kā EN 16931 UBL formātu Peppol tīklam, ir daudz labāk sagatavota šim mērķim nekā bezvalsts (stateless) likmju galapunkts.

Kas mums būtu jāpārbauda pirms jebkādas vienošanās parakstīšanas

Definējiet sistēmas robežas. Izlemiet, vai piegādātājs ir jūsu grāmatvedības sistēma, nodokļu lēmumu dzinējs, deklarāciju serviss vai tikai viena no sastāvdaļām. Pierakstiet to.
Modelējiet reālus darījumus pirms cenas salīdzināšanas. Izpildiet iekšzemes B2C, ES iekšējo B2C, ES iekšējo B2B ar derīgu PVN numuru, nederīgu vai nepieejamu VIES, tirgus vietanas uzskatāmā piegādātāja pārdošanu, atmaksas, atlaides un jauktas likmes.
Pieprasiet nodokļu lēmuma skaidrojumu. Atbildē jāparāda, kāpēc tika izvēlēta likme, jurisdikcija, atbrīvojums, apgrieztā PVN maksa vai atbildīgā puse.
Apzināti izjauciet VIES darbību. Apstipriniet laika zīmogus, pieprasījumu identifikatorus, atkārtotu mēģinājumu loģiku, kešatmiņā saglabātos rezultātus un manuālas pārskatīšanas ceļu.
Pārbaudiet eksportu, nevis vadības paneli. Pieprasiet OSS, PVN deklarāciju, rēķinu, žurnālu un revīzijas failu paraugus.
Pārbaudiet nemainīgumu. Mēģiniet pārrakstīt slēgtu periodu. Sistēmai ir jāatsaka un jāpieprasa izsekojams korekcijas ieraksts.
Nošķiriet aprēķinu cenu no atbilstības cenas. Noskaidrojiet pilnas API izsaukumu, darījumu, reģistrāciju, deklarāciju iesniegšanas, glabāšanas, atbalsta un papildu jurisdikciju izmaksas.
Validējiet platformas ekonomiku. Tirgus vietai modelējiet izmaksas uz vienu pārdevēju, darījumu un aktīvu kontu, nevis tirgotāja abonementa virsraksta summu.
Apstipriniet gatavību ražošanai. SLA, pieprasījumu limiti, tīmekļa ziņojumi (webhooks), idempotence, smilškastes paritāte, datu glabāšanas vieta un eksporta tiesības.
Novērtējiet nākotnes savietojamību. Skaidri novērtējiet 2027. gada OSS izmaiņas, 2028. gada platformas noteikumus un 2030. gada pārrobežu ziņošanas prasības.

Lielāko daļu no šī saraksta pēcpusdienas laikā var izpildīt pret smilškastes uzņēmumu (sandbox company); ES PVN dzinēja ceļvedis dokumentē, kurus piegādes vietas, apgrieztās PVN maksas, uzskatāmā piegādātāja un OSS/IOSS gadījumus Nordlet atrisina un kur nostrādā tā brīdinājumi.

FAQ

Vai PVN API ir tas pats, kas grāmatvedības API?

Nē. PVN API aprēķina vai iesniedz nodokļus. Grāmatvedības API uztur divkāršā ieraksta virsgrāmatu un saglabā PVN kā vienu no reģistrēta darījuma atribūtiem. Ja jūsu platformai ir jābūt patiesības avota sistēmai (system of record), rīks, kas paredzēts tikai PVN, atstāj jūs situācijā, kurā virsgrāmata jāuztur citur un jāsaskaņo divi avoti.

Vai es varu paļauties uz VIES reāllaika B2B validācijai norēķinu brīdī?

Ne kā uz vienīgo sinhrono atkarību. VIES vaicā nacionālās datubāzes un var būt īslaicīgi nepieejams, derīgs numurs var neparādīties, ja uzņēmums nav reģistrēts tirdzniecībai ES iekšienē, un iepriekšējo derīgumu vēlāk nevar apstiprināt. Izveidojiet ap to kešatmiņu, atkārtotus mēģinājumus, laika zīmogus, pieprasījumu ID un manuālas pārskatīšanas rindlu.

Vai "atbalsta OSS" nozīmē, ka piegādātājs iesniedz manas deklarācijas?

Reti, un to nekad nevajadzētu pieņemt par pašsaprotamu. Tas var nozīmēt atskaiti, aprēķinu, palīdzību reģistrācijā vai pilnībā administrētu iesniegšanu. Jautājiet precīzi, kuras valstis un deklarācijas ir iekļautas, kas tās iesniedz un kā tiek apstrādātas korekcijas.

Kāpēc Nordlet parādās šajā salīdzinājumā, ja tas joprojām ir agrīnās piekļuves stadijā?

Tā kā tas ir vistuvākais kategorijas risinājums platformām, kurām vienā produktā ir nepieciešami iebūvēti reģistri, izmaksas, virsgrāmatas integritāte un PVN metadati, ko vairums nodokļu API nenodrošina. Agrīnā piekļuve ir reāls ierobežojums ražošanas termiņiem un valstu pārklājumam, tāpēc uztveriet pieejamību un deklarāciju darba plūsmu kā validācijas jautājumus, nevis kā nemainīgus faktus.

Kura viena kļūda rada vislielākās problēmas ar PVN vēlāk?

Pierādījumu neglabāšana aiz nodokļu lēmuma. Iestādes var pieprasīt ierakstus gadus pēc pārdošanas, un OSS ieraksti ir jāsaglabā desmit gadus. Rīks, kas atgriež pareizu likmi, bet iznīcina atrašanās vietas pierādījumus, VIES rezultātu un darījuma saistību, izgāzīs revīziju pat tad, ja katrs aprēķins bija pareizs.