E-rēķins Latvijā nav “PDF rēķins e-pastā”. E-rēķins ir strukturēts elektronisks rēķins, kuru sistēmas var nolasīt automātiski. Tieši tas ir mērķis: mazāk manuāla darba, mazāk kļūdu, ātrāka apmaksa un vienkāršāka uzskaite.
Šajā rakstā es izskaidrošu:
- kas Latvijā tiek saprasts ar e-rēķinu,
- kā tas atšķiras no PDF,
- ko uzņēmumam sagatavot, lai e-rēķini “iet cauri”,
- un kā pārbaudīt e-rēķinu XML, pirms to sūti.
Ja tev jau ir XML fails un gribi to pārbaudīt:
https://www.erekini.eu/peppol-validator
Validācija notiek pārlūkā, fails netiek augšupielādēts.
Kas ir e-rēķins (praktiski)
E-rēķins ir rēķins, kas ir:
- XML formātā (nevis PDF),
- strukturēts pēc konkrētiem noteikumiem (profilu/standartu loģika),
- paredzēts automātiskai apstrādei (grāmatvedība, EDS, sistēmas).
PDF ir “skaists attēls ar tekstu”. XML ir “dati”, ko sistēma var saprast bez cilvēka.
Kāpēc ar PDF vairs nepietiek
PDF joprojām būs ikdienā, bet tas nerisina galveno problēmu: manuālu ievadi un kļūdas.
Tipiskās PDF problēmas:
- rēķins tiek pārrakstīts uzskaitē ar roku
- sajaucas PVN, piegādes datumi, rekvizīti
- rēķini pazūd e-pastos
- apmaksa ievelkas, jo komunikācija ir lēna
Strukturēts e-rēķins ļauj sistēmām to “apēst” automātiski un samazināt šo haosu.
Ko uzņēmumam vajag, lai e-rēķins būtu korekts
Šīs lietas ir svarīgākas par jebkuru “AI” funkciju. Ja šis nav sakārtots, e-rēķins krīt.
1) Pareizi rekvizīti (piegādātājs un pircējs)
- uzņēmuma nosaukums
- reģistrācijas numurs
- PVN numurs (ja ir)
- adrese
- kontaktinformācija (nav vienmēr obligāti, bet praktiski palīdz)
2) Konsekvents rēķinu numerācijas princips
- skaidrs formāts (piem., 2026-001)
- unikāls numurs
3) PVN loģika, kas sakrīt ar rindām
- PVN bāze + PVN summa
- rindas summas, atlaides, noapaļošana
4) Identifikatori un atsauces (kur visbiežāk krīt)
Peppol pasaulē bieži klūp:
- schemeID
- BuyerReference
- identificējošie lauki pircējam/piegādātājam
Ja tev validācija krīt, 80% gadījumu tas ir šeit.
Kā Latvijā visbiežāk notiek e-rēķinu plūsma
Reālais process uzņēmumos parasti izskatās šādi:
- Tu sagatavo rēķinu sistēmā
- Sistēma ģenerē Peppol/EN16931 saderīgu XML
- Tu nosūti (atkarīgs no integrācijas: B2B/B2G, platformas, apmaiņas kanāls)
- Saņēmēja sistēma automātiski ieimportē
- Grāmatvedība un apmaksa kļūst ātrāka
Svarīgi: “nosūtīt e-rēķinu” nav tas pats, kas “uztaisīt XML”. Dažām plūsmām ir papildnoteikumi. Tieši tāpēc validācija pirms nosūtīšanas ir milzīgs laika ietaupījums.
Kā pārbaudīt e-rēķinu XML (pirms sūti)
Ātrākais veids ir:
- paņem savu XML failu
- ielādē validatorā
- skaties, kas krīt
- salabo ģenerēšanu (nevis labo failu ar roku katru reizi)
Pārbaude:
https://www.erekini.eu/peppol-validator
Biežākās problēmas Latvijā (īss saraksts)
Ja tu redzi kādu no šiem, tu neesi viens:
- nepareizs schemeID
- trūkst BuyerReference
- PVN summas nesakrīt ar rindām
- kopsummas nesakrīt (LegalMonetaryTotal vs rindas)
- nepareizs dokumenta tips (Invoice vs CreditNote)
Pilns saraksts ar labojumiem:
https://www.erekini.eu/app/blog/peppol-xml-kludas-validacija/
Ko darīt uzņēmumam jau tagad (lai nebūtu panika vēlāk)
- Sakārto klientu kartītes (ID, PVN, adrese)
- Sakārto numerāciju un rekvizītus
- Pārbaudi vienu reālu XML failu validatorā
- Ja validācija krīt, salabo ģenerēšanu sistēmā
- Izvēlies risinājumu, kas šo padara par “ikdienu”, nevis atsevišķu projektu
Ja tev e-rēķini ir regulāri, Business plāns ir paredzēts uzņēmumiem un PVN maksātājiem:
https://www.erekini.eu/app/pricing/
Mini FAQ
Vai e-rēķins aizstāj PDF?
Praksē bieži dzīvos abi. PDF ir cilvēkam, XML ir sistēmai.
Vai varu vienkārši konvertēt PDF uz XML?
Dažreiz, bet tas nav drošs ceļš. Labāk ģenerēt XML no sistēmas datiem, lai saglabājas loģika un konsekvence.
Kā zināt, vai mans XML ir pareizs?
Validē to pirms nosūtīšanas: https://www.erekini.eu/peppol-validator
