Peppol ja Peppol API: mis see on ja millal seda vaja

Peppol on rahvusvaheline e-arvete võrgustik, mitte failivorming ega üksik operaatoriühendus. Eestis võib e-arve saajaks registreeritud ostja alates 1. juulist 2025 nõuda müüjalt e-arvet, ELi piiriülene käibemaksu aruandlus algab 1. juulil 2030 ning Peppoli enda arvespetsifikatsioon uueneb korra paari aasta tagant. E-arvete käsitlemine on nihkunud finantsi lisaküsimusest süsteemidisaini küsimuseks. Just seetõttu tasub teada, mis Peppol on, millised kuupäevad tegelikult loevad ning millal ehitada oma tarkvarasse Peppol API ja millal piisab tavalisest operaatoriühendusest.

Alusta arvest, mitte lühendist

Sinu enda süsteem, olgu see ise ehitatud ERP ehk majandustarkvara, arveldusmootor, SaaS-toode või kauplemisplatvorm, oskab juba arveid koostada. Kitsaskoht tekib hetkel, mil klient või riigiasutus ei taha enam PDF-i meili teel, vaid struktureeritud, masinloetavat e-arvet, mille tema süsteem loeb sisse ilma ühegi käsitsi ümbertrükitud reata.

Mis on e-arve Euroopa Komisjoni definitsiooni järgi?

Euroopa Komisjon defineerib e-arvet üsna kitsalt: selle määratluse järgi on e-arve arve struktureeritud, masinloetavas vormingus, mis võimaldab müüja ja ostja vahel automaatset elektroonilist töötlust. Ilus ja korrektne PDF sellele definitsioonile ei vasta, sest masina jaoks on see pilt, mitte andmevoog. Sama lehe järgi kehtestati direktiivi kõrvale Euroopa standard EN 16931-1, mis kirjeldab e-arve põhiandmemudeli: mis väljad arvel peavad olema ja mis tähenduses.

See on kogu jutu vundament. Kõik ülejäänu, olgu see Peppol, API või operaatorid, on vaid viis, kuidas selline masinloetav arve punktist A punkti B liigub.

Mis on Peppol ja miks see ei ole arvevorming?

Kõige levinum arusaamatus: Peppolit peetakse failivorminguks või ühe kindla operaatori ühenduseks. Kumbki ei pea paika.

Kuidas nelja nurga mudel töötab?

Peppol on rahvusvaheline võrgustik, mis toimib nelja nurga mudelil (four-corner model). Sina ühendud ühe sertifitseeritud ligipääsupunktiga (Access Point), sinu partner teise, ja need kaks ligipääsupunkti räägivad omavahel turvaliselt. OpenPeppoli enda kirjelduse järgi kehtib põhimõte „connect once, reach all”: ühenda end korra ühe operaatoriga ja jõuad kõigi vastuvõtjateni. Kõige lihtsam on seda võrrelda mobiilsidevõrguga: pole vahet, milline operaator kummalgi otsal on, tänu ühtsele standardile jõuab kõne kohale.

Kuidas saatja teab, kuhu arve saata?

Võrgu keskmes on kaks komponenti. SML ehk Service Metadata Locator on keskne aadressiregister, mis ütleb, millise SMP poole pöörduda, sarnaselt sellele, kuidas internet leiab domeeninime järgi õige serveri. SMP ehk Service Metadata Publisher on omakorda saaja „aadressiraamat”, kust selgub, kas ja millises vormingus partner konkreetset dokumenti üldse vastu võtab. Saatja ligipääsupunkt teeb enne saatmist selle otsingu ise ära.

Kas Peppoli spetsifikatsioon on muutumatu?

Arve sisu ise järgib Peppol BIS Billing 3.0 spetsifikatsiooni, ühist ärireeglistikku, mis rajaneb EN 16931 andmemudelil ja UBL-i (Universal Business Language, ISO/IEC 19845) failistruktuuril. Oluline on üks asi, mida müügijutt sageli vaikib: spetsifikatsioon ei ole liikumatu. OpenPeppoli post-award tabeli järgi avaldati BIS Billing 3.0 üks väljalase 24. novembril 2025 kohustusliku kuupäevaga 23. veebruar 2026, järgmine avaldati 20. mail 2026 kohustusliku kuupäevaga 17. august 2026, ning rahvusvaheline PINT BIS Billing EU 1.1.1 avaldati 8. juunil 2026 kohustusliku kuupäevaga 7. september 2026. Kes ehitab Peppoli tuge oma koodi, peab arvestama, et valideerimisreeglid ja kohustuslikud kuupäevad muutuvad. Seda ei saa üks kord ehitada ja unustada.

Miks Peppol praegu Eestis ja EL-is loeb?

Kolm asja on Peppoli teemast teinud päevakajalise. Kõik kolm on kuupäevaga kinni, mitte „varsti”.

Avalik sektor ja riigihanke piirmäärad

Esimene on avalik sektor. Sama Komisjoni e-arve lehe järgi võeti direktiiv 2014/55/EL vastu 16. aprillil 2014 ja hiljemalt 2020. aasta aprilliks pidid kõik avaliku sektori asutused suutma vastu võtta ja töödelda EN-standardile vastavaid e-arveid nende riigihangete puhul, mille maht ületab ELi riigihanke piirmäärasid. Need piirmäärad ei ole abstraktsed: aastateks 2026–2027 kehtestatud tabeli järgi on keskvalitsuse asjade ja enamiku teenuste piirmäär 140 000 €, kohalike hankijate oma 216 000 €, sotsiaal- ja eriteenuste oma 750 000 € ning ehitustööde oma 5 404 000 €. Eesti oma seadus läheb aga kaugemale: raamatupidamise seadus nõuab riigiraamatupidamiskohustuslasele, kohaliku omavalitsuse üksusele ja muudele nimetatud avaliku sektori ostjatele kauba või teenuse müümisel masintöödeldava arve ehk e-arve esitamist, kuid ei seo seda kohustust summalise piirmääraga.

Eesti raamatupidamise seaduse muudatus

Teine on Eesti oma seadus. Riigi Teatajas avaldatud raamatupidamise seaduse muudatuse järgi (RT I, 10.10.2024, 1), mis jõustus 1. juulil 2025, võib äriregistrisse e-arve saajaks märgitud raamatupidamiskohustuslane nõuda müüjalt e-arve esitamist, ja e-arve loetakse nõuetekohaseks, kui see vastab EN 16931-1 standardile. See ei ole üldkohustus kõigile B2B-arvetele, vaid ostja valikuõigus. Aga kui su klient selle õiguse kasutab, pead sa suutma e-arve väljastada.

ViDA ja piiriülene aruandlus

Kolmas on ViDA (VAT in the Digital Age) ehk ELi käibemaksureform. Maksu- ja tolliliidu teate järgi võeti pakett vastu 11. märtsil 2025 ja avaldati Euroopa Liidu Teatajas 25. märtsil 2025. Sama teate järgi hakkab piiriülese B2B tehingute digiaruandlus (Digital Reporting Requirements) kehtima 1. juulil 2030 ning liikmesriigid, kellel on riigisisene reaalajas aruandluskohustus, peavad oma süsteemid ELi standarditega ühtlustama 1. jaanuariks 2035. Lisaks võivad liikmesriigid pärast jõustumist kehtestada teatud tingimustel kohustusliku riigisisese e-arveldamise.

Üks selgitus, mida siin sageli vaja läheb: Eestis ei ole praegu Peppoli kaudu toimivat reaalajas käibemaksu aruandlust. See on tulevikupilt, mille ViDA aastaks 2030–2035 raamistab, mitte tänane olukord. Kes lubab vastupidist, eksib.

Kuhu Peppol API tegelikult sobib

Peppol API on integratsioonikiht ehk tehniliselt liides, mille kaudu sinu tarkvara saadab ja võtab arveid vastu ilma inimese vahelesekkumiseta. Vahel nimetatakse seda ka headless e-arvelduseks. Idee on lihtne: sinu süsteem hoiab alles oma kasutajaliidese, hinnaloogika ja arvegeneratsiooni, aga Peppoli võrgu tehnilise poole, olgu selleks vormingusse teisendamine, saaja otsing, saatmine, allkirjastamine või vastuvõtt, teeb ära sertifitseeritud operaator API kaudu.

Mõtle sellele kui tööjaotusele. Sinu arendajad ei pea saama Peppoli eksperdiks, ei pea läbima sertifitseeritud ligipääsupunkti konformsustesti ega jälgima igat spetsifikatsiooni väljalaset. Nad kutsuvad API-t. Operaator kannab sertifitseeritud ligipääsupunkti kohustused.

Siin tuleb ka üks aus hoiatus. API ei tee sinu arveandmeid iseenesest õigeks. Kui su süsteem paneb valed käibemaksukoodid või puuduliku ostja identifikaatori, siis valideerimine lükkab arve tagasi. Hea API teebki seda kohe, mitte kuu aega hiljem. Aga andmete sisuline korrektsus jääb ikkagi sinu süsteemi vastutuseks.

Kus API end ära tasub ja kus mitte?

Headless-integratsioon tasub end ära seal, kus arvete maht või protsess muudab käsitsi portaali kasutamise mõttetuks:

• ise ehitatud ERP või arveldusmootor, kus arved sünnivad sinu enda äriloogikast ja peaksid sealt otse võrku liikuma;
• SaaS-toode oma arveldusega, mis arveldab tuhandeid kliente ja ei saa iga arvet inimkäega portaali toksida;
• kauplemisplatvormid ja turuplatsid, kus arveid liigub palju osapoolte vahel ja vaja on nii saatmist kui vastuvõttu;
• suuremahulised püsiarved ehk tellimused, liitumistasud ja kommunaal, kus arveldus on tsükliline ja automaatne;
• mitme juriidilise isikuga grupid, kus üks integratsioon peab teenindama mitut müüjaidentifikaatorit;
• äriregistrisse e-arve saajaks märgitud kliendid, kes võivad nõuda müüjalt e-arve esitamist, kusjuures EN 16931-1 vastavust üksnes eeldatakse nõuetekohase vormistusena ja pooled võivad kokku leppida muu asjakohase standardi kasutamises;
• automaatsed sissetulevad ostuarved, mis peaksid jõudma otse kinnitusringi ja raamatupidamisse;
• staatusepõhised töövood, kus sinu süsteem peab teadma, kas arve võeti vastu, lükati tagasi või kinnitati.

Ja nüüd see, mida enamik artikleid maha vaikib. Kui sa oled tavaline ettevõte, kes on sisse ostnud ERP-i või arveldustarkvara kasutusõiguse ega ehita seda ise, siis Peppol API-t sul tõenäoliselt vaja ei ole. Sellisel juhul piisab tavalisest operaatoriühendusest, näiteks Finbite arvekeskuse kaudu, et Peppoli e-arveid saata ja vastu võtta. Operaator hoolitseb vormingu, valideerimise ja võrgu eest, sina kasutad valmis keskkonda või oma raamatupidamistarkvara valmis liidestust. API on mõeldud neile, kes tahavad Peppoli oma tarkvara sisse ehitada, mitte neile, kellel on juba töötav lahendus olemas.

Üheselt: mikroettevõttele, kes saadab kaks arvet kuus, ei tasu ei API-t ega isegi eraldi integratsiooni, sest veebikeskkond katab vajaduse üle.

Kontroll-loend enne esimest koodirida

Enne kui arendaja avab redaktori, tasub need küsimused läbi käia. Iga punkt on koht, kus hilinenud otsus maksab hiljem topelt.

• Identifikaatorid. Milline on sinu ja su partnerite Peppol-ID? Eestis põhineb see tavaliselt registrikoodil. Kust sa saaja ID kätte saad ja kuidas seda oma andmetes hoiad?
• Toetatud dokumenditüübid. Kas piisab müügiarvest ja kreeditarvest, või on vaja ka ostuarvete vastuvõttu, tellimusi või arvevastuseid?
• UBL-i genereerimine. Kes koostab EN 16931 ja BIS Billing 3.0 nõuetele vastava faili, kas sinu süsteem või operaator sinu andmete pealt?
• Valideerimine. Kas arvet valideeritakse enne saatmist sünkroonselt, nii et vead tulevad kohe välja, mitte päev hiljem?
• Saaja otsing. Kuidas kontrollid enne saatmist, kas partner on üldse Peppolis ja võtab selle dokumenditüübi vastu?
• Saatmise ja vastuvõtu vood. Kuidas käsitled sissetulevaid arveid, kas need liiguvad automaatselt kinnitusringi ja raamatupidamisse?
• Arvevastused ja staatused. Kas sinu süsteem peab teadma, et arve võeti vastu, lükati tagasi või kinnitati, ja mida ta selle infoga teeb?
• Veakäsitlus ja logid. Mis juhtub tagasilükatud arvega? Kes seda näeb ja kuidas parandus uuesti teele läheb?
• Arhiveerimine. Kus ja kui kaua säilitad saadetud ja saadud e-arveid seaduse nõuete kohaselt?
• Varuplaan. Mis saab siis, kui saaja pole Peppolis? Kas on olemas teine kanal, näiteks operaatori keskkond?
• Spetsifikatsiooni uuendused. Kes jälgib OpenPeppoli kohustuslikke kuupäevi ja uuendab valideerimisreeglid õigeaegselt?

Viimane punkt on see, mille peale kõige rohkem takerdutakse. Peppol ei ole ühekordne projekt, vaid püsiv ühendus standardiga, mis edasi elab. Kui valid operaatori API asemel valmis operaatoriühenduse, kandub see hoolduskoormus enamjaolt operaatorile. Kui ehitad ise, jääb see sinu meeskonna lauale. Seda tasub teada juba enne, kui esimene rida koodi kirjutatakse.