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

A strukturált e-számlázásnál a PDF már legfeljebb „emberi olvasóra” jó kísérő, a gépek és a partnerek rendszerei XML-ben keresik a számla lényegét. Ha a mezők nem stimmelnek, a validáció elbukik, ha a validáció nincs rendben, a feldolgozás megáll (vagy ami rosszabb, csendben hibásan könyvelődik). 2026-ban, az EN 16931 körüli elvárások erősödésével ez egyre kevésbé „informatikai részletkérdés”, sokkal inkább pénzügyi és compliance kockázat.

Ez a cikk azt adja kézbe, amire egy pénzügyet támogató IT csapatnak és egy implementációt vezető projektgazdának tényleg szüksége van: melyek a tipikus mezőcsoportok az elektronikus számla XML formátumában, hogyan néz ki a validáció több rétege, és mit jelent mindez az EN 16931 (európai e-számla szabvány) szempontjából.

Mit jelent az „e-számla XML”, és mi köze az EN 16931-hez?

Az „elektronikus számla XML formátum” a gyakorlatban nem egyetlen fájlstruktúrát jelent.

• Az EN 16931 egy európai szabvány, ami elsősorban a számla szemantikai adattartalmát írja le (milyen adatelemek, milyen logikával, milyen összefüggésekkel).

• Ezt a szemantikai modellt többféle szintaxissal lehet „leönteni” XML-re, a leggyakoribbak:UBL (gyakran használják B2B integrációkban, a PEPPOL is erre épít),UN/CEFACT CII (szintén elterjedt európai környezetben).

Emellett Magyarországon külön világ a NAV Online Számla adatszolgáltatás XML-e, ami sok esetben integrációs szempontból együtt él az e-számlázással. A két XML célja eltérhet, ezért a mezők megfeleltetését nem érdemes „egy az egyben” feltételezni.

Hiteles kiindulópontok:

• Európai Bizottság eInvoicing háttéranyagok (EN 16931): European Commission eInvoicing

• PEPPOL BIS Billing specifikáció és validációs anyagok: PEPPOL BIS Billing

• NAV Online Számla technikai dokumentáció: NAV Online Számla

A számla XML tipikus felépítése (mezőcsoportok logikája)

Bármelyik szabványos XML-t nézed (UBL vagy CII), a szerkezet üzletileg nagyon hasonló: fejléc, szereplők, sorok, adók, összesítők, fizetés, hivatkozások.

Az alábbi táblázat nem „tag-szótár”, hanem implementációs ellenőrző nézet: melyik adatcsoportnak milyen szerepe van, és hol szokott elcsúszni.

EN 16931 szemléletben: mitől „jó” egy e-számla XML?

Az EN 16931 lényege nem az, hogy „XML legyen”, hanem hogy a számla gépileg feldolgozható, egységes jelentésű adatelemeket tartalmazzon. A gyakorlatban ez három dolgot jelent:

1) Kötelező adatelemek és konzisztencia

A legtöbb elutasítás nem azért történik, mert „hibás az XML”, hanem mert a kötelező adatok hiányoznak vagy ellentmondanak egymásnak (például az áfa bontás nem adja ki az összesítőt).

Gyakorlati tanács: a törzsadatok (partner, cikk, adókód) minősége sokkal többet számít, mint a serializer kód szépsége.

2) Kódlisták és szabványos azonosítók

Az interoperabilitás alapja, hogy mindenki ugyanazt értse ugyanazon érték alatt. Tipikus példák:

• Pénznem: ISO 4217

• Ország: ISO 3166-1

• Mértékegység: gyakran UN/ECE kódlisták

Ha ezeket „szabad szövegként” töltöd, a partneri feldolgozás, a PEPPOL csatornák vagy a validátorok könnyen elkaszálják.

3) CIUS és partner-specifikus szabályok

Sok környezetben az EN 16931 fölött létezik egy szűkítés vagy kiegészítés (CIUS, illetve hálózati profilok). A PEPPOL BIS Billing például ilyen: nem csak a mezőket mondja meg, hanem üzleti szabályokat is.

Következmény: két „EN 16931 kompatibilis” XML közül az egyik átmegy a partnerhez, a másik nem, mert más profilt vár.

Validáció: XSD, Schematron, üzleti kontrollok, és mi mire jó

A „validáció” kifejezést sokan egyetlen lépésnek gondolják. Valójában több réteg van, és mindegyik más hibát fog meg.

Miért nem elég az XSD?

XSD-vel átmehet egy olyan számla, ahol a fejléc bruttó összege nem egyezik a sorok összegével, vagy az áfa bontás hibás. Ezek üzleti szabályok, tipikusan Schematron szinten jelennek meg.

Gyors, mégis auditálható validációs minta

Ha kevés időd van „jól” megcsinálni, akkor is érdemes legalább ezt a minimális rendet tartani:

• Pre-flight: XSD + üzleti szabály validáció minden generált kimenetre.

• Hibakezelés: a validációs hibát tárold (szabálykód, mezőútvonal, számlaazonosító), és legyen belőle riportálható backlog.

• Mintavételezés: a sikeres kimenetekből is ellenőrizz rendszeresen (például új partner, új áfakulcs, új deviza).

Ha NAV adatszolgáltatás is érintett, a gyakorlati hibaelhárítási oldalról hasznos kiegészítés: NAV e-számla: gyakori hibák és gyors megoldások cégeknek.

Kritikus mezők, ahol a legtöbb projekt elbukik (és hogyan előzd meg)

ÁFA bontás és kerekítés

A legtöbb automatikus feldolgozási hiba itt jön elő. Tipikus okok:

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

• Kedvezmény (line allowance) rossz helyen kerül levonásra.

• Több áfakulcsos számlán a bontás nem egyezik az összesítővel.

Javaslat: egyeztesd előre a pénzüggyel a kerekítési szabályt, és írd le tesztesetekben (nem csak „kód szinten”).

Azonosítók: adószámok, partner ID-k, hivatkozások

E-számlánál sok környezetben nem elég a cég neve. Az automatizáció azonosítókat vár:

• adószám / közösségi adószám,

• cégjegyzékszám vagy egyéb regisztrációs azonosító,

• partner-specifikus azonosító (például vevői törzsszám).

Ha ezek törzsadatban hiányosak, az XML hiába „szép”, nem lesz feldolgozható.

Tételsorok: mértékegység, mennyiség, egységár

A tételsor az AP automatizáció és az ERP könyvelési logika alapja. Tipikus hibák:

• A mennyiség és egységár szorzata nem egyezik a sor nettó értékkel (kerekítés, kedvezmény).

• Mértékegység nincs kódlistából, a partner validátora elutasítja.

• Helyesbítésnél/sztornónál negatív tételek kezelése nem konzisztens.

Deviza és árfolyamok

Ha több pénznemű számlázás van:

• tisztázd, milyen pénznemben képződik az áfa és az összesítő,

• legyen egyértelmű, hol jelenik meg az árfolyam és milyen dátumhoz kötődik,

• egyeztesd a könyvelési elvárásokat (különösen export, közösségi ügylet).

Bevezetési döntések: UBL vagy CII, PEPPOL vagy közvetlen integráció?

A jó döntés a partnerkörödön és a compliance kényszereken múlik, nem azon, hogy a fejlesztők melyik XML-t szeretik.

Gyakorlati döntési szempontok

• Partneri elvárás: ha a vevők PEPPOL-on kérik, a BIS profilhoz kell igazodnod.

• Ökoszisztéma: ha a számlázó/ERP eleve egyik szintaxist támogatja stabilan, azt érdemes preferálni, és a megfeleltetést a standardhoz igazítani.

• Validációs eszközök: melyik útra van a csapatnak és a beszállítónak megbízható validator készlete.

A szabályozási kontextushoz és határidőkhöz hasznos háttér: E-számlázás 2026: Amit Minden Vállalkozónak Tudnia Kell az Új Szabályokról.

Tesztelés és átadás: milyen „bizonyítékokat” kérj a beszállítótól?

Ha e-számla XML implementációt veszel át (számlázó, ERP kiegészítő, middleware, iPaaS), akkor nem elég egy „kiküldtünk 3 mintát” típusú átadás. A minimum, ami hosszú távon olcsóbbá teszi az üzemeltetést:

• Mintacsomag: tipikus és szélső esetekkel (több áfakulcs, kedvezmény, deviza, előleg, helyesbítés, fordított adózás, export).

• Validációs riport: XSD és üzleti szabály validáció eredménye minden mintára.

• Mezőtérkép: törzsadat mező → XML mezőcsoport logika (különösen adókódok, mértékegységek, partner ID-k).

• Hibakezelési specifikáció: mi történik elutasításnál, hol látszik a hiba, ki javítja, mi a retry szabály.

• Archiválási és audit nyomvonal: hogyan bizonyítod utólag a sértetlenséget és a hozzáférés kontrollt.

Az archiválás és kiállítás oldalról egy KKV-barát, auditálható lista: E-számla 2026: ellenőrzőlista kiállításhoz és archiváláshoz.

Operáció és stabilitás: az XML csak a kezdet

Sok projekt ott csúszik el, hogy az XML előáll, „átmegy a validátoron”, de az éles folyamat nem stabil.

A minimum operációs elvárások e-számla integrációnál:

• Státuszok (elkészült, validált, elküldve, kézbesítve, elutasítva, újrapróbálva).

• Idempotens küldés (ugyanaz a számla ne menjen ki kétszer egy hálózati hiba miatt).

• Retry/backoff és riasztás (ne ember nézze 0–24-ben a hibákat, de legyen SLA).

• Naplózás és auditálhatóság (ki, mikor, mit küldött, milyen validációs eredménnyel).

Ha a csatorna és a folyamatbiztonság is kérdés, a digitális aláírás szerepét érdemes tisztán látni: Elektronikus számla digitális aláírás: kell-e 2026-ban?.

Hogyan tud segíteni a Syneo, ha az XML-es e-számlázás „beragad”?

Az EN 16931-hez igazodó e-számla XML bevezetés tipikusan több rendszert érint (számlázó, ERP, NAV-adatszolgáltatás, DMS/archívum, bank, EDI/PEPPOL). Ilyenkor a hiba ritkán egyetlen XML tag, inkább adat, integráció és folyamat együttese.

A Syneo ilyen helyzetekben jellemzően ezekben tud támogatni, a konkrét igényhez igazítva:

• követelmények és partneri profilok tisztázása (EN 16931, CIUS, partner-specifikus elvárások),

• mezőtérkép és adatminőségi szabályok kialakítása ERP/számlázó törzsadatokra,

• validációs pipeline megtervezése (XSD + üzleti szabályok + operáció),

• integrációs stabilizáció és monitoring (hibakezelés, idempotencia, státuszmodellek),

• auditálható archiválási és hozzáférés-kezelési minimumok.

Ha integrációs architektúra oldalról is aktuális a téma, kapcsolódó háttér: Rendszerintegráció: hogyan kösd össze az ERP-t, CRM-et és BI-t?.