Galiojantis PDF nereiškia galiojančios Peppol sąskaitos faktūros

Peppol (visos Europos elektroninių sąskaitų faktūrų perdavimo tinklas) tikrina struktūrizuotus sąskaitos faktūros duomenis, o ne PDF failo vaizdą. Prieš siunčiant reikia patikrinti tris atskirus lygius: XML failo struktūrą, turinio atitiktį standartui EN 16931 (Europos e. sąskaitų faktūrų turinio standartas, nurodantis, kokie duomenys sąskaitoje faktūroje turi būti), ir paties Peppol verslo taisykles, surinktas BIS Billing 3.0 specifikacijoje. Pagal openPeppol dokumentaciją, pranešimas laikomas atitinkančiu reikalavimus, jei pagal šiuo metu galiojančias taisykles nerandama nė vienos fatalinės klaidos. Įspėjimai atitikties nepažeidžia. Tačiau lygiai taip pat svarbu, kad validavimo įrankiai tikrina tik sąskaitos faktūros pranešimą, o ne tai, ar pirkėjo sistema jį iš principo priims ar apmokės. Tarp žalios šviesos validavime ir „sąskaita faktūra apmokėta“ dar yra keli žingsniai.

Kokia yra penkių žingsnių patikra prieš spaudžiant „Siųsti“?

Šis procesas veikia nepriklausomai nuo to, ar naudojate ERP sistemą, apskaitos programinę įrangą, ar operatoriaus portalą:

  • Eksportuokite XML failą: sukurkite sąskaitos faktūros failą UBL arba CII formatu – be jo validavimas tiesiog neįmanomas.
  • Paleiskite schemos ir verslo taisyklių patikrą: pirmiausia struktūrinė patikra, tada Schematron taisyklės (kalba, skirta XML failo vidinių sąsajų tikrinimui), kurios tikrina sumas, kodus ir laukų tarpusavio ryšius.
  • Ištaisykite fatalines klaidas: pagal openPeppol taisyklę siuntėjas neturi siųsti pranešimo, kuris neatitinka BIS specifikacijos. Tai griežta taisyklė, ne rekomendacija.
  • Patikrinkite gavėjo Peppol galimybes: įsitikinkite, kad pirkėjas yra registruotas tinkle ir gali priimti konkretų dokumento tipą.
  • Išsaugokite validavimo rezultatą: pasilikite ataskaitą ir perdavimo patvirtinimą. Tai pirmas dalykas, kurio jūsų paklaus, kai sąskaita faktūra „pasimeta“.

Kuris validatorius tinka kuriam darbui?

XSD, arba XML schema, tikrina, ar failas iš principo yra taisyklingas XML: laužtiniai skliaustai tinkamose vietose, privalomi elementai esantys. Schematron tikrina kitą dalyką – verslo taisykles ir elementų tarpusavio ryšius, pavyzdžiui, ar eilučių sumos sutampa su bendra sąskaitos faktūros suma. Pagal Europos Komisijos paaiškinimą, Schematron savarankiškai XML struktūros nepatikrina, todėl naudokite jį kartu su atitinkama schema arba įrankiu, kuris atlieka abu veiksmus vienu metu. Komisija tam siūlo nemokamą validavimo paslaugą, kuriai nereikia registruotis ir kurią Latvijos mokesčių administracija tiesiogiai rekomenduoja naudoti prieš teikiant XML sąskaitą faktūrą VID sistemai. Jei sąskaitas faktūras siunčiate per operatorių ar apskaitos programinę įrangą, kuri validavimą atlieka viduje, kiekvienos sąskaitos faktūros papildomai tikrinti įrankyje rankiniu būdu nebūtina. Tai pagrįstas sprendimas įprastu atveju, tačiau testuojant naują XML generavimo logiką verta naudoti atskirą, nepriklausomą įrankį.

Skaitykite ataskaitą: fatalinė klaida prieš įspėjimą

Fatalinė klaida reiškia, kad sąskaita faktūra neatitinka BIS specifikacijos ir jos siųsti negalima. Įspėjimas reiškia, kad sąskaita faktūra techniškai priimtina, bet verta atkreipti dėmesį. Praktikoje daugiausia problemų kyla penkiose vietose: pardavėjo ir pirkėjo identifikatoriai (netinkama schema arba neteisingas registro kodas), PVM kategorija ir tarifas, eilučių ir bendros sumos vertės (apvalinimo klaidos lengvai išsiskiria), mokėtina suma su valiutos kodu, ir mokėjimo nuoroda su apmokėjimo terminu. Jei sąskaitos faktūros eilutėje nurodyta 100 eurų plius 22 % PVM, bet bendros sumos lauke stovi neteisingas skaičius, validatorius grąžina fatalinę klaidą – ir pagrįstai, nes ta suma tiesiai patenka į pirkėjo apskaitą.

Kaip patikrinti pristatymą atskirai nuo galiojimo?

Turiniu tvarkinga sąskaita faktūra nebūtinai pasieks gavėją. Peppol turinio ir verslo taisyklių patikra yra viena, maršrutizavimas per Peppol tinklą – kita. Prieš siunčiant verta patikrinti, ar pirkėjo galutinis punktas (endpoint) palaiko tą konkretų dokumento tipą, kurį siunčiate. Peppol katalogas yra viešai ieškoma registruotų gavėjų sąrašas, bet už jo pildymą atsako paslaugų teikėjai – tai jų atsakomybė, ne pareiga. Todėl visiškai tvarkingas gavėjas kataloge gali tiesiog nesirasti. Jei kyla abejonių, tiesiai paklauskite pirkėjo jo Peppol identifikatoriaus, o nepasitikėkite vien tuo, kad katalogas parodys visą tiesą.

Kas pasikeičia 2026 m. rugpjūtį?

BIS Billing 3.0 versija 3.0.20 (su hotfix’u) yra privaloma nuo 2026 m. vasario 23 d., tačiau nauja versija 3.0.21 tampa privaloma 2026 m. rugpjūčio 17 d. Pakeitimas ištaiso elektroninio adreso schemos (EAS – kodas, rodantis, kurioje sistemoje yra registruotas įmonės identifikatorius) kodų sąrašo klaidą ir pašalina 14 neveikiančių kodų, todėl senu validatoriumi atlikta patikra gali duoti neteisingą rezultatą. Ta pati versija įtraukia pasirenkamą profilį, leidžiantį gauti formalų sąskaitos faktūros patvirtinimą (invoice response), tačiau tam reikalinga atskira SMP registracija (SMP – meta duomenų valdymo taškas, nurodantis, kokius dokumentus gali priimti konkretus dalyvis) ir tai automatiškai neveikia su kiekviena sąskaita faktūra. Jei naudojate paruoštą sprendimą, raštu paklauskite savo operatoriaus, kada jie perkelia įrankius į naują versiją. Jei XML kuriate patys, atnaujinkite validavimo taisykles iki 2026 m. rugpjūčio 17 d. – kitaip jūsų pačių programinė įranga pradės tvirtinti sąskaitas faktūras pagal taisykles, kurių Peppol nebepriima.

Estija ir Latvija: vietinės patikros

Estijoje įmonė, įregistruota verslo registre kaip e. sąskaitų faktūrų gavėja, nuo 2025 m. liepos 1 d. gali reikalauti, kad pardavėjas pateiktų sąskaitą faktūrą standarto EN 16931-1 formatu. Sąskaita faktūra, atitinkanti šį standartą, laikoma tinkamai išrašyta, tačiau šalys gali sutarti ir dėl kito tinkamo standarto. Tai nereiškia, kad Peppol Estijoje yra privalomas kiekvienai B2B sąskaitai faktūrai – tik tai, kad registruotas gavėjas gali reikalauti šio formato.

Latvijoje terminai sudėtingesni. VID (Latvijos mokesčių administracija) paaiškina, kad e. sąskaitos faktūros B2G, G2B ir G2G sandoriuose privalomos nuo 2025 m. sausio 1 d., o e. sąskaitos faktūros duomenų teikimas VID sistemai privalomas nuo 2026 m. sausio 1 d. – duomenis reikia pateikti ne vėliau kaip per penkias darbo dienas po sąskaitos faktūros išsiuntimo. B2B segmente duomenų teikimas iki 2027 metų pabaigos yra savanoriškas, tačiau VID rekomenduoja prieš teikiant XML failą jį patikrinti tos pačios Europos Komisijos nemokamos validavimo paslaugos pagalba, kurią naudojate ir Peppol sąskaitos faktūros atveju. Verta šias dvi atskiras pareigas – turinio atitiktį ir savalaikį pateikimą VID sistemai – tikrinti pagal atskirus sąrašus, o ne tikėtis, kad viena operatoriaus patikra automatiškai apima abu.

FAQ

Kas kehtiv PDF tähendab, et Peppol e-arve on valideeritud ja sobib saatmiseks?

Ei. Peppol valideerib struktureeritud e-arve sõnumi andmed (XML), mitte PDF-i välimust. Enne saatmist tuleb eraldi kontrollida XML-i struktuuri, EN 16931 sisu ning Peppol/BIS Billing 3.0 äritreegleid.

Millised on 5 sammu enne Peppol e-arve saatmist?

Esiteks ekspordi arve XML (UBL või CII). Seejärel käivita skeemi ja äritreeglite kontroll. Paranda fataalsed vead BIS-iga kooskõlasoleku järgi, kontrolli saaja Peppol-võimekust ning säilita valideerimise raport ja kinnitus.

Mis vahe on skeemi (XSD) ja äritreigli (Schematron) kontrollil?

XSD kontrollib, kas fail on korrektne XML: kohustuslikud elemendid ja struktuur. Schematron kontrollib äritreegleid ja elementidevahelisi seoseid, näiteks kas rea- ja kogusummad klapivad.

Mis muutub BIS Billing 3.0 uue versiooniga alates 17. augustist 2026?

Uus BIS Billing 3.0 versioon 3.0.21 muutub kohustuslikuks 17.08.2026. Muudatus parandab elektroonilise aadressiskeemi (EAS) koodinimekirja vea ja eemaldab 14 mittetöötavat koodi, mis võib vana valideerimise loogikaga anda vale tulemuse.