Elektronische Rechnung in Ungarn

Machen Sie sich mit den ungarischen Vorschriften zur Echtzeit-Rechnungsmeldung, den Anforderungen von NAV Online Számla sowie dem geplanten Übergang zur ViDA-konformen E-Rechnungsstellung vertraut.

Jetzt kostenlos registrieren Demo anfordern

Land auswählen

Überblick

Ungarn wird regelmäßig neben Italien und Polen als Mandatsland geführt. Das ist es nicht. Ungarn betreibt eine verpflichtende Echtzeitmeldung von Rechnungsdaten über das NAV-System Online Számla – ein Regime kontinuierlicher Transaktionskontrolle, in dem die Rechnung selbst weiterhin Papier oder PDF sein darf, während ihre Daten automatisch an die Steuerverwaltung gehen.

Das ändert sich – aber noch nicht. Am 3. Juli 2026 veröffentlichte die NAV ein aktualisiertes ViDA-Umsetzungskonzept, das den künftigen Übergang zu verpflichtenden EN-16931-XML-Rechnungen, direkter API-Zustellung, nationaler Akkreditierung von Rechnungsdienstleistern und einem ausdrücklichen Fünf-Ecken-Modell beschreibt. Es ist ein Konzept: Ein rechtsverbindliches Startdatum für ein inländisches B2B-Mandat legt es nicht fest.

EAS 9910

die ungarische Umsatzsteuernummer, HU gefolgt von acht Ziffern

Meldung

kein Clearing – die NAV validiert die Daten, genehmigt aber nichts

NAV-XML

ein nationales Meldeschema, weder Peppol BIS noch UN/CEFACT CII

Zeitplan

Ungarn führte als eines der ersten EU-Länder eine Echtzeitmeldung ein – 2018. Der Anwendungsbereich wurde seither stetig ausgeweitet; das Rechnungsmandat selbst ist bislang ausgeblieben.

Bereits in Kraft

1. Juli 2018

Die Echtzeitmeldung beginnt

Zunächst nur für inländische Rechnungen mit mindestens 100.000 HUF Umsatzsteuer. Die Schwelle entfiel am 1. Juli 2020.

1. November 2019

Empfangspflicht im B2G

Ungarische öffentliche Auftraggeber müssen EN-16931-konforme E-Rechnungen für erfasste Vergaben annehmen und verarbeiten – eine Pflicht des Empfängers, nicht des Lieferanten.

4. Januar 2021

Die Meldung erfasst nahezu alles

Der Anwendungsbereich erweitert sich von inländischen Umsatzsteuerrechnungen auf praktisch jede Rechnung, auf die ungarische Rechnungsvorschriften anwendbar sind – B2C, innergemeinschaftlich und Ausfuhr eingeschlossen.

1. Juli 2025

E-Rechnung im Energiesektor

Ein gesondertes Mandat für Lieferungen von Strom und Erdgas an Nichtprivatpersonen. Die Regelung schreibt weder eine einzige verbindliche Syntax noch einen einzigen Austauschkanal vor.

3. Juli 2026

Die NAV veröffentlicht das aktualisierte ViDA-Konzept

Nach einer öffentlichen Konsultation von November 2025 bis Januar 2026 und einer früheren Fassung im März legt die NAV die beabsichtigte künftige Architektur dar. Siehe das ViDA-Konzept der NAV.

Noch bevorstehend

1. September 2026

Allgemeine Meldepflicht für Belege

Handschriftliche und computererstellte Belege, deren Daten nicht automatisch über eine Online- oder E-Registrierkasse übermittelt werden, sind der NAV binnen drei Kalendertagen zu melden – tagesweise und nach Steuersätzen aggregiert.

1. Juli 2030

ViDA für innergemeinschaftliches B2B

EU-weite digitale Meldung für grenzüberschreitende B2B-Umsätze auf Basis verpflichtender E-Rechnungen. Das ist ein grenzüberschreitendes Datum – kein ungarisches Inlandsmandat.

Bis 1. Januar 2035

Angleichung des nationalen Systems

Nationale Systeme der Echtzeit-Transaktionsmeldung sind an Modell und Standards der EU anzugleichen.

Lesen Sie den 1. Juli 2030 nicht als Beginn eines ungarischen inländischen B2B-Mandats. Die NAV hat dafür kein Startdatum angekündigt. Das Länderfactsheet der Europäischen Kommission verzeichnet für Ungarn weiterhin kein allgemeines B2G-Lieferanten-, B2B- oder B2C-Mandat.

Das RTIR-Modell

Das System ist ein zentrales Echtzeit-Meldemodell, und sein prägendes Merkmal ist die Trennung zweier Flüsse. Die Rechnung erreicht den Käufer über den vereinbarten Kanal; die Rechnungsdaten gehen automatisch und unmittelbar an die NAV.

Zwei parallele Flüsse

Verkäufer → Käufer

Rechnungssoftware des Verkäufers → NAV Online Számla

Wird Rechnungssoftware eingesetzt, muss die Übermittlung automatisch und unmittelbar ohne menschliches Zutun erfolgen. Die NAV empfängt das XML, führt technische und Konsistenzprüfungen durch und gibt ein Verarbeitungsergebnis zurück. Was sie nicht tut: die Rechnung genehmigen. Die NAV erteilt keine Vorabfreigabe, und Ausstellung und Meldung sind rechtlich getrennte Vorgänge.

Was es ist – und was nicht

Zentrale kontinuierliche Transaktionskontrolle mit Echtzeitmeldung der Rechnungsdaten

Kein Clearing-Modell – nichts muss genehmigt werden, damit die Rechnung gültig ist

Kein Peppol-Vier-Ecken-Modell – und noch kein Fünf-Ecken-Modell

Die Meldepflicht knüpft an die Rechnung an, unabhängig davon, wie das Geschäftsdokument den Käufer erreicht hat – als PDF, als XML oder auf Papier –, sofern die Rechnung in den ungarischen Meldebereich fällt.

B2G

Ungarn kennt ein Empfänger-, kein Lieferantenmandat. Seit dem 1. November 2019 müssen öffentliche Stellen strukturierte, EN-16931-konforme E-Rechnungen für Vergaben oberhalb der geltenden EU-Schwellenwerte annehmen und verarbeiten können. Eine allgemeine Pflicht, dass jeder Lieferant seine B2G-Rechnung elektronisch ausstellt, besteht nicht.

Zutreffend formuliert: verpflichtende Empfangsfähigkeit ohne verpflichtende elektronische Ausstellung durch Lieferanten. Verlangt ein ungarischer öffentlicher Kunde eine EN-16931-Rechnung, nutzt er eine Fähigkeit, die das Gesetz ihm vorschreibt – er setzt keine Pflicht Ihrerseits durch.

Die NAV-Meldung läuft davon unberührt parallel: Eine B2G-Rechnung im ungarischen Meldebereich ist wie jede andere zu melden. Nach dem künftigen Konzept würden Umsätze zwischen Unternehmen und öffentlichen Einrichtungen in die einheitliche strukturierte Rechnungsarchitektur aufgehen – die B2G-spezifischen Ausführungsregeln und der Starttermin bleiben jedoch künftiger Gesetzgebung vorbehalten.

B2B und B2C heute

Ein allgemeines inländisches B2B-E-Rechnungsmandat gibt es nicht. Ein ungarischer Lieferant stellt eine Rechnung aus – auf Papier oder elektronisch – und beim Einsatz von Rechnungssoftware erreichen die Daten die NAV automatisch. Der Käufer erhält die Rechnung über den vereinbarten geschäftlichen Kanal. Peppol ist nicht erforderlich.

B2C und Belege

Auch ein allgemeines B2C-E-Rechnungsmandat besteht nicht. Stellt ein Unternehmen eine Rechnung aus, können deren Daten in den NAV-Meldebereich fallen. Der Einzelhandel läuft über eine eigene Compliance-Ebene rund um Belege, Online-Registrierkassen und die E-Beleg-Infrastruktur.

Ab dem 1. September 2026 weitet sich diese Ebene aus: Handschriftliche und computererstellte Belege, deren Daten nicht automatisch übermittelt werden, sind binnen drei Kalendertagen zu melden – tagesweise und nach Steuersätzen aggregiert. Die NAV stellt dafür eine kostenlose mobile und Desktop-Anwendung bereit, die den Beleg ausstellt und die Meldung automatisch übernimmt – die praktische Antwort für Betriebe, die bislang mit handschriftlichen Belegblöcken gearbeitet haben.

Strom und Erdgas

Das einzige echte Branchenmandat. Seit dem 1. Juli 2025 sind elektronische Rechnungen für bestimmte Lieferungen von Strom und Erdgas an nichtprivate Empfänger verpflichtend. Bemerkenswert: Die Regelung schreibt weder eine einzige verbindliche strukturierte Syntax noch einen einzigen Austauschkanal vor – „elektronisch“ ist hier also weiter gefasst als „EN-16931-XML“.

Grenzüberschreitend

Ungarischer Lieferant → EU-KäuferKeine allgemeine E-Rechnungspflicht. Die Meldung greift bereits, soweit ungarische Rechnungsvorschriften anwendbar sind. Ab 1. Juli 2030 führt ViDA die verpflichtende E-Rechnung als Grundlage der grenzüberschreitenden Meldung ein

EU-Lieferant → ungarischer KäuferDie Rechnung eines ausländischen Lieferanten wird nicht zur ungarischen Inlandsrechnung. Die NAV erkennt Rechnungen EU-ansässiger Steuerpflichtiger nach dem Recht eines anderen Mitgliedstaats gesondert an

Ausfuhr in ein DrittlandKein E-Rechnungsmandat. Rechnungsdaten können dennoch in den NAV-Meldebereich fallen, soweit ungarische Rechnungsvorschriften anwendbar sind – die Erweiterung 2021 erfasste auch ausfuhrbezogene Rechnungen

Nach dem Konzept würde die Ausstellungsfrist bei innergemeinschaftlichen Umsätzen zehn Tage nach der Leistung betragen, während die derzeitige Achttagesfrist im Inland voraussichtlich bestehen bleibt.

Das ViDA-Konzept der NAV

Das am 3. Juli 2026 veröffentlichte Konzept ist eines der architektonisch interessantesten Dokumente, die zuletzt aus einer europäischen Steuerverwaltung gekommen sind – und es sollte als Richtungsaussage gelesen werden, nicht als Fristenkatalog.

Es handelt sich um ein Konzept, und die NAV bezeichnet es auch so. Es begründet kein Startdatum für ein inländisches B2B-Mandat, und ein solches wurde nicht angekündigt. Alles Folgende beschreibt beabsichtigte Architektur, keine geltende Pflicht.

Die fünf Ecken

1Der steuerpflichtige Verkäufer

2Die Rechnungssoftware oder der Rechnungsdienstleister des Verkäufers

3Der steuerpflichtige Käufer

4Das Buchhaltungssystem oder der Dienstleister des Käufers

5Die Steuerverwaltung, die NAV

Eine optionale sechste Ecke ist zugelassen – ein zusätzlicher Akteur, der Rechnungsdaten an die Steuerverwaltung übermittelt. Der Einsatz eines Dienstleisters ist nicht verpflichtend: Verkäufer und Käufer dürfen eigene Software nutzen.

Weiterhin kein Clearing

Die NAV formuliert den Grundsatz klar: Rechnungsstellung und Datenlieferung bleiben getrennt, und die Erfüllung der Datenlieferung ist keine Voraussetzung für die Ausstellung der Rechnung. Anspruchsvoll ist die Architektur dennoch – die Rechnungssoftware müsste die Rechnung vorvalidieren, die Pflichtangaben prüfen, die inländische Steuernummer prüfen, die Datenstruktur prüfen und bei technischen Fehlern die Erstellung oder Ausstellung blockieren.

Die richtige Einordnung lautet daher: Fünf-Ecken-CTC mit nahezu Echtzeit-Meldung, aber ohne behördliche Genehmigung als konstitutive Voraussetzung der Ausstellung. Das ist ein echter Unterschied zum italienischen SdI-Modell.

Meldung durch den Käufer

Ungarn erwägt etwas, das ViDA selbst nicht verlangt: eine Meldung durch den Käufer. Nach dem Konzept soll er eine erhaltene inländische oder innergemeinschaftliche Rechnung binnen fünf Tagen melden – im Inland die vollständige Rechnung, bei innergemeinschaftlichen Umsätzen möglicherweise einen reduzierten Datensatz. Die NAV weist ausdrücklich darauf hin, dass dieser Punkt weiterer Prüfung bedarf; er ist also noch in Diskussion.

Was sich inhaltlich ändern würde

—Die Rechnung wird zu einem maschinell verarbeitbaren Datenobjekt nach EN 16931, mit den von der Norm erlaubten ungarischen Ergänzungen

—Strukturierte Rechnungsdaten würden für jede Rechnung erzeugt, selbst wenn der Käufer eine Papierdarstellung erhält

—Für die inländische Datenlieferung erhielte die NAV die vollständige Rechnung, nicht eine Auswahl umsatzsteuerlicher Felder

—Die heutige Online-Számla-Datenstruktur würde nicht einfach auf die europäische Norm gehoben – vorgesehen ist eine neue EN-16931-basierte Struktur samt Mapping zwischen dem Altschema und dem künftigen

Das Konzept lehnt das hybride Szenario ausdrücklich ab, in dem ein PDF die Rechnung ist und ein XML-Anhang nur die Mindestpflichtangaben trägt. Im künftigen Modell ist das XML die maßgebliche Rechnung; ein menschenlesbares PDF oder Bild ist eine visuelle Darstellung, und bei Abweichungen gilt das XML. Für Privatpersonen wäre eine visuelle Fassung verpflichtend; im B2B könnten die Parteien entscheiden, ob sie eine benötigen.

Formate und PDF

Das häufigste Missverständnis zu Ungarn ist die Annahme, eine Peppol-BIS-Rechnung erfülle die Meldepflicht. Das tut sie nicht – es handelt sich um zwei verschiedene Objekte.

NAV-Online-Számla-XML

Ein NAV-spezifisches XML- und XSD-Schema – eine Meldedatenstruktur. Das erwartet die API.

EN 16931 – UBL oder CII

Rechtlich relevant für den B2G-Empfang. Nicht das Meldeschema und kein verpflichtendes Rechnungsformat für inländisches B2B oder B2C.

Eine Peppol-BIS-UBL-Rechnung ist keine NAV-Online-Számla-Meldung. Im heutigen System ist zwischen beiden in der Regel eine eigene Transformations- und Mappingschicht nötig.

Ist ein PDF zulässig?

Ja – nach den heute geltenden Regeln. Die NAV stellt fest, dass eine Rechnung papierbasiert oder elektronisch sein kann, und definiert die elektronische Rechnung als eine in beliebigem elektronischen Format ausgestellte und empfangene Rechnung mit den Pflichtangaben des Umsatzsteuergesetzes. Eine nur per E-Mail versandte Rechnung kann darunterfallen; die NAV nennt sogar eine gescannte Papierrechnung als Beispiel.

—Die elektronische Rechnungsstellung setzt die Zustimmung des Empfängers voraus, ausdrücklich oder konkludent – eine Zahlung kann genügen

—EDI erfordert eine vorherige schriftliche Vereinbarung

—Eine elektronische Rechnung ist elektronisch aufzubewahren

Heute kann ein PDF also eine rechtsgültige elektronische Rechnung sein – ohne eine strukturierte EN-16931-Rechnung zu sein. Zwei verschiedene Kategorien, die man in Verträgen und Systemspezifikationen auseinanderhalten sollte.

Peppol in Ungarn

Peppol ist kein verpflichtender nationaler Transportkanal – weder heute noch im Konzept. Die NAV hält fest, dass die Rechnungsstellung über Peppol für Unternehmen eine Option und keine Pflicht sein wird, dass Ungarn keinen verbindlichen Peppol-Dienstleister benennen will und dass die NAV weder ihr eigenes System an Peppol anbinden noch einen staatlichen Peppol-Rechnungsdienst anbieten wird.

Transport und Meldung bleiben getrennt

Eine Übermittlung über Peppol erfüllt die ungarische steuerliche Meldepflicht nicht, wenn nationale Regeln daneben eine NAV-Datenlieferung verlangen. Zwei Funktionen, zwei Umsetzungen.

Peppol Authority

Ungarn erscheint derzeit nicht in der OpenPeppol-Liste nationaler Peppol Authorities. In Jurisdiktionen ohne eigene Authority übernimmt die Peppol Coordinating Authority diese Rolle, und ein dort ansässiger Dienstleister schließt sein Service Provider Agreement mit OpenPeppol. Das Konzept sieht die Einrichtung einer ungarischen Peppol Authority vor, die dann Hungary-spezifische Anforderungen definieren würde.

Eine Unstimmigkeit sollte man kennen: Das Konzept besagt, ungarische Dienstleister könnten ohne eine ungarische Peppol Authority Peppol nicht beitreten – die aktuelle OpenPeppol-Liste zertifizierter Dienstleister enthält jedoch bereits einen ungarischen Eintrag, zertifiziert unter OpenPeppol. Die Formulierung des Konzepts beschreibt daher eher die künftige nationale Governance als die heutige Peppol-Mitgliedschaftspraxis.

Kennungen

Das für Ungarn bestätigte länderspezifische Schema ist EAS 9910 – HU:VAT, die ungarische Umsatzsteuernummer in der Form HU plus acht Ziffern, mit Status „aktiv“. Ein ungarischer Teilnehmer kann also etwa als 9910:HU12345678 registriert werden. Das internationale Schema 9913 (EU:REID) existiert in der Codeliste, ist aber keine ungarische nationale Unternehmenskennung; ein gesondertes ungarisches Handelsregister-EAS wurde nicht festgestellt.

Anforderungen an Anbieter

Heute verlangt Ungarn von Access Points keine zusätzliche nationale Akkreditierung. Ein Gegenstück zum slowakischen digitálny poštár gibt es nicht, ebenso wenig eine Anforderung an eine ungarische juristische Person, ein offizielles elektronisches Postfach oder einen lokalen Vertreter – und ein zertifizierter EU-Access-Point kann ungarische Teilnehmer im freiwilligen Peppol-Modell bedienen.

Was das Konzept ergänzen würde

Eine nationale Akkreditierung von Rechnungsverfahren und Dienstleistern, vorgesehen als Selbstbedienungsverfahren ohne detaillierte IT-Prüfung. Software oder Dienst müssten einen technischen Test gegen XML-Dateien der NAV bestehen und nachweisen, dass sie:

—eine korrekte Rechnung erzeugen

—eine identische Datenlieferung erzeugen

—die verpflichtende Vorvalidierung durchführen

—eine Rechnung blockieren, die den technischen und inhaltlichen Anforderungen nicht genügt

Vorabakkreditierung

Verpflichtend für Rechnungsdienstleister. Ein Steuerpflichtiger, der einen akkreditierten Dienstleister nutzt, müsste sich für Ausstellung und Datenlieferung nicht selbst akkreditieren lassen.

Akkreditierung des Steuerpflichtigen

Erforderlich, wenn der Steuerpflichtige eigene Rechnungssoftware nutzt – für sein eigenes operatives Verfahren, unabhängig davon, ob der Softwarehersteller gesondert akkreditiert wurde.

Eine öffentliche Positivliste ist vorgesehen. Über nicht akkreditierte Software oder ein nicht akkreditiertes Verfahren übermittelte Daten blieben bis zu 30 Tage im Status „ausstehend“; die Rechnung könnte gleichwohl ausgestellt werden, doch bei nicht abgeschlossener Akkreditierung innerhalb dieser Frist droht dem Steuerpflichtigen eine Sanktion.

Was das für einen ausländischen Access Point bedeutet

Die Peppol-Zertifizierung allein würde wahrscheinlich nicht genügen, wenn ein ausländischer Anbieter zugleich als ungarischer Rechnungsdienstleister auftritt und den gesetzlichen Ausstellungs- und Meldeprozess ausführt – für diese Rolle verlangt das Konzept eine Vorabakkreditierung.

Nicht beantwortet lässt das Konzept, ob ein ausländischer EU-Anbieter ohne ungarische Niederlassung akkreditiert werden könnte, seine heimische juristische Person nutzen dürfte oder eine Zweigniederlassung beziehungsweise einen lokalen Vertreter bräuchte. Eine Anforderung an lokale Präsenz ist nicht formuliert – aber auch nicht ausgeschlossen. Behandeln Sie Peppol-Zertifizierung und ungarische Anbieterakkreditierung als zwei potenziell unabhängige Compliance-Ebenen.

Ressourcen für Entwickler

Technisch ist Ungarn ungewöhnlich offen, und eine Integration lässt sich vollständig testen, bevor sie die Produktion berührt. Die NAV unterhält ein öffentliches GitHub-Repository für die Machine-to-Machine-Schnittstelle von Online Számla mit Schemadefinitionen und XML-Beispieldateien sowie eine vollständige Testumgebung.

Test-Frontendonlineszamla-test.nav.gov.hu

Test-APIapi-test.onlineszamla.nav.gov.hu

Produktiv-Frontendonlineszamla.nav.gov.hu

Produktiv-APIapi.onlineszamla.nav.gov.hu

Die aktuelle Schnittstellenspezifikation ist Version 3.0. Die NAV führt zudem ein Entwicklertagebuch zu Schnittstellenänderungen und nimmt über das Repository Kommentare zu veröffentlichten und geplanten XSD-Versionen entgegen – auch außerhalb formeller Konsultationsphasen. Sämtliche von der NAV veröffentlichten Inhalte liegen neben Ungarisch auch auf Englisch vor, und Beiträge werden in beiden Sprachen angenommen. Die Links stehen unter Ressourcen.

Aufbewahrung

Nach dem ungarischen Rechnungslegungsgesetz sind Buchungsbelege mindestens acht Jahre in lesbarer Form aufzubewahren und müssen jederzeit wiederherstellbar sein. Rechnungen sind Buchungsbelege.

Eine elektronisch ausgestellte oder empfangene Rechnung ist elektronisch aufzubewahren – sie auszudrucken und das Papier abzulegen, genügt nicht

Echtheit der Herkunft, Unversehrtheit des Inhalts und Lesbarkeit sind durchgehend zu gewährleisten – die NAV akzeptiert dafür unter anderem innerbetriebliche Kontrollverfahren mit verlässlichem Prüfpfad

Das NAV-System Online Számla ist ein Meldesystem, nicht Ihr Archiv – die Aufbewahrung bleibt beim Steuerpflichtigen

Die Unterscheidung wiegt in Ungarn schwerer als anderswo, weil Rechnung und Meldung verschiedene Artefakte sind. Die NAV-Übermittlung aufzubewahren erfüllt nicht die Pflicht, die Rechnung aufzubewahren – und ein PDF der Rechnung belegt nicht, was gemeldet wurde.

Sanktionen

Das ungarische Sanktionsdesign hat eine Besonderheit, die systematische Fehler weit gefährlicher macht als Einzelfälle: Die gesetzliche Obergrenze skaliert mit der Zahl der betroffenen Rechnungen.

500.000 HUFAllgemeine Höchstgrenze des Verspätungsbußgelds für nicht natürliche Personen, einschließlich gewöhnlicher Gesellschaften, nach der Abgabenordnung

200.000 HUFDieselbe Obergrenze für natürliche Personen

× betroffene RechnungenBei Verstößen gegen die Rechnungsmeldepflicht – Unterlassen, verspätete Übermittlung, unvollständige, fehlerhafte oder falsche Daten – gilt als Sondergrenze das allgemeine Höchstmaß multipliziert mit der Zahl der betroffenen Rechnungen oder rechnungsgleichen Belege

Bis zu 1 Mio. HUFFür die Verletzung der Pflicht zur Ausstellung von Rechnungen oder Belegen oder für eine Ausstellung, die nicht dem tatsächlichen Entgelt entspricht

Hinter diesen Zahlen stehen drei verschiedene Tatbestände, die man nicht vermengen sollte: ein Verstoß gegen die Rechnungsausstellung, ein Verstoß gegen die NAV-Meldung und – künftig – ein Verstoß gegen die strukturierte E-Rechnung. Nach dem Konzept blieben Daten aus nicht akkreditierter Software 30 Tage ausstehend, und bei nicht abgeschlossener Akkreditierung könnte eine Sanktion folgen; ein neuer Tarif wurde jedoch nicht festgelegt, sodass jede Zahl dazu verfrüht wäre.

Ist die E-Rechnung die einzige Grundlage für den Vorsteuerabzug?

Nein. Die NAV hält fest, dass eine Rechnung elektronisch oder auf Papier ausgestellt werden kann, und eine Rechnung kann nach dem Umsatzsteuergesetz materielle Voraussetzung des Vorsteuerabzugs sein. Das geltende Recht verlangt nicht, dass die den Abzug tragende Rechnung eine E-Rechnung ist – die rechtmäßige Papierrechnung existiert weiterhin. Maßgeblich sind die Anforderungen des Umsatzsteuergesetzes, Echtheit der Herkunft, Unversehrtheit des Inhalts, Lesbarkeit und der Bezug zu einer tatsächlichen Leistung.

Das Konzept würde das XML zur offiziellen und authentischen Rechnung machen, der die menschenlesbare Fassung nachgeordnet ist. Es begründet jedoch nicht, dass die Annahme durch die NAV konstitutive Voraussetzung des Abzugs wäre – im Gegenteil hält es am Grundsatz fest, dass die Datenlieferung keine Voraussetzung der Rechnungsausstellung ist. Das künftige ungarische Modell als „kein Clearing, keine gültige Rechnung, kein Abzug“ zu beschreiben, ginge über das hinaus, was das veröffentlichte Konzept sagt.

Wie wir Sie unterstützen

Ungarn verlangt, Meldeebene und Austauschebene als getrennte Aufgaben zu behandeln – genau so bauen wir es:

Austausch über Peppol BIS Billing 3.0 mit ungarischen und europäischen Partnern über einen zertifizierten Access Point

Adressierung über EAS 9910 mit der ungarischen Umsatzsteuernummer

Mapping zwischen EN-16931-Rechnungsdaten und dem Meldeschema von NAV Online Számla

EN-16931-Rechnungen für ungarische öffentliche Auftraggeber, die ihre Empfangsfähigkeit nutzen

Validierung gegen EN 16931 vor dem Versand, mit nachvollziehbaren Status- und Fehlermeldungen

Anbindung über API, SFTP und CSV, mit ERP- und IDoc-Quelldaten

Eine Architektur, die das Fünf-Ecken-Modell des Konzepts aufnehmen kann, sobald es Gesetz wird

Häufige Fragen

Ist die E-Rechnung in Ungarn verpflichtend?

Nein – abgesehen von bestimmten Strom- und Erdgaslieferungen an Nichtprivatpersonen seit dem 1. Juli 2025. Verpflichtend ist die Echtzeitmeldung der Rechnungsdaten an die NAV. Die Rechnung selbst darf weiterhin Papier oder PDF sein. Das Länderfactsheet der Europäischen Kommission verzeichnet für Ungarn kein allgemeines B2G-Lieferanten-, B2B- oder B2C-Mandat, und die NAV hat kein Startdatum angekündigt.

Erfüllt der Versand über Peppol die ungarische Pflicht?

Nein. Peppol-Transport und NAV-Meldung sind getrennte Funktionen. Eine Übermittlung über Peppol erfüllt die steuerliche Meldepflicht nicht, wenn nationale Regeln daneben eine NAV-Datenlieferung verlangen. Eine Peppol-BIS-UBL-Rechnung ist zudem keine NAV-Online-Számla-Meldung – das Meldeschema ist ein NAV-spezifisches XML/XSD, sodass zwischen beiden in der Regel eine Transformationsschicht nötig ist.

Darf ich weiterhin per PDF fakturieren?

Ja, nach den geltenden Regeln. Die NAV definiert die elektronische Rechnung als eine in beliebigem elektronischen Format ausgestellte und empfangene Rechnung mit den Pflichtangaben des Umsatzsteuergesetzes; eine nur per E-Mail versandte Rechnung kann darunterfallen. Erforderlich ist die Zustimmung des Empfängers, ausdrücklich oder konkludent – eine Zahlung kann genügen –, und EDI braucht eine vorherige schriftliche Vereinbarung. Die elektronische Rechnung ist dann elektronisch aufzubewahren. Beachten Sie: Eine gültige PDF-Rechnung ist gleichwohl keine strukturierte EN-16931-Rechnung; das künftige Konzept würde das beenden und das XML zur maßgeblichen Rechnung machen.

Muss ich B2G-Rechnungen elektronisch senden?

Eine allgemeine Lieferantenpflicht besteht nicht. Seit dem 1. November 2019 müssen ungarische öffentliche Auftraggeber EN-16931-konforme E-Rechnungen für erfasste Vergaben annehmen und verarbeiten können – das ist ein Empfängermandat. Verlangt ein öffentlicher Käufer eine EN-16931-Rechnung, nutzt er eine gesetzlich vorgeschriebene Fähigkeit. Die NAV-Meldung gilt für die Rechnung parallel wie üblich.

Was ist das Fünf-Ecken-Modell, und wann startet es?

Es ist die Architektur, die die NAV in ihrem ViDA-Umsetzungskonzept vom 3. Juli 2026 dargelegt hat: Verkäufer, dessen Software oder Dienstleister, Käufer, dessen System oder Dienstleister sowie die Steuerverwaltung – mit einer optionalen sechsten Ecke für eine Stelle, die Daten an die NAV übermittelt. Ein Dienstleister wäre nicht verpflichtend. Ein Startdatum gibt es nicht: Das Dokument ist ein Konzept und legt keines fest. Der ViDA-Termin 1. Juli 2030 betrifft grenzüberschreitendes innergemeinschaftliches B2B, nicht die ungarische Inlandsfakturierung.

Kann ein ausländischer Peppol Access Point ungarische Kunden bedienen?

Heute ja. Es wurde keine ungarische Regel festgestellt, die einen zertifizierten EU-Access-Point daran hindert, einem ungarischen Endnutzer freiwillige Peppol-Dienste anzubieten; eine ungarische juristische Person, ein Postfach oder ein lokaler Vertreter sind nicht erforderlich. Ungarn hat keine nationale Peppol Authority, sodass dort ansässige Anbieter mit OpenPeppol kontrahieren. Nach dem künftigen Konzept könnte sich das ändern: Für Rechnungsdienstleister wäre eine Vorabakkreditierung verpflichtend, und das Konzept sagt nicht, ob ein ausländischer Anbieter ohne ungarische Niederlassung akkreditiert werden könnte.

Welche Sanktionen drohen bei Meldeverstößen?

Die allgemeine Obergrenze beträgt 500.000 HUF für Gesellschaften und 200.000 HUF für natürliche Personen. Bei Verstößen gegen die Rechnungsmeldepflicht gilt als Sondergrenze dieses Höchstmaß multipliziert mit der Zahl der betroffenen Rechnungen – ein systematischer Fehler ist damit erheblich gravierender als ein Einzelfall. Gesondert steht die Verletzung der Pflicht zur Ausstellung von Rechnungen oder Belegen mit bis zu 1 Mio. HUF im Raum. Ausstellungsverstöße, Meldeverstöße und künftige Verstöße gegen die strukturierte Rechnung sind eigenständige Tatbestände.

Kann ich eine Integration vor dem Produktivstart testen?

Ja, und Ungarn macht es einfacher als die meisten Länder. Die NAV betreibt eine vollständige Testumgebung mit eigenem Frontend und eigener API und unterhält ein öffentliches GitHub-Repository mit den Schemadefinitionen und XML-Beispieldateien für die Machine-to-Machine-Schnittstelle. Die aktuelle Schnittstellenspezifikation ist Version 3.0, und die NAV führt ein Entwicklertagebuch zu Schnittstellenänderungen. Alle von der NAV veröffentlichten Inhalte liegen auch auf Englisch vor.

Zusammenfassung

Ungarn sollte heute nicht als Mandatsland neben Italien oder Polen eingeordnet werden. Es betreibt eine verpflichtende Echtzeitmeldung von Rechnungsdaten über NAV Online Számla, mit einem NAV-spezifischen XML-Schema, ohne Clearing, ohne Peppol-Pflicht – und mit dem PDF als weiterhin gültiger elektronischer Rechnung, sofern der Empfänger zustimmt.

Die Richtung ist klar und wirklich interessant: Das NAV-Konzept vom Juli 2026 beschreibt den Übergang von „die Rechnungsdaten melden“ zu „die strukturierte XML-Rechnung ist selbst das maßgebliche Objekt, das Verkäufer, Käufer und Steuerverwaltung teilen“ – ein Fünf-Ecken-CTC mit optionaler Peppol-Interoperabilität und nationaler Akkreditierung von Rechnungsdienstleistern. Was es nicht beschreibt, ist ein Datum.

Das Risiko liegt eher auf Anbieter- als auf Steuerpflichtigenseite: Die Peppol-Zertifizierung wird die geplante ungarische Anbieterakkreditierung voraussichtlich nicht ersetzen, wenn ein Anbieter gesetzliche Ausstellungs- und Meldefunktionen übernimmt. Eine Anforderung an lokale Präsenz ist nicht formuliert – aber auch nicht ausgeschlossen.

Ressourcen

NAV Online Számla – das Produktivsystem Registrierung, Meldung der Rechnungsdaten und die kostenlose Rechnungsanwendung der NAV NAV auf GitHub – Repository Online Invoice Offizielle XSD-Schemadefinitionen und XML-Beispiele für die M2M-Schnittstelle, mit allen vier Umgebungs-URLs NAV – Entwicklerdokumentation Die Schnittstellenspezifikation von Online Számla, aktuell Version 3.0 NAV – Entwicklertagebuch Schnittstellenänderungen und geplante XSD-Versionen – vor einem Integrationsprojekt lohnt das Abonnement NAV – Testumgebung Den gesamten Meldeablauf testen, bevor die Produktion berührt wird NAV – die ungarische Steuer- und Zollverwaltung Leitfäden zu Rechnungsstellung und Umsatzsteuer, Informationsbroschüren und das ViDA-Umsetzungskonzept

Benötigen Sie Unterstützung bei der E-Rechnungspflicht?

Als zertifizierter Peppol Access Point bieten wir Lösungen für den sicheren Versand und Empfang elektronischer Rechnungen in ganz Europa – inklusive Formatkonvertierung, Validierung und Integration in nationale Systeme.

Jetzt kostenlos testen