ES PVM atitikties automatizavimas naudojant debesijos apskaitos API

Praktinis vadovas platformoms ir prekyvietėms, kurioms reikia tikrosios buhalterijos, teisingo PVM ir audito pėdsako, galinčio atlaikyti patikrinimus po kelerių metų.

ES PVM jau seniai nėra vien skaičiavimo problema. Tai – įrodymų problema. Tarifai yra paskelbti, ribos žinomos, o OSS deklaracijos – gerai dokumentuotos. Auditus žlugdo ir platformas mastelio didinimo etape palaužia tai, kad neįmanoma atkurti, kaip konkreti PVM išvada buvo padaryta tam tikroje sąskaitoje faktūroje, remiantis taisyklėmis ir duomenimis, kurie egzistavo tuo konkrečiu momentu. Debesijos apskaitos API gali tai automatizuoti nuo pradžios iki pabaigos, tačiau tik tuo atveju, jei ji sukurta aplink sprendimų medį (decision graph), o ne vien aplink tarifą.

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

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

Platformai, parduodančiai į kelias ES šalis, PVM automatizavimas yra tarpusavyje susijusių sprendimų grandinė:

Ar pirkėjas yra verslo (B2B), ar galutinio vartotojo (B2C) segmento subjektas ir kur jis yra įsikūręs?
Kurios šalies tarifas ir kokia mokesčių kategorija taikoma sąskaitos faktūros išrašymo dieną?
Ar tiekimui taikomas atvirkštinis apmokestinimas (reverse-charge), OSS, IOSS, ar tai vietinis sandoris?
Ar prekyvietė buvo laikoma prekių/paslaugų teikėju (deemed supplier), ar pardavėjas?
Kokie įrodymai pagrindžia kiekvieną iš šių atsakymų ir ar juos vėliau bus galima atkurti?

Skaičiaus automatizavimas neautomatizuojant logikos sukuria klasikinę audito nesėkmę: sumos teisingos, tačiau jokio pagrindžiančio pėdsako nėra. Šiuolaikiniai mokesčių varikliai vis dažniau siūlo audito lygio įrodymų pėdsakus ir istorinę tarifų paiešką būtent todėl, kad kontrolieriai dabar orientuojasi į tai, kaip buvo priimtas PVM sprendimas, o ne tik į jo galutinę vertę.

Debesijos apskaitos API yra natūrali vieta šiam pėdsakui saugoti, nes joje jau saugoma sąskaita faktūra, didžiosios knygos (general ledger) įrašas ir sandorio partneris. „Nordlet“ yra sukurta remiantis šia idėja: nekintama (immutable) dvigubo įrašo (double-entry) didžioji knyga, kiekvienos šalies PVM logika, VIES patvirtinimas ir i.SAF registru generavimas – visa tai pasiekiama per vieną REST sąsają su tipizuotais SDK ir webhook pranešimais. API nėra tik plonas buhalterijos apvalkalas. Tai paties sprendimo apskaitos sistema.

Trys API galimybės, kurios atlieka pagrindinį darbą

Didžioji dalis PVM automatizavimo darbo susiveda į tris galimybes, kurias apskaitos API turi sklandžiai pateikti.

1. Tarifų turinys ir mokesčių kategorijos, susietos su data. Tarifai keičiasi. Kategorijos keičiasi. Lengvatiniai tarifai pridedami ir šalinami. Veiksmingas modelis, kaip teigia „Sage“ kūrėjams skirta dokumentacija apie ES PVM reformą ir apskaitos API, yra prekes susieti su mokesčių kategorijomis, tuomet mokesčių kategorijas susieti su konkrečios šalies kodais ir įsigaliojimo datomis. Tarifo kodavimas tiesiogiai prekei kiekvienoje šalyje yra klaidingas modelis, kuris tyliai kaupiasi, kol pasikeitęs tarifas po metų sugadina sistemą.

2. PVM mokėtojo kodų (VAT ID) tikrinimas su lanksčiu klaidų valdymu. VIES yra pagrindinis tarpvalstybinio B2B tikrinimo šaltinis. Jis taip pat kartais būna nepatikimas. Protingi sprendimai kaupimo talpykloje (cache) saugo patvirtinimus su trumpu galiojimo laiku (TTL), bando pakartoti užklausą nesėkmės atveju, o dviprasmiškus atvejus nukreipia į peržiūros eilę, vietoj to, kad blokuotų pardavimą. Įsitikinimas, kad VIES turi sinchroniškai sėkmingai veikti kiekvienos transakcijos metu, yra priežastis, dėl kurios platformos pačios susikuria sistemos trikdžius.

3. Įrodymų surinkimas ir nekintamumas. Kiekvienas PVM sprendimas turi saugoti savo įvesties duomenis: kliento šalies signalus, PVM mokėtojo kodą ir patvirtinimo laiko žymą (timestamp), mokesčių kategoriją, tarifų lentelės versiją, taikomą schemą (vietinė, OSS, IOSS, atvirkštinis apmokestinimas) ir prekyvietės vaidmenį. Tas įrašas turi išgyventi tarifų pasikeitimus ir konfigūracijos koregavimus. Nekintama didžioji knyga su laikotarpių užrakinimu (period locking), kurią „Nordlet“ užtikrina API lygiu, reiškia, kad uždaryto mėnesio negalima tyliai perrašyti, kad vėlesnis auditas atrodytų gražiau.

Šios trys galimybės yra pagrindas. Viskas kita, įskaitant OSS teikimą, i.SAF generavimą ir suderinimą, dedasi ant viršaus.

PVM sprendimo, o ne tik tarifo modeliavimas

Dažniausia įterptosios apskaitos nesėkmės priežastis – traktavimas, kad mokesčių laukas sąskaitoje faktūroje yra paieškos rezultatas. Taip nėra. Tai mažo sprendimo medžio rezultatas, ir būtent šį medį reikia išsaugoti.

Veikiantis modelis:

Klasifikuokite sandorio partnerį. B2B arba B2C. Jei tai B2B, patikrinkite PVM mokėtojo kodą per VIES ir išsaugokite atsakymą, įskaitant laiko žymą bei statusą. Jei tai B2C, surinkite bent du buvimo vietos signalus: atsiskaitymo adresą, IP arba geolokaciją ir, jei įmanoma, mokėjimo priemonės šalį.
Nustatykite paslaugų/prekių teikimo vietą (place of supply). Skaitmeninėms paslaugoms PVM seka kliento, o ne teikėjo buvimo vietą. Prekėms taisyklės skiriasi priklausomai nuo siuntimo kilmės ir paskirties vietos. API turi pažymėti kiekvieną sąskaitos faktūros eilutę nustatyta teikimo vieta ir panaudotais signalais.
Pasirinkite schemą. Vietinė, OSS (tarpvalstybinis B2C ES viduje), IOSS (mažos vertės importas) arba atvirkštinis apmokestinimas. Slibo ribų (threshold) logika, ypač 10 000 EUR tarpvalstybinio B2C riba skaitmeninėms paslaugoms, turi būti skaičiuojama pagal slenkantį langorį (rolling window), o ne atskirai pagal einamąją sąskaitą faktūrą.
Nustatykite tarifą. Raskite šalies tarifą mokesčių kategorijai sąskaitos faktūros išrašymo dieną. Išsaugokite naudotą tarifų lentelės versiją.
Įrašykite į didžiąją knygą. Sukurkite dvigubo įrašo įrašą su mokėtinu PVM, išskirtu pagal šalis ir schemas, kad OSS ir vietines PVM deklaracijas būtų galima parengti iš naujo nepervedant duomenų.

Kiekvienas žingsnis turi būti matomas per API. Webhook pranešimai, tokie kaip sale_invoice.paid, leidžia tolesnėms sistemoms reaguoti į būsenos pasikeitimus be nuolatinio užklausų siuntimo (polling). Idempotentiškumo raktai (idempotency keys) apsaugo nuo dvigubų didžiosios knygos įrašų, jei tinklo pakartotinis bandymas įvyksta netinkamu momentu. Nei vienas iš jų nėra egzotika, tačiau abu yra būtini esant platformos masteliui.

OSS, IOSS ir 10 000 EUR riba

SaaS ir skaitmeninėms paslaugoms praktinė automatizavimo problema yra OSS. Tiekėjas, parduodantis tarpvalstybiniu mastu B2C segmente ES viduje, taiko savo šalies tarifą, kol einamaisiais arba praėjusiais kalendoriniais metais viršijama 10 000 EUR riba, o tada taiko pirkėjo valstybės narės tarifą ir kas ketvirtį atsiskaito per OSS. Praktinės gairės dėl PVM atitikties SaaS ir skaitmeninėms paslaugoms šią problemą priskiria duomenų konvejerio (pipeline), o ne registracijos kategorijai.

Konvejeris, kurį turi palaikyti apskaitos API:

Sekti tarpvalstybines B2C pajamas lyginant jas su riba slenkančiu principu per kalendorinius metus.
Automatiškai perjungti tarifo nustatymą iš namų šalies į paskirties šalį viršijus ribą, atgaline data nekeičiant ankstesnių sąskaitų faktūrų.
Grupuoti operacijas pagal valstybę narę, schemą ir valiutą ketvirčio OSS deklaracijai.
Konvertuoti sumas į EUR pagal teisingą valiutos kursą OSS ataskaitoms teikti.
Eksportuoti deklaracijai paruoštą duomenų rinkinį formatu, kurį gali apdoroti teikėjas arba teikimo paslauga.

„Nordlet“ tai sprendžia taikydama kiekvienos šalies PVM logiką didžiojoje knygoje ir ataskaitų teikimą, kuris grupuoja pagal schemas ir valstybes nares: OSS deklaracijos apskaičiuojamos iš pačių sąskaitų faktūrų, įskaitant ankstesnių laikotarpių pataisymus, o 10 000 EUR riba sekama automatiškai. Deklaracija yra kildinama iš didžiosios knygos, o ne atkuriama nuo nulio kiekvieną ketvirtį. Tai ir yra sprendimo medžio perkėlimo į apskaitos sistemą, o ne į atskirą skaičiuoklę, prasmė.

IOSS atveju galioja ta pati struktūra mažos vertės importui, tik su skirtingomis ribomis ir kita deklaracija.

Prekyviečių ir platformų srautai yra atskiroje kategorijoje

Prekyvietės traktavimas kaip įprasto B2C kanalo yra vieta, kur klysta stebėtinai daug diegimų. Daugeliu ES scenarijų platforma yra laikoma prekių/paslaugų teikėju (deemed supplier) ir yra atsakinga už PVM surinkimą bei sumokėjimą. Paties pardavėjo apskaitoje turi atsispindėti, kad PVM atveju sandorio šalis yra platforma, o ne galutinis pirkėjas.

Štai čia įterptoji apskaitos API uždirba savo vertę. Platforma pardavimo metu žino, ar ji veikė kaip pripažintas teikėjas. Šis faktas turi būti įrašytas į sąskaitos faktūros įrašą ir perkeltas į didžiąją knygą, kad pardavėjo knygose nebūtų dvigubai skaičiuojamas PVM, kurį platforma jau sutvarkė. Mokesčių vaidmens indikatorių perdavimas per API ir jų atvaizdavimas ataskaitose skiria švarią buhalteriją nuo nesibaigiančio suderinimo.

Platformoms, kuriančioms ant „Nordlet“, tai yra savaime suprantama: sąskaitos faktūros turi lauką vatScheme (įskaitant marketplace_deemed) ir žymą deemedSupplier, o apdorojimo moduliatorius (treatment resolver) gražina taikomą schemą kartu su jos teisiniu pagrindu pagal Direktyvą 2006/112/EB. Kartu su kelių įmonių (multi-company) palaikymu, platformos ir pardavėjo apskaita gali gyventi po tuo pačiu API stogu, su skirtingomis įmonėmis ir skirtingais vaidmenimis, neperkeliant PVM įrašų tarp jų.

Ką ViDA keičia, o ko ne

PVM skaitmeniniame amžiuje (VAT in the Digital Age – ViDA) keičia automatizavimo pobūdį iš „apskaičiuok ir užregistruok“ į „apskaičiuok, užregistruok ir perduok“. E. sąskaitų faktūrų išrašymas ir beveik realiu laiku vykdomas ataskaitų teikimas mokesčių administratoriui tampa konvejerio dalimi. Tai nepakeičia apskaitos API. Dėl to apskaitos API struktūrizuoti sąskaitų faktūrų duomenys tampa šaltiniu, kuris atspindimas ataskaitų teikimo šliuze.

Dvi praktinės pasekmės:

Sąskaitų faktūrų metaduomenys turi būti turtingesni, nei leidžia dauguma senųjų schemų. „Peppol BIS 3.0“ laukai, struktūrizuotas PVM išskaidymas pagal eilutes ir schemų identifikatoriai apskaitos API turi būti pirmo lygio objektai, o ne įrašyti kaip laisvo teksto pastabos.
Apskaitos dokumentas ir teikiamas dokumentas turi išlaikyti sinchronizaciją. Jei išrašomas kredito avizas, ataskaitų teikimo šliuzas turi matyti pataisymą su tais pačiais identifikatoriais. Nekintamos didžiosios knygos ir aiški dokumentų kilmė (lineage) tai padaro paprastais. Aplaidi buhalterija tai paverčia kančia.

Pasiruošimas ViDA reiškia mažiau naujų funkcijų ir daugiau jau egzistuojančios drausmės sugriežtinimo.

Trumpa automatizavimo požiūrių apžvalga

Požiūris	PVM sprendimo įrodymai	OSS/IOSS valdymas	Prekyvietės vaidmens modeliavimas	Tinkamumas įterptosioms platformoms
Rankinė buhalterija su skaičiuoklėmis	Silpni, atkuriami po fakto	Rankinis, linkęs į klaidas	Dažniausiai ignoruojamas	Prastas
Senoji apskaitos programinė įranga su papildomu mokesčių moduliu	Daliniai, dažnai už didžiosios knygos ribų	Palaikomas, bet izoliuotas	Ribotas	Nuo prasto iki vidutinio
Bendrinė apskaitos API („Xero“, „QuickBooks“ stiliaus)	Priklauso nuo integracijos drausmės	Skiriasi priklausomai nuo rinkos ir priedų	Oficialiai nepatvirtinta teikėjo vaidmens srautams ES kontekste	Vidutinis
„Nordlet“ (API-first, orientuota į ES)	Nekintama didžioji knyga, mokesčių metaduomenys sąskaitoje, laikotarpių užrakinimas	Vietinė kiekvienos šalies PVM logika, i.SAF, VIES, OSS pasiruošimas	Pirmo lygio: `vatScheme`, `deemedSupplier` kiekvienai sąskaitai	Stiprus

Šioje lentelėje atsispindi šiam straipsniui surinkti įvesties duomenys. Tais atvejais, kai konkurento galimybės nėra dokumentuotos tyrimo medžiagoje, paliekama pastaba, kad tai nėra viešai patvirtinta, o ne daromos prielaidos.

Ką kurti pirmiausia, jei pradedate dabar

Jei komanda įdiegia įterptąją ES PVM automatizavimą naudojant debesijos apskaitos API, eiliškumas, kuris dažniausiai sutaupo daugiausiai perdirbimo laiko:

Pirmiausia sumodeliuokite sandorio partnerį ir jo šalies signalus. Visi tolesni sprendimai priklauso nuo to. Saugokite signalus, o ne tik nustatytą šalį.
Sukurkite mokesčių kategorijų sluoksnį. Susiekite produktus ir paslaugas su kategorijomis. Susiekite kategorijas su šalių kodais. Niekada nesusiekite produktų tiesiogiai su tarifais.
Prijunkite VIES tikrinimą su kaupimu talpykloje ir peržiūros eile. Neleiskite, kad VIES pasiekiamumas stabdytų jūsų atsiskaitymo procesą.
Siųskite ir vartokite webhook pranešimus apie sąskaitų faktūrų būsenos pasikeitimus. Kiekvienam rašymo veiksmui naudokite idempotentiškumo raktus.
Užrakinkite laikotarpius vos jiems pasibaigus. Užtikrinkite tai API lygiu, o ne taisyklėmis.
Kelkite OSS deklaracijas iš didžiosios knygos. Jei deklaracijai reikia atskiros skaičiuoklės, didžiojoje knygoje trūksta metaduomenų.
Tik tada pridėkite e. sąskaitų faktūrų ir ataskaitų šliuzo integraciją. Pirmiausia privalo būti tvarkingi pradiniai duomenys.

Dauguma šių investicijų yra vienkartinės ir tyliai atsiperka kas ketvirtį. Neribota smėlio dėžės (sandbox) įmonė yra pigiausia vieta įrodyti šį eiliškumą nuo pradžios iki pabaigos.

D.U.K.

Ar VIES patvirtinimo pakanka įrodyti, kad B2B pardavimui buvo teisingai taikytas 0 proc. PVM tarifas?

Ne vien paties patvirtinimo. VIES patvirtina, kad PVM mokėtojo kodas yra galiojantis tam tikru metu. Auditui atsparus įrašas taip pat apima patikrinimo laiko žymą, atsakymo duomenis, kliento nurodytą šalį ir įrodymus, kad prekės ar paslaugos buvo patiektos tam PVM mokėtojui. Visa tai išsaugokite prie sąskaitos faktūros.

Ar platforma gali pasikliauti prekyviete, kad ši tvarkytų PVM, ir praleisti savo logiką?

Tik tiems konkrečiams sandoriams, kuriuose prekyvietė pagal ES taisykles yra laikoma teikėju (deemed supplier). Paties pardavėjo apskaitoje vis tiek turi tinkamai atsispindėti šie sandoriai, o visi pardavimai už šios taikymo srities ribų, įskaitant tiesioginius pardavimus ir B2B srautus, lieka pardavėjo atsakomybe. Saugesnis variantas yra aiškiai sumodeliuoti vaidmenį kiekvienam sandoriui atskirai.

Kaip dažnai ES PVM tarifai keičiasi iš tikrųjų?

Pakankamai dažnai, kad užkoduoti tarifai keltų realių problemų. Keičiasi lengvatinių tarifų kategorijos, įvedami ir baigiasi laikini tarifai, atsiranda naujų valstybių narių taisyklių. Tarifų turinio sluoksnis su įsigaliojimo datomis nėra perteklinis inžinerinis sprendimas. Tai yra minimalus pagrindas.

Kuo praktikoje skiriasi OSS ir IOSS?

OSS apima tarpvalstybinius B2B/B2C prekių ir skaitmeninių paslaugų pardavimus ES viduje, deklaruojamus kas ketvirtį per vieną valstybę narę. IOSS apima mažos vertės importą į ES, paprastai iki 150 EUR vertės vartojimo prekes. Abi sistemos kyla iš tų pačių apskaitos duomenų, jei didžiojoje knygoje kiekvienas sandoris pažymėtas savo schema.

Ar nekintama didžioji knyga reiškia, kad pataisymai yra neįmanomi?

Ne. Pataisymai atliekami per naujus įrašus, o ne redaguojant senuosius. Kredito avizas anuliuoja sąskaitą faktūrą, atvirkštinis įrašas ištaiso klaidingą įrašą. Nekintamumas neleidžia tyliai perrašyti istorijos, o būtent to ir ieško auditoriai.