Kötelező E-Rechnung Németországban: strukturált számlák kiállítása saját rendszerekből 2027. január 1-jéig

2027. január 1-jétől az a német vállalkozás, amelynek 2026-os árbevétele meghaladta a 800 000 eurót, nem küldhet többé papír- vagy PDF-számlát egy másik német vállalkozásnak. A számlának strukturált e-számlának kell lennie: az EN 16931 európai szabvány szerint felépített adatfájlnak. 2028. január 1-jétől a küszöb megszűnik, és a szabály néhány szűk kivételtől eltekintve minden vállalkozásra vonatkozik.

Egy kis cégnek ez szoftverfrissítésként érkezik. Annak a cégnek viszont, amelynek a számlái saját számlázórendszerből, iparági csomagból vagy tizenöt éve testre szabott ERP-ből jönnek, ez szoftverprojekt, és nagyjából tizenhárom hét van hátra. Ez a cikk a második csoportnak szól.

Mit mond a törvény

A meghatározást a § 14 UStG tartalmazza: olyan számla, „die in einem strukturierten elektronischen Format ausgestellt, übermittelt und empfangen wird und eine elektronische Verarbeitung ermöglicht”. A formátumnak meg kell felelnie a 2014/55/EU irányelv szerinti európai szabványnak (a gyakorlatban az EN 16931-nek), vagy a felek állapodhatnak meg benne, feltéve, hogy a kötelező adatok helyesen és hiánytalanul kinyerhetők egy, a szabvánnyal összeegyeztethető formába. A PDF nem felel meg, bármilyen rendezettnek látszik is.

A kötelezettség azokra az ügyletekre vonatkozik, amelyekben egy másik vállalkozás a vevő, és mindkét fél Németországban telepedett le. Az átmenetet a § 27 Abs. 38 UStG szabályozza:

• A 2025-ben és 2026-ban teljesített ügyletekről továbbra is lehet papíron számlázni, vagy a vevő hozzájárulásával más elektronikus formátumban, amennyiben a számla 2026. december 31-ig kimegy.
• A 2027-ben teljesített ügyletekre ugyanez a könnyítés 2027. december 31-ig érvényes, de csak akkor, ha a számlakibocsátó teljes árbevétele az előző naptári évben nem haladta meg a 800 000 eurót.
• Az EDI, amely nem felel meg a szabványnak, a 2027-ben teljesített ügyletekre a vevő hozzájárulásával mérettől függetlenül tovább használható.

Három részlet többet számít, mint amilyennek látszik.

A küszöböt az előző évi árbevétel alapján mérik. A 2027-es helyzete a 2026-os számán múlik, amelyet senki nem fog pontosan ismerni a könyvek lezárásáig. Ha bármennyire is közel van a 800 000 euróhoz, úgy építsen, mintha felette lenne.

A könnyítés egy küldési dátummal ér véget. Szó szerint olvasva az első átmeneti szabály 2026. december 31-én már nem fedi le a papír- és PDF-számlát, még a 2026-ban elvégzett munkára sem. Ha a küszöb felett van, és utólag számláz, a decemberi munkáról január első hetében küldött számlának már strukturáltnak kell lennie. Ezt erősíttesse meg az adótanácsadójával, de ne tervezzen január közepi éles indulást.

Néhány számla kívül esik a hatályon: a fogyasztóknak szóló számlák, a határon átnyúló számlák, a bruttó 250 eurót meg nem haladó kisösszegű számlák, a számlának minősülő menetjegyek, a Kleinunternehmer (alanyi adómentes kisvállalkozó) számlái, valamint az UStG § 4 Nr. 8 és Nr. 29 közötti pontjai szerint adómentes ügyletek.

Nem tudunk olyan törvényjavaslatról, amely ezeket a dátumokat elhalasztaná. Tervezzen úgy, hogy érvényesek maradnak.

A fogadás 2025 óta kötelező. A kiállítás az új rész.

2025. január 1. óta minden német vállalkozásnak képesnek kell lennie e-számlák fogadására. A német Szövetségi Pénzügyminisztérium e-számlázási GYIK-ja egyenesen fogalmaz arról, mi kell ehhez: „Für den Empfang einer elektronischen Rechnung genügt bereits ein E-Mail-Postfach.” Egy postafiók elég.

Figyeljen a § 14 egyik mondatára: ahol az e-számlázási kötelezettség érvényes, a címzett hozzájárulására nincs szükség. Egy német üzleti vevő nem utasíthatja vissza a strukturált számláját.

A kiállítás más probléma. Fogadáskor egy eszköz valaki más fájlját olvassa. Kiállításkor az Ön rendszere a szerző: ha az adat a forrásnál hibás, a láncban később senki nem tudja kijavítani, és az a számla, amely elbukik a vevője validálásán, kifizetetlenül áll.

Kinek elég ehhez egy frissítés

Egyenesen: ha kis cégként DATEV-ből, lexoffice-ból, sevDeskből vagy hasonló csomagból számláz, a formátumot a szoftverszállítója szállítja. Ellenőrizze a törzsadatait (közösségi adószám, ügyfélcímek, bankadatok), kapcsolja be a funkciót, és küldjön egy tesztszámlát. Nincs szüksége projektre, és szoftvercégre sincs.

Nagyjából ugyanez igaz egy, a standardhoz még közel álló, elterjedt ERP-re: a kimenetet a gyártó vagy a partnere adja, a munka pedig beállítás és tesztelés.

A cikk további része azoknak a cégeknek szól, amelyek számlái saját tulajdonú kódból jönnek, vagy olyan kódból, amelyet már senki nem tart karban:

• előfizetéses platformok, piacterek és közművek számlázómotorjai, amelyek programból, nagy volumenben állítanak ki számlákat;
• nagykereskedelmi, építőipari, logisztikai vagy helyszíni szervizszoftverek, ahol a szállító kicsi, lassú vagy már nem is létezik;
• olyan ERP-k, amelyek számlakimenetét évekkel ezelőtt egyedi nyomtatóprogramként, jelentéssablonként vagy hó végi körlevélként írták újra.

A formátumok: EN 16931, XRechnung és ZUGFeRD

Az EN 16931 az európai szabvány. Meghatározza a számla szemantikai modelljét (a mezőket, azok jelentését, hogy melyik kötelező, és a köztük fennálló üzleti szabályokat), és két XML-szintaxishoz köti: az UBL 2.1-hez és az UN/CEFACT CII-hez.

Az XRechnung az EN 16931-re épülő német specifikáció, amelyet a KoSIT gondoz: tiszta XML bármelyik szintaxisban, a közigazgatási szervek megkövetelik, és vállalkozások között ugyanúgy érvényes. A KoSIT XRechnung-oldala szerint a 3.0-s verzió 2024. február 1. óta hatályos, és legalább 2027. július 31-ig az is marad. A 4.0 előzetes változata 2026 szeptemberében jelent meg, a végleges kiadás 2027 tavaszára várható. Ön a 3.0-val indul élesben, és az első évén belül frissít.

A ZUGFeRD hibrid formátum: PDF/A-3 fájl, beágyazott CII XML-lel. Az emberek a PDF-et olvassák, a gépek az XML-t. Franciaországban ugyanezt a formátumot Factur-X-nek hívják, a kettő technikailag azonos. A FeRD 2026. augusztus 4-én tette közzé a 2.5.2-es verziót. A ZUGFeRD profilokban létezik (MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED), és a minisztérium GYIK-ja a ZUGFeRD-t a 2.0.1-es verziótól fogadja el, „mit Ausnahme der Profile MINIMUM und BASIC-WL”.

Hibrid számlánál az XML számít. A GYIK a strukturált részt „führender Teil”-nek, vagyis vezető résznek nevezi. Ha a PDF és az XML eltér egymástól, a PDF a hibás.

A legtöbb német B2B számlakibocsátónak az ésszerű alapértelmezés a ZUGFeRD az EN 16931 profillal, hogy a számlákat még szemmel olvasó vevők folytathassák, emellett XRechnung a közigazgatási szerveknek és mindenkinek, aki kéri. Mindkettő egyetlen belső számlaobjektumból készüljön, ne két külön kódágból.

Mit kell megváltoztatni a rendszerében

A számla adattá válik, nem elrendezéssé

Sok régebbi rendszer nyomtatáskor rakja össze a számlát: sablonba fűzött szöveg, a jelentésen belül összeadott végösszegek, az áfára vonatkozó megjegyzés pedig beégetett bekezdés. Ebből semmi nem éli túl az EN 16931-et. Olyan tárolt számlaobjektum kell, amely minden mezőt tartalmaz, és abból készül az XML és a PDF is.

A mezők, amelyek általában hiányoznak vagy hibásak:

• A felek adatai. Strukturált címek ISO-országkódokkal, és közösségi adószám vagy adószám. A szabad szöveges címblokkokat szét kell bontani.
• A teljesítés dátuma vagy a szolgáltatási időszak, adatként tárolva, nem a fejléc egyik mondataként.
• Mértékegységek. Minden mennyiséghez az ENSZ-EGB 20. számú ajánlásának kódja kell (H87 a darab, KGM a kilogramm, DAY a nap). A „Stk.” és a „pauschal” értékeket le kell képezni.
• Áfa. Minden sor áfakategóriát és -kulcsot hordoz. A számla kategória és kulcs minden kombinációjára egy-egy áfaösszesítést tartalmaz, és a végösszegeknek két tizedesjegyre pontosan egyezniük kell. Azok a rendszerek, amelyek soronként kerekítik az áfát, itt elbuknak.
• A mentességre és a fordított adózásra utaló szöveg. A PDF alján lévő mondatból áfakategória-kód és mentességi indok lesz.
• Fizetés. A fizetési mód, az IBAN és a feltételek strukturált formában.
• Hivatkozások. A rendelésszám vagy vevői hivatkozás, amely alapján a vevő szállítói könyvelése egyeztet. Ha eddig nem tárolta, kezdje el most rögzíteni.

Gyakori buktató a csak szöveget tartalmazó sor („szállítás a megállapodás szerint”). Strukturált számlában a sor számlázható tételsor, így ez a szöveg megjegyzésbe való.

Helyesbítések, jóváírások és önszámlázás

A GYIK egyértelmű: ahol az e-számlázási kötelezettség érvényes, a helyesbítésnek is e-számlának kell lennie, a helyesbítésre szolgáló számlatípussal. Az EN 16931-ben ez szám és kiállítási dátum alapján visszamutat az előző számlára, ezért a rendszerének ezt a kapcsolatot adatként kell megőriznie.

Figyeljen a szóhasználatra. A német áfajogban a „Gutschrift” önszámlázással kiállított számla, amelyet a vevő állít ki előzetes megállapodás alapján (§ 14 Abs. 2 UStG). Amit angolul credit note-nak hívnak (árcsökkentés vagy sztornó), az helyesbítés. Sok rendszer egy dokumentumtípust használ mindkettőre. A leképezés előtt válassza szét őket, és ha önszámlázással számláz a beszállítói helyett, ezeket a dokumentumokat kezelje úgy, mint a rendszere által kiállított számlákat.

A végszámla mellékletben felsorolhatja a korábbi részfizetéseket, amennyiben a strukturált rész hivatkozik rá; a GYIK megerősíti, hogy ez 2027 után is így marad.

Validálás, mielőtt bármi kimegy

A KoSIT nyílt forráskódú validátort tesz közzé, amely sémák és Schematron-szabályok alapján ellenőrzi az XML-t, nyilvános XRechnung-konfigurációval. Parancssorból, HTTP-démonként vagy könyvtárként is futtatható. Tegye a küldési útvonalba: minden számlát validáljon, mielőtt kimegy, a hibás pedig kerüljön egy sorba, amelynek megnevezett gazdája van, azzal az információval, melyik mező melyik szabályt sértette.

ZUGFeRD esetén a beágyazott XML-t a profilja szabályai szerint validálja, a PDF/A-3 tárolót külön ellenőrizze, és győződjön meg róla, hogy a PDF ugyanazokat a végösszegeket mutatja, mint az XML.

Továbbítás

A GYIK szerint a törvény „sieht keinen bestimmten Weg vor”: nem ír elő csatornát. Az e-mail csatolt fájllal megfelel. Ugyanígy egy API, egy letöltési portál, egy csoporton belüli közös tárhely, vagy (ez a minisztérium saját példája) egy pendrive. Németországban a belföldi B2B-forgalomhoz a Peppol nem kötelező.

A fejlesztési munka ügyfelenként jelentkezik: számlázási cím, preferált formátum, és nyilvántartás arról, mi hová ment ki. Egy sikertelen küldés utáni újrapróbálkozás ugyanazt a dokumentumot viszi ugyanazzal a számlaszámmal. Egy ügyletre két számlaszám adóügyi probléma, nem szoftveres.

Archiválás

Legalább a strukturált részt „unversehrt in seiner ursprünglichen Form”, vagyis sértetlenül, eredeti formájában kell megőrizni, a § 14b UStG pedig a kiállítás évének végétől számított nyolc évben határozza meg a megőrzési időt. Pontosan azokat a bájtokat tárolja, amelyeket elküldött, hash-sel együtt. Ne tervezze, hogy a számlákat később az adatbázisból generálja újra: addigra az adatok és a kód is megváltoznak. Ugyanez vonatkozik a beérkező e-számlákra.

Terv 2026 októberétől decemberéig

Tizenhárom hét elég egy fókuszált fejlesztéshez, ha a forrásadatok elfogadható állapotban vannak. A számlázórendszer lecseréléséhez nem elég.

1. és 2. hét: leltár és döntések. Vegye számba az összes helyet, ahol számla készül, beleértve a kézi jóváírásokat, a projektzáró számlákat és az egyik nagy ügyfélhez használt táblázatot. Vesse össze a 2026-os árbevételt a küszöbbel. Válassza ki az alapértelmezett formátumot, és döntse el, hogy saját maga építi meg a generátort, vagy egy e-számlázási szolgáltató API-jának küldi a számlaadatokat.

A 2. héttől a 4. hétig: adathiány-elemzés. Képezzen le mezőről mezőre három hónapnyi valódi számlát az EN 16931-re. Jelölje meg, mi hiányzik, minek kell kóddá válnia, és mit számolnak másként. Itt derül ki a projekt valódi mérete.

A 4. héttől a 9. hétig: fejlesztés. A számlaobjektum, a leképezés, az XML és a PDF/A-3 előállítása, a validátor a küldési útvonalban, a hibasor és az archívum. Ezzel párhuzamosan valaki rendbe teszi a törzsadatokat, és begyűjti az ügyfelektől a számlázási címeket.

A 9. héttől a 11. hétig: visszajátszás és pilot. Futtassa át az elmúlt három hónap számláit az új generátoron, és validálja mindegyiket. Ezután próbálja ki néhány vállalkozó kedvű ügyféllel, és kérdezze meg, be tudják-e olvasni a rendszereik a fájlokat.

A 11. héttől a 13. hétig: befagyasztás és üzemeltetési kézikönyv. Decemberben fagyassza be a változtatásokat. Írja le, ki a gazdája a hibasornak, hogyan kell helyesbítést kiállítani, és mi történik, ha egy ügyfél visszautasít egy számlát. A decemberi munkáról szóló januári számlák már a hatály alá tartoznak.

2027. január. Éles indulás, és az első hónapzárásig, valamint az első áfabevallásig naponta figyelje a sort.

2027 folyamán. Tervezze meg az XRechnung 4.0-ra való frissítést, mielőtt a 3.0 érvényessége lejár, és a küszöb alatti csoporttagokat is állítsa át 2028. január 1. előtt.

Ha későn kezd, az automatizálásból faragjon le, ne a kimenet érvényességéből: először a nagy volumenű számlatípusokat automatizálja, a ritka dokumentumokat pedig néhány hétig kézzel küldje ki egy e-számlázó eszközön keresztül.

Hol kaphat segítséget

Megépítjük a kapcsolatot a számláit előállító rendszer és a törvény által megkövetelt formátum között: az adatmodell módosítását, a leképezést, a validálást, a továbbítást és az archívumot, az Ön kódbázisában, a csapata mellett dolgozva. Az e-számlázási integrációs szolgáltatásunk leírja, hogyan futnak ezek a projektek; ha a kötelezettség egy ERP-csere közepére esik, nézze meg az ERP-modernizációs oldalunkat. A tágabb naptár a 2026-os uniós digitális megfelelési útmutatónkban található.

Mérnökök vagyunk, nem adótanácsadók: a hatályra vonatkozó kérdések a Steuerberaterére (német adótanácsadójára) tartoznak, mi pedig az ő válasza szerint építünk. Írja meg, mi állítja elő ma a számláit, és nagyjából hány számla megy ki havonta: írjon az office@c9group.dev címre.