EL-i käibemaksuvastavuse automatiseerimine pilvepõhise raamatupidamise API abil

Praktiline juhend platvormidele ja turgudele, mis vajavad korrektseid raamatupidamisandmeid, õiget käibemaksu ja aastaid hiljemgi kehtivat auditijälge.

EL-i käibemaks ei ole enam arvutus-, vaid tõendamisülesanne. Maksumäärad on avalikustatud, piirmäärad teada ja OSS-i deklaratsioonid põhjalikult dokumenteeritud. Auditis kukutakse läbi ja platvormid jooksevad suuremahulisel kasutusel ummikusse seetõttu, et puudub suutlikkus taasesitada, kuidas tehti konkreetne käibemaisuotsus konkreetsel arvel, kasutades tollal kehtinud reegleid ja sisendandmeid. Pilvepõhine raamatupidamise API suudab seda algusest lõpuni automatiseerida, kuid ainult siis, kui see on üles ehitatud otsustuspuule, mitte pelgalt maksumäärale.

See eristus määratleb kogu järgneva sisu.

Mida "EL-i käibemaksu automatiseerimine" tegelikult tähendab

Platvormi jaoks, mis müüb kaupu või teenuseid mitmesse EL-i riiki, on käibemaksu automatiseerimine omavahel seotud otsuste ahel:

Kas klient on ettevõtja (B2B) või eraklient (B2C) ja kus ta asub?
Millise riigi maksumäär ja milline maksukategooria kehtib arve kuupäeval?
Kas tegemist on pöördmaksustamise, OSS-i, IOSS-i või kodumaise tehinguga?
Kas käibemaksukohustuslasest tarnija oli veebiturg (deemed supplier) või otsemüüja?
Millised tõendid neid vastuseid toetavad ja kas neid saab hiljem taasesitada?

Numbri automatiseerimine ilma põhjendusi automatiseerimata ongi tüüpilise auditist läbikukkumise põhjus: summad on õiged, kuid puudub kaitstav tõendajälg. Kaasaegsed maksumootorid pakuvad üha enam auditikindlaid tõendajälgi ja ajalooliste määrade päringuid, kuna kontrollikeskmes on nüüd see, kuidas käibemaisuotsuseni jõuti, mitte ainult selle lõpptulemus.

Pilvepõhine raamatupidamise API on selle jälje säilitamiseks loomulik paik, sest see salvestab juba praegu arve, pearaamatu kande ja tehingupartneri. Nordlet on üles ehitatud sellele ideele: muutumatu ehk immutables kahekordne raamatupidamine, riigipõhine käibemaksuloogika, VIES-i kontroll ja i.SAF-i registrite genereerimine on kõik kättesaadavad ühe REST-liidese kaudu, millel on tüübistatud SDK-d ja veebikonksud (webhooks). API ei ole õhuke kiht raamatupidamise peal, vaid otsuse enda andmebaas.

Kolm API funktsiooni, mis kannavad kogu raskust

Suurem osa käibemaksu automatiseerimisest taandub kolmele funktsioonile, mida raamatupidamise API peab korrektselt võimaldama.

1. Maksumäärad ja maksukategooriad, seotud konkreetse kuupäevaga. Määrad muutuvad. Kategooriad muutuvad. Soodusmäärad lisatakse ja eemaldatakse. Toimiv muster, nagu Sage oma arendajate juhendis EL-i käibemaksureformi ja raamatupidamise API-de kohta väidab, on kaupade/teenuste vastendamine maksukategooriatega ja seejärel maksukategooriate vastendamine riigipõhiste koodidega koos kehtivuskuupäevadega. Konkreetse määra kõvakodeerimine (hard-coding) kauba ja riigi kaupa on vastumuster, mis kogub vaikselt vigu, kuni maksumäära muutus aasta hiljem midagi ära lõhub.

2. Käibemaksukohustuslase numbri (KMKR) kontroll koos varuplaaniga. VIES on piiriülese B2B-kontrolli ametlik allikas. Samas on see kohati ebakindel. Mõistlikud süsteemid puhverdavad kontrollitulemusi lühikese kehtivusajaga (TTL), proovivad tõrgete korral uuesti ja suunavad ebaselged juhud ülevaatusjärjekorda, selle asemel et müüki blokeerida. Eeldus, et VIES peab iga tehingu puhul sünkroonselt õnnestuma, tekitab platvormidele tarbetuid seisakuid.

3. Tõendite kogumine ja muutumatus. Iga käibemaisuotsus peaks salvestama oma sisendid: kliendi asukohasignaalid, KMKR-i ja kontrolli ajatempli, maksukategooria, maksumäärade tabeli versiooni, kohaldatava skeemi (kodune, OSS, IOSS, pöördmaksustamine) ja veebituru rolli. See kirje peab säilima ka maksumäärade ja seadistuste muutudes. Muutumatu pearaamatu abil perioodide lukustamisega, mida Nordlet API tasemel tagab, ei saa suletud kuud vaikselt ümber kirjutada, et hilisemat auditit ilusamaks muuta.

Need kolm funktsiooni on vundament. Kõik muu, sealhulgas OSS-i aruandlus, i.SAF-i genereerimine ja vastavuskontroll, toetub sellele.

Käibemaisuotsuse modelleerimine, mitte ainult määra arvutamine

Kõige levinum viga manustatud raamatupidamises on käsitada arve maksurida kui otsingu tulemust. See ei ole nii. See on väikese otsustuspuu väljund ja just seda puud on vaja säilitada.

Toimiv mudel:

Klassifitseerige tehingupartner. Kas B2B või B2C. B2B korral kontrollige KMKR-i VIES-i kaudu ja salvestage vastus koos ajatempli ja olekuga. B2C korral koguge vähemalt kaks asukohasignaali: arve aadress, IP või geolokatsioon ja maksevahendi riik, kui see on saadaval.
Määrake tarbimiskoht (place of supply). Digiteenuste puhul järgib käibemaks kliendi asukohta, mitte müüja oma. Kaupade puhul sõltuvad reeglid lähte- ja sihtkohast. API peaks märgistama iga arverea tuletatud tarbimiskoha ja kasutatud signaalidega.
Valige skeem. Kodune, OSS (piiriülene B2C EL-i siseselt), IOSS (väheväärtuslikud impordid) või pöördmaksustamine. Piirmäärade loogikat, eriti digiteenuste 10 000 euro suurust piiriülest B2C piirmäära, tuleb arvutada jooksva akna, mitte eraldiseisva arve alusel.
Rakendage maksumäär. Otsige üles riigi määr vastavale maksukategooriale arve kuupäeva seisuga. Salvestage kasutatud maksumäärade tabeli versioon.
Kandke pearaamatusse. Koostage kahekordse kirjendamise kanne, kus makstav käibemaks on jaotatud riigi ja skeemi järgi, et OSS-i ja kodumaisi käibemaksudeklaratsioone saaks koostada andmeid uuesti tuletamata.

Iga samm peab olema API kaudu jälgitav. Veebikonksud, nagu sale_invoice.paid, võimaldavad alamajasüsteemidel reageerida olekumuutustele ilma pideva pärimiseta (polling). Idempotentsusvõtmed (idempotency keys) hoiavad ära topeltkanded pearaamatus, kui võrgutõrke tõttu saadetakse päring uuesti valel hetkel. Kumbki neist ei ole eksootiline, kuid mõlemad on platvormi mahus vältimatud.

OSS, IOSS ja 10 000-eurone piirmäär

SaaS-i ja digiteenuste jaoks on praktiliseks automatiseerimisülesandeks OSS. Tarnija, kes müüb EL-i siseselt piiriüleselt B2C-le, kohaldab oma koduriigi määra seni, kuni jooksval või eelmisel kalendriaastal ületatakse 10 000 euro piirmäär, ning hakkab seejärel rakendama kliendi liikmesriigi määra ja deklareerima kvartaalselt OSS-i kaudu. Praktiline juhend käibemaksuvastavuse kohta SaaS-i ja digiteenuste jaoks käsitleb seda andmetorustiku, mitte registreerimise probleemina.

Torustik, mida raamatupidamise API peab toetama:

Jälgige piiriülest B2C tulu võrreldes piirmääraga jooksva kalendriaasta lõikes.
Lülituge automaatselt koduriigi määratluselt sihtriigi määratlusele, kui piirmäär on ületatud, ilma eelmiste arvete kuupäevi tagasiulatuvalt muutmata.
Rühmitage tehingud liikmesriigi, skeemi ja valuuta järgi kvartaalse OSS-i deklaratsiooni jaoks.
Normaliseerige summad eurodesse õige vahetuskursi kuupäeva alusel OSS-i aruandluse jaoks.
Eksportige deklaratsioonivalmis andmestik vormingus, mida aruandlusteenus saab tarbida.

Nordlet lahendab selle pearaamatu riigipõhise käibemaksuloogika ja skeemi ning liikmesriigi alusel rühmitava aruandluse kaudu: OSS-i deklaratsioonid arvutatakse arvetelt endilt koos varasemate perioodide parandustega ning 10 000 euro piirmäära jälgitakse automaatselt. Deklaratsioon tuletatakse pearaamatu andmetest, mitte ei ehitata igas kvartalis nullist üles. Selles seisnebki otsustuspuu paigutamise mõte raamatupidamissüsteemi sisse, mitte eraldiseisvasse tabelarvutusprogrammi.

IOSS järgib madala väärtusega impordi puhul sama mustrit teistsuguste piirmäärade ja deklaratsiooniga.

Veebiturgude ja platvormide vood on omaette kategooria

Veebituru (marketplace) käsitlemine tavalise B2C-kanalina on koht, kus üllatavalt paljud lahendused teevad vea. Paljudes EL-i stsenaariumides on platvorm käibemaksu mõistes müüja (deemed supplier) ning vastutab käibemaksu kogumise ja tasumise eest. Kaupmehe enda raamatupidamine peab kajastama, et nende tehingute puhul on käibemaksupoolne osapool platvorm, mitte lõppklient.

Siin teenib manustatud raamatupidamise API oma leiva. Platvorm teab müügihetkel, kas ta tegutses käibemaksu mõistes müüjana. See fakt tuleb kirjutada arvekirjesse ja kanda edasi pearaamatusse, et kaupmehe raamatupidamine ei topeltarvestaks käibemaksu, mille platvorm on juba lahendanud. Maksueesmärgiliste rollinäitajate edastamine API kaudu ja nende kajastamine aruannetes teeb vahet puhastel raamatupidamisandmetel ja lõputul vastavusse viimisel.

Platvormide jaoks, mis ehitavad Nordletile, on see esmaklassiline tugi: arvetel on väli vatScheme (sealhulgas marketplace_deemed) ja lipp deemedSupplier, ning käsitluse lahendur tagastab kohaldatava skeemi koos selle õigusliku alusega direktiivi 2006/112/EÜ alusel. Kombineerituna mitme ettevõtte (multi-company) toega saavad platvormi raamatupidamine ja kaupmehe raamatupidamine elada sama API all erinevate ettevõtete ja rollidena, ilma et käibemaksukanded nende vahel lekiksid.

Mida ViDA muudab ja mida mitte

Käibemaks digiajastul (VAT in the Digital Age ehk ViDA) muudab automatiseerimise olemust "arvuta ja raamatupidamisse kanda" asemel "arvuta, kanna raamatupidamisse ja edasta". E-arved ja peaaegu reaalajas toimuv aruandlus maksuhalduritele muutuvad torustiku osaks. See ei asenda raamatupidamise API-t. See muudab raamatupidamise API struktureeritud arveandmed allikaks, mida peegeldatakse aruandluslüüsi (gateway).

Kaks praktilist tagajärge:

Arve metainformatsioon peab olema rikkalikum, kui enamik pärandsüsteemide skeeme lubab. Peppol BIS 3.0 väljad, struktureeritud käibemaksujaotus rea kohta ja skeemi identifikaatorid peavad olema raamatupidamise API põhiosa, mitte lisatud vabas vormis märkustena.
Raamatupidamisdokument ja raporteeritud dokument peavad püsima sünkroonis. Kreeditarve väljastamisel peab aruandlusluks nägema parandust samade identifikaatoritega. Muutumatud pearaamatud ja selge dokumentide ajalugu teevad selle lihtsaks. Lõtv raamatupidamine teeb selle keeruliseks.

ViDA-ks valmistumine on vähem uued funktsioonid ja rohkem olemasoleva korra distsipliini tugevdamine.

Lühike võrdlus automatiseerimisviisidest

Lähenemine	Käibemaisuotsuse tõendid	OSS/IOSS käsitlemine	Veebituru rolli modelleerimine	Sobivus manustatud platvormidele
Manuaalne raamatupidamine tabelarvutusprogrammidega	Nõrgad, tagantjärele taasesitatud	Manuaalne, vigadealt	Tavaliselt ignoreeritud	Nõrk
Pärandraamatupidamistarkvara lisatud maksumooduliga	Osapooled, sageli väljaspool pearaamatut	Toetatud, kuid isoleeritud	Piiratud	Nõrk kuni keskmine
Üldine raamatupidamise API (Xero, QuickBooks stiilis)	Sõltub integratsiooni distsipliinist	Erineb turuti ja lisamooduliti	Ei ole EL-i kontekstis deemed-supplier voogude jaoks avalikult kinnitatud	Keskmine
Nordlet (API-keskne, EL-ile suunatud)	Muutumatu pearaamatus, arvepõhine maksunäitaja, perioodi lukustus	Omatoodetud riigipõhine käibemaks, i.SAF, VIES, OSS-valmis rühmitus	Esmatähtis: `vatScheme`, `deemedSupplier` arve kohta	Tugev

Tabel kajastab käesoleva artikli jaoks saadaolevaid sisendeid. Juhtudel, kui konkurendi funktsionaalsus ei ole uuringu lühikokkuvõttes dokumenteeritud, on see märgitud avalikult kinnitamata, mitte eeldatud.

Mida ehitada esimesena, kui alustate praegu

Kui meeskond juurutab manustatud EL-i käibemaksu automatiseerimist pilvepõhise raamatupidamise API kaudu, aitab järgmine järjestus vältida enim ümbertegemist:

Modelleerige tehingupartner ja selle asukohasignaalid enne kõike muud. Kõik allavoolu tehtavad otsused sõltuvad sellest. Salvestage signaalid, mitte ainult tuletatud riik.
Ehitage välja maksukategooriate kiht. Vastendage tooted ja teenused kategooriatega. Vastendage kategooriad riigikoodidega. Ärge kunagi vastendage tooteid otse maksumääradega.
Ühendage VIES-i kontroll koos puhverduse ja ülevaatusjärjekorraga. Ärge laske VIES-i kättesaadavusel takistada ostukorvi tasumist.
Väljastage ja tarbige veebikonkse arve olekumuutuste kohta. Kasutage iga kirjutamistoimingu juures idempotentsusvõtmeid.
Lukustage perioodid kohe, kui need sulguvad. Rakendage seda API tasemel, mitte reeglistikuna.
Tuletage OSS-i deklaratsioonid pearaamatust. Kui deklaratsioon nõuab eraldi tabelarvutust, ei kanna pearaamat piisavalt metainfot.
Alles seejärel lisage e-arvete ja aruandluslüüsi integratsioon. Lähteandmed peavad esmalt korras olema.

Enamik neist on ühekordsed investeeringud, mis tasuvad end igas kvartalis vaikselt ära. Piiramatu liivakastikeskkond (sandbox company) on odavaim koht selle järjestuse otsast lõpuni tõestamiseks.

FAQ

Kas VIES-i kontrollist piisab tõestamaks, et B2B-müük oli õigesti 0% maksumääraga?

Üksi sellest ei piisa. VIES kinnitab, et KMKR on teatud ajahetkel kehtiv. Auditikindel kirje sisaldab lisaks kontrolli ajatemplit, vastuse andmeid, kliendi deklareeritud riiki ja tõendeid selle kohta, et kaubad või teenused tarniti sellele KMKR-iga registreeritud üksusele. Salvestage need kõik arve juurde.

Kas platvorm võib loota, et veebiturg haldab käibemaksu ja jätta oma loogika ehitamata?

Ainult nende konkreetsete tehingute puhul, kus veebiturg on EL-i reeglite järgi käibemaksu mõistes müüja (deemed supplier). Kaupmehe raamatupidamine peab siiski neid tehinguid korrektselt kajastama ning kõik müügid väljaspool seda ulatust, sealhulgas otsemüük ja B2B-vood, jäävad kaupmehe vastutusele. Turvalisem on roll selgelt tehingupõhiselt modelleerida.

Kui tihti EL-i käibemaksumäärad tegelikult muutuvad?

Piisavalt tihti, et kõvakodeeritud määrad tekitavad reaalseid probleeme. Soodusmõjuga kategooriad muutuvad, ajutised määrad võetakse kasutusele ja aeguvad ning uued liikmesriigi reeglid ilmuvad. Kehtivuskuupäevadega määrade sisendkiht ei ole ülearendus, vaid miinimumtase.

Mis vahe on praktikas OSS-il ja IOSS-il?

OSS katab EL-i siseseid piiriüleseid B2C kauba- ja digiteenuste müüke, mida deklareeritakse kvartaalselt ühe liikmesriigi kaudu. IOSS katab väheväärtuslikku importi EL-i, tavaliselt alla 150-euroseid tarbekaupu. Mõlemad tuletatakse samadest raamatupidamisandmetest, kui pearaamat märgistab iga tehingu sellele vastava skeemiga.

Kas muutumatu pearaamat tähendab, et parandused on võimatud?

Ei. Parandused tehakse uute kannete, mitte vanade muutmise teel. Kreeditarve tühistab arve, korrigeeriv kanne parandab vale kande. Muutumatus hoiab ära ajaloo vaikiva ümberkirjutamise, mida audiitorid just otsivad.