PEPPOL e-arve Lätis: mis läheb enne saatmist valesti

Esimese struktureeritud e-arve juures läheb kõige sagedamini valesti vorming ja aadress, mitte summa. PDF e-kirja manuses ei ole Lätis struktureeritud e-arve: nõutav on XML-fail, mille struktuur vastab PEPPOL BIS Billing 3.0 spetsifikatsioonile. Enne saatmist komistavad arved tavaliselt kuue asja otsa: puuduv või skeemitunnuseta ostja elektrooniline aadress, puuduv ostja viide või ostutellimuse number, vale või puuduv spetsifikatsiooni tunnus, käibemaksu kategooria ilma vabastuse põhjenduseta, kogusummad, mis ridade ja käibemaksuga kokku ei lähe, ning puuduv maksekonto. Need on fataalsed reeglid. Arve ei jõua saajani, vaid tuleb veateatena tagasi. Enne saatmist tasub XML üle kontrollida Euroopa Komisjoni e-arve valideerimisrakenduses.

Kellele peab Lätis e-arve tegelikult minema?

Lätis kehtestati nõue etappide kaupa ja segadus tekib just seal. Läti maksuameti VID järgi on struktureeritud e-arved kohustuslikud alates 1. jaanuarist 2025 riigisektori ja Lätis registreeritud ettevõtete vahelistes arveldustes ehk G2G, B2G ja G2B segmendis. Raamatupidamise seadus sätestab, et arve, mille ettevõte esitab tasumiseks teisele Lätis registreeritud ettevõttele ehk kauba või teenuse saajale, vormistatakse struktureeritud e-arvena. Sama ülevaade seob 1. jaanuari 2026 teise kohustusega: neis samades segmentides tuleb e-arve andmed edastada ka VID-ile. Kodumaine B2B tuleb järele alles 1. jaanuaril 2028, kui arved tuleb vormistada e-arvena ja üheaegselt VID-ile esitada. Ajavahemikus 1. jaanuarist 2026 kuni 31. detsembrini 2027 on B2B andmete esitamine vabatahtlik. 2026. aasta jaanuar ei muutnud seega kõiki B2B-arveid kohustuslikuks.

Millised B2B-arved kohustuse alla langevad, ütleb raamatupidamise seaduse (Grāmatvedības likums) 11. paragrahv: lõige 14 räägib teisele Lätis registreeritud ettevõttele tasumiseks esitatavast arvest ja lõige 16 loetleb piiratud erandid, mis on seotud dokumendi liigi ja süsteemiga. Käibepiiri seal ei ole.

Teine arusaamatus on see, et PEPPOL BIS Billing 3.0 oleks kanal. See on vorming. Ministrite kabineti 9. detsembri 2025 määrus nr 749, mis jõustus 1. jaanuaril 2026, lubab kanali valida: e-adrese ehk riigiportaali ametlik elektrooniline aadress, operaatori kanal või muu pooltega kokku lepitud tee, näiteks süsteemidevaheline liidestus või e-post. PEPPOL-vormingus arve ei ole automaatselt PEPPOL-võrgus liikunud arve. Ja vastupidi: PEPPOL-võrk ei ole Lätis ainus lubatud teekond.

Mis juhtub siis, kui ERP arve teele saadab?

API kaudu saatmine näeb praktikas välja nii:

1. ERP ehk majandustarkvara koostab arvest UBL 2.1 XML-i, mis järgib EN 16931 andmemudelit ja PEPPOL BIS Billing 3.0 reegleid.
2. Fail valideeritakse: kõigepealt XML-skeem (XSD), seejärel ärireeglid ehk Schematron-kontroll.
3. Arve läheb valitud kanalis saaja elektroonilisele aadressile ja kanal tagastab saatmise staatuse.
4. VID-i koopia liigub kas EDS-i üleslaaditud XML-failina või E-Invoice API V2 kaudu otse raamatupidamistarkvarast; VID võtab vastu ainult XML-i, ilma manustega.
5. Viimane samm on staatuste kontroll nii saaja poolel kui VID-is.

Miks on esimene viga vale aadress, mitte vale summa?

PEPPOL BIS Billingus on nii müüja kui ostja elektrooniline aadress (EndpointID) kohustuslik ja kummalgi peab olema skeemitunnus, mis ütleb, mis liiki identifikaator see on, näiteks käibemaksukohustuslase number või registrikood. Skeemitunnuseta aadress on fataalne viga, mitte puuduv detail.

Ostja aadressi ei tohi ise tuletada. Küsige see ostjalt kirjalikult ja kontrollige kolme asja: identifikaator ise, selle skeem ning kanal, milles ostja arveid vastu võtab. Kui ostja võtab arveid vastu e-adrese kaudu, ei aita operaatori kanalisse saadetud tehniliselt laitmatu XML midagi. Eesti ettevõttel, kes esitab arve Läti eelarveasutusele, tasub asutuse staatus ja rekvisiidid kokku leppida enne esimest arvet, mitte pärast esimest tagasilööki.

Millised päise väljad ei tohi jääda süsteemi hooleks?

PEPPOLi fataalsed reeglid nõuavad, et arvel oleksid muu hulgas spetsifikatsiooni tunnus, arve number, väljastamise kuupäev, arve liigi kood, valuuta, müüja ja ostja nimi, postiaadressid ja riigikoodid, kogusummad ning vähemalt üks arverida. Mitmed neist tulevad tarkvarast vaikeväärtusena ja jäävad seetõttu üle vaatamata.

Kahele väärtusele tasub eraldi pilk visata. Spetsifikatsiooni tunnus (CustomizationID) ja äriprotsessi tunnus (ProfileID) peavad vastama kehtivale BIS-i versioonile: OpenPeppol avaldas PEPPOL BIS Billing 3.0 mai 2026 väljalaske 20. mail 2026 ja see on kohustuslik alates 17. augustist 2026. Kui teie tarkvara genereerib vanemat versiooni, avastate selle tavaliselt alles saaja veateatest.

Miks jõuab korrektne arve valesse töövoogu?

PEPPOL-arvel peab olema kas ostja viide või ostutellimuse number. Üks neist kahest on nõutav. Ostja viide ei ole dekoratsioon, vaid saaja sisemise suunamise võti: selle järgi jõuab arve õige kulukeskuse, lepingu või kinnitaja juurde.

Siit tuleb vaikne tõrge, mida valideerimisrakendus ei püüa kinni. XML on korrektne, arve liigub kohale, aga vale viitega arve jääb saaja poolel kinnitusringi ette seisma ja makse hilineb. Kandke ostjalt saadud väärtus tähemärgi täpsusega üle, sest ka tühikud ja sidekriipsud loevad, ning hoidke see väärtus ERP-is kliendi või lepingu juures, mitte ühe arve manuaalses väljas.

Käibemaks ja kogusummad: siin XML enam ei andesta

Käibemaksu osa on koht, kus enamik esimesi arveid põrub. Iga arverida vajab reatunnust, arveldatud kogust, mõõtühiku koodi, kauba või teenuse nimetust ja netohinda, ning riigi, valuuta ja käibemaksu kategooria väljad peavad kasutama ettenähtud koodiloendeid. Oma lühendid ja vabatekst siin ei tööta.

Sagedasemad tõrked:

• Pöördmaksustamine ilma põhjenduseta. Pöördmaksustamise korral peab käibemaksusumma olema null ja arvel peab olema vastav vabastuse põhjuse kood või tekst. Maksuvabad ja käibemaksu kohaldamisalast välja jäävad kategooriad nõuavad samuti nulli ja oma põhjendust.
• Kogusummad ei klapi. PEPPOL kontrollib, et arve summa koos käibemaksuga võrduks netosumma ja käibemaksu liiduga ning et tasumisele kuuluv summa läheks kokku juba tasutud summa ja ümardusega.
• Ümardamine. Käibemaksu kategooria maks tuleb arvutada ja ümardada kahe komakohani. Kolmanda komakoha jätmine lõpeb veateatega.
• Allahindlused ja lisatasud. Dokumendi tasandi allahindlusel ja lisatasul on oma põhjuseväli ning need peavad kajastuma kogusummade arvutuses.
• Puuduv maksekonto. Kui makse toimub krediidiülekandega, on maksekonto tunnus kohustuslik. Vananenud IBAN või puuduv maksekorralduse viide ei ole kosmeetiline puudus, vaid saatmist takistav viga.

Saatmispäeva kontrollnimekiri

Enne esimest saatmist tehke see järjekord läbi ühe korra käsitsi ja seejärel jätke see püsivaks rutiiniks.

1. Valideerige XML. VID soovitab faili enne esitamist kontrollida Euroopa Komisjoni valideerimisrakendusega. Valige rakenduses õige dokumendiliik, kas UBL-arve või UBL-kreeditarve, ja lülitage sisse nii XML-skeemi kui Schematroni kontroll.
2. Kontrollige saatmise staatust. Kanal peab kinnitama, et arve jõudis saaja aadressile.
3. Kontrollige VID-i staatust. VID näitab tagasilükatuna neid faile, mille töötlus lõppes veaga, sest need ei läbinud PEPPOL-standardile vastavuse kontrolli (XML, XSD ja Schematron) või viirusekontrolli.
4. Ärge saatke dublikaati. E-arve esitatakse VID-ile üks kord, hiljemalt viie tööpäeva jooksul pärast saatmise päeva. Kui arve on juba VID-i jõudnud, ei tohi seda teise kanali kaudu uuesti esitada.
5. Vea parandamiseks kasutage kreeditarvet. Kui arve on juba teele läinud, ei kustuta seda tagasi. Parandus käib kreeditarve või korrigeeriva dokumendiga, mis viitab algsele arvele. Kui eelneva arve viide on olemas, peab olemas olema ka eelneva arve number.

Millises järjekorras veateateid parandada?

Veateated tulevad kihtidena ja neid tasub lahendada ülalt alla. Kõigepealt XSD ehk XML-skeemi vead: vale elemendi nimi, puuduv nimeruum, vale järjekord. Kuni skeem ei kehti, ei jõua fail ärireegliteni üldse. Seejärel tulevad Schematroni reeglid, mille tunnused ütlevad ise, kust otsida: EN 16931 ärireeglid puudutavad standardi enda nõudeid, PEPPOLi enda reeglid selle spetsifikatsiooni kitsendusi ja UBL-süntaksi reeglid (näiteks tunnusega UBL-SR) seda, mitu korda üks element tohib esineda. Spetsifikatsioon jagab reeglid raskusastme järgi ja „fatal” tähendab tõkendit – hoiatused võib esimeses järjekorras rahule jätta, fataalsed vead mitte.

Kui üks vale arve on läbi käinud, on mõistlik kirja panna, mis täpselt valesti oli ja kust see väärtus ERP-is tuleb. Teisel korral on sama viga tavaliselt andmemudeli, mitte tähelepanu küsimus.

Loe ka: English · latviski

Viimati kontrollitud: 21. september 2026