Hungary (NAV Online Számla)

Hungary requires real-time invoice data reporting to NAV (Nemzeti Adó- és Vámhivatal, the Hungarian tax authority) through the Online Számla v3.0 interface. Space Invoices reports invoices, credit notes (MODIFY), invoice voids (STORNO), advance invoices, and advance deduction on final invoices for Hungarian entities.

Scope

Supported	Out of scope
Invoices, credit notes (MODIFY), invoice voids (STORNO)	Online cash registers / receipts
Advance invoices and advance deduction on final invoices	Simplified and aggregate invoices
B2B, B2C, EU and third-country customers	Self-billing
Ordinary VAT rates 5%, 18%, and 27%	Margin schemes
	VAT groups, for both supplier and customer (Hungarian `vatCode=5` tax numbers)
	Multi-tax-line invoices (more than one tax rate on a single line)
	Batch modifications
	Invoices issued under the EU One-Stop-Shop (OSS) special scheme, which are not reported to NAV
	VAT rates other than 5%, 18%, and 27% on ordinary lines — zero-rate, exempt, out-of-scope, reverse-charge, or otherwise untaxed lines must use an explicit `vat_treatment` instead of a rate (see Explicit VAT treatment)
	MNB exchange rates (only ECB rates are supported — see ECB exchange rate election)

Obligation

Hungary has no invoice-data reporting threshold: invoices issued by Hungarian VAT taxpayers are reportable whether the customer is a Hungarian business, a private person, or an EU or third-country customer, unless an admin records an explicit exemption. Real-time reporting is treated as mandatory by default (obligation: "required"). Final issuance of a Hungarian invoice is blocked with 422 NAV_NOT_CONFIGURED until NAV is enabled with verified credentials, unless an admin has declared the entity exempt with a recorded legal basis (obligation: "exempt", exemption_reason).

Drafts are never blocked. You can create and edit draft invoices for a Hungarian entity regardless of NAV configuration; the check only runs on final issuance.

Setup

1. Register a NAV technical user

On the NAV Online Számla portal, the primary user registers a technical user and generates:

login and password,
a signing key, and
a 16-character exchange key.

Sandbox entities report to the NAV TEST environment; live entities report to NAV production. These are separate NAV registrations — a TEST technical user does not work against production, and vice versa. Register a technical user for each environment you use.

2. Store the credentials

Credentials are write-only: the API never echoes them back, only verification and error metadata.

Store NAV technical user credentialstypescript

const _settings = await sdk.entities.storeEntityNavCredentials("ent_abc123", {
  login: "abc123XY",
  password: "correct-horse-battery-staple",
  signing_key: "synthetic-signing-key-value",
  exchange_key: "0123456789abcdef",
});

When NAV dispatch is available for the entity’s environment, storing credentials also verifies them against NAV. A rejected credential (422 NAV_CREDENTIALS_REJECTED) or an unavailable verification (503 NAV_VERIFICATION_UNAVAILABLE) leaves any previously stored credential unchanged. You can re-verify stored credentials at any time with POST /entities/{id}/nav/credentials/verify.

3. Configure distinct number formats

NAV rejects a duplicate invoice number across invoices, credit notes and advance invoices for the same supplier. A newly created entity with country_code: "HU" already gets distinct number_formats for these three types — invoice: "SZ-{yyyy}-{nnnnn}", credit_note: "JSZ-{yyyy}-{nnnnn}", advance_invoice: "ESZ-{yyyy}-{nnnnn}" — with matching business-unit variants in unit_number_formats (e.g. invoice: "SZ-{yyyy}-{u}-{nnnnn}"), so a fresh Hungarian entity can enable NAV without editing numbering first. Other document types (estimate, delivery note, expense) keep the shared {yyyy}-{nnnnn} default. This only applies to entities created after this default was introduced — existing entities and any entity where these formats were later changed are not affected. If your entity’s number_formats still overlap (for example, an entity created before this default, or one where numbering was changed back to the shared default), configure distinct number_formats for the three types via the entity settings endpoint before enabling NAV.

If the entity also issues documents per business unit, unit_number_formats needs the same treatment: business-unit numbering is shared by every business unit of the entity (it is keyed by document type only, not per unit — a specific unit is distinguished at render time by its own {u} value), so the three business-unit formats must also be pairwise distinct from each other. Cross-type combinations count too — a business-unit invoice format and an entity-level credit note format draw from independent counters but can still render the identical number, and that combination is checked as well, in both directions (entity-level vs. business-unit, and business-unit vs. entity-level, for every pair of the three document types). Enabling NAV — or staying enabled — is rejected with 422 NAV_NUMBER_FORMATS_OVERLAP while any of these comparisons (main-vs-main, unit-vs-unit, or cross main-vs-unit) could produce the same number for two different document types. The response’s conflicts array identifies exactly which document types and which format pool (entity-level or business-unit) collide.

4. ECB exchange rate election

For foreign-currency invoices, the supplier must have elected with NAV to use European Central Bank exchange rates rather than the Hungarian National Bank (MNB) rate. Space Invoices only supports the ECB election; record it in the entity’s NAV settings with ecb_exchange_rate_elected: true. An entity that has not made this election with NAV, or that relies on MNB rates, is out of scope.

5. Cash accounting election (optional)

If the supplier elected the Hungarian cash accounting scheme (pénzforgalmi elszámolás, VAT Act Chapter XIII/A), set cash_accounting: true. Eligible invoices then report NAV’s cashAccountingIndicator. The invoice document itself must also show the phrase “Pénzforgalmi elszámolás”; automatic printing of that phrase on Space Invoices PDFs is not available yet, so add it through your document note or template until it is. An invoice that mixes cash-accounting-covered and uncovered transactions is rejected and must be split. Changing this election is blocked with 409 NAV_CASH_ACCOUNTING_LOCKED while a NAV submission is in flight, since queued reports were built against the previous election.

6. Enable NAV dispatch

Enabling requires verified credentials to already be stored, and requires distinct number formats (step 3) to already be configured.

Enable NAV dispatchtypescript

const _settings = await sdk.entities.modifyEntityNavSettings("ent_abc123", {
  enabled: true,
});

Declaring an exemption instead

If the entity is not obligated to report (for example, it only issues invoices genuinely out of scope of Hungarian real-time reporting), an admin can record an exemption with its legal basis instead of enabling NAV:

Declare an entity exempt from NAV reportingtypescript

const _settings = await sdk.entities.modifyEntityNavSettings("ent_abc123", {
  obligation: "exempt",
  exemption_reason: "Entity only issues invoices out of scope of Hungarian real-time reporting.",
});

Setting obligation back to "required" clears any stored exemption reason.

Issuing invoices

Explicit VAT treatment for non-standard lines

Set items[].e_invoicing.hungary.vat_treatment explicitly whenever a line has no positive, non-reverse-charge VAT percentage. It is never inferred from transaction_type, customer country, or product classification — you must supply it. The supported cases:

`vat_treatment.type`	When to use it
`exemption`	A VAT exemption case (`AAM`, `TAM`, `KBAET`, `KBAUK`, `EAM`, `NAM`) — requires `case` and a `reason` (max 200 characters, non-blank).
`out_of_scope`	An out-of-scope-of-VAT case (`ATK`, `EUFAD37`, `EUFADE`, `EUE`, `HO`) — requires `case` and a `reason` (max 200 characters, non-blank).
`domestic_reverse_charge`	Domestic reverse charge (no VAT charged, purchaser accounts for it).
`no_vat_charge`	No VAT charge for another reason not covered above.

Domestic reverse charge:

Create an invoice with a domestic reverse-charge linetypescript

const _invoice = await sdk.invoices.create({
  customer: {
    name: "Budapest Ipari Kft.",
    country: "Hungary",
    country_code: "HU",
    tax_number: "12345678-2-42",
    address: "Váci út 1.",
    city: "Budapest",
    post_code: "1133",
  },
  items: [
    {
      name: "Construction subcontracting service",
      quantity: 1,
      price: 500000,
      classification: "service",
      unit: "UN",
      taxes: [{ rate: 0, classification: "reverse_charge" }],
      e_invoicing: {
        hungary: { vat_treatment: { type: "domestic_reverse_charge" } },
      },
    },
  ],
});

An intra-Community exempt supply:

Create an invoice with an exempt linetypescript

const _invoice = await sdk.invoices.create({
  customer: {
    name: "Berlin Handels GmbH",
    country: "Germany",
    country_code: "DE",
    tax_number: "DE123456789",
    address: "Unter den Linden 1",
    city: "Berlin",
    post_code: "10117",
  },
  items: [
    {
      name: "Intra-Community supply of goods",
      quantity: 10,
      price: 1200,
      classification: "product",
      unit: "UN",
      taxes: [{ rate: 0, classification: "exempt" }],
      e_invoicing: {
        hungary: {
          vat_treatment: {
            type: "exemption",
            case: "KBAET",
            reason: "Intra-Community exempt supply of goods.",
          },
        },
      },
    },
  ],
});

A foreign buyer does not, by itself, change the required VAT treatment — set vat_treatment based on the actual transaction, not the customer’s country.

Private-person customers

For a private-person (B2C) customer, set is_end_consumer: true on the customer. NAV Online Számla reports these lines without the customer’s name and address, even though the invoice document itself still needs them for the customer to be identifiable:

Create an invoice for a private-person customertypescript

const _invoice = await sdk.invoices.create({
  customer: {
    name: "Kovács János",
    is_end_consumer: true,
    country: "Hungary",
    country_code: "HU",
    address: "Kossuth Lajos utca 5.",
    city: "Debrecen",
    post_code: "4024",
  },
  items: [
    {
      name: "Consulting service",
      quantity: 1,
      price: 80000,
      classification: "service",
      unit: "UN",
      taxes: [{ rate: 27, classification: "standard" }],
    },
  ],
});

Credit notes

A Hungarian credit note (MODIFY) must reference exactly one original invoice. Multi-original corrections are not supported.

Advance invoices and final-invoice deductions

An advance invoice’s own lines are always reported as advance-payment lines (NAV’s advanceIndicator). When an advance invoice’s payment is later applied to a final invoice, Space Invoices automatically adds one negative deduction line per (advance, VAT rate) combination to the final invoice’s NAV report — you do not construct these lines yourself. Each deduction line references the advance invoice’s number and its recorded payment date, and reports in HUF (a HUF advance needs no conversion; a foreign-currency advance requires a HUF-quoted exchange rate on the advance invoice, or issuance fails with 422 NAV_ADVANCE_EXCHANGE_RATE_INVALID). An advance invoice applied without a recorded payment date fails with 422 NAV_ADVANCE_PAYMENT_DATE_MISSING.

Finalizing a draft invoice with linked advances. For Hungarian entities with NAV enabled, finalizing a draft invoice that already has advances linked to it (via advance_applied relations created at draft time) allocates those advances in the same database transaction as finalization, before the NAV submission’s report XML is built. This guarantees the report NAV receives already includes the advance deduction lines. Finalizing such a draft is therefore all-or-nothing: if advance allocation fails (for example, a currency mismatch), the whole finalize fails and the document is not issued, rather than issuing successfully and only then failing to apply the advance.

Immutability

Once a document has been reported to NAV, it is immutable — further edits return 409 NAV_DOCUMENT_IMMUTABLE — except when NAV rejected the report (a failed/aborted submission), in which case the document can be corrected and retried.

Status lifecycle and actions

Every invoice, credit note, and advance invoice carries a server-managed nav object once it is subject to NAV reporting:

`nav.status` values

reserved

A NAV submission has been reserved for this document but not yet dispatched.

dispatching

The submission is being sent to NAV.

submitted

NAV accepted the transmission; the result is not yet known.

done

NAV finished processing and accepted the invoice.

done_with_warnings

NAV accepted the invoice but returned warning messages — see nav.messages.

aborted

NAV rejected the submission (technical or business validation failure).

ambiguous

The result of a dispatch attempt is unknown (for example, a timeout) and must be reconciled against NAV before retrying.

failed

The submission failed and did not reach a NAV outcome.

annulment_pending

A technical annulment has been submitted and is awaiting NAV's decision.

annulled

NAV accepted the technical annulment.

nav.retry_available, nav.reconcile_available and nav.annulment_available tell you which of the following actions are currently valid for the document; call the action rather than inferring availability purely from status.

Retry

Retries the current submission with a fresh dispatch attempt, either after it’s failed or aborted, or after its technical annulment has been verified by NAV (nav.status is annulled) — in that case the annulled submission and its annulment are superseded and the report is re-submitted under the same invoice number: an invoice or advance invoice is rebuilt as a new CREATE from the document’s current data; a credit note re-sends its original MODIFY/STORNO report. Previous attempts are kept for audit as superseded. Returns 409 NAV_RETRY_NOT_AVAILABLE when not currently available.

Retry a failed NAV submissiontypescript

const _invoice = await sdk.invoices.retryInvoiceNav("inv_abc123");

Reconcile

Runs reconciliation with NAV immediately instead of waiting for the next scheduled pass. For a submitted submission this polls NAV’s transaction status; for an ambiguous submission this searches NAV’s transaction list for a matching prior dispatch. Never sends anything new to NAV. Returns 409 NAV_RECONCILE_NOT_AVAILABLE when not currently available.

Reconcile a NAV submission nowtypescript

const _invoice = await sdk.invoices.reconcileInvoiceNav("inv_abc123");

Reconciliation only ever confirms an ambiguous submission when NAV’s transaction list returns our exact original document byte-for-byte — that moves it to submitted. Everything else leaves the document ambiguous, with reconciliation retrying automatically in the background: no matching NAV transaction found yet (NAV_RECONCILE_NO_CANDIDATE), a transaction found but not confirmed as this submission (NAV_RECONCILE_UNMATCHED_CANDIDATE), too many candidate transactions to check safely (NAV_RECONCILE_CANDIDATES_EXCEEDED), or the scan itself couldn’t be conclusively completed (NAV_RECONCILE_LOOKUP_INCONCLUSIVE). None of these is ever auto-resolved to failed. To resolve a submission stuck ambiguous, check the invoice directly in NAV Online Számla — if NAV shows no record of it, contact support. See Status actions below.

Technical annulment

Submits a NAV technical annulment (manageAnnulment) for a done/done_with_warnings submission with no annulment already pending or done. A technical annulment corrects a technical mistake in the transmission itself (for example, ERRATIC_INVOICE_NUMBER) — it does not correct business errors in the invoice; issue a credit note (MODIFY) or void (STORNO) for those. A submitted technical annulment requires manual approval on the NAV portal before it takes effect; it is not automatically accepted. Once NAV verifies the annulment (nav.status becomes annulled), retry the document — for an invoice or advance invoice this reports a corrected version, rebuilt from the document’s current data, under the same invoice number; see Retry.

Technically annul a NAV submissiontypescript

const _invoice = await sdk.invoices.annulInvoiceNav("inv_abc123", {
  annulment_code: "ERRATIC_DATA",
  reason: "Duplicate submission cancelled.",
});

Returns 409 NAV_ANNULMENT_NOT_AVAILABLE when not currently available.

Errors

Setup and credentials

Code	Meaning	Fix
`NAV_NOT_SUPPORTED_FOR_COUNTRY`	The NAV settings/credentials endpoints were called for a non-Hungarian entity.	Only call these endpoints for Hungarian entities.
`NAV_ENVIRONMENT_UNSUPPORTED`	The entity’s `environment` is neither sandbox nor live, so it cannot be mapped to a NAV protocol environment.	Set the entity to a supported environment before configuring NAV.
`NAV_TAX_NUMBER_INVALID`	The entity’s `tax_number` could not be parsed as a Hungarian tax number.	Correct the entity’s tax number.
`NAV_CREDENTIALS_REJECTED`	NAV gave a definitive rejection of the stored technical user credentials (login, password, signing key, or exchange key) during verification.	Re-check the credentials on the NAV portal, then store them again.
`NAV_VERIFICATION_UNAVAILABLE`	Verification could not be completed — NAV was unreachable, returned scheduled maintenance, dispatch is currently switched off, or a transport/parse failure occurred. Any previously stored credential and its verification state are left unchanged.	Retry verification later.
`NAV_CREDENTIALS_UNREADABLE`	A stored credential could not be decrypted (for example, after key-rotation drift).	Re-enter and store the credentials.
`NAV_CREDENTIALS_NOT_CONFIGURED`	No NAV credentials are stored for this entity/environment.	Store credentials before verifying or enabling NAV.
`NAV_CREDENTIALS_NOT_VERIFIED`	An action requires verified credentials, but none are currently verified.	Store or re-verify credentials first.
`NAV_CREDENTIALS_TAXPAYER_MISMATCH`	Enabling NAV was attempted with a stored credential verified for a different tax number than the entity’s current one.	Enter and verify NAV credentials for the entity’s current tax number before enabling NAV reporting.
`NAV_CREDENTIALS_CHANGED`	The stored credentials changed concurrently while verification was in progress.	Retry the request.
`NAV_TAX_NUMBER_CHANGED`	The entity’s tax number changed concurrently while credentials were being stored.	Retry the request.
`NAV_CREDENTIALS_IN_USE`	Attempted to delete credentials while NAV dispatch is enabled, a submission is in flight, or a technical annulment is awaiting verification.	Disable NAV dispatch and wait for any in-flight submission or annulment to finish, then delete.
`NAV_NUMBER_FORMATS_OVERLAP`	Invoice, credit note, and advance invoice number formats (entity-level or business-unit) could produce the same number.	Configure distinct `number_formats`/`unit_number_formats` per document type — see Configure distinct number formats.
`NAV_CASH_ACCOUNTING_LOCKED`	Attempted to change the cash accounting election while a NAV submission is in flight.	Wait for the in-flight submission to complete, then update the election.
`NAV_EXEMPTION_REASON_REQUIRED`	Setting `obligation: "exempt"` without an `exemption_reason`.	Provide a legal-basis `exemption_reason`.
`NAV_EXEMPTION_REASON_NOT_ALLOWED`	An `exemption_reason` was provided while `obligation` is `"required"`.	Only set `exemption_reason` together with `obligation: "exempt"`.
`NAV_SOFTWARE_IDENTITY_NOT_CONFIGURED`	The deployment’s `NAV_SOFTWARE_*` identity configuration is missing or invalid.	Operator/deployment issue — not fixable from the API; contact support.

Issuance

Code	Meaning	Fix
`NAV_NOT_CONFIGURED`	Final issuance blocked: NAV is required but not enabled with verified credentials.	Complete Setup, or record an exemption.
`NAV_INVOICE_DATA_INVALID`	Issuance-time validation of the mapped NAV invoice data failed; the response includes the specific `issues`.	Inspect `issues` and correct the referenced fields — see Invoice-data validation issues below.
`NAV_INVOICE_NUMBER_NOT_UNIQUE`	The invoice number collides with another document already reported to NAV for this entity.	Use a number that has not already been reported, or resolve the number-format overlap.
`NAV_CREDIT_NOTE_ORIGINAL_REQUIRED`	A Hungarian credit note has no (or more than one) linked original invoice/advance invoice.	Reference exactly one original document.
`NAV_ORIGINAL_NOT_REPORTED`	The credit note’s original document has not been successfully reported to NAV yet.	Fix and retry the original document’s NAV report first.
`NAV_CASH_ACCOUNTING_MIXED_INVOICE`	An invoice mixes cash-accounting-covered and uncovered transactions.	Split the invoice so each document is entirely covered or entirely uncovered.
`NAV_ADVANCE_PAYMENT_DATE_MISSING`	An advance invoice applied to this final invoice has no recorded payment date.	Ensure the advance invoice has a recorded payment before finalizing/issuing the final invoice.
`NAV_ADVANCE_EXCHANGE_RATE_INVALID`	An applied foreign-currency advance invoice has no HUF-quoted exchange rate.	Store a HUF-quoted exchange rate on the advance invoice.

Document immutability

Code	Meaning	Fix
`NAV_DOCUMENT_IMMUTABLE`	Attempted to edit fiscal/legal fields on a document already reported to NAV (and not in a correctable `failed`/`aborted` state).	Issue a credit note or technical annulment instead of editing.
`NAV_CREDIT_NOTE_VOID_UNSUPPORTED`	An issued Hungarian credit note cannot be voided: once issued it must be reported to NAV, even if it has not been dispatched yet.	Issue a further corrective credit note instead.
`NAV_ADVANCE_INVOICE_VOID_UNSUPPORTED`	An advance invoice already reported to NAV cannot be voided; Space Invoices can’t yet issue a corrective credit note against an advance invoice directly.	If the advance has been applied to a final invoice, issue a corrective credit note against that final invoice instead; otherwise contact support.
`NAV_ADVANCE_APPLICATION_AFTER_ISSUANCE`	Attempted to apply/link an advance to an invoice that already has a NAV submission.	Advances must be applied before the invoice is reported; use a credit note to correct an already-reported invoice.
`NAV_VOID_WITH_ADVANCES_UNSUPPORTED`	Voiding a NAV-reported invoice that has applied advances is not supported, because the generated cancellation would not reverse the reported advance deductions.	Issue a credit note for the amounts to correct instead of voiding.

Status actions (retry, reconcile, annulment)

Code	Meaning	Fix
`NAV_SUBMISSION_NOT_FOUND`	No NAV submission exists for this document.	The document has not been reserved for NAV reporting; nothing to retry/reconcile/annul.
`NAV_RETRY_NOT_AVAILABLE`	Retry was called while the submission is not `failed`/`aborted`.	Check `nav.retry_available` before calling retry.
`NAV_RETRY_CONFLICT`	The submission was concurrently updated (for example, by another retry) during the retry attempt.	Retry the request.
`NAV_RECONCILE_NOT_AVAILABLE`	Reconcile was called while the submission is not `submitted`/`ambiguous`.	Check `nav.reconcile_available` before calling reconcile.
`NAV_RECONCILE_CANDIDATES_EXCEEDED`	Too many NAV transactions matched this row’s window during reconciliation to safely conclude an outcome.	The submission stays `ambiguous`; this is visible to operators and does not need a caller-side fix.
`NAV_RECONCILE_LOOKUP_INCONCLUSIVE`	NAV’s `queryTransactionList` scan of the dispatch window itself could not be conclusively validated — for example a NAV-side error on a page, or a page with a malformed entry. Reconciliation stops scanning at that page: it doesn’t know what candidates it might be missing.	The submission stays `ambiguous` and is retried automatically with backoff.
`NAV_RECONCILE_UNMATCHED_CANDIDATE`	The transaction-list scan (once conclusively validated) found at least one candidate transaction in the dispatch window, but none of them could be confirmed as this submission — for any reason: different content, an undecodable original, a NAV-side error on that candidate’s status lookup, or a missing/empty result. This is never treated as proof the submission wasn’t received; the candidate might still be it.	The submission stays `ambiguous`, is retried automatically with backoff, and needs manual resolution — calling reconcile again re-runs the same check and will not resolve it by itself unless the underlying NAV data changes. Check NAV Online Számla and contact support if it persists.
`NAV_RECONCILE_NO_CANDIDATE`	The transaction-list scan for the dispatch window was conclusively validated (every page a schema-valid, `funcCode=OK` response with no malformed entries) but found no candidate transaction at all. This is never treated as proof the submission wasn’t received — a later scan may still surface it.	The submission stays `ambiguous` and is retried automatically with backoff. Check NAV Online Számla; if NAV has no record of the invoice, contact support to resolve it.
`NAV_ANNULMENT_NOT_AVAILABLE`	Annulment was called while the submission is not `done`/`done_with_warnings`, or an annulment is already pending/done.	Check `nav.annulment_available` before calling annulment.
`NAV_DISPATCH_UNAVAILABLE`	A manual reconcile could not reach NAV because dispatch is currently switched off at the deployment level for this environment.	Wait for dispatch to be enabled; scheduled processing resumes automatically once it is.

Invoice-data validation issues

NAV_INVOICE_DATA_INVALID’s response issues array carries one entry per problem, each with its own code and a path pointing at the offending field. The mapper validates every field NAV requires; the codes below are grouped by area — this is not exhaustive, but covers every category of check:

Area	Representative codes	Typical fix
Document identity	`NAV_INVOICE_NUMBER`, `NAV_REFERENCE_REQUIRED`, `NAV_REFERENCE_NOT_ALLOWED_FOR_CREATE`, `NAV_MODIFICATION_INDEX_INVALID`, `NAV_ORIGINAL_INVOICE_NUMBER`, `NAV_ORIGINAL_DELIVERY_DATE_REQUIRED`	Correct the document number or credit-note chain reference.
Currency and dates	`NAV_ECB_EXCHANGE_RATE_ELECTION_REQUIRED`, `NAV_EXCHANGE_RATE_MISSING`, `NAV_EXCHANGE_RATE_INVALID`, `NAV_EXCHANGE_RATE_QUOTE_CURRENCY_NOT_HUF`, `NAV_DATE_MISSING`, `NAV_DATE_INVALID`, `NAV_AMOUNT_INVALID`	Elect ECB rates (see ECB exchange rate election), or provide a finite, HUF-quoted exchange rate and valid dates/amounts.
Totals and lines	`NAV_INVOICE_NO_LINES`, `NAV_SUMMARY_VAT_RATE_MISSING`, `NAV_SUMMARY_RECONCILIATION_MISMATCH`, `NAV_LINE_DESCRIPTION`, `NAV_LINE_QUANTITY_MISSING`, `NAV_LINE_TOTAL_MISSING`, `NAV_LINE_UNIT_OF_MEASURE_OWN`	Ensure the document has lines and that line/document totals reconcile.
Supplier	`NAV_SUPPLIER_COUNTRY_NOT_HU`, `NAV_SUPPLIER_TAX_NUMBER_INVALID`, `NAV_SUPPLIER_VAT_GROUP_UNSUPPORTED`, `NAV_SUPPLIER_NAME`, `NAV_SUPPLIER_CITY`, `NAV_SUPPLIER_ADDRESS_INCOMPLETE`, `NAV_SUPPLIER_ADDRESS_DETAIL`	Correct the entity’s Hungarian tax number and address; VAT-group suppliers (`vatCode=5`) are out of scope (see Scope).
Customer	`NAV_CUSTOMER_MISSING`, `NAV_CUSTOMER_VAT_STATUS_UNDETERMINED`, `NAV_CUSTOMER_NAME`, `NAV_CUSTOMER_CITY`, `NAV_CUSTOMER_ADDRESS_INCOMPLETE`, `NAV_CUSTOMER_ADDRESS_DETAIL`, `NAV_CUSTOMER_COUNTRY_MISSING`, `NAV_CUSTOMER_TAX_NUMBER`, `NAV_CUSTOMER_TAX_NUMBER_INVALID`, `NAV_CUSTOMER_VAT_GROUP_UNSUPPORTED`	Provide the customer’s tax number, `is_end_consumer`, and address as required; VAT-group customers (`vatCode=5`) are out of scope.
Line VAT treatment	`NAV_LINE_MULTIPLE_TAXES`, `NAV_LINE_VAT_RATE_UNSUPPORTED`, `NAV_LINE_VAT_TREATMENT_REQUIRED`, `NAV_LINE_VAT_TREATMENT_NOT_ALLOWED`, `NAV_LINE_VAT_TREATMENT_INVALID`, `NAV_LINE_VAT_TREATMENT_INVALID_FOR_REVERSE_CHARGE`, `NAV_LINE_VAT_TREATMENT_REASON`, `NAV_LINE_VAT_CASE_CUSTOMER_MISMATCH`	Use exactly one tax per line, only rates 5/18/27 for ordinary lines, and an explicit `vat_treatment` for everything else — see Explicit VAT treatment.
Advance deduction lines	`NAV_LINE_ADVANCE_CONFIG_INVALID`, `NAV_LINE_ADVANCE_ORIGINAL_INVOICE_NUMBER`, `NAV_LINE_ADVANCE_EXCHANGE_RATE_INVALID`, `NAV_LINE_ADVANCE_EXCHANGE_RATE_REQUIRED`	These are set internally when building advance deduction lines; if seen, check the applied advance invoice’s currency and exchange rate.
Text and postal-code facets	`NAV_TEXT_INVALID_CHARACTERS`, `NAV_POSTAL_CODE_MISSING`, `NAV_POSTAL_CODE_INVALID`	Remove characters illegal in XML 1.0, or correct the postal code format.

This list is not exhaustive. Issuance-time validation problems are returned in the issues array of the NAV_INVOICE_DATA_INVALID response; rejections reported later by NAV appear on the document in nav.error_code and nav.messages.

Operations (deployment configuration)

NAV dispatch is gated per environment at the deployment level, independent of any single entity’s settings:

NAV_TEST_DISPATCH_ENABLED and NAV_LIVE_DISPATCH_ENABLED — off by default. While off, NAV submissions are reserved but dispatch is paused; nothing is sent to NAV until the corresponding switch is on.
NAV_SOFTWARE_* — the software identity NAV requires on every submission (developer: Studio 404 d.o.o.). Exact values are configured per deployment and are not documented here since they are not secrets an integration needs to supply.

NavSettingsResponse.dispatch_available reflects whether the relevant switch is currently on for that entity’s environment; submission_available additionally requires the entity to be enabled with verified credentials.

Pacing. Every NAV call made by an API process is paced to roughly 1 request/second, and a burst of documents from one request collapses into a single batched dispatch trigger rather than one dispatch run per document. This pacing bound is per-process, not cluster-wide — it keeps a single process well inside NAV’s rate limits, but does not itself guarantee a cluster-wide request rate when multiple processes dispatch concurrently. This is operational behavior, not something an integration configures.

See the Entities API Reference, Invoices API Reference, Credit Notes API Reference, and Advance Invoices API Reference.