A 65M – „Összesítő jelentés kereskedelmi partnerenként” megnevezésű – nyomtatvány immár negyedik éve része az életünknek, része az ÁFA-bevallásnak. Tapasztalataim alapján, azonban még mindig alapvető hibákat követnek el az adózók a szoftverekben a kitöltéshez szükséges mindennapi munka, az adatrögzítés során. Cikkemben ezekre az alapvető hibákra szeretném felhívni a figyelmet.

Egy felhasználóbarát, igényes ügyviteli szoftver szinte automatikusan állítja elő a 65M jelentés kitöltéséhez szükséges adatokat.

Nézzük meg nagy vonalakban (a kivételektől eltekintve), mi is a feladata a szoftvernek!

Először is figyelnie kell tételesen azokat a belföldi (két magyar adóalany), vevői, egyenesen adózó számlákat, melyek ÁFA-értéke eléri az 1 millió forintot.

Figyelnie kell továbbá tételesen azokat a belföldi, szállítói, egyenesen adózó számlákat, melyek ÁFA-értéke eléri az 1 millió forintot, és az adózó – részben, vagy egészben – levonásba helyezi őket.

Ezen felül ÁFA-időszakra és partnerre összesítve figyelnie kell, hogy a belföldi, szállítói, ÁFA-értéket tartalmazó, egyenesen adózó számlák levonásba helyezendő ÁFA-értéke eléri-e az 1 millió forintot.

Ezen a ponton el is érkeztünk az első alapvető hibázási lehetőséghez. A hibát mind a szoftver tervezője, mind a felhasználója képes előidézni, elkövetni.

Kulcsszó: „partnerre összesítve”. Sok ügyviteli szoftver vagy nem teszi kötelezővé a szállító adószámának rögzítését, vagy megengedi, hogy ugyanazon adószám több szállítónál, partnernél is szerepeljen. Az esetek többségében a tervezők ezt nem önszántukból, hanem felhasználói kérésre teszik.

Gondoljunk bele, mi is lehet a következménye egy ilyen működésnek a 65M jelentést nézve. Egyszerűen csak annyi, hogy a jelentés főlapjának 06-os sorát nem tudjuk szabályosan kitölteni. Ez esetben előfordulhat ugyanis, hogy egy adott szállító többször szerepel a rendszer partnertörzsében. Az már részletkérdés, hogy ugyanazon megnevezéssel, vagy picit másként, adószámmal, vagy adószám nélkül. Amennyiben egy adott adószám több partnernél is szerepelhet, úgy a szoftver tervezője próbálhatja kivédeni a hibázási lehetőséget oly módon, hogy adószámra összesít, de ez is hiába, ha az adószám nem kötelező.

Mit tehetünk, hogy egy ilyen apróság miatt ne kockáztassuk jelentésünk adattartalmának helyességét?

Szoftvertervezői oldalon alapvető megoldás lehet, hogy megköveteljük az adószám kötelezőségét, és egyediségét. Amennyiben erre – felhasználóink igénye folytán – nincs lehetőségünk, úgy például elkülöníthetjük a partnerek egy csoportját, akiknél kötelező és egyedi az adószám, meghagyva felhasználónak a lehetőséget arra, hogy partnerei egy másik csoportjánál rögzítse az adószámot – természetesen itt is CDV-ellenőrzés mellett -, de kedve szerint. A felhasználó persze ezt is ki tudja játszani, ha nem akadályozzuk meg, hogy hol ebből a csoportból, hol a másikból választott partnerhez viszi fel a szállítói számláit. Erre is figyelnünk kell!

Felhasználói oldalon – egy nem szigorú rendszer esetén – például oly módon előzhető meg a hiba elkövetése, hogy a partnertörzs karbantartása egyetlen kézben van. Arra gondolok, hogy a partnereket kizárólag egyetlen, hozzáértő felhasználó rögzítheti a rendszerben, odafigyelve arra, hogy adott partner valóban csak egyszer szerepeljen a törzsben, és szükség esetén annak adószáma is rögzítve legyen.

Van még egy fontos feladat a 65M jelentést illetően, mégpedig a korrekciós számlák gyűjtése. Figyelnünk kell ugyanis a jelentendő számlákhoz kapcsolódó korrekciós számláinkat is, ami elő is idézi a következő hibázási lehetőséget.

A legtöbb ügyviteli szoftverben el vannak különítve egymástól az egyes számlatípusok. Így vevői, és szállítói számlatípuson belül is létezik például előlegszámla, végszámla, visszáru – a legkülönbözőbb elnevezésekkel –, de létezik módosító, érvénytelenítő, vagy helyesbítő, és sztornó számla is. Alapfeltétel, hogy az előleg és végszámlák, illetve a korrekciós és eredeti számlák össze vannak kapcsolva, így nem is okozhat különösebb gondot a jelentéshez szükséges adatok előállítása.

A hibázási lehetőség abból adódik, amikor – sok esetben szintén felhasználói nyomásra – a normál vevői és szállítói számlák is rögzíthetőek nullánál kisebb végösszeggel. Ez esetben ugyanis felhasználó rögzítheti (és sok esetben rögzíti is, mert úgy gondolja, egyszerűbb) a módosító szállítói számláját normál, de mínuszos szállítói számlaként. Az eredeti – módosítandó – számla számát pedig beírja a mínuszos számla egy megjegyzésnek fenntartott mezőjébe.

Mi a veszélye ennek a módszernek? Annyi, hogy a rendszer nem tudja figyelni – vagy nem teljes körűen – a korrekciós számlákat, így nem is tud helyes adattartalmú 65M jelentés előállni. Hiába írjuk megjegyzésbe az eredeti számla számát, a szoftvernek ez valóban csak egy megjegyzés, nincs meg a kapcsolat az eredeti számlával.

Mit tudunk tenni?

Szoftvertervezőként adjuk meg felhasználónak a lehetőséget valamennyi, nála előforduló számlatípus elkülönített rögzítésére azért, hogy ne kérje tőlünk a normál vevői, és szállítói számlák mínuszos végösszeggel történő rögzítésének lehetőségét.

Felhasználóként pedig, ha a szoftverünk egy kicsit engedékeny is, de biztosítja a lehetőséget, ne sajnáljuk azt a kis pluszmunkát, figyeljünk oda rá és a korrekciós számlákat valóban korrekciósként rögzítsük. Megjegyzem, a korrekciós számlákat – egy felhasználóbarát szoftverben – sokkal egyszerűbb rögzíteni, mint a normál számlákat, hisz a rendszer az eredeti számla valamennyi adatát bekínálja, csupán a módosuló adatokon szükséges változtatni.

Nem véletlenül említettem meg az előleg és végszámlákat sem. Ezek szabálytalan rögzítése ugyanis szintén el tudja rontani a jelentést. Miért is? Mert – hasonlóan a korrekciózott ügyletekhez – az előleges ügyleteket teljes egészében az előleg- és végszámlákat együttvéve is vizsgálnunk kell. Amennyiben előlegszámláinkat és végszámláinkat normál számlaként rögzítjük és végszámláinkon az előlegekre a szoftverünk által kezelhetetlen módon, csupán egy megjegyzés típusú mezőben hivatkozunk, úgy rendszerünkből nem tud a jelentéshez helyes adathalmaz előállni.

Sajnos ez egy olyan eset, olyan rögzítési hiba, amit szoftvertervezői oldalról szinte képtelenség kivédeni, ezért is fontos odafigyelnünk rá. Amennyiben pedig szoftverünk nem képes előlegszámlákat, végszámlákat kezelni – amennyiben lehetőségünk van rá –, kérjük a megoldást szoftverünk fejlesztőjétől.

Mindezeken felül természetesen több ponton is elronthatjuk a jelentésünket, de úgy gondolom, a leírtak azok, amik miatt kár lenne hibázni.

Nagyon fontos még és ügyeljünk rá, hogy van, amikor a számla áthárított ÁFA-értékét és van, amikor a számla levonásba helyezendő ÁFA-értékét kell figyelni! Figyeljünk továbbá a részkiegyenlített pénzforgalmi ÁFA-elszámolású számlák jelentésbe helyezésének szabályára!

Végül pedig – a fent leírtakat nagyrészt figyelmen kívül hagyva – napjainkban az adózónak már lehetősége van arra is, hogy az 1 millió forint ÁFA-érték alatti számláit is beállítsa a jelentésbe…

* * *

Legyél az elsők között! Írd be tavaszi konferenciáink dátumait már most a naptáradba és élj speciális kedvezményeinkkel! >> KEDVEZMÉNYES KONFERENCIANAPTÁR 2016 – TAVASZ