Prepare SAP for Hungary eVAT M2M before ÁNYK closes

No. After ÁNYK closes, eÁFA provides a web channel and an M2M channel. NAV presents M2M as the practical route for organizations with larger document volumes, digital accounting and more complex tax decisions. The channel choice should be documented for each VAT registration and operating model.

Legal applicability and any exceptional taxpayer status still require confirmation by the customer’s tax adviser or responsible tax function.

NAV states that the ÁNYK framework will cease operation after 31 December 2026. The project should not treat that date as the technical start date. Before the old route closes, the team needs a confirmed channel, NAV registration, tested access, approved mapping, reconciled sample periods, accepted exception procedures and named production owners.

NAV makes transaction-based information available from authority sources such as Online Invoice data, online cash-register and simplified-invoice information, and customs documents. The SAP process contributes governed VAT analytics and maps company tax treatment to NAV’s standard tax codes. The declaration process must reconcile the SAP population, NAV-held source data and the resulting VAT position.

M2M is a filing and data-processing channel. It does not by itself determine whether the taxpayer files monthly, quarterly, annually or under an exceptional period. The customer’s existing legal filing profile and due date must be confirmed separately.

NAV notes that M2M validation can take 3 to 5 days. That time, plus investigation and approval, must be planned before the statutory due date.

The taxpayer remains responsible for the legal filing. An automated connection does not transfer that responsibility to NAV, SAP or the software provider. The implementation therefore needs named preparer, reviewer, submitter and exception-owner roles, plus evidence showing which version was approved and transmitted.

• Validation checks the analytics and returns findings before or during the filing process.
• Repair responds to a NAV repair request while preserving the authority reference and submission chain.
• Taxpayer correction continues the correction version chain for a submitted filing where that procedure applies.
• Self-revision changes the declared tax position after filing and must preserve the original filing, the revised values, the legal reason and the version relationship.

The correct legal procedure depends on the filing state and facts. Tax must approve the procedure; the SAP workflow should enforce and evidence the approved choice.

NAV describes conditional benefits, including removal of the invoice-recipient M-sheet obligation when statutory conditions are met and relief from the self-revision surcharge when an eligible M2M correction is submitted within the statutory 15-day window. NAV also describes a limited 15-day protection for qualifying reliable taxpayers, subject to stated exceptions.

These are legal effects, not software features. Confirm eligibility before relying on them. See NAV’s current M2M guidance.

Confirm foreign Hungarian VAT registrations, Plants Abroad reporting, one-time customer or vendor accounts, received-invoice differences, annual or exceptional filing periods, succession, liquidation or winding-up situations, and any period previously corrected through another channel. These scenarios can change source selection, authority procedure, ownership and test coverage.

The page does not prescribe one universal retention period. The customer should set the period from Hungarian legal requirements, group tax policy, audit policy and system-archiving rules. The implementation must then retain or archive the approved source population, mapping version, payload, NAV response, status history, user actions and correction relationships for that agreed period.

The add-on is designed for customer-managed ABAP landscapes and is assessed for SAP ECC and SAP S/4HANA on-premise or private-cloud deployments. The exact release, SAP_BASIS level, installed components, Unicode status, transport path and available HTTP and security services are confirmed before commitment.

No direct in-system add-on installation is claimed for SAP S/4HANA Cloud Public Edition. Public Edition and mixed landscapes require a separately designed side-by-side or integration route. Selecting Public Edition in the readiness check should therefore lead to architecture confirmation, not an assumption of classic add-on compatibility.

Not automatically. For a supported customer-managed ABAP landscape, SAP can communicate through an approved HTTPS route using STRUST, SM59 and the configured NAV destination. BTP, middleware or a custom provider can still be selected where the customer’s network, security, cloud or shared-service architecture requires it. The proposal must state which component owns transformation, credentials, transmission, retry and monitoring.

The customer completes the applicable NAV portal and M2M registration steps, obtains the technical-user access and keys, and authorizes their use. Basis and security teams configure trusted certificates, outbound HTTPS routing, proxy or firewall rules, secure credential storage, endpoint separation and restricted administrative access. Secrets must not be stored in transports, source code, logs or visible configuration exports.

The implemented path starts from governed SAP FI tax data for the selected company code, period and filing context. Scope confirmation identifies any SD, MM, BSEC one-time-account, Plants Abroad, custom table, external system or spreadsheet dependency. Every non-SAP input needs an owner, controlled interface, reconciliation rule and retained source reference.

Mapping is maintained by company code, SAP tax code, direction and validity period against NAV’s standard eVAT tax-code catalog. Coverage checks should identify used but unmapped combinations before XML generation. Tax owns the meaning and approval of the mapping; SAP owns controlled configuration, transport or maintenance access and regression evidence.

The active NAV interface specification, XML schema, document type and endpoint must be recorded for each environment. Catalog releases use a version identifier, and the generated payload retains version metadata. A NAV change should trigger impact assessment, code or configuration change where needed, regression testing, customer communication and a controlled deployment before the authority cutover.

The run fixes the source population and configuration context, generates and stores the exact XML, performs local structural checks, exposes the payload for controlled review and can execute NAV validation. Mapping gaps, material reconciliation differences, invalid configuration and missing approval should be treated as stop conditions rather than warnings that users can ignore.

Each filing run needs a stable internal identifier linked to NAV message, document and processing references. Network retry must be separated from a new legal submission. Before resending after a timeout, operations should query or reconcile the authority state so an uncertain transport outcome does not create an uncontrolled duplicate. Status polling, errors and follow-up actions remain linked to the same history.

Company-code authorization limits the data population. Display, run creation, validation, legal submission and exceptional archive or deletion activities should be separated according to customer policy. SAP Application Log, retained payloads, masked HTTP exchanges, status history, configuration approvals and deletion records provide the operational evidence. Sensitive keys and secrets must remain excluded.

Fit testing should use representative high-volume periods, not only a small happy-path sample. Measure extraction, XML generation, compression, database growth, transmission, NAV processing, polling and monitor response. Agree background-job scheduling, timeouts, package sizing, archiving and operational thresholds before production acceptance.

Regression scope should cover extraction, mapping validity, generated schema, signing or credential handling, TLS, submission, status retrieval, correction chains, authorization checks, logging and evidence retrieval. Relevant triggers include SAP upgrades, support packages, certificate renewal, proxy changes, tax-code changes, new company codes and each NAV specification or schema release.

• SAP system inventory, release and deployment model
• Hungarian VAT registrations, company codes and filing frequencies
• Current filing process and representative accepted periods
• Used SAP tax codes, tax procedures and known exceptions
• Source-system and reconciliation inventory
• NAV registration owner, technical access and test credentials
• DEV, QAS and production transport route
• Basis, security, tax, AP, AR and operations contacts
• Retention, approval, segregation-of-duties and support requirements

Missing inputs become explicit readiness actions, not hidden implementation assumptions.

Tax owns legal scope, tax-code meaning, reconciliation tolerance, corrections and filing approval. SAP functional owns source interpretation and configuration. Development or product delivery owns the implemented logic. Basis and security own transports, TLS, destinations, credentials and jobs. Operations own monitoring and incidents. Project management owns gates, dependencies and acceptance. Named deputies are needed for filing-critical activities.

1. Fit and scope: confirm taxpayer, SAP, source and architecture boundaries.
2. Design: approve mapping, reconciliation, security, roles and exception procedures.
3. Install and configure: import transports, configure environments, credentials, mappings and controls.
4. Test: complete technical, functional, negative, correction and volume scenarios in NAV TEST.
5. Accept and cut over: close blockers, approve evidence, rehearse rollback and enable production.
6. Operate: monitor the first filing, stabilize ownership and enter the change-maintenance cycle.

An illustrative planning basis for a single ready SAP landscape is approximately four to six weeks from confirmed prerequisites to controlled production handover. This is not a commitment before fit confirmation.

Multiple source systems, several registrations, incomplete tax mapping, customer security lead times, unavailable NAV access, custom tax logic or limited UAT capacity can extend the elapsed plan. The written proposal should state assumptions, customer effort, milestones and stop conditions.

The normal path is SAP development, quality or test, and production, aligned with NAV TEST and NAV production endpoints. Configuration must distinguish endpoints and credentials without transporting production secrets. The transport plan should record import order, prerequisites, post-import checks, rollback method and who approves each move. A direct production-only installation is not an acceptable substitute for end-to-end testing.

• Normal period creation, validation, approval, submission and status completion
• Used and unused tax codes, missing mapping and validity-date boundaries
• Outgoing, incoming, one-time-account and foreign-registration scenarios in scope
• NAV data differences and reconciliation approval
• Schema, application, authentication, TLS and timeout failures
• Safe retry after an uncertain communication outcome
• NAV repair, taxpayer correction and self-revision chains
• Authorization denial and segregation-of-duties checks
• High-volume processing, jobs, logs, archive and evidence retrieval
• Transport rollback and restoration of the prior operating route where possible

Go-live requires confirmed legal and company scope, approved mappings, working NAV production access, trusted TLS, completed UAT, reconciled representative periods, resolved critical defects, trained users, named support owners, agreed retention, tested monitoring, cutover and rollback instructions, and formal Tax, SAP, Basis and project approval. Open items need an owner, due date and documented risk acceptance.

Cutover confirms the production endpoint, credentials, certificate chain, roles, jobs, configuration versions and source-period controls. The team should run a production connectivity check that does not create an unintended legal filing, then apply the approved filing procedure. The first live period should have enhanced monitoring, rapid Tax and Basis availability, frequent status review and a documented decision route for stop, repair, correction or rollback.

S4FN delivery can include the add-on, architecture and configuration records, mapping workbook, installation sequence, test and acceptance pack, cutover controls, operating manual and audit runbook within the written scope. The customer retains legal tax decisions, NAV registration and authority, source-data accuracy, landscape access, security approval, business acceptance, production submission authority and internal support responsibilities unless a separate managed-service scope says otherwise.

The support model should define filing-window coverage, incident severity, contact route, evidence required for triage, customer and provider response boundaries, certificate and credential ownership, and escalation to NAV. Version maintenance should include monitoring official NAV releases, impact assessment, regression scope, delivery method, customer testing and production approval. These terms belong in the commercial and support schedule, not in assumptions.

Scope is driven by SAP systems and releases, company codes and VAT registrations, source systems, tax-code complexity, custom logic, deployment architecture, number of environments, security requirements, test support, documentation depth, cutover coverage and post-go-live support. The readiness review should convert these into a written boundary, deliverables, customer responsibilities, schedule and price before work begins.