Nē. Šī pārpratuma sakne ir tur, kur divus atšķirīgus pienākumus sajauc kopā. No 2028. gada 1. janvāra ikvienam Latvijā reģistrētam uzņēmumam, kas izraksta rēķinu citam uzņēmumam apmaksai, jāsagatavo strukturēts e-rēķins un jānodod tā dati Valsts ieņēmumu dienestam (VID). Pienākums izriet no Grāmatvedības likuma, kura sākotnējais termiņš tika pārcelts no 2026. gada uz 2028. gadu. Bet tieša pieslēgšanās VID API (application programming interface, proti, saskarnei, kas ļauj divām programmatūras sistēmām automātiski apmainīties ar datiem) ir tikai viens no trim atļautajiem kanāliem, ko paredz Ministru kabineta 2025. gada 9. decembra noteikumi Nr. 749. Līdzās tai ir atļauta arī e-adrese un operatora kanāls. Laika periods no 2026. līdz 2027. gadam praksē ir brīvprātīgs testēšanas logs, ne vēl spēkā esošs pienākums.
Vai 2028. gadā ikviens e-rēķins jāsūta tieši caur VID API?
Šeit rodas lielākā daļa neskaidrību. Likums uzliek divus pienākumus vienlaikus: uzņēmumam jāsagatavo rēķins kā strukturēts e-rēķins, un tā dati jānodod VID. Neviena no šīm prasībām neprecizē, kā tieši šī datu plūsma tehniski notiek. Šo jautājumu risina MK noteikumi Nr. 749, kur ir aprakstīti trīs atļautie ceļi. Tiešs API saslēgums patiesībā ir nepieciešams tikai mazākajai daļai uzņēmumu, jo e-adrese un operatora kanāls šo darbu paveic to vietā automātiski.
Uz ko attiecas pienākums no 2028. gada 1. janvāra?
Pienākums attiecas uz visiem Grāmatvedības likumā nosauktajiem subjektiem: Latvijā reģistrētām komercsabiedrībām, ārvalstu uzņēmumu filiālēm Latvijā un nerezidenta pastāvīgajai pārstāvniecībai, kā arī fiziskajām personām, kas veic saimniecisko darbību. Likums nenosaka apgrozījuma, rēķina summas vai PVN maksātāja statusa slieksni, tāpēc pienākums attiecas gan uz vienpersonas uzņēmumu, gan lielu koncernu vienādi.
Pienākums gulstas uz izrakstītāju: jūsu uzņēmumam jāsagatavo strukturēti rēķini, kas adresēti citam Latvijas uzņēmumam, un jānodod to dati VID, neatkarīgi no tā, vai rēķina saņēmējs pats šim solim ir gatavs. Izņēmumi ir nedaudzi: tie attiecas uz darījumiem, kas dokumentēti ar sertificētu kases aparātu, uz Nacionālā veselības dienesta un Nodarbinātības valsts aģentūras sistēmās veidotiem rēķiniem, kā arī uz noteiktām drošības un tiesībsardzības iestādēm.
Vai dati pircējam un VID jāsūta pa vienu un to pašu ceļu?
Šeit ir otrs punkts, ko vērts turēt atsevišķi. Kanāls, pa kuru rēķins nonāk pie darījuma partnera, un kanāls, pa kuru dati nonāk VID, nav obligāti viens un tas pats. MK noteikumi Nr. 749 ļauj partneriem vienoties par vienu vai vairākiem piegādes kanāliem: oficiālo e-adresi, operatora kanālu vai citu abpusēji saskaņotu ceļu, piemēram, sistēmu integrāciju vai e-pastu.
Datu iesniegšanai VID ir trīs konkrēti ceļi: oficiālā e-adrese, kuras informācijas sistēma e-rēķina paziņojumu VID nosūta automātiski; operatora kanāls, kas ir integrēts VID sistēmas API; vai VID pašas EDS API (Elektroniskās deklarēšanas sistēmas saskarne) vai failu augšupielādes funkcija. Ja izmantojat e-adresi vai operatoru, jūsu pašu sistēmai ar API vispār nav jāsazinās, jo šo darbu izpilda starpnieks. VID savā biežāk uzdoto jautājumu sadaļā apstiprina, ka no grāmatvedības programmatūras XML formāta e-rēķina failu var pārsūtīt VID arī tiešā veidā – tas ir trešais variants blakus pirmajiem diviem, ne vienīgais ceļš.
Kas jāzina, izvēloties tiešo E-Invoice API V2 saslēgumu?
Ja izvēlaties tiešo saslēgumu, piemēram, tāpēc, ka rēķinu apjomi ir lieli un vēlaties procesu automatizēt pilnībā, VID šim mērķim izmanto E-Invoice API V2 pakalpojumu. Pirms izstrādātāji var sākt darbu, jāizpilda vairāki soļi:
- sagatavot rēķinu, kas atbilst strukturēta e-rēķina XML formātam;
- vienoties ar darījuma partneri par kanālu, pa kuru rēķins nonāks pie viņa – tas var atšķirties no ceļa, pa kuru dati nonāk VID;
- EDS izveidot API sertifikātu vai API atslēgu (piekļuves atslēgu) ar Dokumentu API tiesībām;
- integrēt grāmatvedības vai uzņēmuma resursu vadības sistēmu ar VID API, izmantojot OpenAPI 3.0 un Swagger komponentus; parasti to dara programmatūras izstrādātājs, nevis grāmatvedis;
- nosūtīt VID rēķina kopiju pa noteikto kanālu un žurnalēt nosūtīšanas rezultātu, lai vēlākas domstarpības gadījumā būtu pierādāms, kad un kā rēķins bija iesniegts.
Vienu detaļu izstrādātāji viegli aizmirst: API atslēga ir spēkā maksimāli 90 dienas, pēc tam tā jāgenerē no jauna. Viena e-rēķina maksimāli atļautais izmērs ir 20 MB.
Kāds ir strukturēta e-rēķina tehniskais minimums: XML, UBL 2.1 un PEPPOL BIS Billing 3.0?
Strukturēts e-rēķins nav PDF, kaut arī tie var vizuāli izskatīties līdzīgi. Likuma nozīmē strukturēts e-rēķins ir tāds, ko dators var automātiski nolasīt un apstrādāt bez cilvēka iejaukšanās. Failu formāts ir XML (Extensible Markup Language, proti, izplešama marķēšanas valoda), kas atbilst standartam LVS EN 16931-1:2017 un tehniskajai specifikācijai LVS CEN/TS 16931-2:2017. VID datus pieņem tādā veidā, kur XML struktūra atbilst UBL 2.1 (Universal Business Language) un PEPPOL BIS Billing 3.0 satura izmantošanas specifikācijai (CIUS, proti, Core Invoice Usage Specification). Peppol tīkla lietošana pati par sevi nav obligāta. Obligāts ir tas, ka failu struktūra atbilst tai pašai specifikācijai, ko izmanto Peppol. Ja šobrīd partnerim sūtāt PDF rēķinu, tas 2028. gadā automātiski neatbildīs prasībām. Vajadzīgs atsevišķs XML fails, kas atbilst datu modelim, pat ja tam līdzi nāk cilvēkam lasāms PDF.
Vai e-rēķina iesniegšana VID notiek reālajā laikā?
E-rēķins VID jāiesniedz vienreiz, ne vēlāk kā piecu darba dienu laikā pēc tā nosūtīšanas dienas. Tas ir iesniegums pēc fakta, ne reāllaika ziņošana.
Ja uzņēmuma vai operatora informācijas sistēmā rodas kļūme, par to jāpaziņo EDS ne vēlāk kā nākamajā darba dienā pēc termiņa iestāšanās, un rēķins iesniedzams triju darba dienu laikā pēc kļūmes novēršanas. Ja kavēšanās iemesls ir citāds, tas tāpat jāpaziņo EDS, un rēķins iesniedzams 30 kalendāra dienu laikā no iemesla konstatēšanas.
Sankcija, kas paredzēta par attaisnojuma dokumentu sagatavošanas, reģistrēšanas vai lietošanas prasību pārkāpšanu, ir brīdinājums vai naudas sods līdz 86 naudas soda vienībām. Atsevišķu, tikai uz API balstītu sodu likums neparedz.
Ko darīt līdz 2027. gada 31. decembrim?
Periods no 2026. gada 1. janvāra līdz 2027. gada 31. decembrim ir paredzēts brīvprātīgai testēšanai. MK noteikumi Nr. 749 ļauj nebudžeta uzņēmumiem datus VID iesniegt jau tagad, neradot no tā pienākumu. Šo laiku vērts izmantot lietderīgi:
- pārbaudiet XML formāta rēķinus ar Eiropas Komisijas e-rēķinu validācijas rīku, pirms tos sūtāt VID;
- testējiet izvēlēto piegādes ceļu (e-adresi, operatoru vai tiešo saslēgumu) ar reāliem darījumiem, ne tikai ar testa datiem;
- piešķiriet EDS tiesības darbiniekiem, kuri turpmāk iesniegs e-rēķinus vai risinās kļūmes;
- aprakstiet iepriekš, kā rīkosities sistēmas kļūmes gadījumā, lai piecu darba dienu noteikums nebūtu pārsteigums;
- atjauniniet klientu pamatdatus un rēķinu plūsmas procesus, jo 2028. gadā katram Latvijas biznesa klientam strukturētam e-rēķinam jābūt gatavam, ne vēl izstrādes stadijā.
Kas 2028. aastal peab iga e-arve minema VID API kaudu?
Ei. Seadus nõuab struktureeritud e-arve vormistamist ja andmete edastamist VID-ile, kuid MK määrus nr 749 lubab kolme kanalit: ametlik e-adress, operaatori kanal või otsene API. Enamik ettevõtteid saab kasutada e-adressi või operaatorit, mis edastavad andmed automaatselt.
Keda kohustus alates 1. jaanuarist 2028 puudutab?
Kohustus laieneb kõigile Läti registreeritud äriühingutele, filiaalidele, püsivatele tegevuskohtadele ja majandustegevusega tegelevatele füüsilistele isikutele. Käibe- või summakünnist pole – kohustus kehtib ühtviisi nii ühemeheettevõttele kui suurkontsernile.
Kas arve saajale ja VID-ile andmed peavad liikuma sama teed?
Ei. Kanal, mille kaudu arve jõuab kaubanduspartnerini, ja kanal VID-i andmete edastamiseks võivad olla erinevad. Partnerid võivad kokku leppida ühes või mitmes tarnekanalis, samas kui VID-ile esitamiseks on kolm eraldi võimalust.
Mida eeldab E-Invoice API V2 otseliides?
Otseliides nõuab API sertifikaadi või võtme loomist EDS-is, raamatupidamistarkvara liidestamist VID API-ga (OpenAPI 3.0) ja arve XML-vormingus saatmist. API võti kehtib maksimaalselt 90 päeva ja ühe e-arve maksimaalne suurus on 20 MB.