SSMxT Tagging Errors: Why MBRS Filings Fail Validation

The failure that costs money is not the one that stops the file generating. It is the one that generates cleanly, lodges cleanly, and carries a number that is wrong by a factor of a thousand.

SSMxT validation is good at arithmetic and blind to meaning. It will refuse a statement of changes in equity that does not foot. It will happily accept total assets of RM53,928 for a company with RM53.9 million on its balance sheet, because 53,928 is a perfectly valid number.

That asymmetry is how you should read every error family below: the ones the tool catches are inconvenient, and the ones it does not are the ones to review for.

The two errors validation cannot see

Scale

SSMxT handles rounding through the XBRL decimals attribute, not by rounding the value. SSM’s own worked example: a company whose accounts are stated in thousands and whose assets read 53,928 tags the fact as 53928000 with decimals set to -3.

A preparer who copies the printed figure straight off the face of the accounts tags 53928. No rule fires. The instance is valid XBRL. The lodged accounts show a company one-thousandth of its actual size — machine-readable, permanent, and visible to anyone who pulls the data.

Every filing prepared from a set of accounts presented in thousands or millions needs a scale check as a discrete review step, separate from validation.

Element selection

The taxonomy carries thousands of concepts, several of which will plausibly fit any given balance. Nothing in mTool tells you that you picked the plausible one rather than the right one.

Two consequences follow. First, the tagged accounts stop matching what a reader of the PDF would understand. Second — and this is the one that bites in year two — the mapping decision is a precedent. Tag the same balance differently next year and your comparatives diverge in the data even though the printed accounts are consistent.

Record the mapping. Not the file, the mapping: account, concept, and the reason where the choice was a judgement call.

The five families of validation failure

SSM builds the rules into the taxonomy’s formula linkbase, using existence assertions and value assertions, modelled so that true means the rule passed.

Mandatory elements. Concepts that must be present, one assertion per concept so that the failure message names the missing element. SSM’s documented example: “Assets” should be reported.

Derived mandatory elements. Required only under certain conditions, modelled with a precondition plus a value assertion. SSM’s example is exact and worth memorising: when the filer selects status of company as “Public company”, then disclosure of financial statements audit status should be “Audited”.

This is the family that produces the most bewildered support requests, because the error surfaces in the financial statements while its cause is a dropdown in the filing information block. Before arguing with a derived mandatory error, re-read the header.

Dimension aggregation. Members of an axis must sum to their parent where the preparer structured them in a summation-like hierarchy. SSM’s example: total equity equals non-controlling interest plus other equity components plus equity attributable to owners of the parent.

Positive and negative values. Here the intuition most preparers bring is wrong. The architecture document is explicit that there are no elements which should always be stored as a negative value, because negatively weighted items such as cost of sales are stored as positive numbers in most cases. What the formula linkbase actually carries is a list of elements that must always be positive — SSM’s example is that the total amount of indebtedness in MYR should be a positive value.

So the common sign error in an SSMxT filing is not a missing minus sign. It is a preparer helpfully adding one.

Cross-statement and correlated data. The same fact appearing in more than one statement must agree, and logically related facts are checked against each other. A profit figure in the statement of profit or loss that disagrees with the opening-to-closing movement in the statement of changes in equity used to be invisible in a PDF. It now blocks the file.

Underneath all five sit the structural checks — XBRL, dimensional, formula, table, extensible enumeration and iXBRL validation — confirming the instance is well formed against SSMxT_2022v1.0 itself.

Block tagging versus detail tagging

Detail tagging gives a figure its own concept: individually machine-readable, individually validated, individually comparable across years. Block tagging captures a whole note as text against a single text-block concept.

The rule that decides which you use is not a preference. Company extensions to SSMxT_2022v1.0 are not allowed. Where the taxonomy carries a concept, you tag to it. Where the accounting standards require detail the taxonomy does not model — segment breakdowns being SSM’s own example of entity-specific detail — the instruction is to supply it by text-block tagging into an appropriate text block concept.

The failure mode is over-blocking: a preparer under deadline pressure blocks an entire note that the taxonomy models concept by concept. It generates, it lodges, and it hollows out the filing. Nothing in the data pipeline SSM built gets any use out of a note stored as a paragraph.

Where an instance is prepared in iXBRL, untagged human-readable content can sit in the document alongside the tagged facts. That reduces the pressure to force everything into a tag, but it does not license blocking what should be detailed.

Notes that do not map

Three situations recur.

A note the taxonomy has no concept for. Text block. This is the designed answer, not a workaround.

A note the taxonomy models under a different name. More common than preparers expect, because SSMxT inherits IFRS Taxonomy 2022 labels while Malaysian accounts often carry house terminology. Use the inbuilt SSMxT browser in mTool to search the concept, not the label you are used to.

A note that belongs to a presentation basis you did not choose. The taxonomy carries alternatives — current/non-current versus order of liquidity for the statement of financial position, function versus nature of expenses for profit or loss, direct versus indirect for cash flows. Concepts belonging to the basis you did not select are not available. Preparers read this as a missing element. It is a presentation choice made two steps earlier.

Currency, and the statutory rule behind it

Monetary facts must carry iso4217:MYR. Preparers of foreign-owned subsidiaries reporting to a group in another currency sometimes assume the presentation currency travels with the accounts. It does not.

This is not just a taxonomy constraint. Section 259(1)(c) of the Companies Act 2016 requires that all amounts shown in financial statements and reports lodged with the Registrar be quoted in Malaysian currency, and that documents in any language other than Bahasa Malaysia or English be accompanied by a certified translation.

Common mistakes

• Keying the printed figure from accounts stated in thousands instead of the full amount with decimals set to -3. Passes validation, misstates the accounts.
• Adding minus signs to expenses. SSMxT stores negatively weighted items as positive in most cases.
• Arguing with a derived mandatory error without checking the filing information header that triggered it.
• Blocking a note the taxonomy models in detail because the deadline is closer than the understanding.
• Searching the taxonomy for your own account name rather than the IFRS label, then concluding the concept does not exist.
• Changing presentation basis year to year, which silently breaks the comparatives in the data.
• Assuming a validation failure is a rejection. Validation is offline in mTool; rejection and query happen in mPortal after upload. Neither stops the statutory clock.
• Tagging a group’s presentation currency instead of Malaysian Ringgit.
• Treating the mapping as disposable. The instance document is disposable. The mapping is the asset.

What’s next

Build a two-column review step into your close: every tagged fact against the face of the accounts, checked for scale, and every judgement-call mapping recorded with its reason. Neither is a validation rule, which is exactly why neither will be caught for you.

If you are still choosing an entry point or working out the maker and lodger roles, start with the MBRS 2.0 preparation guide.