eVAT M2M 2.0: a new milestone in VAT filing
eVAT M2M is the new logic of VAT filing: transactional data, unified NAV tax codes, pre-submission validation. The 2.0 specification stabilizes the model.
Much of the market communication around eVAT M2M still focuses on the submission channel: 'who does NAV's data reach', 'who benefits from switching', 'what incentives does NAV offer'. This framing is professionally misleading. eVAT M2M is not just a new submission channel — it is a shift in the logic of VAT filing: from form-centric operation to transactional-level data, unified NAV tax code logic, and pre-submission validation. The 2.0 interface specification published on May 14, 2026 stabilizes this model in a form that extends to changes in early 2027, ahead of the ÁNYK phase-out. In this article, we walk through what this shift means at an operational level, and how companies should approach the transition.
What is eVAT M2M, really?
The eVAT system has been operating since February 1, 2024, and offers two types of access: the web interface and the machine-to-machine (M2M) connection. The web interface logic is based on data sourced from NAV's systems — the taxpayer fills in (or approves pre-populated NAV data) on a single interface, then submits the return after reviewing the draft. M2M, by contrast, is not an interface but a data stream: structured data from the company's own systems, delivered as XML-based reporting directly to NAV.
At first glance, the difference seems technical compared to current VAT filing methods — but the real difference is logical. In M2M, the VAT return is not a 'completed form' but the structured output of VAT analytics. The return lines (07, 66, 69, etc.) are automatically generated from the transactional items transmitted by the taxpayer, coded with NAV's standardTaxCodes. The process shifts its center of gravity from submission to data production and data quality.
The three structural shifts
The eVAT M2M model rests on three mutually reinforcing pillars. These fit into NAV's new data-driven operational logic.
1. Transactional-level data
ÁNYK returns expect aggregated amounts: the tax base and tax amount for a given return line. eVAT M2M, by contrast, expects data at the transactional level — every invoice, every line item appears as a separate row in the VAT analytics, alongside the source document identifier, partner data, and other specific information. This requires higher data quality, but in return makes every element of the return traceable.
2. Unified NAV tax code logic
eVAT M2M does not use the company's internal tax codes, but the unified standardTaxCode system defined by NAV. The tax code shows which return line a given item maps to, and at what tax rate. From NAV's perspective, this means that instead of as many VAT analytics structures as there are businesses, every taxpayer provides data in the same logical structure. On the company side, this requires a clear mapping between internal tax codes and NAV's codes.
3. Pre-submission, multi-level validation
NAV performs a multi-step check on M2M data at the moment of submission. It cross-references the VAT analytics items against information from its own databases: online invoice reporting, cash register data, and the customs declaration processing system. Discrepancies and warning messages are returned to the taxpayer synchronously, before submission. The 2.0 specification specifically deepens this layer: NAV itself stated that 'one of the greatest advantages of the eVAT M2M system is the volume and client value of validations'.
The May 2026 milestone: the 2.0 interface specification
NAV published the eVAT M2M 2.0 XSD schema on March 9, 2026, and the accompanying interface specification on May 14, 2026. The most important property of the 2.0 version is the long-term stabilization of the data model: the new structure no longer contains ÁNYK field identifiers, so it will remain usable unchanged after January 1, 2027, when ÁNYK is phased out.
The 2.0 is also deeper in content. According to NAV's announcement, the specification 'contains more detailed tax-technical explanations than before, which supports implementation better than previously'.
The hardest part of implementation: data and tax codes
The hardest part of implementing eVAT M2M is typically not the interface, but getting the tax logic in order. If tax codes are inconsistent, exceptions are unregulated, or manual corrections are undocumented, the system quickly surfaces these gaps.
This may mean extra work in the short term, but it is actually an advantage. Where these problems become visible, that is where truly consistent and repeatable filing operations can first be established.
Why it is not just a standalone IT project
In mid- and large-enterprise practice, implementing eVAT M2M is not just about developing a new interface. The center of gravity lies elsewhere: the company's ERP or accounting system (typically SAP, Oracle, Microsoft Dynamics, or a custom build) determines what VAT analytics, what tax coding, and what control points underlie the data from which the M2M XML can be assembled.
Global ERP systems are, moreover, typically closed, centrally versioned software. They will not build custom development for a single subsidiary because of a Hungarian tax specificity — such as a field in the eVAT M2M XSD — and local-level modifications are typically expensive and slow. It is therefore rarely a practical solution for a company to make the ERP directly M2M-capable.
Market practice therefore distinguishes two main strategies:
Internal development — the company's IT team or a vendor implements the code that generates M2M XML from the ERP. Advantage: maximum customizability. Disadvantage: every NAV version update is its own development task, warning handling must also be solved in-house, and in-house expertise is needed for tax content accuracy.
External Tax-Tech middleware — a turnkey software positioned between the ERP and NAV (such as SimplyX). It generates valid M2M XML from the ERP's exported data, handles version updates, and displays NAV warning messages on a visual dashboard with bulk review and management capabilities. Behind the solution is typically a team of tax and technology experts.
The middleware layer works well logically because it solves exactly the two problems that companies struggle to address through direct ERP development: continuous alignment with changing NAV specifications, and effective handling of warning messages.
Today's taxpayer benefits
There are currently concrete, legally established benefits associated with eVAT M2M:
Users of the eVAT system are exempt from submitting the domestic summary report (M-sheet, K-sheet).
Self-corrections submitted via M2M within 15 days of the due date are exempt from the self-correction surcharge.
VAT returns submitted via M2M by reliably rated taxpayers are subject to a 15-day audit moratorium (except in cases of serious irregularities).
Where M2M analytics are submitted in full, the tax authority will not request additional data in a subsequent audit.
The realistic business case for eVAT M2M is not today's benefit package, but the structural shift described above: transactional-level data management, unified tax code logic, pre-submission validation, and the long-term data model stabilized by version 2.0.
How to get started
A well-structured eVAT M2M transition is not a standalone IT project, but four sequential work phases — of which only the last is technical:
| Phase | What to cover |
|---|---|
| 1. Data model assessment, data quality audit | Mapping the current structure of VAT analytics against the eVAT M2M 2.0 XSD schema. Where do items come from, with what data content, through what control points? What is the data quality, are the required data available? |
| 2. Tax code mapping | Mapping the company's internal tax codes to NAV's standardTaxCode system. Until now this was typically proprietary logic; from now on it must align with an external standard. |
| 3. Implementation decision | Internal development vs. external Tax-Tech middleware. For most, middleware is the more practical choice — not necessarily because it is faster to implement, but because it does not require large-scale IT development within the ERP system. |
| 4. Pilot + parallel run | A pilot on a stable, high-volume transaction type, then parallel verification against the ÁNYK return. Comparing the two outputs supports final validation. |
From a leadership perspective: what the CFO and finance director see
Data quality — pre-submission validations force source-system (ERP, invoicing, cash register) data quality to be maintained. Return quality is no longer a separate process, but the direct output of transactional data quality.
Auditability — every item in every return is traceable to a specific document, NAV tax code, and validation result. There is no need to 'reconstruct' how a return line was derived during an audit.
Scalability — as transaction volumes grow, the M2M model scales linearly, without a significant increase in manual control points.
This kind of transparency is especially important in a market where compliance is increasingly a question of digital operational capability. Organizations are not simply looking for new NAV channels, but for systems where compliance is predictable and less dependent on individuals.
Frequently asked questions
Is switching to eVAT M2M mandatory before 2027?
The use of the eVAT system (web or M2M) is expected to become mandatory for VAT filing from January 1, 2027, because ÁNYK reaches its last day on December 31, 2026. Choosing eVAT M2M specifically, however, is not mandatory — the web-based eVAT is also an option. M2M is specifically recommended for mid- and large-sized companies and accounting firms where transaction volume and data structure complexity justify system integration. However, it is also useful for small businesses, as it eliminates the need to manually re-make decisions that have already been defined in accounting software before preparing the VAT return. Before 2027, switching is not mandatory.
How does M2M XML differ from traditional ÁNYK filing?
ÁNYK fills in a form: the user enters aggregated amounts for return lines. eVAT M2M XML, by contrast, contains transactional-level data — every invoice, every line item as a separate row, coded with NAV standardTaxCodes. The return lines are generated from this on the NAV side. The difference between the two is not one of data volume, but of logic: we are sending analytics, not aggregates, alongside the main return data.
What does the 2.0 specification published on May 14, 2026 change?
The 2.0 interface specification includes more detailed tax-technical explanations and expanded VAT analytics data content. The data structure no longer contains ÁNYK field identifiers, so it remains usable unchanged after 2027 — this stabilizes the development investment. Version 2.0 is planned to be testable from July and will replace version 1.0 from August.
What does 'NAV standardTaxCode' mean?
In VAT analytics, every item must be tagged with a tax code uniformly defined by NAV. The tax code determines which VAT return line the item falls into, and at what tax rate. This logic unifies VAT analytics on the NAV side — every taxpayer provides data in the same code structure, regardless of what internal tax coding they use in their own system. The mapping between the two code systems is one of the key tasks of implementation.
In-house development or external software — which is the better choice?
For most, external Tax-Tech middleware is the more practical choice. Not because it is simpler, but because internal ERP transformation is disproportionately expensive and risky for a Hungarian tax specificity. The middleware generates valid M2M XML from the ERP's exported data, handles NAV version updates, and presents warning messages in a clear, reviewable format.
What will happen to the A60 data reporting?
According to NAV's May 2026 announcement, the A60 data content will not be part of the VAT analytics: it will appear as a standalone operation within the eVAT M2M system. The communication base (XML, authorization, submission protocol) will be identical to that of the VAT analytics.
Where can the official technical documentation be found?
NAV publicly publishes all technical documentation related to eVAT M2M — XSD schemas, interface specification, example XMLs, change logs — on GitHub: github.com/nav-gov-hu/eVAT. Developer questions, ideas, and comments are also answered there, in the Discussions section, directly by NAV experts.