ES PVN atbilstības automatizācija, izmantojot mākoņgrāmatvedības API

Praktisks ceļvedis platformām un tirdzniecības vietām, kurām nepieciešami reāli grāmatvedības reģistri, pareizs PVN un revīzijas liecību virkne, kas iztur pārbaudi arī pēc gadiem.

ES PVN vairs nav aprēķinu problēma. Tā ir pierādījumu problēma. Likmes ir publicētas, sliekšņi ir zināmi, un OSS deklarācijas ir labi dokumentētas. Tas, kas gāž revīzijas un sagrauj platformas lielā mērogā, ir nespēja rekonstruēt, kā konkrēts PVN lēmums tika pieņemts uz konkrēta rēķina, izmantojot tajā brīdī pastāvošos noteikumus un ievaddatus. Mākoņgrāmatvedības API var to automatizēt no gala līdz galam, taču tikai tad, ja tas ir veidots ap lēmumu grafu, nevis tikai ap pašu likmi.

Šī atšķirība nosaka visu turpmāk minēto.

Ko patiesībā nozīmē "ES PVN automatizācija"

Platformai, kas veic pārdošanu vairākās ES valstīs, PVN automatizācija ir savstarpēji saistītu lēmumu ķēde:

Vai pircējs ir uzņēmums (B2B) vai patērētājs (B2C), un kur tas atrodas?
Kuras valsts likme un kāda nodokļa kategorija ir piemērojama rēķina datumā?
Vai piegādei piemēro nodokļa apgriezto maksājumu (reverse charge), OSS, IOSS vai iekšzemes režīmu?
Vai tirdzniecības vieta bija uzskatāma par preces piegādātāju (deemed supplier), vai arī tirgotājs?
Kādi pierādījumi pamato katru no šīm atbildēm, un vai tos vēlāk var atkārtoti nospēlēt (replayed)?

Automātisks aprēķins bez automatizētas pamatojuma loģikas rada klasisku revīzijas kļūmi: pareizi kopsummas, bet nav aizstāvamu pierādījumu. Mūsdienu nodokļu dzinņi arvien vairāk piedāvā revīzijas līmeņa pierādījumu virknes un vēsturisko likmju uzmeklēšanu tieši tāpēc, ka nodokļu iekasētāji tagad pievērš uzmanību tam, kā tika nonākts līdz PVN lēmumam, nevis tikai tam, kāds tas bija.

Mākoņgrāmatvedības API ir dabiska vieta šo liecību glabāšanai, jo tas jau saglabā rēķinu, grāmatojumu un darījuma partneri. Nordlet ir veidots, balstoties uz šo ideju: nemainīga divkāršā ieraksta virsgrāmata, valstij specifiska PVN loģika, VIES pārbaude un i.SAF reģistru ģenerēšana – viss pieejams caur vienu REST saskarni ar tipizētiem SDK un tīmekļa āķiem (webhooks). Šis API nav vienkārši virsmas slānis virs grāmatvedības. Tā ir pati sistēma, kurā reģistrēts pats lēmums.

Trīs API iespējas, uz kurām balstās viss process

Lielākā daļa PVN automatizācijas darbu reducējas uz trim funkcijām, kuras grāmatvedības API ir skaidri jānodrošina.

1. Likmju saturs un nodokļu kategorijas, kas piesaistītas datumam. Likmes mainās. Kategorijas mainās. Samazinātās likmes tiek pievienotas un dzēstas. Kā norādīts Sage izstrādātāju ceļvedī par ES PVN reformu un grāmatvedības API, darba modelis paredz preču piesaistīšanu nodokļu kategorijām un pēc tam kategoriju piesaistīšanu valstij specifiskiem kodiem ar spēkā stāšanās datumiem. Konkrētas likmes ierakstīšana kodā katrai precei katrā valstī ir pretstats labai praksei, kas nemanāmi uzkrājas, līdz likmes maiņa pēc gada kaut ko salauž.

2. PVN numura pārbaude VIES ar drošu atteices apstrādi (graceful degradation). VIES ir oficiālais avots starptautiskai B2B pārbaudei. Tā darbība mēdz būt nestabila. Saprātīgas sistēmas saglabā pārbaužu rezultātus kešatmiņā ar īsu derīguma termiņu (TTL), mēģina veikt atkārtotu pieprasījumu kļūmes gadījumā un novirza neskaidros gadījumus uz manuālas pārbaudes rindu, nevis bloķē pirkumu. Uzskats, ka VIES katram darījumam ir jāatbild sinhroni, nozīmē pašbūvētu sistēmas dīkstāvi.

3. Pierādījumu fiksēšana un nemainīgība. Katram PVN lēmumam ir jāsaglabā tā ievaddati: klienta atrašanās vietas pazīmes, PVN numurs un pārbaudes laika zīmogs, nodokļu kategorija, likmju tabulas versija, piemērojamais režīms (iekšzemes, OSS, IOSS, apgrieztais maksājums) un tirgotāja loma. Šim ierakstam ir jāizdzīvo likmju izmaiņas un iestatījumu labojumi. Nemainīga virsgrāmata ar periodu slēgšanu, ko Nordlet nodrošina API līmenī, nozīmē, ka slēgtu mēnesi nevar nemanāmi pārrakstīt, lai vēlāk revīzija izskatītos glītāka.

Šīs trīs spējas ir pamats. Viss pārējais, tostarp OSS deklarēšana, i.SAF ģenerēšana un kontu saskaņošana, balstās uz tām.

PVN lēmuma modelēšana, nevis tikai likmes meklēšana

Visbiežāk sastopamā kļūme iegultajā grāmatvedībā ir nodokļa lauka uztveršana rēķinā kā meklēšanas vaicājuma rezultāts. Tā tas nav. Tā ir neliela lēmumu grafa izeja, un tieši šis grafs ir jāsaglabā.

Strādājošs modelis:

Klasificēt darījuma partneri. B2B vai B2C. Ja tas ir B2B, pārbaudiet PVN numuru VIES un saglabājiet atbildi, ieskaitot laika zīmogu un statusu. Ja tas ir B2C, fiksējiet vismaz divas atrašanās vietas pazīmes: rēķina adresi, IP adresi vai ģeolokāciju un, ja pieejams, maksājuma līdzekļa valsti.
Noskaidrot piegādes vietu. Digitālajiem pakalpojumiem PVN seko klienta atrašanās vietai, nevis piegādātājam. Precēm noteikumi atšķiras atkarībā no nosūtīšanas izcelsmes un galamērķa. API katrai rēķina rindai ir jāpiešķir iegūtā piegādes vieta un izmantotie signāli.
Izvēlēties režīmu. Iekšzemes, OSS (starptautiski B2C darījumi ES ietvaros), IOSS (mazvērtīgu preču imports) vai apgrieztais maksājums. Sliekšņu loģika, jo īpaši 10 000 EUR robežvērtība starptautiskiem B2C digitālajiem pakalpojumiem, ir jāaprēķina pret slīdošu logu, nevis izolēti katram rēķinam atsevišķi.
Piemērot likmi. Atrodiet valsts likmi attiecīgajai nodokļu kategorijai rēķina datumā. Saglabājiet izmantotās likmju tabulas versiju.
Grāmatot virsgrāmatā. Izveidojiet divkāršā ieraksta ierakstu ar maksājamo PVN, kas sadalīts pa valstīm un režīmiem, lai OSS un vietējās PVN deklarācijas varētu sagatavot bez datu atkārtotas atvasināšanas.

Katrai darbībai ir jābūt novērojamai, izmantojot API. Tādi tīmekļa āķi (webhooks) kā sale_invoice.paid ļauj pakārtotajām sistēmām reaģēt uz stāvokļa izmaiņām bez nepārtrauktas datu vaicāšanas (polling). Idempotences atslēgas (idempotency keys) novērš dubultus virsgrāmatas ierakstus, ja tīkla kļūmes dēļ pieprasījums tiek izpildīts atkārtoti neīstajā brīdī. Neviena no šīm lietām nav eksotiska, taču platformas mērogā tās nav apspriežamas.

OSS, IOSS un 10 000 EUR slieksnis

SaaS un digitālajiem pakalpojumiem praktiskā automatizācijas problēma ir OSS. Piegādātājs, kas veic starptautisku B2C tirdzniecību ES iekšienē, piemēro savas mītnes zemes likmi, līdz tekošajā vai iepriekšējā kalendārajā gadā tiek sasniegts 10 000 EUR slieksnis, pēc kura tas sāk piemērot pircēja dalībvalsts likmi un iesniedz ceturkšņa deklarāciju, izmantojot OSS. Praktiskās vadlīnijas par PVN atbilstību SaaS un digitālajiem pakalpojumiem šo jautājumu definē kā datu cauruļvada, nevis reģistrācijas problēmu.

Cauruļvads, kas grāmatvedības API ir jāatbalsta:

Sekot līdzi pārrobežu B2C ieņēmumiem pret slieksni uz slīdoša pamata, katram kalendāra gadam atsevišķi.
Automātiski pārslēgt likmes noteikšanu no mītnes valsts uz galamērķa valsti, kad slieksnis ir sasniegts, neretroaktīvi labojot iepriekšējos rēķinus.
Sagrupēt darījumus pa dalībvalstīm, režīmiem un valūtām ceturkšņa OSS deklarācijai.
Normalizēt summas EUR pēc pareizā valūtas kursa datuma OSS ziņošanai.
Eksportēt sagatavošanai gatavo datu kopu formātā, ko var nolasīt deklarāciju iesniedzējs vai pakalpojums.

Nordlet to atrisina, izmantojot valstij specifisku PVN loģiku virsgrāmatā un atskaites, kas grupē datus pēc režīmiem un dalībvalstīm: OSS deklarācijas tiek aprēķinātas no pašiem rēķiniem, ņemot vērā iepriekšējo periodu labojumus, un 10 000 EUR slieksnis tiek izsekots automātiski. Deklarācija tiek atvasināta no virsgrāmatas, nevis katru ceturksni rekonstruēta no nulles. Tā ir galvenā jēga lēmumu grafa ievietošanai grāmatvedības sistēmā, nevis atsevišķā izklājlapā.

IOSS darbojas līdzīgi mazvērtīgu preču importam, taču ar citiem sliekšņiem un citu deklarācijas formu.

Tirgošanās platformu un ekosistēmu plūsmas ir īpaša kategorija

Tirdzniecības vietas (marketplace) pielīdzināšana parastam B2C kanālam ir kļūda, ko pieļauj pārsteidzoši daudzi ieviesēji. Daudzos ES scenārijos platforma tiek uzskatīta par preces piegādātāju (deemed supplier), un tā ir atbildīga par PVN iekasēšanu un nomaksu. Tirgotāja paša grāmatvedībai ir jāatspoguļo fakts, ka platforma, nevis gala pircējs, ir PVN ziņā nozīmīgais darījuma partneris šiem darījumiem.

Šeit iegultais grāmatvedības API parāda savu patieso vērtību. Platforma pārdošanas brīdī zina, vai tā rīkojās kā preces piegādātājs. Šim faktam ir jābūt ierakstītam rēķina datiem un pārnestam uz virsgrāmatā, lai tirgotāja grāmatos neveidotos PVN dubultā uzskaite, par kuru platforma jau ir parūpējusies. Nodokļu lomas indikatoru pārsūtīšana caur API un to atspoguļošana atskaitēs ir galvenā atšķirība starp sakārtotu grāmatvedību un kontu saskaņošanu, kas nekad nesakrīt.

Platformām, kas izveidotas uz Nordlet bāzes, tas ir standartrisinājums: rēķinos ir iekļauts lauks vatScheme (tostarp marketplace_deemed) un deemedSupplier pazīme, un apstrādes noteicējs (treatment resolver) atgriež piemērojamo režīmu kopā ar tā juridisko pamatojumu saskaņā ar Direktīvu 2006/112/EK. Apvienojumā ar vairāku uzņēmumu (multi-company) atbalstu, platformas grāmatvedība un tirgotāja grāmatvedība var pastāvēt zem viena API, izmantojot dažādus uzņēmumus un dažādas lomas, nepieļaujot PVN grāmatojumu noplūdi starp tiem.

Ko maina ViDA un ko tā nemaina

Digitālā laikmeta PVN iniciatīva (ViDA) maina automatizācijas būtību no "aprēķināt un iegrāmatot" uz "aprēķināt, iegrāmatot un nosūtīt". E-rēķini un gandrīz reāllaika ziņošana nodokļu iestādēm kļūst par daļu no cauruļvada. Tas neaizstāj grāmatvedības API, bet gan padara grāmatvedības API strukturētos rēķinu datus par avotu, kas tiek atspoguļots ziņošanas vārtejā.

Divas praktiskas sekas:

Rēķinu metadatiem jābūt bagātākiem, nekā to atļauj vairums mantoto shēmu (legacy schemas). Peppol BIS 3.0 laukiem, strukturētam PVN sadalījumam pa rindām un shēmu identifikatoriem ir jābūt grāmatvedības API pamatvērtībām, nevis jāpievieno kā brīvā teksta piezīmēm.
Grāmatvedības dokumentam un ziņojuma dokumentam ir jāsaglabā savstarpēja saskaņa. Ja tiek izrakstīts kredītreķins, ziņošanas vārtejai ir jāredz labojums ar tiem pašiem identifikatoriem. Nemainīgas virsgrāmatas un skaidra dokumentu izcelsmes līnija to padara par vienkāršu uzdevumu, bet nevīžīga grāmatvedība to padara sāpīgu.

Gatavošanās ViDA vairāk saistīta ar esošo procesu disciplīnas stingrāku ievērošanu, nevis ar jaunām funkcijām.

Īss automatizācijas pieeju salīdzinājums

Pieeja	PVN lēmuma pierādījumi	OSS/IOSS apstrāde	Tirgus vietas lomas modelēšana	Piemērotība iegultajām platformām
Manuāla grāmatvedība ar izklājlapām	Vāji, rekonstruēti pēc fakta	Manuāla, kļūdu pilna	Parasti tiek ignorēta	Vāja
Mantotā grāmatvedības programmatūra ar papildu nodokļu moduli	Daļēji, bieži ārpus virsgrāmatas	Tiek atbalstīta, bet izolēta	Ierobežota	Vāja līdz viduvēja
Vispārējs grāmatvedības API (Xero, QuickBooks stila)	Atkarīgs no integrācijas disciplīnas	Atšķiras atkarībā no tirgus un papildinājumiem	Nav publiski apstiprināta deemed-supplier plūsmām ES kontekstā	Viduvēja
Nordlet (API pirmais, orientēts uz ES)	Nemainīga virsgrāmata, rēķina PVN metadati, periodu slēgšana	Vietējais valsts PVN, i.SAF, VIES, OSS gatava grupēšana	Augstākā līmeņa: `vatScheme`, `deemedSupplier` katrā rēķinā	Spēcīga

Tabula atspoguļo šim materiālam pieejamos ievaddatus. Vietās, kur konkurenta iespēja nav dokumentēta pētījumā, tā ir atzīmēta kā publiski neapstiprināta, nevis pieņemta iepriekš.

Ko būvēt vispirms, ja sākat tagad

Ja komanda ievieš iegulto ES PVN automatizāciju mākoņgrāmatvedības API, visprātīgākais secība, kas palīdz ietaupīt laiku:

Vispirms izveidojiet darījuma partnera un tā valsts pazīmju modeli. No tā ir atkarīgi visi nākamie lēmumi. Saglabājiet pazīmes, nevis tikai iegūto valsti.
Izveidojiet nodokļu kategoriju slāni. Piesaistiet produktus un pakalpojumus kategorijām. Piesaistiet kategorijas valstu kodiem. Nekad nepiesaistiet produktus tieši likmēm.
Pievienojiet VIES pārbaudi ar kešatmiņu un manuālo rindu. Neļaujiet VIES pieejamībai bloķēt jūsu pirkuma noformēšanas procesu.
Izgudrojiet un patērējiet tīmekļa āķus (webhooks) rēķinu statusa izmaiņām. Izmantojiet idempotences atslēgas katrā datu rakstīšanas darbīcā.
Aizveriet periodus uzreiz pēc to beigām. Nostipriniet to API līmenī, nevis tikai iekšējās politikās.
Atvasiniet OSS deklarācijas no virsgrāmatas. Ja deklarācijai ir nepieciešama atsevišķa izklājlapa, virsgrāmatā nav pietiekami daudz metadatu.
Tikai tad pievienojiet e-rēķinus un ziņošanas vārtejas integrāciju. Sākotnējiem datiem ir jābūt pareiziem.

Lielākā daļa no šiem soļiem ir vienreizēji ieguldījumi, kas klusi atmaksājas katrā ceturksnī. Neierobežots smilšu kastes (sandbox) uzņēmums ir lētākā vieta, kur pierādīt šo secību no sākuma līdz galam.

FAQ

Vai VIES pārbaude ir pietiekama, lai pierādītu, ka B2B pārdošanai ir piemērota 0% likme?

Pati par sevi nē. VIES apstiprina, ka PVN numurs ir derīgs konkrētā laika brīdī. Revīzijas prasībām atbilstošs ieraksts ietver arī pārbaudes laika zīmogu, atbildes datu kopu, klienta norādīto valsti un pierādījumus tam, ka preces vai pakalpojumi tika piegādāti šim reģistrētajam subjektam. Saglabājiet visu šo informāciju pie rēķina.

Vai platforma var paļauties uz tirgus vietu (marketplace) attiecībā uz PVN un izlaist savu loģiku?

Tikai tiem konkrētajiem darījumiem, kuros saskaņā ar ES noteikumiem tirgus vieta darbojas kā preces piegādātājs (deemed supplier). Tirgotāja grāmatvedībai joprojām ir pareizi jāatspoguļo šie darījumi, un visi pārdošanas apjomi ārpus šīs jomas, tostarp tiešie tirdzniecības darījumi un B2B plūsmas, paliek tirgotāja atbildībā. Drošāk ir skaidri modelēt katra darījuma lomu atsevišķi.

Cik bieži ES PVN likmes mainās tik būtiski, ka tam ir nozīme?

Tik bieži, ka "cieti" ierakstītas likmes rada reālas problēmas. Samazināto likmju kategorijas mainās, tiek ieviestas un beidzas pagaidu likmes, un parādās jauni dalībvalstu noteikumi. Likmju satura slānis ar spēkā stāšanās datumiem nav pārmērīga inženierija. Tā ir bāzes prasība.

Kāda ir praktiskā atšķirība starp OSS un IOSS?

OSS attiecas uz pārrobežu B2C preču un digitālo pakalpojumu tirdzniecību ES iekšienē, par ko reizi ceturksnī ziņo caur vienu dalībvalsti. IOSS attiecas uz mazvērtīgu preču importu ES, parasti patēriņa precēm, kuru vērtība nepārsniedz 150 EUR. Abi veidi tiek iegūti no tiem pašiem grāmatvedības datiem, ja virsgrāmata katram darījumam piešķir atbilstošu shēmas pazīmi.

Vai nemainīga virsgrāmata nozīmē, ka labojumi nav iespējami?

Nē. Labojumi tiek veikti ar jauniem ierakstiem, nevis rediģējot vecos. Kredītreķins anulē rēķinu, bet koriģējošais ieraksts izlabo kļūdainu grāmatojumu. Nemainīgība novērš vēstures klusisku pārrakstīšanu, ko tieši meklē revidenti.