Draft ViDA implementation framework published for Hungary

The publication constitutes an informational document aimed at professional associations and market participants, in which NAV and NGM experts present the concept for Hungary's ViDA implementation with respect to mandatory electronic invoicing. In its current state, this document does not represent a detailed implementation plan, nor should it be construed as a definitive position. The authorities intend to refine and clarify the framework based on the outcomes of public consultations.

Mandatory e-invoicing requirements

Under the proposed concept, electronic invoicing will become mandatory for most transaction types. While the ViDA Directive would require this only for intra-Community transactions, Hungary intends to mandate e-invoicing on a near-universal basis. Accordingly, the obligation will extend to:

• domestic business-to-business (B2B) transactions,
• cross-border intra-Community B2B transactions, and
• business-to-government (B2G) transactions.

Regarding invoice issuance deadlines, a 10-day post-supply deadline will be introduced for intra-Community transactions, whereas the current 8-day rule will remain unchanged for domestic transactions.

In terms of format, the Hungarian implementation is expected to build upon the provisions of the VAT Act and will be based on the structured data model set out in the EN 16931 European standard. The final Hungarian version of the standard has not yet been published by the legislator. The objective is to establish invoicing and data reporting on unified digital foundations, ensuring data content compliant with legislative requirements and secure data transmission.

Paper invoices may only be issued to private individuals and buyers outside the European Union; however, parties may also opt for e-invoicing in these cases.

Data-based e-invoicing (EN 16931)

A fundamental element of the concept is that the definition of "electronic invoice" rests on a data-based approach: invoices must be available in a machine-readable, structured format based on the EN 16931 European standard. The Hungarian solution would incorporate local supplements beyond the EU "core" data content, the specification of which is expected to align with the 2026 version of the standard.

The essential requirement is that invoices must be generated as structured XML in all cases, even where the invoice is presented to the buyer in paper form. In this context, the document also stipulates that Hungary will not permit hybrid invoicing (PDF with attached XML); invoices must invariably be produced as XML compliant with the XSD schema developed pursuant to EN 16931. This represents a significant departure from current practice, given that businesses have historically favoured PDF-based invoices.

The invoice image (the human-readable version) will be optional by default, except for invoices issued to private individuals, for which the creation of an invoice image will be mandatory. A key principle is that the invoice image does not constitute an official invoice and, in the event of a discrepancy, the XML will be deemed the legally authoritative "document." This represents a reversal of current practice, under which the invoice image is determinative.

Secure channels, buyer identification, and API requirements

The concept explicitly precludes email-based invoice transmission: invoices may only be transmitted via secure, authenticated, and encrypted channels. A prerequisite for this is prior buyer identification, which encompasses:

• the validation of the buyer's tax identification number, and
• identification of the buyer's receiving endpoint, which may be a service provider system or the buyer's proprietary business management system.

A key operational element is that all affected parties must establish API-based connectivity. This means that without API integration, invoice issuance and receipt will be effectively impossible. On the buyer side, the objective is to create a receiving endpoint through which – irrespective of the issuer's identity – all invoices can be received. It is therefore unnecessary to establish separate connections with each supplier; a single receiving point accessible to all counterparties will suffice.

However, invoices originating from other Member States or third countries fall outside the scope of Hungarian regulation; consequently, this secure channel solution will not apply to all invoice sources.

The introduction of mandatory electronic invoicing will require significant IT development investment from both businesses and software developers. This will involve not only redesigning invoice structures but also implementing API integration for accounting/ERP systems (via direct API integration, middleware solutions, or dedicated integration platforms). Based on the concept, it appears certain that invoicing software systems (seller and buyer systems) will communicate directly with each other, meaning the tax authority will not fundamentally assume an intermediary role. However, NAV will also offer an invoice forwarding support service – presumably to address cases where the requisite developments cannot be implemented.

Invoicing software requirements and taxpayer accreditations

Invoicing software must function not merely as technical tools, but also as compliance checkpoints. Invoicing software must perform preliminary validation, including:

• the completeness of mandatory invoice data pursuant to the VAT Act,
• verification of the buyer's tax identification number, and
• compliance of the data structure with the XSD schema.

Where validation fails, the software must prevent invoice creation, consequently precluding data reporting.

A central element of the Hungarian model is "taxpayer accreditation." According to the concept, accreditation will be self-service in nature, based on predefined validation tests. Two accreditation types will be introduced:

• preliminary (service provider) accreditation, which is mandatory for invoicing service providers, and
• taxpayer accreditation, which is mandatory for taxpayers with proprietary invoicing software, irrespective of whether the developer is otherwise accredited.

Data reports originating from non-accredited systems may remain in pending status for a maximum of 30 days. The invoice may nonetheless be issued; however, once the 30-day deadline has expired, a default penalty may be imposed. The concept emphasizes that responsibility for compliant invoicing and data reporting lies with the invoice issuer; accordingly, it is advisable to address the allocation of costs and liability arising from non-compliant operation in contracts between developers, service providers, and taxpayers.

A question remains as to how economic operators using an ERP system developed in another Member State for their Hungarian operations will be able to meet the accreditation requirements.

Data reporting, buyer data reporting, and status reports

The concept distinguishes between intra-Community and domestic transactions: for intra- Community transactions, only the reporting of basic data pursuant to the ViDA Directive is mandatory (although the complete invoice dataset may also be submitted), whereas for domestic transactions, the full invoice submission is prescribed as data reporting.

For invoices issued to private individuals, the document emphasizes that data reporting may not contain personal data. In such cases, the invoicing software transmits data in encrypted form, and the associated key must be retained.

One of the most significant innovations in the Hungarian approach is buyer data reporting and status reports, which are not obligations prescribed by the ViDA Directive but rather Hungarian-specific requirements. Under the buyer feedback mechanism, the buyer must acknowledge receipt of the invoice within 5 days of receipt, on an invoice-by-invoice basis, in near real-time. The precise method of feedback has not yet been clarified.

Additionally, a status report mechanism may be introduced. It would be aligned with the VAT return period and completed by the VAT return submission deadline. In the status report, the buyer must indicate which invoices do not correspond to actual economic events. The concept stipulates that should the buyer subsequently accept the transaction; immediate correction is required.

However, questions remain regarding the actual deterrent effect of this mechanism. In the case of bad-faith taxpayers, the submission of additional fictitious data reports would not constitute an obstacle, while for good-faith taxpayers, the status report would primarily increase the potential for errors arising from administrative processes.

The rationale for introducing buyer feedback and status reports is more effective fraud prevention: data reaches the authority in near real-time, in contrast to the current system where significant delays may occur until either the domestic recapitulative statement (M sheets) or the EU Sales and Purchase Lists (A60) is submitted and processed. However, the question arises whether the parallel operation of buyer data reporting and status reports may result in unjustified additional administrative burden.

PEPPOL Network and NAV Services

Pursuant to the secure invoice transmission principle, the concept permits connection to the PEPPOL network (Pan-European Public Procurement Online), while clearly stipulating that PEPPOL usage will not be mandatory. Hungary will not prescribe a mandatory Access Point service provider; the development of solutions is left to the market. The concept also stipulates that NAV's proprietary invoicing system will not connect to the PEPPOL network.

The concept further identifies services provided (or planned) by NAV:

• invoice archiving/retention (for issuers and domestic buyers, where the complete invoice is submitted);
• attachment upload capability (max. 5 MB, with limited retention period);
• provision of a free, ViDA-compatible NAV invoicing application;
• invoice forwarding service (standalone or integrated);
• data reporting visibility for issuers and buyers;
• ViDA-OSA conversion (reconciliation of ViDA and the currently applied data structure); and
• support for XSLT-based invoice visualisation (rendering).

In summary, significant innovations are anticipated, which NAV intends to support in part through services and tools.

It seems to be sure that data-based invoicing supports a comprehensive digital transformation. Concurrently, the underlying data for machine-processed (M2M) eVAT returns will become more reliable, ultimately facilitating more accurate and predictable VAT reporting.

* * *

We trust this newsletter will assist you in reviewing the proposed rules. The publication issued by NAV-NGM is available in full at: https://nav.gov.hu/vida/koncepcio

Should any questions arise regarding the above, our advisors remain at your disposal.