PEPPOL e-rēķins Latvijā: kas noiet greizi pirms sūtīšanas

Pirmajā strukturētajā e-rēķinā visbiežāk greizi noiet formāts un adrese, nevis summa. PDF fails e-pasta pielikumā Latvijā nav strukturēts e-rēķins. Vajadzīgs XML, proti, mašīnlasāms datu fails, kura struktūra atbilst PEPPOL BIS Billing 3.0 specifikācijai. Pirms nosūtīšanas rēķini parasti aizķeras pie sešām lietām: trūkst pircēja elektroniskās adreses vai tai nav shēmas identifikatora, trūkst pircēja atsauces vai pasūtījuma numura, nepareizs vai neesošs specifikācijas identifikators, PVN kategorija bez atbrīvojuma pamatojuma, kopsummas, kas nesaskan ar rindām un PVN, un trūkstošs maksājuma konts. Tie ir fatāli noteikumi. Rēķins nenonāk pie saņēmēja, bet atgriežas ar kļūdas ziņojumu. Tāpēc XML pirms sūtīšanas ir vērts pārbaudīt Eiropas Komisijas e-rēķinu validācijas rīkā.

Kam Latvijā e-rēķins patiesībā jāsūta?

Latvijā prasība ieviesta pakāpeniski, un tieši tur rodas neskaidrības. Pēc VID skaidrojuma strukturēti e-rēķini ir obligāti no 2025. gada 1. janvāra norēķinos starp valsts sektoru un Latvijā reģistrētiem uzņēmumiem, proti, G2G, B2G un G2B segmentā, kas nozīmē valsts ar valsti, uzņēmums ar valsti un valsts ar uzņēmumu. Grāmatvedības likums nosaka: rēķinu, ko uzņēmums iesniedz apmaksai citam Latvijā reģistrētam uzņēmumam, proti, preces vai pakalpojuma saņēmējam, sagatavo kā strukturētu e-rēķinu. Tas pats VID apskats 2026. gada 1. janvāri sasaista ar otru pienākumu: šajos pašos segmentos e-rēķina dati jānodod arī VID. Vietējais B2B seko tikai 2028. gada 1. janvārī, kad rēķini jāsagatavo kā e-rēķini un vienlaikus jāiesniedz VID. Laikā no 2026. gada 1. janvāra līdz 2027. gada 31. decembrim B2B datu iesniegšana ir brīvprātīga. 2026. gada janvāris tātad nepadarīja obligātus visus B2B rēķinus.

Kuri B2B rēķini pienākumam pakļauti, nosaka Grāmatvedības likuma 11. pants: četrpadsmitā daļa runā par rēķinu, ko iesniedz apmaksai citam Latvijā reģistrētam uzņēmumam, bet sešpadsmitā daļa uzskaita ierobežotus izņēmumus, kas saistīti ar dokumenta veidu un sistēmu. Apgrozījuma sliekšņa tur nav.

Otrs pārpratums ir uzskats, ka PEPPOL BIS Billing 3.0 ir kanāls. Tas ir formāts. Ministru kabineta 2025. gada 9. decembra noteikumi Nr. 749, kas stājās spēkā 2026. gada 1. janvārī, ļauj izvēlēties kanālu: e-adrese, proti, valsts portāla oficiālā elektroniskā adrese, e-rēķinu operatora kanāls vai cits ar pusēm saskaņots ceļš, piemēram, sistēmu savstarpēja integrācija vai e-pasts. Rēķins PEPPOL formātā nav automātiski rēķins, kas pārvietojies Peppol tīklā. Tas darbojas arī pretēji, jo Peppol tīkls nav vienīgais Latvijā atļautais ceļš.

Kas notiek, kad ERP nosūta rēķinu?

Sūtīšana caur API, proti, programmatūras saskarni, praksē izskatās šādi:

1. ERP jeb resursu pārvaldības un grāmatvedības programma no rēķina izveido UBL 2.1 XML failu, kas ievēro EN 16931 datu modeli un PEPPOL BIS Billing 3.0 noteikumus.
2. Fails tiek validēts: vispirms XML shēma (XSD), pēc tam biznesa noteikumi, proti, Schematron pārbaude.
3. Rēķins izvēlētajā kanālā aiziet uz saņēmēja elektronisko adresi, un kanāls atgriež nosūtīšanas statusu.
4. Kopija VID nonāk vai nu kā Elektroniskās deklarēšanas sistēmā (EDS) augšupielādēts XML fails, vai caur E-Invoice API V2 tieši no grāmatvedības programmas; VID pieņem tikai XML, bez pielikumiem.
5. Pēdējais solis ir statusu pārbaude gan saņēmēja pusē, gan VID.

Kāpēc pirmā kļūda ir nepareiza adrese, nevis nepareiza summa?

PEPPOL BIS Billing paredz, ka obligāta ir gan pārdevēja, gan pircēja elektroniskā adrese (EndpointID), un abām jābūt ar shēmas identifikatoru, kas pasaka, kāda veida identifikators tas ir, piemēram, PVN maksātāja numurs vai reģistrācijas numurs. Adrese bez shēmas identifikatora ir fatāla kļūda, nevis trūkstoša detaļa.

Pircēja adresi nedrīkst izsecināt pašam. Pieprasiet to pircējam rakstiski un pārbaudiet trīs lietas: pašu identifikatoru, tā shēmu un kanālu, kurā pircējs rēķinus pieņem. Ja pircējs rēķinus saņem caur e-adresi, tehniski nevainojams XML, kas nosūtīts operatora kanālā, nelīdzēs. Igaunijas uzņēmumam, kas rēķinu iesniedz Latvijas budžeta iestādei, iestādes statusu un rekvizītus vērts saskaņot pirms pirmā rēķina, nevis pēc pirmās atgrūšanas.

Kuri galvas lauki nav atstājami sistēmas ziņā?

PEPPOL fatālie noteikumi prasa, lai rēķinā cita starpā būtu specifikācijas identifikators, rēķina numurs, izdošanas datums, rēķina veida kods, valūta, pārdevēja un pircēja nosaukums, pasta adreses un valstu kodi, kopsummas un vismaz viena rēķina rinda. Vairāki no šiem laukiem nāk no programmas kā noklusējuma vērtības un tāpēc paliek nepārbaudīti.

Divām vērtībām vērts uzmest atsevišķu skatienu. Specifikācijas identifikatoram (CustomizationID) un biznesa procesa identifikatoram (ProfileID) jāatbilst spēkā esošajai BIS versijai: OpenPeppol publicēja PEPPOL BIS Billing 3.0 2026. gada maija laidienu 2026. gada 20. maijā, un tas ir obligāts no 2026. gada 17. augusta. Ja programma ģenerē vecāku versiju, to parasti atklājat tikai no saņēmēja kļūdas ziņojuma.

Kāpēc korekts rēķins nonāk nepareizā darbplūsmā?

PEPPOL rēķinā jābūt vai nu pircēja atsaucei, vai pasūtījuma numuram. Viens no diviem ir obligāts. Pircēja atsauce nav dekorācija, bet saņēmēja iekšējās maršrutēšanas atslēga: pēc tās rēķins nonāk pie pareizā izmaksu centra, līguma vai apstiprinātāja.

No šī rodas klusa kļūda, ko validācijas rīks neķer. XML ir korekts, rēķins aiziet, bet ar nepareizu atsauci tas saņēmēja pusē iestrēgst pirms apstiprināšanas darbplūsmas, un maksājums kavējas. Pārnesiet no pircēja saņemto vērtību ar rakstzīmes precizitāti, jo arī atstarpes un defises ir svarīgas, un glabājiet to ERP pie klienta vai līguma, nevis viena rēķina manuālā laukā.

PVN un kopsummas: šeit XML vairs nepiedod

PVN daļa ir vieta, kur lielākā daļa pirmo rēķinu izgāžas. Katrai rēķina rindai vajadzīgs rindas identifikators, rēķinā uzrādītais daudzums, mērvienības kods, preces vai pakalpojuma nosaukums un neto cena, savukārt valsts, valūtas un PVN kategorijas laukos jālieto noteiktie kodu saraksti. Savi saīsinājumi un brīvs teksts šeit nestrādā.

Biežākās kļūdas:

• Apgrieztā PVN maksāšana (reverse charge) bez pamatojuma. Ja piemēro apgriezto PVN maksāšanu, PVN summai jābūt nullei un rēķinā jābūt atbilstošam atbrīvojuma iemesla kodam vai tekstam. Ar nodokli neapliekamās un PVN piemērošanas jomā neietilpstošās kategorijas arī prasa nulli un savu pamatojumu.
• Kopsummas nesaskan. PEPPOL pārbauda, ka rēķina summa ar PVN ir vienāda ar neto summas un PVN kopu un ka maksājamā summa saskan ar jau samaksāto summu un noapaļojumu.
• Noapaļošana. PVN kategorijas nodoklis jāaprēķina un jānoapaļo līdz divām zīmēm pēc komata. Atstāta trešā zīme beidzas ar kļūdas ziņojumu.
• Atlaides un piemaksas. Dokumenta līmeņa atlaidei un piemaksai ir savs iemesla lauks, un tām jāatspoguļojas kopsummu aprēķinā.
• Trūkstošs maksājuma konts. Ja maksājums notiek ar kredīta pārvedumu, maksājuma konta identifikators ir obligāts. Novecojis IBAN vai trūkstoša maksājuma uzdevuma atsauce nav kosmētisks trūkums, bet nosūtīšanu bloķējoša kļūda.

Nosūtīšanas dienas kontrolsaraksts

Pirms pirmās sūtīšanas izejiet šo secību vienu reizi ar rokām un pēc tam atstājiet to kā pastāvīgu rutīnu.

1. Validējiet XML. VID iesaka failu pirms iesniegšanas pārbaudīt Eiropas Komisijas validācijas rīkā. Izvēlieties rīkā pareizo dokumenta veidu (UBL rēķins vai UBL kredītrēķins) un ieslēdziet gan XML shēmas, gan Schematron pārbaudi.
2. Pārbaudiet nosūtīšanas statusu. Kanālam jāapliecina, ka rēķins nonācis saņēmēja adresē.
3. Pārbaudiet VID statusu. VID kā atteiktus rāda tos failus, kuru apstrāde beigusies ar kļūdu, jo tie nav izturējuši atbilstības PEPPOL standartam pārbaudi (XML, XSD un Schematron) vai vīrusu pārbaudi.
4. Nesūtiet dublikātu. E-rēķinu VID iesniedz vienu reizi, ne vēlāk kā piecu darbdienu laikā pēc nosūtīšanas dienas. Ja rēķins jau nonācis VID, to nedrīkst iesniegt atkārtoti citā kanālā.
5. Kļūdu labojiet ar kredītrēķinu. Ja rēķins jau aizgājis, to atpakaļ neizdzēš. Labojums notiek ar kredītrēķinu vai koriģējošu dokumentu, kas atsaucas uz sākotnējo rēķinu. Ja ir iepriekšējā rēķina atsauce, jābūt arī iepriekšējā rēķina numuram.

Kādā secībā labot kļūdu ziņojumus?

Kļūdu ziņojumi nāk slāņos, un tos vērts risināt no augšas uz leju. Vispirms XSD, proti, XML shēmas kļūdas: nepareizs elementa nosaukums, trūkstoša nosaukumvieta, nepareiza secība. Kamēr shēma nav spēkā, fails vispār nenonāk līdz biznesa noteikumiem. Tad nāk Schematron noteikumi, kuru identifikatori paši pasaka, kur meklēt: EN 16931 biznesa noteikumi attiecas uz paša standarta prasībām, Peppol noteikumi uz šīs specifikācijas sašaurinājumiem, bet UBL sintakses noteikumi (piemēram, ar identifikatoru UBL-SR) uz to, cik reižu viens elements drīkst atkārtoties. Specifikācija sadala noteikumus pēc smaguma pakāpes, un „fatal“ nozīmē šķērsli. Brīdinājumus pirmajā kārtā var atstāt mierā, fatālās kļūdas ne.

Kad viens nepareizs rēķins izgājis cauri, ir saprātīgi pierakstīt, kas tieši bija greizi un no kurienes šī vērtība ERP nāk. Otrajā reizē tā pati kļūda parasti ir datu modeļa, nevis uzmanības jautājums.

Pieejams arī: eesti keeles · English

Pēdējo reizi pārbaudīts: 2026. gada 21. septembris