NAV Online Számla integrációs ellenőrzőlista

Az ERP- vagy számlázórendszer és a NAV Online Számla közötti gépi kapcsolat nem egyetlen fejlesztési feladat. Ez a lista azt bontja lépésekre, amit egy integráció előtt és közben tisztázni kell — a technikai felhasználótól az élesítés utáni üzemeltetésig. Minden tételnél ott áll, ki felel érte, és miért számít.

A jogszabályi határidők és az interfész műszaki korlátai a lap alján felsorolt NAV-forrásokból származnak. A szakaszokhoz rendelt időzítés a mi ajánlásunk a projekt sorrendjére, nem NAV-előírás. Konkrét ügyben a NAV hatályos dokumentációja az irányadó.

Frissítve: 2026. október 8.

1. NAV-oldali előfeltételek

Gépi adatszolgáltatáshoz technikai felhasználó kell. Ezt az Online Számla webfelületén csak az elsődleges felhasználó — a törvényes képviselő vagy az állandó meghatalmazott — hozhatja létre, és csak ő generálhat hozzá kulcsokat.

Ajánlott: a fejlesztés indítása előtt

  • Tisztázza, ki az elsődleges felhasználó az Online Számla rendszerben, és elérhető-e a projekt idejére. (Felelős: Pénzügy / cégvezetés) — Technikai felhasználót és kulcsokat csak ő hozhat létre. Ha ez a személy nem elérhető, a projekt az első lépésnél megáll.
  • Hozzák létre a technikai felhasználót, és generálják le az XML aláírókulcsot és az XML cserekulcsot. (Felelős: Elsődleges felhasználó) — A technikai felhasználó loginját a rendszer generálja, a jelszót az elsődleges felhasználó adja meg. A kérések aláírásához és a token visszafejtéséhez mindkét kulcs kell.
  • Regisztráljanak a tesztkörnyezetben is, külön technikai felhasználóval és külön kulcsokkal. (Felelős: Elsődleges felhasználó + IT) — A teszt- és az éles környezet egymástól független: az éles hozzáférés a tesztben nem működik, és fordítva.
  • Döntsék el, hol és hogyan tárolják a jelszót és a kulcsokat, és ki férhet hozzájuk. (Felelős: IT-biztonság) — Ezekkel a cég nevében lehet adatot szolgáltatni a NAV-nak. Titokként, az alkalmazás adataitól elkülönítve érdemes kezelni őket.
  • Rögzítsék a kulcscsere folyamatát: ki jelzi, ha az elsődleges felhasználó új kulcsot generál. (Felelős: IT + pénzügy) — Újragenerálás után a régi kulcsokkal a beküldés hibára fut. A NAV a gyakori hibák között külön említi ezt az esetet.

2. Forrásadat és 3.0 XML-megfeleltetés

A NAV az Online Számla 3.0 XML-sémája szerinti adatot vár. A legtöbb utólagos hiba abból ered, hogy a forrásrendszer adatai nem egyértelműen feleltethetők meg a séma mezőinek.

Ajánlott: a fejlesztés első szakaszában

  • Készüljön mezőszintű megfeleltetés a forrásrendszer számlaadatai és a 3.0 XML mezői között. (Felelős: ERP-felelős + adóterület) — Ez lesz a fejlesztés és a tesztelés közös alapja. Nélküle minden validációs hibánál újra kell vitatni, honnan jön az adat.
  • Gyűjtse össze, milyen számlatípusok fordulnak elő: belföldi, külföldi vevős, magánszemély vevős, devizás, gyűjtőszámla, előleg, áfacsoport tagjaként vagy jogutódként kiállított. (Felelős: Számlázás / könyvelés) — 2021 óta nincs értékhatár: a magánszemélynek és a külföldi vevőnek kiállított számla is jelentendő, magánszemély neve és címe nélkül. 2026-tól az áfacsoport tagjának és a jogelődnek az adószámáról is adatot kell szolgáltatni.
  • Feleltesse meg a belső áfakódokat az XML áfamezőinek, a mentességek és az egyéb jogcímek indoklásával együtt. (Felelős: Adóterület) — Az áfakulcs, a mentesség és a fordított adózás jelölése a leggyakoribb üzleti validációs hibaforrások közé tartozik.
  • Írja le, hogyan kezeli a rendszer a módosító és sztornó számlákat: alapszámla-hivatkozás, modificationIndex, modifyWithoutMaster. (Felelős: ERP-felelős) — A modificationIndex a láncon belül egyedi kell legyen. A modifyWithoutMaster értékének egyeznie kell azzal, hogy létezik-e alapadatszolgáltatás. A sztornó lezárja a láncot.
  • Ellenőrizze a számlaszámok formátumát, beleértve a módosító számlákban hivatkozott eredeti számlaszámokat. (Felelős: ERP-felelős) — 2026. január 1-től ERROR (79-es üzenet), ha az eredeti számlaszámban whitespace szerepel.

3. Validációk és hibakezelés

A NAV a beküldött adatot séma- és üzleti szabályok szerint ellenőrzi. Az ERROR elutasítást jelent, a WARN nem — de a NAV az utóbbi években több WARN-t ERROR-rá szigorított.

Ajánlott: a fejlesztéssel párhuzamosan

  • Ellenőrizze, hogy a rendszer a beküldés előtt saját maga is lefuttatja a 3.0 séma szerinti ellenőrzést. (Felelős: IT) — A sémahibás kérést a NAV elutasítja. Helyben olcsóbb elkapni, mint a NAV válaszából visszafejteni.
  • Vesse össze a hatályos validációs üzenetlistát a saját számlatípusaival, és jelölje meg, mely ERROR-ok fordulhatnak elő. (Felelős: IT + adóterület) — A NAV az interfészspecifikációban és a GitHub-tárházában közli az üzeneteket. A lista nem állandó: 2025 szeptemberében 15, 2026 januárjában további WARN-üzenet vált elutasító ERROR-rá.
  • Készüljön fel a már bejelentett szigorításokra: az áfacsoport-tag adószámára (60) és a sztornózott teljesítési dátumra (11401) vonatkozó szabályokra. (Felelős: IT + adóterület) — A 60-as üzenet a tesztkörnyezetben 2026. január 1. óta ERROR, és a NAV átmeneti idő után élesben is az lesz. A 11401-es WARN-t a NAV előre jelezte, hogy ERROR-rá szigorítja.
  • Nézze meg a korábbi beküldések WARN-üzeneteit, és döntse el, melyiket javítják a forrásadatban. (Felelős: Adóterület) — A WARN-os számla is teljesíti az adatszolgáltatást, de a mostani WARN a következő szigorításnál ERROR lehet.
  • Rögzítse, ki kapja meg és ki javítja az elutasított (ABORTED) számlákat, és milyen határidővel. (Felelős: Pénzügy + IT) — Elutasításnál a hiba elhárítása után meg kell ismételni az adatszolgáltatást. Ha ez 3 munkanapon belül nem sikerül, kézi rögzítés kötelező.
  • Döntse el, használják-e a technikai érvénytelenítést, és ki hagyja jóvá a webfelületen. (Felelős: Pénzügy) — Csak technikai hibára való, üzleti tartalom javítására nem — arra módosító vagy sztornó számla kell. Az érvénytelenítést az elsődleges felhasználónak jóvá kell hagynia.

4. Beküldés, határidők és státuszkövetés

A számlázóprogrammal kiállított számla adatait a kiállításkor azonnal kell továbbítani. A kötelezettség akkor teljesül, ha a NAV a feldolgozást sikeresnek igazolja vissza.

Ajánlott: a fejlesztés második szakaszában

  • Ellenőrizze, hogy a beküldés a kiállításhoz kötött, automatikus lépés, nem utólagos kézi művelet. (Felelős: IT) — A 23/2014. NGM rendelet 13/A. §-a szerint az adatszolgáltatás a számla kiállításakor azonnal esedékes.
  • Építsék be a tranzakcióstátusz lekérdezését, és a számlát csak DONE státusznál tekintsék teljesítettnek. (Felelős: IT) — A sikeres HTTP-válasz csak a befogadást jelenti. A teljesítést a NAV feldolgozási eredménye (DONE) igazolja; ABORTED esetén újra kell küldeni.
  • Tervezzék meg a NAV-kimaradás és a saját oldali hiba kezelését, a jogszabályi 24 és 48 órás határidőkkel. (Felelős: IT + pénzügy) — NAV-oldali elérhetetlenségnél a megszűnést követő 24 órán belül kell beküldeni. Saját oldali hibánál 48 óra után be kell jelenteni a hibát a NAV felületén, és kézi rögzítésre kell váltani.
  • Kezelje a rendszer az időtúllépést úgy, hogy ne küldjön duplán. (Felelős: IT) — NAV-oldali timeout után a mentés még percekig tarthat. Azonnali újraküldés helyett előbb a tranzakciólistát és a státuszt kell lekérdezni.
  • Ellenőrizze a kötegelést és a forgalomkorlátot: legfeljebb 100 számla kérésenként, IP-címenként másodpercenként 1 kérés. (Felelős: IT) — A korlát feletti kérések késleltetést kapnak, 60 másodperc várakozás után pedig a NAV eldobja őket. Nagy volumennél ez könnyen határidő-csúszást okoz.

5. Tesztelés és élesítés

A NAV tesztkörnyezetében rögzített adatok nem jelennek meg a NAV nyilvántartásában, ezért élesítés előtt ott érdemes végigpróbálni minden számlatípust.

Ajánlott: élesítés előtt legalább 2–4 héttel

  • Készüljön tesztkészlet a 2. szakaszban összegyűjtött összes számlatípusra, módosító és sztornó számlával együtt. (Felelős: Számlázás + IT) — A ritka esetek — devizás módosítás, külföldi vevő, gyűjtőszámla — szoktak élesben először hibát dobni.
  • Futtassák végig a tesztkészletet a tesztkörnyezetben, és dokumentálják a NAV válaszait. (Felelős: IT) — Ugyanazokkal a validációkkal találkoznak, mint élesben, következmény nélkül. A tesztkörnyezet rendelkezésre állása viszont nem garantált, ezért legyen tartalékidő.
  • Próbálják ki a hibautakat is: elutasított számla javítása, időtúllépés, kulcscsere. (Felelős: IT) — A sikeres beküldést mindenki teszteli. Az élesben jelentkező gondok jellemzően a hibakezelésből jönnek.
  • Rögzítsék az élesítés napját, a felelőst és a visszaállási tervet. (Felelős: Projektvezetés) — Élesítés után az adatszolgáltatás azonnal jogi kötelezettség. Ha a gépi út megáll, tudni kell, ki és hogyan rögzít kézzel.

6. Üzemeltetés és audit

Élesítés után a feladat a folyamatos kontroll: minden számlánál tudni kell, hogy eljutott-e a NAV-hoz, és mi lett az eredménye.

Ajánlott: élesítéskor bevezetni

  • Legyen napi áttekintés a beküldött, a feldolgozás alatt álló, a WARN-os és az elutasított számlákról. (Felelős: Pénzügy) — Az elutasított számlát határidőn belül újra kell küldeni. Ehhez valakinek észre is kell vennie.
  • Őrizzék meg minden beküldés kérését, a tranzakcióazonosítót és a NAV válaszát. (Felelős: IT) — Egy NAV-vizsgálatnál ezzel bizonyítható, mi ment be, mikor, és mit válaszolt rá a NAV.
  • Egyeztessék időszakonként a saját számlaadatokat a NAV-nál nyilvántartottakkal. (Felelős: Könyvelés) — A NAV-ból lekérdezhető, mi szerepel a nyilvántartásban. Az eltérések így még az áfabevallás előtt kiderülnek.
  • Kövesse valaki a NAV Online Számla közleményeit és a validációs változásokat. (Felelős: IT + adóterület) — A NAV a szigorításokat jellemzően néhány hónappal korábban jelenti be, és előbb a tesztkörnyezetben vezeti be.
  • Tudatosítsák a mulasztás kockázatát a felelősökben. (Felelős: Cégvezetés) — Az elmaradt vagy hibás adatszolgáltatás az Art. 220. és 229. §-a alapján nem természetes személy adózónál számlánként akár 1 millió forintig terjedő mulasztási bírsággal sújtható.

Források

Kapcsolódó