Peppol rēķina validēšana un tā nosūtīšana ir divas pilnīgi atšķirīgas darbības, ko grāmatveži un programmatūras komandas bieži sajauc vienā solī. Validēšana nozīmē rēķina XML faila, jeb datora nolasāma datu faila, pārbaudi pret Eiropas e-rēķinu standarta EN 16931 prasībām. Tā parāda, vai struktūra un lauki ir kārtībā, bet rēķinu nekur tālāk nevirza. Nosūtīšana nozīmē rēķina faktisku piegādi adresātam Peppol tīklā, par ko atbild Peppol-sertificēts piekļuves punkts (Access Point). Manuālai pārbaudei noder bezmaksas Eiropas Komisijas e-rēķinu validēšanas rīks, kas pārbauda rēķinu UBL vai CII formātā. Faktiskai nosūtīšanai tomēr nepieciešams savienojums ar Peppol-sertificētu pakalpojumu sniedzēju, kura piekļuves punkts izejošo ziņojumu validē vēlreiz un atrod adresātu pirms tālāknodošanas.
Kāpēc parasti nepieciešami divi rīki, nevis viens?
Šī neskaidrība rodas, jo abas darbības izmanto vienu un to pašu vārdu – „validēšana”. Bezmaksas validators atbild uz jautājumu „vai fails ir korekts?”. Piekļuves punkts atbild uz jautājumu „kur un kā šis fails faktiski nonāk adresātā?”. Peppol Interoperability Framework šo modeli apraksta kā četru stūru modeli (4 stūru modelis): pārdevējs nosūta rēķinu savam piekļuves punktam, tas atrod pircēja piekļuves punktu, izmantojot centralizētu adresātu reģistru, un pārsūta rēķinu tālāk droši. Katram nosūtošajam piekļuves punktam ir pienākums pirms nosūtīšanas pārbaudīt izejošo ziņojumu pret Peppol BIS noteikumiem. Šī pārbaude ir nosūtīšanas procesa daļa, nevis atsevišķs pakalpojums, ko pasūtāt manuāli. Bezmaksas validators pats nekur ziņojumu nepārsūta un nepārbauda, vai adresāts pastāv. Tā ir kvalitātes kontrole pirms nosūtīšanas, nevis piegādes pakalpojums – to skaidri parāda rīka apraksts.
Labākās validēšanas iespējas pēc lietošanas gadījumiem
Manuālai pārbaudei un izstrādātājiem
Ja rēķinu pārbaudāt manuāli pirms nosūtīšanas, praktiskākais risinājums ir Eiropas Komisijas eInvoice Validator – tas ir bezmaksas un pieejams caur tīmekļa saskarni, REST saskarni vai SOAP saskarni. Izstrādātājiem, kas validēšanu iebūvē tieši programmatūrā, nepieciešami oficiālie Peppol Schematron artefakti, jeb noteikumu faili, kas pārbauda katra BT koda (Business Term, biznesa termins) atbilstību standartam, un izmaiņu vēsture parāda, kad šie noteikumi mainās.
Produkcijas vidē, kur rēķini faktiski tiek nosūtīti
Produkcijas vidē, kur rēķini tiek faktiski nosūtīti, trešo, obligāto pārbaudi veic jūsu piekļuves punkts: tas automātiski validē izejošo ziņojumu, pirms tas vispār nonāk tīklā. Šo trešo pārbaudi jums nav jāpasūta atsevišķi, bet ir vērts zināt, ka tā notiek. Citādi rodas maldīgs priekšstats, ka manuāla validēšana un faktiskā nosūtīšana ir viens un tas pats process.
Ko pārbaudīt Peppol rēķinā pirms nosūtīšanas?
Pirms nosūtīšanas noderēs vienkāršs pārbaudes saraksts:
- Struktūra: pārbaudiet, ka XML fails atbilst UBL vai CII struktūrai un ka visi EN 16931 obligātie lauki ir aizpildīti.
- Identifikatori: pārskatiet Peppol BIS identifikatorus, dokumenta tipa kodus un skēmas, ko 3.0.21 versijas izmaiņas daļēji atjaunināja – piemēram, koriģēts elektroniskās adreses skēmas (EAS) kodu saraksts.
- Galapunkts: pārbaudiet pircēja galapunkta identifikatoru (endpoint ID) un tā skēmu, jo nepareiza skēma nozīmē, ka piekļuves punkts adresātu neatradīs.
- Atsauces: pievienojiet pircēja atsauci vai pasūtījuma (PO) atsauci, ja pircējs to pieprasa.
- PVN un summas: pārskatiet PVN sadalījumu pa rindām un kopsummā, rēķina kopējo vērtību un valūtu, un pārbaudiet valstij specifiskos papildu noteikumus.
Latvijā XML struktūrai jāatbilst nacionālajam standartam, kas balstās uz Peppol BIS Billing 3.0 specifikāciju. Ja kāds no šiem elementiem trūkst vai ir nepareizā formātā, validators rēķinu noraidīs jau pirms nosūtīšanas. Labāk lai tas notiek tur, nevis pie adresāta.
Kā izvēlēties Peppol rēķinu nosūtīšanas rīku vai piekļuves punktu?
Kas nepieciešams atkarībā no nosūtīšanas apjoma
Vajadzības atšķiras atkarībā no tā, cik rēķinu nosūtāt un kādā veidā.
| Lietotājs | Kas nepieciešams visvairāk |
|---|---|
| Reti sūta rēķinus manuāli | Vienkārša tīmekļa saskarne, validēšana pirms nosūtīšanas, skaidrs nosūtīšanas statuss |
| Grāmatvedības programmatūras lietotājs | Iebūvēts Peppol savienojums, kas automātiski atjaunina noteikumus |
| ERP/API komanda | Tieša saskarne ar piekļuves punktu, atbalsts vairākiem dokumentu tipiem, audit trail, jeb nosūtīšanas žurnāls |
Kā pārbaudīt piekļuves punkta sertifikātu
Kuru pakalpojumu sniedzēju izvēlēties, var pārbaudīt OpenPeppol sertificēto pakalpojumu sniedzēju sarakstā, kas atjaunināts 2026. gada 28. augustā. Sarakstā redzams, vai pakalpojumu sniedzējs sertificēts kā piekļuves punkts (AP), pakalpojumu metadatu sniedzējs (SMP) vai kā abi. Svarīga nianse: sarakstā norādītā valsts apzīmē sniedzēja juridisko atrašanās vietu, nevis reģionu, kurā tas faktiski sniedz pakalpojumu – tāpēc igauņu grāmatvedības programmatūra var pilnīgi bez problēmām izmantot Beļģijā reģistrētu piekļuves punktu. Papildus sertifikāta pārbaudei paskatieties, kādus dokumentu tipus sniedzējs atbalsta, vai tas piedāvā adresāta iespēju meklēšanu, cik ātra ir ieviešana, vai var eksportēt nosūtīšanas žurnālu auditam, un kā tas parāda kļūdu ziņojumus. Šīs pēdējās divas lietas atšķir labu sniedzēja rīku no slikta.
Ko jautāt par Peppol BIS Billing 3.0.21 2026. gada augusta izmaiņām?
Šobrīd spēkā esošā versija ir Peppol BIS Billing 3.0.21, kas publicēta 2026. gada 20. maijā un kļuva obligāta 2026. gada 17. augustā. Šī versija izmanto EN 16931 validēšanas noteikumu atjaunināto versiju 1.3.16, publicētu 2026. gada 10. aprīlī. Ja jūsu validators vai rēķinu programmatūra šos noteikumus nav atjauninājusi, tā var uzrādīt kļūdainu rezultātu, kaut arī rēķins faktiski jaunajām prasībām neatbilst. Versija pievienoja arī izvēles profilu „Billing with Response”, kas pircējam ļauj nosūtīt atbildi (response) uz rēķinu, taču šim profilam nepieciešama atsevišķa SMP reģistrācija. Fakts, ka jūsu ikdienas rēķinu nosūtīšana darbojas, automātiski nenozīmē, ka pircējs var vai zina, kā izmantot šo atbildes profilu. Ja pakalpojumu sniedzējs piedāvā šo funkciju, jautājiet konkrēti, vai reģistrācija ir izdarīta, nevis tikai „vai tas ir atbalstīts”.
Kā atšķiras nosūtīšanas iespējas Igaunijā un Latvijā?
Igaunijas reģistra bāzes modelis
Igaunijā sistēma darbojas reģistra bāzē. No 2025. gada 1. jūlija grāmatvedības uzskaites subjekts var reģistrēt savu statusu un e-rēķinu saņemšanas kanāla datus komercreģistrā, norādot, ka vēlas saņemt tikai datora nolasāmus rēķinus. Ja pircējs sevi šādi reģistrējis, tas var pieprasīt no pārdevēja e-rēķinu, kas ir noteikumiem atbilstoši sagatavots, ja tas atbilst EN 16931-1 standartam, izņemot, ja puses vienojušās citādi. Tas nenozīmē, ka visiem Igaunijas B2B rēķiniem automātiski jākustas caur Peppol tīklu. Vienošanās par formātu un nosūtīšanas nosacījumiem paliek pušu ziņā, ja likums nenosaka citādi. Tātad pārdevēja pirmais solis ir pārbaudīt, vai pircējs reģistrā ir pieprasījis e-rēķinu, un tikai tad izvēlēties piemērotu nosūtīšanas veidu.
Latvijas noteiktais termiņu grafiks
Latvijā situācija likumdošanas ziņā ir laika skalā daudz skaidrāk noteikta. Strukturēti e-rēķini ir obligāti no 2025. gada 1. janvāra valsts un uzņēmumu darījumos (G2G, B2G, G2B). E-rēķina datu nodošana VID (Valsts ieņēmumu dienestam) šajā pašā segmentā kļuva obligāta no 2026. gada 1. janvāra. B2B sektorā, jeb starp uzņēmumiem, datu iesniegšana VID šobrīd ir brīvprātīga un tāda paliks līdz 2027. gada 31. decembrim, bet no 2028. gada 1. janvāra strukturēts e-rēķins un ziņošana VID kļūst obligāta visiem Latvijā reģistrētiem uzņēmumiem arī B2B rēķinos. Praktiski rēķinu VID jāiesniedz ne vēlāk kā piecu darba dienu laikā pēc tā nosūtīšanas – vai nu augšupielādējot XML failu elektroniskajā deklarēšanas sistēmā (EDS), vai izmantojot API tieši no grāmatvedības programmatūras. VID iesaka pirms iesniegšanas pārbaudīt XML failu ar Eiropas Komisijas validēšanas rīku. Tā ir viena no konkrētākajām vietām, kur bezmaksas validators un obligātā atskaitīšana faktiski satiekas.
Piecu minūšu tests pirms rēķinu programmatūras nomaiņas
Pirms izlemjat mainīt programmatūru vai piekļuves punktu, izdariet vienu vienkāršu pārbaudi. Izveidojiet tipisku rēķinu, kas ietver visus ikdienā lietotos laukus – piemēram, PVN, atsauces un pircēja datus. Validējiet to ar Eiropas Komisijas rīku, lai novērstu redzamas struktūras kļūdas. Pārbaudiet, ka pircēja galapunkta (endpoint) skēma un identifikators ir pareizi un ka pakalpojumu sniedzējs atbalsta tieši jums nepieciešamo dokumenta tipu. Nosūtiet vienu kontrolrēķinu faktiskajam vai testa adresātam un saglabājiet nosūtīšanas statusu kā pierādījumu. Tas noderēs, ja vēlāk radīsies strīds par to, vai rēķins ir nonācis pie adresāta. Ja darbojaties Latvijā, papildus pārbaudiet, vai šis rēķins pareizi virzās tālāk arī uz VID pusi, jo nosūtīšana Peppol tīklā un datu nokļūšana pie nodokļu administrācijas ir divi atsevišķi soļi, ko ir vērts pārbaudīt katru atsevišķi.
FAQ
Miks on reeglina vaja kahte tööriista, mitte üht?
Tasuta valideerija kontrollib faili korrektsust, ligipääsupunkt edastab arve adressaadile. Mõlemad tegevused kasutavad ‘valideerimist’, kuid on erinevad protsessid.
Mida kontrollida Peppol-arvel enne saatmist?
Kontrolli XML-struktuuri, EN 16931 kohustuslikke välju, Peppol BIS identifikaatoreid, ostja lõpp-punkti identifikaatorit, viiteid, käibemaksu jaotust ja riigipõhiseid reegleid.
Kuidas valida Peppol-arvete saatmise tööriist?
Valik sõltub arvete mahust: väheste arvete puhul lihtne veebiliides, raamatupidamistarkvara kasutajale sisseehitatud ühendus, ERP/API-tiimile otseühendus ligipääsupunktiga. Kontrolli teenusepakkujat OpenPeppoli sertifitseeritud nimekirjast.
Mida küsida Peppol BIS Billing 3.0.21 muudatuse kohta?
Küsi, kas tarkvara on uuendatud reeglitele 1.3.16 ja kas toetatakse valikulist profiili ‘Billing with Response’ koos SMP-registreeringuga.