SSM Taxonomy Architecture Document Issued by: … XBRL...SSM Taxonomy Architecture Document Issued...
Transcript of SSM Taxonomy Architecture Document Issued by: … XBRL...SSM Taxonomy Architecture Document Issued...
SSM Taxonomy Architecture Document
Issued by:
The Companies Commission of Malaysia
May 2014
This SSM Taxonomy Architecture Document will support software developers in
the implementation of the SSMT within their applications as well as to generate
supported XBRL reports.
2
Index
1. Introduction ...................................................................................................................................... 3
1.1 The SSM Taxonomy 2013 ............................................................................................ 3
1.2 Nature and Scope .......................................................................................................... 3
2. SSM Taxonomy Architecture ........................................................................................................ 4
2.1. Scope of SSM Taxonomy Elements ........................................................................... 4
2.2. Taxonomy Architecture Principles.............................................................................. 5
2.3. Data modelling techniques in the SSM Taxonomy ................................................ 7
2.3.1. Hierarchical modelling ................................................................................................... 7
2.3.2 Axes modelling ................................................................................................................ 9
2.4. The structure of SSM Taxonomy .............................................................................. 12
2.5. Absolute and relative paths....................................................................................... 14
2.6. Namespaces and prefixes .......................................................................................... 15
2.7. Core, role and entry-point schemas ........................................................................ 16
2.8. Customised Data Types.............................................................................................. 19
2.9. Linkbases ...................................................................................................................... 20
2.9.1 Presentation linkbase ................................................................................................. 20
2.9.2 Definition linkbase........................................................................................................ 21
2.9.3 Calculation linkbase ..................................................................................................... 22
2.9.4 Label linkbase ............................................................................................................... 22
2.9.4.1 Reuse of IFRS labels .................................................................................................... 24
2.9.4.2 Total and net labels ..................................................................................................... 24
2.9.4.3 Negated labels .............................................................................................................. 25
2.9.5 Reference linkbases ..................................................................................................... 27
3. Style Guide .....................................................................................................................................28
3.1 General Guidance ........................................................................................................28
3.2 Style guide for Extended Link Roles (ELR) ............................................................28
3.3 Style Guide for element name and ID .................................................................... 29
3.4 Style Guide for Label Linkbase ................................................................................. 34
4. References ...................................................................................................................................... 42
3
1. Introduction
1.1 The SSM Taxonomy 2013
The purpose of this document is to define the architecture of the Suruhanjaya
Syarikat Malaysia Taxonomy (SSMT). SSMT is the XBRL representation of
financial reporting submission to SSM, based on Malaysian Financial Reporting
Standard (MFRS), Private Entity Reporting Standard (PERS) and the relevant
requirements under Companies Act1965 and the New Companies Bill.
This SSMT document will support software developers in the implementation of
the SSMT within their applications, as well as preparers in its use to generate
supported XBRL reports.
A certain degree of familiarity with the XBRL 2.1 Specification and related
Specifications such as XBRL Dimensions 1.0 as well as with XBRL terminology and
concepts is a pre-requisite to read and understand this document.
1.2 Nature and Scope
The first version of the SSMT is based on the 2012 version of the IFRS Taxonomy
(IFRS Taxonomy 2012) as issued by the IFRS Foundation. The IFRS Taxonomy
2012 can be found in the IFRS Foundation website at the following link:
http://www.ifrs.org/XBRL/IFRS-Taxonomy/IFRS-Taxonomy-2012/Pages/IFRS-
Taxonomy-2012-files.aspx.
Relevant reference documentation of the IFRS Taxonomy 2012 should be referred
to in conjunction with this document. In particular, the principles and rules from
the IFRS Taxonomy Guide should be considered adopted “as is” in the SSMT,
unless otherwise noted.
The IFRS Taxonomy 2012 is compliant with the provisions of the Global Filing
Manual (GFM), published by the Interoperable Taxonomy Architecture (ITA)
project, a joint initiative between the US Securities and Exchange Commission
(SEC), the Japan Financial Supervision Agency (FSA) and the International
Financial Reporting Standards (IFRS) Foundation XBRL team, with the
participation of the European Commission as an observer. The GFM should also be
referred to in conjunction with this document to the extent to which its provisions
are relevant. The current copy of the GFM at the time of publication of this
document can be found here:
http://www.ifrs.org/XBRL/Resources/Documents/GlobalFilingManual20110419.pdf
4
In addition to the reporting concepts defined in the IFRS Taxonomy 2012, which
are largely applicable in Malaysia following the adoption of the International
Financial Reporting Standards, the SSMT also includes local reporting concepts,
necessary to support Malaysian local requirements as well as additional
information not covered by the IFRS Taxonomy 2012 and necessary for SSM
consumption. In addition, SSMT architecture is ready to support additional future
reporting requirements, which will also generate the need to accommodate local
reporting concepts in the taxonomy.
One of the main objectives of this document is to define the SSMT architecture so
that it is compliant with the base IFRS Taxonomy architecture and in particular
with the best practices on its extension, and at the same time flexible enough to
accommodate the reporting concepts necessary to support the Malaysian
jurisdictional extension to the base IFRS taxonomy as well as future additional
reporting requirements. To achieve this goal the SSMT architecture is also
inspired by the experience and lessons learned from the Standard Business
Reporting (SBR) XBRL programs, in particular from the Australian SBR Taxonomy
Architecture, which includes a fully compliant IFRS jurisdictional extension and
also successfully supports heterogeneous reporting requirements from different
Government agencies – requirements that are very similar to those that the SSMT
will support.
More information about the SBR program in Australia and The Netherlands can be
found in the respective websites:
http://www.sbr.gov.au
http://www.sbr-nl.nl/english/
2. SSM Taxonomy Architecture
2.1. Scope of SSM Taxonomy Elements
Financial
Reporting Malaysian Financial Reporting Standards (MFRS)
Private Entity Reporting Standards (PERS)
Balance Sheet / Statement of Financial Position;
Income Statement / Statement of Comprehensive Income;
Statement of Changes in Equity;
Statement of Cash Flows; and
Notes to the financial statements.
5
Non-Financial
Reporting - as
required under
the Companies
Act 1965 / New
Companies Bill:
Directors‟ Report;
Statement by Directors;
Directors‟ Business Review (New Companies Bill);
Auditors Report to Members / Auditor‟s Statement;
and
The return of solvent Exempt Private Company.
Type of
companies and
industries will be
included/
excluded in the
first phase of
SSM’s XBRL
submission
Inclusion
Public Companies – Listed and Non-Listed
Private Companies
Exclusion
Banking, financial and insurance industry (Bank Negara taxonomy)
Companies which are limited by guarantee and
Foreign Companies.
2.2. Taxonomy Architecture Principles
The objectives of consistency with the overall IFRS 2012 Taxonomy architecture
and best practices for its extension to meet local requirements as well as of
flexibility and openness to future developments and expanded reporting
requirements are achieved in the SSMT Architecture through two (2) foundational
principles:
From a taxonomy structure perspective – in other words, in terms of physical
allocation and structure of the taxonomy folders and files: the base IFRS 2012
Taxonomy files and the Malaysian extension files are allocated consistently with
the characteristic SBR two-layer taxonomy architecture:
1. Definitional layer, where all the reporting concepts and other resources –
such as data types, common labels, common references - that may be re-
used by any report supported by the taxonomy are defined;
2. Reports layer, where the subset of resources defined in the definitional
layer that are used in each report supported by the taxonomy is identified
and the structure of each report is defined.
In practical terms this translates into distributing the various core files defined in
the IFRS base taxonomy and in the Malaysian extension in the appropriate folders
6
located in the definitional layer, and the various entry points that support specific
reports in the appropriate folders in the reports layer. This physical allocation of
the taxonomy files has minimal impact on the taxonomy from a technical
perspective, and it does not affect the compliance of the SSMT with the IFRS
Taxonomy Architecture principles and with best practices in extending the base
IFRS taxonomy; on the other end, it helps support processes related to the
taxonomy creation and maintenance that enhance its consistency with the overall
requirements of the SSMT.
From a taxonomy creation and maintenance processes perspective: any new
element created in the taxonomy – by SSM now, and potentially by other entities
that will join the taxonomy development in the future – must comply with the
principles set in this document and to notify SSMXBRL Unit for the purposes of
streamlining the taxonomy. These principles basically reflect the IFRS Taxonomy
Architecture rules as stated in Section 4, Extender‟s Guide in The IFRS Taxonomy
2012 Guide, which are adopted in their entirety, unless otherwise explicitly noted,
with two important additions:
1. Every new reporting concept and related resources - such as data types,
common labels and references - must be created in the definitional layer of
the taxonomy. No reporting concept can be created in the reports layer;
2. Before adding a new reporting concept, appropriate processes must be
followed to make sure that no existing reporting concept has the same or
similar meaning. If a match is found, no new reporting concept is created and
instead the existing concept is used for the purpose for which the creation of a
new concept was initially considered.
These two key principles ensure that the growth of the taxonomy both in scope
and over time is consistent both with the IFRS architecture – by re-using the
concepts and related resources from the base IFRS taxonomy, and following the
guidelines of the IFRS Taxonomy Guide for its extensions - and the SBR
environment, where harmonization must happen across different domains rather
than limited to the financial statements domain, and therefore requires a strong
governance in place to manage duplications in reporting concepts that are
semantically identical but are called in different ways by different participating
regulators. It also helps the process of harmonization of the information within
each regulator – for example, as SSM starts analyzing the Malaysian jurisdictional
requirements and the various reports in scope and adding new reporting concepts
to the base IFRS ones, this principle will help ensuring consistency and avoid
duplications.
7
2.3. Data modelling techniques in the SSM Taxonomy
The SSMT is designed to reflect the disclosure requirements for companies in
Malaysia which are required to submit their financial statements to SSM. Given
that MFRS is largely based on IFRS, SSMT has adopted the 3,771 IFRS Taxonomy
2012 elements as the basis of its core elements.
In addition to the reporting concepts defined in the IFRS Taxonomy 2012, which
are largely applicable in Malaysia following the adoption of the International
Financial Reporting Standards, the SSMT also includes local reporting concepts,
necessary to support Malaysian jurisdictional requirements as well as additional
information not covered by the IFRS Taxonomy 2012.
SSM data requirements for regulatory, compliance, data collection and statistical
purposes were identified and selected. Upon evaluation, the elements which are
not listed in IFRS were identified and duly incorporated as extensions for SSMT.
While deciding data modelling structures, the key factors under consideration are:
a) Disclosures which are deemed useful for SSM consumption are collected
using detailed information elements (detailed tagging). Companies may
use the element „Others‟ defined in faces of financial statements to group
the additional disclosures that they wish to disclose.
b) Notes to the financial statements that are deemed to be useful for SSM
consumption are collected using detailed tagging method. Notes „Others‟ is
created for companies to utilize if they wish to disclose additional
information that is not related to specific notes to the financial statement.
c) Despite the fact that IFRS XBRL taxonomy architecture allows for
extensibility, companies or filers MUST NOT create extensions in the
form of new elements or dimensional properties (except for the
dimension mentioned in paragraph 2.3.2; page 9 and paragraph
2.9.2; page 21) , to ensure better data comparability.
Reporting scope for the SSMT is covering at the moment all MFRS, PERS and
Companies Act requirements. The modelling approach is adopted from IFRS
Taxonomy architecture and is represented in two ways – via hierarchies and/or
via axes (dimensions).
2.3.1. Hierarchical modelling
The most common modelling technique used in the SSMT is hierarchical/list
modelling in the presentation, definition and calculation linkbases (or if there are
8
no calculation relationships between the concepts, then only the presentation and
definition linkbases are modelled).
An example of hierarchical modelling is shown in Table 1 (below) in the ELR
[110000] Statement of comprehensive income, by function of expense.
Hierarchical modelling is used for most statements and notes in the SSMT.
Extended link [110000] Statement of comprehensive income, by function of expense
Statement of comprehensive income [abstract]
Revenue
Cost of sales
Gross profit
Other income
Distribution costs
Administrative expenses
Other expense
Other gains (losses)
Profit (loss) from operating activities
Finance income
Finance costs
Share of profit (loss) of associates and joint ventures accounted for using
equity method
Gain (losses) on fair value of financial assets
Profit (loss) before tax
Tax expense (income), continuing operations
Contribution of zakat
Profit (loss) from continuing operations
Profit (loss) from discontinued operations
Profit (loss)
Other comprehensive income [abstract]
Gains (losses) on revaluation
Income tax on gains (losses) on revaluation
Actual gains (losses) on defined benefit plans
Income tax on gains (losses) on defined benefit plans
Gain (losses) on share of other comprehensive income of associates and joint ventures
Income tax on share of other comprehensive income of associates and joint ventures
Exchange differences on translation [abstract]
Gains (losses) on exchange differences on translation, before tax
Reclassification adjustments on exchange differences on translation, before
tax
Income tax on exchange differences on translation
Available-for-sale financial assets [abstract]
Gains (losses) on remeasuring available-for-sale financial assets, before tax
9
Extended link [110000] Statement of comprehensive income, by function
of expense
Reclassification adjustments on available-for-sale financial assets, before tax
Income tax on available-for-sale financial assets
Cash flow hedges [abstract]
Gains (losses) on cash flow hedges, before tax
Reclassification adjustments on cash flow hedges, before tax
Adjustments for amounts transferred to initial carrying amount of hedged items
Income tax on cash flow hedges
Other comprehensive income, others
Income tax on other comprehensive income, others
Total other comprehensive income
Income tax on total other comprehensive income
Total comprehensive income
Profit (loss), attributable to [abstract]
Profit (loss), attributable to owners of parent
Profit (loss), attributable to non-controlling interests
Comprehensive income attributable to [abstract]
Owners of parent
Non-controlling interests
Basic earnings per share [abstract]
Basic earnings (loss) per share from continuing operations
Basic earnings (loss) per share from discontinued operations
Total basic earnings (loss) per share
Diluted earnings per share [abstract]
Diluted earnings (loss) per share from continuing operations
Diluted earnings (loss) per share from discontinued operations
Total diluted earnings (loss) per share
Table 1: A hierarchical model of a statement
2.3.2 Axes modelling
The second modelling technique used in the SSMT is modelling via tables
(hypercubes) and axes (explicit dimensions). Each such axis can be connected to
any set of line items (reportable concepts) via a table, thereby creating a
dimensional structure.
The SSMT contains two types of axes – applied axes, and for application axes.
Most axes in the SSMT are applied axes because they have relationships to line
items (reportable concepts). Only one axis in the SSMT is for application because
it does not have any explicit relationships.
Table 2 provides an example model of the Statement of changes in equity
[abstract] by the means of axes. Line items (reportable concepts) are denoted
10
with an X. Line items can be reported for various members (domain members) of
the axis Components of equity [axis], which are linked by the table Statement of
changes in equity [table]. For example, preparers can report the line item
Issuance of shares, for the member Share capital [member], on the axis
Components of equity [axis].
Extended link [310000] Statement of changes in equity
Statement of changes in equity [abstract]
Statement of changes in equity [table] table MFRS101.106
Components of equity [axis] axis MFRS101.106
Equity [member] member [default] MFRS101.106
Equity attributable to owners of
parent [member] member MFRS101.106
Issued capital [member] member MFRS101.106
Treasury shares [member] member MFRS101.106
Retained earnings [member] member MFRS101.106
Other reserves [member] member MFRS101.106
Non-controlling interests [member] member MFRS101.106
Statement of changes in equity [line items] line items MFRS101.106
Equity at beginning of period X MFRS101.106
Changes in equity [abstract]
Profit (loss) X MFRS101.106
Other comprehensive income X MFRS101.106
Total comprehensive income X MFRS101.106
Dividends paid X MFRS101.106
Acquisition (dilution) of equity interest in subsidiaries
X MFRS101.106
Issuance of shares X MFRS101.106
Other transactions with owners X MFRS101.106
Other changes in equity X MFRS101.106
Total increase (decrease) in equity X MFRS101.106
Equity at end of period X MFRS101.106
Table 2: A dimensional model of a Statement of changes in equity (presentation linkbase view)
11
Components of equity
Equity
Equity attributable to owners
of parent
Non-c
ontr
ollin
g
inte
rests
Issued
capital
Tre
asury
share
Reta
ined
earn
ings
Oth
er
reserv
es
inte
rest
Statement of changes in equity
Equity
Changes in equity
Comprehensive income
Profit (loss)
Other comprehensive income
Comprehensive income
Dividends paid
Acquisition (dilution) of equity interest in
subsidiaries
Issuance of shares
Increase (decrease) through transactions
with owners, equity
Increase (decrease) through other
changes, equity
Increase (decrease) in equity
Equity
Table 3: A dimensional model of a Statement of changes in equity (Cartesian product view)
12
2.4. The structure of SSM Taxonomy
Figure 1 illustrates the folder structure and files content of SSMT:
Figure 1: Folder structure in SSMT
There are two layers defined in SSMT folder structure:
1. Definitional layer:
Definitional layer is where the Core schema and other imported schema are
located. There are 3 folders defined in this layer:
i. In the “ic” folder, the file ssmt-cor_2012-12-31.xsd is the schema
where the Malaysian jurisdictional extension elements are defined, and
lab_ssmt-en_2012-12-31.xml is the related English label linkbase.
Multiple languages will be supported with multiple label linkbases in the
same location.
ii. In the “ext” folder, two of the “base” IFRS taxonomy resource ifrs-
cor_2012-03-29.xsd and lab_ifrs-en_2012-03-29.xml are imported as
external resources. In SSMT all IFRS concepts are imported and will
serve as the base taxonomy where only some of the concepts will be re-
used in the report layer.
13
iii. In the “fdn” folder, the file ssmt-fdn_2012-12-31.xsd is the schema
where the new data types for non-financial report or Companies Act are
defined.
2. In the Reports layer:
Reports layer is where the related concepts are grouped to represents a
submission report. This layer consists of the following folders:
i. The “ssm” folder is the only folder that will be present in the first SSMT
release – other folders will be added in the future as more Government
agencies and regulators join the SSMT. Within each agency folder there is
one folder for each report of that agency supported by the SSMT. Initially,
the “ssm” folder will contain the MFRS, PERS and CA (requirements under
new Companies Bill) reports, as shown in Figure 1.
a. In the “mfrs” folder, the file mfrs_2012-12-31_full_entry_point.xsd
is the full entry point for the MFRS report. This entry point is then
break down into four different entry point files to accommodate
preparer‟s disclosure type which are:
mfrs_2012-12-31_func-direct
mfrs_2012-12-31_func-indirect
mfrs_2012-12-31_nature_direct
mfrs_2012-12-31_nature_indirect
These entry point files imports both the ssmt-cor_2012-12-31.xsd
and the ifrs-cor_2012-03-29.xsd schemas from the Definitional
layer and related labels. The folder also contains the folder
“mfrs_2012”, which contains “per standard” resources such as
presentation, definition calculation and reference linkbases,
modified as appropriate to include resources related to the
Malaysian jurisdictional extension elements.
b. In the “pers” folder, the pers_2012-12-31_full_entry_point.xsd is
the entry point for the PERS report. This entry point is then break
down into four different entry point files to accommodate preparer‟s
disclosure type which are:
pers_2012-12-31_func-direct
pers_2012-12-31_func-indirect
pers_2012-12-31_nature_direct
pers_2012-12-31_nature_indirect
This entry point imports both the ssmt-cor_2012-12-31.xsd and the
ifrs-cor_2012-03-29.xsd schemas from the Definitional layer and
14
related labels. The folder also contains the folder “pers_2012”,
which contains all resource such as presentation, definition
calculation and reference linkbases related to non-financial report.
c. In the “ca” folder, the file ca_2012-12-31_full_entry_point.xsd is
the entry point for a non- financial report. This report contains the
disclosure requirements under the new Companies Bill. This entry
point imports both the ssmt-cor_2012-12-31.xsd and the ifrs-
cor_2012-03-29.xsd schemas from the Definitional layer and related
labels. The folder also contains the folder “ca_2012”, which contains
all resource such as presentation, definition calculation and reference
linkbases related to non-financial report.
2.5. Absolute and relative paths
The unique root resource location (URL) of the SSMT is
http://www.ssm.com.my/taxonomy/YYYY-MM-DD/ followed by the file path as per
the folder structure in Figure 1. The following table provides examples of absolute
paths to SSMT files:
Table 4: Sample absolute paths
SSMT files can be referenced using both absolute and relative paths. Software
vendors should note that SSMT files should not be amended and should therefore
be referenced via absolute paths in order to avoid file changes being made by
preparers and extenders. This is particularly important when working directly on
the entry point schemas without importing them to another extension schema. In
such cases, all linkbase amendments should be treated as an extension and
saved in new, separate linkbase files.
File Absolute path
core schema http://xbrl.ssm.com.my/taxonomy/YYYY-MM-DD/ssmt/
def/ic/ssmt-cor_YYYY-MM-DD.xsd
English label linkbase http://xbrl.ssm.com.my/taxonomy/YYYY-MM-DD/ssmt/
def/ic/lab_ssmt-en_YYYY-MM-DD.xml
reference linkbase for
MFRS (IAS 1)
http://xbrl.ssm.com.my/taxonomy/YYYY-MM-DD/ssmt/
rep/ssm/mfrs/mfrs_2012/ias_1_2012-12-
31/ref_mfrs_101_2012-12-31.xml
15
2.6. Namespaces and prefixes
Namespaces are required to uniquely identify the schemas that are defined in the
taxonomy. In addition, it also provides information relating to release date of
taxonomy and owners of the taxonomy.
For every namespace a unique prefix is to be defined. The prefix provides some
indication of what the namespace refers to. The table below summaries the
namespaces and prefixes used in the SSMT:
Prefix Namespace URI Use
rol_{ias | ifrs | ifric | sic|
ps_mc}_{“number”}_YY
YY-MM-DD
http://xbrl.ssm.com.my/r
ole/mfrs/ rol_{ias | ifrs
|ifric | sic
}_{“number”}_YYYY-MM-
DD
Namespace for the standards‟
roles schemas (where YYYY-MM-
DD is the standard or
interpretation issue date related to
the latest taxonomy release date).
This namespace is not used for
concepts. Example of
such role is rol_ias_12_2012-12-
31 with URI
http://xbrl.ssm.com.my/role/mfrs/
rol_ias_12_2012-12-31
rol_{mfrs |
pers | ca}-dim_YYYY-
MM-DD
http://xbrl.ssm.com.my/r
ole/{mfrs | pers |
ca}/{mfrs | pers | ca}-
dim
Namespace for the dimensional
roles schema. This namespace is
not used for concepts.
ssmt http://xbrl.ssm.com.my/t
axonomy/YYYY-MM-
DD/ssmt
Main namespace for all SSM
taxonomy concepts shared by
MFRS, PERS and CA (where YYYY-
MM-DD is the taxonomy release
date).
Table 5: Namespaces and prefixes
16
2.7. Core, role and entry-point schemas
The SSMT uses IFRS taxonomy as its base taxonomy, hence there are two
schemas which define the reporting concepts
i. ssmt-cor_YYYY-MM-DD.xsd
Consists of additional reporting concepts which are not define by IFRS,
mostly local reporting concepts which necessary to support Malaysian
jurisdictional requirements
ii. ifrs-cor_YYYY-MM-DD.xsd
Consists of reporting concepts as released in IFRS taxonomy
Just like IFRS Taxonomy, SSMT also does not use tuples or typed axes. Items
and explicit axes are used instead. There are a total of 4053reporting concepts in
the SSMT which includes the concepts define in IFRS Taxonomy.
In the SSMT, only the core schema (ssmt-cor_YYYY-MM-DD.xsd andifrs-
cor_2012-03-29.xsd) contains reportable concepts (located in definitional layer).
An additional role schema is placed in each standard (and axes) folder (located in
reporting layer). These role schemas contain definitions of the presentation,
calculation and definition ELRs. Role schemas do not contain concepts, tables,
axes or members.
Entry points are defined to group related reporting concepts in one schema file.
The following table lists all entry points schemas define in SSMT:
Entry point Schema Location Purpose
mfrs_2012-12-
31_full_entry_point
.xsd
http://xbrl.ssm.com.my/taxon
omy/2012-12-
31/ssmt/rep/ssm/mfrs/mfrs_2
012-12-
31_full_entry_point.xsd
Full entry point schema
consists all reporting
concepts for MFRS
mfrs_2012-12-
31_func-direct.xsd
http://xbrl.ssm.com.my/taxon
omy/2012-12-
31/ssmt/rep/ssm/mfrs/mfrs_2
012-12-31_func-direct.xsd
Entry point for MFRS
preparer who submit the
following:
i. Statement of
comprehensive income,
by function of expense
ii. Statement of cash flows –
Direct
17
Entry point Schema Location Purpose
mfrs_2012-12-
31_func-
indirect.xsd
http://xbrl.ssm.com.my/taxon
omy/2012-12-
31/ssmt/rep/ssm/mfrs/mfrs_2
012-12-31_func-indirect.xsd
Entry point for MFRS
preparer who submit the
following:
i. Statement of
comprehensive income,
by function of expense
ii. Statement of cash flows –
Indirect
mfrs_2012-12-
31_nature_direct.x
sd
http://xbrl.ssm.com.my/taxon
omy/2012-12-
31/ssmt/rep/ssm/mfrs/mfrs_2
012-12-31_nature_direct.xsd
Entry point for MFRS
preparer who submit the
following:
i. Statement of
comprehensive income,
by nature of expense
ii. Statement of cash flows –
Direct
mfrs_2012-12-
31_nature_indirect.
xsd
http://xbrl.ssm.com.my/taxon
omy/2012-12-
31/ssmt/rep/ssm/mfrs/mfrs_2
012-12-31_nature_indirect.xsd
Entry point for MFRS
preparer who submit the
following:
i. Statement of
comprehensive income,
by nature of expense
ii. Statement of cash flows – Indirect
pers_2012-12-
31_full_entry_point
.xsd
http://xbrl.ssm.com.my/taxon
omy/2012-12-
31/ssmt/rep/ssm/pers/pers_2
012-12-
31_full_entry_point.xsd
Full entry point schema
consists all reporting
concepts for PERS
pers_2012-12-
31_func-direct.xsd
http://xbrl.ssm.com.my/taxon
omy/2012-12-
31/ssmt/rep/ssm/pers/pers_2
012-12-31_func-direct.xsd
Entry point for PERS
preparer who submit the
following:
i. Statement of
comprehensive income,
by function of expense
ii. Statement of cash flows –
Direct
18
Entry point Schema Location Purpose
pers_2012-12-
31_func-
indirect.xsd
http://xbrl.ssm.com.my/taxon
omy/2012-12-
31/ssmt/rep/ssm/pers/pers_2
012-12-31_func-indirect.xsd
Entry point for PERS
preparer who submit the
following:
i. Statement of
comprehensive income,
by function of expense
ii. Statement of cash flows –
Indirect
pers_2012-12-
31_nature_direct.x
sd
http://xbrl.ssm.com.my/taxon
omy/2012-12-
31/ssmt/rep/ssm/pers/pers_2
012-12-31_nature_direct.xsd
Entry point for PERS
preparer who submit the
following:
i. Statement of
comprehensive income,
by nature of expense
ii. Statement of cash flows –
Direct
pers_2012-12-
31_nature_indirect.
xsd
http://xbrl.ssm.com.my/taxon
omy/2012-12-
31/ssmt/rep/ssm/pers/pers_2
012-12-31_nature_indirect.xsd
Entry point for PERS
preparer who submit the
following:
i. Statement of comprehensive income, by nature of expense
ii. Statement of cash flows – Indirect
ca_2012-12-
31_full_entry_point
.xsd
http://xbrl.ssm.com.my/taxon
omy/2012-12-
31/ssmt/rep/ssm/ca/
ca_2012-12-
31_full_entry_point.xsd
Entry point for non-financial
reporting - as required under
the Companies Act 1965 /
New Companies Bill:
i. Directors‟ Report;
ii. Statement by Directors; iii. Directors‟ Business
Review (New Companies Bill);
iv. Auditors Report to the Members / Auditor‟s Statement; and
v. The return of Exempt Private Company
Table 6: Entry point schemas
19
2.8. Customised Data Types
The SSMT uses item types as defined in XBRL 2.1 specification and the additional
data types as defined in customized data types schema, ssmt-fdn_2012-12-
31.xsd which is located in “fdn” folder in definitional layer. SSM imposed some
restrictions on the allowed values for some reporting concepts. These restrictions
are incorporated in the taxonomy by creating customized data types (XML
schema enumerations) for the concepts. For example, a ssmt-
fdn:companyStatusItemType has enumerations of Sdn. Bhd., Bhd., and Sdn.
which describes the company status in Malaysia. By defining a new data type,
preparers submitting values for this concept will be restricted to this set of
enumerations. The definitions of all the data types will be placed in a special
module (called ssmt-fdn) which will be imported by schemas containing the
concepts. The examples of new data type defined within SSMT are defined in the
following table:
DataType Assigned to element Restriction
companyStatusItemType CompanyStatus Sdn. Bhd.;
Bhd.;
Sdn.
businessReviewIsRelated
ToItemType
DisclosureOfBusinessRevie
wAdressOfEnvironmentSoci
alCommunityAndOtherMatt
ers
Environmental matters;
Social and Community
issues;
Others
recordsNotKeptProperlyB
yCompanyItemType
ExplanationOfRecordsWere
NotKeptProperlyByCompan
y
Accounting and its
supporting documents;
Register books
sevenDigitAndOneAlphab
etItemType
CompanyRegistrationNumb
er;
CompanyRegistrationNumb
erOfLocalHoldingCompany;
CompanyRegistrationNumb
erOfLocalUltimateHoldingC
ompany;
CompanyRegistrationNumb
erOfLocalSubsidiary
[0-9][0-9][0-9][0-9][0-
9][0-9][0-9][a-z|A-Z]
Table 7: Examples of custom data types
20
2.9. Linkbases
Linkbases in SSMT are organised and viewed as a set of financial statements as
prepared by different types of entities. The SSMT uses sort codes (an artificial 6-
digit number) at the beginning of each ELR definition, which provides viewing and
sorting functionality.
2.9.1 Presentation linkbase
The presentation linkbase is designed to display the hierarchy of elements as it
would appear in a typical set of financial statements. Example of the
presentation view of Statement of financial position is as shown in the figure
below:
Figure 2: Presentation linkbase
21
2.9.2 Definition linkbase
The SSMT uses definition linkbases to express dimensional relationships. The
SSMT defines axes and members for listed relationships, and therefore only uses
explicit axes. Typed axes are not used in the SSMT at the moment. The SSMT
defines tables where an axis has clearly been applied to a set of line items.
Example of the definition view of Statement of changes in equity is as shown in
the figure below:
Figure 3: Definition linkbase
Consequently, axes in the SSMT are either applied (to line items) or for
application (not linked in a table). The latter can be connected to any set of line
items, depending on the needs of the preparer.
There are two types of definition linkbases in the SSMT.
The first is the definition linkbase file placed in the standards folder, which mirrors
the structure of the presentation linkbase if the presentation linkbase contains a
table. These file names have the prefix def_, they represent hierarchies of line
items, and they link axes to a given set of reportable items (line items) within the
SSMT. These hierarchies re-use the presentation linkbase ELRs and therefore also
their ordering numbers (ELR definitions that are numbered between [100000] and
[899999] represent line items).
The second type of definition linkbase represents axes, and these are placed in
the dimensions folder or in the standards folder (if they represent axes that are
applied to a set of line items). Dimensional definition linkbases also have an
equivalent in the structure of the presentation linkbase. These filenames have the
prefix dim_ or pre_. ELR definitions that are numbered between [900000] and
[989999] should be linked via tables with ELR definitions numbered between
22
[100000] and [899999]1 or they should already be linked to the respective sets of
line items. It is possible to combine one set of line items with more than one axis
on a table.
All defaults for axes (dimensions) are placed in a single ELR number [990000] to
avoid redundancies. This ELR does not have an equivalent in the presentation
linkbase.
2.9.3 Calculation linkbase
In the SSMT, calculation linkbases are used to define arithmetical relationships as
per XBRL specifications. Example of the calculation view under ELR [821000] Note
– Provisions.
Figure 4: Calculation linkbase view
Weight of +1 denotes the element will be added to arrive at the sub-total, while -
1 indicates value to be reduced.
Due to certain limitations of calculation linkbase, not all additive and subtractive
relations can be defined. For example, additive and subtractive relationship
cannot be handled in Calculation linkbase due to the different periodtypes (instant
and duration) being assigned to elements.
2.9.4 Label linkbase
The SSMT2012 uses the label roles as specified in XBRL 2.1 as well as label roles
which are introduced in XBRL standards in recent years. All the labels are defined
in English and are created as per the rules specified in Style Guide. The different
types of labels are defined to make the taxonomy to facilitate easy viewing of
taxonomy. The label roles used in the SSMT are listed in the table below:
1In other words, ELRs that have the prefix def_ should be linked via table (hypercube) with ELRs
from the file that have the prefix dim_.
23
Label role Use
http://www.xbrl.org/2009/
role/negatedLabel
Label for a concept, when the value being
presented should be negated (sign of the value
should be inverted). For example, the standard
and standard positive labels might be profit (loss)
after tax and the negated labels loss (profit) after
tax.
http://www.xbrl.org/2009/
role/negatedTotalLabel
http://www.xbrl.org/2009/
role/negatedTerseLabel
http://www.xbrl.org/2009/
role/netLabel
The label for a concept when it is to be used to
present values associated with the concept when
it is being reported as the net of a set of other
values. Net labels allow the expression of labels,
other than the one to be used as total label, if the
presentation tree represents a gross/net
calculation instead of a traditional calculation roll-
up. For example, the standard label for Property,
plant and equipment can have the total label
Total property, plant and equipment and the net
label Net property, plant and equipment.
http://www.xbrl.org/2003/
role/label
Standard label role for a concept. The IFRS
Taxonomy uses standard labels to guarantee
uniqueness of the labels.
http://www.xbrl.org/2003/
role/totalLabel
The label role for a concept when it is to be used
to present values associated with the concept
when it is reported as the total of a set of other
values. This role should not be used to infer
semantics of facts reported in instance
documents.
http://www.xbrl.org/2003/
role/periodStartLabel
The label role for a concept with the
periodType="instant" when it is to be used to
present values associated with the concept when
it is reported as a start (end) period value. These
roles should not be used to infer semantics of
facts reported in instance documents.
http://www.xbrl.org/2003/
role/periodEndLabel
http://www.xbrl.org/2003/
role/terseLabel
Short label role for a concept, often omitting text
that should be inferable when the concept is
reported in the context of other related concepts.
http://www.xbrl.org/2003/
role/documentationLabel
Additional explanation for the user on particular
concept
Table 8: Label roles
24
2.9.4.1 Reuse of IFRS labels
Current version of SSMT is not reusing some of the original labels as
defined within IFRS 2012 Taxonomy. The reason for that is SSMT includes
local reporting labels as well as to provide additional information not
covered by the IFRS Taxonomy 2012.
Result of such approach may generate a number of Financial Reporting
Taxonomy Architecture (FRTA) validation errors according to section
2.1.102. The section states that each concept must have a label with the
standard label role. However some of the IFRS elements were not provided
with a label, in order to indicate that particular concept is not reportable to
SSM for this taxonomy version. The above mentioned inconsistencies will
not have a negative impact on the taxonomy or its users.
2.9.4.2 Total and net labels
Total and net labels are used as preferred labels in presentation linkbase
for those elements which have calculations are defined in calculation
linkbase. For example, if an element (which is numeric in nature) is a
summation of other elements, then total label role is used. Figure 5
displays the calculation hierarchy of the example where total label is used
in presentation linkbase.
Figure 5: Total label in presentation linkbase
2http://www.xbrl.org/technical/guidance/FRTA-RECOMMENDATION-2005-04-25.htm#_2.1.10
25
2.9.4.3 Negated labels
Negated labels in the SSMT use a set of label roles from the XBRL
International Link Role Registry (LRR). Negated labels are generally used
for elements which are to be reduced in order to arrive at a sub-total. The
label merely indicates, the negative weight and the use of negated labels
do not affect the sign of a reported value in XBRL. Negating a label only
affects the visualization of the reported data; it does not affect the data
itself (there is no influence on the sign of reported concepts).
The following negated labels are used in the SSMT:
i. Standard negated label role
ii. Negated total label role
iii. Terse negated label role
Figure 6 below shows the use of negated label and negated terse label as
preferred label in presentation linkbase.
Figure 6: Negated label in presentation linkbase
26
Calculation view of the same example of statement of cash flow is shown in
Figure 7 below:
Figure 7: Calculation view of negated label
In the taxonomy, the debit and credit attributes impact the way calculation
linkbase is created. As per XBRL specifications, a debit can be added to
debit, or credit can be added to credit and a credit can be reduced from
debit or a debit can be reduced from credit. Addition or reduction of
elements is determined by weight attribute. So if weight is +1, it indicates
elements are added and if weight is -1, it indicates element is to be
reduced in order to arrive at the sub-total.
With reference to Figure 7 above, „Payments to suppliers for goods and
services‟, „Payments to and on behalf of employees‟ and „Other cash
payments from operating activities‟ are to be deducted from other cash
flow receipts from operations . Therefore, those elements are defined with
“-1” weight in the taxonomy. As the weight is negative, the value to be
27
stored in instance document will have no sign (or will be positive). By doing
this, the calculation relationships defined in the taxonomy will tally.
However while displaying the information; software products may use
inverted sign, wherever negated labels are used in the taxonomy. Inverted
values may be presented in brackets, in a separate column or with a minus
before the value.
2.9.5 Reference linkbases
The SSMT uses reference roles as listed in the following table:
Reference role Use
http://www.xbrl.org/2003/role/
disclosureRef
Reference to documentation that details an
explanation of the disclosure requirements
relating to the concept.
http://www.xbrl.org/2003/role/
exampleRef
Reference to documentation that illustrates by
example the application of the concept that
assists in determining appropriate usage.
http://www.xbrl.org/2009/role/
commonPracticeRef
Reference for common practice disclosure
relating to the concept. Enables common
practice reference to a given point in
Table 9: Reference roles
A reference resource is made of several parts and these are parts defined in XBRL
specification. Table 9 below summarizes the reference parts that are referred to
in SSMT:
Part Use
Name {MFRS|PERS|CA}
Number Number of the standard or interpretation
Section Title of sections of standard or interpretation
Subsection Title of the subsection of the section
Paragraph Paragraph (number) in the standard
Sub-paragraph Subparagraph (number) of a paragraph
Clause Subcomponent of a subparagraph
URI Link to text of the standard in MFRS/PERS/CA
Table 10: Reference resource parts
28
3. Style Guide
The purpose of this Style Guide is to facilitate the creation of a consistent, high-
quality and easy-to-use taxonomy in many languages.
The objectives of defining the Style Guide are to:
1. Provide users of the taxonomy with labels that are recognizable to the
user.
2. Provide users of the taxonomy with consistency, which makes it easier
to locate a concept.
3.1 General Guidance
Wording prescribed in Malaysian Financial Reporting Standards (MFRS), Private
Entity Reporting Standards (PERS) and Companies Act (CA) takes precedence
over the rules in this guide. This guide is to be used in conjunction with the above
mentioned standards and act. It should only be applied when the said standards
and act do not provide enough guidance to construct labels for SSMT.
3.2 Style guide for Extended Link Roles (ELR)
3.2.1 Roles definitions SHALL start with the ordering number.
For better sorting of the extended link roles (ELR), the definitions of the ELRs
SHALL starts with a six-digit number.
The numbers allow sorting of the ELRs according to the structure of financial
reports.
ELR for faces of financial statements will follow the sequence of number
starting from 1.
For example:
Statement of comprehensive income starts with number „1‟
Statement of financial position starts with number „2‟
Statement of changes in equity starts with number „3‟
Statement of cash flows starts with number „4‟
The second digit of ELR sequence number represents further categorization of
an ELR.
29
For example, Statement of comprehensive income have two types; by
function and by nature. Hence, the sorting numbers for these ELR are:
[11000] Statement of comprehensive income, by function
[12000] Statement of comprehensive income, by nature
ELR for notes to the financial statements will start with number „8‟ followed by
sequence running number.
For example
„[801000] Notes – Corporate information‟ followed by „[802000] Notes –
Summary of significant accounting policies
3.2.2 Roles definitions SHOULD use the agreed wording.
Roles definitions for disclosures should start with the number followed by the
word „Notes – „.
For example:
[833000] Notes –Other assets.
Exceptions for dimensions ELR:
[901000] Axis - Retrospective application and retrospective restatement‟.
3.3 Style Guide for element name and ID
3.3.1 The element id MUST be created in the format namespace prefix of
the taxonomy, followed by an underscore, followed by the element name (“prefix_ElementName”)
For example:
ssmt_DisclosureOfProfitBeforeTaxAbstract‟
ssmt_DateOfAuditorsStatement‟
3.3.2 Element name SHOULD be concise, follow terminology as per the
regulations, and avoid being excessively descriptive
30
For example:
Reporting concept Element name
PropertyPlantAndEquipmentBeforeAccu
mulatedDepreciationAndExcludingIntan
gibleAssets
PropertyPlantAndEquipmentGross
Table 11: Example of concise element name
3.3.3 Concept names SHOULD adhere to the LC3 convention
LC3 means Label Camel Case Concatenation (LC3). Some of the important or
relevant LC3 rules require that:
Element names MUST be based on an appropriate presentation label for the
element. The element name SHOULD be a natural language expression
that is meaningful to experts in the domain covered by a taxonomy
The first character of the element name must not be underscore ( _ )
The first character of the element name must be capitalized
Connective words in the label may be retained in the element name.
Examples of English connective words include (but are not limited to) the
following: and, for, which, with
As a consequence of XML element name restrictions, all special characters
must be omitted from the element name. Special characters include the
following:
( ) * + [ ] ? \ / ^ { } | @ # % ^ = ~ ` “ ” ; : , <>& $ ₤ €
Element names must be limited to 256 characters or fewer
3.3.4 The following articles MUST NOT be used in element names:
Disallowed articles:
An
A
The
31
3.3.5 The adjectives in all labels SHOULD be used with a noun (except terse
labels).
For example, “TemporarilyIdle” alone means nothing.
“ExplorationAndEvaluationAssetsTemporarilyIdle” is meaningful
3.3.6 Numbers SHOULD be expressed as text when less than 10.
The expression of number is a matter of judgment. The following rules for
numbers should be considered:
Exact numbers one through nine should be spelt out, except for
percentages and numbers referring to parts of a book (for example, „5
per cent‟, „page 2‟) and accounting standard number or paragraph, if to
be used.
Numbers of 10 or more should be expressed in figures.
3.3.7 Adjectives SHOULD be used when there is ambiguity surrounding a concept.
For example, „Provisions‟ should always be current, non-current or total. The
proper element name should be „CurrentProvisions‟ or „NonCurrentProvisions‟
3.3.8 Concepts for disclosures that define textual type explanations SHOULD start with a descriptor that explains the nature of the text
For example:
“DisclosureOfCorporateInformationAbstract”
“ExplanationOfReasonWhyPreviousFinancialStatementFiguresAreRestated”
Whereas for the concept label “ImpactOfChangesInAccountingEstimates” , it is
not clear if the concept is an amount or a narrative.
The following are common starting wordings for text-type content that appear
in disclosures:
AdditionalInformationAbout
AddressOf
AddressWhere
CountryOf
DescriptionAndCarryingAmount
Of
DescriptionOf
ExplanationWhen
IndicationOf
InformationAbout
InformationRequired
InformationWhether
MethodsUsedTo
NameOf
32
DescriptionOfAccountingPolicyF
or
DescriptionOfNatureOf
DescriptionOfReasonFor
DescriptionOfReasonWhy
DisclosuresIn
DisclosureOf
DomicileOf
ExplanationOf
PrincipalPlaceOf
QualitativeInformationAbout
RangeOf
ResidenceOf
StatementOf
SummaryQuantitativeDataAbout
3.3.9 Concepts that represent a non-monetary or non-text value SHOULD start with an appropriate descriptor
These include concepts that are decimals, percentages and dates.
For example:
“DateOfExemptPrivateCertificate”
“NumberOfExecutiveEmployees”
The following are common starting labels for non-monetary and non-text
content which appear within disclosures:
“DateOf…”
“NumberOf….”
“WeightedAverageExercisePriceOf …”
“PercentageOf…”
“ProportionOf…”
3.3.10 The element name for abstract concepts that do not represent
hypercubes, dimensions, domains, or domain members MUST append the word “Abstract” or “LineItems” to the end of the element name
Abstract elements are used to organise the taxonomy. Element names for
abstract items shall append the word “Abstract” or “LineItems”. The reason for
this is to differentiate the abstract concepts from the concepts which can
actually hold values.
For example:
“DirectorsBusinessReviewAbstract”
“StatementOfFinancialPositionLineItems”
33
3.3.11 The element name for nonnum:textBlockItemType concepts MUST
append the word “Explanatory” to the end of the name
Text block elements are used to disclose narrative information.
For example:
“DisclosureOfStatementByDirectorsExplanatory”
“DisclosureOfDirectorsReportExplanatory”
3.3.12 The element name for dimensions MUST append the word “Axis” to the end of the name
Dimensions are abstract concepts used as containers for domains, and domain
members should be clearly recognizable through their names.
For example: “CategoriesOfRelatedPartiesAxis”
3.3.13 The element name for hypercubes MUST append the word “Table” to the end of the name
Hypercubes are abstract concepts used as link between dimensions and line
items.
For example: “DisclosureOfProfitBeforeTaxTable”
3.3.14 The element name for domain and domain members MUST append the word “Member” to the end of the name
Domain and domain members are abstract concepts used as members on the
axis (dimension).
For example: “KeyManagementPersonnelOfGroupMember”
3.3.15 The word “total” MUST NOT be used in any element name
The word “total” should not be used in an element name. The word “total” can
be used in the total label role. In addition, the total label role can use the word
“aggregated” and net label role the word “net”.
For example, “AssetsTotal” should not be used as element name; “Assets” is
sufficient. A total label as “Assets, Total” should be created instead.
34
3.4 Style Guide for Label Linkbase
3.4.1 Labels SHOULD be concise, follow IFRSs terminology, and avoid being excessively descriptive.
For example „Property, plant and equipment before accumulated depreciation
and excluding intangible assets‟ should be „Property, plant and equipment,
gross‟.
3.4.2 The agreed spelling SHOULD be used.
As there are various accepted ways to spell some terms, the following list of
terms should be used in the SSMT.
anti no hyphen
co no hyphen except
o “co-operate/co-operation”
o “co-ordinate/co-ordination”
non always hyphen (but note “nonsense”, “nonentity” etc.)
over no hyphen except
o “over-optimistic”
o “over-represent”
pre no hyphen except
o “pre-empt”
o “pre-exist”
post always hyphen
pro no hyphen except
o “pro-forma”
re no hyphen except
o “re-enter”
o “re-present” (to present again)
o “re-record”
semi always hyphen
35
sub no hyphen except
o „sub-lessee”
o „sub-lessor”
super no hyphen
un no hyphen
under no hyphen except
o “under-record”
o “under-report”
o “under-represent”
Specific terms to be used with hyphen
o Available-for-sale
o Held-to-maturity
o Held-for-trading
3.4.3 Labels SHALL NOT contain certain special characters.
The following characters should generally be avoided in creating concept
labels:
Disallowed Characters
? | >< : * “ + ; = . & ! @ # { } \
Allowed Characters
A-Z, a-z, 0-9, (,), comma, -, „, space, [ ], /
3.4.4 Labels MUST start with a capital letter and MUST NOT use upper case,
except for proper names and abbreviations
For example, “Explanation of reason why previous financial statement figures
are re-classified”.
List of words (among others) that are capitalized:
MFRS
PERS
36
XBRL
CA
Director‟s Report
Stock Exchange
3.4.5 The following articles MUST NOT be used in labels:
Disallowed articles:
An
A
The
3.4.6 The adjectives in all labels SHOULD be used with a noun (except terse labels).
For example, „Temporarily idle‟ alone means nothing. „Exploration and
evaluation assets, temporarily idle‟ is meaningful
3.4.7 Dashes SHALL NOT be used in labels where commas can be used
instead.
For example, DO NOT use „Disclosure - Director's Report [text block]‟, but
rather use „Disclosure of Director's Report [text block]‟.An exception is the use
of dashes in the definition of extended link roles.
3.4.8 In a series of three or more items, commas SHALL be used after each item excluding the penultimate item.
Use a comma to separate items in a series of three or more items not
including before the final „and‟. For example: „Property, plant and equipment
3.4.9 Numbers SHOULD be expressed as text when less than 10.
The expression of number is a matter of judgment. The following rules for
numbers should be considered:
Exact numbers one through nine should be spelt out, except for
percentages and numbers referring to parts of a book (for example, „5
per cent‟, „page 2‟).
37
Numbers of 10 or more should be expressed in figures.
3.4.10 The word „per cent‟ SHALL be spelt out, as two words.
A range would be written as ‟5 to 10 per cent‟.
3.4.11 Labels SHALL NOT have leading spaces, trailing spaces or double spaces.
3.4.12 Certain adjectives and prepositions used in labels SHOULD appear before or after the noun and be separated by a comma.
For example: ‟Other intangible assets, gross‟ and „Other comprehensive
income, net of tax‟.
The following sentence construct models the intention of how concept labels
should be created. Note that what is contained in curly braces {}, is one
component of the label. The different sets of curly braces are the different
components of the same label. The format below prescribes the order in which
the components should appear if present:
{Total*} {other} {current or non-current} {noun}, {net [of tax] or
gross [of tax]}, {at cost or at fair value}
For example: „Total other non-current asset, gross, at fair value‟
Example of properly-constructed labels (per model):
„Current trade receivables, gross‟
„Other comprehensive income, net of tax‟
„Accumulated depreciation of biological assets, at cost‟
Example of poorly-constructed labels (not per model):
„Current gross trade receivables‟
„Trade and other receivables, current, net‟
„Equity – share subscriptions, total‟
„Accumulated at cost depreciation of biological assets‟
Exceptions include net or gross labels for which the counterpart does not exist.
For example:
38
„Gross profit‟, „Net exchange differences, brand names‟ or „Net cash flows from
(used in) financing activities‟.
3.4.13 Adjectives SHOULD be used when there is ambiguity surrounding a concept.
For example, „Provisions‟ should always be current, non-current or total. The
proper label for the taxonomy concept should be „Current provisions‟, „Non-
current provisions‟ or „Total provisions‟ (this used as a totalLabel role for the
concept Provisions).
3.4.14 Concepts for disclosures that define textual type explanations SHOULD start with a descriptor that explains the nature of the text
For example:
“Explanation of reason why previous financial statement figures are
restated”
“DescriptionOfReasonWhyUsingDifferentReportingDateOrPeriodForForeig
nSubsidiary”.
Whereas for the concept label “Impact of changes in accounting estimates”, it
is not clear if the concept is an amount or a narrative.
The following are common starting labels for text-type content that appear in
disclosures:
Additional information
about…
Address of …
Address where …
Country of …
Description and carrying
amount of …
Description of …
Description of accounting
policy for…
Description of nature of…
Description of reason for…
Indication of …
Information about…
Information required …
Information whether …
Methods used to…
Name of …
Principal place of …
Qualitative information about …
Range of …
Residence of …
Statement of …
39
Description of reason why…
Domicile of …
Explanation of …
Explanation when …
Summary quantitative data
about …
3.4.15 Concepts that represent a non-monetary or non-text value SHOULD
start with an appropriate descriptor
These include concepts that are decimals, percentages and dates.
For example:
“Date of Exempt Private Certificate”
“Number of executive employees”
The following are common starting labels for non-monetary and non-text
content which appear within disclosures:
Date of…
Number of….
Weighted average exercise price of …
Percentage of…
Proportion of…
3.4.16 Labels SHOULD avoid defining what they do or do not include.
For example, ‟Property, plant and equipment including land and buildings‟
should be avoided. What an item includes or excludes should be provided in
the definition of the concept or the calculation linkbase. In some cases, a label
needs to define inclusions and exclusions, because particular concepts do not
have an agreed meaning.
For example: „Intangible assets without goodwill‟ is allowed.
3.4.17 For concepts that can be either negative or positive, the concept label MUST use parentheses ( ) to indicate which concept is represented as
positive or negative values in the instance document
There are occasions in an instance document when the value of a concept
could be positive or negative, for example, “Increase (decrease)”. A space
should appear between the positive item and the opening parenthesis. A slash
should not be used. The following are examples of concepts that may have
positive or negative values:
40
Disposals (acquisitions)
from (used in)
Gains (losses)
Income (expense)
Increase (decrease)
Inflow (outflow)
Loss (reversal)
Paid (refund)
Profit (loss)
Proceeds from (purchase
of)
Write-downs (reversals)
Parentheses SHOULD be used to denote positive or negative values and
SHOULD NOT be used to denote alternative terms for a label such as „Deferred
(unearned) revenue‟.
3.4.18 The label component related to XBRL and not to regulations
(accounting standards, acts etc.) MUST be placed between square brackets “[ ]” at the end or beginning of the label
The component of labels placed in square brackets provides XBRL-related
information that does not influence the accounting information (for example
for alternative breakdown). For example:
[824000] Notes – share capital
Disclosure of share capital [abstract]
3.4.19 The standard label for abstract concepts that do not represent hypercubes, dimensions or domain members SHALL append the word
„[abstract]‟ or „[line items]‟ to the end of the label.
Abstract elements are used to organize the taxonomy. Labels for abstract
items shall append the word „[abstract]‟. The reason for this is to differentiate
the concept labels and names.
For example:
„Assets [abstract]‟.
„Disclosure of trade and other payables [line items]‟
3.4.20 The standard label for textBlockItemType concepts SHALL append the word „[text block]‟ to the end of the label
Text block elements are used to disclose narrative information.
For example:
„Disclosure of Exempt Private Certificate [text block]‟.
41
3.4.21 The standard label for dimensions SHALL append the word „[axis]‟ to
the end of the label.
Dimensions are abstract concepts used as containers for domains, and domain
members should be clearly recognizable through their labels.
For example:
„Consolidated and Separate [axis]‟.
3.4.22 The standard label for hypercubes SHALL append the word „[table]‟ to the end of the label.
Hypercubes are abstract concepts used as link between dimensions and line
items.
For example:
„Disclosure of share capital [table]‟.
3.4.23 The standard label for domain members SHALL append the word
„[member]‟ to the end of the label.
Domain members are abstract concepts used as members on the axis
(dimension).
For example:
„Company [member]‟.
3.4.24 The word „total‟ SHALL NOT be used in any label (except in the total label role).
The word „total‟ should not be used in a standard label name. The word „total‟
can be used in the total label role. In addition, the total label role can use the
word „aggregated‟ and net label role the word „net‟.
For example, „Assets, total‟ should not be used as standard label; „Assets‟ is
sufficient.
Examples of disallowed use of „total‟, which should be avoided for standard
label role:
„Assets, total‟
„Changes in issued capital, total‟
„Sales, total‟
„Total assets‟
42
„Aggregated assets‟
3.4.25 Authoritative references SHOULD NOT be used in a label, unless
necessary to make the label meaningful
Labels should not include the name of authoritative literature. However in
certain cases, where it is necessary to include such details, there is can be
used.
3.4.26 Labels representing the period start label SHALL use the following
format ‟at beginning of period‟ at the end of the label. Labels representing the period end label SHOULD use „at end of period‟ at the end of the label.
Example of proper use of the period start and period end label:
„Provisions at beginning of period‟
„Provisions at end of period‟
Example of disallowed use of the period start and period end label:
„Provisions, beginning balance‟
„Provisions, at start‟
„Provisions, period end‟
4. References
The SSM Taxonomy Guide has been prepared considering the practices followed
by some of the globally known taxonomies. The following documentation has
been considered for identifying the scope of information to be provided as part of
Taxonomy Guide.
The IFRS® Taxonomy 2012 Guide
Global Filing Manual (GFM)
ACRA Taxonomy 2013 Guide
The content of this Guide is purely based on SSM Taxonomy. The above
mentioned guides were referred in order to be in line with the documentation
practices followed globally.