eVAT M2M 2.0: Why Last-Minute Preparation Is Not Enough
The eVAT M2M 2.0 XSDs and specification are now available. Learn why migration is not only an IT task — and what companies should prepare before August 2026.
Several important developments have emerged around eVAT M2M version 2.0 in recent weeks. NAV published the 2.0 XSD schemas on its public GitHub repository, released the new interface specification, and practical migration questions are increasingly visible on community forums. NAV’s 2.0.1 release of 14 May 2026 confirms that the final 2.0 XSDs and the updated specification are now available.
This is good news: preparation is no longer based only on drafts and earlier samples. Deadlines remain tight, however. NAV’s earlier guidance indicates that 2.0 will be available in the test environment from early July 2026, with production rollout planned for 1 August 2026. From that date, only version 2.0 will be accepted for XML uploads.
eVAT M2M preparation should therefore not be treated as a simple IT task. The challenge is not only whether a system can produce an XML file. The real question is whether accounting, tax, and ERP processes can deliver the data quality required to produce a compliant return in eVAT M2M.
eVAT M2M is not just a technical channel change
Many companies have built internal processes around ÁNYK filing logic over years. Returns are often assembled through general-ledger reconciliations, tax analytics, or Excel-based matching. eVAT M2M expects a far more detailed, structured, and consistent data model.
This is especially challenging where:
multiple ERP or invoicing systems run in parallel;
detailed outgoing invoice data lives in a different system than accounting data;
the company uses a global ERP such as SAP, Oracle, Microsoft Dynamics, or a custom platform;
VAT coding relies heavily on internal tax codes, manual decisions, or post-hoc corrections;
special transactions are common — reverse charge, intra-EU supplies, export, import services, partially deductible VAT, apportionment, or cash accounting.
On NAV’s GitHub forum, a recurring theme is that eVAT M2M does not always map cleanly to existing accounting data models. One example: invoice-level detail sits in billing, while the accounting system holds only periodic aggregated postings.
This is not purely a technical issue. If filing data is not structured, sufficiently granular, or governed by a single logic, eVAT M2M rollout requires data-quality and process preparation before integration work begins.
A core message of version 2.0: tax logic comes first
With the 2.0 documentation published, the question is no longer whether a specification will exist, but how well companies can translate it into day-to-day operations.
Recent topics on NAV’s GitHub Discussions show the focus shifting to tax content: interpreting self-revision and corrections, reverse-charge invoices, document-level outgoing invoice reporting, XML conversion, taxpayer corrections, A60 reporting, and 2.0 XSD changes.
In practice, eVAT M2M projects require more than populating fields technically. Companies must define how each economic event is reflected in analytics with the correct tax treatment.
For example, different logic may apply to:
a standard domestic purchase;
a partially deductible phone bill;
a cost linked to a company car;
a reverse-charge purchase of iron or steel products;
an intra-EU acquisition of goods;
a prepayment linked to an export transaction;
a corrective or credit note affecting a prior period.
Public issues show these are operational questions, not theory. Posts frequently seek clarification on partial deductibility, apportionment, reverse charge, negative tax base or tax amount, exempt transactions, and special tax coding.
Tax-code mapping is a key risk, not admin work
In many companies, VAT coding has historically been built on internal ERP tax codes. Those codes often encode more than a rate — ledger logic, reporting lines, deductibility status, country rules, or manual decision points.
eVAT M2M works in NAV standard tax codes and structured analytics. Mapping ERP codes to NAV standards cannot be a simple one-to-one table.
At minimum, mapping should answer three questions:
What economic event does each ERP tax code actually cover?
Which filing logic applies to the transaction?
Are the required detail fields available in the source system?
Without clear answers, go-live often produces errors, warnings, manual fixes, or blocking validations.
The ÁNYK-to-eVAT transition needs separate attention
Rolling out eVAT M2M does not automatically simplify how earlier filing periods are managed. A dedicated GitHub question asked how to amend or self-revise ÁNYK-filed VAT returns in eVAT M2M.
NAV/NTCA clarified that VAT returns submitted on ÁNYK forms can only be self-revised on form. If a period was filed on a form basis, it cannot be self-revised via eVAT M2M or the eVAT web interface. NAV also warned that mixed ÁNYK and eVAT use across periods can create risk, especially if multiple channels are used for the same period.
Migration is therefore not only a technical cutover. Companies need a clear record of which channel was used per period, and how later self-revisions or corrections will be handled.
Why this matters especially for global ERP environments
Hungarian eVAT M2M must connect local tax requirements with a company’s global or regional ERP structure — often harder than it first appears.
In global ERPs, tax codes are frequently designed for multiple countries, business processes, or central templates. Hungarian eVAT M2M expects detailed local tax logic, document-level data, and NAV standard coding. A globally “accounting-correct” dataset may still be insufficiently granular or structured for eVAT M2M.
This is especially true when:
billing and accounting data sit in separate systems;
VAT analytics are assembled from multiple sources;
Hungarian filing logic partly lives in Excel or manual reports;
standard ERP reports do not contain all fields required for eVAT M2M;
local tax and regional IT/ERP teams do not share a common eVAT data model.
In such environments, success depends as much on aligning tax logic and data sources as on technical integration.
What to prepare now
After the 2.0 documentation release, preparation should start on practical grounds. Priority workstreams include:
1. Review tax-code mapping
Assess how current ERP tax codes map to NAV standard codes. Review not only common codes but higher-risk cases: reverse charge, partial deductibility, apportionment, export, intra-EU transactions, cash accounting, and corrections.
2. Identify data sources
Map where eVAT M2M data actually lives. Not everything will be in the general ledger or VAT report — billing, procurement, cash register, customs, or other subsystems may be required.
3. Test special transactions
A simple domestic invoice is not enough. Run scenarios typical for your business: negative lines, credit notes, partially deductible costs, cross-border transactions, and partners with mixed tax status.
4. Clarify ownership
eVAT M2M is not an IT-only project. Tax, accounting, ERP, and control functions all need owners. Decide early who owns tax-code logic, data validation, error handling, and submission status tracking.
5. Define migration and self-revision strategy
Know from which periods eVAT M2M will be used, how prior ÁNYK periods are handled, and what internal documentation supports the transition.
Conclusion
The arrival of eVAT M2M 2.0 is an important milestone. Once schemas and specifications are public, the question for companies is no longer whether there is something to build against, but whether their data, processes, and tax logic are ready.
Companies that treat eVAT M2M as XML upload only may discover too late that the hardest part is not producing the file, but correctness, completeness, and tax interpretability of the underlying data.
Successful preparation requires thoughtful tax mapping, data-quality checks, ERP alignment, and documented internal processes — not developer capacity alone.
eVAT M2M is not simply a new filing channel. It is a new operating model in which VAT processes can become more transparent, structured, and automatable — provided migration does not start at the last minute.
Frequently asked questions
When will eVAT M2M 2.0 replace version 1.0?
According to NAV guidance, version 2.0 is expected to become available in the test environment from early July 2026, with production rollout planned for 1 August 2026. From that point on, only version 2.0 will be accepted for XML uploads.
Why is last-minute preparation not enough for eVAT M2M?
Because the challenge is not only generating XML. Data quality, tax-code mapping, handling special transactions, and aligning ERP processes all matter. If these are not in place, go-live often surfaces errors, warnings, or blocking validations.
How are prior ÁNYK VAT returns handled after eVAT M2M goes live?
VAT returns filed on ÁNYK forms can only be self-revised on form. If a period was submitted on paper/form, it cannot be self-revised via eVAT M2M or the eVAT web interface. Companies need a clear record of which channel was used for each period.
Where can I find the official eVAT M2M 2.0 documentation?
NAV publishes XSD schemas, interface specifications, and related materials on GitHub: github.com/nav-gov-hu/eVAT. Technical questions are also addressed on the Discussions board.