NAV e-számla: gyakori hibák és gyors megoldások cégeknek

A NAV e-számla (és a NAV Online Számla adatszolgáltatás) tipikusan akkor „fáj” a legjobban, amikor már élesben számlázol, a pénzügy várja a kimenő számlákat, a vevő reklamál, miközben a rendszer csak annyit mond: sikertelen beküldés. A jó hír, hogy a hibák nagy része néhány visszatérő okra vezethető vissza, és ezekhez létezik gyors, gyakorlatban működő javítási minta.

Ez a cikk cégeknek szól, akik már használnak (vagy épp bevezetnek) e-számlát és NAV-kapcsolatot, és gyors hibakeresési, javítási és megelőzési megközelítést keresnek. (Jogértelmezésnél és adózási kérdésnél mindig egyeztess könyvelővel vagy adótanácsadóval.)

Mi romlik el leggyakrabban a NAV e-számlánál?

A legtöbb probléma nem „a NAV hibája”, hanem három réteg valamelyikének félrecsúszása:

• Adat réteg: törzsadatok (vevő, adószám, cím), termék/áfa logika, deviza, dátumok, kerekítés, számlalánc (módosító, stornó).

• Formátum és validáció réteg: XML szerkezet, kötelező mezők, típusok, XSD kompatibilitás, karakterkódolás.

• Integráció és üzemeltetés réteg: technikai felhasználó, tokenek, jogosultságok, hálózati problémák, időzítések, újrapróbálkozás (retry), idempotencia, naplózás.

Ha ezt a három réteget szétválasztod a hibakeresésben, a hibaelhárítás ideje jellemzően percekre vagy 1-2 órára csökken, nem napokra.

15 perces „triage” hibakeresés (mielőtt bármit átírsz)

Mielőtt fejlesztői módba váltasz, csinálj egy gyors, következetes triage kört:

1) A hiba reprodukálható vagy időszakos?

• Ha időszakos (néha jó, néha rossz), gyanús: hálózat, NAV elérhetőség, rate limit, timeout, retry hiánya.

• Ha mindig ugyanarra a számlára rossz, gyanús: adat vagy XML.

2) Hol bukik el? Kiállítás, beküldés, státusz visszaolvasás?

Definiáld pontosan a „bukás pontját”:

• A számlázó nem generál XML-t.

• Van XML, de a beküldés sikertelen.

• A beküldés sikeres, de a feldolgozási státusz hibás.

• Feldolgozás oké, de vevő oldali e-számla befogadás vagy archiválás csúszik el.

3) Van-e meg a minimum bizonyíték a hibához?

Legalább ez legyen kéznél:

• számla azonosító (belső ID, számlaszám)

• küldött XML pontos verziója

• beküldési időpont (időzóna is)

• NAV válasz (requestId, tranzakció azonosító, hibaüzenet)

• alkalmazás log (HTTP státusz, timeout, retry)

Ha ezek nincsenek meg, első lépés a naplózás rendbetétele, különben vakon fogsz javítani.

Gyakori NAV e-számla hibák és gyors megoldások (gyakorlatban)

Az alábbi példák szándékosan „mintázatok”, nem konkrét hibakódok listája, mert a pontos üzenetek verzió és integráció szerint eltérhetnek. A logika viszont stabil.

1) „Schema validation” jellegű hibák (XSD, kötelező mező hiány)

Jelenség: a NAV már az első validáción elutasítja a beküldést, gyakran azonnali hibával.

Tipikus okok:

• kötelező mező hiányzik (például partner adat, cím részlete, mennyiségi egység)

• rossz adattípus (szám helyett szöveg, túl sok tizedes)

• nem kompatibilis XML struktúra a használt XSD-hez

Gyors megoldás:

• futtasd az XML-t XSD validáción (fejlesztői pipeline-ban is)

• ellenőrizd, hogy a számlázó által használt séma verzió illeszkedik-e a NAV-hoz

• állíts be „fail fast” szabályt: a számla ki se menjen, ha az XML nem valid

Megelőzés: verziózott XSD tesztek a CI-ben és automatikus regresszió teszt, amikor számlázó/ERP frissül.

2) Hibás vagy hiányos vevő adatok (különösen adószám)

Jelenség: a számla elkészül, de a NAV validáció vagy üzleti ellenőrzés elutasítja.

Tipikus okok:

• elgépelés a vevő adószámában

• régi partner törzsadat (változott cégadatok)

• rosszul kezelt országkód, közösségi adószám (EU)

Gyors megoldás:

• egyetlen forrás (system of record) kijelölése partner adatokra

• törzsadat egyeztetés az ERP és a számlázó között

Megelőzés: törzsadat-szabályok (validáció a mentésnél) és rendszeres partner adattisztítás.

3) Dátumok logikai hibái (teljesítés, kiállítás, fizetési határidő)

Jelenség: „üzleti logika” jellegű elutasítás, vagy a vevő nem fogadja be az e-számlát, mert ellentmondásos.

Tipikus okok:

• teljesítés dátuma későbbi vagy korábbi, mint amit a folyamat enged

• időzóna eltérés miatt a nap „átcsúszik” (különösen éjfél körül, API-k integrációjánál)

Gyors megoldás:

• egységes időkezelés (UTC vagy helyi idő, de következetesen)

• szabályok beépítése a számlagenerálásba (ne csak beküldéskor derüljön ki)

Megelőzés: automata tesztesetek „határidős” és „hóvégi” dátumokra.

4) Kerekítés és összegek eltérése (sorok, áfa, végösszeg)

Jelenség: a NAV vagy a vevői feldolgozás azt érzékeli, hogy az összegmezők nem stimmelnek.

Tipikus okok:

• soronkénti vs összesített kerekítés keverése

• túl sok tizedes (mennyiség vagy egységár)

• deviza és árfolyam kezelés következetlensége

Gyors megoldás:

• rögzíts egy kerekítési policy-t (például soronként kerekítünk, majd összegzünk)

• egyeztesd a policy-t a könyveléssel (különösen áfa összegzésnél)

Megelőzés: „számla matematikai ellenőrző” modul a számlázó előtt.

5) Áfa logika félrecsúszása (mentesség, fordított adózás, 0%)

Jelenség: a rendszer elküldi a számlát, de az üzleti validáció vagy vevői rendszer megakad.

Tipikus okok:

• 0% áfa okának hiánya vagy rossz kódolása

• fordított adózás esetén hiányzó hivatkozás vagy rossz jelölés

Gyors megoldás:

• a termék/szolgáltatás törzsben legyen egyértelmű áfa-szabály

• a kivételek (mentesség, fordított) legyenek külön „esetként” kezelve, ne ad hoc kézzel

Megelőzés: pénzügyi kontroll lista a ritka áfa-esetekhez és mintaszámlák tesztelése.

6) Duplikált számlaszám vagy ütköző sorszámozás

Jelenség: ugyanazzal a számlaszámmal több beküldés, elutasítás vagy zavar a vevőnél.

Tipikus okok:

• párhuzamos számlagenerálás több telephelyen

• rosszul kezelt „újraküldés” (retry) duplikál

Gyors megoldás:

• központi sorszámtartomány kezelés

• idempotens beküldés: ugyanaz a belső azonosító ne generáljon új számlaszámot

Megelőzés: sorszámozás governance és integrációs terhelés teszt.

7) Módosító vagy stornó számlalánc hibái

Jelenség: a beküldés vagy a feldolgozás elbukik, mert a hivatkozott eredeti számla nem illeszkedik.

Tipikus okok:

• hibás hivatkozás az eredeti számlára

• a módosítás logikája (tétel szint, összeg szint) nincs egységesítve

Gyors megoldás:

• implementálj számlalánc ellenőrzést: „létezik-e az alap számla”, „státusza rendben van-e”, „nem módosítottuk-e már ugyanazzal a logikával”

Megelőzés: számlalánc „state machine” szemlélet és auditálható napló.

8) Technikai felhasználó, token, jogosultság problémák

Jelenség: hitelesítési hiba, jogosultság hiány, beküldés nem megy, státusz lekérdezés nem működik.

Tipikus okok:

• lejárt, visszavont, hibásan tárolt kulcsok

• rossz környezet (teszt vs éles) kulcsainak keverése

• túl széles vagy túl szűk jogosultságok

Gyors megoldás:

• szétválasztott credstore (külön teszt és éles)

• kulcsrotáció és dokumentált hozzáférés-kezelés

Megelőzés: hozzáférés-kezelési minimumok bevezetése, ehhez jó kiinduló a Syneo útmutatója az e-számla belépésről és hozzáférés-kezelésről.

9) Timeout, NAV elérhetőség, újrapróbálkozás hiánya

Jelenség: „néha működik, néha nem”, csúcsidőben több a hiba.

Tipikus okok:

• túl rövid timeout beállítás

• nincs exponenciális backoff retry

• nincs queue, minden valós időben megy

Gyors megoldás:

• vezess be aszinkron beküldést sorral (queue)

• állíts be retry szabályokat (limit, backoff, dead letter queue)

Megelőzés: monitorozás, hibaarány riasztás, és „degradált mód” (számla kiáll, beküldés késleltetett, de kontrollált).

10) „Sikeres beküldés”, de rossz státusz kezelés (félkész folyamat)

Jelenség: a beküldésre kapsz választ, de később derül ki, hogy feldolgozási hiba van, vagy a folyamat „függőben ragad”.

Tipikus okok:

• a rendszer nem kérdez vissza státuszt

• nincs SLA arra, hogy meddig lehet függő

• nincs kivételkezelési workflow

Gyors megoldás:

• automatizált státusz polling vagy webhook jellegű feldolgozás (ha az architektúra támogatja)

• napi (vagy órás) „reconciliation” riport: mi függő, mi hibás

Megelőzés: pénzügy és IT közös kivételkezelési folyamat (ki mit csinál, mennyi időn belül).

Gyors áttekintő táblázat: jelenség -> ok -> javítás

„Operációs minimum”: mit érdemes mérni és naplózni NAV e-számlánál?

A NAV e-számla nem csak fejlesztés, üzemeltetés is. Ha nincs meg a minimum observability, a hibaelhárítás drága lesz.

Ha a cégednél DevOps szemléletben gondolkodtok, ezek a metrikák jól illeszkednek egy általános monitorozási keretbe is (erről bővebben: DevOps alapok 2026-ban).

Mikor érdemes „rendszerszintű” javításban gondolkodni, nem tűzoltásban?

Vannak jelek, amikor már nem egy-egy hibát kell javítani, hanem a teljes e-számla folyamatot stabilizálni:

• Hetente visszatér ugyanaz a hibacsoport (például kerekítés, áfa kivételek).

• Több rendszer érintett (ERP, CRM, számlázó, DMS), és a felelősség „szétfolyik”.

• Nincs megbízható reconciliation, ezért a pénzügy csak manuálisan tudja ellenőrizni.

• Új szabvány vagy verzióváltás közeleg, és nincs tesztcsomag.

Ilyenkor sokat segít egy rövid felmérés, integrációs térkép és felelősségi mátrix. Ha több rendszer között mozog az adat, érdemes megnézni a rendszerintegrációról szóló útmutatót is.

A szabályozási oldal áttekintéséhez hasznos háttér lehet az e-számlázás 2026 összefoglaló, a gyakorlati kiállítási és archiválási „higiénéhez” pedig az E-számla 2026 ellenőrzőlista.

Külső forrásként a hivatalos követelményekhez és frissítésekhez mindig a NAV Online Számla tájékoztatók és dokumentáció oldalait érdemes alapnak tekinteni.

Gyakran ismételt kérdések (FAQ)

Mi a különbség a NAV e-számla és a NAV Online Számla adatszolgáltatás között? A gyakorlatban a cégek sokszor egyben kezelik, de eltérhet a „számla elektronikus jellege” (befogadás, archiválás) és az adatszolgáltatás technikai folyamata. Ha hibát keresel, mindig tisztázd, melyik réteg bukik: kiállítás, beküldés, státusz, befogadás.

Mit csináljak, ha időszakosan hibás a beküldés, de ugyanaz az XML néha átmegy? Ilyenkor jellemzően nem adat- vagy XSD hiba van, hanem timeout, átmeneti elérhetőség, rate limit, vagy retry hiány. Az aszinkron beküldés queue-val és kontrollált retry-val általában gyorsan stabilizál.

Honnan tudom, hogy XSD (schema) hibám van? A hibák gyakran már a beküldéskor, azonnal jelentkeznek, és tipikusan „kötelező mező”, „érvénytelen struktúra” jellegűek. Az igazi gyors megoldás a lokális XSD validáció a beküldés előtt.

Miért csúsznak el az áfa és kerekítés jellegű hibák rendszeresen? Mert ezek ritkán egyetlen mező hibái, inkább policy kérdések: hogyan kerekítünk, hogyan számolunk soronként, hogyan kezeljük a kivételeket. A megoldás egy közösen elfogadott (pénzügy + IT) szabályrendszer és automata tesztcsomag.

Hogyan kerülhető el a duplikált számlaszám beküldés retry miatt? Idempotens beküldéssel (azonos belső ID azonos kimenetet eredményez), központi sorszámozással, és dead letter queue-val a tartós hibákhoz, hogy ne pörögjön végtelenül a retry.

Mikor érdemes külső szakértőt bevonni a NAV e-számla hibákhoz? Ha a hiba több rendszert érint (ERP, számlázó, integrációs réteg), ha nincs rendes naplózás és reconciliation, vagy ha a javítások visszatérően ugyanott törnek meg. Ilyenkor egy rövid audit és stabilizációs terv gyorsabb és olcsóbb, mint a folyamatos tűzoltás.

Következő lépés: gyors stabilizáció vagy megelőző audit

Ha a NAV e-számla hibák miatt rendszeresen megáll a számlázás, vagy szeretnéd megelőzni a verzióváltásokkal járó kellemetlen meglepetéseket, érdemes a problémát nem csak „egy hibaként”, hanem folyamatként és integrációként kezelni.

A Syneo csapata IT tanácsadásban, rendszerintegrációban és egyedi fejlesztésben is támogat, a cél pedig az, hogy a NAV beküldés mérhetően stabil legyen (naplózás, retry, reconciliation, jogosultságok), ne egyéni hősökön múljon.

További háttérhez nézd meg az IT tanácsadásról szóló összefoglalót, vagy indulj a Syneo oldaláról a kapcsolatfelvételhez.