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

SUMMARY

Executive Summary:

Hungary has implemented a sophisticated suite of digital tax compliance systems, including real-time invoice data reporting (e-reporting), electronic invoicing (e-invoicing), a Standard Audit File for Tax (SAF-T), and an electronic transport control system (EKAER). These systems aim to enhance VAT compliance, combat fraud, and modernize tax administration. While e-invoicing is largely voluntary (with a sector-specific mandate coming in 2025), real-time reporting is comprehensive and strictly enforced. SAF-T is not yet mandatory for periodic submission, but may be required during audits. EKAER monitors the movement of goods to prevent VAT fraud related to transport. The overarching trend is toward continuous transaction control and leveraging real-time data for tax enforcement.

Key Themes and Information:

1. Electronic Invoicing (E-Invoicing):

• Current Status: B2B e-invoicing is largely voluntary. Companies can still issue invoices on paper or PDF as long as they comply with e-reporting obligations. “Hungary does not yet mandate B2B electronic invoicing for all businesses.”
• B2G: Public authorities must accept e-invoices, but suppliers are not forced to issue them.
• 2025 Energy Sector Mandate: Beginning January 1, 2025, mandatory e-invoicing will be introduced for electricity and natural gas suppliers selling to non-private (business) customers. “Electricity and natural gas suppliers will be required to issue e-invoices (no paper) for sales to all non-private (business) customers.”
• Structured Format: Electronic invoices must be in a structured data format (e.g., XML) that allows automated processing. Plain PDF invoices are not considered “electronic invoices” under upcoming EU rules. The NAV “Online Számla” system uses XML schemas. The schema includes a field where the issuer can indicate that the transmitted XML is not only for reporting to the tax authority but also constitutes an electronic invoice for the buyer.
• Data Requirements: An e-invoice must contain the same information as a paper invoice (seller/buyer details, invoice number/date, description of goods/services, VAT rate/amount, etc.).
• Archiving: Electronic invoices must be archived in electronic form for 8 years. They cannot be printed to paper for official storage.
• Penalties: There isn’t a specific fine for failing to use e-invoicing (outside the energy sector after 2025), but non-compliance with invoicing rules can attract penalties. “Administrative fines per invoice or per audit finding” can be expected for non-compliance once e-invoicing becomes mandatory.

2. Real-Time Invoice Data Reporting (E-Reporting via Online Számla):

• Core Principle: Every VAT invoice issued by a Hungarian-registered business must be reported electronically to the tax authority (NAV) in real-time.
• Implementation Timeline:July 1, 2018: RTIR went live for domestic B2B invoices with VAT ≥ 100,000 HUF.
• July 1, 2020: Threshold abolished; all domestic B2B and B2G invoices subject to reporting.
• January 1, 2021: Mandate extended to all invoices, including B2C and cross-border transactions.
• Transactions in Scope: Virtually all transactions that involve an invoice under Hungarian VAT rules are in scope (domestic B2B, B2G, B2C, intra-EU, and export sales). “If a business registered for VAT in Hungary issues an invoice, it must report the data (with only a few exceptions).” OSS transactions are generally excluded.
• Taxable Persons in Scope: All VAT-registered taxpayers in Hungary are subject to this obligation, regardless of size or turnover (with limited exceptions for VAT-exempt small businesses).
• Data to Be Reported: Includes invoice identification, supplier/customer information, line-item details, tax details, and additional information (e.g., currency codes, exchange rates). “The entire content of the invoice is sent,” in a structured XML format.
• Reporting Method and Deadline: Reporting must occur immediately as the invoice is issued. If invoices are issued on paper, they must be entered manually into NAV’s web interface, “ideally within 1 day.” “Reporting must occur essentially immediately as the invoice is issued”
• Penalties: Failure to report an invoice in real-time can result in a penalty of up to 500,000 HUF per invoice (approximately €1,200). “Failure to report an invoice in the real-time system can result in a penalty up to 500,000 HUF per invoice”
• Impact: The e-reporting system has been credited with reducing VAT fraud and improving compliance. Hungary’s VAT gap fell significantly after its introduction.

3. SAF-T in Hungary (Standard Audit File for Tax):

• Current Status: SAF-T HU is not yet mandatory as a periodic submission for all companies. “As of late 2025, Hungary has not introduced a compulsory SAF-T filing for all companies”
• Use in Audits: NAV can request SAF-T-like data during audits. Businesses should be prepared to export their records in the SAF-T HU format if requested. “NAV can ask a company under audit to provide certain data electronically.”
• Data Content: SAF-T HU captures a wide range of financial and tax data including master data, transactional data (general ledger entries, sales/purchase invoices, payments, stock movements, fixed asset transactions), and reporting/analytical data (stock summaries, VAT return data, outstanding receivables/payables). It is a “comprehensive” data set.
• Penalties: If a taxpayer under audit fails to provide the requested electronic data in the format specified by NAV, the tax authority can resort to general provisions. A “default penalty” may be applied for not supplying the SAF-T on request.

4. E-Transport System (EKAER) – Electronic Road Cargo Tracking:

• Purpose: EKAER monitors the movement of goods on Hungarian roads to combat VAT fraud, especially in intra-EU trade.
• Scope: EKAER now mainly targets large or risk-category goods moving in, out, or within Hungary by road.
• Thresholds:Risky goods: EKAER report required if a single transport exceeds 500 kg or 1,000,000 HUF in value.
• Non-risky goods: Thresholds are 2,500 kg or 5,000,000 HUF.
• Taxable Persons in Scope: Any company involved in transporting goods under the covered scenarios must comply with EKAER. This includes Hungarian VAT-registered sellers and buyers, as well as foreign companies with a Hungarian VAT.
• Data and Process: Companies must register the shipment in NAV’s EKAER system and obtain an EKAER number before the goods commence road transport.
• Penalties: The penalty for not filing an EKAER report can be up to 40% of the value of the transported goods. “The law allows NAV to impose a penalty up to 40% of the value of the goods that are unreported or incorrectly reported.” For minor mistakes or late reporting, a smaller default fine (up to 500,000 HUF) can be levied.

5. Pre-filled VAT Returns and the “eVAT” System:

• Current Status: Hungary does not currently have pre-filled VAT returns for general taxpayers. “As of now, Hungary does not provide pre-completed VAT returns to businesses.” The planned eVAT system was delayed and transformed.
• Revised Approach (M2M VAT Returns): NAV shifted towards a machine-to-machine (M2M) data exchange system for VAT returns. The eVAT system pivoted to be an API-based filing and pre-validation service, not NAV drafting the return.
• Future Prospects: It’s possible that pre-filled returns could be offered in the future for very simple taxpayers, but there is no timeline for this.

Key Takeaways:

• Hungary is a leader in digital tax administration, with a focus on real-time data and continuous transaction control.
• Businesses operating in Hungary must invest in IT solutions to comply with these evolving requirements and avoid significant penalties.
• While pre-filled VAT returns are not yet a reality, NAV is actively exploring ways to streamline the filing process through technology.
• The trend is towards greater integration of tax compliance into business operations, requiring close collaboration between tax, finance, and IT departments.

INDEPTH ANALYSIS

Electronic Invoicing (E-Invoicing) in Hungary

• Current Mandates: Hungary does not yet mandate B2B electronic invoicing for all businesses – companies may still issue invoices on paper or PDF, as long as they comply with data reporting obligations. E-invoicing is voluntary in the private sector, except for certain cases (notably a new sector-specific mandate in 2025 – see below). The law (Act CXXVII of 2007 on VAT) permits invoices to be issued electronically or on paper, and contracting authorities (public sector) must accept e-invoices that guarantee authenticity and integrity. In practice, many businesses have adopted e-invoices on a voluntary basis, often via the NAV online system, but it is not universally compulsory. [ec.europa.eu], [taxopolis.eu] [ec.europa.eu] [taxopolis.eu]
• B2G (Business-to-Government): Since April 2019, in line with EU Directive 2014/55/EU, Hungarian public authorities are required to accept e-invoices from suppliers. However, suppliers to the government have not been forced to issue e-invoices – they can choose electronic or paper format, as long as the invoice’s authenticity and content integrity are ensured (e.g. via qualified e-signature or EDI). In other words, e-invoicing in public procurement is enabled but not exclusive (the supplier’s consent was required under old rules). The requirement was that the government must be able to receive structured e-invoices, rather than an outright obligation on businesses to use them. [ec.europa.eu] [ec.europa.eu], [ec.europa.eu]
• New 2025 Energy Sector Requirement: Beginning 1 January 2025, Hungary is introducing mandatory electronic invoicing in the energy sector. Electricity and natural gas suppliers will be required to issue e-invoices (no paper) for sales to all non-private (business) customers. This mandate, set by Government Decree no. 273/2007 (for electricity) and 19/2009 (for gas) as amended, means utility companies (electricity traders, gas distributors, etc.) can no longer send paper invoices to business clients. There is no prescribed single format or platform in the decree – any e-invoicing method allowed by the tax authority can be used. (In practice, this means suppliers may use the existing NAV Online Számla system or other compliant e-invoice solutions that meet Hungarian requirements.) Business customers in these sectors must also archive received invoices electronically, since Hungarian law mandates electronic archiving for e-invoices. Aside from this sector-specific case, no general B2B e-invoice mandate is in force as of 2025. [kpmg.com]
• Structured Format: When Hungarian businesses do choose to issue electronic invoices, the invoices must be in a structured data format that allows automated processing. The NAV “Online Számla” system uses XML schemas (version 3.0 as of 2021) for invoice data. In fact, the real-time reporting XML can serve dually as an e-invoice: the schema includes a field where the issuer can indicate that the transmitted XML is not only for reporting to the tax authority but also constitutes an electronic invoice for the buyer. In such cases, the buyer can download the invoice from the NAV system and it is considered delivered. Outside of the NAV system, other structured formats (e.g. EDIFACT/EDI or the EU standard EN16931 XML format) are also acceptable as long as they meet legal requirements (e.g. contain all required fields and ensure authenticity/integrity). Plain PDF invoices (unstructured) are not considered “electronic invoices” under upcoming EU rules – the EU’s “VAT in the Digital Age” plan will redefine an e-invoice strictly as a file of structured data. (Hungary’s current law still allows PDFs as invoices, but once e-invoicing becomes mandatory EU-wide, PDFs would no longer qualify without accompanying structured data.) [kpmg.com] [taxopolis.eu] [ec.europa.eu] [rsm.hu]
• Scope of Use: Any Hungarian VAT-registered taxable person can issue electronic invoices if they wish (or where required). This includes domestic B2B transactions, B2C transactions (with the customer’s consent to receive e-invoices), and cross-border sales. For B2G transactions, while not mandatory for suppliers, many choose to send electronic invoices to public bodies (since authorities are capable of receiving them). The new 2025 rule compels e-invoicing only in the specific context of energy utilities to business customers. Looking forward, broad B2B e-invoicing mandates may come: EU proposals would allow Member States to mandate e-invoicing without special permission starting 2024, and envision mandatory e-invoicing for all intra-EU transactions by 2028. Hungary is actively preparing for this future – its policy direction is to encourage e-invoicing via the existing reporting infrastructure, likely paving the way for a general mandate once EU law permits it. [ec.europa.eu] [kpmg.com] [rsm.hu] [rsm.hu], [rsm.hu]
• Data Requirements: An electronic invoice in Hungary must contain all the same information as a paper invoice required by the VAT Act – seller and buyer details (names, addresses, tax IDs/VAT numbers), invoice number and date, date of supply, description and quantity of goods/services, unit prices, taxable amount, VAT rate and amount, etc. The NAV XML schema for invoice data encompasses all these fields. If the invoice is issued in a foreign language or currency, the law may require additional data: for example, invoices in foreign currency must include the applicable exchange rate or the HUF conversion. All this information is captured in the electronic report/invoice file. In essence, the format is an XML that mirrors the content of a full invoice as per Hungarian VAT law. [avalara.com] [kpmg.com]
• Process & Submission: When using the NAV system, invoice data is transmitted in real time to the tax authority (see “E-Reporting” below) and can simultaneously be delivered to the customer electronically. The seller’s software generates the invoice and sends the XML through a secure API to NAV immediately upon issuance; NAV validates it and returns a confirmation. If that XML was marked as an e-invoice, the buyer can retrieve it from NAV’s online portal, fulfilling both legal reporting and delivery to the buyer in one step. Businesses not using the NAV system can still issue e-invoices by other means (for instance, via EDI networks or emailing a signed XML/PDF) – in such cases, they still must report the data to NAV’s system within the real-time deadlines. Notably, issuing an e-invoice fulfills the reporting obligation if done through NAV: sending the invoice via the Online Számla platform (with a hash code) is explicitly recognized as a way to meet the real-time reporting mandate. [avalara.com] [kpmg.com] [kpmg.com]
• Archiving Requirements: Electronic invoices must be archived in their electronic form. Hungarian law stipulates that if an invoice is electronic (meaning issued in a format suitable for automated processing), it cannot be printed to paper for official storage – instead, it should be kept digitally with guarantees of integrity and legibility for the required retention period. Typically, e-invoices are stored with either a qualified electronic signature/timestamp, in a secure document management system, or by the tax authority’s system itself. Businesses must ensure e-invoices remain accessible and unaltered for 8 years (the standard retention period for invoices). [kpmg.com] [taxopolis.eu]
• Penalties for Non-Compliance: While Hungary’s VAT law does not have a separate fine specifically for failing to use e-invoicing (since outside of the energy sector it’s not obligatory), compliance issues related to invoicing can attract penalties. For example, if a utility company in 2025+) were to issue paper invoices in violation of the new e-invoice mandate, the tax authority could impose sanctions for violating invoicing rules. Generally, improper invoice issuance (e.g. not meeting format/content requirements) or failure to comply with any invoicing obligation can result in a default fine under the Tax Procedures Act. In practice, the authorities have focused more on the data reporting aspect (penalizing failures in real-time reporting – see next section). As e-invoicing becomes mandatory, we can expect administrative fines per invoice or per audit finding for non-compliance, similar to the HUF 500,000 per invoice fine used in the reporting system. Additionally, issuing invoices in a non-approved manner could lead to the invoice being deemed invalid for VAT purposes, which might trigger further tax assessments or audits. In short, businesses must follow any e-invoicing mandates to avoid fines or disputes. (The energy-sector decree itself doesn’t list a unique penalty, meaning general tax penalty rules apply for lapses.) [avalara.com] [kpmg.com]

Real-Time Invoice Data Reporting (E-Reporting via Online Számla)

• Implementation Timeline: Hungary phased in real-time invoice reporting as follows:
  • July 1, 2018: RTIR went live for the first time. Initially, it applied to domestic B2B invoices with VAT ≥ 100,000 HUF (approximately €320). Any taxpayer registered for VAT in Hungary issuing an invoice meeting that VAT threshold to another Hungarian taxpayer had to transmit the invoice data automatically and immediately to NAV’s online system. This was one of Europe’s first real-time reporting mandates and effectively replaced the old requirement of filing domestic sales listings with the VAT return. [ec.europa.eu]
  • July 1, 2020: The scope was significantly expanded. The VAT amount threshold was abolished, meaning all domestic invoices between taxable persons (B2B and B2G) became subject to real-time reporting, regardless of the invoice value. From this date, any invoice issued by a Hungarian business to another business or public authority in Hungary had to be reported, even if the VAT on it was a few forints. This change was legislated in 2019 and confirmed in mid-2020 as part of the budget tax amendment. [sovos.com], [sovos.com] [kpmg.com]
  • January 1, 2021: The mandate was extended to virtually all invoices, including those issued to non-taxable persons (B2C) and for cross-border transactions. From 2021 onward, invoices issued under a Hungarian VAT number to anyone, anywhere must be reported. This brought B2C sales, intra-Community supplies (EU), and exports into the reporting net. (Previously, if you sold to a private individual or to a foreign company, those invoices were outside the domestic listing requirement – but the new rules closed that gap.) Certain specific scenarios were also included, e.g. self-billed invoices and other special cases, with only a few exemptions (see scope below). The government’s aim in 2021 was not only to improve compliance but also to use the complete data to potentially pre-fill VAT returns. [kpmg.com], [sovos.com] [kpmg.com] [kpmg.com]
  • January–March 2021: A grace period was provided for businesses to adjust to the broadened scope. The Tax Authority announced it would not levy penalties for failures in the new reporting requirements until March 31, 2021, provided the taxpayer was registered in the system and acting in good faith to comply. This 3-month leniency covered the inclusion of B2C and cross-border invoices and the transition to a new data format (v3.0). [kpmg.com], [sovos.com]
  • April 1, 2021: Mandatory use of the new XML schema v3.0 kicked in. The Online Számla system had been upgraded to version 3.0 of the XSD, which, among other things, anonymizes certain personal data on B2C invoices (the buyer’s name/address isn’t transmitted to NAV for privacy). From April 2021, only the 3.0 schema is accepted (the older 2.0 was deprecated).
    (Post-2021 developments: NAV continues to refine the system; for example, in 2025 it introduced stricter validation – many warnings became errors as of Sept 2025 – to improve data accuracy. These technical changes underscore that the system is maturing, but the fundamental scope (all invoices) remains unchanged.) [sovos.com] [kpmg.com] [wts.com], [wts.com]
• Transactions in Scope: Virtually all transactions that involve an invoice under Hungarian VAT rules are in scope for real-time reporting. In summary: if a business registered for VAT in Hungary issues an invoice, it must report the data (with only a few exceptions). Key inclusions and exclusions:
  • Domestic Sales (B2B and B2G): All domestic B2B invoices are reportable, no matter the amount. Initially only high-VAT invoices were included, but since 2020 every invoice between two Hungarian taxpayers is covered. This also includes B2G invoices (business to government): a company billing a Hungarian public institution must report that invoice too. [sovos.com] [avalara.com], [avalara.com]
  • Sales to Consumers (B2C): Since 2021, invoices issued to non-taxable persons (e.g. private individuals) must be reported as well. For example, if a business issues a paper invoice to a retail customer (in lieu of a cash register receipt), that invoice’s data goes to NAV’s system. (However, purely cash register receipts are handled by a different online system; standard retail receipts aren’t “invoices” and thus are outside this system). If a B2C invoice is issued, NAV only receives anonymized buyer data (no personal name/address) due to privacy rules. [kpmg.com] [kpmg.com]
  • Intra-EU and Export Sales: Intra-Community supplies (ICS) of goods from Hungary (which are zero-rated intra-EU sales) and exports of goods outside the EU must be reported. Likewise, services with a place of supply abroad (where Hungarian VAT is not charged, e.g. reverse-charged services to an EU business) also fall under reporting if an invoice is issued. Essentially, even if an invoice is ultimately not subject to Hungarian VAT, as long as it’s issued by a Hungarian VAT-registered entity under its VAT number, it triggers a reporting obligation (unless another specific system covers it, like OSS). [kpmg.com]
  • Foreign VAT-Registered Entities: If a foreign company is VAT-registered in Hungary (has a Hungarian VAT number) and issues an invoice under that Hungarian VAT number (for example, a German company selling goods warehoused in Hungary to Hungarian customers), those invoices also must be reported in real time. The law’s wording captures “any invoice issued under a Hungarian VAT number,” which includes non-resident taxpayers operating in Hungary. [avalara.com] [kpmg.com]
  • Special Cases & Exceptions: There are a few carve-outs defined in the NAV guidance and legislation: [kpmg.com]
    • One-Stop-Shop (OSS) transactions: Distance sales from Hungary to consumers in other EU countries, if the seller is registered under the EU OSS scheme in another country, do not require Hungarian real-time reporting (since those sales are reported via OSS separately). Similarly, distance sales to Hungary reported under OSS by a foreign seller are not in this system. [kpmg.com], [kpmg.com]
    • Reverse-Charge Scenarios: If a foreign business sells in Hungary and the sale is subject to domestic reverse charge (i.e. the Hungarian buyer self-accounts for VAT), and the foreign seller has no Hungarian VAT number, then the foreign seller’s invoice is not reported in this system (they’re not in NAV’s domestic database). Conversely, if a Hungarian seller has a domestic sale that is reverse-charged (e.g. selling construction services where VAT is reverse to the customer), that invoice is reported because it’s issued under a Hungarian VAT number (the system will note it as reverse charge). The only nuance: if the invoice is issued by the customer (self-billing) in a reverse-charge deal, the supplier doesn’t report it (the customer might, as part of their own outgoing invoices). Self-billing cases were adjusted in the rules by 2021. [kpmg.com], [kpmg.com]
    • Import VAT: Import VAT is declared via customs/import processes, not via an invoice from a supplier, so those transactions aren’t directly in this invoice reporting system. (If a Hungarian company imports goods, there isn’t an “invoice” with Hungarian VAT – the VAT comes from the customs declaration.) [kpmg.com]
    • Agricultural flat-rate compensation receipts: Special documents in the agricultural sector (where farmers under the flat-rate scheme issue receipts to buyers for a flat-rate comp) are exempt from this reporting.
      In practical terms, almost every invoice a company issues with their HU VAT ID gets reported, except OSS-covered B2C sales and a few technical exceptions. Even domestic self-billing and certain VAT-exempt invoices are generally reported. The scope is one of the broadest in Europe. [kpmg.com]
• Taxable Persons in Scope: All VAT-registered taxpayers in Hungary are subject to this obligation. This includes Hungarian companies, Hungarian sole proprietors, as well as foreign companies that obtained a Hungarian VAT number for their operations. If you have a Hungarian VAT ID and issue an invoice under it, you must comply. There are no size or turnover exceptions (small businesses must do it too, unless they operate exclusively under the VAT exempt small–taxpayer regime without issuing invoices with VAT – but even then, if they issue an invoice showing VAT or even just indicating their tax number, safer to report it). In effect, anyone who issues invoices that fall under the Hungarian VAT law’s invoicing requirements is included. Even entities who are VAT-exempt but choose to issue VAT invoices (like opt-in taxation) would have to report. The system was rolled out universally – Hungary did not carve out SMEs, apart from providing free tools to help them comply (NAV provided a web portal and XML upload interface, and even a mobile app, for those issuing invoices manually). [avalara.com]
• Data to Be Reported: When an invoice is issued, the required data must be sent to NAV’s central system in a structured format. The data essentially mirrors the full content of the invoice. According to the law, the “data content prescribed by the VAT Act” must be transmitted, including: [sovos.com]
  • Invoice Identification: Invoice number, issuance date, and, for modifications, references to the original invoice (credit/debit notes or cancellation info).
  • Supplier information: Name, address, and tax number (VAT ID) of the issuer. (If the supplier is part of a VAT group, the group’s tax ID is used as per rules.) [avalara.com]
  • Customer information: Name, address, and (for B2B) tax number of the buyer. Note: For B2C invoices, the buyer’s name/address need not be reported to NAV – the system uses a dummy code to anonymize private customer details. For EU customers, the buyer’s VAT ID (if any) is included as well. [avalara.com] [kpmg.com]
  • Line-item details: Description of goods or services, quantity, unit of measure, unit price, and net amount per line. The system requires line-level data for each item on the invoice.
  • Tax details: The VAT rate applied, the net taxable amount, and VAT amount for each VAT rate category on the invoice. If an item is exempt or reverse-charged, the appropriate code or note is included (the XML has fields for marking tax-exempt or reverse-charge items). There are codes for special VAT treatments as well. [avalara.com]
  • Additional info: Certain cases require extra data by law. For example, if an invoice is issued in a foreign currency, the currency code and the exchange rate used to convert to HUF (for VAT reporting) must be reported. If an invoice’s transaction is outside the scope of Hungarian VAT (e.g. service delivered abroad not taxed in HU), that fact is reported so NAV knows why no VAT is on it. Also, the invoice payment due date and payment method can be included (though not strictly required by VAT law, the schema allows it). [kpmg.com]
  • Summary data: Total invoice amount, total VAT amount, etc.
    In short, the entire content of the invoice is sent, ensuring NAV has a mirror copy of what was issued. The format is an XML file (using NAV’s defined XSD schema) transmitted over the internet. NAV also provides a web form where users can input this data manually for each invoice if they don’t have an automated system – which essentially is the same data set, just entered by hand. [avalara.com]
• Reporting Method and Deadline: Reporting must occur essentially immediately as the invoice is issued. The law phrases it as reporting “without delay, immediately, by automated means, without human intervention”. In practice: [ec.europa.eu]
  • If invoices are generated by software, the software must transmit the data automatically in real time (immediately upon finalizing the invoice). The invoice should be reported before or at the same time as it is handed to the customer. This is why most companies integrated their ERP/invoicing systems with NAV via API. The transfer is machine-to-machine (M2M) via a secure REST API (HTTPS) to the Online Számla system. The taxpayer’s system gets back a response (a confirmation ID or any error codes) instantly. If the invoice is successfully reported, the seller can then deliver the invoice to the buyer (or simultaneously, if using NAV as delivery channel). Legally, the requirement is “immediate” – in practice, this means within seconds. Failing to report within a short window (NAV’s guidance used to allow a very short grace in case of technical issues, but essentially it’s real-time) can be considered non-compliance. [avalara.com]
  • If invoices are issued on paper or by a non-integrated method (like using a pre-printed invoice book, or a small software that can’t transmit automatically), the taxpayer is still responsible for reporting those invoices. NAV provides a web interface where such invoices must be entered manually within a set time limit. Initially, for the 2018 version, the rule was that if the invoice VAT ≥ 100k HUF, you had to report within 1 day; if <100k, within 5 days. But since 2020 when all invoices are in scope, effectively all invoices need reporting ideally within 1 day. Indeed, from 2021 with no thresholds, the expectation is essentially immediate for all. However, NAV likely permits a short grace for manual entry – practically a 5-day maximum delay for small invoices was previously mentioned, but one should assume as tight a deadline as possible to avoid any risk of fines. Many small businesses avoided this by either moving to electronic invoicing software (NAV offers a free invoicing tool online) or just ensuring they input the invoice data the same day. [ec.europa.eu]
  • No periodic batch option – it’s not like the old system of reporting invoices monthly; it’s continuous. The data goes invoice-by-invoice in real time. The Online Számla system is available 7×24 and the obligation applies at all times (there’s no “end of month” submission; each invoice is an individual submission).
  • Acknowledgment: NAV’s system validates each submission and returns an acknowledgment with a unique ID. If the submission has errors (schema errors or certain logical errors), it will be rejected and considered not reported. The taxpayer must correct and resend quickly. As of 2025, NAV has tightened what constitutes an error – many conditions that used to be mere warnings now cause rejection (e.g. certain VAT mismatches). So effectively, reporting is only compliant once NAV returns a “received” status. If a company repeatedly fails these validations, those invoices might end up unreported (triggering penalties unless fixed). [wts.com], [wts.com]
• Penalties for Non-Compliance: Hungary imposed and strictly enforces heavy penalties for failures in invoice reporting. Key points on penalties:
  • Fine per Invoice: Failure to report an invoice in the real-time system can result in a penalty up to 500,000 HUF per invoice. This is roughly €1,200 per invoice omission. This fine can be applied for not reporting at all, reporting late, or reporting incorrect data that is deemed non-compliant. In practice, NAV could penalize each individual invoice that wasn’t properly reported. Early on, authorities signaled they would focus on egregious cases, but the law allows stacking fines which can become enormous for systematic neglect. For example, if 10 invoices were not reported, fines could reach 10 × 500k = 5 million HUF. The penalty applies to the issuer of the invoice (since it’s their duty to report). [sovos.com], [avalara.com]
  • Software Compliance Penalty: There are also penalties if a company uses invoicing software that does not comply with the requirements (e.g. if it doesn’t include the real-time reporting function, or if it allows invoice cancellation without reporting). The law can fine the developer of non-compliant software and/or the user of such software. Essentially, businesses must ensure their invoicing systems are updated to meet NAV specs, or they could face sanctions for using inappropriate tools. [sovos.com]
  • Administrative vs. Criminal: These fines are administrative (tax penalties). In extreme fraud cases (like deliberately not reporting many invoices to evade tax), criminal charges could apply separately, but for routine compliance, it’s monetary fines and possibly default interest on any unpaid tax discovered as a result.
  • Grace Periods: As noted, there was a grace period until Mar 31, 2021 for the new scope. Beyond that, NAV has grown increasingly strict. By 2025, with validations tightening, businesses are expected to have near-perfect reporting. [kpmg.com]
  • Audit Triggers: Aside from formal fines, failure to report or inaccurate reporting greatly increases audit risk. NAV cross-checks sales and purchase data. For instance, if a buyer’s VAT return claims input VAT on an invoice that the supplier failed to report, NAV’s systems flag a discrepancy. This can prompt an audit or at least a notice to both parties. NAV has explicitly noted that inaccurate or missing data can lead to audits and other “serious risks”. Thus, non-compliance doesn’t just bring fines, but also the possibility of a deeper investigation into one’s tax affairs. [wts.com]
  • Enforcement: Hungary’s tax authority has been actively using the RTIR data to enforce compliance. E.g., in 2022 NAV performed sweeps to ensure all businesses had registered for the online system. In 2023–2024, as data quality rules tightened, companies received warning messages for errors. By late 2025, many of those warnings turn into blocking errors, meaning if you don’t fix your data, you literally cannot report the invoice (hence you’d be non-compliant and subject to penalty). This underscores that the system is now a core part of VAT enforcement – it’s practically impossible to hide sales without NAV noticing. [wts.com]
  • In sum, the penalties max out at HUF 500k per invoice for non-reporting, and this serves as a strong deterrent. Companies have had to invest in IT solutions to avoid these fines. If caught in non-compliance, aside from monetary fines, a business might lose its “reliable taxpayer” status (a certification in Hungary that gives certain procedural benefits) and be subject to closer scrutiny. NAV’s own presentations stress real-time reporting as a major anti-fraud tool. [avalara.com]
• Benefits and Impact: It’s worth noting that Hungary’s e-reporting system has been credited with reducing VAT fraud and improving compliance. The European Commission’s 2022 report on VAT Gap highlighted that Hungary’s VAT gap fell significantly (to ~5.1% in 2020, one of the lowest in the EU) following the introduction of online invoice reporting. The immediate visibility of transactions has disincentivized under-reporting. Additionally, businesses have found some benefit in that they, too, can cross-check data (NAV allows taxpayers to download data of their incoming invoices, helping them validate their purchase records). The system also laid groundwork for future simplifications like pre-filled returns (discussed later). [rsm.hu]

SAF-T in Hungary (Standard Audit File for Tax)

• Status and Timeline: Hungary began work on implementing SAF-T several years ago, recognizing the benefits for tax audits. In 2019, the tax authority launched a project to create a Hungarian SAF-T system. By 2020-2021, NAV had drafted the SAF-T HU schema and even conducted a public consultation (completed in early 2022) on the proposed structure. Initial unofficial timelines suggested SAF-T reporting could become mandatory by late 2022 or early 2023. However, this timeline was postponed, partly due to the COVID-19 pandemic and the focus on other digital systems. As of late 2025, Hungary has not introduced a compulsory SAF-T filing for all companies – there has been no law enacted that sets a start date for mandatory SAF-T submissions. Instead, NAV has been refining the concept. The latest information (mid-2025) indicates that while the SAF-T schema is ready, the legal implementation is still pending. In the interim, NAV can request SAF-T-like data during audits (see below), but there’s no routine SAF-T return that taxpayers must file periodically yet. It’s expected that Hungary will eventually mandate SAF-T (possibly first for large taxpayers) once the system is fully tested and aligned with EU developments (the EU is considering standard transaction reporting which overlaps with SAF-T goals). [kpmg.com] [snitechnology.net] [marosavat.com] [rsm.hu]
• Scope (Who and What Will Be Covered): The Hungarian SAF-T (often called “SAF-T HU”) is designed to capture a wide range of a company’s financial and tax data in a standardized XML format. NAV has tailored it to Hungarian accounting and tax rules. When it comes into force, it will likely apply to all taxpayers or at least larger enterprises, requiring them to generate this file from their ERP/accounting systems either on a regular basis or upon request. Even now, NAV has the authority during a tax audit to demand electronic export of accounting data, and the SAF-T HU schema provides a template for that. Currently: [grantthornton.hu], [grantthornton.hu]
  • On Request for Audits: NAV can ask a company under audit to provide certain data electronically. With the SAF-T HU schema available, companies are expected to be able to export their records in this format if asked. Indeed, the VAT law (or audit rules) were amended to say businesses must have their systems ready to produce data files as required by the tax authority. In practice, for now this is mainly during targeted audits or compliance checks. For example, if undergoing a comprehensive VAT audit, NAV might say “please provide your sales ledger, purchase ledger, general ledger for the period in SAF-T HU format.” Companies that cannot might face delays or penalties under general rules for non-cooperation. [grantthornton.hu] [marosavat.com]
  • Future Mandatory Filings: When SAF-T HU becomes fully mandated, it could be required periodically (e.g. monthly or quarterly), similar to how e.g. Poland requires monthly SAF-T (JPK) files. Or Hungary might require it annually or just as an audit prerequisite. NAV had indicated it might introduce SAF-T in stages. For instance, they might start with large taxpayers or certain industries. The Grant Thornton Hungary summary notes that SAF-T HU may “in the future become a mandatory reporting format for specific taxpayer groups (e.g., large corporations, those with transfer pricing obligations)”. In any case, all companies should be prepared because the scope of data is very comprehensive, meaning virtually any business’s accounting data falls under it. There aren’t “transaction type” limits like e-invoicing; SAF-T covers all financial records (invoices, ledger entries, etc.), not just VAT invoices. [grantthornton.hu]
• Data Content of SAF-T HU: The SAF-T HU schema is extensive, aiming to mirror the entirety of a company’s bookkeeping relevant for tax. According to NAV’s design and consulting documentation: SAF-T HU is an XML file (or set of files) comprising multiple sections of data. It’s structured by different XSD schemas (currently 14 schemas), each covering a specific domain of data. Key components include: [grantthornton.hu], [snitechnology.net] [grantthornton.hu]
  • Master Data: This section includes static reference information such as the chart of accounts, master lists of customers and suppliers, product master data, and other reference tables. Essentially, it defines the entities used in the transactions (accounts, business partners, items). NAV wants this to interpret the transactional data correctly. (For example, master data would link customer IDs to names/VAT numbers, product codes to descriptions, etc.) [snitechnology.net] [grantthornton.hu]
  • Transactional Data: This is the bulk of the operational data. It covers all accounting entries and invoices. Within this:
    • General Ledger entries (all journal entries, with headers and lines). This shows the accounting movements on each account. [snitechnology.net]
    • Accounts Receivable (Sales invoices): including invoice header (SIH) and invoice lines (SIL) for each outgoing invoice. This overlaps with what the online invoice system captures, but SAF-T likely goes deeper (e.g. linking to GL postings, payments). [snitechnology.net]
    • Accounts Payable (Purchase invoices): purchase invoice headers (PIH) and lines (PIL) for each incoming invoice the business recorded. This is data that the real-time reporting system doesn’t have (since it only knows what others issued, not what you recorded as purchases and when), so it’s particularly useful for audits. [snitechnology.net]
    • Payments: Data on payments made and received (PYH/PYL), possibly including allocation of payments to invoices. This helps NAV see if and when invoices were paid, which can be useful in fraud detection (e.g. circular trading patterns). [snitechnology.net]
    • Stock Movements: Movements of goods (inventory records) – this could detail warehouse receipts, deliveries (could be the MGH/MGL mentioned). Relevant for verifying trading companies’ declared inventories and cross-border shipments. [snitechnology.net]
    • Fixed Assets transactions: Acquisitions, disposals, depreciation of fixed assets (ATD schema). [snitechnology.net]
    • Essentially, every financial event that affects tax can be included. The Hungarian SAF-T notably goes beyond the OECD core by including things like detailed cash register data or analytical tables (ATB), though specifics on those are technical. NAV has said they want more data than the basic OECD SAF-T, to suit Hungarian audit needs. [rsm.hu]
  • Reporting/Analytical Data: This section compiles information relevant to tax filings or overviews, such as:
    • Physical stock summaries (inventory levels) at period ends (PYS), [snitechnology.net]
    • VAT return data (VAT analytic data): a summary of VAT amounts by categories as would be reported. Possibly a cross-check to what was actually filed. [snitechnology.net]
    • Outstanding receivables and payables: lists of open customer invoices (COI) and open supplier invoices (COS) at a given date. This helps NAV see if a company might have undeclared sales (e.g. if there are recorded sales invoices that never made it into a VAT return) or unpaid liabilities. [snitechnology.net]
    • Other declarations (the design mentions an “analysis table” and others which might be management accounting data or some summary the system uses).
      In short, SAF-T HU is comprehensive – it’s not limited to VAT invoices; it encompasses all accounting data that a tax auditor might want to examine. The file(s) must be generated exactly according to NAV’s XML schema definitions so that they can be automatically processed by audit software. This allows NAV to run algorithms on the data to detect inconsistencies or audit targets. [grantthornton.hu]
• Format and Submission: SAF-T HU is an XML-based format aligned with the OECD SAF-T standard but expanded for Hungary. NAV has published the XSD schemas (14 of them) which taxpayers’ systems must use to format the data. The expectation is that companies will extract data from their ERP/accounting software and convert it to the SAF-T XML using either in-house tools or third-party solutions. The file(s) would then be submitted electronically to the NAV (likely via an online portal or API). NAV indicated it will provide a portal for upload when it goes live. Because the data volume can be huge, the SAF-T files might be separated into pieces (the schema is modular) – but with clear rules (e.g. each file only one type of data). For now, since routine submissions are not mandated, submission occurs upon request: for instance, during an audit, NAV might ask the taxpayer to export and send the SAF-T for the audited period. Typically, the taxpayer would then upload the XML (possibly compressed, given size) to NAV’s system or provide it on secure media. When SAF-T becomes a regular obligation, NAV will surely define a deadline (e.g. “by the 20th of each month, submit the previous month’s SAF-T”) if periodic, or simply require it with the VAT return. However, currently (2025) there is no fixed periodic SAF-T filing requirement – it’s “prepare when asked.” [grantthornton.hu], [grantthornton.hu] [grantthornton.hu] [snitechnology.net]
• Penalties for Non-Compliance: Since SAF-T HU is not yet a formal filing obligation for all, there isn’t a specific new penalty schedule in force for it. However, if a taxpayer under audit fails to provide the requested electronic data in the format specified by NAV, the tax authority can resort to general provisions. Under Hungary’s Tax Administration rules, failing to comply with an audit data request or keeping inadequate records can lead to penalties. NAV might impose a default penalty for not supplying the SAF-T on request, and in extreme cases, it could estimate the tax base (if records are deemed not provided or unusable). Once SAF-T becomes mandatory routine reporting, we can expect explicit penalties similar to RTIR – likely fixed fines for late submission or incorrect format. Other countries impose hefty fines (in Poland, e.g., late SAF-T can mean per-report fines). Hungary’s approach might mirror the invoice reporting: a per-occurrence fine or one tied to the size of the company. Additionally, not having your systems SAF-T ready could itself be a breach – NAV requires taxpayers to maintain electronic records in a retrievable form. So companies should already ensure that they can export SAF-T data. In summary, until the SAF-T mandate is official, penalties arise case-by-case during audits (for non-cooperation). Looking forward, non-compliance with SAF-T (once obligatory) would likely incur administrative fines and increased audit scrutiny. [marosavat.com]
• Relationship with Other Systems: Hungary’s SAF-T initiative complements the real-time invoice reporting. In fact, the real-time data means NAV already has all sales invoice data; SAF-T will give them the full accounting context (purchases, ledger, etc.). NAV has mentioned that having complete SAF-T data combined with the live invoice data will enable advanced analytics to detect VAT mismatches, verify compliance, and even eventually streamline tax return preparation. The SAF-T HU project has been occasionally referred to alongside an “eVAT” system, since both aim to leverage data for easier VAT administration. It’s part of Hungary’s broader digital tax strategy (which also includes things like online cash registers and the EKAER transport system). [marosavat.com]

E-Transport System (EKAER) – Electronic Road Cargo Tracking

• Implementation Timeline:
  • January 1, 2015: EKAER system went live and became mandatory for businesses transporting goods on public roads in Hungary under specified conditions. This was established by legislation in late 2014 (implements provisions in the VAT Act and Act on Tax Administration). Initially, the system covered a broad range of movements: essentially all significant movements of goods in, out, or within Hungary by truck needed an EKAER report. At the start, if a vehicle over 3.5 tons was used for transporting goods as part of a sale or intra-company transfer, the transport had to be registered in EKAER, with different rules for “risky” goods (like food, electronics) including a requirement to provide a financial security deposit. [kpmg.com], [rsm.hu]
  • 2015–2020: Over the years, the rules were fine-tuned. The government identified categories of “high-risk goods” (e.g. certain food products, building materials, textiles, etc.) that were subject to stricter controls (like mandatory security deposits or always requiring reporting regardless of quantity). Lower-risk goods had thresholds of weight or value under which reporting might not be needed. However, for the most part, from 2015 to 2020, EKAER was a wide-reaching obligation and a key anti-fraud tool for the NAV, yielding significant discoveries of tax evasion. [rsm.hu]
  • January 1, 2021: A major simplification and reduction in scope took effect. The Ministry of Finance issued Decree 13/2020 (XII.23.) in December 2020, overhauling EKAER rules from 2021. The obligation to use EKAER was narrowed to focus only on “risky” goods and large consignments. Key changes from 2021: [kpmg.com] [kpmg.com], [kpmg.com]
    • Only certain goods require EKAER reports: Specifically, goods previously classified as “high risk” (defined in NGM Decree 51/2014) remain subject to reporting. These include many food items and a set of other sensitive goods. Meanwhile, transports exclusively of non-risk goods generally no longer need EKAER unless they are very large (explained below). This was a significant reduction — it removed many low-risk products from the system’s scope.
    • Thresholds introduced: Now, even for risky goods, small shipments are exempt. The decree set weight and value thresholds. Currently, an EKAER report is required if a single transport (one vehicle, one journey) exceeds 500 kg or 1,000,000 HUF in value for risky goods, or 2,500 kg or 5,000,000 HUF for non-risk goods. In other words, if you are transporting a large load of any goods, you need to report; if it’s a smaller shipment of non-risk goods, you do not. For risky goods, the threshold is much lower, effectively capturing most commercial quantities. [rsm.hu], [rsm.hu]
    • Security deposit changes: The 2021 changes eliminated the requirement for providing a financial guarantee (deposit) for many scenarios. Previously, certain taxpayers had to post a bond to get an EKAER number for high-risk goods. After 2021, guarantees were no longer required for goods subject to 5% VAT (like some livestock, etc.) and “reliable taxpayers” had some exemptions. However, with new special rules in 2023 (discussed below), the guarantee requirement was temporarily reintroduced for some goods due to EU trade issues. [kpmg.com], [rsm.hu]
    • Penalty adjustments: Act CL of 2017 (tax rules) was amended effective 2021 to adjust penalties. From 2021, the maximum penalty for not filing an EKAER report was set at 40% of the transported goods’ value (previously it could be up to 40% anyway, but the rules were refined). Also, a flat default fine up to 500,000 HUF may be applied for incorrect or incomplete reporting (as opposed to completely missing reports).
      In essence, since 2021 EKAER is targeted at presumably higher-risk shipments, easing the burden on others. [kpmg.com]
  • 2021–2023: The scope remained focused on risky goods. However, external events led to temporary expansions in 2023. Due to the war in Ukraine, the EU allowed member states to restrict import of certain agricultural goods from Ukraine. Hungary responded by requiring an EKAER report for grain and some other “sensitive” products imported from Ukraine or other sources, even if they weren’t previously classed as risky. Government Decree 130/2023 (April 18, 2023) temporarily added certain cereals and oilseeds (wheat, corn, sunflower seeds, etc.) to EKAER reporting and reinstated a security deposit for those, from April 2023 until July 1, 2023. This was a short-term measure to monitor grain inflow. Also, in 2021 a special decree (403/2021) had added some building materials under EKAER due to price control measures, but without a security requirement. By late 2023, these extra requirements had expired or were expected to expire, so the ongoing baseline is the post-2021 structure. [rsm.hu], [rsm.hu] [rsm.hu]
  • Present: As of the latest rules (Oct 2024 as referenced by RSM), EKAER announcements are required for: [rsm.hu]
    • All intra-EU acquisitions (goods coming into Hungary from EU, or imports from outside EU) and the first domestic sale of goods not to end-consumers, if they involve road transport by a vehicle over 3.5t (or subject to toll) and the quantity/value exceeds the threshold (as mentioned: >500 kg/1m HUF for risky goods, >2500 kg/5m HUF for non-risk). [rsm.hu], [rsm.hu]
    • All intra-EU dispatches (goods sent out from Hungary) and exports, similarly if above thresholds. (Though RSM’s wording suggests the new 2023 grain rule did not affect exports or domestic outbound, focusing on incoming.) [rsm.hu]
    • In summary: EKAER now mainly targets large or risk-category goods moving in, out, or within Hungary by road. It exempts small shipments and final consumer deliveries. For example, a truckload of electronics going from a Hungarian warehouse to a store would need EKAER if it’s over 5 million HUF; a small van delivering a few boxes likely falls under thresholds and is exempt. A load of meat or sugar (risky goods) over 500 kg definitely needs reporting. A company moving its own inventory from Hungary to its depot in Austria by truck would file EKAER for that intra-Community supply. But delivering furniture to a private customer (final consumer) inside Hungary might not require EKAER because it’s a “first domestic supply to an end-user” which is not within the listed categories (only first supply not to end-user triggers EKAER). [rsm.hu]
• Taxable Persons in Scope: Any company involved in transporting goods under the covered scenarios must comply with EKAER. This includes:
  • Hungarian VAT-registered sellers dispatching goods within Hungary (to non-consumers) or exporting/intra-EU selling – they must obtain an EKAER number before shipment. [rsm.hu]
  • Hungarian buyers receiving goods from the EU (intra-Community acquisition) or from imports – typically the recipient (if they arrange transport) or sender (if they arrange) has to report; Hungarian regulations usually put the onus on the “first domestic consignee” for incoming goods to do the reporting. But the law allows either the sender or receiver to fulfill it as long as it’s done.
  • Foreign companies with a Hungarian VAT and transporting goods in Hungary (e.g. a foreign trader delivering goods to a Hungarian customer) also fall under EKAER rules. If they are the ones arranging the transport into Hungary, they likely need to handle the EKAER reporting (or their local logistic partner does).
  • In practice, businesses often delegate the technical reporting to their logistics personnel or freight forwarders, but legally the obligation is on the shipper/receiver as defined by law. If multiple parties are involved, the rules specify who must register the EKAER account and get the number (usually the seller for outbound, the buyer for inbound).
  • Exemptions: Some transports are exempt: e.g., private individuals moving personal goods are not in scope (non-commercial). Also, goods not traveling by road (rail, air, postal) aren’t in EKAER. If a small van under 3.5t is used and not subject to toll, it might bypass EKAER rules by virtue of the vehicle type (the rule specifically says vehicles subject to toll or over 3.5t). This might exclude light deliveries, but one must be cautious – many delivery vans still count if they pay toll for certain roads. [rsm.hu]
  • Notably, EKAER is focused on taxable persons (businesses). It’s part of tax control, so it doesn’t target occasional non-business transports.
• Data and Process: To comply with EKAER, a company must register the shipment in NAV’s EKAER system and obtain an EKAER number before the goods commence road transport. The data required includes:
  • Who: The name, address, and tax number of the sender and the recipient of the goods.
  • What: Detailed description of the goods, including commodity codes (HS codes), gross weight (in kg), and value (HUF) of the goods. If goods are “risky,” that must be indicated per their category. [kpmg.com]
  • Transport details: The vehicle’s identification (license plate number) and the route. The system often requires the vehicle plate to be provided (there’s allowance to update plate info within a short window if not known immediately).
  • Transaction details: Type of movement (intra-EU acquisition, domestic supply, etc.), date of transport commencement. If it’s an intra-EU movement, references like the transport document or order number may be included.
  • Security: If applicable (for risky goods by certain taxpayers), a security deposit must be arranged – this part has been largely reduced for many (as of 2021, reliable taxpayers and certain goods were exempt from deposit). But in the temporary decree 130/2023, even reliable taxpayers had to provide security for specific grain imports. The security is a financial guarantee (like a bank guarantee or insurance bond) amounting to typically 15% of the goods’ value, held to ensure tax compliance. This requirement generally now applies only in narrow cases. [rsm.hu]
  • Once the data is submitted through NAV’s EKAER web portal (or via API), the system issues an EKAER number for that transport. This number must accompany the goods (typically noted on shipping documents). If stopped by police or tax officers en route, the EKAER number is checked against the load.
  • Due Dates: The data must be submitted before the transport begins (for inbound, before entering Hungary; for outbound, before starting from the warehouse). Realistically, companies do it just-in-time when loading the truck. There is also a requirement to confirm receipt for inbound goods: once the goods arrive, the recipient should confirm in the system within a set time. If details change (like route or vehicle), updates must be made promptly in the system. The EKAER number is valid for a single transport and for a limited time (15 days usually). If goods aren’t transported within that window, the number expires.
  • Ex post corrections: If a mistake was made (e.g., weight was off slightly), the system allows some modifications, but generally all key data should be correct at the time of transport.
• Enforcement and Penalties: EKAER is enforced by both the tax authority (NAV) and traffic police. Trucks on Hungarian roads can be stopped and inspectors will ask for an EKAER number for the cargo. If none is provided for a shipment that requires one, or if the data does not match (e.g., truck loaded with goods not declared, or overweight vs declared weight), penalties apply:
  • The law allows NAV to impose a penalty up to 40% of the value of the goods that are unreported or incorrectly reported. This is a steep sanction intended to deter cheating. For example, if a truck carrying €50,000 of goods had no EKAER, the fine could be up to €20,000 equivalent. [kpmg.com]
  • Additionally, NAV may seize the goods or seal the vehicle until the situation is resolved or penalty paid. This ensures the potential tax loss is mitigated (this is particularly applied if they suspect the goods themselves might be smuggled or used for VAT fraud).
  • For minor mistakes or late reporting, a smaller default fine (up to 500,000 HUF) can be levied. This might be applied per incident of, say, an incorrect detail or filing after the truck already departed. [kpmg.com]
  • In 2021’s adjusted rules, NAV clarified that failing to register at all (completely missing EKAER) is the serious offense drawing up to 40% fine, whereas improper or incomplete data (e.g., slight discrepancy in weight) would generally fall under the lesser default penalty category. [kpmg.com]
  • A 2023 special case: for the sensitive grain products under the temporary decree, the government warned of fines up to 100% of the goods’ value for violations – extremely punitive, reflecting the policy urgency in that scenario. That was unusual; normally 40% is the cap.
  • Companies that consistently comply can attain “reliable taxpayer” status which (under previous rules) gave relief like no deposit requirement. Conversely, those who violate often can be tagged as “risky taxpayers,” potentially facing more frequent inspections.
  • It’s important to note EKAER enforcement is separate from invoice reporting. EKAER focuses on physical movement of goods. It has succeeded in increasing transparency of goods transport – for instance, fewer trucks of untaxed goods circulate because they risk confiscation.
• Overlap with VAT Reporting: EKAER is essentially an anti-fraud measure to catch illicit trade in real time (like hauling a truck of goods without invoice). While invoice reporting covers the invoicing side, EKAER covers the logistics side. Together, they allow NAV to match whether goods moved correspond to invoices issued. If goods moved without corresponding invoices or vice versa, it raises red flags for NAV.

Pre-filled VAT Returns and the “eVAT” System

• Initial Plan: The Hungarian government announced that, leveraging the online invoice reporting data, the tax authority (NAV) would start preparing draft VAT returns for taxpayers. The first phase was intended to cover the monthly/quarterly return for the period starting 1 October 2021, to be prepared in early 2022. In other words, by February 2022, certain businesses would receive a proposal for their Q4 2021 VAT return from NAV, which they could review, amend if needed, and accept. This initiative was dubbed the “E-VAT” system (eÁFA in Hungarian). The idea was to roll it out gradually: initially using the domestic invoice data that NAV already has, and later incorporating more data (imports, EU sales lists, etc.). [kpmg.com]
• Postponement: However, this introduction was postponed. In November 2021, due to the ongoing COVID-19 emergency, the government issued Decree 613/2021 that delayed the launch of eVAT until after the “state of emergency” ended. The state of emergency was then scheduled to last until Dec 31, 2021, implying the earliest start for eVAT would be returns due Feb 2022. Even that was uncertain, as the emergency could be extended. Essentially, the rollout did not happen in late 2021. [kpmg.com]
• Revised Approach (M2M VAT Returns): In 2022, NAV re-evaluated the concept. Rather than unilaterally generating full VAT returns for businesses (which can be complex, especially for those with adjustments, import VAT, EU reverse charges, etc.), NAV shifted towards a machine-to-machine (M2M) data exchange system for VAT returns. In October 2022, NAV had face-to-face consultations where they unveiled a new “eVAT 2.0” concept called M2M. Under this approach: [kpmg.com]
  • Taxpayers’ systems would connect directly to NAV via API to submit VAT return data and retrieve relevant information (like their invoice data, partner VAT status info, etc.). It’s more of a two-way communication: the taxpayer’s software sends the return, and NAV’s system can instantly do validations or provide data back (like what NAV knows about their sales/purchases). [kpmg.com]
  • This would simplify filing by integrating it into companies’ accounting software environment, rather than the company going to NAV’s portal to download a prepared return.
  • Essentially, the eVAT system pivoted to be an API-based filing and pre-validation service rather than NAV drafting the return for you. NAV published an XSD schema and API specs for this M2M VAT return submission in early 2023, and invited comments from developers. The goal is to modernize how returns are filed (moving away from the older XML upload via the government portal (ÁNYK) to direct system-to-system reporting). It also would allow querying NAV’s databases for data like “show me all the invoices my suppliers reported where I’m the buyer” – which helps companies double-check their input VAT. NAV indicated features like partner tax number validation, import VAT data fetch, and warning messages for anomalies would be part of this system. [kpmg.com] [kpmg.com], [kpmg.com]
  • This revised plan was under development through 2023. It appears NAV deprioritized fully pre-filled returns in favor of making filing easier and more accurate through tech.
• Current State (2025): As of now, Hungary does not provide pre-completed VAT returns to businesses. Taxable persons must continue to compile and file their VAT returns (typically monthly or quarterly, due by the 20th of the following month) as before. The difference is that they have a wealth of data available to assist them: [sovos.com]
  • Businesses can log in to the Online Számla system to download their incoming and outgoing invoice data, which can help in preparing the VAT return (essentially verifying that all sales were declared and all purchase VAT claimed matches reported invoices).
  • NAV sometimes pre-calculates summary statistics – for example, it knows the sum of your sales based on reported invoices, and can flag if your VAT return significantly deviates from that. But it doesn’t yet send you a full draft return for acceptance.
  • For small taxpayers (like sole proprietors on cash accounting), no automated VAT return exists either – they also must file returns.
• Future Prospects: The idea of NAV preparing VAT returns (“ NAV-adótervezet az ÁFA-ban”) isn’t completely off the table. It has been seen as the next logical step after the success of pre-filled personal income tax returns (where millions of individuals just accept NAV’s draft). But VAT is inherently more complex (e.g., adjustments, partial exemption, different tax regimes). The invoice data alone is insufficient for a correct VAT return in many cases. Thus, NAV’s intermediate approach is to at least provide the tools and data to make it easier for taxpayers to do it themselves (hence the M2M system to get data and pre-validate). It’s possible that after the M2M system is in wide use and NAV gathers experience, they might introduce a hybrid: for very simple taxpayers (say a domestic trading firm with no imports or special items), NAV could offer a “here’s your draft VAT return – press OK to file”. In fact, initial plans were to implement it in steps – first using only the domestic invoice data for the simplest cases, then gradually include more data types. But the postponement and redesign mean that as of 2025, no taxpayer is receiving an automatically prepared VAT return from NAV. Instead, the taxpayer must still actively file, albeit with NAV’s data at their disposal. [kpmg.com]
• Summary of No Pre-filled Returns: To directly answer the query: Hungary does not currently have pre-filled VAT returns for general taxpayers. The planned eVAT system was delayed and transformed. Businesses need to file returns by the statutory deadlines, using their own records. NAV’s comprehensive data collection (via e-invoicing/reporting and EKAER, etc.) is used on the back-end to cross-check those returns and to offer some services (like data queries, analytics), but not yet to auto-generate the return for you. The question of “whether there are any pre-filled VAT returns” – at this point, no, not for VAT (personal income tax yes, VAT no). NAV’s focus is on providing APIs and tools to make compliance easier rather than sending out a return that you simply confirm. For instance, the VAT summary report (M-sheet) that taxpayers used to manually fill (listing domestic purchases) could eventually be auto-filled from NAV’s data, but currently taxpayers still must submit it with their return. The evolution is ongoing, and Hungary is among the front-runners in aiming for real-time data-driven tax administration. We may see eVAT or a similar prefill service in the future, especially aligned with the EU’s broader “VAT in the Digital Age” reforms. [sovos.com]

• Hungarian VAT Act CXXVII of 2007, Sections 169-175 (invoice requirements and e-invoicing provisions). [ec.europa.eu], [ec.europa.eu]
• Ministry of Finance Decree 23/2014 (VI.30.) NGM (Hungarian Invoicing Decree) – governs invoice content and the real-time reporting mechanism, as amended in 2018 and 2020. [kpmg.com]
• NAV Online Számla system documentation (v3.0 XSD schema, 2021) – technical details for real-time invoice data reporting. [kpmg.com]
• Act CL of 2017 (Rules of Taxation) – sections on default penalties, including §**_ (which specifies fines for missing RTIR data up to HUF 500k per invoice) and EKAER-related penalties. [sovos.com] [kpmg.com]
• Ministry of Finance Decree 13/2020 (XII.23.) – redefined EKAER from 2021, including risk goods definition (refers to NGM Decree 51/2014) and threshold rules. [kpmg.com], [rsm.hu]
• NAV EKAER official site and Decree 5/2015 (II.27.) NGM – original EKAER implementation rules.
• Government Decree 130/2023 (IV.18.) – temporary extension of EKAER to certain grain products (Ukrainian import control). [rsm.hu], [rsm.hu]
• Big4 and advisory Newsletters/Alerts: e.g., KPMG Tax Alerts (Jan 14, 2021; Sept 15, 2020; Nov 22, 2021; Oct 20, 2022), RSM Hungary blogs (Mar 1, 2023; May 12, 2025), WTS Hungary update (June 20, 2025) – providing interpretation of new rules and confirming timelines. [kpmg.com], [kpmg.com], [kpmg.com], [kpmg.com] [rsm.hu], [rsm.hu] [wts.com]
• EU Directive 2014/55/EU on e-invoicing in public procurement – requiring acceptance of e-invoices by public bodies. [ec.europa.eu], [ec.europa.eu]
• European Commission “VAT in the Digital Age” proposal (2022) – not yet law, but relevant to future Hungarian e-invoicing plans (structured e-invoice definition, 2028 mandate). [rsm.hu]
• OECD SAF-T Standard (version 2.0, 2010) – basis for the Hungarian SAF-T HU structure. [grantthornton.hu]

• See also
  • E-Invoicing/Real Time Reporting – What can you find on VATupdate.com
  • Worldwide Upcoming E-Invoicing mandates, implementations and changes – Chronological
  • Collection of E-Invoicing Guides – Worldwide – VATupdate
• • Briefing / Comprehensive Guides (incl. podcasts)

• Join the Linkedin Group on Global E-Invoicing/E-Reporting/SAF-T Developments, click HERE
• Join the LinkedIn Group on ”VAT in the Digital Age” (VIDA), click HERE