eVAT M2M 2.0 in production: what changed on 3 August?

By Kovács András

eVAT M2M 2.0 went live on 3 August 2026 with no parallel operation. See what changed in the schema, what the system generates and what you need to review.

eVAT M2M 2.0 is not a routine technical update but a genuine major-version change. It went live in production on 3 August 2026, with no parallel operation; the 1.0 format can no longer be used.

The most important change is that version 2.0 breaks away from the logic built around the structure of Hungary's ÁNYK VAT return form. In version 1.0, attachment sheets were supplied under a generic node named sheet — meaning 'page' — while ÁNYK field identifiers, known as NavFieldIds, mapped each item of data to the corresponding field on the form. In effect, the machine interface followed the layout of the ÁNYK form.

The resulting XML structure was extremely cumbersome. Although XML processing is primarily a machine task, it also made the contents of the files harder for people to interpret and review.

Version 2.0 removes this indirect mapping. Attachment sheets now have their own descriptively named nodes, so the data structure is based directly on the information being reported rather than on fields in a form. Existing integrations therefore need to be updated even if their 1.0 submissions worked without errors.

The following overview is based on NAV's 214-page interface specification and the XSD change list and explains the most important structural and functional changes.

Who is affected — and who is not?

The news may sound alarming at first, but it is not relevant to everyone. The 3 August migration directly affects businesses, accounting firms and software vendors that prepare or submit VAT returns through the eVAT M2M interface — in other words, through a machine-to-machine connection. Their systems must be adapted to the 2.0 schema.

For anyone preparing returns in the web-based eVAT interface, or still using ÁNYK for the time being, this particular version change has no immediate effect. For ÁNYK users, however, this is only a temporary reprieve: new returns can be submitted through that channel only until 31 December 2026, after which another filing method must be chosen.

This does not mean that every accounting firm must develop its own M2M integration. Anyone planning to use M2M should, however, already be checking whether their chosen software supports version 2.0.

How the migration took place

The test environment moved to version 2.0 on 1 July 2026. From that date, api-test.eafa.nav.gov.hu accepted only files prepared against the 2.0 schema; tests using the 1.0 format returned errors.

Between 20 and 24 July, NAV surveyed the developer community to assess software readiness. Of the 48 respondents, only 9 said they had completed the necessary development. Another 3 committed to finishing by 20 August, while 36 requested more preparation time.

NAV nevertheless kept the 3 August production date, confirming it on 31 July — only three days in advance. It explained that it saw no realistic possibility of operating versions 1.0 and 2.0 in parallel and that it had already observed successful tests and working solutions in the test environment.

What lies behind 2.0: the interface breaks away from the form

Version 2.0 breaks with the ÁNYK form model

The data structure of the first eVAT M2M version still followed the layout of the ÁNYK forms. Attachment sheets had to be supplied under a generic node named sheet — meaning 'page' — while ÁNYK field identifiers, known as NavFieldIds, mapped each item of data to the corresponding field on the form. Developers therefore had to know not only what a value meant, but also on which ÁNYK sheet, row and field it appeared.

Version 2.0 removes this form-centred approach. In NAV's words, the data structure becomes 'more self-contained, more maintainable and more coherent from a machine-processing perspective'. Instead of the generic sheet node, each attachment sheet now has its own descriptively named node.

The change goes beyond restructuring: the previous validation rules have also been replaced. A file that was valid in the 1.0 format therefore cannot be converted by simply renaming fields. The XML must be generated according to the new structure and the new validation rules.

Version 2.0 also simplifies part of the process: the declarationAdditionalData node, which contained supplementary return data, has been removed. The submitting system no longer has to generate this data group separately, because eVAT M2M calculates the required data from the submitted analytics. The automation can, however, produce the correct result only from complete and accurate analytics.

The location of the vpid field, which contains the customs authority partner identifier (VPID), has also changed. It previously appeared under sheetList, which groups the attachment sheets; in version 2.0 it has moved under the declarationInfo node containing the return's core information. A value supplied in the old location is no longer processed.

Attachment sheets: what does the system complete, and what remains the taxpayer's responsibility?

Version 2.0 takes over several calculations, but that does not mean it prepares the attachment sheets automatically. According to page 68 of the interface specification, the sheetList node grouping the attachments and all eight attachment nodes below it are optional in the schema.

The system automatically produces only one attachment: sheet 03, the indirect customs representative's per-import declaration, where the relevant conditions are met. The taxpayer must still supply the other attachment sheets whenever they are required.

The table below summarises the attachment sheets handled in the 2.0 schema, their XML nodes and their most important data. Sheet 03 is the exception: the submitting system does not include it as part of sheetList; eVAT M2M generates it from the submitted analytics when the required conditions are met.

On reverse-charge attachment sheets, the customs tariff number (customsTariffNumber) must be selected from a predefined value set. Examples include 1003 for barley, 1001 for wheat — including the wheat–rye mixture known as meslin — and 7213 for hot-rolled bars. eVAT M2M automatically supplies the product name associated with the customs tariff number.

The quantity (quantity) is optional in the schema, but whether it may be completed depends on the hybrid-seed indicator (hybridSeed). If the product is hybrid seed and hybridSeed is true, quantity must not be supplied. If the value is false, quantity is mandatory. hybridSeed and the unit of measure (unitOfMeasure) are always mandatory; the permitted units are kg, m3 and MWh.

On attachment A88, the customer's country name does not have to be supplied separately: eVAT M2M fills it from the customer's country code (customerCountryCode). The country code must be selected from a closed value set that includes XI alongside the EU Member State codes. XI denotes Northern Ireland, which is treated separately under EU VAT rules for trade in goods.

New fields

New fields in the analytics

The vatAnalyticsItem element describing each VAT analytics item has been extended with several new fields. One that is particularly easy to misinterpret is invoiceModificationOrCancellation (page 50 of the specification).

The value set for sourceDocumentType has also been extended. Alongside INVOICE, RECEIPT, CUSTOMS_DECLARATION and OTHER, the new DAILY_SUMMARY value denotes a cash register's daily close. It is used for daily aggregates of receipts originating from Hungary's Online Cash Register and eReceipt systems. In this context, the tax day runs from the daily opening until midnight on the same day.

The taxInformation group containing tax information has also gained the indirectCustomsRepresentative data group, which includes the importer's tax number, importerTaxNumber. The field is mandatory where the item relates to an import and the indirect customs representative exercises the right of deduction by assignment. In that case, the importer's eight-digit core tax number must be supplied without the VAT code or regional code.

eVAT M2M also uses this information to generate attachment sheet 03 automatically. The attachment is not created merely because importerTaxNumber is populated; the additional conditions specified in the documentation must also be met.

New field on self-revision attachment 04

The nonStandardAllowanceCalcReason field records why the self-revision charge is calculated differently from the general rule. It must be supplied where an exceptional provision means that the basis or amount of the charge cannot be determined in the standard way.

The field accepts a code from 01 to 09. Values 01–08 identify specific statutory reasons for deviation, while 09 indicates that several of those reasons apply at the same time.

What should you review in your own system?

The accounting and development tasks differ, but both start from the same point: the accuracy and completeness of the submitted analytics.

From the accounting side

In version 2.0, eVAT M2M generates attachment sheet 03 and the supplementary data previously reported in declarationAdditionalData from the submitted analytics. This is a simplification, but it does not resolve data-quality problems: the system does not supply missing identifiers or correct an incorrect tax position.

A missing importer tax number or an incorrect tax position may therefore affect the data generated by the system or cause a validation error. From an accounting perspective, one of the most important questions is where the analytics come from, who reviews them and who is responsible for their content.

For reverse-charge transactions, the tax code and the attachment sheet cannot be handled independently. Certain standard tax codes require the corresponding attachment sheet, and eVAT M2M checks this through separate validation rules. An attachment that is optional in the schema can therefore become mandatory depending on the contents of the return.

A software vendor's readiness can be tested with a few specific questions:

Does the software support the 2.0 schema, and from exactly which version?

Does it handle invoiceModificationOrCancellation only in connection with tax code MP31, or apply it generally to every corrective and cancellation invoice?

Does it transmit customsTariffNumber on the reverse-charge attachments, or does it still expect the product name described in the earlier plans?

Has it discontinued NavFieldId-based mapping?

Does it handle the new validation rules linking attachment sheets and analytics?

What tests demonstrate that the production eVAT M2M system accepts the software's 2.0 files?

A negative or uncertain answer is also valuable information. Without a tested software version and a committed implementation date, the risk is no longer merely technical but also one of scheduling. ÁNYK will be discontinued on 31 December 2026 and cannot serve as a fallback filing channel from 2027 (NAV information on the phase-out of ÁNYK).

From the development side

The NavFieldId-based mapping must be removed. Elements of the internal data model should be mapped directly to the descriptive nodes of the 2.0 schema.

The vpid field must be generated under declarationInfo.

Generation of declarationAdditionalData can be removed, because eVAT M2M calculates the data it contained in version 2.0.

The value of invoiceModificationOrCancellation must be tied to the tax code rather than merely to whether the document is corrective or cancelling. The value true may be used only together with tax code MP31.

Closed value sets — including customs tariff numbers, units of measure, country codes and document types — must be aligned with the current XSD and NAV documentation.

The relationships between attachment sheets and analytics must be tested separately. It is not enough to check only whether the XML conforms to the XSD.

Version 1.0 test cases must be reviewed because the business validation rules have changed alongside the structure.

What is still missing

In its 31 July announcement, NAV promised two further resources for the migration: sample XML files prepared against the 2.0 XSD and a frequently asked questions document. Neither was available in NAV's eVAT GitHub repository when this article was finalised on 18 August 2026. The earlier sample XML files in the repository still use the 1.0 schema and cannot be used unchanged for 2.0 development.

Another open issue was machine-to-machine submission of the A60 recapitulative statement. Instead of in August, NAV published the schema on 3 October 2026, together with its validation list, for now on a separate development branch of its GitHub repository. A60 will not have a separate interface specification: NAV is extending the eVAT M2M specification to cover it.

NAV accepts IT and development questions in the Discussions section of the eVAT GitHub repository. Questions requiring legal interpretation can be submitted through NAV's contact form by selecting the subject for legal questions concerning use of the eVAT interface.

Related resources

Related tools and guides

NAV responses can be interpreted with the searchable list of eVAT validation messages. Besides the messages in the interface specification, the database also covers the changes NAV announced later and the messages of the A60 recapitulative statement, filterable by severity.

Use the free eVAT XML validator to check the XML's structure and format against the XSD. Validation runs locally in the browser and the XML file is not uploaded. Passing schema validation does not, however, mean that the file will also pass NAV's additional business checks.

MP31 and the other standard tax codes can be searched in the 232-entry tax code catalogue. The complete list can also be downloaded in CSV and JSON formats.

For a comprehensive overview of how eVAT M2M works and what implementation involves, see the eVAT M2M guide.

Further articles on the migration

eVAT M2M: what needs to be fixed before the migration? — tax codes, data quality and controls before moving over.

ÁNYK phase-out 2027: transition checklist and timeline — which decisions have to be made, and when, before ÁNYK is discontinued.

NAV M2M and the ÁNYK phase-out: professional preparation for 2027 — the implications of the transition for accounting practice.

Sources

eVAT M2M 2.0 interface specification v1.1 (NAV, 214 pages, Hungarian) — detailed field descriptions, completion rules, value sets and validation rules.

XSD changes in eVAT version 2.0 (NAV, Hungarian) — an overview of the version change and the removed, relocated and restructured data elements.

eVAT M2M 2.0 XSD schema files — the schema files defining the structure of 2.0 XML documents.

Production migration to version 2.0: 3 August 2026 — NAV's 31 July 2026 announcement of the production migration.

eVAT 2.0 available in the test system — the announcement of the test environment's migration on 1 July 2026.

eVAT M2M 2.0 readiness poll — the developer survey conducted between 20 and 24 July 2026.

Questions requiring legal interpretation

Questions requiring legal interpretation can be submitted through the NAV contact form, selecting the subject for legal questions concerning use of the eVAT interface.