Elektronikus számla formai követelményei: mi számít hibának?

Egy elektronikus számlánál a „hiba” nem mindig azt jelenti, hogy rossz az összeg vagy téves az áfakulcs. Sokszor formai eltérés az, ami miatt a vevő rendszere elutasítja a számlát, a NAV-validáció megakad, vagy egy belső auditnál nem lesz bizonyítható a folyamat (ki állította ki, mikor, milyen tartalommal, és változott-e utólag).

Ebben a cikkben a formai követelmények szemszögéből nézzük meg, mi számít hibának 2026-ban, hogyan érdemes osztályozni a hibákat (blokkoló vs. javítható), és milyen gyors lépésekkel lehet stabilizálni a kiállítási és befogadási folyamatot.

Mit jelent a „formai követelmény” elektronikus számlánál?

A gyakorlatban a formai követelmény azt jelenti, hogy a számla:

• tartalmazza a jogszabályok által elvárt minimális adattartalmat (számlaazonosítók, felek adatai, tételek, adó adatok, összegek stb.),

• olvasható és értelmezhető marad a megőrzési idő alatt,

• bizonyítható az eredete (hitelessége) és az, hogy nem módosult (adattartalom sértetlensége),

• a választott elektronikus formátum (például strukturált XML) technikai és üzleti validációkon átmegy.

Ezek a követelmények részben adózási és számviteli elvárásokból, részben pedig az e-számla technikai szabványosodásából fakadnak (például az EN 16931 strukturált e-számla irányból). Magyarországon a NAV Online Számla adatszolgáltatás és az e-számlázási gyakorlat együttese miatt a „formai hiba” gyakran technikai elutasításként jelentkezik.

Kapcsolódó háttéranyagok a Syneo oldalán:

• Hogyan vezess be elektronikus számlázást? Kezdők gyakorlati útmutatója

• Elektronikus számla jogszabályok 2026-ban: rövid összefoglaló

A leggyakoribb formai hibák: 4 „hiba-réteg”, ahol elcsúszik a számla

Elektronikus számláknál érdemes a hibákat négy rétegben vizsgálni, mert mindegyik máshol derül ki, és máshogy javítható.

1) Kötelező adattartalom hiánya vagy hibás kitöltése

Ez a klasszikus „számlatartalmi minimum” réteg. Tipikus formai hibák:

• Hiányzó vagy nem egyedi számlasorszám (duplikáció, rossz számtartomány, újrainduló sorszámozás kontroll nélkül).

• Kiállítás dátuma hiányzik, vagy olyan formátumú, amit a fogadó rendszer nem tud feldolgozni.

• Eladó adatai hiányosak (név, cím, adószám), vagy az adószám formailag hibás.

• Vevő adatai hiányosak, különösen B2B folyamatokban, ahol automatikus könyvelés és partner-törzs illesztés történik.

• Teljesítés időpontja (ha releváns) hiányzik vagy ellentmondásos.

• Tételek leírása túl általános („szolgáltatás”, „termék”), és a belső befogadási szabályok miatt nem könyvelhető.

Fontos: ezek egy része jogszabályi minimum, más része pedig „vállalati formai minimum” (például költséghely, PO-szám, szerződésszám). Utóbbi nem feltétlen jogszabályi kérdés, de ugyanúgy elutasításhoz vezethet, ha a vevő AP-folyamata ezt blokkolja.

2) Matematikai és logikai inkonzisztenciák (formailag „van mező”, csak nem stimmel)

Ezek a hibák különösen gyakoriak integrációknál (ERP → számlázó → NAV → vevő). Tipikus minták:

• Tételsorok nettó/bruttó/áfa összegei nem adják ki a végösszeget (kerekítés, devizaárfolyam, több áfakulcs kezelése).

• Áfakulcs és adóösszeg ellentmondása (például 0% kulcs, de mégis van adóösszeg).

• Negatív mennyiség vagy egységár olyan bizonylaton, ahol a fogadó fél ezt nem támogatja (helyesbítő logikát várna).

• Devizanem és árfolyam mezők hiányoznak vagy nem konzisztens a számítás.

Ezek sokszor nem „tartalmi vita”, hanem formai feldolgozhatósági hiba: a fogadó rendszer nem tudja megbízhatóan automatikusan könyvelni.

3) Formátum és validációs hibák (XSD, séma, mező-hossz, kódkészletek)

Strukturált e-számláknál (például EN 16931 kompatibilis XML) a hibák egy része tisztán technikai:

• kötelező mező hiányzik a sémához képest,

• rossz a dátum formátuma,

• túl hosszú a mező,

• rossz kódkészletet használsz (például mértékegység, országkód).

Ilyenkor tipikusan az történik, hogy a számla már a validációs kapun elhasal, és nem jut tovább.

Fejlesztői nézőpontból hasznos kiegészítés:

• Elektronikus számla XML formátum: mezők, validáció, EN 16931

4) Bizonyíthatósági és archiválási formai hibák (auditállóság)

Még ha a számla „átmegy” a rendszereken, egy auditnál elbukhat, ha nem tudod bizonyítani:

• mikor állítottad ki,

• hogyan kézbesítetted,

• hogy az állomány nem módosult,

• hogy a megőrzés alatt végig olvasható és visszakereshető maradt.

Ez a réteg nem mindig azonnali elutasítás, viszont komoly kockázat lehet (belső kontroll, partner-audit, adóellenőrzés). A témához kapcsolódik:

• E-számla 2026: ellenőrzőlista kiállításhoz és archiváláshoz

• Elektronikus számla digitális aláírás: kell-e 2026-ban?

Mi számít „blokkoló hibának”, és mi „javítható eltérésnek”?

A legnagyobb működési különbséget az adja, hogy a hiba:

• blokkoló: a számlát nem lehet befogadni, feldolgozni vagy beküldeni (például sémahiba, hiányzó kötelező mező, duplikált sorszám),

• javítható, de kockázatos: átmegy, de később vitát, manuális munkát vagy auditkérdést okoz (például hiányzó PO-szám, túl általános tételmegnevezés, hiányos kézbesítési bizonyíték),

• figyelmeztetés (warning): nem akad meg a folyamat, de trendként rombolja az automatizációt (például nem egységes mértékegységek, vegyes kerekítési szabályok).

A jó hír: ezt a logikát le lehet képezni egy egyszerű szabálykészletre, és automatán mérni (hibaarány, top hibák, partnerenkénti elutasítás).

Gyakori formai hibák és a helyes reakció (gyors táblázat)

Az alábbi táblázat nem jogi állásfoglalás, hanem egy bevált, operatív szemlélet: mit tekints „azonnal javítandónak”, és mit kezelsz kivételként.

„Találtunk egy hibás e-számlát” – mit tegyünk valójában?

A leggyakoribb hiba, hogy ilyenkor a csapat megpróbálja „utólag átírni” a fájlt vagy újraküldeni ugyanazzal az azonosítóval. Ez rövid távon csábító, hosszú távon viszont komoly auditkockázat.

Egy működő, auditbarát döntési fa inkább így néz ki:

1) Hol bukott el a folyamat?

• Kiállítás előtt (belső validáció): ideális eset, itt javíts.

• NAV-adatszolgáltatásnál / technikai kapun: jellemzően formátum vagy kötelező mező hiba.

• Vevőnél befogadáskor: gyakran vállalati formai minimum hiányzik (PO-szám, költséghely) vagy partner-törzs eltérés.

• Archiválásnál / auditnál: bizonyíthatósági hiányosság.

2) Szükséges-e helyesbítő vagy sztornó?

Ha a számla már kibocsátott bizonylatként él a folyamatban, a „javítás” tipikusan helyesbítő/sztornó irány. Ennek pontos módja vállalati és könyvelési kontextusfüggő, ezért érdemes könyvelővel és adótanácsadóval egyeztetni.

3) A hiba egyszeri, vagy rendszerszintű?

• Egyszeri: partner-törzs adat probléma, ritka kivétel.

• Rendszerszintű: kerekítés, áfa logika, számlaszám ütközés, XML verzióváltás. Itt gyors stabilizáció kell.

Ehhez gyakorlati segítség:

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

Megelőzés: a 6 kontroll, ami a formai hibák 80 százalékát eltünteti

Nem kell azonnal „nagy programot” indítani. A legtöbb szervezetnél néhány célzott kontroll hoz gyors eredményt.

Kötelező mezők és törzsadatok „kapuzása”

A számlakiállítás előtt legyen egy minimum ellenőrzés: vevő/eladó törzsadatok, adószám formátum, cím, deviza, fizetési feltételek.

XSD és üzleti validáció két külön lépésként

• XSD/séma: „technikai érvényesség”.

• Üzleti szabályok: összegek, áfa logika, dátumok, kerekítés.

E kettőt érdemes külön mérni, mert más csapat javítja (IT vs pénzügy).

Sorszámozás és idempotencia integrációban

A duplikált sorszám és a duplikált beküldés tipikus „rejtett” hiba. Integrációban alapelv, hogy ugyanazt az eseményt ne lehessen véletlenül kétszer könyvelni vagy beküldeni.

Kézbesítési státuszok és naplózás

Legyen visszakövethető:

• mikor generáltad,

• mikor küldted,

• a vevő átvette-e,

• volt-e elutasítás, és mi volt a hibakód.

Archiválás: visszakereshetőség és hozzáférés

Az archiválás nem csak „tárhely”. Kérdés, hogy 3-5-8 év múlva is:

• megtalálod-e,

• bizonyítható-e, hogy nem módosult,

• jogosultak-e csak azok férnek hozzá, akiknek kell.

Mérőszámok: hibaráták és top hibák

Ha nincs metrika, csak „érzés” van. Már egy egyszerű dashboard is elég:

• elutasítási arány partnerenként,

• top 10 hiba ok,

• átlagos javítási idő,

• manuális beavatkozással érintett számlák aránya.

Külső hivatkozások (szabvány és hatósági háttér)

Ha mélyebben szeretnéd ellenőrizni a keretrendszert és a terminológiát:

• NAV Online Számla portál és dokumentációk: NAV Online Számla

• eIDAS rendelet (elektronikus azonosítás és bizalmi szolgáltatások): EUR-Lex 910/2014

Gyakran Ismételt Kérdések (FAQ)

Mi a különbség a formai és a tartalmi hiba között e-számlánál? A formai hiba tipikusan a kötelező adatok, a technikai formátum vagy a feldolgozhatóság hibája (hiányzó mező, sémahiba, inkonzisztens összegek). A tartalmi hiba inkább üzleti vagy adózási tévedés (például rossz termék, rossz teljesítés, rossz adókezelés). A kettő a gyakorlatban sokszor összefolyik, mert egy „tartalmi” tévedés formailag is inkonzisztenciát okozhat.

Ha a vevő elutasítja az e-számlát formai hibára hivatkozva, akkor az „érvénytelen”? Nem automatikusan. A vevői elutasítás gyakran feldolgozási szabály (például hiányzó PO-szám). Viszont ha kötelező adattartalom hiányzik, vagy a számla azonosítói problémásak, az valódi megfelelési kockázat is lehet. Ilyenkor érdemes gyorsan tisztázni: jogszabályi minimum hibáról van szó, vagy vállalati befogadási szabályról.

Mi számít a leggyakoribb blokkoló hibának 2026-ban? A legtöbb szervezetnél a top 3: hiányzó/hibás partner-törzsadat (különösen adószám és cím), összegek és kerekítések inkonzisztenciája, illetve XML/séma validációs hibák (verzióváltás vagy rossz mezőformátum).

Javíthatom utólag a már kiállított elektronikus számla fájlt? Audit és bizonyíthatósági szempontból ez kockázatos. Általában a helyes megoldás valamilyen szabályos helyesbítő/sztornó folyamat, illetve a hibát okozó adat vagy rendszerbeállítás javítása. A konkrét lépést érdemes könyvelővel egyeztetni.

Hogyan derül ki gyorsan, hogy a hiba adat, formátum vagy folyamat? A leghatékonyabb a „4 réteg” szerinti triage: kötelező adattartalom, logikai konzisztencia, technikai validáció (XSD), archiválási bizonyíték. Ha ehhez van logolás és hibakód-gyűjtés, 15 perc alatt besorolható a legtöbb eset.

Stabil e-számlázás kevesebb elutasítással: Syneo támogatás

Ha rendszeresen kapsz vevői elutasításokat, NAV hibákat, vagy az archiválás auditálhatósága kérdéses, érdemes egy rövid, célzott felméréssel kezdeni.

A Syneo csapata e-számlázási projektekben folyamat, integráció és információbiztonsági szemmel segít: hibák gyors triage-a, validációs szabályok kialakítása, monitoring és archiválási minimumok rendbetétele.

Továbblépés: nézd meg a szolgáltatásainkat a Syneo oldalon, vagy olvasd el az E-számlázás 2026 útmutatót a felkészüléshez.