Samoobdavčitev pridobitev iz EU ni vprašanje poznavanja 34. člena ZDDV-1, temveč vprašanje pravilne klasifikacije vsakega posameznega računa v f23, f23a ali f25 — in prav tu slovenska MSP-jevska računovodstva sistematično izgubljajo denar in pravico do odbitka.
Devetdeset odstotkov napak ni datumskih. So klasifikacijske: blago vs. storitev, digitalna storitev vs. licenca, EU vs. tretja država. Pravilo o 15. dnevu naslednjega meseca je enovrstični algoritem, ki ga zna vsak knjigovodja. Razlika med f23, f23a in f25 pa je tista, ki vam ob FURS kontroli pobere odbitek.
Tri vrste samoobdavčitve niso ista stvar — in DDV-O to ve
Pridobitev blaga iz EU, prejem storitve iz EU in samoobdavčitev iz tretjih držav so tri ločene transakcije z ločenimi pravnimi podlagami, ločenimi f-polji in ločenimi dokaznimi zahtevami. Kdor jih obravnava kot eno kategorijo »samoobdavčitve«, je že na poti v popravek obračuna. Pridobitev blaga znotraj Unije gre v f23 (vstopni DDV v f41), pridobitev storitve iz druge članice v f23a (odbitek v f41), samoobdavčitev iz tretjih držav po posebnih pravilih v f25.
Razlika ni kozmetična. Pri blagu iz EU mora biti dobavitelj DDV zavezanec v drugi članici, promet mora biti za plačilo, blago mora biti pridobljeno v Sloveniji in pridobitelj mora biti identificiran za DDV v Sloveniji [2]. Pri storitvah iz EU samoobdavčitev nastopi tudi, če izvajalec sploh nima identifikacijske številke za DDV — pomembno je le, da je davčni zavezanec [3]. Isti učinek iz dveh različnih pravnih razlogov, zato DDV-O obrazec loči polji.
Tretja kategorija — prejem storitev iz tretjih držav — sploh ni pridobitev znotraj Unije in ne sodi v f23 ali f23a. Gre v f25 in zahteva svojo dokumentacijo. Računovodski program, ki te tri tokove zlije v eno vrsto prometa, vam bo pokvaril DDV-O obrazec ne glede na to, kako natančno vodite datume.
Pravilno f-polje določa narava transakcije, ne sedež dobavitelja
To je preprosto pravilo, ki v praksi pade na vsakem drugem računu. Programska oprema na USB ključku je blago (f23). Ista programska oprema, prenesena prek spleta, je storitev (f23a). Vzdrževanje strežnika na daljavo je storitev. Vzdrževanje strežnika z menjavo komponente, kjer komponenta predstavlja večji del vrednosti računa, je mešana dobava, ki jo FURS lahko prekvalificira. Licenca SaaS je storitev. Najem fizičnega vozila iz Avstrije je storitev. Najem vozila s šoferjem je prevozna storitev s svojimi pravili.
Mejne primere reši trojica vprašanj na vsakem računu: ali se predmet fizično premika čez mejo (kandidat za f23); ali je vrednost pretežno pripisana fizičnemu predmetu ali storitvi (vključno z licenco, dostopom, izvedbo); ali je prevoz na računu ločeno zaračunan kot samostojna postavka (in s tem ločena storitev). Brez teh treh kontrol večina računov konča v napačnem polju.
Kraj opravljanja storitev med davčnimi zavezanci je sedež naročnika — pri slovenskem prejemniku torej Slovenija [3]. Pri blagu je kraj pridobitve tam, kjer se konča odpošiljanje in je blago dano na razpolago kupcu [2]. Računovodski program brez sistemskega klasifikatorja na vstopu teh dveh kriterijev ne more samodejno razločiti. To delo mora opraviti AI klasifikator, ki bere vsebino računa, ne knjigovodja, ki bere zgolj sedež izdajatelja.
Datum obdavčitve je trivialen problem; datum knjiženja je pravi problem
Pravilo iz 34. člena je v eni vrstici: obdavčljivi dogodek pri pridobitvi blaga znotraj Unije nastane, ko je pridobitev opravljena, obveznost obračuna DDV pa na dan izdaje računa, oziroma najkasneje 15. dan v mesecu, ki sledi mesecu obdavčljivega dogodka, če račun do takrat ni izdan [1]. Težava ni v algoritmu — težava je, da se v računovodskem programu prevede v tri ločene datume.
Prvi je datum prejema dokumenta. Drugi določa DDV obdobje obveznosti — v kateri DDV-O gre obračunani izhodni DDV. Tretji določa obdobje pravice do odbitka. V optimalnem scenariju so vsi trije v istem mesecu in obveznost ter odbitek se izničita do centa znotraj enega obračuna. V realnosti se vsaj eden premakne: dobavitelj izda račun 28.01.2026 z dobavo 22.01.2026, vi ga skenirate 03.02.2026, odbitek pa po pravilih spada v januarski obračun.
FURS ne preveri pravila o 15. dnevu. FURS preveri konsistentnost teh treh datumov v knjigi prejetih računov, v DDV-O obrazcu in v XML, ki ga oddate prek eDavkov. Če sta obveznost in odbitek razglašena v različnih obdobjih brez utemeljitve, je obračun napaden ne glede na to, da je vsaka transakcija sama po sebi pravilna. Kontrola, ki to prepreči, ni mesečni pregled — je avtomatski izračun vseh treh datumov ob vnosu računa.
VIES preverjanje ni formalnost — je predpogoj za odbitek
Pogoj, da je dobava obravnavana kot pridobitev blaga znotraj Unije, vključuje veljavnost dobaviteljeve DDV identifikacije v drugi članici [2]. Ta pogoj se preverja v VIES na dan obdavčljivega dogodka, ne na dan vnosa računa v računovodstvo. Če dobavitelj na dan dobave v VIES ni veljaven, pravna kvalifikacija transakcije pade — in z njo pravica do odbitka v istem obdobju.
MSP, ki VIES preverja občasno ali samo ob prvem poslu z novim partnerjem, gradi mino z zamikom. Avstrijski ali nemški dobavitelj lahko izgubi veljavno DDV identifikacijo med dvema vašima nabavama, vi pa boste to ugotovili šele takrat, ko bo kontrola za nazaj zahtevala dokazilo o veljavnosti za vsak posamezen račun. Edini smiseln režim je VIES preverjanje za vsak prejeti račun, samodejno, z arhiviranjem rezultata (datum, čas, status) kot priloge k dokumentu.
Tega dela postopka ročno ne dela nihče dosledno. Klasifikator, ki ob branju računa izvleče DDV ID dobavitelja, ga preveri v VIES in shrani potrdilo k transakciji, ni nadgradnja — je minimum za vsak resen ZDDV-1 skladnostni proces.
Štiri napake, ki vas dejansko stanejo
Najdražje napake pri samoobdavčitvi niso datumske, ampak klasifikacijske. Prva: nemški dobavitelj na računu zaračuna 19 % nemškega DDV (ker mu niste sporočili veljavnega slovenskega DDV ID, ali ker je transakcijo obravnaval kot prodajo končnemu potrošniku). Računovodja, ki tega ne ujame ob vnosu, samoobdavčitev izvede še enkrat na bruto znesek — dvojna obdavčitev, ki je nikoli ni mogoče v celoti vrniti.
Druga: dvojno samoobdavčevanje istega računa, ker je bil najprej knjižen kot domač strošek in nato še enkrat kot EU pridobitev po popravku. Tretja: prekoračitev praga za Intrastat (220.000 € pri pridobitvah letno) brez prijave — kazen ni DDV-jska, je statistična, vendar sproži širši pregled. Četrta: storitev iz EU klasificirana v f23 namesto v f23a (ali obratno) — obračun je numerično pravilen, polje napačno, FURS to odkrije pri navzkrižnem ujemanju z VIES poročili drugih članic.
Vse štiri prepreči avtomatska kontrola ob vnosu računa: prepoznava tujega DDV na računu (in zavrnitev samoobdavčitve na bruto), preverjanje unikatnosti računa po številki in dobavitelju, kumulativno spremljanje EU pridobitev proti Intrastat pragu, in klasifikacijski klic blago/storitev. Pregled ob koncu obračunskega obdobja je prepozen — takrat se napake zacementirajo v oddan obrazec [8].
G-Energy d.o.o., marec 2026: 12 EU računov, ničla do centa
G-Energy d.o.o. je v marcu 2026 prejel 12 računov iz EU: štiri iz Avstrije (kabli in oprema), tri iz Nemčije (industrijski deli in licenčna pogodba SaaS), dva iz Italije (transportne storitve), dva iz Češke (viličar) in enega iz Nizozemske (svetovanje). Skupna vrednost: €116.431,84. Ročna obdelava bi pomenila 12 dokumentov × približno 20 minut (vnos, VIES poizvedba, izbira vrste prometa, izračun datumov, knjiženje obveznosti in odbitka) — štiri ure dela, ob predpostavki, da klasifikacija prvič vedno uspe.
AI klasifikator v Waveflow je iz vsakega PDF-ja izvlekel dobavitelja, DDV ID, datum izdaje, datum dobave, vrednost in vrsto blaga oziroma storitve. Za vsakega od 12 dobaviteljev je izvedel VIES poizvedbo in shranil potrdilo k dokumentu. Devet računov je razvrstil v f23 (pridobitve blaga iz EU), dva v f23a (italijanski transport in nizozemsko svetovanje), licenčna SaaS pogodba iz Nemčije je šla v f23a, viličar iz Češke pa je bil ločeno označen kot pridobitev osnovnega sredstva znotraj Skupnosti — v računovodskem programu lastna vrsta prometa [8]. Obveznost in odbitek sta bila knjižena v istem obdobju, KPR in KIR sta se zaprla do centa, FURS-ready XML je bil pripravljen za eDavke v sekundah.
Bistvo ni hitrost. Bistvo je, da je vseh 12 transakcij prešlo skozi isti deterministični postopek — branje, klasifikacija, VIES, izbor f-polja, izračun datumov, knjiženje — brez 12 individualnih človeških odločitev, od katerih bi se vsaka lahko premaknila za eno polje ali en datum. Pri 200 računih na mesec je to razlika med tem, ali obračun zdrži kontrolo, ali ne.
Sklep
Računovodja, ki še vedno klasificira EU račune ročno, ne dela napake v znanju ZDDV-1. Pozna 34. člen, pozna pravilo o 15. dnevu, pozna razliko med f23 in f23a. Dela napako v izbiri orodja — in to napako FURS prej ali slej zaračuna v evrih, najpogosteje šest do osemnajst mesecev po obračunu, ko se popravki obrestujejo in izgubljen odbitek ni več uveljavljiv.
Pravilna postavitev procesa je preprosta: vsak prejeti račun klasificiran ob vnosu, VIES preverjen samodejno, f23/f23a/f25 določi AI in ne knjigovodja, vsi trije datumi (prejem, obveznost, odbitek) usklajeni, vsak korak pusti revizijsko sled. Vse drugo je improvizacija, ki dobro deluje samo do prve kontrole.