Finance teams invoicing in Vietnam carry a compliance burden Dynamics 365 Business Central was never localised for. Vietnamese e-invoicing requires each sales invoice to be transmitted to an authorised e-invoice service provider, to carry a provider-assigned invoice code (and, where the taxpayer is in scope, a tax-authority verification code), to exist in both a human-readable representation and a machine format, and to be retained with an auditable trail. Out of the box, Business Central posts a Sales Invoice Header, prints a report layout, and stops. Everything after that — provider credentials, serial and form patterns, VAT category mapping, transmission retries, rejection handling, adjustment and replacement invoices, archive retention — happens in a spreadsheet, a provider portal, or a second data-entry pass. That gap is where numbers drift: an invoice posted in Business Central and an invoice issued at the provider stop agreeing, and reconciliation at period close becomes manual detective work.

ECOSIRE builds a per-tenant AL extension (or an AppSource-packaged app where you prefer that route) that closes the loop inside Business Central. A setup table and page hold provider endpoint, credentials, invoice form and serial patterns, and environment (test vs production). Table extensions on Sales Invoice Header, Sales Cr.Memo Header and Customer carry the Vietnamese fields the standard tables have no home for — buyer tax code (MST), provider invoice code, provider transaction id, issue status, verification code and rejection reason. Codeunits do the work: a mapping codeunit resolves VAT posting setup and item/resource lines to the tax categories your provider expects, a transmission codeunit calls the provider REST API with typed request objects and handles the authentication and token lifecycle, and a status codeunit polls or receives the outcome. Event subscribers on the posting routines (OnAfterPostSalesDoc and friends) enqueue the document rather than blocking the user's post — transmission runs through a job queue entry, so a slow or unreachable provider never stops a warehouse from invoicing.

Output is generated once from the posted document. The machine format your provider requires is produced from Business Central data, and the human-readable representation is produced from the same source so the two can never diverge — the PDF the customer receives and the file the provider receives are two renderings of one posting, not two independent documents. Where the provider returns a signed or coded artefact, we store it against the document and expose it on the posted invoice page, so a controller can open the invoice in Business Central and see the provider's invoice code, transmission timestamp and current status without leaving the ERP.

Rejections are treated as a first-class workflow, not an error log. A rejected transmission lands in a queue page with the provider's reason code translated into plain language, the offending field highlighted where the provider identifies one, and a guided correction path: fix the master data or the document, then resubmit under the same or a replacement number according to your provider's rules. Adjustment and replacement invoices are modelled explicitly so the audit trail shows what was issued, what was superseded, and why. Everything — request, response, status transition, user, timestamp — is written to a log table that survives the document, and archive retention is configured to your policy. Permission sets ship with the extension so an AP clerk, a finance manager and a system administrator each see only what they should, and API pages (REST API v2.0 / OData v4) expose issue status for Power BI, Power Automate or a Dataverse-connected app when you want compliance reporting outside Business Central. We build for current release waves on both SaaS and on-premises.

This is build-to-order: it does not exist as a download today. We start with a scoping call, confirm your e-invoice service provider and their API contract, your form and serial patterns, your VAT setup and your correction policy, then write a fixed scope. Typical delivery is 2–4 weeks from confirmed scope, depending on provider API complexity and how much of your master data needs tax-code remediation first. You get the AL source built against your Business Central version, deployment to a sandbox for UAT, a documented rollback, then production installation, training and a post-go-live support window.