XRechnung, ZUGFeRD és BIS Billing 3.0: mely e-számla-formátumokat kell támogatnia szoftverének

Az EN 16931 szemantikai adatmodellt ír le. Meghatározza, milyen adatokat tartalmaz egy számla, és ezek hogyan viszonyulnak egymáshoz, például a számlaszámot BT-1-ként vagy a vevői hivatkozást BT-10-ként. Maga a szabvány nem fájlformátum.

A technikai leképezéshez két szintaxist enged meg: az UBL-t és az UN/CEFACT CII-t. Mindkettő ugyanazt a szemantikai modellt képezi le, de az elemnevekben és a felépítésben különböznek. Az a szoftver, amely csak UBL-t olvas be, nem tud automatikusan feldolgozni egy CII-számlát, még akkor sem, ha az szabványnak megfelelő.

A megvalósítás szempontjából ez a karbantartási ráfordításról dönt. Két párhuzamos leképezés azt jelenti, hogy minden szabályváltozást két helyen kell átvezetni. Aki ehelyett egyszer a szabvány szemantikai modelljére képez le, és abból állítja elő mindkét szintaxist, változásonként csak egy helyhez nyúl.

Fogadáskor fordítva: a beérkező fájlt először a szemantikai modellre képezik le, és onnan veszik át az Ön adatmodelljébe.

A szabvány felett helyezkednek el a nemzeti és hálózatspecifikus változatok, amelyeket a szabvány Core Invoice Usage Specificationnek, röviden CIUS-nak nevez. Egy CIUS szűkíti a szabványt. Opcionális mezőket tesz kötelezővé, másokat kizár, és saját Schematron-szabályokat hoz magával. A szabvány terjedelmén túlmutató változatok neve extension (kiterjesztés).

Szintaxistól és változattól függetlenül az e-számla vagy tiszta XML-fájlként, vagy beágyazott XML-fájlt tartalmazó PDF/A-3-ként létezik. A második esetre a hibrid formátum kifejezés honosodott meg.

Az XRechnung az EN 16931 egyik CIUS-a, amelyet az IT-szabványok koordinációs hivatala (Koordinierungsstelle für IT-Standards, röviden KoSIT) gondoz. Mindkét szintaxisban létezik. Megjelenítési komponense nincs, a fájl tiszta XML.

A szövetségi közigazgatásnak szóló számlákhoz az XRechnung az előírt formátum. A számla címzése a Leitweg-ID alapján történik, amelyet az adatkészletben vevői hivatkozásként adnak meg.

A benyújtási út a címzettől függ. Szóba jönnek a ZRE és az OZG-RE portálok vagy egy Peppol Access Point. A B2B-ben a Leitweg-ID-nek nincs szerepe. Ott az XRechnung csak egy a több megengedett profil közül.

Jelenleg a 3.0.2-es verzió érvényes. Az XRechnung 4.0-ról, az EN 16931 2026-os kiadásának megvalósításáról már létezik előzetes verzió. Az XRechnung 4.0 végleges verziója várhatóan 2027 tavaszán jelenik meg.

A ZUGFeRD egy CII szerinti XML-fájlt csomagol egy PDF/A-3-ba. Az ember a PDF-et látja, a szoftver pedig az XML-t olvassa.

A specifikáció több, eltérő adatterjedelmű profilt ismer, a MINIMUM-tól az EXTENDED-ig.

A MINIMUM és a BASIC WL nem tartalmaz teljes számlát, és nem felel meg a szabványnak. Az EN 16931 profiltól kezdve (régebbi változatokban COMFORT néven) a strukturált rész szabványnak megfelelő. Szoftverének importáláskor ki kell olvasnia a profilt, és a MINIMUM vagy BASIC WL profilú fájlokat külön kell kezelnie, például kézi ellenőrzéssel.

A Factur-X technikailag nagyrészt megegyezik a ZUGFeRD-del.

A ZUGFeRD főként ott hasznos, ahol ügyfelei olyan címzetteknek számláznak, akik a számlákat továbbra is vizuálisan ellenőrzik. Ennek során jogilag csak a beágyazott XML az irányadó. Ha a PDF és az XML eltér egymástól, a 2025. október 15-i BMF-körlevél szerint a strukturált rész adatai az elsődlegesek.

Egy csak a PDF-et ellenőrző jóváhagyási folyamat ezért olyan számlát is jóváhagyhat, amelynek irányadó tartalma eltér.

Küldéskor szoftverének a PDF-et és az XML-t ugyanabból az adatkészletből kell előállítania, hogy a kettő ne térjen el egymástól. Fogadáskor az ellenőrzéshez saját nézetet kell felépítenie az XML-ből, ahelyett hogy a mellékelt PDF-et jelenítené meg. A német Szövetségi Pénzügyminisztérium szintén azt javasolja, hogy az XML-részt saját maga jelenítse meg.

A Peppol BIS Billing 3.0 szintén az EN 16931 egyik CIUS-a, az UBL 2.1-re rögzítve. Az OpenPeppol saját formátumként specifikálta a számlák és jóváírások hálózaton keresztüli cseréjéhez.

A szabvány szabályai mellett saját Schematron-szabályokat is hoz magával. Egy fájl átmehet az EN 16931 szerinti ellenőrzésen, és elbukhat egy Peppol-szabályon. Gyakran olyan kódlistákról vagy mezőkről van szó, amelyeket a hálózat szűkebben határoz meg, mint a szabvány.

A specifikációt verziózottan fejlesztik tovább. Aki maga validál, ellenőrizze, hogy szabálykészletei megfelelnek-e az aktuális állapotnak.

Hosszabb távon a Peppol a PINT felé halad, amely a számlaprofilok nemzetközileg összehangolt alapja Európán kívül. A németországi megvalósításon ez jelenleg nem változtat.

Ezekhez a számlákhoz szoftverének tudnia kell XRechnungot előállítani. A címzett Leitweg-ID-je kötelező mezőként a számla adatkészletébe tartozik, és az XRechnungban vevői hivatkozásként (BT-10) jelenik meg. Ha hiányzik vagy rossz mezőben áll, a befogadó portál elutasítja a számlát.

A törvény EN 16931 szerinti számlát követel meg, a formátumot nyitva hagyja. Az XRechnung, a ZUGFeRD az EN 16931 profiltól kezdve és a Peppol BIS Billing is megengedett. A beágyazott XML ennek során jogilag irányadó marad. Ha a PDF és az XML eltér egymástól, a címzett esetleg más adatokat ellenőriz, mint amelyek jogilag érvényesek.

A belföldi vállalkozásoknak 2025. január 1. óta képesnek kell lenniük EN 16931 szerinti e-számlák befogadására. Szabványnak megfelelő e-számlához a feladónak ezért nincs szüksége a címzett hozzájárulására, még akkor sem, ha az egy bizonyos formátumot részesít előnyben.

A két félnek csak a továbbítási csatornáról és a szabványon kívüli formátumokról kell megállapodnia. A gyakorlatban ezért a megállapodott csatorna az adott üzleti partner törzsadataiba tartozik.

A Peppol BIS Billing 3.0 mellett a Peppol-hálózaton keresztül XRechnung és 2025 márciusa óta ZUGFeRD hibrid fájlként is továbbítható. Azok a dokumentumtípusok, amelyeket egy címzett a címtárszolgáltatásban regisztrált, mutatják, milyen formátumokat fogad. Küldés előtt szoftverének le kell kérdeznie ezt a regisztrációt, és ki kell választania a megfelelő formátumot. Egyedi ellenőrzésekhez a Peppol-azonosító kereső bejelentkezés nélkül megmutatja ezt.

Folyamatos üzemben szoftverének ezt a lekérdezést küldés előtt automatikusan kell végrehajtania, vagy közvetlenül az SML és SMP címtárszolgáltatásokon, vagy Peppol Access Pointja API-ján keresztül. Ez alapján meghatározható egy közösen támogatott formátum, majd ebben a formátumban állítják elő az e-számlát.

A beérkező számlák abban a formátumban érkeznek, amelyet a feladó választott. Szoftverének ezért mindkét szintaxist, az UBL-t és a CII-t is olvasnia kell, és ezzel az XRechnungot is mindkét változatban. Ehhez jön a ZUGFeRD és a Factur-X mint hibrid fájlok, és amint ügyfelei külföldről kapnak számlákat, az ott szokásos profilok.

Minden beérkező fájl tartalmaz egy azonosítót arról, melyik változatot használja. UBL-ben a cbc:CustomizationID elemben, CII-ben az irányelv kontextusparaméterében áll. Szoftverének először ezt az azonosítót kell kiolvasnia, mert ettől függ, mely ellenőrzési szabályok érvényesek, és hogyan kerül át a fájl az Ön adatmodelljébe.

Egyes Peppol Access Pointok leveszik Önről ezt a lépést. Ellenőrzik a beérkező fájlt, kiolvassák a számlaadatokat, és az eredeti fájllal együtt egységes adatkészletként adják át.

Szoftverének a fogadást a küldés előtt teljes körűen le kell fednie, vagyis mindkét szintaxist és a hibrid formátumokat, mert ügyfeleinek már ma képesnek kell lenniük e-számlák befogadására.

A küldés ügyfelei számára két lépcsőben válik kötelezővé: 2027. január 1-jétől az előző évben 800 000 eurót meghaladó teljes árbevétel esetén, 2028. január 1-jétől pedig az összes többi belföldi B2B-ügyletre.

Aki a CII-szintaxissal kezd, azzal az XRechnung CII-változatát és a ZUGFeRD-et is elő tudja állítani. Az UBL akkor válik szükségessé, amint a Peppol-hálózatban lévő címzettek Peppol BIS Billing 3.0-t várnak, mert ez a formátum UBL-t feltételez.

Minden áfajogi kötelező adatnak gépileg feldolgozható módon az e-számla strukturált részében kell szerepelnie. Ide tartozik a szolgáltatás leírása is. Egy mellékletre, szállítólevélre vagy linkre való hivatkozás nem helyettesít kötelező mezőt. Ennek alapja a német Szövetségi Pénzügyminisztérium e-számláról szóló GYIK-je és a 2025. október 15-i BMF-körlevél.

Az ok az e-számla felépítésében rejlik. Az olyan hibrid formátumoknál, mint a ZUGFeRD, az XML-ben lévő adatok az irányadók, a PDF csak egy nézet. Egy csak a PDF-ben látható adat ezért nem számít.

Ha egy kötelező adat hiányzik a strukturált részből, a számla nem szabályszerűnek minősül, és veszélybe kerülhet a címzett előzetesen felszámított áfa levonásának joga. Ügyfelei ezt legkésőbb akkor veszik észre, amikor üzleti partnereik emiatt visszautasítják a számlákat.

Sok számlasablon a kötelező adatokat szövegblokkokként viszi, amelyek csak a PDF-ben jelennek meg. Ez gyakran a szolgáltatás leírását érinti, például „a 2026-114. számú ajánlat szerint”, a számla láblécében szereplő teljesítési időszakot és a fordított adózásra vonatkozó megjegyzést.

Az adatmodellben ezen adatok mindegyikének saját mezővel kell rendelkeznie, amelyből az XML kitöltésre kerül. A teljesítési időszak az elszámolási időszak mezőibe (BG-14), a fordított adózásra vonatkozó megjegyzés az adókategóriába a mentesség okával (BT-120 és BT-121) tartozik.

A technikai validálás azt ellenőrzi, hogy a szabvány kötelező mezői megvannak-e, és formailag helyesen vannak-e kitöltve. Azt nem ismeri fel, hogy a szolgáltatás leírása áfajogi szempontból elegendő-e. Egy számla tehát átmehet az ellenőrzésen, és egy kötelező adatot mégis csak hiányosan tartalmazhat.

A szállítóleveleket, munkaidő-kimutatásokat és más, a számlát kísérő dokumentumokat mellékletként be lehet ágyazni az e-számlába, az EN 16931-ben a kiegészítő bizonylatok csoportján (BG-24) keresztül. Ez helyettesíti a külön küldést, és a számlát és az igazolást egy fájlban tartja.

Egy XRechnungot két szabályrendszer alapján ellenőriznek: az EN 16931 szabályai és a KoSIT kiegészítő szabályai alapján. A Peppol BIS Billing 3.0-ra ugyanez vonatkozik az OpenPeppol szabályaival. Egy csak a szabvány szerinti ellenőrzés ezért csak korlátozottan mond valamit arról, hogy a címzett elfogadja-e a fájlt. Szoftverének annak a változatnak a szabályrendszere alapján kell ellenőriznie, amelyet a címzett elvár.

A KoSIT és az OpenPeppol rendszeresen tesz közzé szabályrendszereik új verzióit módosított kódlistákkal és Schematron-szabályokkal. Ha szoftvere nem tartja naprakészen a szabálykészleteket, olyan számlákat is elutasíthatnak, amelyeket korábban elfogadtak. Az elutasítás ilyenkor a címzettől érkezik, az ok azonban a saját, elavult szabálykészletben van.

A fejlesztés közbeni tesztekhez az egyes fájlok az ingyenes e-számla-validátorral ellenőrizhetők az EN 16931 és a Peppol-szabályok alapján. Az üzem közbeni automatikus ellenőrzéshez az InvoiceRails API-n keresztül is kínál validálást az EN 16931 és olyan profilok alapján, mint az XRechnung, a ZUGFeRD és a Peppol BIS Billing. Az ellenőrzési jelentés külön tünteti fel a hibákat, a figyelmeztetéseket és a tájékoztatásokat.

Egy leképezést egyszer építenek meg, a mögötte álló ellenőrzési szabályok azonban évente többször is változhatnak. A következő nagyobb váltás az XRechnung 4.0-val és az EN 16931 2026-os kiadásával már küszöbön áll.

A 2026-os kiadás az UBL 2.5-re támaszkodik. Megfelelő megvalósításokban az UBL 2.5 csak akkor használható, ha a CEN közzétett egy frissített szintaxis-kötést (syntax binding). Addig az UBL 2.1-en alapuló meglévő kötések érvényesek. A szolgáltatók tehát előkészíthetik az átállást, de még nem hajthatják végre.

Aki maga építi meg a csatlakozást, tartósan átvállalja ezt a karbantartást. Ide tartozik a mindkét szintaxisra vonatkozó leképezések, a kódlisták és a Schematron-szabályok naprakészen tartása, valamint a KoSIT, a FeRD, az OpenPeppol és a CEN verzióterveinek követése. Ez megvalósítható, de fejlesztési időt köt le, amely a saját termékből hiányzik.

Alternatívaként a formátumok karbantartása kiszervezhető egy Peppol Access Pointra. Az InvoiceRails, a fino data services OpenPeppol által tanúsított Access Pointja, egy API-n keresztül több mint 60 formátumot fed le, köztük az XRechnungot, a ZUGFeRD-et és a Factur-X-et, és folyamatosan karbantartja a validálási szabályokat és a formátumfrissítéseket.

A szolgáltatók egyszer csatlakoztatják a küldést és a fogadást, és a funkciót tetszőleges számú ügyfelük rendelkezésére bocsátják, igény szerint saját márkanév alatt. A saját számlaadatok interfészre történő leképezése a szolgáltatónál marad, csakúgy, mint a saját adatmodell kötelező mezői.

Hogy a szoftverszolgáltatók alapvetően hogyan hozzák be az e-számlát a saját termékükbe, arról az e-számláról szoftverszolgáltatóknak szóló cikkben olvashat.