Hungarian invoicing law does not care that your accounting is correct — it cares that NAV received the invoice data within the statutory window after issue, in the exact XML schema NAV publishes, signed with your technical user's request signature. ERPNext will happily let you submit a Sales Invoice with a customer whose EU VAT number sits in a free-text field, a tax template that nets two rates into one line, and a company tax number that never made it into the right place. None of that matters until NAV returns a warning or an aborted transaction and your finance team discovers, at month end, that a batch of invoices was never accepted. ERPNext core has no NAV client, no manageInvoice call, no transaction-status polling, and no concept of an invoice that is legally posted but not yet reported.

What we build is a proper Frappe app — its own module, its own DocTypes, installed on your bench alongside erpnext — not a pile of Server Scripts glued onto stock forms. A NAV Settings single DocType holds the technical user login, the password and signature keys (stored in Password fieldtype fields, never plain columns), the software identifier, and the environment switch between the NAV test service and production. A NAV Invoice Report DocType is created per Sales Invoice submission and carries the full lifecycle: the generated invoice XML, the base64 payload, the transactionId returned by manageInvoice, every queryTransactionStatus poll result, the NAV validation messages, and the final state. A NAV Tax Mapping child table maps your ERPNext Item Tax Templates and Tax Categories onto NAV's line VAT rate structures — standard rates, domestic reverse charge, intra-Community supply, margin scheme, out of scope — so the classification comes from master data you can audit, not from code someone has to redeploy.

Technically, the flow hangs off hooks.py doc events. on_submit of Sales Invoice validates that everything NAV needs is present — company tax number in the correct 8-3-2 form, customer tax number and address for domestic B2B above the itemised-VAT threshold, currency and exchange rate for non-HUF invoices, a line-level VAT rate on every row — and fails the submit with a specific field-level message rather than letting a bad invoice reach NAV. It then enqueues the report through Frappe's background queue with frappe.enqueue, so submission never blocks the user's browser. The client builds the XML for the current NAV Online Invoice schema version, computes the request signature, and posts to manageInvoice. Because NAV is asynchronous, a scheduler_events cron polls queryTransactionStatus for every pending report with backoff, parses the per-invoice result blocks, and writes warnings and errors back onto the NAV Invoice Report as a child table you can read without opening a log file.

Rejections raise a Frappe Notification to the finance role, and the correction workflow issues the NAV modify or storno operation with the correct modification-index chain when the accountant cancels and amends the invoice in ERPNext. Whitelisted methods (@frappe.whitelist()) expose submit, re-poll and status-read over the Frappe REST API, so middleware or a BI refresh can read reporting state without screen-scraping the desk. A Client Script adds a live NAV status indicator and a "View NAV Response" dialog directly on the Sales Invoice form, and a Role Profile keeps credentials and the manual re-submit action away from ordinary invoice clerks. The same posting produces both the machine payload for NAV and the human-readable PDF your customer receives, from one Print Format, so the two can never drift. Every request and response is retained with timestamp and submitting user for the statutory retention period, filterable in a list view and exportable for audit.

This is build-to-order. You are not downloading a marketplace app and hoping it fits — we build it against your Frappe/ERPNext version (v15 or v16), your chart of accounts, your tax templates, your naming series and your actual invoice mix. Scoping starts with a short call where we look at real invoices: domestic B2B, B2C, EU intra-Community, non-HUF, credit notes, and anything downstream of a POS or subscription flow. Typical delivery is one working week from confirmed scope. We build on a staging bench, run UAT against NAV's test service with your own data so you see a real transactionId come back before anything touches production, then install on your production bench with a documented rollback. You receive the source in a git repository you own, so nothing here is a lock-in.