Derīgs PDF fails nenozīmē derīgu Peppol e-rēķinu.

PDF fails, kas izskatās perfekti, joprojām var neizturēt Peppol validāciju, jo Peppol (viseiropas e-rēķinu piegādes tīkls) pārbauda rēķina pamatā esošos strukturētos datus, nevis to, kā tas izskatās ekrānā. Pirms nosūtīšanas ir jāpārbauda trīs atsevišķi slāņi: XML faila struktūra, vai tā saturs atbilst EN 16931 (Eiropas e-rēķinu satura standartam, kas nosaka, kādiem datu laukiem jābūt rēķinā), un Peppol paša biznesa noteikumi, kas ietverti BIS Billing 3.0 specifikācijā. Saskaņā ar openPeppol... dokumentācija, ziņojums tiek uzskatīts par atbilstošu, ja pašlaik aktīvie noteikumi neatrod fatālas kļūdas. Brīdinājumi nepārkāpj atbilstību. Tikpat svarīgi: validācijas artefaktu pārbaude pats rēķina ziņojums, nevis tas, vai pircēja sistēma to faktiski pieņems vai apmaksās. Zaļā gaisma validācijas laikā un "rēķins ir apmaksāts" joprojām ir vairāku soļu attālumā.

Kā izskatās piecu soļu pārbaude pirms nosūtīšanas?

Šis process darbojas vienādi neatkarīgi no tā, vai izmantojat ERP sistēmu, grāmatvedības programmatūru vai operatora portālu:

  • Eksportēt XML failu: ģenerēt UBL vai CII failu (divi strukturēti formāti, kuros tiek apmainīti rēķini). Bez tā vispār nav nekā, ko validēt.
  • Palaidiet shēmas un biznesa noteikumu pārbaudi: vispirms strukturālā validācija, pēc tam Schematron noteikumi (valoda XML faila lauku savstarpējo relāciju pārbaudei), kas aplūko kopsummas, kodus un to, kā lauki ir saistīti kopā.
  • Labojiet fatālas kļūdas: openPeppol likums ir tas, ka sūtītājs nedrīkst sūtīt ziņojumu, kas neatbilst BIS standartiem. Tā ir stingra prasība, nevis ieteikums.
  • Pārbaudiet saņēmēja Peppol iespējas: pārliecinieties, ka pircējs patiešām ir reģistrējies tīklā un var saņemt konkrēto dokumenta veidu, ko jūs sūtāt.
  • Saglabājiet validācijas rezultātu: Saglabājiet atskaiti un piegādes apstiprinājumu. Tā ir pirmā lieta, ko ikviens prasīs, kad rēķins "pazūd".“

Kurš validators veic kādu darbu?

XSD jeb XML shēma (fails, kas definē, kas tiek uzskatīts par derīgu XML) pārbauda, vai fails vispār ir pareizs XML: vai elementi ir pareizajās vietās, vai ir aizpildīti obligātie lauki. Schematron pārbauda pavisam ko citu: biznesa noteikumus un elementu savstarpējās attiecības, piemēram, vai rindu vienību summa atbilst rēķina kopsummai. Saskaņā ar Eiropas Komisijas skaidrojums, Schematron pats par sevi nepārbauda XML struktūru, tāpēc izmantojiet to kopā ar shēmas pārbaudi vai rīku, kas darbojas abos vienlaicīgi. Komisija piedāvā bezmaksas validācijas pakalpojums tieši šim nolūkam reģistrācija nav nepieciešama, un Latvijas nodokļu iestāde uzņēmumiem norāda uz to tieši pirms XML rēķina iesniegšanas VID. Ja rēķinus nosūtāt, izmantojot operatoru vai grāmatvedības programmatūru, kas jau veic iekšējo validāciju, jums nav manuāli jāpārbauda katrs rēķins, izmantojot atsevišķu rīku. Tas ir labi ikdienas lietošanai. Taču, testējot jaunu XML ģenerēšanas loģiku, jebkurā gadījumā palaidiet to, izmantojot atsevišķu validatoru.

Ziņojuma lasīšana: fatāla kļūda pirms, brīdinājums pēc

Fatāla kļūda nozīmē, ka rēķins neatbilst BIS standartiem un to nedrīkst nosūtīt. Brīdinājums nozīmē, ka rēķins tehniski ir pieņemams, taču to ir vērts pārskatīt. Praksē problēmas koncentrējas ap piecām vietām: pārdevēja un pircēja identifikatori (nepareiza shēma vai nepareizs reģistra kods), PVN kategorija un likme, rindu un kopsummas (noapaļošanas kļūdas viegli iekļūst), maksājamā summa kopā ar tās valūtas kodu un atsauces numurs blakus maksājuma termiņam. Ja rēķina rindā ir norādīts 100 eiro plus 22% PVN, bet kopsummas laukā ir norādīts cits skaitlis, validators rada fatālu kļūdu, un tas ir pareizi, jo šis skaitlis nonāk tieši pircēja grāmatvedības sistēmā.

Kā pārbaudīt piegādi atsevišķi no derīguma termiņa?

Strukturāli pareizs rēķins joprojām negarantē piegādi. Viena lieta ir pārbaudīt Peppol saturu un biznesa noteikumus; cita lieta ir maršrutēšana Peppol tīklā. Pirms nosūtīšanas pārbaudiet, vai pircēja galapunkts patiešām atbalsta konkrēto dokumenta veidu, kuru gatavojaties nosūtīt. Peppol direktorijs ir publiski meklējams reģistrēto saņēmēju saraksts, taču ieraksta atjaunināšana ir pakalpojuma sniedzēja ziņā, nevis juridisks pienākums, tāpēc tajā joprojām var trūkt pilnīgi derīga saņēmēja. Ja neesat pārliecināts, jautājiet pircējam tieši viņa Peppol identifikatoru, nevis paļaujieties, ka direktorijā ir redzama visa informācija.

Kas mainīsies 2026. gada augustā?

BIS Billing 3.0 versija 3.0.20 (ar tās labojumfailu) ir obligāta kopš 2026. gada 23. februāra, bet 3.0.21 versija kļūst obligāta no 2026. gada 17. augusta. Atjauninājums novērš kļūdu elektroniskās adreses shēmas (EAS, kods, kas norāda, kurā sistēmā uzņēmuma identifikators ir reģistrēts) kodu sarakstā un noņem 14 kodus, kas vairs nedarbojas, kas nozīmē, ka pārbaude, izmantojot veco validatoru, tagad var sniegt nepareizu rezultātu. Tajā pašā versijā ir pievienots papildu profils, kas ļauj sūtītājam saņemt oficiālu rēķina atbildi, taču tam ir nepieciešama atsevišķa SMP reģistrācija (Service Metadata Publisher, direktorija ieraksts, kas norāda tīklam, kur novirzīt uzņēmuma rēķinus), un tas netiek automātiski reģistrēts katrā rēķinā. Ja izmantojat standarta risinājumu, rakstiski jautājiet savam operatoram, kad viņi pārvieto savus validācijas artefaktus uz jauno versiju. Ja ģenerējat savu XML, atjauniniet validācijas noteikumus līdz 2026. gada 17. augustam. Pretējā gadījumā jūsu programmatūra turpinās apstiprināt rēķinus atbilstoši noteikumiem, kurus Peppol vairs nepieņem.

Igaunija un Latvija: vietējās pārbaudes

Igaunijā uzņēmums ienāca tirgū uzņēmumu reģistrs Kopš 2025. gada 1. jūlija e-rēķinu saņēmējs var pieprasīt pārdevējiem nosūtīt rēķinus atbilstoši EN 16931-1 standartam. Rēķins, kas atbilst šim standartam, tiek uzskatīts par pareizi formatētu, lai gan abas puses joprojām var vienoties par citu piemērotu standartu. Tas nenozīmē, ka Peppol ir obligāts katram B2B rēķinam Igaunijā; tas tikai nozīmē, ka reģistrēts saņēmējs var pieprasīt šo formātu.

Latvijas laika līnija aptver vairākus slāņus. VID (Latvijas Nodokļu iestāde) skaidro, ka e-rēķini ir obligāti B2G, G2B un G2G darījumiem (uzņēmumu un valdības, valdības un uzņēmumu un valdības starpā) kopš 2025. gada 1. janvāra, un e-rēķinu datu iesniegšana pašai VID kļuva obligāta no 2026. gada 1. janvāra. Datiem jānonāk VID piecu darba dienu laikā pēc rēķina nosūtīšanas. B2B segmentā šo datu iesniegšana paliek brīvprātīga līdz 2027. gada beigām, taču VID joprojām iesaka XML failu pirms iesniegšanas pārbaudīt, izmantojot to pašu bezmaksas Eiropas Komisijas validācijas pakalpojumu, ko izmantotu Peppol rēķinam. Tās ir divas atsevišķas saistības – satura atbilstība un savlaicīga iesniegšana VID, un ir vērts tās izsekot divos atsevišķos kontrolsarakstos, nevis pieņemt, ka jūsu operators sedz abus bez jūsu pārbaudes.

Bieži uzdotie jautājumi

Vai derīgs PDF fails nozīmē, ka Peppol e-rēķins ir validēts un piemērots nosūtīšanai?

Nē. Peppol validē strukturētos e-rēķina ziņojuma datus (XML), nevis PDF izskatu. Pirms nosūtīšanas atsevišķi jāpārbauda XML struktūra, EN 16931 saturs un Peppol/BIS Billing 3.0 biznesa noteikumi.

Kādi ir 5 soļi pirms Peppol e-rēķina nosūtīšanas?

Vispirms eksportējiet rēķinu XML formātā (UBL vai CII). Pēc tam veiciet shēmas un biznesa noteikumu pārbaudi. Izlabojiet fatālas kļūdas atbilstoši BIS atbilstībai, pārbaudiet saņēmēja Peppol iespējas un saglabājiet validācijas pārskatu un apstiprinājumu.

Kāda ir atšķirība starp shēmas (XSD) un biznesa darījumu (Schematron) validāciju?

XSD pārbauda, vai fails ir pareizs XML: obligātie elementi un struktūra. Schematron pārbauda biznesa noteikumus un elementu savstarpējās attiecības, piemēram, vai rindu un kopsummas sakrīt.

Kas mainīsies jaunajā BIS Billing 3.0 versijā no 2026. gada 17. augusta?

Jaunā BIS Billing 3.0 versija 3.0.21 kļūs obligāta no 2026. gada 17. augusta. Izmaiņas novērš kļūdu elektroniskās adresācijas shēmas (EAS) kodu sarakstā un noņem 14 nedarbojošos kodus, kas ar veco validācijas loģiku varēja dot nepareizu rezultātu.