Elektronikus számla XML formátum: mit ellenőrizz beküldés előtt?

Az elektronikus számlázásban az egyik legkellemetlenebb helyzet, amikor a számla adatszolgáltatása a NAV felé „elakad”, hibára fut, vagy ugyan befogadja a rendszer, de figyelmeztetéseket kapsz. A háttérben ilyenkor gyakran az XML-adatszerkezet vagy az abban szereplő adatok (dátumok, adószámok, áfa-összesítők, hivatkozások) inkonzisztenciája áll.

Ez a cikk egy beküldés előtti ellenőrző szemléletet ad: mire érdemes ránézni még azelőtt, hogy az elektronikus számla XML formátumú adatszolgáltatást elküldöd, vagy a számlázóprogram elküldi helyetted.

Először tisztázzuk: „e-számla XML” vagy NAV Online Számla XML?

A gyakorlatban két, egymáshoz közeli, de mégis külön világ csúszik össze a hétköznapi szóhasználatban:

• Elektronikus számla (e-számla): a vevőnek átadott számla elektronikus formában, a hitelesség, sértetlenség és olvashatóság követelményeivel.

• NAV Online Számla adatszolgáltatás: a NAV felé küldött, szabványosított XML üzenet, amely a számla adatait tartalmazza.

A „beküldés” szó és az XML-es ellenőrzések tipikusan a NAV Online Számla irányába történő adatszolgáltatásra utalnak. Itt nem az a kérdés, hogy a PDF szépen néz-e ki, hanem hogy az XML séma szerint érvényes-e, és az adatok üzletileg is konzisztensen vannak-e feltöltve.

A hivatalos specifikációt és XSD-ket a NAV Online Számla fejlesztői dokumentációja tartalmazza, érdemes mindig az aktuális verzióból dolgozni: NAV Online Számla dokumentáció.

A beküldés előtti ellenőrzés 3 szintje

A leghatékonyabb hibamegelőzéshez érdemes három rétegben gondolkodni:

A következő fejezetekben végigmegyünk a legfontosabb ellenőrzési pontokon.

1) XML technikai ellenőrzések: formai hibák kiszűrése

A NAV felé küldött XML esetében a legelső akadály mindig a sémavalidáció (XSD).

Karakterkódolás és tiltott karakterek

Tipikus, nehezen észrevehető hibaforrások:

• Nem megfelelő karakterkódolás (általában a UTF-8 az elvárt).

• Vágólapról beillesztett „okos idézőjelek”, rejtett vezérlő karakterek.

• Túl hosszú mezők (például megjegyzés, cím második sor), amelyek kilógnak a maximális hosszból.

Ha a számlázóprogramod ad egy „validálás” vagy „tesztküldés” funkciót, érdemes a küldés előtt lefuttatni, különösen integráció vagy egyedi fejlesztés esetén.

Verzió és séma megfelelőség

Az Online Számla világa verziózott: az XSD és az üzleti szabályok változhatnak.

Amit érdemes ellenőrizni:

• A használt XML a megfelelő interfészverzióhoz tartozik.

• A kötelező csomópontok és attribútumok az adott verzió szerint szerepelnek.

• Nem maradt bent régi mező vagy régi logika egy korábbi implementációból.

Ha gyakran kapsz olyan jellegű hibát, hogy „schema validation error”, az sokszor verzióeltérés vagy rossz namespace beállítás.

Egyediség és ismételt beküldés kezelése

Üzemben visszatérő probléma, amikor ugyanazt a számlát (vagy ugyanazt a kérés-azonosítót) véletlenül újraküldi a rendszer hálózati hiba, timeout vagy retry miatt.

Amit célszerű átgondolni:

• Van-e idempotens logika (ugyanarra a tranzakcióra ne szülessen duplikált beküldés).

• Mentésre kerül-e a beküldött XML és a NAV válasza (audit és hibaelhárítás miatt).

A NAV oldali feldolgozás ellenőrzéséhez hasznos lehet a státuszok értelmezése is. Ha ezzel küszködsz, érdemes ezt a témát külön is áttekinteni: NAV Online Számla státuszok, hibák, figyelmeztetések.

2) Kötelező adattartalom: amit a NAV biztosan számon kér

A sémán túl a leggyakoribb bukás a hiányos vagy rosszul kitöltött kötelező adatoknál jön.

Számlaazonosítók és alapadatok

Ellenőrizd, hogy következetes-e:

• Számla sorszáma (formátum, egyediség, megszakítások kezelése)

• Számla kiállításának dátuma

• Teljesítés dátuma (ha releváns)

• Fizetési határidő (ha releváns)

• Devizanem és árfolyam, ha nem HUF-ban számlázol

A dátumoknál különösen gyakori a logikai hiba (például fizetési határidő a kiállítás előtt), ami ugyan nem mindig technikai elutasítás, de kockázatot és magyarázkodást szülhet.

Ha időszakos elszámolásaid vannak, a teljesítési időpontok kezelésének szabályai különösen fontosak. Ehhez kapcsolódóan jó kapaszkodó: Folyamatos teljesítés számlázása, dátumok.

Eladó és vevő adatai (és a „vevő típusa”)

Az XML-ben sok mező „csak adat”, de üzletileg nem mindegy, hogy a vevő:

• belföldi adóalany,

• EU-s adóalany közösségi adószámmal,

• harmadik országbeli partner,

• magánszemély.

Tipikus hibák:

• Elgépelés az adószámban (vagy rossz formátum)

• Rossz országkód, rossz közösségi adószám jelölés

• Magánszemélynél olyan mezők erőltetése, amelyek nem relevánsak, vagy adatvédelmi szempontból aggályosak

Ha kifejezetten magánszemélyeknek számlázol, hasznos lehet a törzsadatok jogszerű bekérése: Milyen számlázási adatokat kérhetsz magánszemélytől?

3) Áfa és összesítők: itt dől el a legtöbb „csendes” hiba

Az áfával kapcsolatos hibák egy része nem azonnali elutasításként jelenik meg, hanem figyelmeztetésként, későbbi egyeztetésként, vagy rosszabb esetben helyesbítési kényszerként.

Áfakulcsok és mentességi jelölések következetessége

Ellenőrizd, hogy a tételek és az összesítők ugyanazt mondják:

• Tételsori adókulcs (például 27%, 18%, 5%, alanyi, tárgyi, fordított, ÁFA tv. hatályán kívüli)

• Adóalap és adó összege tételszinten

• Áfaösszesítőben szereplő bontás

Különösen rizikós, amikor a rendszer „szövegesen” jól jelöli a mentességet, de a strukturált mezőkben nem az elvárt kód vagy kategória szerepel.

A kötelező számlaadatokról és a helyes adattartalomról (általános szemmel) itt találsz háttéranyagot: Számlázási adatok, mit kell rögzíteni a számlán.

Kerekítés és végösszeg egyezősége

A NAV (és a könyvelés) szempontjából az egyik legtipikusabb ellentmondás:

• a tételsorok összegéből számolt nettó, áfa, bruttó,

• az összesítőben megadott nettó, áfa, bruttó,

• a fizetendő végösszeg

Különösen több tétel, kedvezmény, előleg beszámítás, devizás számla esetén tud elszaladni egy 1 Ft-os eltérés. Ezeket a hibákat érdemes automatikus ellenőrzéssel fogni.

4) Számlatípusok, hivatkozások: sztornó és helyesbítés XML-ben

A módosító és érvénytelenítő számlák (helyesbítés, sztornó) beküldésekor a hibák gyakran nem a számoknál, hanem a hivatkozásoknál vannak.

Mit érdemes ellenőrizni sztornó/helyesbítés előtt?

• Az eredeti számla sorszáma pontosan és a megfelelő mezőben szerepel

• A módosítás jellege helyesen van jelölve (ne „normál” számlaként menjen ki)

• A módosító okirat logikája konzisztens (mire hivatkozik, mit módosít)

• Időrend és dátumok rendben vannak (ne legyen értelmezhetetlen lánc)

Ha a sztornózás alapjait szeretnéd rendszerezni, ehhez van egy külön, gyakorlati útmutató: Sztornó számla kiállítása.

5) Tipikus beküldés előtti „gyorsfogások” (amivel sok hibát megelőzhetsz)

Nem mindig van idő mély XML-diagnosztikára, ezért érdemes kialakítani pár gyors, rutinszerű ellenőrzést.

• Törzsadat frissesség: vevő adószám, cím, ország, pénznem beállítások.

• Számlasablon és sorszámozás: ha több cég, több számlatömb van, ne keveredjen.

• Tételsor logika: mennyiség, egységár, kedvezmény mezők együtt értelmezhetőek.

• Áfaösszesítő kontroll: a program által számolt és a kézzel megadott mezők ne üssék egymást.

• Beküldési státusz követés: ne csak az „elküldtük” legyen meg, hanem a NAV oldali feldolgozás eredménye is.

A NAV felé történő beküldés folyamatát és ellenőrzését külön is érdemes ismerni: Számla feltöltés NAV-ba, mikor kell, hogyan ellenőrizd.

6) Naplózás és bizonyíthatóság: mentsd el, amit elküldesz

Egy későbbi vita vagy ellenőrzés során aranyat ér, ha meg tudod mutatni:

• melyik számlához milyen XML ment ki,

• mikor ment ki,

• mit válaszolt a NAV (transaction azonosító, státusz, hibakód, figyelmeztetés).

Ez nem csak fejlesztői komfort, hanem üzleti biztonság. Ha csapatban dolgoztok, a hozzáférések és felelősségi körök rendezése is csökkenti a hibák esélyét (ki állíthat ki számlát, ki küldhet be, ki módosíthat). Ehhez kapcsolódóan: Belépés, jogosultságok, csapatok online számlázóban.

Rövid összefoglaló: mit nézz át beküldés előtt?

Ha egyetlen „preflight” ellenőrzést akarsz bevezetni, ez a sorrend általában beválik:

1. XSD/séma validáció (verzió, kötelező mezők, típusok)

2. Partner- és adószám adatok (vevő típusa, ország, adózási státusz)

3. Dátumlogika (kiállítás, teljesítés, fizetési határidő)

4. Áfa és összesítők egyezősége (tételsor vs összesítő, kerekítés)

5. Számlatípus és hivatkozások (sztornó, helyesbítés, eredeti számla)

6. NAV feldolgozási státusz visszaellenőrzése (ne csak elküldött legyen, hanem befogadott is)

Hogyan segít ebben egy jól felépített számlázási rendszer?

Minél több számlát állítasz ki, minél több csatornából jön adat (webshop, CRM, manuális rögzítés), annál inkább rendszerkérdés, hogy mennyi hiba jut el az XML-ig. Egy olyan platform, ahol egy fiókban átlátod a cégeidet, a csapatjogosultságokat és az adminisztrációt, sokat levesz a terhelésből.

A Kontozz célja kifejezetten a kisvállalkozások támogatása központi számlakezeléssel, több cég kezelésével, csapatjogosultságokkal és riportokkal. Ha szeretnéd egyben kezelni az üzleti adminisztrációt, nézd meg: Kontozz.hu.