Kaip patikrinti e. sąskaitą prieš pirmą „Peppol“ siuntimą?

Trumpas atsakymas: prieš pirmą tikrą sąskaitą tą patį failą reikia praleisti per tris skirtingus patikrinimus. „Peppol“ specifikacijoje jie aprašyti atskirai: tai sintaksės patikra, EN 16931 duomenų modelio patikra ir pačios „Peppol“ papildomų taisyklių, vadinamųjų CIUS, patikra. Techniškai perskaitomas XML failas dar neįrodo atitikties. 2026 m. rugsėjo 16 d. duomenimis reikia naudoti versiją 3.0.21, paskelbtą 2026 m. gegužės 20 d. ir privalomą nuo 2026 m. rugpjūčio 17 d., kartu su 2026 m. balandžio 10 d. paskelbtais 1.3.16 validavimo artefaktais. Praktikoje tikrinkite keturis dalykus: pirkėjo el. adresą ir jo schemos kodą, privalomus rekvizitus, sumų grandinę nuo eilučių iki mokėtinos sumos ir profilio identifikatorius. Tik po to siųskite bandomąją sąskaitą per „Peppol Testbed“ aplinką, o tikram pirkėjui siųskite dar vėliau.

Kokius tris taisyklių rinkinius e. sąskaita turi atitikti vienu metu?

PDF failas gali atrodyti nepriekaištingai: teisingas logotipas, tvarkingos sumos, mandagus mokėjimo terminas. E. sąskaita vis tiek įstrigs validavime. Priežastis paprasta. E. sąskaita vienu metu turi atitikti tris taisyklių rinkinius, kurie parašyti skirtingose vietose ir skirtingais tikslais.

Pirmasis rinkinys yra nacionaliniai sąskaitų faktūrų reikalavimai. Jie nuo formato nepriklauso: nesvarbu, ar sąskaita keliauja popieriuje, ar mašininiu būdu nuskaitomu duomenų srautu. Pavyzdžiui, Estijoje pagal pridėtinės vertės mokesčio įstatymą sąskaita faktūra įprastai turi būti išrašyta per septynias kalendorines dienas, o joje turi būti visi įstatyme išvardyti duomenys. Antrasis rinkinys yra EN 16931, europinis e. sąskaitos duomenų modelis. Jis nurodo, kokie laukai ir kokia skaičiavimo logika sąskaitoje turi būti. Trečiasis rinkinys yra „Peppol“ papildomi apribojimai, kurie yra griežtesni už patį EN 16931.

Estijos pavyzdys gerai parodo, kodėl tai nėra vien techninis klausimas. Nuo 2025 m. liepos 1 d. apskaitos subjektas, verslo registre pažymėtas kaip e. sąskaitų gavėjas, gali reikalauti e. sąskaitos iš pardavėjo, o tinkama laikoma EN 16931-1 standartą atitinkanti e. sąskaita, jei šalys nesutarė dėl kito aktualaus standarto. Kitaip tariant, jei prekes ar paslaugas pardavinėjate Estijos įmonėms, atsakymas „kol kas atsiųsime PDF failą“ nebėra vien jūsų pasirinkimas.

Kodėl pradėti reikia nuo pirkėjo, o ne nuo XML?

Dauguma pirmųjų nepavykusių siuntimų sužlunga ne dėl skaičiavimų, o dėl adresavimo. Todėl tris dalykus su pirkėju išsiaiškinkite dar prieš tai, kai programuotojas imasi XML failo.

Pirmas dalykas yra kanalas. Įsitikinkite, kad pirkėjas sąskaitas priima per tinklą „Peppol“ ir kad jo pusė iš tikrųjų užregistruota gavimui. Jei pirkėjas nori atsakymo į sąskaitą, t. y. patvirtinimo apie jos būseną, „Peppol BIS Billing 3.0“ tam turi atskirą neprivalomą 02 profilį, kuriam reikia savo registracijos paslaugų metaduomenų registre (SMP). Su įprastu sąskaitos profiliu jis savaime neatsiranda.

Antras dalykas yra el. adresas su schemos kodu. „Peppol“ reikalauja, kad ir pardavėjo, ir pirkėjo elektroninis adresas (EndpointID) būtų nurodytas, o prie jo esantis schemos kodas (schemeID) priklausytų „Peppol“ EAS kodų sąrašui; pats atributas yra privalomas, o ne rekomendacinis. Čia yra viena nauja spąstų vieta. Versija 3.0.21 ištaisė klaidingą kodų sąrašo nuorodą ir kartu pašalino 14 EAS kodų, kuriuos anksčiau techniškai buvo galima naudoti. Jei jūsų buhalterinės apskaitos ar verslo valdymo sistemos (ERP) partnerio kortelėje jau seniai įrašytas schemos kodas, patikrinkite jį, nes vakar veikusi reikšmė šiandien gali grąžinti klaidą.

Trečias dalykas yra nuoroda. „Peppol“ papildoma taisyklė PEPPOL-EN16931-R003 reikalauja, kad sąskaitoje būtų arba pirkėjo nuoroda, arba pirkimo užsakymo nuoroda, o abiejų nebuvimas yra „fatal“ lygio klaida. Pirkėjo paklauskite tiesiai: ar į sąskaitą rašote pirkimo užsakymo numerį, ar sutartą pirkėjo nuorodos (buyer reference) reikšmę, ir iš kur tiksliai ją imsite.

Kas nutinka po to, kai ERP išsiunčia sąskaitą?

Grandinė trumpesnė, nei atrodo. ERP arba apskaitos programa per API perduoda sąskaitos duomenis jūsų el. sąskaitų operatoriui, kuris yra sertifikuotas prieigos punktas (Access Point). Operatorius suformuoja arba patikrina UBL formato XML failą, praleidžia jį per validavimą, pagal pirkėjo el. adresą randa jo operatorių ir perduoda sąskaitą tinkle „Peppol“. Pirkėjo operatorius sąskaitą pateikia pirkėjo sistemai, kur duomenys iškart atsiranda pirkimo sąskaitų faktūrų darbalaukyje. Jei jūsų operatorius validuoja siuntimo metu (sinchroninis validavimas), klaidą gausite tuoj pat API atsakyme. Tai pigiausias jūsų testas.

Kokie rekvizitai turi būti sąskaitoje ir XML faile?

Šį sąrašą peržiūrėkite su tikra sąskaita, o ne su pavyzdiniu failu. „Peppol BIS Billing 3.0“ reikalauja, be kita ko:

• specifikacijos identifikatoriaus ir sąskaitos numerio;
• išrašymo datos ir sąskaitos tipo kodo;
• sąskaitos valiutos;
• pardavėjo ir pirkėjo pavadinimų bei abiejų šalių pašto adresų;
• bent vienos sąskaitos eilutės.

Prie to prisideda dar keli dalykai: kas parduota (prekės ar paslaugos pavadinimas eilutėje), mokėjimo duomenys, pagal kuriuos pirkėjas sumokės, PVM mokėtojo kodai ten, kur jie reikalaujami, ir pirkėjo nuoroda arba užsakymo numeris. Kiekviena sąskaitos eilutė turi turėti lygiai vieną PVM kategoriją. Jei vienoje eilutėje susimaišo standartiniu tarifu apmokestinama ir neapmokestinama dalis, eilutę reikia išskirti į dvi.

Kokia tvarka „Peppol“ tikrina sumas?

Sumų patikra nėra laisvos formos. „Peppol“ bendrųjų sumų grandinė yra privaloma ir eina būtent taip:

1. Eilučių neto suma yra visų sąskaitos eilučių neto sumų suma.
2. Bendra suma be mokesčių = eilučių neto suma − dokumento lygio nuolaidos + dokumento lygio papildomi mokesčiai.
3. Bendra suma su PVM = bendra suma be mokesčių + bendra PVM suma.
4. Mokėtina suma = bendra suma su PVM − sumokėta avanso suma + apvalinimo suma.

PVM suvestinė skaičiuojama atskirai. Kiekvienos PVM kategorijos suma turi būti apmokestinamoji vertė × tarifas / 100, apvalinta iki dviejų skaičių po kablelio, o šių sumų suma turi būti lygi bendrai sąskaitos PVM sumai. Dažniausia klaida čia tokia: ERP skaičiuoja PVM kiekvienai eilutei atskirai ir kiekvieną eilutę atskirai apvalina, o sąskaitos suvestinė skaičiuoja pagal kategorijas, todėl vienas centas nesutampa ir sąskaita nepraeina validavimo. Prieš siųsdami patikrinkite, pagal kurią logiką dirba jūsų sistema.

XML patikra: profilis, kodai, datos ir apvalinimas

Profilio identifikatoriai turi būti būtent tokie, kokių reikalauja specifikacija. Įprastos sąskaitos ir kreditinės sąskaitos atveju CustomizationID bazinė reikšmė yra `urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0`, o ProfileID reikšmė yra `urn:fdc:peppol.eu:2017:poacc:billing:01:1.0`. Savo iniciatyva versijos priesagos prie jų nepridėkite. Taisyklė PEPPOL-EN16931-R004 versijoje 3.0.21 buvo patikslinta, ir versijos informaciją turintis CustomizationID dabar grąžina aiškų klaidos pranešimą.

Kodai ir datos ne mažiau konkretūs. Valiutos kodas turi būti iš galiojančio ISO 4217 sąrašo. Versija 3.0.21 iš jo pašalino ANG ir BGN, o pridėjo XCG. Datos rašomos pagal specifikacijos semantinius duomenų tipus formatu YYYY-MM-DD, taigi 2026 m. rugsėjo 16 d. faile atrodo `2026-09-16`, o ne `16.09.2026`.

Dėl apvalinimo verta įsidėmėti vieną dalyką. Eilutės neto suma, mokesčių suvestinės sumos, bendrosios sumos, mokėtina suma ir nuolaidų bei papildomų mokesčių sumos gali turėti ne daugiau kaip du skaičius po kablelio. Vieneto kainai tokio apribojimo nėra, o dokumentacijoje pateiktas pavyzdys yra `10000.1234`. Vadinasi, tiksli vieneto kaina yra leidžiama, tačiau galutinės sumos turi būti cento tikslumu ir tarpusavyje sutapti.

Kokia tvarka taisyti klaidas?

Validatorius grąžina tris klaidų rūšis, o taisyti jas verta iš viršaus į apačią:

1. XSD, t. y. sintaksės klaidos. Failas neatitinka UBL schemos: elementas ne toje vietoje, trūksta vardų srities, reikšmė netinkamo tipo. Kol jos neištaisytos, kiti patikrinimai net nepasiekia turinio.
2. BR ir BR-CO klaidos. Jos kyla iš EN 16931 taisyklių: trūksta privalomo lauko, neveikia skaičiavimas, panaudotas neleidžiamas kodas.
3. PEPPOL ir UBL-SR klaidos. „Peppol“ papildomi apribojimai ir sintaksės taisyklės, pavyzdžiui, PEPPOL-EN16931-R003 arba pasikartojimo apribojimai. Čia patenka ir konkrečios šalies taisyklės.

Skaitykite ne tik klaidas, bet ir įspėjimus. Versijoje 3.0.21 taisyklės PEPPOL-COMMON-R052 ir R053 iš įspėjimų tapo klaidomis, nes dabar jos privalomos visiems profiliams. Šiandienos įspėjimas gana dažnai yra kito leidimo klaida.

Kokį testų rinkinį reikia praleisti prieš pirmą tikrą sąskaitą?

Viena taisyklinga pavyzdinė sąskaita neįrodo nieko. Paruoškite penkis atvejus ir praleiskite juos visus per „Peppol Testbed“ arba savo operatoriaus validatorių:

• įprastą sąskaitą su jūsų šalies standartiniu PVM tarifu;
• sąskaitą su dokumento lygio nuolaida arba papildomu mokesčiu;
• sąskaitą, kurioje vienu metu yra kelios PVM kategorijos (pavyzdžiui, standartinis tarifas ir neapmokestinamas pardavimas);
• kreditinę arba tikslinamąją sąskaitą su nuoroda į pirminę sąskaitą;
• tarpvalstybinę sąskaitą, jei jas apskritai siunčiate, nes kitos šalies pirkėjo el. adresas, schemos kodas ir mokesčių identifikatoriai veikia kitaip.

Šiuos failus išsaugokite. Kai po pusmečio pasirodys nauja validavimo artefaktų versija, per penkias minutes žinosite, ar kas nors sulūžo.

Ko įveiktas validavimas dar neįrodo?

Įveiktas validavimas įrodo vieną dalyką: failas atitinka sintaksę, EN 16931 duomenų modelį ir „Peppol“ papildomas taisykles. Jis neįrodo, kad sąskaita pasieks gavėją ir kad pirkėjas ją apmokės.

Atskirai reikia patikrinti keturis dalykus. Ar pirkėjas iš tikrųjų pajėgus priimti sąskaitą ir ar naudojote teisingą jo el. adresą. Ar pirkėjo vidinė taisyklė reikalauja pirkimo užsakymo numerio, nes neteisingas arba nenurodytas numeris sąskaitą sustabdys jo patvirtinimo cikle, net jei „Peppol“ buvo patenkintas. Ar sąskaitos turinys atitinka sutartį: kainos, kiekiai, mokėjimo terminas. Ir ar apmokestinimas iš esmės teisingas, nes validatorius tikrina, ar PVM skaičiavimas neprieštarauja pats sau, o ne tai, ar pasirinkote tinkamą PVM kategoriją.

Pirmas siuntimas praeina sklandžiausiai tada, kai su pirkėju sutariate dėl vienos konkrečios sąskaitos, kurią peržiūrėsite kartu: jūs patvirtinate, kad sąskaita išėjo ir praėjo validavimą, jis patvirtina, kad sąskaita atsirado sistemoje ir yra patvirtinimo cikle. Visa kita po to yra tik apimties klausimas.

Taip pat skaitykite: eesti keeles · English · latviski

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