Thailand's e-Tax Invoice & Receipt regime does not accept a PDF that merely looks like a tax invoice. The document must carry a digital signature backed by a certificate from an ETDA-recognised authority, must exist in a defined XML structure alongside the human-readable copy the buyer actually reads, must carry the seller's and buyer's 13-digit Tax IDs and branch codes exactly as registered, and must be retained in a form an auditor can reopen years later with the signature still verifiable. Dynamics 365 Business Central ships strong VAT posting, posting groups, and document numbering — but out of the box it has no concept of a Thai e-Tax payload, no signing pipeline, no submission channel, and no way to record that a specific posted document was accepted, rejected, or later cancelled. Teams close the gap with a spreadsheet, a service-bureau portal, and a person who re-keys invoice lines twice a day. That person is the compliance control, and they are also the single point of failure.

We build a per-tenant AL extension (or an AppSource-targeted app where you prefer that packaging) that makes e-Tax issuance a consequence of posting rather than a separate chore. Table and page extensions on Sales Invoice Header, Sales Cr.Memo Header, and your receipt documents add the fields the regime cares about: e-Tax status, authority reference, signing timestamp, certificate serial, rejection reason, and correction linkage. A dedicated E-Tax Document table holds one row per issued document with its full lifecycle. Codeunits do the real work: one composes the XML from Business Central master data (customer Tax Registration No., branch code, VAT Business and Product Posting Groups, unit of measure, line amounts, VAT amount, withholding where it applies), one handles signing against your certificate — HSM, PKCS#12 store, or your signing provider's API — and one handles transport to your ETDA-accredited service provider or the channel your tax advisor has approved. An event subscriber on OnAfterPostSalesDoc queues the document instead of blocking the posting routine, so a network outage at the provider never stops your users from invoicing.

The rest of the design is about what happens when things go wrong, because that is where most e-invoicing projects fail. Submission runs through a Job Queue Entry, so retries, back-off, and error visibility are native Business Central behaviour your administrator already knows how to read. A rejection lands back on the document as a status and a readable reason, with an action that walks the user through the correct remedy — a credit memo and re-issue, or a corrected document referencing the original — rather than letting someone quietly patch the XML by hand. The signed payload and the buyer-facing PDF are both retained, linked to the posted document, and exposed through API pages (REST API v2.0 / OData v4) so Power Platform flows, a Dataverse-connected portal, or your archive of record can pull them without touching the database. Permission sets keep issue, re-issue, and cancel as separate rights, which is what your auditor asks about first.

Everything is built for current Business Central release waves and works on SaaS as well as on-premises, with the signing component chosen to match: a SaaS tenant calls an external signing service, an on-premises deployment can use a local certificate store or HSM directly. Document composition, status lifecycle, job queue behaviour, API surface, and archiving are identical either way, so a group running both deployment models gets one pattern rather than two.

This is build-to-order, not an AppSource download. After a scoping call we confirm your Business Central version and deployment model, your accredited service provider or signing arrangement, which document types are in scope (tax invoice, receipt, tax invoice/receipt, credit note, debit note, abbreviated tax invoice), how your customer master carries Tax IDs and branch codes today, and what your retention obligation looks like. We then build the extension against your setup, deliver it to a sandbox for UAT with your finance team and tax advisor, and go live with a rollback plan in hand. Typical delivery is two to four weeks from confirmed scope. You receive the full AL source for your Business Central version and the git repository — the compliance logic sitting between your ledger and the Revenue Department is not something you should have to rent back from a vendor.