Briefing Document & Podcast: Hungary’s Digital Tax Reporting Landscape: E‑Invoicing, E‑Reporting, SAF-T and E‑Transport

Implementation Timeline & Key Milestones (Including Grace Periods)

• July 1, 2018 – Introduction of Real-Time Invoice Reporting (RTIR): Hungary’s National Tax and Customs Administration (NAV) launched mandatory real-time invoice data reporting for domestic B2B invoices above a certain VAT threshold. From this date, any taxpayer registered for VAT in Hungary issuing an invoice with VAT ≥ HUF 100,000 had to transmit the invoice data electronically to NAV immediately upon issuance. This “Online Számla” system was an anti-VAT-fraud measure replacing the old monthly sales ledger. (Initially, paper or PDF invoices could still be issued to the buyer, but the data had to be sent to NAV in XML format automatically by the invoicing software.) A grace period was effectively in place during the initial rollout for businesses to adapt their IT systems, though the law was enforceable from July 2018. [ec.europa.eu]
• November 1, 2019 – B2G E-invoicing (Public Sector) Requirement: Since late 2019, Hungary transposed EU Directive 2014/55/EU on public procurement e-invoicing. All public authorities must be able to receive and process structured e-invoices, and suppliers in public contracts above EU thresholds must submit invoices in an EU-compliant electronic format. In practice, this meant contracting authorities at central and local levels had to accept e-invoices as of Nov 2019, although businesses were (and are) not universally mandated to issue e-invoices to the public sector unless contractually required. [vatupdate.com], [vatupdate.com] [globalvatc…liance.com]
• July 1, 2020 – Expansion of RTIR to All Domestic Invoices: Hungary removed the VAT amount threshold for real-time reporting. From this date, all invoices issued by a Hungarian VAT-registered taxpayer to another domestic taxpayer (B2B or B2G) with a supply in Hungary must be reported to NAV. This closed the gap so that essentially every domestic invoice had to be reported electronically, regardless of value. (The only exception at this stage was invoices to private individuals and certain telecom/digital services under special OSS rules – see below.) [ferbal.hu]
• January 1, 2021 – Full Scope Real-Time Reporting (Domestic B2C and Cross-Border): The RTIR mandate was extended to all outgoing invoices, including those issued to domestic non-taxable persons (B2C) and to foreign recipients. As of 2021, any invoice a Hungarian VAT-registered business issues – whether for domestic B2B, domestic B2C, intra-Community supply, or export – is subject to the real-time data reporting obligation. The only narrow exceptions are certain telecommunications, broadcasting, and e-services where the place of supply is another EU country and the supplier uses the OSS scheme for VAT (such invoices need not be reported to NAV). Notably, invoices to private individuals are reported without transmitting personal data like the customer’s name or address (to protect privacy) even though those details appear on the invoice. [ferbal.hu], [ferbal.hu] [ferbal.hu]
• Grace Period (Q1 2021): To facilitate this major expansion, NAV announced a sanction-free period from January 4, 2021 through March 31, 2021. During this window, taxpayers would not be fined for missing or incorrect invoice data reports under the new scope, on the condition that they work to adapt systems to the updated XML schema (Online Számla 3.0) and comply by April 1, 2021. In effect, the first three months of 2021 served as a grace period for businesses to implement the new requirements without incurring penalties. Starting April 1, 2021, the tax authority began enforcement – meaning late, missing, or incorrect data submissions could trigger fines. [kcgpartners.com], [kcgpartners.com]
• June 2021 – Online Számla 3.0 and Optional NAV E-invoice Service: By mid-2021, Hungary deployed NAV Online Invoicing System version 3.0, aligning with the European e-invoicing standard (EN 16931). This update introduced the option for businesses to issue invoices purely by reporting the XML to NAV (without separately delivering an invoice to the customer). If the supplier indicates in the XML that it is an “electronic invoice” and includes a hash of the data, NAV’s system can make that invoice available to the customer electronically, treating the XML as the original invoice. From June 1, 2021, using the NAV system or API in the new format became mandatory for all RTIR submissions. (In other words, as of that date all taxpayers had to use the Online Számla platform with the updated schema for their invoice reports.) This change also coincided with the inclusion of domestic B2C invoices in RTIR and introduced stricter data validation rules and technical improvements on the NAV portal. After this go-live, Hungary’s real-time reporting covered 100% of invoices issued by VAT-registered persons (except OSS-covered services). [ec.europa.eu], [ec.europa.eu] [ec.europa.eu]
• **January 1, 2025 (Planned) – Sectoral B2B E-invoicing Mandate (Energy Sector) – Postponed: ** The Hungarian government initially set Jan 1, 2025 as the date when certain industries would face compulsory e-invoicing for B2B transactions. In particular, suppliers of electricity and natural gas were to be required to issue all invoices to non-residential (business) customers exclusively in electronic form. This mandate, adopted via amendments to Government Decrees 273/2007 and 19/2009, aimed at making e-invoices standard in the energy sector. However, on Dec 31, 2024 (literally at year-end), the authorities announced a 6-month postponement to allow more preparation time. The new effective date was set to July 1, 2025. [kpmg.com], [pwc.com] [pwc.com]
• July 1, 2025 – Mandatory E-invoicing for Energy Suppliers: As of July 2025, companies trading in electricity and gas must issue electronic invoices for all B2B transactions (all “non-retail” customers). This covers invoices to business end-users and to intermediaries like energy wholesalers (not just the final consumers). The law also implicitly requires customers in this sector to accept e-invoices and handle them accordingly. (Hungary’s VAT Act traditionally required customer consent for e-invoicing, but this has been overridden for mandated scenarios – see Archiving section below for changes on customer consent.) The postponement served as a built-in grace period, giving affected companies an extra six months to upgrade their invoicing systems and train staff. By mid-2025, the energy sector became a pilot for broader B2B e-invoicing mandates in Hungary’s push toward digital VAT compliance. [pwc.com]
• Future Outlook – 2025 and Beyond (ViDA and Full Mandates): Hungary is actively planning for full mandatory e-invoicing and expanded e-reporting in line with the EU’s “VAT in the Digital Age” (ViDA) initiative. In November 2025, NAV and the Ministry of Economy launched a public consultation on a concept paper for a new e-invoicing and real-time reporting framework. According to this proposal (not yet law as of end-2025): Mandatory e-invoicing would be extended to virtually all B2B transactions, including domestic B2B and intra-EU B2B, and also B2G (business-to-government) supplies. For B2C and extra-EU (export) invoices, paper invoicing would remain allowable if the customer is a private consumer or if Hungarian rules don’t mandate e-invoice, but even those would still require real-time data reporting to NAV. In other words, Hungary envisions a combined e-invoicing + e-reporting model: all invoices must exist in a standard electronic (XML) form for reporting, and in most cases that electronic form will also become the official invoice. The consultation document suggests using a European standard XML (EN 16931) as the required format for all invoices (even if a paper copy is also given for B2C) and joining the PEPPOL network as an option for transmitting invoices. It also proposes buyer-side reporting (domestic buyers report invoices received within 5 days) to complement seller reporting. These plans are under discussion; no fixed implementation date is set yet, but Hungary appears poised to implement the ViDA requirements ahead of the EU’s 2030 deadline for cross-border e-reporting. In summary, future developments likely mean mandatory e-invoicing for all B2B transactions in the next few years, with phased implementation and possibly further grace periods for different sectors. (The energy sector’s 2025 mandate is seen as the first step in this direction.) [sovos.com] [sovos.com], [sovos.com] [globalvatc…liance.com], [globalvatc…liance.com]

Scope of Transactions Covered (Domestic, Intra-EU, Export)

• Domestic B2B and B2G: All domestic business-to-business invoices are subject to real-time reporting, with no value threshold (since 2020). This includes standard domestic supplies where Hungarian VAT applies, as well as domestic reverse-charge supplies (which still require an invoice). B2G invoices (supplies to public authorities) must also be reported, and separately, contracting authorities must accept e-invoices for public contracts (since 2019). (While businesses aren’t generally forced to issue e-invoices to the public sector, many do so under contract terms, and the data still goes through RTIR.) Starting July 2025, specific sectors (e.g. energy utilities) must issue actual e-invoices (not paper) for all domestic B2B sales. [ferbal.hu] [vatupdate.com] [pwc.com]
• Domestic B2C: Since 2021, invoices issued to Hungarian private individuals or other non-VAT-registered customers must be reported to NAV in real-time as well. This was a major expansion, capturing retail and consumer transactions where an invoice is issued. (Simplified receipts from cash registers are handled by a different system, but if a formal invoice is created for a consumer, it falls under RTIR.) Personal data of B2C customers (name, address) are not transmitted in the report – NAV only receives anonymized or limited data for those invoices by law. Notably, even though the data is reported, e-invoicing in B2C remains voluntary – businesses can still give paper or PDF invoices to consumers unless a specific law mandates otherwise. (Most consumers still receive paper/PDF receipts, except e.g. utility bills where electronic form is now mandated.) [ferbal.hu]
• Intra-EU B2B (cross-border within EU): Outgoing intra-Community supply invoices (sales from Hungary to EU VAT-registered buyers, typically zero-rated) have been in scope for data reporting since 2021. Initially, Hungary’s RTIR only covered domestic sales, but as of Jan 2021, invoices relating to intra-EU transactions (e.g. goods delivered from Hungary to another member state, or services where the place of supply is another EU country) must also be reported. The data reporting for these might sometimes be “core” invoice data rather than full detail (aligning with planned EU rules), but currently Hungary requires essentially the full invoice data even for these zero-VAT invoices. Intra-EU purchase invoices received by a Hungarian business (so-called acquisitions) are not reported by the seller to NAV (the foreign supplier reports to their own authority). Thus, those purchase invoices don’t appear in RTIR and must be handled via the normal VAT return (this is one reason the draft VAT return won’t have all data – see pre-filled VAT section). Under future proposals, Hungary may introduce buyer-side reporting to capture purchases, but as of 2025 only the supplier side is reported. [ec.europa.eu] [sovos.com]
• Export (Non-EU) Invoices: Similarly, export invoices (sales from Hungary to a customer outside the EU) are covered by the real-time reporting obligation since 2021. These typically have no VAT (zero-rated export), but the invoice data still must be sent to NAV. Import transactions (goods imported into Hungary) do not involve an outgoing invoice from a Hungarian supplier, so they aren’t part of e-invoice reporting – those are handled by customs and import VAT declarations. However, if a Hungarian business issues an invoice for a service or goods that is outside the scope of Hungarian VAT (e.g. a service performed entirely abroad), and that invoice is still subject to Hungarian invoicing rules, it must be reported with a special flag indicating the transaction is outside the VAT scope or under reverse-charge. In summary, any invoice issued by a Hungarian VAT-registered taxpayer, regardless of where the buyer is located or whether VAT is charged, is in scope for reporting (with only very limited exceptions, like OSS-covered digital services). [ferbal.hu] [kcgpartners.com]
• Foreign VAT-Registered Businesses: The obligation also explicitly covers foreign companies that are VAT-registered in Hungary (but not established). If a non-resident entity has a Hungarian tax number and issues invoices for supplies in Hungary, those invoices must be reported just like a local firm’s invoices. This includes cases like foreign webshops selling in Hungary and issuing invoices – they must use RTIR for their B2B/B2C Hungarian sales, unless they opt into the OSS for B2C. Starting July 2021, EU distance sellers using the OSS (One-Stop Shop) for their Hungarian B2C sales were exempted from the RTIR obligation for those OSS transactions. (The logic: if a foreign business is reporting all its EU B2C sales via OSS in another country, Hungary does not force real-time invoice reporting on those sales.) But aside from the OSS scenario, established and non-established VAT payers are equally in scope – a domestic tax number triggers the same requirements for data reporting. Even businesses with no physical presence in Hungary must connect to NAV’s system or use a third-party solution to submit their invoice data remotely. There is no size or turnover exemption – even small businesses that are VAT registered (including those under the domestic VAT threshold who volunteer for VAT) fall under RTIR. The only businesses completely out of scope are those not registered for VAT at all (e.g. truly small firms under the VAT exemption that don’t issue VAT invoices, or purely OSS-managed foreign sellers). [rsm.hu]
• Summary: Today, domestic B2B, B2C, intra-EU, and export invoices issued by Hungarian VAT taxpayers all require real-time reporting to NAV. The mandated use of actual e-invoices (as opposed to just reporting data) is, for now, limited to specific cases like the energy sector B2B from 2025 and public procurement receiving. However, the trend is toward expanding mandatory e-invoicing to more sectors and transaction types in coming years, on top of the universal data reporting that’s already in place. [ferbal.hu], [ferbal.hu] [pwc.com] [globalvatc…liance.com], [sovos.com]

Taxable Persons in Scope (Established vs. Non-Established)

• Hungarian Established Businesses: All companies, sole proprietors, or other entities established in Hungary and registered for VAT must comply with the invoicing and reporting rules. This includes both standard VAT payers and special cases (e.g. members of a VAT group, taxpayers under the cash accounting scheme, etc., when they issue invoices). There are no exemptions for small businesses aside from those completely out of the VAT system. (If a business is under the VAT threshold and did not opt into VAT, it generally wouldn’t issue VAT invoices, but if it does issue an invoice with VAT or a formal invoice requested by a customer, it would trigger the obligation – in practice most truly exempt small businesses don’t use the NAV system because they don’t charge VAT.)
• Foreign Businesses with Hungarian VAT Registration: Non-established companies registered for VAT in Hungary are explicitly required to comply with real-time invoice data reporting on their Hungarian invoices. For example, if a German company is VAT-registered in Hungary to sell goods locally or to provide services, it must ensure its invoices to Hungarian customers are reported through NAV’s system just like a local company would. The Hungarian Tax Authority has clarified that this requirement covers foreign distance sellers and other non-resident taxpayers alike. One notable exception is for foreign businesses using the OSS (One-Stop Shop) scheme for EU distance sales: those sales are reported via OSS and therefore such a company need not do real-time reporting for its OSS-covered B2C invoices in Hungary. (But if that same company also had, say, B2B sales in Hungary requiring a local VAT number, those B2B invoices would have to be reported.) Aside from the OSS case, any foreign company with a Hungarian tax number – even with no physical presence – is in scope. There’s no differentiation or relief simply for being non-established; they can use automated APIs from abroad to transmit data, and NAV’s system is accessible from anywhere (taxpayers must ensure their foreign billing service can connect to NAV). [rsm.hu]
• Entities Not Liable for VAT: Interestingly, even entities not liable for VAT may fall under certain aspects of the e-invoicing framework. For example, if a legal person is not a taxpayer but still issues an invoice-like document under Hungarian rules, the legislation was phrased broadly to capture invoice data reporting for invoices issued to “persons or organizations not subject to VAT” as well. In practice, cases of truly non-VAT-liable entities issuing VAT invoices are rare (they’d usually just not be in the VAT system). However, the law ensures that if, say, a private individual or a VAT-exempt organization issues an invoice that is formally under the VAT Act, those invoices should be reported. (This can occur in cases like a non-profit charging fees with VAT or a private person selling a new car within the EU – edge cases). The 2021 extension specifically mentioned that invoices issued to “foreign or domestic natural persons, legal persons, or organizations not subject to VAT” are now within the data reporting obligation. Essentially, the scope is tied to invoices that fall under the invoicing requirements of the VAT Act, rather than the status of the issuer. So if an entity issues an invoice as defined by VAT law, they are expected to report it if they have a Hungarian VAT number or obligation. [kcgpartners.com]
• Summary: All VAT-registered taxpayers in Hungary – whether domestic or foreign, whether fully liable or only legally required to issue an invoice – must adhere to the e-reporting rules. Established vs. non-established: there is generally no difference in treatment. Both must use the Online Számla system for any invoices relating to Hungarian VAT transactions. The only carve-outs are for those using special Union schemes (OSS) or not in the VAT system at all. It’s also worth noting that Hungary did not adopt the optional extra year for sub-central government entities under the EU e-invoicing directive – it implemented on time, which underscores that even public bodies and their suppliers were quickly brought into the fold. In summary, if you have a Hungarian VAT ID and issue invoices, you’re in scope – regardless of establishment status. [rsm.hu] [ec.europa.eu]

Data Requirements: What Invoice Data Must Be Reported?

• Full Invoice Details: The core content of the invoice as defined by the VAT Act must be transmitted. This includes: issuer’s details (name, address, tax number), buyer’s details (name, address, tax number if applicable), invoice number, issue date, supply date, line-item details (description of goods/services, quantity, unit price), taxable amount for each VAT rate, the VAT rate, VAT amount, currency, and total amounts. In practice, the XML schema (NAV “XSD 3.0” or higher) has fields for all mandatory elements of an invoice under Hungarian law. For example, if an invoice is issued with a foreign currency, the currency code must be provided. If an invoice is a modification or credit note, reference to the original invoice ID is required. [avalara.com] [kcgpartners.com]
• Additional Flags/Indicators: The system also collects certain classifications about the transaction that may not explicitly appear on a paper invoice but are needed for tax reporting. According to official guidance, the data submission should indicate, for instance, if the transaction is outside the scope of Hungarian VAT or under reverse-charge rules. For example, if a Hungarian firm issues an invoice for a service where VAT place of supply is abroad (hence no Hungarian VAT), the data report must include a flag showing “transaction falls outside the territorial scope of VAT Act”. If an invoice is subject to domestic reverse charge (where the buyer pays the VAT, common in construction or scrap trading in Hungary), that must be coded appropriately. Other data points include whether the transaction is a supply of goods or services (important for some cross-border reporting), and an indicator if the invoice is an electronic invoice (in the sense of NAV providing it to the customer). Essentially, NAV requires not just the invoice amounts, but contextual data to know how to treat the transaction. [kcgpartners.com]
• Hash and Electronic Invoice Specifics: If the invoice itself is being issued as an e-invoice through NAV (rather than just reporting), the XML must contain a hash value of the invoice data for integrity and an “eInvoice” indicator. When these are present, NAV’s system understands that this XML is the legal invoice copy to be forwarded to the buyer (who can download it from the NAV portal or via API). In such cases, all the information that would normally be on the invoice (even beyond what minimal RTIR requires) must be included in the XML. For instance, normally RTIR might not require the buyer’s address if it’s a domestic B2B (tax number suffices), but for a full e-invoice, that address would be part of the invoice and thus should be in the XML. The Hungarian system’s design is that the same XML file can fulfill both the reporting obligation and serve as the actual invoice document, provided it meets the e-invoice criteria. [ec.europa.eu]
• European Standard Compliance: Hungary’s data format has been aligned with the European e-invoicing standard EN 16931. According to both EU and local sources, the NAV XML schema is fully compliant with the EU standard semantic model. As part of the 2025 concept, it’s stated that all invoices will need to be created in an XML format compliant with EN 16931 (the European norm), even if a paper copy is later printed. This ensures that the data content covers everything that an EU-standard invoice would require. In other words, the format for e-reporting is a structured XML with standardized fields. (Older methods like unstructured PDFs are not acceptable for reporting, though they could still be given to customers outside the system if allowed.) [ec.europa.eu] [sovos.com]
• Transmission Method: The invoice data is transmitted via a secure web service (HTTPS API) or via NAV’s online portal. Most medium and large businesses integrate their ERP/invoicing software directly with NAV’s API, so that when an invoice is issued, the software automatically sends the XML payload to NAV’s server in real time. Smaller businesses or those with low volume can use NAV’s web portal to upload invoices manually or use a simplified input form. There is also an option to send data in batch via an XML upload or to use a third-party reporting tool. The key is that no human intervention is supposed to be needed in the reporting process – it should be an automated machine-to-machine submission triggered by the invoicing system. [avalara.com] [ec.europa.eu]
• Immediate Validation and Response: NAV’s system performs immediate validation on the data. Upon receiving the XML, it checks the completeness and correctness (e.g., ensuring required fields are present, numeric fields make sense, tax sums match rates, customer tax ID format is valid, etc.). If everything is in order, NAV returns a confirmation (ACK code) to the sender system in seconds. If there’s an error (e.g., a schema validation error or a logical inconsistency), NAV returns an error code and the invoice may need to be corrected and resent. Only once a positive acknowledgment is received should the invoice be considered successfully reported. (If using the NAV system as the invoicing medium, the buyer can then retrieve it; if the business is separately sending a PDF to the buyer, they typically wait for the ACK before sending, to ensure the invoice is valid in the tax authority’s eyes.) [avalara.com]
• Content Scope: Importantly, only invoices and similar documents are in scope, not every transaction or receipt. Invoices that are fully issued from cash registers (receipts) go through a different online system (online cash register data reporting) and are not part of RTIR. However, modifying documents like credit notes or invoice cancellation documents are included – they must also be reported immediately just like regular invoices. The data report for a credit note will reference the original invoice number and provide negative amounts as appropriate. Pro forma invoices or quotations (which are not true tax invoices) are not reported. The requirement applies to any document that qualifies as an invoice under the VAT Act. [rsm.hu]

Deadlines for Transmitting Invoice Data (Reporting Timing)

Hungary’s system is designed for real-time or nearly real-time reporting. Key points on the timing and deadlines for data submission:

• “Real-Time” Requirement: The law stipulates that the invoice data must be transmitted immediately after issuance of the invoice, essentially at the same time the invoice is created. In practice, this means the data is sent within seconds of finalizing the invoice in the billing system. The Hungarian NAV expects that the reporting is done **before or at the latest when the invoice is delivered to the customer】. In other words, if you are emailing a PDF invoice to a client, you should have already received confirmation from NAV for the data submission by that time. The process is automated – when an invoice is issued in the company’s software, the software calls NAV’s API instantly. There is no allowance for manual end-of-day batch uploads or weekly summaries; it’s designed as an ongoing live feed of invoices. [avalara.com]
• Legal Definition of “Immediate”: “Immediate” is not defined in minutes, but the system’s intent is clear that it should be **continuous and without human intervention. According to NAV’s guidance, any significant delay constitutes non-compliance. Practically, if an invoice isn’t reported within a few minutes of issuance, the tax authority could consider that a violation (especially if audited). [ec.europa.eu]
• Technical Failures – 24 Hour Rule: In cases of technical issues (like a network outage or NAV system downtime), the authorities allow a short grace period to transmit the data once the issue is resolved. Hungary has an “Offline 24” concept mentioned in some technical documentation. This implies that if the immediate transmission fails due to system outage, the taxpayer must transmit the invoice data within 24 hours after issuance using a backup solution (NAV provides an “Offline form” for emergency reporting). This is not so much a routinely allowed delay as a contingency. If both the primary and backup reporting fail within 24 hours, the business should notify the tax authority and resolve the issue urgently. Regular operation, however, assumes instant reporting. [globalvatc…liance.com]
• Buyer Reporting (Planned): As of 2025, buyers do not have to report incoming invoices – only sellers report. However, the new concept under consultation proposes that buyers would need to report confirmation of invoices received within 5 days for domestic transactions. This is to create a cross-check (ensuring what sellers report matches what buyers received). This requirement is not yet in force. Currently, the onus is entirely on the issuer to report on time. [sovos.com]
• Periodic Summaries: There is no periodic batch deadline (such as “report by the 15th of next month”) in Hungary’s system for sales invoices – it’s continuous. This distinguishes it from some other countries’ systems where data might be uploaded in batches. In Hungary, each invoice triggers an immediate report. The monthly VAT return still exists separately, but one does not wait until the VAT return to submit invoice data; it must have been done at issuance. The old requirement for domestic sales listing in the VAT return (M-form) was essentially replaced by RTIR back in 2018. [ec.europa.eu]
• Grace for New Scope Implementations: As noted in the timeline, when new requirements have come into effect (e.g. 2021 extension), the government has sometimes given a grace period where late reporting wasn’t fined for a short time. But those were one-time transitional measures. Under normal conditions now, any failure to report an invoice by the time of issuance is a breach. NAV’s systems are quite fast, and businesses are expected to have stable connectivity to comply. [kcgpartners.com]

Format of E-Invoices and E-Reporting Transmission

• E-invoice Format: Hungary’s official e-invoice format for the NAV system is an XML data file following NAV’s schema (currently version 3.x) which is compatible with the European Norm (EN 16931). This means the structured data aligns with the EU core invoice model, ensuring interoperability. The legally valid invoice in an e-invoicing context is this XML file itself (particularly when it contains the e-invoice hash and is flagged as an e-invoice). In the new proposals, it is stated that even if a paper invoice is issued to a consumer, an XML must still be created and that “the legally authentic invoice will always be the XML file”. So the XML is central. It can be considered a sort of “FA3” XML (as some sources call it) which contains all invoice data elements and metadata. [ec.europa.eu] [sovos.com] [globalvatc…liance.com]
• Accepted Standards: Besides the NAV XML for reporting, Hungary also accepts the EU standard XML invoice (UBL or UN/CEFACT format) under the European standard, especially for B2G invoices. Since Hungarian authorities must accept EU compliant invoices for public procurement, formats like PEPPOL BIS 3.0 (CIUS) are acceptable for B2G. However, those still need to be converted or reported via NAV’s platform for tax reporting. In practice, many service providers map the EN16931 invoice into the NAV schema to fulfill the reporting. So while companies can use various software, the final data that NAV receives is in the NAV-prescribed XML format.
• Transmission Platform: The data is transmitted through the NAV Online Számla system, which is a centralized government platform. This platform exposes a web service API for integration, and also a web portal (onlineszamla.nav.gov.hu) where users can log in. Transmission can be done via: direct machine-to-machine API calls (the common method for high volume issuers), uploading XML files through the web interface, or in low-volume cases, manually keying invoice details into a web form. There is also a mobile app for viewing submissions. For businesses, the automated API is key – they register their system with NAV (get an API key) and then the software sends HTTPS POST requests with XML payloads. The communication is encrypted and requires authentication (each taxpayer has a technical user and key). [ec.europa.eu]
• Response Format: Upon sending an invoice report, NAV returns an XML response indicating success or error, using preset codes. A successful submission yields an InvoiceAccepted message with an ID. If the invoice is flagged as an e-invoice, NAV will store it and make it available for the buyer through the system. If not, NAV still stores the data for audit purposes but the seller delivers the invoice to the buyer separately.
• No Specific Software Imposed: Hungary did not impose a single invoicing software; instead, it imposed standards and an API. Companies can use any invoicing program or ERP as long as it meets the requirements. However, invoicing software must comply with certain rules. Notably, plans have been announced for mandatory accreditation of invoicing software – programs will have to pass tests to ensure they generate compliant XML and perform validations. Non-accredited software could lead to penalties after a 30-day grace if not fixed. This means Hungary is moving towards certifying that invoice software adheres to the format and content rules (blocking invoices that are missing required data, etc.). [sovos.com]
• PEPPOL and Cross-Border Channels: Although the current system uses a direct connection to NAV, Hungary has indicated it will join the PEPPOL network to facilitate cross-border e-invoicing. This would provide an optional channel for businesses to exchange invoices. However, even if using PEPPOL, Hungarian taxpayers would likely still submit the data to NAV (either via PEPPOL access point connected to NAV or separately). At present, PEPPOL is not yet integrated, but it’s on the roadmap post-2025. For now, the NAV portal/API is the primary channel for e-reporting and e-invoice exchange. [sovos.com]
• Formats for Buyers/Recipients: For a buyer to receive an e-invoice issued through NAV, they have a couple of options. A Hungarian buyer who also uses the NAV system can log in and download the invoice XML (along with a human-readable visualization if needed). Alternatively, many companies use service providers that pull the data from NAV and convert it into a PDF or readable format for processing. It’s worth noting that no advanced electronic signature is required on NAV-issued e-invoices – the transmission through the government system and the hash serve to guarantee authenticity/integrity. (Outside the NAV system, if a company emails an unsigned PDF as an invoice, Hungarian law would normally require an advanced electronic signature or EDI agreement to count as an e-invoice. But if using the NAV XML, those requirements are handled by the system’s security.) [ec.europa.eu]
• Paper Invoices: Traditional paper invoices are still permitted for certain transactions (like B2C or transactions not yet mandated for e-invoicing), but even for those, the data must be sent via the electronic system. Essentially, one might print a paper invoice for a customer, but simultaneously the invoice data goes in XML to NAV. The paper is just a copy for the buyer’s convenience; legally the digital report is what NAV cares about. If a sector becomes fully e-invoicing mandated (like energy B2B), then paper is no longer allowed unless the law explicitly allows an exception. In general, Hungary is moving toward treating the XML as the definitive record of the invoice. [sovos.com]
• Summary: The e-invoice format in Hungary is a standardized XML schema and the e-reporting format is identical. Transmission is via an online portal/API (Online Számla) provided by NAV. The European standard for e-invoices is implemented, and future developments will reinforce using that standard for all invoices. Businesses should ensure their software outputs compliant XML and can communicate with NAV’s system. In short, the format is fully digital and structured; unstructured formats (like a simple PDF) alone do not meet the reporting requirement – they must be accompanied by or transformed into the required XML. [ec.europa.eu] [avalara.com]

Penalties for Non-Compliance

• Monetary Fines per Invoice: Failure to report an invoice, or inaccurate/late reporting, can lead to hefty fines. The law provides for an administrative penalty of up to HUF 500,000 (around €1,300) per invoice that is not reported or is reported improperly. This can be imposed on the supplier who fails to submit the data. If non-compliance is repeated or deemed willful, penalties can accumulate and may be assessed at the maximum per each invoice omitted. Some sources note that for repeated offenses, fines up to HUF 1,000,000 per invoice can be levied – effectively doubling the penalty in severe cases. These are among the highest invoice-related fines in Europe, underscoring how critical compliance is to the tax authority. For example, if a business neglected to report 10 invoices, theoretically a 5 million HUF fine could result. [avalara.com] [globalvatc…liance.com]
• Warnings and Grace in Practice: In practice, NAV’s initial approach has been somewhat conciliatory, especially during new rollout phases. During the early phase of RTIR, NAV often issued warnings or notice letters for first-time errors, giving the taxpayer a chance to correct the issue, rather than immediately imposing the maximum fine. As noted, in Q1 2021 a general grace period was announced where no default penalties would be given for non-compliance under the new rules. Even outside formal grace periods, NAV tends to allow corrections: for instance, if an invoice was not transmitted due to a technical glitch, the company can send it late once discovered, and NAV may refrain from fining if it’s an isolated incident. The Global VAT Compliance report indicates that NAV “issues warnings and allows for corrections before fines are applied,” essentially a de-facto grace approach for initial non-compliance. That said, this tolerance is not guaranteed, especially as the system is now mature. By 2022-2023, the expectation is that businesses have had ample time to comply. [kcgpartners.com] [globalvatc…liance.com]
• Additional Consequences: Beyond direct fines, failure to comply with e-reporting can trigger audits and other tax risks. NAV may flag a taxpayer who consistently fails to report or has discrepancies for a VAT audit. Also importantly, if a supplier doesn’t report an invoice, the buyer’s right to deduct VAT on that invoice could be jeopardized. Hungarian law allows tax authorities to disallow VAT deduction for the buyer if the invoice is not reported and thus not in the tax authority’s system (this is part of the “data consistency” push). Thus, non-compliance can harm trading partners too. It’s mentioned that persistent non-compliance “may trigger VAT audits and deduction denials for buyers”. Essentially, compliance is also policed by making sure buyers only accept invoices that were properly reported (buyers can use NAV’s system to check if an invoice is in the database). [globalvatc…liance.com]
• Penalties for E-invoicing Mandate Breaches: In cases where e-invoicing (electronic format) is mandatory (e.g. energy sector from 2025), failing to issue an electronic invoice (issuing paper instead) would likely fall under similar penalty provisions. Additionally, using a non-accredited invoicing software (in the future when accreditation is required) could result in penalties after a 30-day remediation period. There could also be sanctions such as revoking permission to use certain software if it continuously violates rules. [sovos.com]
• Criminal Aspect: While straightforward fines are the primary tool, in extreme cases where invoice data is deliberately not reported to facilitate tax evasion, it could be viewed as tax fraud. Hungarian authorities treat the real-time report as a tax control mechanism, so intentional suppression of invoices might result in criminal tax evasion charges if large VAT amounts are unreported. However, day-to-day compliance issues are handled administratively (penalties and audit adjustments).
• Enforcement Timeline: For the new energy sector mandate, Hungary signaled that full enforcement of penalties would come after an initial period. Sources suggest that 2025 is for implementation and by 2026 NAV will apply full penalties for any non-compliance in that sector. This implies a soft ramp-up: after July 2025, some leniency, but by 2026 expect strict fines. Generally, after any grace period ends, NAV does actively enforce the rules. [globalvatc…liance.com]

Archiving and Retention Requirements

Hungary requires strict archiving of invoices, especially electronic invoices, to ensure data integrity and availability for tax audits. Key requirements:

• Electronic Archiving of E-Invoices: If an invoice is issued electronically, Hungarian law mandates that it must be stored in its electronic form in a way that guarantees its authenticity and integrity for the entire retention period. The VAT Act’s rules on invoicing stipulate that the authenticity of origin, integrity of content, and legibility of an invoice must be ensured from issuance until the end of storage. This applies equally to paper and electronic invoices, but in practice for e-invoices it means digital archiving systems must keep the files undegraded and accessible. Both the issuer and the recipient of an e-invoice have to fulfill archiving obligations (the recipient cannot simply print and discard the digital file – they are expected to retain the digital invoice they received). [kpmg.com], [bbj.hu] [bbj.hu] [kpmg.com]
• Retention Period: The general retention period for invoices in Hungary is 8 years (counted from the end of the relevant tax year). This comes from the Accounting Act, which requires accounting documents (including invoices) to be kept for 8 years. Some sources have mentioned 5 years, but that shorter period likely referred to minimum VAT Directive requirements. In practice, Hungarian companies follow the 8-year rule as domestic law is stricter. The Budapest Business Journal, citing Andersen tax experts, confirms that the retention period is eight years and during that time the invoice must remain both readable and verifiably authentic. For example, an invoice issued in 2025 must be kept until at least 2033. [bbj.hu]
• Format of Archiving: Invoices must be archived in their original format. For paper invoices, that means keeping the paper (or making a certified electronic copy). For e-invoices (like NAV XML or signed PDFs), it means they should be stored electronically. Simply printing out an e-invoice does not fulfill the requirement – the electronic data (with signature or hash) is the original and must be retained electronically. Hungary permits companies to choose their archiving method, but it must meet legal standards. Many use specialized digital archiving solutions that ensure the files are unalterable (often using timestamping or digital signatures for stored files). There is also a possibility to convert paper invoices to digital and then archive digitally, but certain conditions must be met (the conversion process must also ensure authenticity and integrity, per legislation). [bbj.hu]
• E-archive Inspections: The tax authority (NAV) has the right to access and inspect electronic archives during audits. Companies should be able to retrieve any stored invoice and present it in a human-readable form on request. There are detailed Decrees (e.g., NGM Decree 23/2014) that set out how electronically stored invoices should be managed and made available to auditors. Typically, if using NAV’s system, NAV themselves have the data; but the obligation on the taxpayer remains to keep their own copies. [nav.gov.hu], [nav.gov.hu]
• Customer Consent for E-invoicing & Changes from 2025: Historically, Hungarian law required the customer’s prior consent to issue an electronic invoice (otherwise the default expectation was paper). This is rooted in EU law which until 2023 allowed requiring buyer consent. In the context of the energy sector mandate and the upcoming ViDA changes, this is evolving. As of 2024, with ViDA’s approval at EU level, member states can mandate e-invoicing without needing individual consent. Indeed, Hungary signaled that starting in 2025, businesses may receive invoices digitally even without giving express consent for sectors where e-invoicing is mandated. The VAT Act will be updated so that if e-invoicing is compulsory (like for utility bills), the buyer cannot refuse an e-invoice on the basis of not consenting. This is important for archiving because it means more companies (as buyers) will suddenly find themselves receiving only digital invoices and thus need proper e-archiving solutions. The Andersen/BBJ article warns that many businesses “will be required to fully comply with the laws on digital retention of e-invoices” and must be ready by Jan 1, 2025 (when they start receiving e-bills). Companies not yet equipped for e-archiving are advised to implement solutions as soon as possible. [bbj.hu], [bbj.hu] [bbj.hu]
• Archiving Solution Requirements: Separate legislation and guidelines specify acceptable methods for digital archiving. Generally, three methods are recognized for guaranteeing authenticity and integrity over years: (1) using an advanced electronic signature and timestamp on each invoice and storing them digitally; (2) storing invoices in an EDI system with agreed procedures; or (3) using a secure dedicated archiving system that meets standards (often involving regular data integrity checks and controlled access). NAV can audit the archiving method itself, not just the content. Many companies outsource e-archiving to providers or use certified software that complies with these rules. [bbj.hu]
• Period of Transition: Given the newest mandates, many businesses in 2025 are transitioning to e-archiving. The law does allow that if a company had only paper archives, it can digitize them, provided the digital conversion ensures all legal guarantees (authenticity, integrity, legibility). This is an incentive to move towards fully electronic document management. [bbj.hu]

Pre-Filled VAT Returns (eÁFA)

One benefit of Hungary’s comprehensive real-time reporting system is that it enabled the tax authority to start offering pre-prepared (“pre-filled”) draft VAT returns to taxpayers, often referred to as the eVAT or eÁFA system. Here are the details:

• Introduction of Draft VAT Returns: In 2021, the Hungarian government introduced legislation to have NAV prepare draft VAT returns for taxpayers, using the data collected from the Online Invoice system (among other sources). The original plan was to start with periods from mid-2021. After a slight delay, NAV rolled out the first draft VAT returns for the tax period of October 2021 (available in November). This initiative mirrors what Hungary already did for personal income tax (where the tax authority pre-fills tax returns for individuals). For VAT, it’s more complex, but the goal is to reduce administrative burden by leveraging the data NAV already receives. [mgi-bpo.hu]
• How it Works: By the 12th of the month following a tax period, NAV makes a draft VAT return (قرار) available on its e-tax portal for the taxpayer. For example, for the October 2021 monthly period, the draft was accessible from November 12, 2021. This draft, called eÁFA (electronic VAT), is based primarily on the invoices reported through the RTIR system. NAV uses the sales invoice data you have reported (outgoing invoices) to pre-fill your output VAT and uses the purchase invoices reported by your suppliers (incoming invoices where your VAT number was the buyer) to pre-fill the input VAT. [mgi-bpo.hu]
• Limitations of the Draft: It’s critical to note that the draft return is not complete in many cases. NAV can only include data it knows about. As NAV itself acknowledged, the draft “will not contain all the data in such a way to fully comply with the VAT Act”. For instance: [mgi-bpo.hu]
  • Intra-community acquisitions (purchases from EU suppliers) are not reported by the foreign supplier to NAV, so those are not in the draft. [mgi-bpo.hu]
  • Import VAT, certain self-assessed VAT (like reverse charges on services from abroad), and special cases (e.g. partial VAT deduction rules, pro-rata, tourism tax adjustments) are not known to NAV and thus not in the draft. [mgi-bpo.hu]
  • Any invoice issued by foreign suppliers to the Hungarian taxpayer (that isn’t reported in NAV’s domestic RTIR) won’t appear. Also, domestic purchases from very small suppliers who might not have reported (if any) or certain exempt transactions might be missing.
  NAV therefore makes it clear the draft is a starting point. Taxpayers must review and complete any missing details. For example, if you had EU acquisitions, you need to add those before submitting the return.
• Voluntary Use: The draft VAT return is optional – it’s provided for convenience. The taxpayer is not obliged to accept it. They can continue filing VAT returns manually as before if they prefer. If they do choose to use it, they must carefully verify it against their own records. Accepting the draft in the portal and submitting it counts as filing the return, but the taxpayer remains responsible for its accuracy. The law states that the draft only becomes the official return if the taxpayer actively accepts/approves it. Doing nothing is not an option; if you ignore the draft, you still have to file a return by the deadline (which could be simply the draft confirmed or your own submission). [mgi-bpo.hu]
• Current Status: As of the latest information, NAV’s eVAT draft system is operational and has been gradually improved. By 2024, NAV was integrating more data sources (e.g. they planned digital ledger data) to improve the draft’s completeness. It’s part of a broader move toward real-time tax compliance. However, for many businesses (especially those engaged in international trade or complex transactions), the draft VAT return might still require substantial editing. For simpler businesses (purely domestic trade with all suppliers using RTIR), the draft could be very close to final. NAV’s long-term aim is to automate VAT returns to the greatest extent possible as more data (like cross-border transaction data under ViDA) becomes available to them.
• Pre-Filled Return and VAT Payment: If a taxpayer accepts a draft return, it is as if they filed that return themselves. Any VAT due must still be paid by the normal deadline, and any VAT refund claimed will be processed per usual procedures. The draft being available by the 12th of the month (for monthly filers) gives a couple of weeks before the filing/payment deadline (which is the 20th of the following month for monthly VAT returns in Hungary). So taxpayers have time to adjust it.
• Significance: Hungary was one of the first EU countries to attempt pre-filled VAT returns for businesses. This was only feasible because the RTIR system provides detailed sales and purchase data to the tax authority in real time. Essentially, NAV can cross-match sales and purchases at the transaction level for domestic B2B transactions. The introduction of eÁFA shows the benefit of the e-reporting regime: reducing administrative work and potentially errors for compliant taxpayers. It’s also a compliance tool – if NAV’s draft shows something and the taxpayer changes it, NAV could inquire why (e.g., if a taxpayer reduces their output VAT compared to NAV’s calc, they better have a valid reason like issuing a late credit note or an exemption NAV didn’t know about).
• Conclusion on Pre-filled Returns: Yes, Hungary offers pre-filled VAT returns (draft VAT returns) to taxpayers, beginning with late 2021 periods. This system is ongoing and expected to expand. It does not yet fully replace the need for taxpayer input, but it is a major step toward automation. Taxpayers are still responsible for reviewing and finalizing the return. The existence of this system underscores Hungary’s advanced digital tax administration: by combining RTIR data, NAV aims eventually to provide near-complete VAT returns, especially as more data (like eventual intra-EU reporting via ViDA) comes in. [mgi-bpo.hu]

• Official Hungarian legislation and NAV guidance (VAT Act CXXVII 2007; Act LXXXIII 2018; NAV Online Számla documentation). [ec.europa.eu], [kcgpartners.com], [mgi-bpo.hu]
• European Commission e-invoicing country factsheet (Hungary, updated Aug 2025). [ec.europa.eu], [ec.europa.eu]
• Big Four and tax advisory publications: KPMG TaxNewsFlash (Jan 2025), PwC Hungary Alert (Jan 2025), Deloitte/BBJ commentary (Dec 2024). [kpmg.com] [pwc.com], [pwc.com] [bbj.hu], [bbj.hu]
• Tax technology firms and consultancies: Sovos updates (Nov 2025), Global VAT Compliance (Sep 2025), VATupdate summaries (2025), Avalara guide, RSM Hungary notes, and law firm articles (KCG Partners). These confirm the rules and their evolution. [sovos.com], [sovos.com] [globalvatc…liance.com], [globalvatc…liance.com] [vatupdate.com], [vatupdate.com] [avalara.com], [avalara.com] [rsm.hu], [rsm.hu] [kcgpartners.com], [kcgpartners.com]
• NAV official press releases and consultation documents (NAV 2025 ViDA consultation news) and NAV informational booklets. [nav.gov.hu] [nav.gov.hu]
• Hungarian VAT regulations (e.g. Government Decree 273/2007 (X.19) for energy sector) and the Hungarian VAT Act provisions for electronic invoices and data reporting, as referenced by the above sources.