Mekkora változást hoz az online számlarendszer júliusi kiterjesztése, amely tulajdonképpen az egész vállalkozó szektort rászorítja a digitalizációra? Mi ennek a technológiai háttere?
Azzal, hogy az online számlázást kiterjeszti a NAV az összes belföldi számlára, az azt jelenti, hogy 100 százalékos pontosságú adatokat tesz elérhetővé a piaci szereplők számára. Korábban volt egy olyan fejlesztésünk, amely az analóg, vagyis papírszámlákat olvasta be és digitalizálta 90-99 százalékos pontossággal, hogy ezzel megkönnyítsük a vállalkozások, könyvelők életét. Úgyhogy számunkra ez rossz hír volt, mert a korábbi fejlesztésünk értelmét vesztette, azonban hatalmas lehetőséget láttunk az új helyzetben és megalkottuk azt a megoldást, amivel 100 százalék adatpontossággal lehet rögzíteni emberi érintés nélkül a szállítói számlákat, legyen az PDF-ben nyomtatott, szkennelt vagy akár kézi számla.
Az online számlarendszer nagy előnye az – amellett, hogy megkönnyíti az adóalanyok ellenőrzését – hogy mind a vállalkozások, mind a könyvelők számára a számlainformációk elérhetővé válnak. Csakhogy önmagukban ezek nem elegendőek. Mondok egy példát: egy vállalkozás kap egy szállítói számlát, amit bevisz a könyvelőhöz. A könyvelőprogram lehívja a NAV-tól az XML-eket, de ettől még azokat össze kell párosítani a vállalkozótól kapott számlák képével. A számlasorszámot begépeli a gépbe, ami alapján megtalálja a megfelelő XML-t pár percen belül, függően a NAV szervereinek leterheltségétől. Ezután beszkenneli a hozzá tartozó számlát, majd lefűzi azt. A folyamat nem sokkal lett hatékonyabb, csak a szállítói adatokat és tételeket nem kellett külön begépelni. Jelentős változást az hozhat a számlaképek tömeges feldolgozásában, ha kihasználjuk a NAV által biztosított lehetőségeket és automatizáljuk a folyamatokat, a képi és XML adatok összekapcsolását.
A számlázóprogramok XML-formátumban tudnak számlaadatot küldeni az adóhatóság részére a 2018. július elsején életbe lépő számlaadat-szolgáltatási kötelezettségnek megfelelően. Az XML egy olyan formázás nélküli, szöveges dokumentum, amelyet könnyen, automatikusan fel lehet dolgozni.
Nem erre szolgál a NAV rendszere azzal, hogy a számlák XML adata elérhetővé válik a könyvelőprogramok számára?
Részben, azonban a számviteli törvény szerint az eredeti bizonylat alapján kell könyvelni. Az XML adat, amit a NAV-tól le lehet kérni, az nem a bizonylat maga, csak adat. De ha törvényileg rendben is volna, az XML alapján nem lehet pontosan könyvelni. Tegyük fel, hogy egy céghez beérkezik 125 számla egy hónapban. Ebből a menedzsment befogad 120-at, 5-re azt mondja, hogy nem fizeti ki, mert nem volt mögötte teljesítés. Ez a tény viszont az XML-ből nem derül ki a könyvelő számára. De az sem, ha a számlákat a vállalkozás projektek szerint szeretné szétosztani, vagyis szükség van a számlaképekre, amit jó esetben egy számlázóprogramból küld el, de kisebb cégeknél sokkal inkább jellemző, hogy papíron, szatyorban viszik be személyesen, esetleg feladják postán. Így vagy úgy, ebből a számlaképből derül ki például a PO-szám (purchase order – megrendelési szám) – ez alapján fogják tudni beazonosítani a számla előéletét a vállalatirányítási rendszerek.
De olyan helyzet is előfordulhat, hogy az XML-hez nincs számlakép: a könyvelő nem tudhatja miért nem fogadta be a cég, elveszett, egyeztetnie kell a vállalkozóval, szállítóval. Fordítva is lehet gond, ha olyan képet kap a könyvelő, amihez nem tartozik XML – vagyis kapott egy olyan számlát, amelynek a kiállítója vélhetően nem tett eleget az adatszolgáltatási kötelezettségének.
Tehát fontos, hogy a könyvelő az XML mellé a számlaképet is megkapja és a hatékonyságnövekedés akkor lehet érdemi, ha ez is valamilyen digitális csatornán érkezik és az XML és képi adatokat nem kell manuálisan összekapcsolni. Ennek megoldására született meg az SDSYS megoldása, amely bármilyen rendszert képessé tesz a szállítói számlák automatikus és érintésmentes feldolgozására, 100 százalékos adatpontossággal, ráadásul a ma elérhető számlafeldolgozó rendszeréknél, sőt az EDI szolgáltatásoknál is kedvezőbb áron.
Amikor azt látjuk, hogy az egyik vezető kiskereskedelmi lánc a Facebookon keres számlegyeztető munkatársat szállítói számlák rögzítésére, akkor nyilvánvaló, hogy van még tér a hatékonyság növelésére, a digitális rendszerek még a nagy piaci szereplőknél is kezdetlegesek
Az EDI (Electronic data interchange) elektronikus adatcsere, egy szabványos elektronikus dokumentumkezelési automatizmus. Az EDI lehet szervezeten belüli egységek, vagy különböző szervezetek közötti üzleti párbeszédnek, adatcserének a csatornája. Magában foglalja az elektronikus adatcsere teljes paradigmáját: az adatkapcsolatot, az üzenetfolyamot, az elektronikus dokumentumok formátumát, a szoftvereket, amelyek a dokumentumok kódolására, titkosítására és értelmezésére szolgálnak.
Miért nem terjedt el az EDI használata például az élelmiszeripari kiskereskedelemben?
Ha egy cég például szeretne beszállítóvá válni három nagyobb élelmiszeripari kiskereskedelmi láncban, és digitálisan, EDI-on szeretné bonyolítani, akkor ahhoz három EDI kapcsolat kell, aminek külön-külön meg kell fizetni a díját, háromszor több százezer forintot, de a számláknak darabonként is van költsége. Ezek jelentős összegek, amit a piaci szereplők inkább elkerülnek.
Az EDI-nak az adta a hitelességét amikor 1988-ban létrejött az EDI szabvány (ISO 9735), akkoriban még az IT, az internet nem volt olyan hiteles csatorna, más világ volt. Mára azonban ez megváltozott, a technológia eljutott egy olyan szintre, hogy ha van egy olyan zárt csatorna, amin keresztül bekötöm a beszállítóimat, akkor nincs szükség egy külső, harmadik fél autentikációjára, ami nehézkessé és drágává teszi a folyamatot.
A számlázás ma úgy néz ki, hogy a vállalkozónak van egy számlázóprogramja, ami adatot küld a NAV-nak (XML), a könyvelőnek pedig átküldi a képet. A számlatömbös pedig a NAV oldalán feltölti a számla adatait, majd szatyorban beviszi a számlákat a könyvelőhöz.
Mi például az SDSYS rendszerével megoldjuk, hogy a számlázóprogramból kinyert XML-t újra disztributáljuk úgy, hogy a képet is csatoljuk hozzá. Például ez a motor hajtja a Billingo számla szinkron szolgáltatását a Billingo és az SDSYS kompatibilis könyvelőprogramok között, így megszűnik a manuális adat export/import. A SDSYS megoldásában kép és adat együtt kerül be a könyvelőprogramba, ami azért fontos, mert ezeket együtt lehet csak lekönyvelni. Így a KKV-k is nagyvállalati hatékonyságot érhetnek el a számlák feldolgozásában.
Az XML és a számlakép különválasztásra miért van egyáltalán szükség, ha ilyen sok bonyodalommal jár?
Erre a jogszabályváltozás, az adatszolgáltatás miatt van szükség, amiért a NAV bekéri a számlák adatait a cégektől. Ha képestől, mindenestől kérnék, az akkora adatforgalmat jelentene, ami egyszerűen kezelhetetlen és felesleges volna. A NAV elsődleges célja, hogy rálásson a számlaforgalomra, kiszűrje a törvénytelenségeket nem pedig az, hogy a könyvelők munkáját elvégezze. Az XML az ellenőrzéshez szükséges minden adatot tartalmazza. Az már egy másik kérdés, hogy ha már elérhető egy ilyen értékes digitális adathalmaz, akkor azt érdemes felhasználnia a könyvelőknek. A NAV ezt most elérhetővé teszi.
A feladat az, hogy a NAV-tól lekérhető XML-t a lehető leggyorsabban és legegyszerűbben újrapárosítsák a számlaképpel, amihez viszont már szükségük van a vállalkozások együttműködésére, mert a számlakép tőlük érkezik. Ennek eljuttatására és a kompatibilitási problémák, az adatkonzisztencia megőrzésre használjuk a NAVCOM 2.0 megoldásunkat.
De bármely szolgáltató, aki ezt a problémát megoldja a könyvelőknek és vállalkozóknak, valamint meg is tudja erről győzni őket, az óriási piaci előnyre tesz szert. Azok a számlázóprogramok nyerhetnek nagyot, amelyek képesek a vevői és szállítói számlákat közvetlenül bejuttatni a könyvelőprogramokba, mindenféle manuális tevékenység nélkül.
Ideális esetben ez úgy nézhetne ki, hogy a könyvelő belép a saját könyvelőprogramjába és látja, hogy a vállalkozók/beszállítók milyen számlákat küldtek be neki és mellette – párosítva – látja a NAV-tól beérkezett XML-adatokat is. Itt még hozzáírhat főkönyvi számot, projektszámot, pozíciószámot, stb., de az adatrögzítéssel nem kell foglalkoznia, ezt a szoftverek már elvégezték.
Az egész arról szól, hogyha valaki egyszer egy számlát rögzített digitálisan, akkor annak van egy lenyomata, ami mások által felhasználható. A gond ott van, hogy ezek a rendszerek teljesen más input-output adatokat dobnak ki, amik nem kompatibilisek egymással. A NAV rendszere egyfajta megoldást nyújt erre a problémára, azzal, hogy mindenkitől megkövetel egy standard XML formátumot. A mi megoldásunk bármely rendszerrel képes együttműködni láthatatlan módon. Vagyis egy könyvelőnek nem kell leváltania a megszokott könyvelőprogramját, mert azokat az adatokat, amelyeket – még ha digitálisan születtek is meg – kompatibilitási problémák miatt be kellett gépelni, most egyszerűen le tudja hívni.
Felhasználói oldalról a probléma a gondolatmenttel van, hogy még a digitálisan előállított számlákat is előfordul, hogy kinyomtatják, majd beszkennelik, hogy rögzítsék egy másik rendszerben, ahelyett, hogy az elektronikus adatot a digitális térben kezelnék.
Ki lehet a nyertese ennek a digitális átállásnak?
Elsősorban azok a közepes és nagyobb vállalatok, akik nagy mennyiségű számlát dolgoznak most fel manuálisan vagy fél automatikusan. Ők egy életre elfelejthetik a szállítói számlák manuális rögzítését. A fix adminisztrációs költségek csökkenni fognak és a folyamataik teljesen válságállóvá, automatikussá és érintésmentessé válnak.
Másodsorban a klasszikus könyvelő irodák piacán a számlázóprogramok vannak jó helyzetben, mert rendelkeznek a technikai felhasználóval, amivel a könyvelőprogramok nem feltétlenül. (A technikai felhasználót a NAV generálja, amely a gép-gép közti online adatszolgáltatáshoz szükséges.) Rendelkezésükre áll minden fontos információ, hiszen ők küldik be a számlaadatokat a NAV-hoz és így vissza is kaphatják azokat. Tehát rendelkezésre áll a vevő és szállító számla XML -je is. A dolog ott lesz érdekes, hogy hogyan jutnak el a szállítói számla képi információi a címzettnek, a könyvelőnek? Az online számlázóprogramok online át szeretnék küldeni a telepített, a neten nem elérhető könyvelői programokhoz, kérdés, hogy hogyan.
Jelenleg a számlázó - és könyvelőprogramok között úgynevezett feladásokat csinálnak, ami azt jelenti, hogy kiszednek – exportálnak – egy rendszerből egy fájlt, majd miután eljuttatták a könyvelőhöz, aki betölti – importálja – a könyvelőprogramba. Ezt szakszerűen úgy mondják, hogy az adatkonzisztencia megszűnhet, nem natív módon kommunikálnak egymással a rendszerek.
A könyvelőprogramok szemszögéből kicsit bonyolultabb a helyzet, mert ott nem biztos, hogy rendelkeznek minden technikai felhasználóval. Így viszont egyszerre két folyamatot kell fenntartaniuk - egyet a régi folyamatnak, durván az ügyfelek 20 százalékánál, a többségnél pedig egy teljesen újat. Ez nem hogy nem hatékony, hanem egyenesen kontraproduktív. A szoftverfejlesztőknek kell megoldaniuk a technikai részleteket, ehhez pedig a számlázóprogramok fejlesztői előnyből indulnak. A megoldás az lenne, ha a szoftverfejlesztő cégek leülnének és együtt kidolgoznának megoldásokat, amelyek univerzálisak. Jelenleg inkább az történik, hogy egy-egy cég köt együttműködést és egymástól független ökoszisztémákat építenek, amelyek csak egymással kompatibilisek. Ezzel viszont váltásra kényszerítik a könyvelőket. A jó megoldás az, ha a meglévő programok felokosításával teremtjük meg a kapcsolatot a programok között, mi ebben láttuk meg a piaci rést. Több könyvelőprogram is nyitott a változásra, érdemes velük hosszú távra tervezni.
Milyen külföldi minták vannak a könyvelési folyamat, az adatrögzítés digitalizálására? Átültethetőek ezek a megoldások a magyar rendszerbe?
A brit piacon például a könyvelők – kis túlzással – életükben nem láttak számlaadtarögzítést. Úgy dolgoznak, hogy bejönnek az adatok, ők pedig adóterveznek, könyvelnek, tanácsadást végeznek. A kétmillió felhasználóval rendelkező könyvelőprogramban, a Xero-ban 900 beépített alkalmazás van, tehát ennyi szoftverrel tudnak kommunikálni. Magyarországon néhány ilyen könyvelőprogram van, azok is legfeljebb 3-4 másik számlázóprogrammal tudnak kommunikálni natívan. A külföldi rendszereknél rájöttek arra, hogy egyszerűbb, ha ők maradnak a core tevékenységüknél és nem akarnak egyszerre munkaügyi nyilvántartók, EDI szolgáltatók vagy task managerek lenni. Magyarországon hajlamosak a fejlesztők mindent maguk megcsinálni a könyvelőprogramtól a számlázón át az üzleti intelligenciáig. Ahelyett, hogy egy rendszer lenne, mindenki egy protokollt tudna használni. Persze nem fair a magyar adókörnyezetet összehasonlítani a brit rendszerrel, de magában az elv, hogy a könyvelőknek hozzáadott értékű szolgáltatást kell nyújtaniuk, arra most lesz igazán lehetőségük az elkövetkezendő két évben.
Milyen piaci átrendeződéssel fog járni a folyamat és mit nyernek vele a vállalkozások?
A bürokrácia csökkenésén túl a vállalkozók is nyernek, mert például látni fognak valós idejű áfa értéket, valós idejű szállítói tartozásokat, a vevői kintlévőségeket, de ha feltöltik e mellé a külföldi számlákat, akkor már a valós idejű cash flow-t is látják majd. A könyvelőknek pedig megszűnik az adatrögzítés, csak a külföldi számlákat kell majd külön felvinniük, az idejük többi részében foglalkozhatnak adótanácsadással vagy adóoptimalizálással.
Azok a könyvelők, akik eddig az adatrögzítésből éltek, nekik nehéz lesz. El fog indulni egy olyan típusú verseny a könyvelők között, amire még ők sem számítanak, mert az utóbbi 20 évben nem voltak rákényszerülve, hogy versenyezzenek.
Van Magyarországon körülbelül 100 elterjedt könyvelőprogram stabil ügyfélbázissal, a könyvelők pedig nagyon ritkán váltanak szoftvert. Ha ezt megteszik a következő 2-3 évben, az nem egy évre fog szólni. Ha valaki most okosan meg tudja fogni a könyvelőket és figyel az ő igényeikre, akkor nagy nyertese lehet ennek a folyamatnak.
Mi a helyzet a nagyvállalati rendszerekkel?
Corporate oldalon most vált létfontosságúvá a beszállítókkal való kapcsolattartás megreformálása, és hogy mennyire tudják ezt 100 százalékban digitális útra terelni. A NAV miatt rengeteg nagyvállalat rendszerét is át kell állítani, ezért olyan technológiai partnerekkel is együtt dolgozunk, mint például SAP tanácsadó cégek. Kidolgoztunk egy modult, amely pár hét alatt képes bármilyen SAP rendszert NAV kompatibilissé tenni. A cél az, hogy ez egy dobozosított, nagyvállalatok számára elérhető csomag legyen. Hiába dolgoznak ugyanis saját fejlesztőcsapattal a nagyoknál, ha a csapat vezetője külföldi, aki nincs képben a magyar jogszabályi változásokkal, akkor ezeket a munkákat kiadják külsős cégeknek. Itt jön képbe az SDSYS, amely NAV kompatibilissé teszi a rendszerüket, innen pedig már csak egy lépés, hogy az egész beszállítói rendszerükre kiterjesszük ezt. Kvázi ez a mi trójai falovunk, mert egyébként egy kis magyar cég nehezen rúg labdába a nagyoknál, azonban a NAV-os átállás kapóra jött nekünk. Növekedési stratégiánk része, hogy réspiaci megoldással szolgáljuk ki a nagyobb technikai partnereket, ERP, ECM szolgáltatókat.
A cikk megjelenését az SDSYS támogatta.
