NAV XML Excelbe konvertálás könyveléshez

A NAV Online Számla rendszerből lekért számla XML-eket akkor érdemes Excelbe rendezni, ha havi könyvelési listát, ÁFA-előkészítést vagy ellenőrzési munkafüzetet készítesz. A legstabilabb szerkezet két lapból áll: egy számlafej-lapból, ahol egy sor egy számla, és egy tétellapból, ahol egy sor egy számlatétel, közös számlaazonosítóval.

Ez a NAV XML Excelbe konvertálás lényege könyvelési feldolgozásnál. Nem az a cél, hogy a teljes NAV Online Számla 3.0 XML sémát egyetlen óriási táblába öntsd, hanem hogy a NAV-tól letöltött számla XML-ből olyan munkafüzet készüljön, amelyet tényleg lehet használni partnerellenőrzésre, kontírozási előkészítésre, ÁFA-listára vagy könyvelőprogram-import előtti tisztításra.

Az egyetlen lapos megoldás gyorsnak tűnik, de hamar szétcsúszik. Egy számlának lehet egyetlen tételsora, de lehet ötven is. Ha minden tételsor külön sorba kerül, a számlafej-adatok ismétlődnek, és a számlaszintű összesítések könnyen duplázódnak. Ha minden számla egy sorban marad, elveszik a tételszintű ÁFA, termék, szolgáltatás, költséghely vagy elemzési bontás.

A kétlapos modell ezért könyvelői szempontból tisztább:

• Számlafej-lap: egy sor egy számla, a partner, dátum, deviza, nettó, ÁFA és bruttó összegek fő adataival.
• Tétellap: egy sor egy számlatétel, a tételleírással, mennyiséggel, egységárral, ÁFA-kulccsal és tételszintű összegekkel.

A két lapot közös számlaazonosító köti össze. Ez lehet a NAV-ból jövő számlaszám és a saját cég adószámának kombinációja, vagy egy belső technikai kulcs, amely minden tételsoron ismétlődik. Így a számlafej és a tételsor külön kezelhető, de bármikor összekapcsolható pivotban, Power Query-ben vagy importfájl-készítésnél.

Ez a cikk nem az Online Számla adatszolgáltatási kötelezettség részletes magyarázata. A kiindulópont az, hogy a számlaadat már ott van a NAV rendszerében, és a könyvelő azt szeretné átalakítani ismételhető, ellenőrizhető Excel-munkafolyamattá.

Mit tölthetsz le a NAV Online Számlából, és melyik út mikor elég

A NAV Online Számla feldolgozásánál először azt kell eldönteni, milyen adatot és milyen gyakran akarsz lekérni. Más megoldás kell egy kis cég havi gyors ellenőrzéséhez, és más egy könyvelőirodának, amely sok ügyfél számláit dolgozza fel minden hónapban.

Három gyakorlati út létezik.

• Webes listaexport: akkor elég, ha kevés számlát ellenőrzöl, és a NAV Online Számla felületén szűrt lista adataival dolgozol. Ez gyors ellenőrzésre jó, de nem mindig ad elég részletet tételszintű feldolgozáshoz.
• XML-letöltés: akkor hasznos, ha a számlafej mellett a számlatételeket, ÁFA-kulcsokat, devizát, partneradatokat és módosító kapcsolatokat is ki akarod bontani Excelbe.
• API-s vagy szoftveres lekérés: akkor indokolt, ha sok cég, sok ügyfél vagy ismétlődő havi folyamat van. Ilyenkor a kézi export ideje és hibakockázata gyorsan nagyobb lesz, mint a beállítási munka.

A kézi út általában így néz ki: belépsz az onlineszamla.nav.gov.hu felületre, kiválasztod a saját céget vagy ügyfelet, beállítod az időszakot, külön szűröd a bejövő és kimenő oldalt, majd letöltöd a listát vagy az XML-adatot. API-s útnál előbb technikai felhasználót kell létrehozni az adminisztrációs részen, rögzíteni kell a szükséges kulcsokat a lekérő szoftverben, majd időszakra, irányra és adószámra szűrt lekérdezést kell futtatni. Könyvelőirodában érdemes ügyfelenként dokumentálni, ki adta a jogosultságot, milyen időszakot kérdeztek le, és hol van az eredeti exportfájl.

A technikai felhasználó a gépi lekéréshez tartozik. Könyvelői nyelven ez nem "plusz könyvelői jog", hanem egy NAV Online Számla felhasználói típus, amelyhez az API-s kapcsolat azonosítói és kulcsai kapcsolódnak. Ha csak a webes felületen töltesz le listát vagy fájlt, nem ugyanazt a munkát végzed, mint amikor egy program rendszeresen lekérdezi a számlaadatokat egy technikai felhasználón keresztül.

A NAV hivatalos oldala adja a technikai alapot: a NAV Online Számla publikus fejlesztői tárhelye elérhetővé teszi az éles webes felületet, az éles API-végpontot, az aktuális 3.0 interfészspecifikációt, valamint az M2M interfészhez tartozó sémaleírókat, példa XML-eket és leírásokat. Könyvelőként ebből nem kell minden XSD-részletet megtanulni, de fontos tudni, hogy a 3.0 séma az a feldolgozási logika, amelyhez a mai NAV XML-eket igazítani kell. Régebbi 2.0 XML-t csak archív vagy történeti exportoknál érdemes külön kezelni; a mai havi feldolgozást ne erre építsd.

A bejövő számlák lekérése NAV XML alapon más kérdés, mint a kimenő számlák ellenőrzése, de a kiinduló rendszer ugyanaz. A cég lehet vevő, amikor szállítói számlákat keresel, vagy eladó, amikor a saját kibocsátott számláidat ellenőrzöd. Több cégnél vagy több ügyfélnél a lekérdezési időszak, az adószám és a jogosultság pontos beállítása ugyanannyira fontos, mint maga az export.

Ha a jogszabályi és adatszolgáltatási háttér a kérdés, akkor külön kell kezelni a NAV Online Számla adatszolgáltatási kötelezettsége témát. Itt a feldolgozási oldal a lényeg: hogyan lesz a NAV-nál már meglévő számlaadatból könyvelési Excel.

A kétlapos Excel-munkafüzet mezői könyveléshez

A jó NAV XML feldolgozás könyveléshez nem a lehető legtöbb oszlopot jelenti. A jó munkafüzet annyi mezőt tart meg, amennyiből a számla azonosítható, ellenőrizhető, összesíthető és továbbadható a könyvelési folyamat következő lépésére.

A számlafej-lap legyen egy sor per számla logikájú. Praktikus oszlopok:

• belső számlaazonosító
• irány, például bejövő vagy kimenő
• saját cég adószáma vagy ügyfélkód
• invoiceNumber
• supplierTaxNumber
• customerTaxNumber
• szállító neve
• vevő neve
• invoiceIssueDate
• invoiceDeliveryDate
• currencyCode
• exchangeRate
• számla nettó összesen
• számla ÁFA összesen
• számla bruttó összesen
• dokumentumtípus vagy státusz
• megjegyzés vagy ellenőrzési státusz

A tétellap legyen egy sor per számlatétel logikájú. Itt a számlaazonosító ismétlődik, mert ez köti vissza a tételt a számlafejhez. Hasznos oszlopok:

• belső számlaazonosító
• invoiceNumber
• tételsorszám
• lineDescription
• mennyiség
• egységár
• lineNetAmount
• vatRate
• lineVatAmount
• lineGrossAmount
• költséghely
• főkönyvi szám javaslat
• tétel megjegyzés

A mezőket már a konverzió után normalizáld. A dátumok legyenek egységes formátumban, a számmezők valódi Excel-számok legyenek, ne szövegként beolvasott értékek, az ÁFA-kulcs pedig következetesen százalék vagy külön kód legyen. Devizás számlánál a currencyCode és exchangeRate alapján őrizd meg az eredeti devizát és a forintos ellenőrzési értéket is. Minden import előtt fusson egy egyszerű kontroll: a tétellap lineNetAmount, lineVatAmount és lineGrossAmount összege számlánként egyezzen a számlafej nettó, ÁFA és bruttó összesítőjével.

A NAV XML számla tételek Excelbe emelésénél a közös kulcs a legfontosabb szerkezeti döntés. Ha a tétellapon minden sorban szerepel ugyanaz a számlaazonosító, akkor a számlafej-adatok visszakereshetők XLOOKUP-pal, összefűzhetők Power Query-ben, és szűrhetők pivotban. Ha ez hiányzik, a munkafüzet látványra lehet rendezett, de import vagy ellenőrzés közben törékeny lesz.

Nem kell minden XML-ágat külön oszlopként kitenni. A NAV invoiceData XML sok olyan információt hordoz, amely fejlesztői vagy speciális ellenőrzési helyzetben hasznos, de a havi könyvelési listában csak zajt adna. A mezőválasztás célja nem a teljes séma lemásolása, hanem egy állandó könyvelői adatmodell: azonos számlaazonosítás, stabil dátummezők, következetes partneradatok, tételszintű ÁFA-bontás és olyan megjegyzésmezők, amelyekbe az ellenőrzési munka eredménye visszaírható.

Ha könyvelőprogram-import a cél, a fejlécneveket igazítsd az adott rendszer elvárásaihoz. Ha ügyfélriport vagy belső ellenőrzés készül, maradhatnak beszédesebb oszlopnevek. A lényeg, hogy a számlafej és a tételsor ne keveredjen egyetlen táblába, mert más kérdésekre válaszolnak.

Bejövő és kimenő számlák: azonos XML-logika, eltérő ellenőrzési cél

A NAV XML szerkezete hasonló marad, de a könyvelői kérdés attól függ, hogy a cég vevőként vagy eladóként szerepel a számlán. Ezért az Excelben ne csak a mezőket tartsd meg, hanem az irányt is jelöld külön oszlopban.

Bejövő számláknál az elsődleges kérdések általában ezek:

• ki a szállító;
• szerepel-e helyesen a saját cég vevőként;
• mikor volt a teljesítés és a számlakibocsátás;
• milyen nettó, ÁFA és bruttó érték jelenik meg;
• milyen ÁFA-kulcsok vannak tételsoronként;
• illeszkedik-e a számla a kapott PDF-hez, jóváhagyáshoz vagy szerződéshez.

Ez az AP oldal: szállítói lista, levonható ÁFA, költséghely, jóváhagyás, fizetési előkészítés. Itt a supplierTaxNumber a partner adószáma, a customerTaxNumber pedig a saját cégé vagy az ügyfélé, akinek könyvelsz.

Kimenő számláknál a hangsúly más. A saját cég eladóként szerepel, ezért a supplierTaxNumber lesz a saját adószám, a customerTaxNumber pedig a vevőé. A munkafüzet ilyenkor vevői listát, fizetendő ÁFA ellenőrzést, árbevételi összesítést és számlázási kontrollt támogat. A kérdés nem az, hogy levonható-e az ÁFA, hanem hogy a kibocsátott számlák teljes, helyes és időszakhoz illeszkedő listája szerepel-e a zárásban.

Több ügyféllel dolgozó könyvelőirodánál a saját cég adószáma önmagában nem mindig elég. Érdemes külön ügyfélkódot, cégnevet vagy belső mappanév-azonosítót is felvenni a számlafej-lapra. Ha ugyanabban az Excel-munkafüzetben több cég időszaki adata szerepel, enélkül könnyen összekeverednek a partnerösszesítők és az ÁFA-kimutatások.

Az irány oszlop egyszerűnek tűnik, mégis sok későbbi hibát megelőz. Ugyanaz a számlaszám vagy partnernév egészen más ellenőrzési logikát kap attól függően, hogy bejövő vagy kimenő számláról van szó.

Módosító, sztornó, devizás és fordított adózású számlák jelölése

A NAV XML-ből készült Excel akkor használható ellenőrzési munkafájlként, ha a kivételeket nem rejti el. A tiszta sorok mellett szükség van olyan oszlopokra is, amelyek megmutatják, melyik számla igényel könyvelői figyelmet.

Módosító, helyesbítő és sztornó számláknál ne csak az összegeket vedd át. Legyen külön dokumentumtípus- vagy státusz-oszlop, és ha elérhető, az eredeti számlára mutató hivatkozás is kerüljön a munkafüzetbe. Egy negatív összeg önmagában nem mondja meg, hogy sztornóról, árengedményről, jóváírásról vagy hibásan értelmezett tételről van szó.

Devizás számláknál a currencyCode és az exchangeRate nem mellékes mező. Ha a számla EUR-ban vagy USD-ben készült, de a könyvelés forintban ellenőriz, akkor az ÁFA és a főkönyvi összeg csak akkor követhető vissza, ha a devizanem és árfolyam is ott van a számlafej-lapon. A tétellapon pedig a lineNetAmount, lineVatAmount és lineGrossAmount segít látni, hogy a tételszintű bontás összeadódik-e a számlafej összesítőjére.

Fordított adózású, ÁFA-mentes vagy több ÁFA-kulcsot tartalmazó számláknál a tételszint különösen fontos. Ha csak számlafej-szintű bruttó összeg kerül Excelbe, elveszik az a részlet, amely alapján később megállapítható, mely tétel tartozik melyik ÁFA-kezelés alá. A vatRate mező ezért ne csak ellenőrzési adat legyen, hanem pivot- és szűrési alap.

Hasznos hibajelző oszlopok:

• hiányzó vagy gyanús adószám;
• partnernév és adószám eltérése;
• devizanem vagy árfolyam hiányzik;
• nulla ÁFA indoka nincs jelölve;
• módosító számla eredeti számlaszám nélkül;
• számlafej és tételsor összesen eltér;
• kézi egyeztetés szükséges.

Ezek nem jogi minősítések. A cél az, hogy a havi ÁFA-előkészítés előtt a munkafüzet megmutassa, mely sorok könyvelhetők rutinszerűen, és melyeket kell egyeztetni az ügyféllel, a szállítóval vagy a számlaképpel.

Havi ÁFA-előkészítés NAV XML-ből

A NAV XML-ből készült Excel nem helyettesíti a könyvelői döntést, de nagyon jó előkészítő munkafüzet lehet. A cél az, hogy a számlaadatokból gyorsan látszódjon, mit kell egyeztetni, mely partnerek adják a nagy tételeket, és hol van eltérés az időszaki ÁFA-ellenőrzéshez.

A leggyakrabban hasznos pivotok:

• partnerenkénti nettó, ÁFA és bruttó összeg;
• ÁFA-kulcsonkénti összesítés;
• bejövő és kimenő irány szerinti bontás;
• devizanem szerinti számlalista;
• teljesítési dátum szerinti időszaki szűrés;
• dokumentumtípus szerinti bontás, például normál, módosító, sztornó;
• saját cég vagy ügyfélkód szerinti csoportosítás könyvelőirodai munkához.

Az M-lap, az A-lap és a belső ÁFA-ellenőrzés nem ugyanazt a nézetet kéri. Vezetői vagy ügyféloldali gyorslistához sokszor elég a számlafej-lap, mert ott egy sor egy számla. ÁFA-kulcsonkénti ellenőrzéshez, többkulcsos számlákhoz és tételes vizsgálathoz viszont kell a tétellap is. Ha a tételsorokat túl korán összesíted, később nem tudod visszanézni, melyik sor okozta az eltérést.

Az online számlaadatok más NAV-folyamatokban is megjelennek. A NAV eÁFA munkafolyamat és az online számlaadatok külön téma, mert ott a NAV által összeállított vagy támogatott ÁFA-adatfolyam kerül előtérbe. Ennél az Excel-munkafüzetnél a könyvelő saját ellenőrzési nézetet épít: mit lát a NAV, mit kapott meg az ügyfél, mit lehet könyvelni, és mely sorok igényelnek kézi ellenőrzést.

Fontos határ: a NAV XML adatforrás, nem könyvelési állásfoglalás. Attól, hogy egy számla szerepel a lekérdezésben, még ellenőrizni kell a levonhatóságot, a teljesítési dátumot, a szerződéses hátteret, a számlaképet és a belső jóváhagyást. Az Excel akkor segít igazán, ha ezeket az ellenőrzési státuszokat is vissza tudod vezetni ugyanabba a munkafájlba.

Amikor a NAV XML nem egyezik a kapott számlaképpel

A NAV XML-ben szereplő adat és a könyvelőhöz beérkezett PDF, papír vagy szkennelt számlakép nem mindig ugyanazt a képet adja. Ez nem feltétlenül csalás vagy súlyos hiba. Lehet kerekítési eltérés, később beküldött módosító számla, hiányzó melléklet, rosszul kezelt sztornó, partneradat-eltérés vagy egyszerűen az, hogy az ügyfél még nem küldte át a számlaképet.

Ezért érdemes a számlafej-lapon nemcsak NAV-mezőket tartani, hanem egyeztetési oszlopokat is:

• számlakép megvan;
• PDF vagy papír számla összege egyezik;
• teljesítési dátum egyezik;
• partnernév és adószám egyezik;
• tételsorok száma egyezik;
• eltérés oka;
• egyeztetés státusza;
• ügyfélnek vagy szállítónak elküldve;
• módosító számla szükséges.

A nyers NAV XML Excelbe rendezése vendor-semleges adatfeldolgozási feladat. Ahol külön eszköz természetesen beléphet a munkafolyamatba, az a NAV-adatok melletti számlakép- és dokumentumoldal. Ha a könyvelő e-mailben kapott PDF-ekből, szkennelt számlákból vagy mobilfotókból is ugyanazokat a mezőket akarja kinyerni, ott a számlaadatok Excelbe rendezése már nem XML-konverziós, hanem dokumentum-extrakciós munka.

Az Invoice Data Extraction ilyen kiegészítő helyzetben releváns: PDF, JPG és PNG formátumú számlákból és más pénzügyi dokumentumokból készít strukturált Excel, CSV vagy JSON kimenetet. A felhasználó megadhatja, milyen mezőket kér, például számlaszámot, dátumot, szállítót, nettó összeget, ÁFA-t, bruttó összeget vagy tételsorokat. A kimenet sorai forrásfájl- és oldalszám-hivatkozást is tartalmazhatnak, ami az egyeztetésnél hasznos. Ez nem nyers NAV XML-import, hanem a NAV-lista mellé érkező számlaképek strukturálása.

Ugyanez a gondolkodás más havi dokumentumokra is igaz. A bérjegyzék PDF-ek könyvelői Excel-összesítése például nem NAV XML-feladat, mégis ugyanabba a zárási logikába illeszkedik: különböző forrású pénzügyi dokumentumokból ellenőrizhető, rendezett Excel-adatot kell készíteni. Hasonlóan jár el a könyvelő, amikor a számlaoldal mellett az OTP-s PDF bankkivonatot tételesen Excelbe rendezi a banki mozgások és a NAV-ból érkező számlák egyeztetéséhez.

Mikor maradjon kézi Excel, és mikor kell automatizált lekérés

A kézi Excel-munkafolyamat nem hibás választás, ha a volumen kicsi és az ellenőrzés ritka. Egy-két kis ügyfélnél, kevés havi számlánál vagy alkalmi revíziónál a webes export, az XML-ből készített kétlapos munkafüzet és néhány pivot teljesen arányos megoldás lehet.

Automatizált lekérésre akkor érdemes váltani, amikor a munka ismétlődése önmagában kockázat. Ilyen helyzet, ha sok ügyfél NAV-adatait kell havonta lekérni, ha a tételsorok száma magas, ha több cég adatait kell egységes oszlopsémába rendezni, vagy ha a könyvelőprogram-import előszobájaként minden hónapban ugyanazt a fájlszerkezetet kell előállítani.

A döntést nem csak a számlák darabszáma adja. Ezeket a szempontokat érdemes együtt nézni:

• hány cég vagy ügyfél szerepel a folyamatban;
• hány bejövő és kimenő számla van havonta;
• kell-e tételszintű ÁFA-ellenőrzés;
• van-e több devizanem;
• kell-e ügyfélkód, költséghely vagy főkönyvi előkontírozás;
• ismétlődik-e a folyamat ugyanazzal az oszlopsémával;
• szükséges-e importfájl könyvelőprogramhoz;
• mennyi kézi egyeztetési státuszt kell visszavezetni.

Ha a válaszok többsége alacsony volumenre és egyszerű ellenőrzésre mutat, a kézi Excel is védhető. Ha viszont sok ügyfél, rendszeres havi futás, technikai felhasználóval lekért adat és standard importigény jelenik meg, az API-s vagy könyvelőprogramon belüli megoldás hamar stabilabb lesz.

Bármelyik utat választod, a legfontosabb nem a konverzió pillanata, hanem az állandó adatmodell. Ugyanazok az oszlopok, ugyanaz a dátumformátum, ugyanaz az összeglogika, ugyanazok a hibajelzők és ugyanaz az eltéréskezelés kellenek hónapról hónapra. A jó NAV XML Excel nem egyszeri átalakítás, hanem ismételhető könyvelési munkafolyamat.