NAV eVAT M2M 2.0.2 Changes the SAP Regression Baseline

NAV’s eVAT M2M 2.0.2 release changes a small but important part of the assurance problem for SAP teams. A payload that passed an earlier test is not evidence that the same mapping remains valid against the corrected specification and XSD bundle.

The practical task is therefore not simply to download the new files. It is to establish whether the SAP extraction, transformation and validation chain is tied to the corrected definitions, then produce test evidence that identifies the exact schema version used.

Current production baseline: authority cutover and SAP delivery are separate facts

NAV production has accepted only eÁFA M2M XSD 2.0 since 3 August 2026. SAP product availability can enable an implementation path, but only a captured customer payload and accepted authority result prove compatibility.

Layer or landscape	Confirmed position	Implementation conclusion
NAV test environment	2.0-only since 1 July	All current regression fixtures must use the official XSD 2.0 structure.
NAV production environment	2.0-only since 3 August	Version 1.0 is no longer a productive fallback, and NAV does not support 1.0/2.0 coexistence.
SAP Cloud ERP Public Edition 2608	Production rollout 15–16 August	Record the exact tenant software level and validate the generated XML against NAV XSD 2.0.
SAP S/4HANA / Private Edition	Release-specific support	Confirm the delivered legal content, maintenance level, SAP Notes and exact outbound schema in the customer system.
SAP ECC 6.0	No standard delivery inferred here	Do not use a historic roadmap date as proof of productive support. Confirm the implemented add-on or connector path and test it against NAV directly.

Production control: extract one real SAP-generated payload, retain its namespace and fingerprint, validate it against the official 2.0 XSD, submit it through the intended NAV environment and reconcile the accepted values back to the SAP source.

Sources: NAV XSD 2.0 production notice; SAP Cloud ERP Public Edition 2608 feature and setup documentation. Status reviewed 24 August 2026.

What NAV changed in eVAT M2M 2.0.2

NAV published eVAT M2M version 2.0.2 on 1 July 2026. The package contains M2M 2.0 specification version 1.1 and revised XSD files.

• The specification contains a material clarification in section 6.3.6.1 concerning chassisNumberOfTheCar.
• earBase.xsd removes StatementNameType and corrects CORECCTION to CORRECTION.
• earData.xsd includes additions and removals involving ChassisNumberListType, ChassisNumberOfTheCarItemType and dataAsIndirectCustomsRepresentative.

Those release notes identify where to begin the impact analysis. They do not prove that a particular SAP implementation is affected. That conclusion depends on which schema bundle the solution uses, how XML is generated and whether the changed structures are populated in the taxpayer’s scenarios.

An accepted token is not a schema test

M2M troubleshooting becomes unreliable when several independent checks are treated as one result. Authentication can succeed while the business payload remains incompatible with the current XSD. An XML document can also validate structurally and still fail later business rules.

Keep the following outcomes separate in both test execution and evidence:

• Authentication: NAV accepted the credentials and cryptographic request needed for the interaction.
• XML well-formedness: the generated document is syntactically valid XML.
• XSD validation: the document conforms to a specifically identified schema bundle.
• Business validation: the submitted values and relationships satisfy NAV’s applicable processing rules.
• Accepted processing result: the authority completed the relevant operation and returned a result that can be reconciled to the SAP source data.

A screenshot showing successful authentication cannot replace the XSD validation result. Likewise, a local validation result is incomplete if the evidence does not identify the exact XSD files against which the payload was checked.

Establish the actual SAP impact before changing code

Do not start by editing a mapping or regenerating an interface object. First trace the production path from SAP source data to the submitted XML. The investigation should answer four concrete questions.

1. Which eVAT release is implemented? Record the version or checksum of the specification and every XSD file used by development, middleware and test tooling. A filename alone is weak evidence because files can be replaced without changing local naming conventions.
2. Where is the XML structure enforced? Identify whether validation occurs in SAP, middleware, a custom service, a generated client or more than one layer. The correct remediation point depends on where the schema contract is compiled or interpreted.
3. Which changed definitions are reachable? Trace each corrected type or element to the transformation rule and source field that could populate it. A changed XSD component that is never used in the taxpayer’s scenarios may require regression evidence without requiring a mapping change.
4. Which tests previously covered those paths? Locate positive, negative and boundary payloads for vehicle chassis data, correction-related values and indirect customs representative data where relevant. If no test reaches the changed definition, the old test pack cannot establish compatibility.

A regression protocol that produces defensible evidence

The following sequence limits unnecessary SAP changes while preserving an auditable connection between the NAV release and the final conclusion.

1. Freeze the authority baseline. Store the NAV release tag, publication date, specification version and the checksum of the downloaded XSD bundle. Keep the original files read-only in the test evidence package.
2. Compare schemas structurally. Use an XML-aware comparison where possible. A plain text diff can reveal spelling changes, but it may obscure the effect of type references, occurrence constraints and namespace relationships.
3. Build an impact trace. For every changed definition, document the source field, mapping rule, transformation component, validation layer and test case. Mark a definition as not applicable only when the execution path supports that conclusion.
4. Regenerate only where required. If the implementation uses generated artifacts derived from an XSD, identify which artifacts were generated from the previous bundle. Do not assume that replacing an XSD file automatically updates compiled or generated structures.
5. Validate representative payloads locally. Retain the payload, validation result, validator identity and exact schema checksum. Include at least one payload for every affected business path, plus a controlled negative case that proves the validator rejects an invalid structure.
6. Execute the NAV test separately. Preserve the authority request and response identifiers made available by the interface, the timestamp, environment, payload fingerprint and processing outcome. Do not merge token acquisition and business submission into a single pass or fail statement.
7. Reconcile back to SAP. Confirm that the values accepted by NAV correspond to the intended SAP source document or reporting record. Transport success and HTTP success do not establish business correctness.

The minimum evidence package

A reviewer should be able to reproduce the compatibility conclusion without relying on the memory of the developer who performed the test. Keep these artifacts together:

• NAV release URL, release date and specification version
• Checksums for the XSD files used during validation
• Schema comparison output focused on the corrected definitions
• Mapping impact trace from SAP source to XML element or type
• Sanitized positive and negative test payloads
• Local validation logs with validator and schema identity
• NAV test request and response identifiers where returned by the interface
• Reconciliation result linking the submitted values to the SAP source record
• Named owner and decision for every unresolved difference

This evidence distinguishes three materially different conclusions: no affected execution path was found, an affected path was found and passed regression, or an affected path remains unresolved. A generic status such as “tested successfully” does not preserve that distinction.

Keep eVAT M2M separate from Hungary RTIR

Hungary’s Online Invoice reporting and eVAT M2M are related through VAT data, but they are not interchangeable technical interfaces. Successful RTIR reporting does not prove that an eVAT return payload conforms to the corrected eVAT M2M schemas. Each interface needs its own version baseline, payload tests, authority responses and reconciliation evidence.

For the broader implementation scope, review the Hungary eVAT M2M Integration for SAP page. The release-specific procedure in this article should be used to assess the 2.0.2 schema correction without duplicating the full implementation design.

Official sources

• NAV eVAT M2M release 2.0.2
• NAV eVAT repository
• NAV: XSD 2.0-only production from 3 August 2026
• S4FN: SAP Cloud ERP 2608 Hungary eVAT M2M release analysis

Technical content verified: 24 August 2026. NAV production has accepted only XSD 2.0 since 3 August 2026; validate the exact customer payload against the current official package before production use.