Kas yra „Peppol“ tinklas ir kodėl jis svarbus e-sąskaitoms?

„Peppol“ yra tarptautinis e. sąskaitų faktūrų perdavimo tinklas kartu su jį valdančiu taisyklių rinkiniu. Tai nėra nei failo formatas, nei portalas, nei mokesčių administratoriaus atskaitomybės aplinka. Tinklą sudaro šimtai sertifikuotų paslaugų teikėjų ir vienas centrinis adresavimo komponentas, kurie visi taiko tą patį sąveikumo taisyklių rinkinį (Peppol Interoperability Framework) ir dokumentais apsikeičia pagal keturių kampų modelį. Centriniai komponentai priklauso organizacijai „OpenPeppol“. E. sąskaitoms „Peppol“ svarbus dėl vienos labai praktiškos priežasties: viena integracija su vienu paslaugų teikėju suteikia ryšį su visais tinkle esančiais partneriais, todėl su kiekvienu pirkėju atskirai derinti techninio kanalo nebereikia. Estijos buhalterinės apskaitos įstatyme, pavyzdžiui, nurodyta, kad mašininiu būdu apdorojamo pirminio dokumento formatas ir pateikimo sąlygos sutariami tarp sandorio partnerių, jei įstatymas ar kitas teisės aktas nenustato kitaip.

Ką pirkėjas iš tikrųjų sako, prašydamas sąskaitos per „Peppol“?

Paprastai šis prašymas pardavimo skyrių pasiekia be jokių paaiškinimų. Sąskaita parengta, PDF failas yra, tačiau pirkėjas sako, kad el. pašto priedo nepriims. Pirmasis kylantis klausimas techniškai yra neteisingas, bet žmogiškai visiškai logiškas: kokio formato turi būti „Peppol“ sąskaita?

Teisingas klausimas kitas. „Peppol“ atsako į tai, kaip sąskaita pasiekia pirkėją ir kaip tas pirkėjas surandamas. Apie formatą, duomenų laukus ir šalies vidaus papildomas taisykles atsako standartas EN 16931 ir „Peppol“ dokumentų specifikacijos. O valstybės nustatyta pareiga kyla iš trečios vietos: iš apskaitos arba mokesčių įstatymo. Kai šie trys lygiai susimaišo, gimsta tipiniai nesutarimai: „juk e. sąskaitą turime, atsiųsime PDF failą“.

Ar „Peppol“ yra įstatymas, ar sąskaitos kelias?

Sutartinis sluoksnis po technika

„Peppol“ yra sąveikumo sistemos pavadinimas: teisinės sutartys, politikos ir techninės specifikacijos, kurias taiko „Peppol“ institucijos (Peppol Authority) ir sertifikuoti paslaugų teikėjai. Paslaugų teikėjas gali teikti „Peppol“ paslaugas tik tada, kai yra pasirašęs paslaugų teikėjo sutartį ir išlaikęs „Peppol“ atitikties testavimą. Būtent šis sutartinis sluoksnis tinklą padaro patikima aplinka, o ne tiesiog dar vienu techniniu protokolu.

Ko „Peppol“ neapima

Atskirai stovi du dalykai, su kuriais „Peppol“ painiojamas dažniausiai. Pirma, nacionalinės e. sąskaitų pareigos, kurios kyla iš kiekvienos šalies įstatymų. Antra, mokesčių atskaitomybė, pavyzdžiui, Latvijos reikalavimas sąskaitas perduoti mokesčių administratoriui. Tai savarankiškas procesas, nors ir grindžiamas ta pačia struktūrizuota sąskaita. „Peppol“ tinklas gali būti priemonė šiems reikalavimams įvykdyti, tačiau jis nėra jų šaltinis.

Kaip keturi kampai sudaro vieną prisijungimą?

Kelias nuo pardavėjo iki pirkėjo

Keturių kampų modelis reiškia, kad pardavėjas ir pirkėjas niekada nesijungia tiesiogiai. Pardavėjas (C1) išsiunčia sąskaitą iš savo buhalterinės apskaitos ar verslo valdymo sistemos (ERP) į savo prieigos tašką (Access Point, C2). Tai sertifikuotas paslaugų teikėjas, kuris prieš išsiuntimą privalo išeinantį pranešimą patikrinti ir užtikrinti atitiktį „Peppol“ verslo sąveikumo specifikacijoms (Peppol BIS). Iš ten sąskaita keliauja į pirkėjo prieigos tašką (C3) ir toliau į pirkėjo sistemą (C4).

Kaip tinkle surandamas gavėjas

Gavėjas surandamas dviem žingsniais. Siuntėjo prieigos taškas pirmiausia kreipiasi į SML, t. y. „OpenPeppol“ administruojamą centrinį adresų registrą (Service Metadata Locator), kuris nurodo, kurį katalogą pirkėjas naudoja. Paskui iš to katalogo, arba SMP (Service Metadata Publisher), teiraujamasi, kokius dokumentus pirkėjas apskritai priima ir kur juos siųsti. Pats siuntėjas šio žingsnio nemato, bet pasekmę pamato greitai: jei pirkėjo galimybės SMP neužregistruotos, sąskaita nepajudės, kad ir kaip taisyklingai būtų suformuotas failas.

Pranešimų vientisumą ir siuntėjo atpažinimą užtikrina tinklo viešojo rakto infrastruktūra (Public Key Infrastructure). Sertifikatą paslaugų teikėjas gauna kartu su sutartimi, o pažeidimo atveju jis gali būti atšauktas.

Palyginimas su mobiliojo ryšio tinklu čia tinka gerai: sutartį turite su vienu operatoriumi, o paskambinti galite visiems. Pats „Peppol“ tai formuluoja trumpiau: „connect once, reach all“.

Kurie trys pavadinimai nuolat painiojami?

Standartas, specifikacija ir tinklas

EN 16931 yra Europos e. sąskaitos semantinis standartas, t. y. susitarimas, kokie duomenų laukai sąskaitoje yra ir ką jie reiškia. Standartas nepasako, kaip sąskaitą pristatyti.

„Peppol BIS Billing“ yra įgyvendinimo specifikacija: ji perima EN 16931 turinį ir tiksliai nurodo, kaip jis turi būti išreikštas. „Peppol BIS“ remiasi UBL, t. y. universaliosios verslo kalbos (Universal Business Language) ISO/IEC 19845 standartais, ir papildomai nustato patikrinimo taisykles, tarp jų ir atskirų šalių.

„Peppol“ tinklas yra transportas ir adresavimas, t. y. ta dalis, kuri sąskaitą pristato.

Kodėl PDF failas neužskaitomas

Iš čia kyla ir atsakymas apie PDF failą. El. paštu išsiųstas PDF apskaitos požiūriu gali būti visiškai taisyklinga sąskaita faktūra, tačiau jis nėra mašininiu būdu nuskaitoma struktūrizuota sąskaita. Latvija šią liniją įrašė į teisės aktus: struktūrizuota e. sąskaita pagal Latvijos finansų ministerijos apibrėžimą yra sąskaita, atitinkanti standartą LVS EN 16931-1:2017 ir techninę specifikaciją LVS CEN/TS 16931-2:2017. Žmogui skaitomas failas į šį apibrėžimą nepatenka.

Kas pasikeitė 2026 m. rugpjūtį?

Trys pakeitimai versijoje 3.0.21

Naujausia „Peppol BIS Billing 3.0“ versija 3.0.21 paskelbta 2026 m. gegužės 20 d. ir privaloma nuo 2026 m. rugpjūčio 17 d. Trys pakeitimai tiesiogiai svarbūs tam, kas įmonėje atsako už sąskaitų procesą.

Pirma, atsirado naujas neprivalomas profilis 02 („billing with response“), skirtas atvejams, kai sąskaitai reikalingas privalomas atsakymas. Šis profilis reikalauja atskiros registracijos SMP. Jei norite gauti sąskaitų atsakymus, esamos sąskaitų gavimo registracijos nepakanka. Antra, taisyklės PEPPOL-COMMON-R052 ir R053 iš įspėjimų tapo klaidomis, nes dabar taikomos visiems profiliams. Trečia, buvo pataisytas EAS kodų sąrašas: iš jo pašalinta 14 nebenaudotinų kodų. Jei jūsų sistema pirkėjo elektroninio adreso schemą užpildo iš rankiniu būdu įrašytos reikšmės, ją verta peržiūrėti.

Kaip tai siejasi su ViDA

Pastačius tai šalia ViDA, vaizdas pasidaro aiškesnis. Tarybos direktyva (ES) 2025/516 priimta 2025 m. kovo 11 d. ir leidžia valstybėms narėms nuo 2025 m. balandžio 14 d. nustatyti privalomą e. sąskaitų išrašymą šalies vidaus sandoriuose. Nuo 2030 m. liepos 1 d. skaitmeninės atskaitomybės reikalavimai taikomi tarpvalstybiniams B2B sandoriams, o e. sąskaita tampa numatytuoju tokių sandorių būdu, be to, sąskaita turi būti išrašyta ne vėliau kaip per 10 dienų. Šalys, jau turinčios savo realaus laiko sandorių atskaitomybę, turi ją suderinti su ES modeliu iki 2035 m. sausio 1 d. Jokios datos, kuri kiekvieną įmonę įpareigotų prisijungti prie „Peppol“, direktyvoje nėra.

Ar Estija, Latvija ir Lietuva juda vienu ritmu?

Estija: pirkėjo teisė reikalauti

Estijoje nuo 2025 m. liepos 1 d. verslo registre e. sąskaitų gavėju registruotas apskaitos subjektas gali reikalauti, kad pardavėjas pateiktų e. sąskaitą. Sąskaita laikoma atitinkančia reikalavimus, jei ji atitinka standartą EN 16931-1, nebent šalys susitarė dėl kito tinkamo standarto. Bendros pareigos, kuri kiekvieną pardavėją įpareigotų visas sąskaitas siųsti kaip e. sąskaitas, čia nėra. Svarbu pirkėjo registracija ir sutartinis susitarimas.

Latvija: datos ir mokesčių atskaitomybė

Latvijos grafikas aiškiausias. Nuo 2025 m. sausio 1 d. biudžetinei įstaigai teikiama sąskaita turi būti išrašyta kaip e. sąskaita (G2G, B2G, G2B). Nuo 2026 m. sausio 1 d. tos e. sąskaitos turi būti perduotos ir mokesčių administratoriui VID, o nuo 2028 m. sausio 1 d. reikalavimas apims šalies vidaus B2B sąskaitas. B2B sandoriuose e. sąskaitas galima rengti jau dabar, o duomenis VID savanoriškai perduoti nuo 2026 metų.

Lietuva: viešojo sektoriaus infrastruktūra

Lietuva nuo 2024 m. rugsėjo 1 d. vietoje buvusios „E. sąskaita“ naudoja sistemą SABIS, kurios modernizavimo tikslas, pasak Finansų ministerijos, yra prijungti įmones prie Europos e. sąskaitų infrastruktūros per „Peppol“ tinklą ir užtikrinti EN 16931 atitinkančias viešojo sektoriaus sąskaitas.

Jei prekiaujate visose trijose šalyse, vieno termino neturite. Turite tris skirtingas logikas: Estijoje pirkėjo teisę, Latvijoje datomis apibrėžtą pareigą kartu su mokesčių atskaitomybe, Lietuvoje viešojo sektoriaus infrastruktūrą.

Ką patikrinti prieš kitą sąskaitą faktūrą?

• Pirkėjo gavimo galimybės ir identifikatorius. Paprašykite „Peppol“ ID ir patikrinkite, ar pirkėjas SMP registruotas gauti būtent tą dokumento tipą, kurį ketinate siųsti.
• Reikalaujamas profilis ir šalies taisyklės. Ar pirkėjas laukia įprasto sąskaitų profilio, ar naujojo profilio 02 su atsakymu? Pastarasis reikalauja atskiros registracijos SMP ir jūsų pusėje.
• Paslaugų teikėjo tvarka. Įsitikinkite, kad jūsų prieigos taškas yra sertifikuotas ir kad jo patikrinimo artefaktai atitinka versiją 3.0.21. Nuo 2026 m. rugpjūčio 17 d. senoji versija nebeleidžiama.
• Duomenų kokybė apskaitos sistemoje. Registro kodai, PVM mokėtojo kodai, mokėjimo nuorodos numeriai ir adresų schemos. Dauguma patikrinimo klaidų kyla ne dėl sąskaitos turinio, o dėl trūkstamų arba iš netinkamo sąrašo paimtų kodų.
• Atsakymų darbo srautas. Jei pirkėjas reikalauja sąskaitos atsakymo, kažkas turi nuspręsti, kas tą atsakymą duoda ir kas atsitinka atmetimo atveju.
• Saugojimas. Struktūrizuotas failas yra originalus dokumentas. Sutarkite, kiek laiko jis saugomas ir kas jį saugo: jūsų sistema, paslaugų teikėjas ar abu.

Brangiausia klaida šiame sąraše nėra techninė. Tai prielaida, kad jei vienas didelis pirkėjas jūsų sąskaitas priima, viskas tvarkinga ir visiems kitiems. Latvijos 2028 metų data ir ViDA tarpvalstybinė atskaitomybė nuo 2030 metų yra pakankamai netoli, kad gavimo ir siuntimo galimybes būtų verta sutvarkyti anksčiau, nei kas nors to pareikalaus.

Taip pat skaitykite: eesti keeles · English · latviski

Paskutinį kartą tikrinta: 2026 m. rugsėjo 16 d.