NAV Online Számla Validator Hungary
Verifique o XML de uma fatura húngara com o esquema e os códigos de rejeição da própria NAV — no navegador, sem envio.
What is NAV Online Számla, and who has to use it?
Online Számla is the real-time invoice reporting system of Hungary’s tax authority, the NAV (Nemzeti Adó- és Vámhivatal). Since 2021 every invoice issued under Hungarian VAT rules goes through it — there is no threshold and no exemption for small amounts or private customers. Version 3.0 of the schema is the one in force. When the reported XML carries completenessIndicator set to true, it is not a filing receipt at all: that XML *is* the electronic invoice within the meaning of §169 b) and §170 (1) b) of the Hungarian VAT Act. This free validator checks the file against the official NAV XSD entirely in your browser, so the invoice never leaves your machine.
The NAV’s own schema, and the NAV’s own rejection codes
The first layer is the official XSD published by the NAV itself on github.com/nav-gov-hu, under the MIT licence — the tax authority wrote the licence, and it explicitly permits use, modification and redistribution. That is what also allows this tool to quote the NAV’s 237 official rejection codes word for word, each with the ValidatorFaultType the NAV returns. Structure, types, cardinalities and closed enumerations are never re-encoded by hand.
The second layer runs the checks that are decidable on the document alone, and reports them with the NAV’s own fault type: missing lines, line numbering that is not strictly increasing, a seller identical to the buyer (tax number, name or IBAN), the forbidden VAT code 4, an inverted delivery period, a line referencing itself — and the arithmetic, down to the forint: quantity × unit price = line net, Σ line nets = invoice net, Σ VAT per rate = invoice VAT, net + VAT = gross.
Three of the thirty sample invoices the NAV publishes are arithmetically wrong, and this tool says so rather than looking the other way. Termékdíjas számla declares a VAT amount of 280 000 where the lines, the per-rate total and the gross all say 280 800; Belföldi értékesítés több ÁFA típus has a gross 600 below net + VAT; Gyűjtőszámla 1 carries a rate line of 1 304 000 where 27% of 4 832 000 is 1 304 640. These files predate the checks that now reject them. When the rule and the file come from the same institution and contradict each other, it is the demo file that is out of date.
Key takeaways
- Every Hungarian invoice goes through Online Számla — since 2021, with no threshold whatsoever.
- When completenessIndicator is true, the XML is not a report about the invoice: it IS the electronic invoice, legally.
- The NAV publishes its schema under the MIT licence — the cleanest licensing position of any tax authority we work with.
- The Hungarian tax number check digit is NOT verified here: the formula circulating on blogs appears in no official source, and the NAV itself validates by querying its register.
- Three of the NAV’s own thirty sample invoices fail the NAV’s own arithmetic. That is a fact about the samples, not a bug in the validator.
Frequently asked questions
Is the XML sent to Online Számla a report, or the invoice itself?
It depends on one field. When completenessIndicator is set to true, the transmitted XML is the electronic invoice itself within the meaning of §169 b) and §170 (1) b) of the Hungarian VAT Act — the specification says so in §2.6.2. When it is false, the XML reports the data of an invoice issued elsewhere. The distinction matters: in the first case there is no other invoice document anywhere.
Why does this tool not check the Hungarian tax number (adószám) check digit?
Because no official source publishes the formula. The weights 9-7-3-1-9-7-3 mod 10 circulate on blogs and in forum posts, but they appear in no NAV document. The NAV’s own XSD only constrains the shape of the number, and the NAV validates existence by querying its taxpayer register (queryTaxpayer) — something no client-side tool can do. A rule that cannot be sourced is not invented here.
What can only the NAV check?
Four things, and the tool lists them on screen rather than hiding them behind a green badge: whether the invoice number is unique, whether the customer exists in the taxpayer register, whether the chain of modifying documents is coherent, and whether the party filing is authorised to do so. All four require the NAV’s database.
Can a modifying invoice have no lines at all?
Yes, and rejecting it would be wrong. A document that carries an invoiceReference is a modification, and it may correct the header alone without touching any line — two of the NAV’s official samples do exactly that. Only an original invoice must have lines.
Is my invoice uploaded to a server?
No. The XSD engine and every check run in your browser, in WebAssembly. The file never leaves your machine — which matters here more than usual, since with completenessIndicator set to true this file is the invoice itself.
ValidateFin is an independent tool, not certified or endorsed by the Nemzeti Adó- és Vámhivatal. “Official” refers to the schema used — the Online Számla 3.0 XSD published by the NAV under the MIT licence — not to any accreditation of this tool. Validating a file here does not report it to the NAV.