ediverse Explore the platform

Spotlight PEPPOL BIS Billing 3.0 The EU e-invoicing mandate is here — France Sept 2026, Belgium Jan 2026, Germany 2025.

Hungary — Online Számla and NAV reporting

Hungary has been operating a Real-Time Invoice Reporting (RTIR) system since 2018: the commercial invoice can stay paper or PDF, but its structured data must be reported to NAV right after issuance, by sending an XML to the Online Számla API.

Regulatory timeline

  • Act CXXVII of 2007 on VAT. Legal base of Hungarian invoicing, complemented by Ministerial Decree 23/2014. (VI. 30.) NGM.
  • Decree 23/2014. (VI. 30.) NGM. Ministerial decree on invoice identification and the conditions for electronic invoicing.
  • 1 July 2018. RTIR goes live for B2B invoices with VAT > HUF 100,000, via Online Számla API v1.0 / v1.1.
  • 1 July 2020. Removal of the HUF 100,000 threshold: every domestic B2B invoice must be reported. The transitional non-penalty window runs to 31 March 2021.
  • 1 January 2021. Extension to domestic B2C invoices and every exempt operation. Schema v3.0 introduced.
  • 1 April 2021. End of the tolerance window and penalties kick in (up to HUF 500,000 per undeclared invoice).
  • 2023-2025. Regular technical evolutions of the Online Számla v3.0 schema (sub-versions 3.0.x) adapting to VAT changes and post-Brexit cross-border operations.

Deep dives — 10 dedicated pages

Ten dedicated pages drill into every dimension of the Hungarian RTIR mandate — the 2018-2021 NAV Online Számla rollout, technical specs (API, XSD evolution, QueryTaxpayer, pénztárgép), and real-world B2B usage that pre-dates and coexists with the RTIR (EDIFACT retail/automotive, Termékdíj environmental fee).

2018-2021 RTIR

  • NAV Online Számla — RTIR since 2018 · NAV real-time invoice reporting (RTIR) platform, mandatory 1 Jul 2018 (B2B > 100K HUF VAT), universal 4 Jan 2021. Legal basis 2007. évi CXXVII. törvény + 23/2014. (VI. 30.) NGM decree.
  • RTIR — detailed architecture · Post-issuance reporting (not clearance), asynchronous XML push within 24h, ~99.9% acknowledgment, 3-attempt retry, ~6.5B invoices reported since 2018.
  • XSD evolution v1.0 → v3.0 · 4 versions: v1.0 (Jul 2018), v1.1 (Jul 2019), v2.0 (Apr 2020 intra-EU), v3.0 (Jan 2021 universal). Schemas on onlineszamla.nav.gov.hu/dokumentumtar.
  • Hungarian VAT (ÁFA) regimes · Standard 27% (EU record), reduced 18% (UHT milk, hospitality, dining), super-reduced 5% (books, medicines, fresh milk, district heating), KATA small business, reverse charge art. 142 ÁFA.

Technical specs

  • NAV Online Számla API — endpoints · REST + XML, TokenExchange (5 min), ManageInvoice (batch 100), QueryInvoiceData/Check/Digest, QueryTaxpayer. Prod api.onlineszamla.nav.gov.hu + test api-test.
  • QueryTaxpayer — adószám validation · Real-time validation of Hungarian tax numbers (8-digit root + vatCode + countyCode), ACTIVE/SUSPENDED/DELETED statuses, csoportos áfa VAT groups, < 1 s latency.
  • Online pénztárgép — NAV cash registers · AEE-certified fiscal cash registers since 2014, ~200,000 devices, dedicated M2M SIM communication to pt.nav.gov.hu, B2C retail + dining + taxi scope.

Real-world B2B usage

  • Hungarian retail EDIFACT · Spar, Tesco (Sparkle Foods), Lidl, Aldi, Penny, Auchan, CBA, Coop, Príma — GS1 Hungary EANCOM 2002 subsets, ~500M messages/year, Comarch + EDITEL + GXS VANs.
  • Hungarian automotive EDIFACT · Audi Győr (largest engine plant globally), Mercedes Kecskemét, Magyar Suzuki Esztergom, BMW Debrecen (Neue Klasse 2024), Opel Szentgotthárd — VDA + Galia + Odette, OFTP2 over ENX.
  • Termékdíj — environmental fee · NAV environmental fee on 9 categories (packaging, batteries, EEE, tires, lubricants, advertising paper, PV panels, single-use plastics), productFeeSummary block integrated into XSD v3.0, EPR MOHU coexistence since 2023.

Technical schema

The commercial invoice format remains free: paper, PDF, EDI or PEPPOL. What is mandated is the format of the declaration sent to NAV: XML compliant with the Online Számla v3.0 schema published on onlineszamla.nav.gov.hu. The XML document declares the full invoice (header, lines, VAT, parties) and is embedded in a ManageInvoiceRequest wrapper containing a common header (common:header), an authenticated user block, and a list of invoiceOperations.

Synthetic NAV API call with a CREATE invoiceOperation (the actual payload is base64-encoded or compressed):

xmlonline-szamla-v3.xml
<?xml version="1.0" encoding="UTF-8"?>
<ManageInvoiceRequest xmlns="http://schemas.nav.gov.hu/OSA/3.0/api"
                     xmlns:common="http://schemas.nav.gov.hu/NTCA/1.0/common">
  <common:header>
    <common:requestId>RID2026051600187</common:requestId>
    <common:timestamp>2026-05-16T10:30:00.000Z</common:timestamp>
    <common:requestVersion>3.0</common:requestVersion>
    <common:headerVersion>1.0</common:headerVersion>
  </common:header>
  <common:user>
    <common:login>userLogin</common:login>
    <common:passwordHash>5C7CFA…</common:passwordHash>
    <common:taxNumber>12345678</common:taxNumber>
  </common:user>
  <invoiceOperations>
    <compressedContent>false</compressedContent>
    <invoiceOperation>
      <index>1</index>
      <invoiceOperation>CREATE</invoiceOperation>
      <invoiceData>PD94bWwgdmVyc2lvbj0iMS4wIj8+ ...</invoiceData>
    </invoiceOperation>
  </invoiceOperations>
</ManageInvoiceRequest>

Submission flow

The seller delivers the commercial invoice to the recipient through the usual channels (paper, email, EDI, PEPPOL). In parallel, the seller's accounting software publishes an Online Számla XML to the NAV API over authenticated REST/HTTPS using a technical user (login + SHA-512 password + XML exchange key).

textnav-flow.txt
┌────────────┐                       ┌────────────┐
│ HU Seller  │──── invoice ──────────>│ HU Buyer   │
│ (ERP)      │ (PDF, EDI, paper ok)   │ (ERP)      │
└────────┬───┘                       └────────────┘

         │ XML Online Számla v3.0

┌──────────────────┐
│  NAV (Online     │
│  Számla)         │  ← near-real-time report,
└──────────────────┘     within 5 minutes

The legal deadline is 5 minutes after issuance for automated invoices, immediate for manual ones. NAV returns a transactionId response; polling retrieves the final status (ACCEPTED, WARNING, ERROR) with diagnostics.

Validation

Common pitfalls

  1. Reporting ≠ e-invoicing. NAV is not a clearance portal. Many teams treat Hungary as a full e-invoicing mandate; this is inaccurate. The commercial invoice circulates freely — it is the data that is reported in parallel.
  2. Strict 5-minute deadline for automated invoices. A nightly batch reporting every invoice of the day breaches the rules. NAV audits the gap between issuance date and XML arrival date.
  3. Authentication via technical user + XML token. NAV refuses end-user authentication: a dedicated technical user is required, its password hashed in SHA-512 and combined with an XML key transmitted in a specific block. Changing the password breaks every job if the key is not regenerated in parallel.
  4. Schema v3.0 vs v2.0 sunset in 2020. The v3.0 schema added fields (auto-billing status, detailed payment method, certain cross-border references). An integration still pointing at v2.0 returns an incompatible request version error.
  5. HUF 500,000 fine per undeclared invoice. The penalty (around €1,250 per invoice) for systematic non-reporting adds up fast. Teams often overlook the NotInvoice operations (cancellations, corrections) which must also be reported within the same deadline.