Januártól két fronton is módosult az online számlázás rendszere:
- egyrészt bővült a jelentendő számlák köre: a magánszemélyek részére és az Európai Unió más tagállamába történő termékértékesítés és export után kiállított számlák is bekerültek a rendszerbe, így – egy-két esetet leszámítva – gyakorlatilag a gazdasági élet teljes számlaforgalmára rálátása nyílik a NAV kockázatelemzőinek
- másrészt új, a 3.0 sémát kell alkalmazni a jelentéshez.
Az adatszolgáltatásra kötelezettek körének kiterjesztése – amellett, hogy piaci elemzők számításai szerint az online számlázás így már legalább 200-250 milliárd forint éves plusz bevételt termel majd a költségvetésnek – elsősorban a beérkező számlák számában hozott látványos változást: amíg tavaly decemberben hétköznaponként átlagosan egymillió online számla érkezett az adóhivatalhoz, ez február elejére a duplájára nőtt, 2,3 milliós napi rekorddal.
Azonban az exportáló vállalatok életében is jelentős változást hozott az új év. „Kétfajta példát látunk: az egyik, amikor egy nemzetközi multi leányvállalata működik Magyarországon és az anyacég IT osztálya kér tanácsadást, hogy megpróbálja értelmezni és a saját rendszerébe implementálni az új 3.0 sémát” – mondta a Portfolio-nak Poór Károly, a digitális megoldások fejlesztésével foglalkozó SDSYS cégvezetője, aki azt is hozzátette, hogy ez részben IT feladat, részben viszont adótanácsadási kérdés. Itt egy közös munka, fejlesztés után megtörténik a validáció.
A másik példa, amikor a külföldi partnernek erre nincs kapacitása vagy kompetenciája. Erre az SDSYS-nek van egy szolgáltatása, ami nagy vonalakban abból áll, hogy a meglévő rendszerből kinyerik a megfelelő információkat, azokat átkonvertálják NAV-adatszolgáltatási xml-lé és online továbbítják az adóhatóságnak, majd visszaküldik a válaszüzeneteket a felhasználónak. „Ez is jellemzően tanácsadásnak szokott indulni, aztán mikor a cég elkezd kifutni az időből akkor inkább ránk bízza a feladatot” – teszi hozzá Poór, aki szerint néhány száz cég járhat ebben a cipőben, de az új cégek köre is mindössze pár ezerben mérhető, ráadásul a koronavírus-válság miatt március 31-ig az adatszolgáltatási körbe újonnan belépők haladékot kaptak: a NAV nem szab ki mulasztási bírságot, ha a vállalkozó nem, vagy nem megfelelően szolgáltat adatot a számláiról.
Változtak az áfa kódok
Az már azonban nemcsak az exportáló cégeket érinti, hogy egy sor új áfa kód került be a 3.0 kötelező adatszolgáltatásba, amelyek nem csak informatikai fejlesztést kívánnak a saját rendszert használóktól, hanem már számviteli szinten is újra kell gondolni a működést. „Tapasztalatunk szerint sok helyen okoz fejfájást az áfa kódok értelmezése, amelynek oka jellemzően az információhiány, illetve, hogy az eddigi folyamat és ráépülő szoftver nem elég rugalmas, hogy mindezt kezelni tudja. A bevezetések során az IT mellett az adótanácsadási kérdések voltak a leggyakoribbak, hogy közösen kitaláljuk, hogy az adott ügylet épp melyik áfa kód alá esik és ezt a rendszerben, hogy lehet időtállóan kezelni” – mondta a szakember.
Ugyanis amíg eddig elég volt, ha az áfamentes számlázásnál megadták, hogy alanyi vagy tárgyi mentes, ez mostantól sokkal nehezebb lesz, az adómentesség okát pontosan, részletesen meg kell adni. Ennek oka Poór szerint az erős EU-harmonizációs cél mellett, hogy önmagában a termék, szolgáltatás értékesítésének a módja, az áfa-visszaigénylés, az adóztatás helye és ennek az átláthatósága vált kiemelten fontossá. Például olyan áfakóddal, hogy új közlekedési eszköz értékesítése, még nem találkozott egy átlagos magyar felhasználó a Billingo-ban vagy a Számlázz.hu-ban. Azt kellett a vállalatoknak felmérniük, hogy mivel kell indokolniuk a NAV-os adatszolgáltatásban, hogy egy adott ügylet tétele miért esik esetleg áfakörön kívül.
Az xml válik a számlává, de felvet néhány kérdést a "csodafegyver"
Jelentős változás továbbá, hogy a NAV lehetővé teszi, hogy maga a 3.0 séma szerinti xml is tekinthető majd számlának: „a NAV csodafegyverként jelentette be, hogy mostantól elektronikus számlát is hitelesít. Ez azt jelenti, hogy amennyiben az xml ugyanazokat az információkat tartalmazza, mint a számla, és a kiállító teljes jogi felelősséggel vállalja, hogy ennek a számlának nincs több információtartalma, akkor a NAV-hoz felküldött adatszolgáltatási xml-ből a NAV hitelesítve ad vissza egy letölthető példányt” – mondta Poór.
Azonban a NAV nem tárolja a számlát, illetve a hitelesítés módja miatt számlakép sem keletkezik, ami a szakember szerint felvet néhány kérdést. Az első, hogy a számlának a számviteli törvény szerint van egy formai követelményrendszere, aminek az xml féle e-számla jelen pillanatban nem felel meg, de ez egy szabályozási kérdés, hozzá lehet igazítani a követelményrendszert.
„Ennél nagyobb probléma, hogy a NAV nem tárolja ezeket az e-számlákat. A hagyományos e-számlánál is az a probléma, hogy senki nem akarja ezeket tárolni digitálisan, inkább kinyomtatják. Ha a fogadó fél elfogadja a számlát, mondjuk ráutaló magatartással, vagyis kifizeti, neki is le kell tárolnia azt, és ő sem digitálisan fogja megőrizni.
Igazából nincs itt akkora hozzáadott érték, hiszen hiába e-számlát bocsátottak ki, végül mindenki kinyomtatja”
– mutatott rá Poór.
További probléma, hogy a számlakibocsátónak értesítenie kell a befogadót, hogy számlát állított ki részére, hiszen a NAV nem küld értesítést: elvileg kaphat úgy számlát vállalkozás, hogy nem tud róla.
Van az adatoknak egy megfelelő gravitációs esése: megérkezik a teljesítés, kiállítom a számlát, elküldöm postán vagy digitálisan, iktatják, jóváhagyják, lekönyveljük. A NAV az e-számlával megkerüli ezeket és átugrik sok folyamati lépcsőt
– mondta a cégvezető, aki szerint logikailag alkalmazható lehetne az e-számla, azonban a gyakorlat azt mutatja, hogy a piaci szereplők nem ennek megfelelően járnak el.
„Maga az ötlet remek, de a felhasználás módját ki kell találni. Jelenleg azt látjuk, hogy ez nagy fejvakarást okoz, mert a kiállítói oldalon ad egy plusz terhet, hiszen szólni kell a partnereknek, hogy küldtek egy számlát. A NAV nem vállal semmilyen felelősséget, ha az a számla valamilyen módon elveszik, az olyan, mintha a postás hagyta volna el. Ennek egy szerződéses viszonynak kéne lennie a felek között, hogy beépítik a NAV-os adatszolgáltatást, ami jelenleg nem életszerű” – figyelmeztet a szakember.
A cégvezető szerint
akkor lehetne ez hatékony, ha a vállalatok felismernék, hogy változtatni kell a folyamataikon és a megfelelő helyen – a befogadás pillanatában – csatornáznák be az e-számlákat.
Ez kkv-szinten az online számlázóprogramot jelenti, ott megvan a technikai azonosító, a feltöltés azon keresztül megy, a letöltés is látható, hogy mik a bejövő számlák, és melyikhez tartozik számlakép. Nagyvállalatoknál pedig az iktatási folyamatnál, a számlajóváhagyás előtt kell beépíteni azt a rendszert, ami letölti az xml-eket, amihez kell kép, azt megvárja, összeköti, amihez meg nem, azt tovább engedi. Így nem kell a könyvelésnek visszakérdezni, hogy mi ez a számla, hanem az végig tud menni a folyamaton.
Ehhez azonban egy olyan rendszerre van szükség, amely fel van készülve arra, hogy karakterpontosan ugyanazt rá tudja tenni a NAV xml-re, amit egy pdf-re rátenne. Jelenleg a digitális megoldásokat szállító szolgáltatók piacát ketté lehet bontani: vannak rendszerek, amelyek képesek erre, de vannak, amelyek csak a kötelezően előírt adatokat küldik be a NAV-hoz, így pedig a vevő nem értesül róla, hogy számlája érkezett. Poór szerint itt felmerül a kérdés, hogy ezt ki, és hogyan fogja ellenőrizni, hiszen a NAV jelenleg nem nyilatkozott arról, hogyan fogja ezt ellenőrizni.
Az SDSYS MATCHING elnevezésű megoldása letölti az xml-eket, megkeresi a számlakép-párokat, ha pedig a 3.0 séma szerint kitöltött e-számla jön, akkor tovább engedi, láthatatlan módon együttműködve a különböző vállalatirányítási rendszerekkel.
A könyvelők gyorsan alkalmazkodtak
A könyvelők már előszeretettel használják az xml-t, ami abból is látszik, hogy ha van egy leállás, és a NAV nem ad adatot 10 percen belül, akkor szakmai fórumokon egyből hangot adnak felháborodásuknak. A NAV-tól kapott adatok felhasználásnak legjellemzőbb módja, hogy betöltik a könyvelőprogramba az összes xml-t, és egyfajta sorvezetőként használják, mikor összenézik az ügyfelektől kapott számlaképekkel. „Ez egy félautomata megoldás, ami hoz némi segítséget, de ugyanúgy ellenőrizni kell, megnézni a számlaképet, ellenőrizni az adatokat, van vele manuális munka.
Az igazi áttörés az volna, ha egyből a számlázóprogramból átjönne a számlakép."
A szakember szerint ehhez a rendszer már ki van alakítva, van olyan számlázóprogram, ahol ez lehetséges, csak a piacnak kell felvennie a lépést a rohamtempóban fejlesztő NAV-val.
A cikk megjelenését az SDSYS támogatta.
