Understanding the taxonomy - Australian Prudential Regulation

advertisement
Adopting Standard
Business Reporting
Understanding the taxonomy
Version 1.0 (issued November 2013)
www.apra.gov.au/sbr
Australian Prudential Regulation Authority
Disclaimer and copyright
While APRA endeavours to ensure the quality of this
publication, it does not accept any responsibility for
the accuracy, completeness or currency of the material
included in this publication and will not be liable
for any loss or damage arising out of any use of, or
reliance on, this publication.
© Australian Prudential Regulation Authority (APRA)
This work is licensed under the Creative Commons
Attribution 3.0 Australia Licence (CCBY 3.0).
This licence allows you to copy,
distribute and adapt this work, provided you attribute
the work and do not suggest that APRA endorses you
or your work. To view a full copy of the terms of this
licence, visit www.creativecommons.org/licenses/
by/3.0/au/.
Australian Prudential Regulation Authority
ii
Adopting Standard Business Reporting
Taxonomy design principles for reporting entities
Contents
Introduction
5
The basics of XBRL
5
Definitional taxonomy and reporting taxonomy
6
Labels
8
Language
8
Definition taxonomy labels
8
Standard label
9
Business definition
9
Business guidance
10
Report taxonomy labels
10
Report label
11
Report guidance
11
Dimension taxonomy labels
11
Taxonomy design guidance
Concepts
12
12
Same concept – reported values are identical
12
Same concept – different time period
12
Dimensionality/Contextualisation
Criteria
13
13
When to apply a dimension
13
Segment vs. Scenario
13
Balance attribute
14
Period type - Instant/Duration
14
Attributes that have not been included in the taxonomy
15
D2A form scenarios
15
Tuples
15
Report consolidations as dimensions
15
Australian Prudential Regulation Authority
iii
Adopting Standard Business Reporting
Taxonomy design principles for reporting entities
Australian Prudential Regulation Authority
iv
Adopting Standard Business Reporting
Taxonomy design principles for reporting entities
Introduction
This document has been provided to assist APRA reporting entities to understand the design
principles used to create the APRA SBR Taxonomy. It outlines the decisions in respect of the
harmonisation or creation of data elements.
It is not intended to be a set of hard and fast rules, but more a consideration of the alternatives
when presented with certain scenarios. It is provided as background or introductory information.
The basics of XBRL
The creation of an XBRL taxonomy requires the identification of both the data a computer requires,
and the information required for human interpretation. The human aspect involves identifying what
the data element is and how it should be used.
Computers only require an element identifier to deal with the data in the manner in which they
have been programmed. The single requirement is that the identifier be unique within the set of
data elements with which it has to deal. Humans need additional information to understand what a
data element is intended to represent, such as descriptions and references.
Before XBRL, programmers tried to put additional information into the element identifier to convey
all required information in a computer readable format. This task proved difficult because one
person’s interpretation of the data could vary greatly from another’s, whilst the element remained
the same. XBRL sought to overcome this problem by providing external ‘linkbases’ - places where
the human language and interpretations could be captured that were linked to, but not part of, the
element itself.
Linkbases enable personal preferences for describing an element to be captured, without
compromising the simple needs of the computer for a unique identifier. People more readily agree
on what something is, than what it should be called. XBRL allows for everyone's preference to be
captured and different descriptions of the element to be used, thus avoiding the ‘one size fits all’
problem.
There are several standard XBRL linkbases where the descriptive information about the data
elements (metadata) can be captured:

Label
for easily readable documentation of the taxonomy elements like
names, definitions and usage guidance;

Reference
for references to authoritative literature that conveys shared
understanding among the taxonomy’s stakeholders on what a data
element actually is, regardless of the various labels associated with
it, e.g. Australian accounting standards;

Definition
for structural information about the hierarchies in which the element
exists. In SBR this is mainly used to hold information about the
dimensions of a data element;
Australian Prudential Regulation Authority
5
Adopting Standard Business Reporting
Taxonomy design principles for reporting entities

Calculation
for simple arithmetic validations involving the element, e.g.
checking net figures or subtotals and totals calculate correctly, only
addition and subtraction are contained here; and

Presentation
for visual representation of the hierarchies (structure) in a taxonomy
and the order in which elements in a list should be viewed.
The different descriptions, called labels in XBRL, are identified by label roles.
A single data element can have an unlimited number of labels attached to it, each with its own
unique label role to identify it to the computer.
Computer
Human
(IT responsibility)
(Taxonomy developer responsibility)
Role = label/APRALabel
<custid>
Client Reference
Role = label/busDefinition
Role = label/Standard
This is the unique
identifier used within
the agency system that
receives the data
Party Identifiers Customer Identifier
SBR has determined that every element in the SBR AU Taxonomy will have the ‘standard’ label role.
This label is constructed from the Naming Convention SBR adapted from ISO 11179.
The naming convention’s purpose is to use non-agency specific language to generically describe a
data concept that enables anyone to search the taxonomy and find the element that represents
that concept without understanding agency jargon.
Definitional taxonomy and reporting taxonomy
SBR architecture dictates that data elements on the forms are represented in SBR by a two level
structure:
1.
Definitional Taxonomy, which holds the elements and the generic descriptive information; and
2.
Reporting Taxonomy (one per form), which holds the presentation and form specific
information.
Australian Prudential Regulation Authority
6
Adopting Standard Business Reporting
Taxonomy design principles for reporting entities
These linkbases can be attached to every taxonomy, and labels can be defined at both levels for a
data element.
Computer
Human
(Taxonomy developer responsibility)
(IT responsibility)
DEFINITION
Role = label/APRALabel
Client Reference
<custid>
Role = label/busDefinition
imports
Role = label/Standard
This is the unique identifier
used within the agency
system that receives the
data
Party Identifiers Customer
Identifier
REPORTING
<custid>
Role = label/rptLabel
Super Fund Number
The Reporting Taxonomy inherits linkbases from the Definitional Taxonomy.
Additional metadata specific to the report can be introduced at the Report Taxonomy level. From
the users’ perspective, all the metadata is available for use.
Users of the taxonomy can decide which labels they want displayed when viewing the taxonomy, or
instances created from it. The taxonomy author can define one of the labels as a ‘preferred label’
so that XBRL-aware software will default to this one if users express no preference.
Australian Prudential Regulation Authority
7
Adopting Standard Business Reporting
Taxonomy design principles for reporting entities
Labels
Language
XBRL allows for any number of labels in any number of languages to be applied to a data element.
APRA has restricted its labels to English only, i.e. lang=‘en’.
APRA has created labels for each data element according to the following table:
Taxonomy
LabelType
Example
Source
SBR
Definition
Standard
Electronic Contact Electronic
Mail Address Text
Modified AGIMO
BRM
SBR Mandatory
Definition
busDefinition
Denotes the address of an
electronic mail service.
APRA form
instructions
(common) and
prudential
standards
SBR Mandatory
APRA Mandatory
Definition
busGuidance
A choice of TRUE/FALSE
values.
TRUE = Independent actuarial
advice has been
commissioned by the
reporting party during the
relevant period.
FALSE = Independent
actuarial advice has not been
commissioned by the
reporting party during the
relevant period
APRA forms
(specific)
SBR Optional
(Mandatory for
Boolean items or
items with a list
of allowable
values)
APRA Optional
(Mandatory for
Boolean items or
items with a list
of allowable
values)
Reporting
rptLabel
Email
APRA forms
(specific)
SBR Optional
APRA Mandatory
Reporting
rptGuidance
Provide the business email
address only. Do not use
personal email addresses –
e.g. Gmail
APRA form
instructions
(specific)
SBR Optional
APRA Optional
Definition taxonomy labels
Standard labels and business definition labels are attached to data elements in the Definitional
Taxonomy. They are generic in nature and are used to define a reporting taxonomy, in addition to
any labels at the report level.
Australian Prudential Regulation Authority
8
Adopting Standard Business Reporting
Taxonomy design principles for reporting entities
Standard label
SBR Definitional Taxonomy elements have a ‘standard label’ that uses the XBRL default label role
and the XBRL default extended linkrole (as defined by XBRL.org). The standard label format is
inherited from the SBR AU Taxonomy and assists users to navigate through the taxonomy and
discover unique data elements. It is constructed in the format:
Object Class [space] Property [space] Classword
Object classes are initially taken from the topic categorisations in APRA’s internal Data Dictionary
and are modified as appropriate. Modifications should ensure consistency with the SBR structures
(‘inspired by’ AGIMO’s Business Reference Model) and consistency of the hierarchy within APRA.
When APRA creates new object classes (subject areas), data elements to be classified within these
new classes must be documented and agreed before the object class is applied. Further, the
definition for an object class must be consistent with the definition of its parent class.
Property is an English language description of the element based on the form labels where the
element is used. The purpose of the property is to make the label unique; therefore it is the most
granular component of the label.
Classwords are taken from the SBR standard classwords.
Business definition
The shared understanding of an element can potentially be included in any of the following places
within the DTS (Discoverable Taxonomy Set – the set of files that hold the elements and all the
linkbases for the taxonomy):



as business definition and/or business guidance in the Label linkbase attached to the
Definitional Taxonomy; and/or
as report guidance in the Label linkbase attached to the Report Taxonomy; and/or
as a pointer to an authoritative document in the Reference linkbase attached to either the
Definition and/or the Report Taxonomies.
Note that the business definition is a mandatory requirement under the SBR architecture. Therefore
APRA includes all information regarding the shared understanding of a data element in the business
definition. This ensures all the information required to understand the element is in the one place.
role = http://sbr.gov.au/fdtn/sbr.01.02.tech/businessDefinition
APRA references authoritative documents (i.e. legislation, reporting standard) at a high level within
the business definition, e.g. ‘refer to the relevant Prudential Standards’. Subsequent changes to
these documents will therefore not affect the label linkbases. References will not refer to numbers
(standard, section or page) as these may change over time and result in a maintenance burden
going forward.
This label role is in the same extended linkrole as the standard label, i.e.
http://www.xbrl.org/2003/role/link
The text included in this label comprehensively describes APRA’s understanding of the element. A
user should not need to reference any other metadata to understand APRA’s requirements in regard
to a concept, i.e. no semantic meaning (at the whole of government definitional level) should be
contained in any other taxonomy artefact that is not contained in the Business Definition label.
Australian Prudential Regulation Authority
9
Adopting Standard Business Reporting
Taxonomy design principles for reporting entities
Business guidance
The business guidance label is used to provide additional information at the definitional level that
can be separated from the business definition label in order to keep the definition concise. Such
additional guidance may be a description of what to include or exclude, or examples or descriptions
of how the element is calculated, e.g.
Name
ProfitOrLoss.Unrealised.ChangeInCreditworthinessFairValueGainsNe
t.Amount
Business Definition
This is the net value, as at the relevant date, of any unrealised fair
value gains and (losses) arising from changes in the reporting
party's credit worthiness.
Business Guidance
A gain may arise, for example, from a reduction in fair value of the
reporting party's outstanding debt due to a change in credit rating.
A net gain must be reported as a positive figure and a net loss as a
negative figure.
The business guidance label is always used when an element is a Boolean type and provides a
definition of the true/false values, e.g.
Name
RegulatoryDisclosures.DefinedBenefitInterests.Indicator
Business Definition
This indicates whether the member has a defined benefit interest
or a defined benefit pension.
Business Guidance
A choice of TRUE/FALSE values.
true = The member has a defined benefit interest or a defined
benefit pension.
false = The member does not have a defined benefit interest or a
defined benefit pension.
The business guidance label is also used when an element is restricted to a defined set of values,
e.g.
Name
SuperannuationRegulatoryInformation.OperationalRiskFinancialRequ
irementHeld.Code
Business Definition
This indicates how the financial resources to meet the Operational
Risk Financial Requirement (ORFR) are held.
Business Guidance
The valid enumerated values are:
ORFR trustee capital = The trustee capital held for the purposes of
meeting the Operational Risk Financial Requirement (ORFR);
ORFR reserve = The reserve held for the purposes of meeting the
Operational Risk Financial Requirement (ORFR);
ORFR trustee capital and ORFR reserve = A combination of
Operational Risk Financial Requirement (ORFR) trustee capital and
at least one Operational Risk Financial Requirement (ORFR)
reserve.
Report taxonomy labels
Report level labels are specific to the form that is the subject of the Report Taxonomy and are in
addition to the labels made available from the Definitional Taxonomy.
Australian Prudential Regulation Authority
10
Adopting Standard Business Reporting
Taxonomy design principles for reporting entities
Report label
Report labels are attached to the Report Taxonomy for each form with:
role = http://sbr.gov.au/fdtn/sbr.01.02.tech/rprt/Label
APRA has no official default label for an element. Any change to a label for an element must be
made on each form on which the element appears.
XBRL allows for an ‘extended linkrole’ to be identified with each label so that multiple labels can
be applied to an element. The SBR convention is to name this with an identifier that is unique to
each report taxonomy.
For these reasons, APRA places all Report Taxonomy labels into an extended linkrole called:
http://sbr.gov.au/rpt/apra/formLabel
Report guidance
The report level label is used to provide the user with a close-as-possible representation of the
label on the physical D2A form.
The report level guidance is used to provide form, or report, level guidance to an existing concept.
Information should only be included as report guidance where it is not appropriate for inclusion
within the business definition, but is required to aid understanding. This will typically include
industry or form-specific language/jargon, additional instructions relating to the reporting of the
concept on a particular form, and any useful or necessary cross-form validations. Report guidance
must not add to the description, or definition, of the concept contained within the business
definition.
Dimension taxonomy labels
The SBR taxonomy provides a simple label for each domain member that typically repeats the
element name but with spaces between words.
APRA provides a label and guidance for each element in a dimension taxonomy.
All labels are placed in the default extended linkrole, http://www.xbrl.org/2003/role/link.
The labels have role = http://www.xbrl.org/2003/role/label, i.e. the same as the definitional
taxonomy standard labels and the same as SBR usage. The guidance have the standard XBRL
documentation role = http://www.xbrl.org/2003/role/documentation.
Australian Prudential Regulation Authority
11
Adopting Standard Business Reporting
Taxonomy design principles for reporting entities
Taxonomy design guidance
Concepts
Same concept – reported values are identical
Items with different D2A attributes are identical concepts when the same value is reported by the
same entity for the same period. This may occur when the instructions/guidance for each form
differ but the concepts requested are the same.
Same concept – different time period
When the same concept is reported as at two different time periods, the simple context period
should be used.
For example, retained earnings at the beginning of the reporting period vs. retained earnings
at the end of the reporting period.
Australian Prudential Regulation Authority
12
Adopting Standard Business Reporting
Taxonomy design principles for reporting entities
Dimensionality/Contextualisation
Criteria
Dimensions are used to provide contextualisation to an individual or group of concepts. A dimension
is generally applied to an element to slice and dice the data by geography or currency, for
example. There are two types of dimensions within the SBR taxonomy, Typed and Explicit
dimensions.
The extraction of semantics from the metadata of an individual reporting requirement should allow
for the broadened reuse of the resulting element. This process of extracting semantics should only
occur to the extent that the remaining element is a sensible, stand-alone concept. A reusable
dimension is one that can be applied to, and can provide appropriate semantics to, numerous
unrelated elements.
When to apply a dimension
When the decision of what part of an element’s metadata should be extracted and applied in the
form of a dimension, and what part should remain as the fully qualified element cannot be made
using the guidance above, the following considerations should guide the final design decision:

Do specific reporting requirements exist that suggest business analysis and/or comparison will
be undertaken based on a specific criterion embedded within the element’s metadata?
If so, the metadata that specifically relates to this criterion should be the part extracted and
applied in the form of a dimension.


If there is no suggestion that business analysis and/or comparison will be undertaken, as in the
previous point, the part of an element’s metadata that should be extracted and applied in the
form of a dimension is the part that potentially provides the greatest reuse.
If a dimension already exists within the SBR taxonomy that caters for the semantics being
considered for extraction, then contextualise accordingly to maintain semantic consistency
with SBR.
Segment vs. Scenario
XBRL contains two semantically different contexts for dimensions:
Segment Scenario -
for analysis of concepts by breaking them down into various ‘slices of the pie’,
e.g. wages by state or income by business unit; and
for comparison of concept values created under different sets of assumptions,
e.g. budget v actual, or last year’s estimate v this year’s estimate.
Australian Prudential Regulation Authority
13
Adopting Standard Business Reporting
Taxonomy design principles for reporting entities
SBR only allows the use of the ‘segment’ concept. The Dimensions specification does not allow for
the two different concepts to be used simultaneously within a single hypercube and this limitation
is accepted. The business requirement for dimensions based on the semantics of ‘scenario’ still
exists and are implemented within APRA as dimensions.
Balance attribute
All elements with a data type of ‘monetary’ must have a balance type defined to identify their
value as positive or negative. General accounting principles dictate the balance types as follows:


Debit: balances of Assets & Expenses; Decreases in Liabilities, Equity & Income
Credit: balances of Liabilities, Equity & Income; Decreases in Assets & Expenses
Net items (those elements that are the result of one concept being subtracted from another) should
be set according to the most likely, or intended, result for a going concern business. For example:


‘Net Profit’ could be positive (credit) or a loss (debit). A going concern business would
typically report a profit and so the element should be a credit.
‘Net Position of Derivative Contracts’ may alternate between an asset (debit) and liability
(credit), however the intended outcome is a debit balance.
Adjustments to elements have no ‘typical’ balance and so should have their balance type set to be
the same as that of the element that they are adjusting. In this way, any positive value assigned to
the adjustment will increase the element and any negative value will decrease the element (this is
consistent with natural business practice).
Off Balance Sheet items also have no ’natural’ balance type as they are rarely recorded using the
double entry book keeping method. However, they are typically related in some way to an ’on
balance sheet’ concept. For simplicity and consistency in application, where an on balance sheet
related concept can be identified, the balance type of the off balance sheet concept should be set
to the same value.
Period type - Instant/Duration
The period type conveys important metadata regarding the reporting requirements for an element.
The following defines the guiding principles on when to use the period type - instant, duration and
forever:
1.
Instant is the appropriate attribute when the data is “as at” a particular date or point in time,
e.g. items that would appear in a balance sheet.
2.
Duration is the appropriate attribute for aggregate data that sums, averages or otherwise
operates on values between two points in time, e.g. items that appear in a statement of profit
and loss.
3.
For concepts that do not fall neatly into the above two categories (e.g. name and address
details), the SBR approach is to assign a period type of ‘duration’ and the report guidance
label is used to instruct whether the data element needs to be reported as an ‘instant’. The
intent of this approach is to avoid the duplication of data elements within the SBR AU
Taxonomy where the only difference is the period type.
Australian Prudential Regulation Authority
14
Adopting Standard Business Reporting
Taxonomy design principles for reporting entities
4.
The forever attribute MUST only be used for data elements which have a fact value that is
always true, the example commonly used being the value of Pi. SBR has not utilised the
‘forever’ period type to date but this does not mean it cannot be used if a valid requirement is
identified.
5.
The business definition of a concept should provide sufficient clarity as to whether the concept
is an instant or a duration and the period type should not contradict the business definition.
6.
Concepts with a duration have two associated dates to reference the period start and period
end. In most instances this is the beginning of the reporting period and the end date of the
reporting period.
Attributes that have not been included in the taxonomy
Some attributes exist on forms that are redundant or nonsensical. It provides no benefit to draft
concepts for these and APRA may determine to disallow entities from mapping these to their data.
When such a decision is made, these attributes are not included in the taxonomy and are marked as
an unmapped attribute within the XBRL to D2A conversion. An example of such attributes are the
risk weights included within the reporting forms.
D2A form scenarios
Tuples
Tuples are used to group and provide contextualisation to a set of concepts that cannot be clearly
defined, or do not make sense, when left as standalone concepts. Tuples are typically used to
distinguish repeating rows in a table. Tuples are to be used only where contextualisation through
the use of dimensions is not appropriate.
Tuples are to be supplied with a Standard Label, Business Definition and Report Level Label.
Report consolidations as dimensions
Reporting consolidations that exist in the form header are modelled in the taxonomy as dimensions.
This enables a consistent method to distinguish the information on a particular form without using
the form code.
Australian Prudential Regulation Authority
15
Telephone
1300 55 88 49
Web site
www.apra.gov.au, linking to
http://www.apra.gov.au/CrossIndustry/Pages/SBR.aspx
Mail
GPO Box 9836
in all capital cities
(except Hobart and Darwin)
D2A_SBR_UTT_112013
Email
info@apra.gov.au
Download