PVM ataskaitų teikimo pagal šalis ir VIES tikrinimo automatizavimas

Dauguma PVM klaidų platformos kode kyla iš vienos prielaidos: kad galiojantis VIES rezultatas reiškia, jog pardavimui galima taikyti nulinį tarifą. Taip nėra, ir remiantis tokiu supaprastinimu sugeneruojamos ataskaitos, kurios atrodo gerai tol, kol auditorius paklausia, kodėl ES vidaus (intra-EU) neapmokestinimas PVM buvo pritaikytas be transportavimo įrodymų arba be nuoseklaus paslaugų suteikimo vietos (place-of-supply) įrašo. Būtent atotrūkis tarp „PVM mokėtojo kodas patvirtintas“ ir „šis tiekimas vertinamas teisingai“ yra ta vieta, kur dauguma integracijų tyliai sugenda.

Šiame vadove aprašoma, kaip automatizuoti PVM ataskaitų teikimą pagal šalis ir VIES tikrinimą naudojant debesijos apskaitos API, pasitelkiant Nordlet's accounting API kaip įgyvendinimo pavyzdį. Tikslas – sukurti sistemą, kuri pardavimo momentu surenka tinkamus įrodymus, sukuria nekeičiamus didžiosios knygos įrašus ir parengia deklaravimui paruoštus duomenis, sugrupuotus pagal schemą ir valstybę narę, nereikalaujant vėliau iš naujo skaičiuoti sumų skaičiuoklėje.

Ką VIES iš tikrųjų parodo, ir ko ne

VIES yra ES PVM informacijos mainų sistema. Kai pateikiate šalies kodą ir PVM mokėtojo kodą, ji realiuoju laiku pateikia užklausą atitinkamai nacionalinei duomenų bazei ir grąžina atsakymą, ar ta PVM informacija yra galiojanti, ar negaliojanti. Tai ir yra visa jos apimtis. Ji patvirtina, kad kodas yra registruotas ir, jei valstybė narė tai palaiko, aktyvuotas prekybai ES viduje.

Ji nesuteikia teisės neapmokestinti prekių tiekimo Bendrijos viduje (intra-Community supply). Europos Komisija tai aiškiai nurodo. Galiojantis VIES atsakymas yra tik vienas iš kelių įrodymų. Jums vis tiek reikia patvirtinti, kad pirkėjas yra faktinis gavėjas, kad tiekimas atitinka ES vidaus prekybos sąlygas, kad yra transportavimo ar išsiuntimo įrodymų ir kad sąskaitoje faktūroje yra nurodyta reikiama atvirkštinio apmokestinimo (reverse-charge) formuluotė.

Todėl pirmasis projektavimo sprendimas yra struktūrinis: VIES statusą ir PVM vertinimą (VAT treatment) laikykite atskiruose laukuose. Niekada nesusiekite viesStatus: valid tiesiogiai su zeroRated: true. Kai tik sujungiate šias dvi sąvokas, prarandate galimybę pagrįsti taikytą mokestinį vertinimą, kai kyla abejonių dėl įrodymų.

Būtinosios sąlygos prieš rašant integracijos kodą

Prieš iškviečiant bet kokį galinį punktą (endpoint), apibrėžkite, ką tiksliai deklaruosite. Ši dalis yra nuobodi, bet jos praleidimas kainuoja brangiai.

• Kuriose šalyse įmonė yra įsisteigusi ar turi nuolatines buveines (fixed establishments)
• Kuriose šalyse ji registruota PVM mokėtoja
• Ar ji parduoda prekes, paslaugas, skaitmenines paslaugas, ar viską kartu
• Ar sandoriai yra B2B, B2C, ar abiejų tipų
• Ar ji naudoja vietines registracijas, OSS, IOSS, atvirkštinį apmokestinimą, ar prekyvietės kaip numanomo tiekėjo (deemed-supplier) taisykles
• Kokius rezultatus API turi sugeneruoti: vietinių deklaracijų duomenis, OSS/IOSS duomenis, sąskaitų faktūrų registrus, tokius kaip Lietuvos i.SAF, tik įrašus didžiojoje knygoje, ar naudingąją apkrovą (payloads), skirtą atskiram deklaravimo paslaugų teikėjui

Tai svarbu, nes OSS neapima kiekvieno sandorio. Paslaugos, suteiktos šalyje, kurioje įmonė turi buveinę, paprastai priskiriamos tos šalies vietinei PVM deklaracijai, o ne OSS deklaracijai. Nuo pat pradžių modeliuokite buveines atskirai, kitaip agregavimo metu neteisingai nukreipsite šiuos tiekimus.

Taip pat neįrašykite kietuoju kodu (hard-code) vieno PVM tarifo vienai šaliai. ES taikomi standartiniai, lengvatiniai, ypač lengvatiniai, automobilių stovėjimo (parking), nuliniai (zero-rated) ir konkretiems produktams skirti PVM tarifai, ir jie keičiasi. Patikimas šaltinis konkrečiam produktui konkrečioje valstybėje narėje yra tos šalies mokesčių inspekcija, o Komisijos TEDB suteikia galimybę apžvelgti situaciją įvairiose šalyse. Užfiksuokite šaltinį ir versiją prie kiekvieno tarifo sprendimo, kad vėliau atnaujinus tarifų lentelę nebūtų tyliai perrašyta tai, kaip atvaizduojamas senas sandoris.

Mokestinio sprendimo, ne tik tarifo, modeliavimas

Tvarios integracijos pagrindas yra mokesčių kategorijų sluoksnis, esantis tarp produktų ir tarifų. Susiekite produktus su kategorijomis, kategorijas – su konkrečios šalies mokesčių kodais, o tada – su tarifais, galiojančiais tam tikru laikotarpiu (effective-dated rates):

product/service
    → tax category
    → country-specific tax code
    → effective-dated rate and treatment

Nesaugi versija, sukelianti deklaravimo nukrypimus (reporting drift), yra product SKU → 21% VAT. Tas pats produktas skirtingose šalyse apmokestinamas skirtingais tarifais, o tarifas gali pasikeisti viduryje laikotarpio. Pats Nordlet PVM atitikties vadovas rekomenduoja naudoti būtent šį, kategorijomis pagrįstą susiejimą, o ne tiesiogiai rišti produktus prie procentų.

Jūsų mokesčių kategorijų taksonomija turėtų būti stabili ir vidinė: standartinio tarifo prekės, lengvatinio tarifo prekės, elektroniniu būdu teikiamos paslaugos, įprastos paslaugos, neapmokestinamas tiekimas (exempt supply), nulinio tarifo tiekimas (zero-rated supply), ES vidaus B2B atvirkštinis apmokestinimas, nuotolinė prekyba ES viduje (intra-EU distance sale), IOSS importas, numanomo tiekėjo (deemed-supplier) sandoris. Visi vėlesni procesai remiasi šia taksonomija.

VIES tikrinimas kaip asinchroninė įrodymų rinkimo darbo eiga

Oficiali VIES paslauga pateikia SOAP/WSDL sąsają, kuri priima dviejų raidžių šalies kodą ir PVM mokėtojo kodą. Dokumentuotos jos klaidos yra svarbios jūsų klaidų apdorojimui (error handling): neteisinga įvestis, pasauliniai ir valstybių narių lygiagretumo limitai, paslaugos nepasiekiamumas, valstybės narės nepasiekiamumas ir laiko viršijimai (timeouts). Vertinkite juos kaip skirtingus rezultatus, o ne kaip vieną bendrą „nepavyko“ kategoriją.

Darbo eiga (workflow), kuri atlaiko apkrovą ir auditą, atrodo taip:

1. Normalizuokite PVM ID: paverskite priešdėlį didžiosiomis raidėmis, pašalinkite leistinus tarpus ar skyrybos ženklus ir atskirai išsaugokite pradinę naudotojo įvestą reikšmę.
2. Prieš darydami tinklo užklausą, vietoje patikrinkite šalies kodą ir numerio formatą.
3. Pateikite normalizuotą numerį VIES sistemai.
4. Išsaugokite normalizuotą ID, užklausos ir atsakymo laiko žymas, galiojantį / negaliojantį / neapdorotą statusą, neapdorotą atsakymą (raw response), bet kokią paslaugos klaidą, kliento ir sąskaitos faktūros ID bei aplikacijos priimtą sprendimą.
5. Talpinkite sėkmingus rezultatus podėlyje (cache) apibrėžtą ir dokumentuotą laikotarpį.
6. Pakartokite trumpalaikes technines klaidas su uždelsimu (backoff).
7. Neišspręstus ar prieštaringus atvejus nukreipkite rankinei peržiūrai.
8. Pakartotinai patikrinkite (revalidate), kai podėlyje esantis rezultatas pasensta, arba prieš sandorį, kai šis įrodymas yra reikšmingas.

Nordlet patikrina ES PVM mokėtojo kodą pridedant klientą ir dar kartą jį patikrina prieš išrašant sąskaitą faktūrą, jei ankstesnis rezultatas yra pasenęs – būtent tokio veikimo norėsite, nepriklausomai nuo to, ar patikrinimas vyksta platformoje, ar jūsų pačių kode.

Kritinė taisyklė: nepadarykite atsiskaitymo (checkout) sinchronišku su VIES. Paslaugos sutrikimas nereiškia, kad kodas negaliojantis. Jei pardavimo metu VIES viršija skirtą laiką, sulaikykite sandorį peržiūrai arba priskirkite jam laikiną statusą. Atsiskaitymo blokavimas dėl Komisijos paslaugos nepasiekiamumo yra tiesiog pagalbos užklausų generatorius, o dar blogiau – klaidingai priskirti gerą klientą prie negaliojančių.

Patvirtinimo statuso ir vertinimo atskyrimas

Gavus VIES rezultatą, sprendimų varikliui (decision engine) dar lieka darbo. Saugokite juos kaip atskirus laukus:

{
  "viesStatus": "valid",
  "vatTreatment": "intra_eu_b2b_reverse_charge",
  "evidenceStatus": "reviewed",
  "placeOfSupply": "DE"
}

Prieš taikant atvirkštinį apmokestinimą ar neapmokestinimą PVM, variklis turėtų patikrinti, ar klientas tikrai yra gavėjas, ar kliento šalis ir PVM kodo priešdėlis sutampa, ar tiekimas atitinka ES vidaus prekybos sąlygas, ar taikomos specialios paslaugų teikimo vietos taisyklės, ar yra transportavimo įrodymų, ar pardavėjas veikia kaip numanomas tiekėjas ir ar sąskaitoje faktūroje yra reikiama formuluotė. Galiojantis VIES statusas, neišlaikęs nė vieno iš šių kitų testų, nėra žalia šviesa.

Nekeičiamo PVM sprendimo sukūrimas sąskaitos faktūros išrašymo momentu

Kuriant sąskaitą faktūrą, išsaugokite ir visą sprendimą, o ne tik galutinį tarifą:

invoice
  ├─ line tax category
  ├─ place of supply
  ├─ VAT scheme
  ├─ country-specific rate
  ├─ rate-table version
  ├─ VIES evidence reference
  ├─ location-evidence references
  ├─ legal-basis reference
  └─ marketplace-role flags

ES sąskaitų faktūrų išrašymo taisyklės reikalauja nurodyti tiekėjo ir pirkėjo rekvizitus, sąskaitos faktūros numerį, aprašymą, apmokestinamąją vertę, PVM tarifą, PVM sumą ir bet kokią informaciją apie atvirkštinį apmokestinimą ar neapmokestinimą PVM. Kreditinėse sąskaitose faktūrose (credit notes) ir patikslinimuose turi būti nedviprasmiška nuoroda į pradinę sąskaitą faktūrą.

Nordlet didžioji knyga yra nekeičiama (immutable), todėl taisymai atliekami per naujus įrašus, tokius kaip kreditinės sąskaitos ar atvirkštiniai (storno) įrašai, o ne redaguojant uždarytus įrašus. Kurkite savo vartotoją (consumer) pagal šį modelį, net jei techniškai jūsų saugykla leistų perrašyti duomenis. Uždarytos sąskaitos faktūros redagavimas sunaikina ryšį tarp pradinio deklaravimo ir taisymo, o būtent šią seką ir seka auditorius.

Registravimas, „webhooks“ ir idempotentiškumas

Pardavimas sugeneruoja dvejybinio įrašo (double-entry) buhalterinius įrašus, kurie išsaugo tiek komercinį sandorį, tiek PVM įsipareigojimą, padalytą pagal šalį ir schemą. Vietinis pardavimas gali būti registruojamas taip:

Dr Accounts receivable / payment clearing
    Cr Revenue
    Cr VAT payable — DE — domestic

ES vidaus B2B atvirkštinio apmokestinimo pardavimas registruoja pajamas be pardavimo PVM su nuoroda į atvirkštinio apmokestinimo įrodymus. Tikslus sąskaitų planas (chart of accounts) priklauso nuo jūsų; svarbu tai, kad prie kiekvieno įrašo (posting) liktų prijungtos ataskaitų dimensijos: valstybė narė, schema, mokesčių kategorija, tarifas, laikotarpis, pradinė sąskaita faktūra ir taisymų seka.

Būsenos pasikeitimus valdykite naudodami „webhooks“, o ne apklausas (polling). Nordlet siunčia tokius įvykius kaip sale_invoice.paid, pasirašo pristatymus ir kartoja bandymus su uždelsimu. Kiekvienam rašymo (write) veiksmui priskirkite deterministinį idempotentiškumo raktą:

sale:{platform_order_id}:invoice:{invoice_version}

Jūsų vartotojas taip pat turi būti idempotentiškas. „Webhook“ gali atkeliauti du kartus, atkeliauti vėluodamas arba suveikti po to, kai pradinė užklausa jau buvo sėkminga. Patikrinkite parašus, registruokite įvykių ID, izoliuokite netaisyklingus įvykius, apdorokite juos per patikimą eilę ir reguliariai derinkite „webhook“ būseną su API duomenimis. Jei anksčiau nesate dirbę su pasirašytais „webhooks“ ir idempotentiškumo raktais, būtent čia slypi subtiliausios pasikartojančių įrašų klaidos.

Grupavimas OSS sistemai ir deklaravimui paruoštų eksportų generavimas

Reikalavimus atitinkančius OSS sandorius sugrupuokite didžiosios knygos duomenyse pagal schemą, vartojimo valstybę narę, tiekimo tipą, tarifo kategoriją, tarifą, apmokestinamąją vertę, PVM sumą, išsiuntimo ar įsisteigimo valstybę narę, valiutą ir taisymo laikotarpį.

Sąjungos schemos deklaracijoje tiekimai atskiriami pagal vartojimo valstybę narę, taip pat atskiriamos paslaugos iš identifikavimo valstybės narės, paslaugos iš kitų nuolatinių buveinių ir prekės, išsiųstos iš skirtingų valstybių narių. Apmokestinamoji vertė ir PVM sumos deklaruojamos atskirai standartiniams ir lengvatiniams tarifams. Neapmokestinami ir nulinio tarifo tiekimai išvis neįtraukiami į OSS deklaraciją.

Keletas operatyvinių detalių, dėl kurių dažnai klystama:

• Sąjungos ir ne Sąjungos OSS laikotarpiai yra ketvirtiniai; IOSS yra mėnesiniai. Deklaracijos ir mokėjimai turi būti pateikti iki kito mėnesio pabaigos.
• Nulinė deklaracija yra privaloma kiekvienam laikotarpiui, net jei nebuvo atlikta jokių atitinkamų tiekimų. Sugeneruokite laikotarpio kontrolinį sąrašą ir automatiškai sukurkite nulinės vertės deklaraciją.
• OSS deklaracijos teikiamos eurais, naudojant ECB orientacinį kursą, galiojantį paskutinę mokestinio laikotarpio dieną, jei reikalingas konvertavimas. Išsaugokite šaltinio valiutą, valiutos kursą, kurso datą, konvertuotą sumą ir metodą.

Eksportai turėtų būti imami iš užrakintos didžiosios knygos, o ne iš papildomos skaičiuoklės. Skaičiuoklių sumose prarandami taisymai, išsiuntimo šalys, tarifai ir įrodymai. Eksporte turi būti deklaracijos laikotarpis, schema, vartojimo valstybė narė, išsiuntimo šalis, tiekimo kategorija, tarifas, apmokestinamoji ir PVM suma, valiuta ir pritaikytas FX kursas, einamojo laikotarpio ir praėjusio laikotarpio taisymų sumos, pradinių sąskaitų faktūrų ID, nuorodos į kreditines sąskaitas ir suderinimo sumos.

Būkite tikslūs dėl to, ką API čia pateikia. Nordlet apskaičiuoja OSS ir IOSS deklaracijas iš sąskaitų faktūrų ir didžiosios knygos, įskaitant praėjusių laikotarpių taisymus, paruošia vietinių deklaracijų paketus Lietuvai (FR0600), Vokietijai (UStVA) ir Lenkijai (JPK_V7M) bei generuoja VMI pritaikytus i.SAF registrus Lietuvai. Tai yra deklaravimui paruošti duomenys. Vienas API iškvietimas nepateikia kiekvienos šalies PVM deklaracijos per visus nacionalinius šliuzus, ir jokia deklaracija nėra pateikiama mokesčių inspekcijai jūsų vardu. Apskaitą, deklaracijų generavimą, eksportą, pateikimą per šliuzą ir mokėjimo patvirtinimą savo sistemoje laikykite atskiromis būsenomis. ES PVM variklio vadovas aprašo, kokius atvejus variklis išsprendžia ir kada suveikia jo įspėjimai.

Laikotarpio užrakinimas

Po peržiūros ir patvirtinimo, suderinkite sąskaitas faktūras su didžiosios knygos įrašais, suderinkite didžiosios knygos PVM likučius su deklaracijos duomenų rinkiniu, eksportuokite deklaraciją, užfiksuokite pateikimo ir mokėjimo nuorodas, o tada užrakinkite laikotarpį. Nordlet blokuoja įrašus užrakintam mėnesiui, taip pat ir per API. Taisymai po užrakinimo perkeliami į vėlesnį laikotarpį su aiškiomis nuorodomis į pradinį dokumentą ir paveiktą deklaracijos laikotarpį.

Dažniausios klaidų situacijos ir kaip jų išvengti

Klaidos situacija	Kodėl tai nutinka	Kaip to išvengti
Galiojančio VIES atsakymo laikymas pakankamu nuliniam tarifui taikyti	VIES nesuteikia teisės neapmokestinti PVM	Kartu su rezultatu saugokite pirkėjo, tiekimo, transportavimo ir sąskaitos faktūros įrodymus
Negaliojančio atsakymo laikymas įrodymu, kad registracijos nėra	Kodas gali būti neaktyvuotas prekybai ES viduje, arba duomenų bazė gali atsilikti	Atskirkite negaliojantį, neapdorotą rezultatą ir techninę klaidą; nukreipkite ginčytinus atvejus peržiūrai
Atsiskaitymo sinchronizavimas su VIES	Lygiagretumo limitai, laiko viršijimai, sutrikimai	Asinchroninis tikrinimas, trumpalaikis podėliavimas, uždelsimas, laikinosios būsenos
Rezultatų saugojimas podėlyje amžinai	Registracijos ir aktyvavimo statusas keičiasi	Saugokite laiko žymas ir galiojimo pabaigą; dar kartą patikrinkite prieš sąskaitos išrašymą, jei pasenę
Produktų susiejimas tiesiogiai su PVM procentais	Tarifai ir neapmokestinimo atvejai priklauso nuo šalies ir datos	Produktas į kategoriją, į šalies kodą, į nustatytos datos tarifą
OSS ataskaitų atkūrimas iš skaičiuoklių	Sumose nelieka taisymų, išsiuntimo šalių, įrodymų	Gaukite iš nekeičiamos didžiosios knygos su dimensijomis prie kiekvieno įrašo
Vietinės buveinės paslaugų įtraukimas į OSS	Tam tikros paslaugos priklauso vietinei deklaracijai	Modeliuokite buveines atskirai, maršrutizuokite pagal schemą prieš agreguojant
Nulinių deklaracijų praleidimas	OSS reikalauja teikti deklaraciją kiekvieną laikotarpį	Generuokite kontrolinį sąrašą ir automatiškai kurkite nulinės vertės deklaracijas
Uždarytų sąskaitų faktūrų redagavimas norint ištaisyti klaidas	Sunaikina ryšį tarp pateikimo ir taisymo	Naudokite kreditines sąskaitas ir atvirkštinius įrašus vėlesniame laikotarpyje

Ką mes darytume pirmiausia

Jei rytoj pradėtume šią integraciją, prieš paliesdami bent vieną deklaravimo galinį punktą, pirmiausia sukurtume mokesčių kategorijų sluoksnį ir PVM sprendimo įrašą. Stabilizuokite taksonomiją, susiekite produktus su kategorijomis ir padarykite taip, kad sprendimo įrašas užfiksuotų neapdorotus šalies signalus bei priežastį, kodėl buvo pasirinkta būtent ta paslaugų teikimo vieta. Viskas kita – VIES, registravimas didžiojoje knygoje, OSS grupavimas, eksportas – priklauso nuo to, ar šis modelis yra teisingas.

Tada mes sujungtume VIES kaip asinchroninį įrodymų rinkimo žingsnį su atskirtomis keturiomis būsenomis ir išbandytume tai testinėje įmonėje naudodami paruoštukus sudėtingiems atvejams (laiko viršijimams, neapdorotiems rezultatams, nesutampantiems priešdėliams), prieš leidžiant ją į gamybinę aplinką. Aukščiau nurodytų klaidų situacijų galima beveik visiškai išvengti, jei duomenų modelis perduoda įrodymus ir ataskaitų dimensijas nuo pat pirmojo įrašo didžiojoje knygoje.

D.U.K.

Ar galiojantis VIES atsakymas reiškia, kad ES vidaus B2B pardavimui galiu taikyti nulinį tarifą?

Ne. VIES patvirtina, kad PVM mokėtojo kodas yra registruotas ir, kur tai palaikoma, aktyvuotas prekybai ES viduje. Teisė neapmokestinti prekių tiekimo Bendrijos viduje priklauso nuo papildomų įrodymų: ar pirkėjas yra faktinis gavėjas, transportavimo ar išsiuntimo įrodymų, teisingai nustatytos tiekimo vietos ir reikiamos sąskaitos faktūros formuluotės. VIES rezultatą saugokite kaip vieną iš įvesties duomenų, o ne kaip galutinį sprendimą.

Ar VIES tikrinimas turėtų blokuoti atsiskaitymą?

Neturėtų. VIES sistemoje gali baigtis skirtas laikas arba gali būti pasiekti lygiagretumo limitai, o paslaugos sutrikimas nėra tas pats, kas negaliojantis numeris. Tikrinkite asinchroniškai, talpinkite sėkmingus rezultatus podėlyje dokumentuotą laikotarpį, kartokite bandymus po trumpalaikių trikdžių ir sulaikykite dviprasmiškus atvejus peržiūrai su laikinąja būsena, užuot nutraukę pardavimą.

Ar debesijos apskaitos API gali automatiškai pateikti mano PVM deklaracijas?

Ji gali sugeneruoti deklaravimui paruoštus duomenis, sugrupuotus pagal schemą ir valstybę narę, apskaičiuotus iš nekeičiamos didžiosios knygos su įtrauktais taisymais. Ar ji taip pat pateikia šiuos duomenis per kiekvienos šalies nacionalinį deklaravimo šliuzą, priklauso nuo produkto ir šalies. Nordlet apskaičiuoja OSS ir IOSS deklaracijas, siunčia vietinių deklaracijų paketus Lietuvai, Vokietijai ir Lenkijai, bei generuoja VMI pritaikytus i.SAF registrus Lietuvai, tačiau ji nepateikia jokių duomenų mokesčių inspekcijai jūsų vardu. Apskaitą, deklaracijų generavimą, eksportą, pateikimą per šliuzą ir mokėjimą vertinkite kaip atskiras būsenas, užuot manę, kad vienas API iškvietimas viską deklaruos visur.

Kaip apdoroti taisymus po to, kai laikotarpis užrakinamas?

Registruokite juos vėlesniame laikotarpyje su aiškiomis nuorodomis į pradinį dokumentą ir paveiktą deklaracijos laikotarpį. Nordlet blokuoja naujus įrašus užrakintam mėnesiui, taip pat ir per API, todėl taisymai atliekami per kreditines sąskaitas ar atvirkštinius įrašus, o ne redaguojant uždarytus įrašus. Taip išlaikoma seka tarp pradinio deklaravimo ir patikslinimo.

Papildoma literatūra

• ES PVM atitikties automatizavimas naudojant debesijos apskaitos API
• Debesijos apskaitos API integravimas į SaaS platformą
• PVM mokėtojo kodo tikrinimas (VIES), Europos Komisija