ES PVM atitikties automatizavimas naudojant debesijos apskaitos API

Praktinis vadovas platformoms ir prekyvietėms, kurioms reikia tikros apskaitos, teisingo PVM ir audito sekos (audit trail), atlaikančios patikrinimus po kelerių metų.

ES PVM nebėra skaičiavimo problema. Tai įrodymų problema. Tarifai yra skelbiami, ribos žinomos, o OSS deklaracijos gerai aprašytos. Tai, dėl ko neišlaikomi auditai ir kas žlugdo didelės apimties platformas, yra nesugebėjimas atkurti, kaip buvo priimtas konkretus PVM sprendimas konkrečiai sąskaitai faktūrai, naudojant tuo momentu galiojusias taisykles ir įvesties duomenis. Debesijos apskaitos API gali tai visiškai automatizuoti nuo pradžios iki pabaigos, bet tik tuo atveju, jei jos architektūra paremta sprendimų grafu, o ne vien tarifu.

Šis skirtumas lemia viską, kas išdėstyta toliau.

Ką iš tikrųjų reiškia „ES PVM automatizavimas“

Keliose ES šalyse parduodančiai platformai PVM automatizavimas yra priklausomų sprendimų grandinė:

Ar klientas yra B2B, ar B2C, ir kur jis įsikūręs?
Kurios šalies tarifas taikomas, kuriai mokesčių kategorijai priskiriama ir kokia buvo sąskaitos faktūros išrašymo data?
Ar tiekimui taikomas atvirkštinis apmokestinimas (reverse charge), ar jis deklaruojamas per OSS, IOSS, o gal tai vietinis tiekimas?
Ar prekyvietė (marketplace) buvo laikoma tariama tiekėja (deemed supplier), ar pats prekybininkas?
Kokie įrodymai pagrindžia kiekvieną iš šių atsakymų ir ar juos galima atkurti vėliau?

Skaičiaus automatizavimas neautomatizuojant pagrindimo yra tai, kas sukelia klasikinę audito nesėkmę: sumos teisingos, bet nėra jokios apginamos sekos. Šiuolaikiniai mokesčių varikliai vis dažniau reklamuoja auditui parengtas įrodymų sekas ir istorinius tarifų tikrinimus būtent todėl, kad dabar priežiūros institucijos sutelkia dėmesį į tai, kaip buvo priimtas PVM sprendimas, o ne tik koks jis buvo.

Debesijos apskaitos API yra natūrali vieta šiai sekai saugoti, nes joje jau saugoma sąskaita faktūra, didžiosios knygos dvejybinis įrašas ir kontrahentas. Nordlet yra sukurta remiantis šia idėja: nekintanti dvejybinio įrašo didžioji knyga, konkrečiai šaliai skirta PVM logika, VIES patvirtinimas ir i.SAF registro generavimas – visa tai pasiekiama per vieną REST sąsają su tipizuotais SDK ir „webhook“ pranešimais. Šis API nėra tik plonas apvalkalas virš buhalterinės apskaitos. Tai yra paties sprendimo registravimo sistema (system of record).

Trys esminės API galimybės, turinčios didžiausią svorį

Dauguma PVM automatizavimo darbų susiveda į tris galimybes, kurias apskaitos API turi aiškiai pateikti.

1. Tarifų turinys ir mokesčių kategorijos, susietos su data. Tarifai keičiasi. Kategorijos keičiasi. Lengvatiniai tarifai pridedami ir panaikinami. Veikiantis modelis, kaip teigiama „Sage“ kūrėjų gairėse apie ES PVM reformą ir apskaitos API, yra susieti prekes ir paslaugas su mokesčių kategorijomis, o tada mokesčių kategorijas susieti su konkrečiai šaliai skirtais kodais ir jų įsigaliojimo datomis. Fiksuotas tarifo įrašymas (hard-coding) kiekvienai prekei ir šaliai yra netinkama praktika, kurios pasekmės tyliai kaupiasi, kol po metų pasikeitęs tarifas viską sugriauna.

2. PVM mokėtojo kodo patvirtinimas su grakščiu funkcijų susiaurinimu (graceful degradation). VIES yra oficialus šaltinis tarpvalstybiniam B2B patvirtinimui. Tačiau jis kartais būna nepatikimas. Išmintingos implementacijos talpyklose (cache) saugo patvirtinimus su trumpais TTL, kartoja užklausą įvykus klaidai ir nukreipia neaiškius atvejus į peržiūros eilę, užuot blokavusios pardavimą. Idėja, kad VIES turi sinchroniškai suveikti kiekvienai operacijai, yra tai, kur platformos pačios sau susikuria prastovas.

3. Įrodymų fiksavimas ir nekintamumas. Kiekvienas PVM sprendimas turėtų išsaugoti savo įvesties duomenis: kliento šalies signalus, PVM mokėtojo kodą ir patvirtinimo laiko žymą, mokesčių kategoriją, tarifų lentelės versiją, taikomą schemą (vietinė, OSS, IOSS, atvirkštinis apmokestinimas) ir prekyvietės vaidmenį. Šis įrašas turi išlikti po tarifų pasikeitimų ir konfigūracijos redagavimų. Nekintanti didžioji knyga su laikotarpių užrakinimu (period locking), kurį Nordlet užtikrina API lygiu, reiškia, kad uždarytas mėnuo negali būti tyliai perrašytas, jog vėlesnis auditas atrodytų tvarkingiau.

Šios trys galimybės yra pagrindas. Viskas kita, įskaitant OSS deklaravimą, i.SAF generavimą ir derinimą (reconciliation), statoma ant jų.

PVM sprendimo, o ne tik tarifo, modeliavimas

Dažniausia integruotos apskaitos (embedded accounting) klaida yra mokesčio laukelio sąskaitoje faktūroje traktavimas kaip paieškos rezultato. Taip nėra. Tai nedidelio sprendimų grafo rezultatas, ir būtent šis grafas turi būti išsaugotas.

Veikiantis modelis:

Klasifikuokite kontrahentą. B2B arba B2C. Jei tai B2B, patikrinkite PVM mokėtojo kodą VIES sistemoje ir išsaugokite atsakymą, įskaitant laiko žymą ir būseną. Jei B2C, užfiksuokite bent du buvimo vietos signalus: atsiskaitymo adresą, IP arba geolokaciją ir, jei įmanoma, mokėjimo priemonės šalį.
Nustatykite tiekimo vietą. Skaitmeninėms paslaugoms PVM taikomas pagal kliento, o ne tiekėjo, buvimo vietą. Prekėms taisyklės skiriasi priklausomai nuo siuntos kilmės ir paskirties vietos. API turėtų pažymėti kiekvieną sąskaitos faktūros eilutę su išvesta tiekimo vieta ir panaudotais signalais.
Pasirinkite schemą. Vietinė, OSS (tarpvalstybinė B2C ES viduje), IOSS (mažos vertės importas) arba atvirkštinis apmokestinimas. Ribos skaičiavimo logika, ypač €10,000 tarpvalstybinė B2C riba skaitmeninėms paslaugoms, turi būti apskaičiuojama pagal slenkantį laikotarpį (rolling window), o ne tik dabartinei sąskaitai faktūrai atskirai.
Nustatykite tarifą. Raskite šalies tarifą atitinkamai mokesčių kategorijai sąskaitos faktūros išrašymo dieną. Išsaugokite naudotą tarifų lentelės versiją.
Užregistruokite didžiojoje knygoje. Įrašykite dvejybinį įrašą su mokėtinu PVM, padalintu pagal šalį ir schemą, kad OSS deklaracijas ir vietines PVM deklaracijas būtų galima parengti iš naujo nevedant duomenų.

Kiekvienas žingsnis turi būti matomas per API. „Webhook“ pranešimai, tokie kaip sale_invoice.paid, leidžia priklausomoms sistemoms reaguoti į būsenos pokyčius nenaudojant nuolatinės apklausos (polling). Idempotencijos raktai apsaugo nuo besidubliuojančių įrašų didžiojoje knygoje, kai tinklo pakartojimas (retry) įvyksta netinkamu momentu. Nė viena iš šių funkcijų nėra egzotiška, tačiau platformos mastu jos abi yra privalomos.

OSS, IOSS ir €10,000 riba

SaaS ir skaitmeninėms paslaugoms praktinė automatizavimo problema yra OSS. Tiekėjas, parduodantis tarpvalstybiniu B2C principu ES viduje, taiko savo šalies tarifą, kol einamaisiais arba praėjusiais kalendoriniais metais viršijama €10,000 riba, tuomet pradeda taikyti kliento valstybės narės tarifą ir kas ketvirtį deklaruoja per OSS. Praktiniame vadove apie PVM atitiktį SaaS ir skaitmeninėms paslaugoms tai apibrėžiama kaip duomenų srauto (pipeline), o ne registracijos problema.

Duomenų srautas, kurį turi palaikyti apskaitos API:

Stebėti tarpvalstybines B2C pajamas atsižvelgiant į ribą, kiekvienais kalendoriniais metais kaupiamuoju principu.
Automatiškai perjungti tarifo nustatymą iš buveinės šalies į paskirties šalį, kai viršijama riba, neatgaliojant ankstesnių sąskaitų faktūrų.
Grupuoti operacijas pagal valstybę narę, schemą ir valiutą ketvirtinei OSS deklaracijai.
Konvertuoti sumas į EUR taikant teisingą valiutos kursą OSS deklaravimo datai.
Eksportuoti deklaracijai paruoštą duomenų rinkinį formatu, kurį gali naudoti deklarantas ar deklaravimo paslauga.

Nordlet tai išsprendžia per konkrečios šalies PVM logiką didžiojoje knygoje ir ataskaitas, kurios grupuoja pagal schemą ir valstybę narę: OSS deklaracijos skaičiuojamos iš pačių sąskaitų faktūrų su ankstesnių laikotarpių pataisymais, o €10,000 riba sekama automatiškai. Deklaracija išvedama iš didžiosios knygos, o ne kiekvieną ketvirtį atkuriama nuo nulio. Būtent todėl sprendimų grafas perkeliamas į apskaitos sistemą, o ne paliekamas atskiroje skaičiuoklėje.

IOSS schemai taikomas tas pats principas mažos vertės importui, tik su kitomis ribomis ir kita deklaracija.

Prekyviečių ir platformų srautai yra atskira kategorija

Traktuoti prekyvietę kaip įprastą B2C kanalą yra ta vieta, kur stebėtinai daug sistemų daro klaidų. Daugelyje ES scenarijų platforma laikoma tariama tiekėja (deemed supplier) ir yra atsakinga už PVM surinkimą bei sumokėjimą. Paties prekybininko apskaita turi atspindėti, kad šiose operacijose su PVM susijęs kontrahentas yra platforma, o ne galutinis klientas.

Būtent čia integruota apskaitos API įrodo savo vertę. Pardavimo momentu platforma žino, ar ji veikė kaip tariama tiekėja. Šis faktas turi būti įrašytas į sąskaitos faktūros įrašą ir perkeltas į didžiąją knygą, kad prekybininko apskaitoje nebūtų dvigubai skaičiuojamas PVM, kuriuo jau pasirūpino platforma. Mokesčių vaidmens indikatorių perdavimas per API ir jų atspindėjimas ataskaitose yra skirtumas tarp švarios apskaitos ir derinimo, kuris niekada iki galo nesutampa.

Platformoms, kuriančioms savo sistemas ant Nordlet, tai yra pamatinė funkcija (first-class): sąskaitose faktūrose yra vatScheme (įskaitant marketplace_deemed) ir deemedSupplier požymiai, o apmokestinimo taisyklės nustatymo įrankis grąžina taikomą schemą kartu su jos teisiniu pagrindu pagal Direktyvą 2006/112/EB. Kartu su kelių įmonių palaikymu platformos ir prekybininko apskaita gali veikti tame pačiame API, naudojant skirtingas įmones ir vaidmenis, be jokio PVM įrašų nutekėjimo tarp jų.

Ką ViDA keičia ir ko nekeičia

Skaitmeninio amžiaus PVM (ViDA) keičia automatizavimo formą iš „apskaičiuoti ir užregistruoti“ į „apskaičiuoti, užregistruoti ir perduoti“. E. sąskaitos faktūros ir ataskaitų teikimas mokesčių inspekcijoms beveik realiu laiku tampa šio proceso dalimi. Tai nepakeičia apskaitos API. Tai paverčia apskaitos API struktūrizuotus sąskaitų faktūrų duomenis šaltiniu, kuris atspindimas teikimo sąsajoje.

Dvi praktinės pasekmės:

Sąskaitų faktūrų metaduomenys turi būti išsamesni, nei leidžia dauguma senųjų schemų. Peppol BIS 3.0 laukai, struktūrizuotas PVM paskirstymas kiekvienai eilutei ir schemų identifikatoriai turi būti pamatinės (first-class) apskaitos API savybės, o ne pridedamos kaip laisvo teksto pastabos.
Apskaitos dokumentas ir pateiktas dokumentas turi būti sinchronizuojami. Jei išrašoma kreditinė sąskaita faktūra, teikimo sąsaja turi matyti klaidų ištaisymą su tais pačiais identifikatoriais. Nekintančios didžiosios knygos ir aiški dokumentų kilmės istorija tai padaro nesudėtingu procesu. Laisvas požiūris į apskaitą paverčia tai skausmingu.

Pasiruošimas ViDA yra susijęs ne tiek su naujomis funkcijomis, kiek su esamų procesų disciplinos griežtinimu.

Trumpas automatizavimo metodų palyginimas

Metodas	PVM sprendimo įrodymai	OSS / IOSS apdorojimas	Prekyvietės vaidmens modeliavimas	Tinkamumas integruotoms platformoms
Rankinė apskaita su skaičiuoklėmis	Silpni, atkuriami po fakto	Rankinis, jautrus klaidoms	Dažniausiai ignoruojamas	Prastas
Senoji apskaitos programinė įranga su prijungtu mokesčių moduliu	Daliniai, dažnai už didžiosios knygos ribų	Palaikoma, bet izoliuota	Ribotas	Nuo prasto iki vidutinio
Universali apskaitos API (Xero, QuickBooks stiliaus)	Priklauso nuo integracijos disciplinos	Skiriasi priklausomai nuo rinkos ir priedų	Viešai nepatvirtinta tariamo tiekėjo (deemed supplier) srautams ES kontekste	Vidutinis
Nordlet (orientuota į API ir pritaikyta ES)	Nekintanti didžioji knyga, mokesčių metaduomenys kiekvienai sąskaitai, laikotarpių užrakinimas	Integruotas konkrečios šalies PVM, i.SAF, VIES, OSS pritaikytas grupavimas	Pamatiniame lygyje: `vatScheme`, `deemedSupplier` kiekvienoje sąskaitoje	Puikus

Šioje lentelėje atspindima šiam straipsniui prieinama informacija. Kai konkurento galimybė tyrimo santraukoje nėra dokumentuota, ji paliekama kaip viešai nepatvirtinta, o ne preziumuojama.

Ką kurti pirmiausia, jei pradedate dabar

Jei komanda diegia integruotą ES PVM automatizavimą debesijos apskaitos API aplinkoje, ši seka paprastai padeda išvengti daugiausiai papildomo darbo:

Pirmiausia sumodeliuokite kontrahentą ir jo šalies signalus. Nuo to priklauso kiekvienas tolesnis sprendimas. Išsaugokite signalus, o ne tik išvestinę šalį.
Sukurkite mokesčių kategorijų lygmenį. Susiekite prekes ir paslaugas su kategorijomis. Susiekite kategorijas su šalių kodais. Niekada nesiekite produktų tiesiogiai su tarifais.
Prijunkite VIES patvirtinimą su talpyklos ir peržiūros eilės funkcijomis. Neleiskite, kad VIES pasiekiamumas stabdytų atsiskaitymo procesą.
Siųskite ir priimkite „webhook“ pranešimus apie sąskaitų faktūrų būsenos pokyčius. Kiekvienam įrašymo veiksmui naudokite idempotencijos raktus.
Užrakinkite laikotarpius, vos tik juos uždarote. Užtikrinkite tai API lygyje, o ne įmonės politikoje.
Išveskite OSS deklaracijas iš didžiosios knygos. Jei deklaracijai reikia atskiros skaičiuoklės, vadinasi, didžiojoje knygoje nėra pakankamai metaduomenų.
Tik tada pridėkite e. sąskaitų faktūrų ir ataskaitų sąsajos integraciją. Pradiniai duomenys pirmiausia turi būti teisingi.

Dauguma jų yra vienkartinės investicijos, kurios tyliai atsiperka kiekvieną ketvirtį. Neriboto naudojimo bandomoji aplinka yra pigiausia vieta išbandyti visą šią seką nuo pradžios iki pabaigos.

D.U.K.

Ar pakanka VIES patvirtinimo, norint įrodyti, kad B2B pardavimui buvo teisingai pritaikytas nulinis tarifas?

Paties savaime – ne. VIES tik patvirtina, kad PVM mokėtojo kodas galioja tam tikru momentu. Audito požiūriu apginamą įrašą taip pat sudaro patikrinimo laiko žyma, atsakymo duomenys (payload), kliento nurodyta šalis ir įrodymai, kad prekės ar paslaugos buvo patiektos tam PVM mokėtoju registruotam subjektui. Išsaugokite visa tai susieję su sąskaita faktūra.

Ar platforma gali pasikliauti prekyviete, kad ši pasirūpins PVM, ir praleisti savo logiką?

Tik toms konkrečioms operacijoms, kai pagal ES taisykles prekyvietė yra laikoma tariama tiekėja. Prekybininko apskaitoje vis tiek būtina teisingai atspindėti šias operacijas, o visi pardavimai už šios srities ribų, įskaitant tiesioginius pardavimus ir B2B srautus, lieka prekybininko atsakomybe. Saugesnis numatytasis nustatymas – aiškiai sumodeliuoti vaidmenį kiekvienai operacijai.

Kaip dažnai ES PVM tarifai iš tikrųjų keičiasi tiek, kad tai būtų svarbu?

Pakankamai dažnai, kad kietai įkoduoti tarifai sukeltų realių problemų. Lengvatinių tarifų kategorijos kinta, įvedami ir baigia galioti laikini tarifai, atsiranda naujų valstybių narių taisyklių. Tarifų turinio lygmuo su galiojimo datomis nėra perteklinis programavimas (over-engineering). Tai yra bazinis reikalavimas.

Kuo praktiškai skiriasi OSS ir IOSS?

OSS apima tarpvalstybinius B2C prekių ir skaitmeninių paslaugų pardavimus ES viduje, kurie kas ketvirtį deklaruojami per vieną valstybę narę. IOSS apima mažos vertės importą į ES, paprastai vartojimo prekes iki €150. Abu gaunami iš tų pačių apskaitos duomenų, jei didžiojoje knygoje kiekviena operacija pažymėta atitinkama schema.

Ar nekintanti didžioji knyga reiškia, kad klaidų ištaisymas yra neįmanomas?

Ne. Klaidos taisomos per naujus įrašus, o ne redaguojant senuosius. Kreditinė sąskaita faktūra anuliuoja sąskaitą faktūrą, o stornuojantis įrašas (reversing entry) ištaiso klaidingą įrašą. Nekintamumas užkerta kelią tik tyliam istorijos perrašymui – o būtent tokio elgesio ir ieško auditoriai.