Kuidas kontrollida e-arvet enne esimest Peppoli saatmist?

Lühivastus: enne esimest päris arvet tuleb sama fail läbi lasta kolmest eri kontrollist. Peppoli spetsifikatsioon kirjeldab eraldi süntaksi kontrolli, EN 16931 andmemudeli kontrolli ja Peppoli enda lisareeglite ehk CIUS-i kontrolli. Tehniliselt loetav XML ei tõenda veel vastavust. 16. septembri 2026 seisuga tuleb kasutada versiooni 3.0.21, mis avaldati 20. mail 2026 ja muutus kohustuslikuks 17. augustil 2026, koos 10. aprillil 2026 avaldatud valideerimisartefaktidega 1.3.16. Praktikas kontrollige neli asja: ostja e-aadress ja selle skeemitunnus, kohustuslikud rekvisiidid, summade ahel ridadelt tasumisele kuuluva summani ning profiilitunnused. Alles seejärel saatke testarve läbi Peppol Testbedi ja siis päris ostjale.

Millisele kolmele reeglistikule peab e-arve korraga vastama?

PDF võib välja näha laitmatu: õige logo, korrektsed summad, viisakas maksetähtaeg. E-arve jääb ikkagi valideerimise taha kinni. Põhjus on lihtne. E-arve peab korraga vastama kolmele reeglistikule, mis on kirjutatud eri kohtades ja eri eesmärgiga.

Esimene on Eesti arvenõuded. Käibemaksuseaduse järgi tuleb arve tavakorras väljastada seitsme kalendripäeva jooksul ja arvel peavad olema seaduses loetletud andmed. See ei muutu sellest, kas arve liigub paberil või masinloetava andmevoona. Teine on EN 16931 ehk Euroopa e-arve andmemudel: see ütleb, millised väljad ja milline loogika peavad arvel olema. Kolmas on Peppoli lisapiirangud, mis on EN 16931-st kitsamad.

Eesti kontekstis on sellel ka konkreetne tagajärg. Alates 1. juulist 2025 võib äriregistris e-arve vastuvõtjaks märgitud raamatupidamiskohustuslane müüjalt e-arvet nõuda ning nõuetekohaseks eeldatakse EN 16931-1 standardile vastavat e-arvet, kui pooled ei ole kokku leppinud muud asjakohast standardit. Teisisõnu: „saadame esialgu PDF-i” ei ole enam alati teie valik.

Miks alustada ostjast, mitte XML-ist?

Enamik esimesi ebaõnnestunud saatmisi ei kuku läbi arvutuste, vaid adresseerimise pärast. Seepärast tehke ostjaga kolm asja selgeks enne, kui arendaja XML-i kallale läheb.

Esimene on kanal. Kinnitage, et ostja võtab arveid vastu Peppoli võrgustiku kaudu ja et tema pool on vastuvõtuks registreeritud. Kui ostja soovib arvele vastust ehk kinnitust arve staatuse kohta, on Peppol BIS Billing 3.0-s selleks eraldi valikuline profiil 02, mis nõuab omaette SMP-registreeringut. Tavalise arveprofiiliga see kaasa ei tule.

Teine on e-aadress koos skeemitunnusega. Peppol nõuab, et nii müüja kui ostja elektrooniline aadress (EndpointID) oleks olemas ja et selle juures olev schemeID kuuluks Peppoli EAS-koodiloendisse; atribuut ise on kohustuslik, mitte soovituslik. Siin on üks värske lõks. Versioon 3.0.21 parandas vale koodiloendi viite ja sellega eemaldati 14 EAS-koodi, mida varem oli tehniliselt võimalik kasutada. Kui teie ERP-i partnerikaardil istub ammu seadistatud skeemikood, kontrollige see üle – eile toiminud väärtus võib täna vea anda.

Kolmas on viide. Peppoli lisareegel PEPPOL-EN16931-R003 nõuab, et arvel oleks kas ostja viide või ostutellimuse viide, ja mõlema puudumine on fatal-tasemel viga. Küsige ostjalt otse: kas te panete arvele ostutellimuse numbri või kokkulepitud ostja viite (buyer reference) väärtuse, ja kust see täpselt tuleb.

Mis juhtub pärast seda, kui ERP arve välja saadab?

Ahel on lühem, kui tundub. ERP või majandustarkvara annab arve andmed API kaudu üle teie operaatorile, kes on sertifitseeritud ligipääsupunkt (Access Point). Operaator koostab või kontrollib UBL-kujulise XML-i, laseb selle läbi valideerimisest, leiab ostja e-aadressi järgi tema operaatori ja edastab arve Peppoli võrgus. Ostja operaator toimetab arve ostja süsteemi, kus andmed jõuavad otse ostuarvete töölauale. Kui teie operaator teeb valideerimise saatmise hetkel (sünkroonne valideerimine), saate vea tagasi kohe API vastuses ja see on teie kõige odavam test.

Millised rekvisiidid peavad arvel ja XML-is olemas olema?

Käige see nimekiri läbi ühe päris arve peal, mitte näidisfaili peal. Peppol BIS Billing 3.0 nõuab muu hulgas:

• spetsifikatsiooni tunnust ja arve numbrit;
• väljastamise kuupäeva ja arve tüübi koodi;
• arve valuutat;
• müüja ja ostja nime ning mõlema poole postiaadressi;
• vähemalt ühte arverida.

Sellele lisaks: mida müüdi (kauba või teenuse nimetus real), makseandmed, mille alusel ostja tasub, maksukohustuslasena registreerimise numbrid seal, kus need on nõutud, ning ostja viide või tellimuse number. Iga arverida peab kandma täpselt ühte käibemaksukategooriat. Kui ühel real on segamini standardmääraga ja maksuvaba osa, tuleb rida kaheks lahutada.

Millises järjekorras Peppol summasid kontrollib?

Summade kontroll ei ole vabas vormis. Peppoli kogusummade ahel on kohustuslik ja liigub täpselt nii:

1. Ridade netosumma – kõigi arveridade netosummade summa.
2. Maksuta kogusumma = ridade netosumma − dokumenditasandi allahindlused + dokumenditasandi lisatasud.
3. Käibemaksuga kogusumma = maksuta kogusumma + käibemaksu kogusumma.
4. Tasumisele kuuluv summa = käibemaksuga kogusumma − ettemakstud summa + ümardussumma.

Käibemaksu jaotus käib eraldi. Iga käibemaksukategooria summa peab olema maksustatav väärtus × maksumäär / 100, ümardatud kahe komakohani, ja nende summade summa peab võrduma arve käibemaksu kogusummaga. Levinuim viga on siin see, et ERP arvutab käibemaksu rea kaupa ja ümardab iga rea eraldi, arve kokkuvõte aga arvutab kategooria kaupa, seega sent läheb lahku ja arve kukub läbi. Kontrollige, kummal loogikal teie süsteem töötab, enne kui saadate.

XML-i kontroll: profiil, koodid, kuupäevad ja ümardus

Profiilitunnused peavad olema täpselt need, mida spetsifikatsioon nõuab. Tavalise arve ja kreeditarve puhul on CustomizationID alusväärtus `urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0` ja ProfileID `urn:fdc:peppol.eu:2017:poacc:billing:01:1.0`. Ärge lisage sinna omaalgatuslikku versioonisufiksit. Reegel PEPPOL-EN16931-R004 sai versioonis 3.0.21 täpsustuse ja versiooniinfot sisaldav CustomizationID annab nüüd selge veateate.

Koodid ja kuupäevad on sama konkreetsed. Valuutakood peab olema kehtivast ISO 4217 loendist. Versioon 3.0.21 eemaldas sellest ANG ja BGN ning lisas XCG. Kuupäevad kirjutatakse spetsifikatsiooni semantiliste andmetüüpide järgi kujul YYYY-MM-DD, seega 16. september 2026 on failis `2026-09-16`, mitte `16.09.2026`.

Ümarduse osas tasub ühte asja meeles pidada. Rea netosumma, maksu kokkuvõtte summad, kogusummad, tasumisele kuuluv summa ning allahindluste ja lisatasude summad võivad sisaldada kõige rohkem kahte komakohta. Ühikuhinnale sama piirangut ei ole, dokumentatsioon toob näiteks väärtuse 10000.1234. Täpne ühikuhind on seega lubatud, kuid lõppsummad peavad olema sendi täpsusega ja omavahel kokku jooksma.

Millises järjekorras vigu parandada?

Valideerija annab tagasi kolme laadi vigu ja neid on mõtet parandada ülevalt alla:

1. XSD- ehk süntaksivead. Fail ei vasta UBL-i skeemile: element on vales kohas, nimeruum puudu, väärtus vale tüübiga. Kuni need püsti on, ei jõua ülejäänud kontrollid sisuni.
2. BR- ja BR-CO-vead. Need tulevad EN 16931 reeglitest: puuduv kohustuslik väli, katkine arvutus, keelatud kood.
3. PEPPOL- ja UBL-SR-vead. Peppoli lisapiirangud ja süntaksireeglid, näiteks PEPPOL-EN16931-R003 või kordumise piirangud. Siin on ka riigipõhised reeglid.

Vaadake ka hoiatusi, mitte ainult vigu. Versioonis 3.0.21 muudeti reeglid PEPPOL-COMMON-R052 ja R053 hoiatustest vigadeks, sest need on nüüd kõigile profiilidele kohustuslikud. Tänane hoiatus on üsna sageli järgmise väljalaske viga.

Milline testipakk tuleb enne päris arvet läbi lasta?

Üks korrektne näidisarve ei tõenda midagi. Koostage viis juhtumit ja laske need kõik läbi Peppol Testbedi või oma operaatori valideerija:

• tavaline arve Eesti standardse käibemaksumääraga;
• arve dokumenditasandi allahindlusega või lisatasuga;
• arve, millel on korraga mitu käibemaksukategooriat (näiteks standardmäär ja maksuvaba müük);
• kreeditarve või parandusarve koos viitega algsele arvele;
• piiriülene arve, kui te neid üldse saadate – teise riigi ostja e-aadress, skeemikood ja maksutunnused käituvad teisiti.

Hoidke need failid alles. Kui poole aasta pärast tuleb uus valideerimisartefaktide versioon, on teil viie minutiga selge, kas miski läks katki.

Mida läbitud valideerimine veel ei tõenda?

Läbitud valideerimine tõendab ühte asja: fail vastab süntaksile, EN 16931 andmemudelile ja Peppoli lisareeglitele. See ei tõenda, et arve jõuab kohale ega et ostja selle ära maksab.

Eraldi tuleb üle kontrollida neli asja. Kas ostja on tegelikult võimeline arvet vastu võtma ja kas kasutasite tema õiget e-aadressi. Kas ostja sisereegel nõuab ostutellimuse numbrit. Vale või puuduv number jätab arve tema kinnitusringis seisma, isegi kui Peppol oli rahul. Kas arve sisu vastab lepingule: hinnad, kogused, maksetähtaeg. Ja kas maksustamine on sisuliselt õige – valideerija kontrollib, et käibemaksuarvutus on iseendaga kooskõlas, mitte et te valisite õige käibemaksukategooria.

Esimene saatmine läheb kõige rahulikumalt siis, kui lepite ostjaga kokku ühe konkreetse arve, mille peal koos vaadata: teie kinnitate, et arve läks välja ja valideerus, tema kinnitab, et arve jõudis süsteemi ja on kinnitusringis. Pärast seda on ülejäänud vaid mahu küsimus.

Loe ka: English · latviski · lietuviškai

Viimati kontrollitud: 16. september 2026