The tax runs in the opposite direction on this transaction
A Dynamics 365 Business Central configuration built for service tax usually assumes the task is helping an organisation account for the tax it charges on what it sells. Service tax on imported taxable services runs the other way. Where a person in Malaysia acquires a taxable service from a person outside Malaysia — an overseas software subscription, a cross-border consulting engagement, a foreign-hosted digital tool — the Royal Malaysian Customs Department's (RMCD) own published guidance, available through the MySST specific guides portal, confirms that the Malaysian recipient, not the overseas supplier, is the party required to self-assess and account for the tax. This has applied since 1 January 2019, regardless of whether the recipient is itself registered for service tax. These are general statements of the mechanism, not a determination of any organisation's registration status or liability; check RMCD's current guidance directly, and obtain tax advice where the position is unclear.
The practical effect for a Business Central workflow is that the transaction that matters is a purchase, not a sale — and the tax obligation attaches to acquiring the service, not to invoicing for one. A configuration built only around output tax on sales has nothing in it that would catch this liability at all.
Two forms, and two different clocks
RMCD's guidance draws a clear line between two populations. A person already registered for service tax accounts for tax on an imported service inside the same periodic SST-02 return used for its ordinary service tax obligations, following its own assigned taxable period. A person who is not a registered taxable person accounts for it separately, through the SST-02A declaration, due no later than the last day of the month following the month in which payment was made to the overseas supplier or the invoice was received — whichever of those two events RMCD treats as the trigger, discussed below. That is a different filing rhythm from the SST-02 return's own taxable period, and a workflow that assumes one filing pattern covers every case will miss it for whichever population it did not design for.
A registered recipient should also check whether the overseas supplier is itself a registered foreign service provider already charging service tax on the invoice, which can remove the self-assessment obligation for that supply; confirm the current position against RMCD before assuming either treatment applies.
Which route applies is a fact about the acquiring organisation's own registration status, not a technical setting. A workflow has to know, for each entity using it, whether it files SST-02A as a non-registered person or reports the same liability inside its existing SST-02 return — and has to be reviewed again if that registration status changes.
The trigger is cash-adjacent, and Business Central's default is not
RMCD's guidance states that service tax on an imported taxable service becomes due at the earlier of two events: when payment is made to the overseas supplier, or when the invoice for the service is received — whichever happens first. Neither event is the transaction's posting date, and neither is necessarily the same date a Business Central purchase document would use by default.
Business Central's own VAT and tax reporting mechanism is generally built around the Posting Date of a document, not around a separate payment-or-invoice trigger. A purchase invoice for an overseas subscription might be posted on the date it is entered, paid weeks later, and the invoice itself received before either of those dates — three dates, only one of which RMCD actually cares about, and none of which Business Central will automatically identify as "the earlier of payment or invoice" without deliberate configuration.
The native mechanism a configuration can build on — and its limits
Business Central does not have a purpose-built "Malaysian reverse charge" feature; Microsoft's own local functionality documentation lists Microsoft-led compliance functionality for a defined set of countries, and Malaysia is not among them. What exists instead is a set of generic VAT mechanics that a partner configuration has to adapt deliberately.
Microsoft's documentation on setting up value-added tax describes a Reverse Charge VAT calculation type available within the VAT Posting Setup matrix, alongside Normal VAT and Full VAT. Microsoft documents this specifically for trade between EU countries or regions, where the purchaser rather than the seller calculates and settles the tax; the calculation type itself is a general posting-setup option, not an EU-only mechanism, but Microsoft's own worked example does not extend it to Malaysia, and applying it to a Malaysian imported-services scenario is a configuration decision SCSB and its clients make deliberately, not a feature Microsoft ships pre-configured for this purpose.
The same documentation describes two further mechanics that matter here. Unrealized VAT lets Business Central post a tax amount to a temporary account when a purchase invoice is posted, and move it to the final account only once the actual payment is posted — a genuinely cash-based recognition, and the closest native match to a trigger built around payment. Separately, the VAT Date field lets a document's VAT reporting date differ from its Posting Date, which means a workflow can set the reporting date to whichever date the RMCD rule actually points to, independent of when the purchase itself was recorded in the ledger.
None of these three features was built with Malaysia's earlier-of-payment-or-invoice rule specifically in mind, and none of them decides, on its own, which of the two dates applies to a given transaction. Combining a Reverse Charge VAT posting setup, Unrealized VAT recognition, and a deliberately set VAT Date can approximate RMCD's rule — but only if someone designs the combination for that purpose and tests it against real transactions, rather than assuming the three features interact correctly by default.
The decision that stays with a person, not the software
Whatever combination of settings a configuration uses, someone still has to decide, for each qualifying purchase, whether the invoice was received before payment or after — and set the VAT Date accordingly, so the amount lands in the correct filing period under whichever form applies. A default that quietly uses the purchase's Posting Date for everything has ignored RMCD's own timing rule, even if the VAT amount itself is calculated correctly.
The other risk sits earlier than the date: a purchase from an overseas vendor that was never flagged for reverse-charge treatment in the first place — because the vendor card was set up like any other vendor, without the VAT business posting group that would trigger the calculation — simply never generates the liability at all, and nobody notices until an audit asks for it. A workflow that reconciles the population of purchases from vendors classified as overseas against the population actually captured for reverse charge is the check that catches this gap before RMCD does; a report that only totals what was already flagged correctly cannot, by definition, find what was never flagged.
Decisions to settle before configuration starts
- Whether the acquiring entity is itself registered for service tax, which determines whether the liability is declared through SST-02A or folded into the existing SST-02 return.
- Which VAT business and product posting group combination triggers Reverse Charge VAT calculation for overseas vendors, and how new overseas vendor records are prevented from being set up without it.
- Whether Unrealized VAT and the VAT Date field are both enabled, and how they are expected to interact for this specific posting group combination.
- Who decides, transaction by transaction, whether payment or invoice receipt came first, and how that decision is recorded rather than left to whichever date the system defaulted to.
- What standing extraction reconciles self-assessed import tax against the full population of overseas vendor purchases, so a purchase that was never flagged is still visible to a reviewer.
When this can be managed directly, and when it usually can't
An organisation with occasional, low-value overseas purchases and a small, stable vendor list may track this liability directly from RMCD's own published guidance, without a dedicated Business Central configuration — a manual review of overseas invoices each period may be entirely proportionate at that scale. The case for configuring the mechanism inside Business Central grows with recurring overseas subscriptions, multiple currencies, a vendor base that changes frequently, or transaction volumes high enough that a manual check is no longer a reliable control.
What to do next
Confirm the current registration position, filing route and applicable rate directly against RMCD's current MySST guidance before relying on this article for anything beyond the mechanics of workflow design. Where the requirement is to configure this reverse-charge tracking inside Dynamics 365 Business Central, the SAC SST App can be discussed within an agreed implementation scope.
General-information limitation
This article is general technical information about SST-02A and reverse-charge workflow design concepts in Dynamics 365 Business Central. It is not tax, legal or accounting advice, does not determine any organisation's registration status, filing obligations or tax treatment, and does not confirm that a particular configuration satisfies RMCD's current requirements. RMCD's guidance and Business Central's own functionality are set by their respective publishers and change over time. Confirm the current position against RMCD's published material before implementation.
Dynamics 365 Business Central and Microsoft are trademarks of the Microsoft group of companies.