Hungary NAV Online Invoice (RTIR)

Key Features

Real-time RTIR submission triggered by event subscribers on the sales and service posting codeunits, so reporting fires from the same action that posts the invoice

NAV Online Invoice REST integration covering the full handshake: `tokenExchange`, `manageInvoice` and `queryTransactionStatus`, with request signing and the exchange-key decryption handled in AL

Asynchronous response polling as a dedicated `Job Queue Entry`, so a slow or unavailable NAV endpoint never blocks or rolls back a posting

Tax mapping tables that resolve VAT Business Posting Group, VAT Product Posting Group and VAT Posting Setup combinations to NAV tax codes and RTIR line categories, seeded from your live company data during scoping

VAT scenario coverage for domestic standard rate, reverse charge, intra-community supply, exempt supply and margin schemes, each with its explicit RTIR representation

NAV Submission Log page listing every submission with transaction ID, timestamp, operator, status and the full NAV validation text on rejection

Posted Sales Invoice FactBox showing NAV status inline, so finance never has to leave the document to know whether it reported

Correction workflow producing chained MODIFY and STORNO submissions that reference the original NAV transaction ID, rather than orphaned resubmissions

One posting produces both the machine RTIR payload and the human-readable document layout, removing the second manual export step

Full request and response XML archived per document with retention settings, giving an auditable evidence trail years after the transaction

API pages exposed over REST API v2.0 / OData v4 so submission status and failure counts can be read by Power BI, Power Automate or a Dataverse flow

Separate permission sets for connection configuration and day-to-day operation, keeping NAV signing keys away from AP/AR users

Per-company configuration so a multi-entity tenant keeps distinct NAV technical users, submission logs and archives

Delivered as an AL extension with table and page extensions only — no base application modification — targeting your exact Business Central release wave on SaaS or on-premises

Built to order, done for you

No DIY setup — a working app, built, installed and supported by ECOSIRE.

You order

Start with a one-time build price. We scope it with you at kickoff.

We build & install

ECOSIRE builds, configures and installs it on your Dynamics 365 Business Central.

Go live + support

You go live in about 2–4 weeks, with a post-launch support window.

What you get

Complete AL extension source, compiled and tested against the exact Business Central release wave and localisation you run

Installation and configuration on your sandbox and production environments, including permission sets, NAV technical user credentials setup and job queue entries

Technical documentation: object ID ranges, event subscriber map, RTIR field-to-Business-Central mapping matrix, and API endpoint configuration

End-user guide plus a live training session for finance and AP/AR staff covering submission monitoring, rejection triage and correction workflow

UAT run on a staging environment with your own invoice samples against the NAV test environment, plus a documented rollback plan

Post-go-live support window with a named engineer for defect fixes and NAV response troubleshooting

Git repository handover with full commit history, branch strategy and app.json versioning, so any partner can maintain it

Handover session covering upgrade path, release wave regression checklist and how to extend the mapping tables yourself

Who this is for

Hungarian Finance Manager or Chief Accountant

Legally accountable for NAV Online Invoice compliance and wants reporting to happen at the moment of posting rather than as a monthly reconciliation. Needs visible proof that every invoice reported, a clear queue of anything NAV rejected, and an archive that stands up in a tax review. Buys because the current export-and-upload routine has no failure detection.

Group ERP Manager rolling Business Central into a Hungarian entity

Runs a Business Central template across several countries and has just hit Hungary, where the base application offers nothing for RTIR. Needs an extension that fits the group's existing posting flow and ISV layers, upgrades cleanly through release waves, and can be maintained by the group's own partner. Buys the source code as much as the functionality.

Business Central Partner or Implementation Consultant

Delivering a Hungarian go-live on a fixed date and needs the RTIR piece to be somebody else's build risk. Wants an AL extension delivered against a specific release wave with documented event subscribers, object ID ranges and a mapping matrix, so it can be reviewed and merged into the delivery without reverse-engineering. Buys certainty and documentation.

IT Operations or Application Owner

Owns the tenant, the job queue and the credentials. Cares about where the NAV signing keys live, which permission set can read them, whether a failed submission raises an alert, and how the extension behaves when the NAV endpoint is unavailable. Buys once the security model and failure behaviour are documented rather than assumed.

How Hungary NAV Online Invoice (RTIR) Compares

Criterion	ECOSIRE	Custom Build	Competitor	Dynamics 365 Business Central Native
NAV RTIR real-time reporting	Purpose-built AL codeunit posts the RTIR XML to NAV's Online Invoice API within seconds of posting, with token exchange and response polling handled in a job queue.	Achievable, but your team owns the whole RTIR schema, the AES/SHA request signing and every NAV version bump.	Usually present, but bound to the vendor's assumptions about your invoice flow and release cadence.	No Hungarian RTIR submission exists in Business Central out of the box.
Tax mapping to NAV codes	Mapping tables keyed on your VAT Posting Setup, VAT Business/Product Posting Groups and item data, seeded from your live company during scoping.	Built from scratch; the mapping design usually costs more effort than the API call itself.	Fixed mapping table you populate manually and re-check after every catalogue change.	Standard VAT posting setup only, with no NAV code dimension attached.
Rejection and correction handling	ERROR/WARN responses land on a dedicated NAV Submission Log page with the NAV validation text, retry, and a modification/storno correction chain.	Frequently deferred to phase two, so finance chases failures by email until it is built.	Typically a status flag plus a raw response blob; correction chains often need manual intervention.	Nothing to reject, since nothing is submitted.
Fit to your posting flow	Event subscribers hook your actual posting routines, including sales, service, projects and any ISV layers you already run.	Fits exactly, provided the developer knows both RTIR and your customisation layer.	Fits the vendor's reference flow; deviations need a change request or a workaround.	Not applicable.
Source code and ownership	Full AL source in a git repository handed to you, so any partner can maintain or extend it later.	You own it entirely, along with all future maintenance.	Encrypted AppSource app; you never see the code and cannot change behaviour.	Microsoft base application only.
SaaS and on-premises coverage	Packaged as an AppSource-ready or per-tenant extension, targeting the release wave you actually run, on SaaS or on-prem.	Depends entirely on how the developer scoped the target platform.	Usually SaaS-first; on-premises support varies by vendor.	Both platforms, neither with RTIR.
Archiving and audit trail	Request and response XML stored per invoice with transaction ID, timestamp and operator, retained for statutory review.	Needs a deliberate design decision; often reduced to log entries that get cleaned up.	Retention rules set by the vendor, sometimes in vendor-hosted storage.	Posted document records with no NAV exchange evidence.
Commercial model	One build-to-order fee for your version, plus an agreed post-go-live support window; no per-invoice metering.	Day-rate development with an open-ended maintenance line.	Recurring per-tenant or per-invoice subscription for as long as you invoice in Hungary.	Included, but does not solve the requirement.

Frequently Asked Questions about Hungary NAV Online Invoice (RTIR)

How long does delivery take, and can I download it today?

No — this is build-to-order, not an existing AppSource download. Typical delivery is two to four weeks from confirmed scope. The clock starts once we have agreed the document types in scope, your Business Central version and localisation, and you have provisioned the NAV technical user. Simple scopes on a clean localised install land at the shorter end; multi-company setups, heavy ISV layers or unusual document flows sit at the longer end. We tell you which you are during the scoping call rather than after.

What do you need from us before you can start building?

A NAV Online Invoice technical user with the exchange key and signing key (created in your own NAV account — we never register it on your behalf), access to a Business Central sandbox that mirrors production, your exact release wave and localisation version, a list of document types that must be reported, and a set of representative invoices covering your VAT scenarios: domestic standard rate, reverse charge, intra-community supply, exempt, and any margin-scheme cases you use.

How is support and updating handled after go-live?

Every build includes an agreed post-go-live support window with a named engineer, covering defect fixes and help interpreting NAV responses in production. Beyond that window we offer an optional maintenance agreement covering NAV schema changes and Business Central release wave regression testing — Microsoft ships two major waves a year and NAV revises the RTIR schema periodically, so a compatibility check twice a year is the sensible cadence. Because you hold the full AL source in your own git repository, you are never locked into us: any competent Business Central partner can maintain or extend it.

Will this survive a Business Central upgrade?

It is built as an AL extension using table extensions, page extensions and event subscribers, with no base application modification, so it upgrades the way any well-built extension does. What we cannot promise is that Microsoft never deprecates an event or that NAV never revises the RTIR schema. That is exactly what the maintenance agreement covers: we regression-test the extension against each release wave and against schema changes NAV publishes.

Does it work on Business Central on-premises as well as SaaS?

Yes. We target the platform you actually run and package accordingly — an AppSource-shaped app or a per-tenant extension for SaaS, or a deployable app for on-premises. On-premises deployments need outbound HTTPS to the NAV endpoints and, if you run the job queue under a service account, that account needs the relevant permission set. We confirm this in scoping so there are no surprises at install.

What happens when NAV rejects one of our invoices?

The submission is recorded as rejected with NAV's own validation messages against the posted invoice, and the responsible user sees it on the NAV Submission Log rather than discovering it in a monthly reconciliation. From there you can correct the underlying data and resubmit, or issue a modification or storno document that is submitted as a chained correction referencing the original NAV transaction ID. Optional alerting on the API page lets you push failures to email or a Power Automate flow.

Can you handle multiple legal entities or companies in one tenant?

Yes, and it is a common scope. Each Business Central company gets its own NAV technical user configuration and its own submission log, so credentials are never shared across entities and each company's archive stands on its own for audit. Tell us the company count during scoping — it affects configuration and UAT effort, and therefore the quotation.