Hungary Einvoice

Hungary E-Invoicing Compliance Skill v1.0

General reference only. This skill is general tax/accounting reference material for AI-assisted workflows. It has not been reviewed for any specific person's facts, documents, elections, deadlines, residency, filing status, or local procedures. Do not rely on it to file, pay, amend, or take a tax position without review by a qualified professional in the relevant jurisdiction.

Section 1 -- Quick Reference

Section 2 -- Mandate Scope

Who Must Comply

All Hungarian VAT-registered taxpayers who issue invoices must report invoice data in real-time to the NAV Online Számla system. This includes:

• Domestic B2B invoices (all VAT amounts, including zero)
• Domestic B2C invoices
• Invoices issued to other EU member states (intra-community supplies)
• Export invoices to third countries
• Self-billing invoices (buyer issues on behalf of supplier)
• Modification invoices (credit notes, corrections)

The only invoices excluded from RTIR are those issued under the OSS (One-Stop Shop) regime for non-established sellers.

Timeline Phases

RTIR vs E-Invoicing Distinction

Hungary operates a real-time invoice data reporting model, not a clearance model. The reported XML is a copy of the invoice data, not the invoice itself (unless completenessIndicator=true). The legal invoice can be paper, PDF, or (optionally) the XML itself.

With XSD 3.0, businesses can opt to declare the XML as the actual electronic invoice by setting completenessIndicator=true. In this case, the XML becomes the legally binding document and is available to the buyer via NAV's system.

Section 3 -- Technical Format

XML Schema (XSD 3.0)

The NAV Online Számla system uses a proprietary XML schema maintained by NAV. As of 2026, only XSD version 3.0 is accepted.

Key Schema Structures

API Request Types

Section 4 -- Mandatory Fields

Invoice Data Fields (XSD 3.0)

Modification Invoice Fields

Electronic Invoice (completenessIndicator=true)

When completenessIndicator=true, NAV makes the invoice XML available to the buyer for download, and the XML serves as the legally binding invoice.

Section 5 -- Transmission Method

NAV Online Számla API

API Workflow

1. Token Exchange: Call TokenExchangeRequest to obtain a session token (valid for 5 minutes)
2. Prepare Invoice XML: Generate invoiceData XML conforming to XSD 3.0
3. Compress and encode: Base64-encode the invoice data; optionally compress
4. Submit: Call ManageInvoiceRequest with the encoded invoice data, operation type (CREATE, MODIFY, STORNO), and request signature
5. Receive transaction ID: NAV returns a transactionId
6. Query status: Call QueryTransactionStatusRequest to verify processing result (RECEIVED, PROCESSING, DONE, ABORTED)

Request Signature

Every ManageInvoiceRequest must include a request signature computed from:

• Request ID
• Timestamp
• XML signing key
• Invoice hash values

The signature algorithm uses SHA-512 and the technical user's signing key.

Batch Submission

Up to 100 invoice operations can be submitted in a single ManageInvoiceRequest (within the invoiceOperations element). Each operation has its own index, operation type, and invoice data.

Technical User Management

Each taxpayer registers an "elsődleges felhasználó" (primary user) on the NAV portal, who then creates technical users for API access. Each technical user has:

• Login name and password
• XML signing key (cserekulcs)
• XML exchange key (aláírókulcs)

If keys are regenerated on the portal, they must be updated in the invoicing software immediately.

Section 6 -- Validation Rules

NAV-Side Validation

NAV validates every submitted invoice against:

1. XSD schema validation -- must conform to XSD 3.0; earlier versions rejected
2. Request signature validation -- cryptographic signature must be valid
3. Technical user validation -- credentials and keys must match
4. Business rule validation:
   • Tax number format and validity (8-digit taxpayer ID + VAT code + county code)
   • Invoice number uniqueness per supplier
   • Modification references: original invoice must exist in the system (unless modifyWithoutMaster=true)
   • completenessIndicator restrictions (cannot be true for paper invoices, private person invoices, merged invoices, or pre-2021 invoices)
   • Currency and exchange rate consistency
   • VAT rate validity against current Hungarian VAT law

Pre-Submission Checks

• Validate XML against XSD 3.0 locally before API call
• Verify request signature computation is correct
• Confirm technical user credentials and keys are current (keys must be refreshed if regenerated on the portal)
• Verify tax number validity using NAV's public tax number query service
• Ensure invoice number has not been previously submitted
• For modifications: verify original invoice exists and modification index is sequential

Common Rejection Reasons

Section 7 -- Tax Computation Rules

Hungarian VAT Rates (2026)

Rounding Rules

• VAT amounts calculated per line in the invoice currency (HUF or foreign currency).
• HUF amounts rounded to the nearest whole forint (no decimals).
• EUR/foreign currency amounts rounded to 2 decimal places.
• Summary totals are the sum of rounded line-level amounts.
• NAV validates that line-level amounts sum to the summary totals (with tolerance).

Multi-Rate Invoice Handling

Each VAT rate has a separate summaryByVatRate element in the invoiceSummary. Each element contains:

• vatRateNetData (taxable base at this rate)
• vatRateVatData (VAT amount at this rate)
• vatRateGrossData (gross amount at this rate)

Lines with different VAT rates must declare the rate individually.

Currency Handling

For invoices in foreign currency:

• currencyCode must be a valid ISO 4217 code
• exchangeRate is the MNB (Magyar Nemzeti Bank) rate on the tax point date or a contractual rate
• HUF equivalents are required in the summary for tax reporting purposes
• If the invoice is in HUF, exchangeRate must be 1

Reverse Charge

Domestic reverse charge (fordított adózás) invoices must be reported with:

• vatExemption or vatOutOfScope indicator on relevant lines
• Specific VAT rate type VAT_RATE_EXEMPT with the appropriate exemption reason

Section 8 -- Archiving Requirements

Section 9 -- Penalties for Non-Compliance

RTIR-Specific Penalties

General VAT Penalties

Practical Consequences

• NAV uses RTIR data for automated risk analysis; persistent errors trigger compliance audits
• The planned e-ÁFA (pre-filled VAT return) system relies on correct RTIR data; incorrect submissions lead to discrepancies in the pre-filled return
• Buyers increasingly verify supplier RTIR compliance before accepting invoices

Section 10 -- Interaction with Tax Skills

RTIR → VAT Return (ÁFA bevallás)

NAV uses RTIR data to construct the e-ÁFA (electronic VAT) pre-filled return. From 2024, NAV offers taxpayers a draft VAT return based on:

• Supplier-reported outbound invoices
• Buyer-received inbound invoices
• Customs declarations

Taxpayers review, adjust, and submit the pre-filled return. Discrepancies between RTIR data and the filed return trigger automated queries.

RTIR → e-ÁFA Pre-Filled Return

The e-ÁFA system pre-populates:

• Output VAT from the taxpayer's submitted invoices
• Input VAT from suppliers' reported invoices where the taxpayer is the buyer
• Adjustments for credit notes and modifications

This significantly reduces manual data entry for small and medium businesses.

Electronic Invoice (completenessIndicator=true) → Buyer AP

When a supplier sets completenessIndicator=true, the buyer can retrieve the structured XML invoice from NAV's system. This enables automated accounts payable processing, booking, and reconciliation.

RTIR → Corporate Tax (Társasági adó)

NAV cross-references RTIR data against corporate tax returns. Revenue and cost data from invoices feeds into NAV's risk-analysis algorithms for corporate tax audits.

Future: ViDA Alignment

Hungary's RTIR is expected to evolve into a full structured e-invoicing system aligned with EU ViDA requirements by 2028--2030. The transition will shift from data reporting (XML as a copy) to clearance or exchange (XML as the legally binding invoice, EN 16931 format). Hungary's advanced RTIR infrastructure positions it well for this transition.

NAV Online Számla → e-Nyugta (Electronic Receipt)

NAV is developing the e-nyugta system for electronic receipts, which will eventually replace traditional cash registers for retail B2C transactions. This system will integrate with the existing Online Számla infrastructure.

Disclaimer

This skill and its outputs are provided for informational and computational purposes only and do not constitute tax, legal, or financial advice. Open Accountants and its contributors accept no liability for any errors, omissions, or outcomes arising from the use of this skill. All outputs must be reviewed and signed off by a qualified professional (such as a CPA, tax attorney, or equivalent licensed practitioner in your jurisdiction) before filing or acting upon.

The most up-to-date, verified version of this skill is maintained at openaccountants.com.

Source: OpenAccountants — open tax Guides for AI, reviewed by named CPAs/CAs/EAs. Quality: source-cited draft. For always-current figures and named-accountant backing, connect the OpenAccountants MCP server (openaccountants-mcp).