An export can only show what was recorded
Organisations preparing for a Royal Malaysian Customs Department (RMCD) review often frame the problem as a file: something the accounting system should be able to produce on request, containing the transactions behind the returns. That framing puts the effort in the wrong place. Whatever an extract is called, it can only present what the underlying records already contain. If two different tax treatments were posted through one indistinguishable combination, no export written afterwards can separate them. If the attribute that explains a transaction was never captured when it was posted, no report can reconstruct it. The work that determines whether a Dynamics 365 Business Central configuration can answer an audit happens years before the request arrives, at the point transactions are recorded.
It is also worth being precise about terminology, because the term travels loosely. A prescribed audit file with a defined layout was a feature of the goods and services tax regime that ended in 2018. Under the Sales Tax Act 2018 and the Service Tax Act 2018, what binds is a statutory duty to keep records, together with RMCD's powers to examine them. Confirm what RMCD currently asks for through its own MySST guides rather than assuming a particular file format is required. The design implications below follow from the record-keeping duty itself, which is stable, rather than from any particular export.
What the Acts actually require
Section 24 of the Sales Tax Act 2018 requires every taxable person to keep complete and true records written up to date of all transactions which affect or may affect his liability to sales tax, including records of sales of taxable goods, records of importation and exportation, and all other records the Director General may determine. Section 24 of the Service Tax Act 2018 imposes a parallel duty in respect of service tax, extending to records of provision of taxable services and of imported taxable services.
Four conditions attach to those records in both Acts, and each one has a design consequence. They must be preserved for seven years from the latest date to which the record relates. They must be in the national language or English. They must be kept in Malaysia, except as otherwise approved by the Director General and subject to such conditions as he deems fit. And where a record is in an electronically readable form, it must be kept in such a manner as to enable the record to be readily accessible and convertible into writing. Both Acts add that where a record was originally in manual form and has been converted to electronic form, the record is to be retained in its original form prior to the conversion. These are general statements of the statutory duty, not a determination of any organisation's obligations or compliance position.
That last condition is the one worth sitting with. Readily accessible and convertible into writing is not satisfied by data existing somewhere in a database. It describes an outcome: that seven years later, someone can get at the record and produce it in readable form. A system that can do that today, and a system that can still do it after an upgrade, a re-implementation or a change of provider, are not the same system.
Granularity is decided at posting, not at extraction
Business Central determines tax treatment through combinations of posting groups rather than a single rate held on a document. The consequence for audit readiness is structural: the level of detail at which treatments can later be separated is fixed by how many distinguishable combinations exist. Where sales tax and service tax exposure, different service categories, exempt supplies and out-of-scope transactions all resolve to the same handful of combinations, a later extract can total them but cannot tell them apart, because the distinction was never recorded.
Designing for this means starting from the questions an examiner is likely to ask and working backwards to the combinations required to answer them, rather than starting from the smallest set of combinations that will produce a correct return total. Those two designs both produce a correct return. Only one of them can explain it afterwards.
Dimensions carry the questions a tax code cannot
Some of what an audit asks about is not a tax attribute at all: which branch, which service category as registered, which project, which contract a transaction belonged to. Business Central's dimensions exist for exactly this. Microsoft's documentation on working with dimensions describes two global dimensions available as filters across reports, batch jobs and ledger entry pages, and up to eight shortcut dimensions available as fields on journals, document lines and ledger entries.
Two native controls matter more than the reporting. Default dimensions can be set for accounts and account types, and where a dimension is required but no default value is appropriate, the Value Posting field can be set to Code Mandatory so that a posting cannot proceed without one. Separately, dimension combinations can be blocked or limited, so contradictory pairings are rejected at entry rather than discovered later. These turn a reporting convenience into a data control.
Microsoft also documents that an incorrect dimension used on posted general ledger entries can be corrected, and that global and shortcut dimensions can be changed — while warning that changing a global dimension requires every entry posted with it to be updated, that the process can be time-consuming, may affect performance and may lock tables. Correction is therefore possible but is a controlled remediation exercise, not a routine alternative to capturing the attribute correctly the first time. Choosing the dimension structure carefully at the outset is cheaper than changing it across seven years of entries.
Seven years is longer than most implementations plan for
A retention obligation measured in years collides with system housekeeping designed for tidiness. Business Central's retention policies let an administrator delete outdated data in tables containing log entries and archived records, on a schedule, through a job queue entry that by default runs daily. Microsoft notes that a minimum retention period is defined for some tables for compliance reasons, and that the allowed-table list is provided rather than open-ended.
The exposure is not that posted ledger entries vanish. It is that the surrounding evidence may. Change logs, archived documents and similar records can be the material that explains why a transaction was treated as it was, and a retention period chosen to keep a database lean can be shorter than the period the record duty contemplates. Any retention policy enabled on a Malaysian entity should be reviewed against the seven-year obligation before it runs, not after.
The same point applies to system change. Migrations between databases, environments or providers routinely carry balances and open items forward while leaving detailed history behind. If that history is part of the record, the migration plan has to say where it went, in what form, and how it will be produced and read years later.
What SCSB's configuration approach targets
SCSB treats audit readiness as three properties of the data rather than as a report specification: transactions distinguishable at the level the treatment was decided, attributes captured at posting through mandatory dimensions rather than inferred later, and records that remain retrievable and readable across the full retention period including through system change. An extract built on data with those properties is straightforward. An extract built on data without them is a presentation problem that cannot be solved by a better report.
Decisions to settle before configuration starts
- Which tax treatments the organisation must be able to distinguish afterwards, and whether the posting group structure actually separates them at the point of posting.
- Which attributes belong on dimensions, which of those are mandatory, and which dimension combinations should be blocked or limited.
- Which of the two global and eight shortcut dimension slots are committed to tax and regulatory attributes, given the cost of changing that choice later.
- Whether any retention policy in the environment is shorter than the seven-year record period, and who reviews it before it is enabled.
- How records will remain accessible and convertible into readable form through an upgrade, migration or change of provider, and where that is documented.
When this can be managed without outside help
An organisation with a single registration, one narrow category of taxable supplies and a clean, small chart of accounts may well satisfy the record duty with standard Business Central posting and ordinary document filing, reviewed periodically against RMCD's published guidance. Adding dimension structure it does not need would create work without adding control. The case for a deliberate design grows with multiple registrations or branches, with mixed sales tax and service tax exposure, with exempt or out-of-scope supplies sitting alongside taxable ones, with a history that already spans more than one system, or where an earlier configuration decision has already made two different treatments indistinguishable in the data.
What to do next
Confirm the current record-keeping requirements, and anything RMCD currently expects to be produced during a review, directly against RMCD's own published material; those requirements are set by RMCD, not by this article and not by an accounting system. Where the requirement is to design this posting, dimension and retention structure 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 data structure and record retention concepts in Dynamics 365 Business Central. It is not tax, legal or accounting advice, does not determine any organisation's registration status, record-keeping obligations or tax treatment, and does not confirm that a particular configuration satisfies RMCD's current requirements. The Sales Tax Act 2018, the Service Tax Act 2018, RMCD's guidance and Business Central's own functionality are set by their respective publishers and are revised over time. Confirm the current position against RMCD's published material and Microsoft's current Business Central documentation before implementation.
Dynamics 365 Business Central and Microsoft are trademarks of the Microsoft group of companies.