NAV Online Invoice integration checklist

A machine-to-machine connection between your ERP or invoicing system and Hungary’s NAV Online Invoice system is more than one development task. This list breaks down what has to be settled before and during the integration — from the technical user to operations after go-live. Each item states who typically owns it and why it matters.

Statutory deadlines and the interface’s technical limits come from the NAV sources listed at the bottom of the page. The timing suggested for each stage is our recommendation for project sequencing, not a NAV requirement. In any specific case, NAV’s current documentation prevails.

Updated: 8 October 2026

1. Prerequisites on the NAV side

Machine reporting requires a technical user. Only the primary user — the taxpayer’s legal representative or permanent proxy — can create one on the Online Invoice web interface and generate its keys.

Recommended: before development starts

Confirm who the primary user is in the Online Invoice system and that they are available for the project. (Owner: Finance / management) — Only the primary user can create the technical user and its keys. If that person is unavailable, the project stalls at step one.
Create the technical user and generate the XML signature key and the XML exchange key. (Owner: Primary user) — The technical user’s login is generated by the system; the primary user sets the password. Both keys are needed to sign requests and decrypt the token.
Register in the test environment too, with a separate technical user and separate keys. (Owner: Primary user + IT) — The test and production environments are independent: production credentials do not work in test, and vice versa.
Decide where the password and keys are stored and who can access them. (Owner: IT security) — They allow reporting to NAV on the company’s behalf. Treat them as secrets, separated from application data.
Define the key rotation process: who is notified when the primary user regenerates the keys. (Owner: IT + finance) — After regeneration, submissions with the old keys fail. NAV lists this among the most common errors.

2. Source data and 3.0 XML mapping

NAV expects data according to the Online Invoice 3.0 XML schema. Most later errors stem from source-system data that does not map unambiguously to the schema fields.

Recommended: in the first development phase

Create a field-level mapping between the source system’s invoice data and the 3.0 XML fields. (Owner: ERP owner + tax) — It becomes the shared basis for development and testing. Without it, every validation error reopens the question of where the data comes from.
List the invoice types you issue: domestic, foreign customer, private individual, foreign currency, aggregate, advance payment, issued as a VAT group member or legal successor. (Owner: Billing / accounting) — Since 2021 there is no threshold: invoices to private individuals and foreign customers must be reported too, without a private individual’s name and address. From 2026 the tax numbers of the VAT group member and the legal predecessor must also be reported.
Map internal VAT codes to the XML VAT fields, including exemption and other legal grounds. (Owner: Tax) — VAT rates, exemptions and reverse-charge flags are among the most frequent sources of business validation errors.
Document how the system handles modification and storno invoices: original invoice reference, modificationIndex, modifyWithoutMaster. (Owner: ERP owner) — The modificationIndex must be unique within the chain. modifyWithoutMaster must match whether an original report exists. A storno closes the chain.
Check invoice number formats, including original invoice numbers referenced in modifications. (Owner: ERP owner) — From 1 January 2026 whitespace in the original invoice number is an ERROR (message 79).

3. Validations and error handling

NAV checks submitted data against schema and business rules. An ERROR means rejection, a WARN does not — but in recent years NAV has tightened several WARNs into ERRORs.

Recommended: in parallel with development

Make sure the system runs its own 3.0 schema check before submission. (Owner: IT) — NAV rejects schema-invalid requests. Catching them locally is cheaper than decoding them from NAV’s response.
Compare the current validation message list with your invoice types and flag the ERRORs that can occur. (Owner: IT + tax) — NAV publishes the messages in the interface specification and its GitHub repository. The list changes: in September 2025 fifteen, and in January 2026 further WARN messages became rejecting ERRORs.
Prepare for the tightenings NAV has already announced: the VAT group member tax number (60) and the cancelled delivery date (11401) rules. (Owner: IT + tax) — Message 60 has been an ERROR in the test environment since 1 January 2026 and will become one in production after a transition period. NAV has announced that WARN 11401 will be tightened into an ERROR.
Review the WARN messages on past submissions and decide which ones to fix in the source data. (Owner: Tax) — An invoice with a WARN still fulfils the reporting obligation, but today’s WARN may become the next tightening’s ERROR.
Define who receives and fixes rejected (ABORTED) invoices, and by when. (Owner: Finance + IT) — After a rejection the report must be repeated once the error is fixed. If that does not succeed within 3 working days, manual entry is mandatory.
Decide whether you will use technical annulment and who approves it on the web interface. (Owner: Finance) — It is only for technical errors, not for correcting business content — that requires a modification or storno invoice. The primary user must approve each annulment.

4. Submission, deadlines and status tracking

Data on invoices issued with invoicing software must be transmitted immediately upon issue. The obligation is fulfilled once NAV confirms successful processing.

Recommended: in the second development phase

Check that submission is an automatic step tied to invoice issue, not a later manual action. (Owner: IT) — Under section 13/A of NGM Decree 23/2014, reporting is due immediately when the invoice is issued.
Implement transaction status queries and treat an invoice as reported only on DONE status. (Owner: IT) — A successful HTTP response only means receipt. Fulfilment is confirmed by NAV’s processing result (DONE); an ABORTED invoice must be resubmitted.
Plan for NAV outages and your own failures, with the statutory 24- and 48-hour deadlines. (Owner: IT + finance) — If NAV is unavailable, data must be sent within 24 hours of restoration. If the failure is on your side, after 48 hours you must report it on NAV’s interface and switch to manual entry.
Handle timeouts without sending duplicates. (Owner: IT) — After a NAV-side timeout, saving can continue for minutes. Query the transaction list and status before resubmitting.
Check batching and rate limits: at most 100 invoices per request, 1 request per second per IP address. (Owner: IT) — Requests above the limit are delayed and dropped after 60 seconds of waiting. At high volume this easily causes missed deadlines.

5. Testing and go-live

Data recorded in NAV’s test environment does not appear in NAV’s records, so it is the place to run every invoice type before go-live.

Recommended: at least 2–4 weeks before go-live

Build a test set covering every invoice type from section 2, including modifications and stornos. (Owner: Billing + IT) — Rare cases — foreign-currency modifications, foreign customers, aggregate invoices — are usually the first to fail in production.
Run the test set in the test environment and document NAV’s responses. (Owner: IT) — You meet the same validations as in production, without consequences. Test environment availability is not guaranteed, so plan buffer time.
Test the failure paths too: fixing a rejected invoice, timeouts, key rotation. (Owner: IT) — Everyone tests the happy path. Production problems typically come from error handling.
Agree the go-live date, the owner and the fallback plan. (Owner: Project lead) — From go-live, reporting is a legal obligation. If the machine channel stops, someone must know how to enter data manually.

6. Operations and audit

After go-live the task is continuous control: for every invoice you need to know whether it reached NAV and what the result was.

Recommended: introduce at go-live

Set up a daily overview of submitted, processing, WARN and rejected invoices. (Owner: Finance) — Rejected invoices must be resubmitted within the deadline. Someone has to notice them first.
Retain every submission request, its transaction ID and NAV’s response. (Owner: IT) — In a NAV audit this proves what was sent, when, and how NAV responded.
Periodically reconcile your invoice data with what NAV holds. (Owner: Accounting) — NAV’s records can be queried, so discrepancies surface before the VAT return.
Assign someone to follow NAV Online Invoice announcements and validation changes. (Owner: IT + tax) — NAV usually announces tightenings a few months ahead and introduces them in the test environment first.
Make the owners aware of the penalty risk. (Owner: Management) — Under sections 220 and 229 of the Hungarian Tax Administration Act, missing or incorrect reporting can lead to a default penalty of up to HUF 1 million per invoice for non-individual taxpayers.