eVAT M2M 2.0 is live: what changed with the 3 August migration
Hungary’s eVAT M2M moved to 2.0 on 3 August 2026, with no parallel operation. What changed in the schema, what the system generates, what to review.
Hungary’s production eVAT M2M system moved to XSD version 2.0 on 3 August 2026, during a maintenance window between 19:00 and 21:00. There is no transition period: NAV examined the option of running both versions in parallel and concluded that it was not realistically feasible. Submission in the 1.0 format has ended.
The change is not a matter of renamed fields. Version 2.0 removes the logic that was built around Hungary’s ÁNYK paper forms — which means work even for those who already had a functioning integration. What follows is based on NAV’s two documents: the 214-page interface specification and the accompanying XSD change list.
Who this affects, and who it does not
On first reading the news sounds more alarming than it is for most accounting practices. The 3 August switch affects those who file the VAT return through the machine-to-machine interface. For anyone whose return is prepared on the eVAT web interface, or who still works with ÁNYK, the migration changes nothing in day-to-day work.
The room to wait is finite, though. New returns can be filed through ÁNYK only until 31 December 2026, so the same question reaches everyone affected within months — by then without the ÁNYK fallback. Working through the 2.0 changes now is preparation for the year-end deadline rather than a response to present pressure.
How the migration ran
The test environment switched first: api-test.eafa.nav.gov.hu has worked exclusively with version 2.0 since 1 July 2026. Anyone still testing against 1.0 over the summer would have hit errors then. NAV confirmed the production date on 31 July, a week before the deadline.
The decision did not come out of nowhere. Between 20 and 24 July the authority polled the developer community on how ready they considered their software. Of 48 respondents, 9 said development was complete, 3 committed to being ready by 20 August, and 36 asked for more time. NAV referred to this feedback in its announcement and gave two reasons for holding the date: it saw no realistic option for maintaining both versions, and it had been monitoring successful tests and completed implementations in the test environment.
What sits behind 2.0: the interface breaks away from the form
The first version of eVAT M2M carried a legacy with it. Attachment sheets had to be supplied through a node called sheet, with fields referenced by ÁNYK field identifiers (NavFieldId). A machine interface was therefore reproducing the structure of a paper form: anyone building against it had to know which form a value belonged to, in which row, under which identifier.
Version 2.0 removes this. In NAV’s own words, the aim is for the data structure to become more self-contained, more maintainable and more coherent for machine processing. The sheet node has been deleted, attachment sheets have received their own descriptively named nodes, and the validations that applied to sheet have been replaced by new rules. That last point is the most easily underestimated part of the change: a file that passed cleanly under 1.0 will not fail because the data is wrong, but because a different rule set is now measuring it.
The declarationAdditionalData node has also been removed. Supplementary return data is now calculated by the eVAT M2M system from properly completed analytics. One field has moved as well: vpid used to sit under sheetList and now belongs under declarationInformation — a value left in the old place will not be processed.
Attachment sheets: what you fill in, and what the system generates
This is where precision matters, because it is easy to overestimate the automation. According to page 68 of the interface specification, the sheetList node is optional, and each of the eight attachment nodes within it is optional too. Exactly one attachment sheet is produced by the system: sheet 03, the indirect customs representative’s per-import declaration, which eVAT M2M generates automatically when the conditions are met. Everything else remains the filer’s responsibility.
This is how attachment sheets look in the 2.0 schema. The naming itself signals the shift: these are not numbered pages but data groups named after what they contain.
| Attachment sheet | Node in 2.0 | What it contains |
|---|---|---|
| 02 — Animal disease | animalDisease | Decision number, date the decision became final, the VAT content of the compensation, the deferrable amount. Only fillable when animalDiseaseDefermentIndicator is true. |
| 03 — Indirect customs representative declaration | — (generated by the system) | Not filled by the taxpayer. Created when the filing period is later than 1 March 2025, the tax position is deductible (DEDUCTIBLE), and importerTaxNumber is populated. |
| 04 — Self-revision | selfCheckAttachment | Self-revision data for the current return — charge base, charge amount, increase or decrease in liability — plus modification of a previous self-revision charge. |
| 06 — Bad debt | badDebt | Statement type (write-off, reimbursement, reduction of input tax), reason for settlement, fulfilment of the statutory condition, invoice and partner data. |
| 07 — Reverse charge, supply | reverseChargeSupply | Customer tax number, tax point date, customs tariff number from a closed list, quantity, hybrid seed flag, unit of measure (kg, m3, MWh), tax base. |
| 08 — Reverse charge, acquisition | reverseChargeService | The same structure, using the supplier’s tax number (supplierTaxNumber). |
| 09 — Passenger car chassis number | chassisNumberOfTheCar | Chassis number, and whether the data is reported through an indirect customs representative. |
| A88 — New means of transport | newMeansOfTransport | Customer details (name, country code, postal code) and vehicle details. Each former form row becomes one item. |
| 170 — Transfer and refund request | requestForTransferAndRefund | Tax type to be charged, tax type code and amount, again one item per row. |
On the reverse-charge sheets the field to supply is the customs tariff number (customsTariffNumber), from a closed value list: 1003 for barley, 1001 for wheat and meslin, 7213 for hot-rolled bars, and so on. The product name that belongs to the tariff number is filled automatically by the eVAT M2M system. On the same sheets, quantity is not a mandatory field, whereas the hybrid seed flag (hybridSeed) and the unit of measure (unitOfMeasure) are.
New fields in the analytics
The analytics line item (vatAnalyticsItem) has been extended as well. The most frequently misread new element is invoiceModificationOrCancellation, so here is exactly what page 50 of the specification says about it.
The value list for sourceDocumentType has gained one entry. Alongside INVOICE, RECEIPT, CUSTOMS_DECLARATION and OTHER there is now DAILY_SUMMARY, denoting a cash register’s daily close: this is how receipts from Hungary’s Online Cash Register and eReceipt systems appear, aggregated by day. The tax day for receipt data runs from the daily opening to midnight that day.
The tax information section has gained the indirectCustomsRepresentative group, containing the importerTaxNumber field. Populating it is how the filer indicates that an indirect customs representative is involved — and this field also drives the automatic generation of attachment sheet 03.
Self-revision brings one field introduced in 2026: nonStandardAllowanceCalcReason records why the self-revision charge was calculated on a non-standard basis, using codes 01 to 09, each referring to a specific statutory provision. It is not to be filled for earlier periods.
What to review in your own system
The accounting and development tasks diverge here, but they start from the same point: data quality has moved earlier in the process.
From the accounting side
Sheet 03 and the supplementary return data now come from the system, but only if the analytics are sound: automation builds on the data, it does not correct it. Where a missing tax number or a wrong tax position used to surface while completing an attachment sheet, it now propagates through the return. The real question is therefore where the analytics originate and who owns their content.
On reverse-charge transactions, the relationship between tax code and attachment sheet has become a validation matter: if the tax code is present, the sheet must be too. The two therefore cannot be handled in separate workflows.
The conversation with your software vendor can be narrowed to a few concrete questions. Does the product support the 2.0 schema, and from which version? Does it tie invoiceModificationOrCancellation to tax code MP31, or apply it generally to corrective invoices? Does it supply the customs tariff number on reverse-charge sheets, or does it still expect a product name? Has it dropped the NavFieldId-based mapping? Either the answers exist, or there is development work outstanding — there is no third option.
An unsatisfying answer is still information. Where the timeline is vague or keeps slipping, the risk is not technical but one of scheduling: new returns can be filed through ÁNYK only until 31 December 2026, and after that there is nowhere to fall back to. Channel choice and vendor readiness converge at this point, and the lead time on that decision is measured in months.
From the development side
NavFieldId-based mapping can no longer be used. Data has to be mapped to 2.0 nodes in its own structure.
The vpid mapping moves under declarationInformation, and the generation of declarationAdditionalData can be removed from your code.
Tie the invoiceModificationOrCancellation logic to the tax code rather than the document type: a true value is only valid alongside MP31.
Keeping the closed value lists current — customs tariff number, unit of measure, country code, document type — means tracking the schema.
What is still open
In its 31 July announcement, NAV promised two supporting materials for the migration: sample XML files matching the 2.0 XSD, and a FAQ document. As of this article’s cut-off, the most recent entry in the repository is still dated 31 July, so neither has appeared. The A60 XSD and its interface specification are expected during August; an important detail there is that eVAT M2M will have a single unified specification — the A60 submission process will not be separated out from it.
NAV handles questions on two channels. IT and development questions belong in the Discussions section of the GitHub repository; questions requiring legal interpretation should go through the contact form on nav.gov.hu, selecting the subject relating to legal questions on the use of the eVAT interface.
Related resources
If a submission comes back with an error, our complete eVAT validation message list contains all 101 messages from NAV’s interface specification, searchable and split into blocking and warning categories.
For a schema-level format check, use our free eVAT XML validator: the file stays in your browser, with no upload.
To look up MP31 and the other codes, all 232 entries of the standard tax code catalogue are available, downloadable as CSV and JSON.
For an overview of eVAT M2M as a whole, see our guide.
The broader preparation questions are covered in earlier articles: one on the data clean-up that precedes migration — tax code mapping, data quality, controls — and one on channel choice against the 2027 deadline.
eVAT M2M migration: what to fix before filing — getting the data, tax codes and controls behind the return in order.
ÁNYK phase-out 2027: checklist and timeline — what has to be decided, and when, before ÁNYK ends.
NAV M2M and the ÁNYK phase-out: preparing for 2027 — what this means for accounting practices.
Sources
Detailed field descriptions, mandatory rules and value lists: eVAT M2M 2.0 interface specification v1.1 (NAV, 214 pages, Hungarian)
The version change summary, with removed and relocated nodes: XSD changes in eVAT version 2.0 (NAV, Hungarian)
The 2.0 schema files: eVAT/src/schemas/hu/gov/nav/vdr
The production migration announcement: eVAT Discussions #328 (31 July 2026)
The test environment moving to 2.0: eVAT Discussions #276 (30 June 2026)
The readiness poll: eVAT Discussions #313
Questions of legal interpretation: NAV contact form