Tudástár · E-számla
Az e-számla validálása és az ellenőrzési jelentés helyes értelmezése
Ha a szoftveréből küldött e-számlát elutasítják, csapatának az ellenőrzési jelentés alapján kell kiderítenie, melyik mező váltotta ki az üzenetet, és ki tudja azt kijavítani.
Megmutatjuk, hogyan olvassa az ellenőrzési jelentést, és szoftvere mely pontjain van a validálás helye.
Mit ellenőriz az e-számla validálása
A validátor az e-számlát egymás után három szabályrendszer alapján ellenőrzi, és minden eltérést rögzít egy ellenőrzési jelentésben.
A szintaxis XML-sémája
Az EN 16931 szerinti e-számla két szintaxis egyikében készül: UBL vagy UN/CEFACT CII. Minden elterjedt alkalmazási specifikáció erre a két szintaxisra épül, például az XRechnung, a ZUGFeRD és a Peppol BIS Billing 3.0.
A szintaxis XML-sémája határozza meg, mely elemek megengedettek, milyen sorrendben állnak, és milyen adattípusúak.
A sémahibáknak nincs szabályazonosítójuk. Az XML-elemző saját kódokkal jelzi őket, például cvc-complex-type.2.4.a kóddal egy olyan elemnél, amely ott áll, ahol a séma nem várja.
A ZUGFeRD esetében egy CII-fájl PDF-be van ágyazva. A validátor az XML-részt ellenőrzi. Eltérés esetén ez a rész az irányadó a képi résszel szemben – így rögzíti a német Szövetségi Pénzügyminisztérium kötelező e-számla bevezetéséről szóló, 2025. október 15-i BMF-körlevele.
Az EN 16931 üzleti szabályai
Az üzleti szabályok az e-számla adatait logikai hibákra ellenőrzik, például hogy ki vannak-e töltve a kötelező mezők, és összeillenek-e az összegek. Az Európai Szabványügyi Bizottság (CEN) ezeket a szabályokat Schematron-fájlokként teszi közzé a GitHubon, külön az UBL-hez és a CII-hez.
A szabályazonosító előtagjából felismeri az ellenőrzés fajtáját. A BR és egy szám kombinációjú szabályok a kötelező mezőket és azok számát ellenőrzik, a BR-CO a számításokat és a mezők közötti függőségeket, a BR-CL a kódlistákat, a BR-DEC pedig az összegek tizedesjegyeit. Az olyan szabályok, mint a BR-S, a BR-AE vagy a BR-IC, az egyes áfakategóriák adatait ellenőrzik.
A CEN-fájlok ezen felül szintaxisspecifikus szabályokat is tartalmaznak. Az UBL-CR előtagú szabályok például figyelmeztetést adnak, ha egy UBL-fájl olyan elemeket tartalmaz, amelyek nem tartoznak az EN 16931 adatmodelljéhez.
Az XRechnung és a Peppol BIS Billing 3.0 szabályai
Az XRechnung és a Peppol BIS Billing 3.0 az EN 16931 alkalmazási specifikációi, szakszóval CIUS (Core Invoice Usage Specification). További mezőket írnak elő, és saját szabályokkal egészítik ki az EN 16931-et. Új adatmezőket egy CIUS nem vezethet be.
Az XRechnung szabályai BR-DE előtaggal kezdődnek, és az IT-szabványok koordinációs hivatalától (Koordinierungsstelle für IT-Standards, KoSIT) származnak. A Peppol BIS Billing 3.0 PEPPOL-EN16931 és PEPPOL-COMMON előtagú szabályokkal, valamint országspecifikus szabályokkal egészíti ki ezeket.
A BT-24-ben szereplő specifikációazonosító határozza meg, melyik alkalmazási specifikáció vonatkozik a fájlra. A KoSIT validátora ezen azonosító alapján választja ki a megfelelő ellenőrzési forgatókönyvet. Egy hibás vagy elavult azonosító ezért ahhoz vezethet, hogy a fájlt más szabályok szerint ellenőrzik, vagy elutasítják.
Amit a validálás nem ellenőriz
A validátor nem ismeri fel, hogy az adókulcs illik-e a szolgáltatáshoz, vagy hogy a szolgáltatás leírása elegendő-e.
A német Szövetségi Pénzügyminisztérium szerint minden áfajogi kötelező adatnak az e-számla strukturált részében kell szerepelnie. A szolgáltatás leírását tartalmazó mellékletre való puszta hivatkozás nem elegendő. Egy „lásd melléklet” típusú tételnév a BT-153-ban ennek ellenére átmegy a validáláson, mert egyetlen szabály sem értékeli ennek a mezőnek a tartalmát.
A KoSIT és a németországi elektronikus számla fórum (Forum elektronische Rechnung Deutschland, FeRD) közzétett egy táblázatot, amely a német áfatörvény szerinti kötelező adatokhoz hozzárendeli a megfelelő BT-mezőket. E táblázat alapján meghatározhatja, mely kötelező adatokat kell szoftverének saját plauzibilitási ellenőrzésekkel biztosítania.
Az ellenőrzési jelentés felépítése
Az ellenőrzési jelentés minden bejegyzése általában négy adatot tartalmaz.
Szabályazonosító
A szabályazonosító, például a BR-CO-15 vagy a BR-DE-2, az adott szabályrendszer dokumentációjában szereplő szabályra utal.
Súlyossági szint
A validátor minden üzenetet hibaként vagy figyelmeztetésként jelöl. A Peppol-szabályokban a hibák neve fatal. Egy figyelmeztetés önmagában általában nem vezet elutasításhoz. Egyes validátorok ezen felül tájékoztató üzeneteket is adnak, vagyis a tiszta megvalósításra vonatkozó ajánlásokat, amelyek nem befolyásolják az eredményt. A KoSIT-validátor a jelentése végén javasolja a dokumentum elfogadását vagy elutasítását.
A Peppol az új szabályokat gyakran először figyelmeztetésként vezeti be, majd egy későbbi kiadásban hibává minősíti át. A 3.0.21-es verzióval például a PEPPOL-COMMON-R052 és PEPPOL-COMMON-R053 szabályok figyelmeztetésből hibává váltak, ahogyan az a Peppol BIS Billing 3.0 kiadási megjegyzéseiben szerepel.
Hely (XPath)
A hely egy XPath-kifejezés, amely az XML érintett elemére mutat. Ugyanaz a BT-szám az UBL-ben és a CII-ben különböző helyeken található. Az áfával növelt számlaösszeg (BT-112) UBL-ben a cac:LegalMonetaryTotal alatti cbc:TaxInclusiveAmount elemben, CII-ben a ram:SpecifiedTradeSettlementHeaderMonetarySummation alatti ram:GrandTotalAmount elemben áll.
Több mezőt összehasonlító szabályok esetén a hely gyakran egy szülőelemre mutat. Az üzenetet kiváltó értéket ilyenkor az üzenet szövege alapján találja meg.
Üzenetszöveg
Az üzenetszöveg leírja a szabályt, és többnyire megnevezi az érintett BT-számokat. A BR-CO-15 üzenete például azt mondja ki, hogy az áfával növelt számlaösszegnek (BT-112) meg kell egyeznie az áfa nélküli számlaösszeg (BT-109) és az áfaösszeg (BT-110) összegével.
A 3.0.21-es verzió óta a Peppol-szabályok szövegei a szabályazonosítóval kezdődnek.
Az ellenőrzési jelentések kiértékelése a helyes sorrendben
Egy hosszú ellenőrzési jelentés gyakran néhány okra vezethető vissza.
-
Sémahibák javítása
Amíg a fájl nem felel meg a sémának, az üzleti szabályok eredményei kevéssé informatívak, vagy teljesen hiányoznak. Ezért először az exportban lévő sémahibákat javítsa ki, majd validálja újra a fájlt.
-
Bejegyzések csoportosítása szabályazonosító szerint
Egy leképezési (mapping) hiba minden számlatételben előfordulhat. Egy 40 tételes számla ilyenkor 40 bejegyzést hoz létre ugyanarra a szabályra, amelyek egyetlen okra vezethetők vissza. Ezért a jelentést szabályazonosítók szerint értékelje ki.
-
Következményes hibák felismerése
Egy hiányzó elem egyszerre több szabályt is megsérthet. Ha hiányzik az áfa részletezése (BG-23), a validátor például a BR-CO-18-at és ezen felül az érintett áfakategória szabályait, például a BR-S-01-et is jelzi. Először az okot hárítsa el, és validáljon újra, mielőtt a többi üzenetet egyenként feldolgozná.
-
A BT-számon keresztül a saját adatmodellhez
A BT-szám köti össze az ellenőrzési jelentést az Ön szoftverével. Tartson fenn egy hozzárendelést minden BT-számtól az adatbázismezőhöz, a felület űrlapmezőjéhez és a felelősséghez. A felelősség határozza meg, hogy a hibát az Ön csapata javítja-e, vagy az ügyfele, például ha törzsadatok hiányoznak.
-
Figyelmeztetések értékelése és rögzítése
Minden figyelmeztetésnél döntse el, hogy kijavítja-e, vagy tudatosan elfogadja, és rögzítse a döntést. Minden új kiadásnál ellenőrizze, hogy egy elfogadott figyelmeztetést nem minősítenek-e át hibává.
Tipikus hibaokok szabálycsoportonként
A szabálycsoport gyakran már megmutatja, szoftvere melyik pontján kell a javítást elvégezni.
Szabályazonosító nélküli sémahibák
Az ok az exportban lévő elemsorrend, névtér vagy hibás adattípus. A javítás az exportfunkcióban történik, egyszer, minden ügyfél számára.
BR és egy szám
Az ok egy olyan kötelező mező, amely nincs leképezve, vagy üres a törzsadatokban. A javítás a leképezésben vagy a felület kötelező mezőjénél történik.
BR-CO és BR-DEC
Az ok az összegekben, a kerekítésben, a bizonylatszintű engedményekben és felárakban rejlik. A javítás a számlakészítés számítási logikájában történik.
BR-CL
Az ok egy elavult vagy saját kód, például mennyiségi egységekre vagy országokra. A javítás a szoftverében lévő kódlistáknál történik.
BR-S, BR-AE, BR-IC és további kategóriák
Az áfakategória, az adókulcs és a mentesség oka nem illik össze. A javítás az adólogikában és a cikktörzsadatoknál történik.
UBL-CR
Az export az EN 16931 adatmodelljén kívüli UBL-elemeket tartalmaz. A javítás az exportfunkcióban történik.
BR-DE
Hiányoznak az eladó elérhetőségi adatai, a fizetési adatok vagy a vevői hivatkozás. A javítás többnyire ügyfelei törzsadatainál történik.
PEPPOL-EN16931 és PEPPOL-COMMON
Hiányzik az elektronikus cím, vagy egy azonosító formátuma hibás. A javítás a törzsadatoknál és a Peppol-azonosítók kezelésénél történik.
Hiányzó vevői hivatkozás XRechnungnál (BR-DE-15)
A BR-DE-15 szabály a BT-10-ben hiányzó vevői hivatkozást jelzi. A közigazgatásnak szóló számláknál itt a hatóság Leitweg-ID-je áll. B2B-számláknál a német Szövetségi Pénzügyminisztérium szerint áfajogi szempontból elegendő egy helyőrző, például „-”, ha a számla címzettje nem ad meg saját azonosítót. Szoftvere ezért a B2B-számláknál előre kitöltheti a mezőt egy helyőrzővel, amelyet ügyfelei felülírhatnak.
Kerekítési eltérések az áfánál (BR-S-09)
A BR-S-09 szabály a normál adókulcsú kategória áfaösszegét az adóalap és az adókulcs szorzatával veti össze. Ha szoftvere tételenként kerekíti az áfát, majd összeadja az összegeket, az összeg eltérhet ettől. Sok tétel esetén az eltérés nagyobb lehet, mint a szabály által megengedett tűréshatár. Ezért az adóösszeget kategóriánként az adóalapból és az adókulcsból számítsa ki, ahogy a szabály előírja.
A validálás beépítése a szoftverébe
A validálásnak öt helyen van a helye a szoftverében és a fejlesztési folyamatában.
Küldés előtt
Szoftverének minden e-számlát közvetlenül a létrehozás után validálnia kell, és hiba esetén le kell állítania a küldést. Ügyfelei kevés hasznát veszik egy szabályazonosítónak vagy egy XPath-kifejezésnek. Ezért azokat a szabályokat, amelyeket ügyfelei maguk is javíthatnak, fordítsa le az érintett űrlapmezőnél megjelenő tájékoztatásra. A BR-DE-6-hoz, az eladói kapcsolattartó BT-42-ben szereplő telefonszámához tartozó tájékoztatás például így szólhat: „Kérjük, adjon meg egy telefonszámot az egyeztetéshez”.
Az Ön leképezésére vagy számítási logikájára visszavezethető hibákat ügyfele nem tudja kijavítani. Ezeknek belső jelzésként kell az Ön csapatához kerülniük.
Fogadáskor
Szoftverének a beérkező e-számlákat is validálnia kell, és az eredményt a bizonylatnál meg kell jelenítenie. Tárolja az eredeti fájlt változatlanul, mellette pedig az ellenőrzési jelentést külön dokumentumként. A német Szövetségi Pénzügyminisztérium előírja, hogy az e-számla legalább strukturált részét sértetlenül, eredeti formájában kell megőrizni.
Ha egy bejövő számla hibákat tartalmaz, ügyfele helyesbített számlát kérhet a kiállítótól. Szoftvere támogathatja ezt a lépést, például egy előkészített, az ellenőrzési jelentést tartalmazó megkereséssel a kiállító felé.
Automatizált tesztekben
Hozzon létre egy tesztszámla-gyűjteményt, amely lefedi számlatípusait a kódjaikkal, például a 380-as kódot a számlára és a 384-es kódot a helyesbítő számlára. Fedjen le továbbá minden áfakategóriát, amelyet ügyfelei használnak. Ehhez jönnek az engedmények és felárak, valamint minden szintaxis, amelyet szoftvere előállít. Szándékosan hibás fájlokat is vegyen fel, és ellenőrizze, hogy a validátor elutasítja-e őket.
A KoSIT-validátor nyílt forráskódú parancssori program, amely beépíthető egy build-pipeline-ba. A KoSIT ezen felül egy mintaszámlákat tartalmazó tesztcsomagot is biztosít, amely kiindulópontként szolgálhat saját gyűjteményéhez.
A szabályrendszerek minden frissítése után
A szabályrendszerek új verziószám nélkül is változnak. A KoSIT az XRechnung 3.0.2-höz rendszeresen tesz közzé hibajavításokat tartalmazó csomagokat, legutóbb a 2026. augusztus 31-i változatban. Az XRechnung 3.0 legalább 2027. július 31-ig hatályban marad.
Az XRechnung 4.0 specifikáció előzetes verziója 2026. szeptember 15-én jelent meg. Kifejezetten nem éles használatra szánták, hanem korai áttekintést ad az új és módosított funkciókról. A végleges verzió várhatóan 2027 tavaszán jelenik meg a technikai komponensekkel együtt.
Az OpenPeppol rendszeresen tesz közzé új kiadásokat a Peppol BIS Billing 3.0-hoz, az elmúlt években mindig májusban és novemberben. A 3.0.21-es verzió 2026. május 20-án jelent meg, és 2026. augusztus 17. óta kötelező.
Minden kiadáshoz tervezzen be egy fix időpontot, amikor tesztgyűjteményét az új szabályok alapján validálja. Minden ellenőrzési jelentésben rögzítse, hogy a validátor és a szabályrendszer melyik verziójával készült. Így egy eredményt akkor is nyomon tud követni, ha a szabályok azóta megváltoztak. Az XRechnung 4.0-ra való átálláshoz tesztkörnyezetének mindkét verziót párhuzamosan kell tudnia ellenőrizni.
Az ellenőrzési jelentések kiértékelése az összes ügyfélre kiterjedően
Ha szoftvere sok ügyfél számára állít elő e-számlákat, érdemes az ellenőrzési jelentéseket az összes ügyfélre kiterjedően kiértékelni. Ha ugyanaz a szabályazonosító hirtelen sok ügyfélnél jelenik meg, az ok valószínűleg a leképezésben vagy egy új szabályrendszerben van. Ha csak egy ügyfélnél fordul elő, az ok inkább annak törzsadataiban keresendő.
Validálás az InvoiceRailsszel
Az ebben a cikkben leírt lépéseket teljes egészében saját maga is megvalósíthatja. Az egyszeri ráfordítás ehhez áttekinthető, a tartós azonban nem: a szabályrendszerek, kódlisták és ellenőrzési konfigurációk évente többször változnak, és minden változásnak be kell kerülnie a tesztjeibe, a küldési folyamatába és a kiadási tervezésébe.
A validálás, a küldés és a szabályrendszerek karbantartása ezért egy tanúsított Peppol Access Pointra, például az InvoiceRailsre is átruházható.
E-számla-validátor egyedi ellenőrzésekhez
Az ingyenes InvoiceRails e-számla-validátor bejelentkezés nélkül ellenőrzi az UBL és CII formátumú XML-fájlokat, valamint a hibrid PDF-számlákat. Automatikusan felismeri a szintaxist, a verziót és a profilt, köztük az XRechnungot, a Peppol BIS Billing 3.0-t, a ZUGFeRD-et, a Factur-X-et és az EN 16931 további profiljait. Ezután a fájlt az XML-séma, valamint a felismert profil Schematron- és üzleti szabályai alapján validálja. Az ellenőrzési jelentést PDF-ként letöltheti vagy linkkel megoszthatja, például ha ügyfélszolgálata egy elutasított számlát egyeztet egy ügyféllel.
Az InvoiceRails API az Ön szoftverében
Az InvoiceRails a fino data services OpenPeppol által tanúsított Peppol Access Pointja. Szoftvere REST API-n keresztül csatlakozik az InvoiceRailshez, és ezen keresztül tetszőleges számú ügyfél számára küld és fogad e-számlákat, igény szerint white-label megoldásként.
Az API a validálást saját végpontként kínálja, szintén automatikus profilfelismeréssel. Szoftvere így az e-számlákat közvetlenül a létrehozás után ellenőrizheti. A válaszban minden üzenet tartalmazza a szabályazonosítót, a súlyossági szintet, az üzenetszöveget és a helyet XPath-ként. Szoftvere a validálási azonosítót a számlánál tárolhatja, és az eredményt legalább 90 napig újra lekérheti.
Az InvoiceRails ezen hívás nélkül is validál minden fájlt, amelyet szoftvere a Peppolon keresztül küld. Szoftverének előzetesen ellenőriznie kell, milyen formátumokat támogat egy címzett.
Az InvoiceRails a beérkező e-számlákat is ellenőrzi, és az eredeti fájlt a kiolvasott számlaadatokkal együtt átadja szoftverének. Egy webhook jelzi szoftverének a kézbesítési státusz minden változását.
Szoftvere továbbra is felel az adatmodellje mezőinek hozzárendeléséért, a felületén megjelenő érthető tájékoztatásokért és a kötelező adatoknak azokért a plauzibilitási ellenőrzéseiért, amelyeket egyetlen szabály sem fed le.
