The obligation drives the workflow, not the other way round
For a person registered under the Sales Tax Act 2018 or Service Tax Act 2018, the SST-02 return starts with the registration and the underlying transactions — not with whatever a report happens to produce. The Royal Malaysian Customs Department's (RMCD) own published guidance, available through the MySST portal, states that the taxable period is generally two months, that Form SST-02 must be submitted by the last day of the month following the end of that period, and that a return is required even where no tax is payable for the period. Those are general statements of the filing mechanism, not a determination of any organisation's registration status or tax position; check the current RMCD material directly, and obtain tax advice where the position is unclear.
The practical consequence for a Dynamics 365 Business Central configuration is that the workflow has to be built around that filing rhythm — a defined period, a hard submission deadline, and a mandatory return regardless of outcome — rather than around a convenient reporting date that happens to be easy to run.
The mechanism Business Central actually taxes on
Business Central's base application calculates consumption tax through a combination of posting groups rather than a single "SST rate" field. Microsoft's own documentation on setting up value-added tax describes the mechanism most non-US Business Central configurations, including partner-built Malaysian localisations, are built on: a VAT Business Posting Group assigned to each customer and vendor, a VAT Product Posting Group assigned to each item, resource or general ledger account, and a VAT Posting Setup matrix that combines the two to determine the applicable rate, the calculation type, and the general ledger accounts used for posting. Tax is calculated only for the combination that actually exists in that matrix — an unmapped combination does not default to a sensible rate, it simply fails to calculate one at all, or calculates the wrong one silently if a fallback combination happens to exist.
This matters for SST specifically because Sales Tax and Service Tax are not the same tax, do not necessarily apply to the same transactions, and may need to be distinguished within the posting group structure rather than treated as a single generic rate. Microsoft's documentation also describes a VAT Identifier used to group posting setups that share a rate for reporting purposes, and VAT Clauses that print an exemption explanation on a document where a reduced or zero rate applies — both directly relevant to a Malaysian configuration that needs to show, on the face of a document, why a transaction was or was not taxed.
Assigning posting groups is a data-governance decision, not a one-time setup step
Microsoft's documentation is explicit that the VAT business or product posting group is assigned when a business or product posting group is chosen for a customer, vendor, item or resource — which means a new customer or a new item created without the correct posting group assigned will simply calculate tax incorrectly, silently, until someone notices. Business Central can propagate default posting groups from templates and from general business or product posting groups, which reduces how often a person has to remember the assignment manually, but it does not remove the need for someone to own the master data and periodically confirm new records were set up correctly.
Business Central also lets an organisation define the expected format for a registration number against a country or region — validating entries against a pattern such as digits and letters in a fixed sequence, and rejecting an entry that does not match. Applied to the SST registration number captured on the Company Information page and on customer and vendor records, this is a small but genuine control against a mistyped or incomplete registration number reaching a return, rather than being caught only when RMCD or a counterparty later queries it.
For an SST-02 preparation workflow, this is the single most consequential design decision, because every downstream reconciliation depends on transactions having been taxed correctly at the point of posting. A workflow that only checks tax treatment at return-preparation time is checking it far too late to fix cheaply. SCSB treats posting-group assignment as a standing data-governance responsibility with a named owner, rather than a one-time configuration task closed at go-live.
The reporting mechanism this typically runs through
Business Central's standard route from posting groups to a periodic return is the VAT Statement: a template built from rows that total either specific VAT entries — filtered by VAT Business and VAT Product Posting Group combinations — or specific general ledger accounts, previewed against a date filter for the period being reported. Microsoft's own guidance on setting up a VAT statement recommends structuring one section using VAT Entry Totaling and a second using Account Totaling, specifically so the two can be reconciled against each other, and points to a dedicated G/L – VAT Reconciliation report built for exactly that comparison.
For an SST-02 workflow, the practical value of this structure is that it is not a single number to trust or distrust — it is two independently derived totals, from two different tables, that should agree. A statement that only shows the final figure has quietly discarded the check that makes the figure defensible. Preserving both totals, and investigating rather than overriding any gap between them, is what turns a periodic report into evidence rather than an assertion.
Closing the period without losing what changed inside it
Business Central's VAT Return Period controls — which can block or warn on posting within a closed period, separately from the general posting-date controls — exist for exactly the situation an SST-02 preparation workflow needs: a defined cut-off, after which further changes to that period's data should be visible and controlled rather than silent. A late posting or a correction made after the period has notionally closed is not automatically wrong, but it does need to be caught and investigated, not absorbed unnoticed into next period's figures.
What a controlled extraction looks like
Once the period is closed, a defensible workflow produces a structured population of the transactions and adjustments that the SST-02 figure is built from — not just a total, but the underlying detail: document references, dates, counterparties, values, and the posting groups or treatment codes that determined how each line was taxed. That population is what a reviewer actually checks, and what supports the figure if the return is later queried.
Reconciling the population before anyone reviews a figure
The extracted population should reconcile to the relevant general ledger control accounts before anyone treats the return figure as final. Investigate variances rather than assume they will net out: a duplicate posting, a missing document, an unexpected posting group combination, a manual journal entered outside the normal sales or purchase process, and a reversal or credit memo posted in the wrong period are the differences that actually change a return figure, and each has a different cause that a simple total will not reveal.
Review and evidence: what a "software output" cannot provide
A correctly configured Business Central workflow produces a consistent, traceable population. It does not, by itself, constitute a review of the tax treatment applied to that population, and a report is not a substitute for someone with the appropriate responsibility assessing the classification against current RMCD guidance. The workflow's contribution is making that assessment efficient and evidenced — a clear preparer, a named reviewer, a record of what changed between preparation and submission, and retained supporting documents — not making the assessment itself.
Decisions to settle before configuration starts
- Which VAT business and product posting groups the organisation needs to distinguish Sales Tax from Service Tax treatment, and who owns keeping them assigned correctly on new records.
- How the VAT Return Period control is configured, so a closed period actually blocks or flags unexpected postings rather than silently accepting them.
- What the standing extraction looks like — the fields it carries, not just the total — so a reviewer can trace a figure back to source.
- Which control accounts the extracted population reconciles against, and who investigates a variance.
- Who reviews the tax treatment before submission, and what evidence of that review is retained.
A single-entity business with a narrow range of taxable supplies and clean posting-group assignment may manage this directly from RMCD's own published guidance and Business Central's standard VAT mechanism. The case for implementation support grows with multiple posting group combinations, mixed Sales Tax and Service Tax exposure, high transaction volumes, or master data that has never been reviewed against the posting groups it should carry.
What to do next
Confirm the current filing cycle, registration position and applicable treatment 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 reconciliation and review workflow 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-02 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.