No — this is build-to-order, not an existing AppSource download. Typical delivery is one working week 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.

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.

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.

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.

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.

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.

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.