Electronic invoice in Hungary

Understand Hungary’s real-time invoice reporting rules, NAV Online Számla requirements and the planned transition towards ViDA-compliant e-invoicing.

Select a country

Overview

Hungary is regularly filed alongside Italy and Poland as a mandate country. It is not one. What Hungary operates is mandatory real-time invoice data reporting through the NAV Online Számla system — a continuous transaction control regime in which the invoice itself may still be paper or a PDF, while its data goes to the tax authority automatically.

That is changing, but not yet. On 3 July 2026 NAV published an updated ViDA implementation concept describing a future move to mandatory EN 16931 XML invoices, direct API delivery, national accreditation of invoicing providers and an explicit five-corner model. It is a concept: it sets no legally binding start date for a domestic B2B mandate.

EAS 9910

the Hungarian VAT number, HU followed by eight digits

Reporting

not clearance — NAV validates the data but authorises nothing

NAV XML

a national reporting schema, not Peppol BIS or UN/CEFACT CII

Timeline

Hungary was one of the first EU countries to put real-time reporting in place, in 2018. The scope has widened steadily since; the invoicing mandate itself has not arrived.

Already in force

1 July 2018

Real-time invoice reporting begins

Initially only domestic invoices with VAT of at least HUF 100,000. The threshold was removed on 1 July 2020.

1 November 2019

B2G receiving obligation

Hungarian contracting authorities must accept and process EN 16931 compliant e-invoices for covered public procurement — a duty on the receiver, not the supplier.

4 January 2021

Reporting extends to almost everything

The scope widens from domestic VAT invoices to essentially every invoice to which Hungarian invoicing rules apply — B2C, intra-EU and export included.

1 July 2025

Energy sector e-invoicing

A separate mandate for supplies of electricity and natural gas to non-private persons. The legislation prescribes no single mandatory syntax or exchange channel.

3 July 2026

NAV publishes the updated ViDA concept

Following a public consultation that ran from November 2025 to January 2026 and an earlier version in March, NAV sets out the intended future architecture. See the NAV ViDA concept.

Ahead

1 September 2026

General receipt data reporting

Manual and computer-generated receipts whose data is not transmitted automatically by an online or e-cash register must be reported to NAV within three calendar days, aggregated daily and by VAT rate.

1 July 2030

ViDA for intra-EU B2B

EU-wide digital reporting for cross-border B2B, based on mandatory e-invoicing. This is a cross-border date — not a Hungarian domestic mandate date.

By 1 January 2035

Alignment of the national system

National real-time transaction reporting systems must be brought into line with the EU model and standards.

Do not read 1 July 2030 as the start of a Hungarian domestic B2B mandate. NAV has announced no go-live date for one. The European Commission's country factsheet still records no general B2G supplier, B2B or B2C e-invoice mandate for Hungary.

The RTIR model

The system is a centralised real-time reporting model, and its defining feature is that the two flows are separate. The invoice goes to the buyer by whatever channel the parties agreed; the invoice data goes to NAV automatically and immediately.

Two parallel flows

Seller → buyer

Seller's invoicing software → NAV Online Számla

Where invoicing software is used, transmission must be automatic and immediate, without human intervention. NAV receives the XML, performs technical and consistency validation and returns a processing result. What it does not do is authorise the invoice: NAV issues no prior approval, and issuance and reporting are legally separate processes.

What this is, and is not

Centralised continuous transaction control with real-time invoice data reporting

Not a clearance model — nothing has to be approved before the invoice is valid

Not a Peppol four-corner model, and not yet a five-corner one

The reporting obligation attaches to the invoice regardless of how the business document reached the buyer — as PDF, as XML or on paper — provided the invoice falls within Hungarian reporting scope.

B2G

Hungary has a receiver mandate, not a supplier mandate. Since 1 November 2019 public sector entities must be able to accept and process structured EN 16931 compliant e-invoices for public procurement contracts above the applicable EU thresholds. No general obligation requires every supplier to issue its B2G invoice electronically.

The accurate formulation is mandatory receiving capability, without mandatory electronic issuance by suppliers. If a Hungarian public buyer asks you for an EN 16931 invoice, it is exercising a capability the law obliges it to have — not enforcing a duty on you.

NAV reporting runs in parallel and is unaffected: a B2G invoice within Hungarian reporting scope still has to be reported like any other. Under the future concept, transactions between companies and public institutions would be absorbed into the unified structured invoicing architecture — but the B2G-specific implementing rules and start date remain for future legislation.

B2B and B2C today

There is no general domestic B2B e-invoicing mandate. A Hungarian supplier issues an invoice — on paper or electronically — and, where invoicing software is used, the data reaches NAV automatically. The buyer receives the invoice through whatever business channel the parties agreed. Peppol is not required.

B2C and receipts

No general B2C e-invoice mandate exists either. Where a company does issue an invoice, its data may fall within NAV reporting scope. Retail runs on a separate compliance layer built around receipts, online cash registers and the e-receipt infrastructure.

From 1 September 2026 that layer widens: manual and computer-generated receipts whose data is not transmitted automatically must be reported within three calendar days, aggregated daily and by VAT rate. NAV provides a free mobile and desktop application that issues the receipt and performs the reporting automatically — the practical answer for businesses that until now worked with handwritten receipt books.

Electricity and natural gas

The one genuine sector mandate. Since 1 July 2025, electronic invoices are compulsory for certain supplies of electricity and natural gas to non-private recipients. Notably, the legislation does not prescribe a single mandatory structured syntax or a single exchange channel — so "electronic" here is broader than "EN 16931 XML".

Cross-border

Hungarian supplier → EU buyerNo universal e-invoice obligation. Reporting already applies where Hungarian invoicing rules do. From 1 July 2030, ViDA introduces mandatory e-invoicing as the basis for cross-border digital reporting

EU supplier → Hungarian buyerA foreign supplier's invoice does not become a Hungarian domestic invoice. NAV separately recognises invoices issued by EU-established taxable persons under the law of another member state

Export to a third countryNo e-invoice mandate. Invoice data may still fall within NAV reporting scope where Hungarian invoicing rules apply — the 2021 expansion covered export-related invoices too

Under the concept, the invoice issuance deadline would become ten days after performance for Community transactions, while the current eight-day domestic deadline is expected to remain.

The NAV ViDA concept

The concept published on 3 July 2026 is the most interesting architectural document to come out of a European tax authority recently — and it is worth reading as a statement of direction rather than a set of deadlines.

This is a concept, and NAV describes it as one. It does not establish a start date for a domestic B2B mandate, and none has been announced. Everything below describes intended architecture, not current obligation.

The five corners

1The taxable seller

2The seller's invoicing software or invoicing service provider

3The taxable buyer

4The buyer's accounting system or service provider

5The tax authority, NAV

An optional sixth corner is allowed — an additional actor transmitting invoice data to the tax authority. Using a service provider is not compulsory: seller and buyer may use their own software.

Still not clearance

NAV states the principle plainly: invoicing and data supply remain separated, and performance of the data supply is not a condition of issuing the invoice. The architecture is nonetheless demanding — invoicing software would have to pre-validate the invoice, check the mandatory data, check the domestic tax number, check the data structure and block creation or issuance where technical errors exist.

The right label is therefore a five-corner CTC with near-real-time automated reporting, but without tax-authority authorisation as a constitutive condition of issuance. That is a real difference from the Italian SdI model.

Buyer-side reporting

Hungary is considering something ViDA does not itself require: reporting by the buyer. The concept has the buyer reporting a received domestic or Community invoice within five days — the full invoice for domestic transactions, potentially a reduced data set for Community ones. NAV notes explicitly that this element needs further work, so treat it as under discussion.

What would change in substance

—The invoice becomes a machine-processable data object conforming to EN 16931, with Hungarian additions permitted by the standard

—Structured invoice data would be created for every invoice, even where the buyer receives a paper representation

—For domestic data supply NAV would receive the full invoice, not a selection of VAT fields

—The current Online Számla data structure would not simply be upgraded to the European standard — a new EN 16931 based structure is envisaged, with mapping between the legacy schema and the future one

The concept expressly rejects the hybrid scenario in which a PDF is the invoice and an XML attachment carries only the minimum mandatory data. In the future model the XML is the authoritative invoice; a human-readable PDF or image is a visual representation, and where the two diverge the XML governs. A visual version would be compulsory for private persons; in B2B the parties could decide whether they need one.

Formats and PDF

The single most common misunderstanding about Hungary is the assumption that a Peppol BIS invoice satisfies the reporting obligation. It does not — these are two different objects.

NAV Online Számla XML

A NAV-specific XML and XSD schema — a reporting data structure. This is what the API expects.

EN 16931 — UBL or CII

Legally relevant for B2G receiving. Not the reporting schema, and not a mandatory invoice format for domestic B2B or B2C.

A Peppol BIS UBL invoice is not a NAV Online Számla report. Under the current system a separate transformation and mapping layer is generally needed between the two.

Is PDF allowed?

Yes — under the rules in force today. NAV states that an invoice may be paper-based or electronic, and defines an electronic invoice as one issued and received in any electronic format containing the mandatory VAT Act data. An invoice sent only by e-mail can qualify; NAV even cites a scanned paper invoice as an example.

—Electronic invoicing requires the recipient's consent, which may be express or implied — payment can suffice

—EDI requires a prior written agreement

—An electronic invoice must be retained electronically

So today a PDF can be a legally valid electronic invoice — while not being a structured EN 16931 e-invoice. Two different categories, and worth keeping apart in any contract or system specification.

Peppol in Hungary

Peppol is not a mandatory national transport channel, today or in the concept. NAV states that invoicing through Peppol will be an option for businesses rather than an obligation, that Hungary does not plan to designate a compulsory Peppol service provider, and that NAV will neither connect its own system to Peppol nor offer a state Peppol invoicing service.

Transport and reporting stay separate

Transmitting an invoice over Peppol does not discharge the Hungarian tax reporting obligation where national rules separately require NAV data supply. Two functions, two implementations.

Peppol Authority

Hungary does not currently appear in the OpenPeppol list of national Peppol Authorities. In jurisdictions without one, the Peppol Coordinating Authority acts in that role and a service provider domiciled there signs its Service Provider Agreement with OpenPeppol. The concept envisages establishing a Hungarian Peppol Authority, which would then define Hungary-specific requirements.

Note a discrepancy worth knowing about: the concept says Hungarian service providers cannot join Peppol without a Hungarian Peppol Authority, yet the current OpenPeppol certified service provider list already contains a Hungarian entry certified under OpenPeppol. The concept's wording is best read as describing future national governance, not current Peppol membership practice.

Identifiers

The country-specific scheme that can be confirmed for Hungary is EAS 9910 — HU:VAT, the Hungarian VAT number in the form HU plus eight digits, with active status. A Hungarian participant can be registered as, for example, 9910:HU12345678. The international scheme 9913 (EU:REID) exists in the code list but is not a Hungary-specific national company identifier, and no separate Hungarian commercial-register EAS was identified.

Requirements for providers

Today Hungary imposes no additional national accreditation on access points. There is no equivalent of the Slovak digitálny poštár, no requirement for a Hungarian legal entity, official electronic mailbox or local representative, and a certified EU access point can serve Hungarian participants in the voluntary Peppol model.

What the concept would add

A national accreditation of invoicing procedures and service providers, envisaged as self-service without a detailed IT audit. The software or service would pass a technical test against NAV's XML data files and demonstrate that it can:

—Produce a correct invoice

—Produce an identical data supply

—Perform the mandatory pre-validation

—Block an invoice that does not meet the technical and data requirements

Preliminary accreditation

Compulsory for invoicing service providers. A taxpayer using an accredited provider would not need to be accredited itself for the issuance and data supply process.

Taxpayer accreditation

Required where the taxpayer uses its own invoicing software — of its own operational process, regardless of whether the software developer was separately accredited.

A public positive accreditation list is foreseen. Data submitted through non-accredited software or a non-accredited taxpayer procedure would stay in pending status for up to 30 days; the invoice could still be issued, but if accreditation is not completed within that window the taxpayer could face a penalty.

What this means for a foreign access point

Peppol certification alone would probably not be enough where a foreign provider also acts as a Hungarian invoicing service provider carrying out the statutory issuance and data-supply process — the concept requires preliminary accreditation for that role.

What the concept does not answer is whether a foreign EU provider could be accredited without a Hungarian establishment, use its home-country legal entity, or need a branch or local representative. No local-presence requirement is stated — but a future Hungarian Peppol Authority could add Hungary-specific requirements later. Treat Peppol certification and Hungarian provider accreditation as two potentially independent compliance layers.

Developer resources

Hungary is unusually open on the technical side, and an integration can be tested properly before it touches production. NAV maintains a public GitHub repository for the Online Számla machine-to-machine interface containing the schema definitions and example XML files, alongside a full test environment.

Test frontendonlineszamla-test.nav.gov.hu

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

Production frontendonlineszamla.nav.gov.hu

Production APIapi.onlineszamla.nav.gov.hu

The current interface specification is version 3.0. NAV also runs a developer diary for interface changes and accepts comments on published and planned XSD versions through the repository — outside formal consultation periods as well. All content published by NAV is available in English alongside Hungarian, and contributions are accepted in either language. The links are under resources.

Archiving

Under the Hungarian Accounting Act, accounting documents supporting the books must be retained for at least eight years in legible form, recoverable at any time. Invoices are accounting documents.

An invoice issued or received electronically must be retained electronically — printing it and filing the paper is not compliant

Authenticity of origin, integrity of content and legibility must be assured throughout — NAV accepts business controls creating a reliable audit trail as one way of doing this

The NAV Online Számla system is a reporting system, not your archive — retention stays with the taxpayer

The distinction matters more in Hungary than elsewhere, because the invoice and the report are different artefacts. Keeping the NAV submission does not discharge the obligation to keep the invoice, and keeping a PDF of the invoice does not evidence what was reported.

Penalties

The Hungarian sanction design has a feature that makes systematic failures far more dangerous than isolated ones: the statutory ceiling scales with the number of affected invoices.

HUF 500,000General default penalty ceiling for a non-natural person taxpayer, including an ordinary company, under the Tax Administration Act

HUF 200,000The same ceiling for a natural person taxpayer

× affected invoicesFor breaches of the invoice reporting obligation — omission, late submission, incomplete, erroneous or false data — the special cap is the general maximum multiplied by the number of affected invoices or invoice-equivalent documents

Up to HUF 1 millionFor failure to meet the invoice or receipt issuance obligation, or issuance not reflecting the actual consideration

Three different grounds sit behind those figures and should not be conflated: an invoice issuance violation, a NAV reporting violation, and — in the future — a structured e-invoice violation. Under the concept, data from non-accredited software would remain pending for 30 days and a penalty could follow if accreditation is not completed, but no new tariff has been set, so quoting a figure for that would be premature.

Is an e-invoice the only basis for deducting VAT?

No. NAV states that an invoice may be issued electronically or on paper, and an invoice can serve as a material condition for input VAT deduction under the VAT Act. Current law does not require the invoice supporting a deduction to be an e-invoice — a lawful paper invoice still exists. What matters is the VAT Act requirements, authenticity of origin, integrity of content, legibility and the link to an actual supply.

The concept would make the XML the official and authentic invoice, with the human-readable version subordinate to it. But it does not establish that NAV acceptance is a constitutive condition for deduction — on the contrary, it preserves the principle that data supply is not a condition of issuing the invoice. Describing the future Hungarian model as "no clearance, no valid invoice, no deduction" would overstate what the published concept says.

How we help

Hungary needs the reporting layer and the exchange layer treated as separate problems — which is exactly how we build it:

Peppol BIS Billing 3.0 exchange with Hungarian and European partners via a certified Access Point

Addressing on EAS 9910 with the Hungarian VAT number

Mapping between EN 16931 invoice data and the NAV Online Számla reporting schema

EN 16931 invoices for Hungarian public buyers exercising their receiving capability

Validation against EN 16931 before dispatch, with traceable status and error feedback

Integration via API, SFTP and CSV, with ERP and IDoc source data

An architecture that can absorb the concept's five-corner model when it becomes law

Frequently asked questions

Is e-invoicing mandatory in Hungary?

No, other than for certain electricity and natural gas supplies to non-private persons since 1 July 2025. What is mandatory is real-time reporting of invoice data to NAV. The invoice itself may still be paper or a PDF. The European Commission's country factsheet records no general B2G supplier, B2B or B2C e-invoice mandate for Hungary, and NAV has announced no go-live date for one.

Does sending via Peppol satisfy the Hungarian obligation?

No. Peppol transport and NAV reporting are separate functions. Transmitting an invoice over Peppol does not discharge the tax reporting obligation where national rules separately require NAV data supply. A Peppol BIS UBL invoice is also not a NAV Online Számla report — the reporting schema is a NAV-specific XML/XSD, so a transformation layer is generally needed between the two.

Can I still invoice by PDF?

Yes, under current rules. NAV defines an electronic invoice as one issued and received in any electronic format containing the mandatory VAT Act data, and an invoice sent only by e-mail can qualify. You need the recipient's consent, which may be express or implied — payment can suffice — and EDI needs a prior written agreement. An electronic invoice must then be retained electronically. Note that a valid PDF invoice is still not a structured EN 16931 e-invoice; the future concept would end this by making XML the authoritative invoice.

Do I have to send B2G invoices electronically?

There is no general supplier obligation. Since 1 November 2019 Hungarian contracting authorities must be able to accept and process EN 16931 compliant e-invoices for covered public procurement, but that is a receiver mandate. If a public buyer asks for an EN 16931 invoice it is using a capability the law requires it to have. NAV reporting applies to the invoice in parallel as usual.

What is the five-corner model, and when does it start?

It is the architecture NAV set out in its ViDA implementation concept of 3 July 2026: seller, seller's software or provider, buyer, buyer's system or provider, and the tax authority — with an optional sixth corner for a party transmitting data to NAV. Using a service provider would not be compulsory. There is no start date: the document is a concept and establishes none. ViDA's 1 July 2030 date applies to cross-border intra-EU B2B, not to Hungarian domestic invoicing.

Can a foreign Peppol access point serve Hungarian clients?

Today, yes. No Hungarian rule was identified preventing a certified EU access point from providing voluntary Peppol services to a Hungarian end user, and no Hungarian legal entity, mailbox or local representative is required. Hungary has no national Peppol Authority, so providers domiciled there contract with OpenPeppol. Under the future concept this could change: preliminary accreditation would be compulsory for invoicing service providers, and the concept does not say whether a foreign provider could be accredited without a Hungarian establishment.

What are the penalties for reporting failures?

The general default penalty ceiling is HUF 500,000 for a company and HUF 200,000 for a natural person. For invoice reporting breaches the special cap is that maximum multiplied by the number of affected invoices — so a systematic failure is dramatically more serious than a one-off. Separately, failure to meet the invoice or receipt issuance obligation carries up to HUF 1 million. Issuance violations, reporting violations and future structured-invoice violations are distinct grounds.

Can I test an integration before going live?

Yes, and Hungary makes this easier than most. NAV runs a full test environment with its own frontend and API, and maintains a public GitHub repository containing the schema definitions and example XML files for the machine-to-machine interface. The current interface specification is version 3.0, and NAV publishes a developer diary for interface changes. All NAV-published content is available in English as well as Hungarian.

Summary

Hungary should not be classified today as a mandate country alongside Italy or Poland. It runs mandatory real-time invoice data reporting through NAV Online Számla, with a NAV-specific XML schema, no clearance, no Peppol requirement, and PDF still valid as an electronic invoice where the recipient consents.

The direction of travel is clear and genuinely interesting: NAV's July 2026 concept describes a shift from "report the invoice data" to "the structured XML invoice is itself the authoritative object shared between seller, buyer and tax authority" — a five-corner CTC with optional Peppol interoperability and national accreditation of invoicing providers. What it does not describe is a date.

The risk to watch is on the provider side rather than the taxpayer side: Peppol certification is unlikely to substitute for the planned Hungarian invoicing-provider accreditation where a provider takes on statutory issuance and reporting functions. No local-presence requirement has been stated — but none has been ruled out either.

Resources

NAV Online Számla — the production system Registration, invoice data reporting and the free NAV invoicing application NAV on GitHub — Online Invoice repository Official XSD schema definitions and example XML files for the M2M interface, with all four environment URLs NAV — developer documentation The Online Számla interface specification, currently version 3.0 NAV — developer diary Interface changes and planned XSD versions, worth subscribing to before an integration project NAV — test environment Test the full reporting flow before touching production NAV — the National Tax and Customs Administration Invoicing and VAT guidance, information booklets and the ViDA implementation concept

Need support with e-invoicing requirements?

As a certified Peppol Access Point we provide solutions for sending and receiving electronic invoices securely across Europe — including format conversion, validation and integration with national systems.

Start your free trial