Every business registered for VAT in Hungary is legally required to report the data of each issued invoice to NAV (Nemzeti Ado- es Vamhivatal) through the Online Szamla system, in real time, in a strictly-defined XML schema. Odoo core gives you account, base_vat and the l10n_hu chart of accounts, but it has no native bridge to the NAV Online Szamla 3.0 manageInvoice API — no request signing, no invoiceData XML generation, no transaction status polling, no storno handling. Teams end up exporting invoices and re-keying them into NAV's web portal by hand, which does not scale, breaks the real-time obligation, and leaves no audit trail inside the ERP. That is exactly the gap this build-to-order integration closes.

We build a dedicated Odoo module that hooks into the invoice validation flow. When an account.move of type out_invoice or out_refund is posted, the module generates the NAV-compliant invoiceData XML from the Odoo invoice, base64-encodes it, wraps it in a manageInvoice request, and submits it to the NAV endpoint. Authentication uses your NAV technical user: the module computes the SHA3-512 request signature and requestId, negotiates the exchange token via tokenExchange, and manages token lifetime automatically. Every submission returns a transactionId, which the module then polls via queryTransactionStatus — surfacing NAV's PROCESSED, ABORTED, error and warning results directly on the invoice through a status field and threaded chatter message, so your finance team never has to log into the NAV portal to find out whether a submission cleared.

Technically, the build is grounded in standard Odoo patterns. New fields on account.move (NAV transaction id, index, reporting status, timestamp, raw response) are declared as models.Model fields with compute/@api.depends where derivation is needed; the XML is produced from a QWeb template mapped to the NAV 3.0 schema; submission and polling run as account.move methods invoked from validation and from a scheduled ir.cron retry action. Access is locked down with ir.model.access.csv plus record rules so only accounting users see NAV controls, and a settings screen (in res.config.settings) holds the technical-user credentials, signing key and the NAV test-vs-production environment switch. We handle the harder real-world cases too: modification and storno (cancellation) invoices with the correct modifyWithoutMaster / reference chaining, HUF and foreign-currency invoices with exchangeRate, group-VAT member and self-billing scenarios, and the product classification code fields (VTSZ / KN / CsK / SZJ) on invoice lines. Automatic submit-on-validation is the default, with a manual resubmit button for the cases NAV bounces. Everything works over Odoo's own ORM and can be driven externally through the XML-RPC / JSON-RPC API, and is built and tested against Odoo 17.0, 18.0 and 19.0 (Community and Enterprise).

Because this is a made-to-order engagement, delivery starts with a short scoping call rather than an instant download. We confirm your Odoo version and edition, your NAV technical-user setup, the invoice types and currency scenarios in scope, and any existing localization on your database, then agree a fixed quote and timeline. Typical delivery is one working week from confirmed scope, and you receive installable source code, a UAT pass on a staging copy against the NAV test environment, and a defined post-go-live support window. Pricing starts from $999 (indicative, single-company base scope); multi-company reporting, additional currency or self-billing scenarios, and deeper localization or data-migration depth increase the quoted scope.