Additional information for the Digital Information Reporting developer
When augmenting a compliant XBRL processor to support the Digital Financial Reporting (DFR) advocated by Charles Hoffman there are at least three distinct components:
-
Validating the structure of the taxonomy which has two components:
-
- Checking the model structure rules; and
-
- Validating the consistency of the concepts in presentation, definition and calculation linkbases
-
Identifying and categorizing the blocks or fact sets described by a presentation linkbase
There is lots of information about these processes among the information provided and while important to understand, much of it is qualitative in nature not in the form of a comprehensive unambiguous normative specification a developer will expect. It is not the purpose of this document to provide a specification but instead to provide additional information that tries to make it possible for a developer to interpret the information available in a way that is unambiguous. It is also the purpose of this document to point to the resources that are relevant to developers. The information in this document is based on my experience of successfully supporting the three components listed above.
It is assumed the developer has a good knowledge of the XBRL 2.1, Dimensions 1.0 and Formula specifications. As well as needing to be able to extract information from XBRL presentationLink, definitionLink and calculationLink elements in linkbase files, it is also necessary to be able to extract information from generic:link elements in linkbase files that describe formulas. Finally, it is highly desirable to be able to evaluate XBRL Formulas in the context of an instance document.
Much of the information about DFR is about the abstract concept of reporting and it deliberately avoids technology except in a few places (see the Useful Resources below). I think the idea is that in principle the DFR could be implemented using any schema/storage technology, that XBRL is just one example.
However, if XBRL is to be the schema/storage choice then as a developer it is critical that how these ideas are implemented using XBRL is explained and unambiguous.
The first thing to appreciate is that almost all the available information, when applied to XBRL, is about presentation linkbases. Throughout the DFR information there are terms used like hypercubes (or tables), dimensions (or axes), members, line items (or primary items) . These are terms from the XBRL Dimension specification. But it is really important to realise that in the context of using XBRL to represent a DFR these terms are being used about presentation linkbases.
Take this graphic which appears in several of the documents about DFR:
Figure 1
You could be forgiven for thinking this is referring to restrictions to be applied to some definitions linkbase that follows the XBRL Dimensions specification. But no, this is about restrictions that apply when these concepts are used in a presentation linkbase.
This is because in a DFR, these 'dimensions' concepts are explicitly used in presentation linkbases. Hypercubes, Dimensions, Members and Line Items are still defined in definition linkbases following the XBRL Dimensions specification but they are explicitly added to presentation linkbase as well. Here is an example:
Figure 2
These are screenshots of different views of the same network (networks? see below) in the same taxonomy. You can see in the definition view this is where the hypercube, dimensions, members and line items are defined. But note that the exact same concepts with the exact same relationships also appear in the presentation view.
Their existence in the presentation view is not to define them but to make it clear how fact information should be presented to a report consumer.
So there are two takeaways from this section:
- that when a DFR is implemented in XBRL, the focus is on how concepts are used and constrained in presentation linkbases; and
- that the concepts and their relationships should be identical in both presentation and definition linkbases.
Note that this does NOT mean that the layout of concepts under line items must be the same across presentation and definition extended links, just that the same concepts should exist in both extended link types.
You can see this arrangement implemented in almost all of the conformance test cases as well as the IPSAS and XASB example taxonomies (see 'Useful Resources' below). The only test cases that do not follow this pattern are those used to test that an implementation is able to identify those which do not follow this pattern (see tests 03, 04 and 05 of the 3000 series test cases).
There is nothing in any of the XBRL specification that requires an extended link in one linkbase (say, presentation) to have anything to do with an extended link in another linkbase (say, definition) even if they use the same extended link role (ELR).
In a Digital Financial Report, extended links in one linkbase are related to an extended link in another linkbase if they share the same ELR. You can see this in action in figure 2 above where all the views share an extended link role with a description of '30000 – Property, Plant and Equipment, By Component'.
These extended links, ones that are associated by their common ELR, are known as networks.
Note that concepts only need to be the same between extended links with the same ELR.
As shown in Figure 2, the concepts MUST be the same across extended links in presentation and definition linkbases that share the same ELR. Figure 2 also shows a view of the calculation linkbase. You can see this view shows the calculation linkbase also shares the same ELR and the same concepts.
However, calculations are a special case as not all concepts in the presentation and definition extended links need also to be in the corresponding calculation extended links.
Concepts in a presentation linkbase extended link are grouped into one or more 'fact sets' (see Understanding and Leveraging Fact Sets in Useful resources below). One of the fact set types is 'rollup' and it is only concepts in rollup fact sets that MUST also exist in calculation relationships within an extended link in a calculation linkbase. To be clear, concepts in other fact set types do not need to appear in a calculation extended link.
This requirement makes it important that a DFR validator is able to distinguish between the types of fact set and how to identify fact sets and their types is the subject of the following sections.
The need to correctly identify different types of element is critically important when validating a DFR and a precursor to correctly identifying the types of fact set in a presentation network and to checking model structure rules.
Most of the information listed here is available in one or other documents listed in the 'Useful resources' section but is brought together here for convenience.
Primary Item
A primary item is defined in the XBRL Dimensions 1.0 specification as an element defined in XBRL taxonomies that is in the xbrli:item substitution group but not in the xbrldt:hypercubeItem or xbrldt:dimensionItem substitution group.
This definition is needed to identify line item, concept and abstract types.
Hypercube (Table)
Concepts of this type can be identified because they are in the @substitutionGroup of xbrldt:hypercubeItem. The concept MUST be abstract and have a @periodType of 'duration'.
The arcrole in the arc from a primary item label to hypercube label MUST NOT be http://xbrl.org/int/dim/arcrole/notAll.
There MUST be only one hypercube per network.
In some DFR documents the combination of a hypercube within a network is called a 'component'.
Dimension (Axis)
Concepts of this type can be identified because they are in the @substitutionGroup of xbrldt:dimensionItem. The concept MUST be abstract and have a @periodType of 'duration'.
Member
Concepts of this type can be identified because their @type will be nonnum:domainItemType. The concept MUST be abstract and have @periodType of 'duration'.
Line item
This type can be identified because it is a primary item that is also abstract. In practice, because of the equivalence of presentation and definition network elements, this type also has a 'hasAll' (arcrole http://xbrl.org/int/dim/arcrole/all) relationship with a hypercube element.
There MUST be only one line items element type in each network.
Concept
This type can be identified because it is a primary item that is NOT abstract. In practice, because of the equivalence of presentation and definition network elements, this type has either a direct or indirect 'domain-member (arcrole http://xbrl.org/int/dim/arcrole/domain-member) relationship with a line item element. An indirect relationship is one in which an ancestor node has a domain-member relationship with the line item element.
Abstract
This type can be identified because it is a primary item that is abstract and because of the equivalence of presentation and definition network elements, this type has either a direct or indirect 'domain-member (arcrole http://xbrl.org/int/dim/arcrole/domain-member) relationship with a line item element. An indirect relationship is one in which an ancestor node has a domain-member relationship with the line item element.
With the ability to correctly identify the types of element, it becomes possible to identify the fact sets and identify each one. It is necessary to identify fact sets, and in particular rollup type fact sets, so the correct concepts can be validated between presentation and calculation extended links.
Because of the constraints shown in Figure 1 ALL fact sets are children of either a line item element or an abstract element. This also means that facts within fact sets are comprised only of concept or abstract element types and that abstract types are used only as headers used to organize concepts.
Definitions and accompanying examples of the different type of fact sets can be seen in section 1.3 of Intelligent Digital Financial Reporting – Part 2 (see Useful resources below).
Rollup
If any concept which is a child of an abstract element is in the same network of a calculation linkbase then the parent and all its child elements are part of a rollup fact set.
Rollups can be nested inside each another to any depth
Figure 3
This might be rendered like this:
Figure 4
Roll forward
A roll forward fact set can be detected because:
(a) it always has in instant as the first and last concept in the presentation relations,
(b) the first instant has a periodStart @preferredLabel role;
(c) the second instant concept is the same as the first and has the periodEnd @preferredLabel role; and
(d) XBRL Formulas exists that represents the roll forward mathematical relations.
To categorize a fact set as roll forward it is necessary to be able to interrogate formulas in the same network to determine if any include a concept name filter that references any one of the concepts in the fact set.
Also see 'Matching segment aspect values' below.
Roll forward info
A roll forward info fact set looks like a roll forward, but is not really a roll forward.
While a roll forward reconciles the balance of a concept between two points in time, the roll forward info is really just a hierarchy or set which shows a beginning and ending balance. A roll forward info concept arrangement pattern is generally shown with a roll forward.
Roll forward info can be detected because:
(a) the first concept has a periodStart @preferredLabel;
(b) the last concept in the presentation relations has a periodEnd @preferredLabel.
Also see 'Matching segment aspect values' below.
Adjustment
For an adjustment concept arrangement pattern to be possible the network MUST include a dimension concept with a local name of 'ReportDateAxis'. In addition:
(a) the first concept is an instant and uses the http://xbrlsite.azurewebsites.net/2016/conceptual-model/cm-roles/roles/originallyStatedLabel @preferredLabel which can be found in ./conceptual-model/cm-roles.xsd; and
(b) the last concept is an instant and uses the http://www.xbrl.org/2006/role/restatedLabel @preferredLabel role.
Alias Concepts for 'Report Creation Date [Axis]' are 'us-gaap:CreationDateAxis' and 'ifrs-full:CreationDateAxis', 'frm:ReportDateAxis'
The originally stated and restated values will be represented by separate members of the ReportDateAxis dimension and there should be just two members. The member representing restated value ideally will be; the default member of the axis; and the single domain member of the axis; and the parent (has a domain-child relationship with) any other members. Failing having ALL these characteristics, then any one of them can be used to identify the member representing the restated value. Any other member will represent the originally stated value.
If there is no member that is default or domain or a parent, or both members are domain and neither is a parent of the other then the first member found in document order will be the member representing the restated value.
Variance
A variance is not so much an arrangement pattern as a metapattern as it can be applied to any other concept arrangement pattern. A fact set is a variance if:
- the network includes a dimension with a local name of 'ReportingScenarioAxis';
- the dimension has three members; and
- the members are organized to hierarchy with two members reporting to one of the others.
This allows an arrangement such as variance = actual – budget to be represented.
The members of the ReportingScenarioAxis dimension will be organized into a member arrangement rollup pattern. The member representing the 'total' value of the rollup will be one that is the target of a dimension-domain relationship and will the source of domain-child relationships with other members (root).
Grid
A grid is any fact set in a network that includes a dimension that is not one with a local name of 'LegalEntityAxis', 'ReportDateaxis' or 'ReportingScenarioAxis'.
Complex computation
Complex computation can be identified because:
- there are numeric relations and those relations do not follow any of the other mathematical patterns;
- there is an XBRL formula that represents a mathematical relation other than one of the other mathematical computation patterns.
To categorize a fact set as a complex arrangement pattern it is necessary to be able to interrogate formulas in the same network to determine if any include a concept name filter that references any one of the concepts in the fact set.
Text
Text block can always be identified by the @type used to represent the text block which will be: nonnum:textBlockItemType.
Set or Hierarchy
Any other arrangement is just a set, that is, a simple list of concepts.
When finding the correct prior period value for roll forward and roll forward info fact sets, the prior year value for a corresponding fact (for an opening balance) the algorithm MUST take into account any dimensional information. This means the segment of the context that contains aspects describing the prior year MUST have the same segment aspects as the context that is used to describe the current period. If the context used for the current period has dimension and member values dim:A/member:A and dim:B/member:B then the fact representing the prior year value MUST use a context that also has matching segment aspect value, that is, dim:A/member:A and dim:B/member:B.
A purpose of following the ideas of the DFR framework is so that a generated taxonomy can include additional information an XBRL processor can use to validate the taxonomy. Once such file of information is a model structure rules definition file. There are example files in both the IPSAS and XASB taxonomies.
These definition files use definition links and arcrole to specify the relationships in Figure 1 above. Again, this is for checking relationships of extended links in presentation linkbases.
The model structure rules definition file defines four arcroles. It is the arcs that use the 'allowedChildCategory' arcrole that are relevant to checking the relationships in each presentation extended link. Once a processor has successfully identified the elements types mentioned above, it is then a straight forward task to verify that their relationships comply with the model structure rules.
General Business Reporting XBRL Application Profile
Sections 2 and 3 provide some detail about the validation though the lists provided are not comprehensive.
Intelligent Digital Financial Reporting – Part 2: Conceptual Model Of A Digital Financial Report
This document describes 'Concept Arrangement Patterns' and section 1.3 of this document is useful because it gives examples of each pattern and information that can be used to identify them.
Understanding and Leveraging Fact Sets
Describes the concept of fact sets (sometimes also called blocks). Fact sets (as blocks) are also described by example in the document 'Intelligent Digital Financial Reporting' above.
XBRL-based Digital Financial Reporting Conformance Suite Tests
A link to a list of tests (that in turn link to example instance documents and taxonomies) that test compliance with specific features. The '2000' series examples are useful for testing a processor's ability to identify and categorize line item block types (see the Intelligent Digital Financial Reporting – Part 2 document for a list of them). The '3000' series tests provide examples that are erroneous is various ways.
XASB taxonomy and instance document example
This is a link to a significant taxonomy and instance document called XASB created using DFR ideas
Evidence package for the XASB taxonomy
Provides examples of the XASB taxonomy statements being rendered.
IPSAS taxonomy and instance document example
This is a link to another significant taxonomy and instance document called IPSAS created using DFR ideas
Evidence package for the IPSAS taxonomy
Provides examples of the XASB taxonomy statements being rendered.
Evidence package for US GAAP 'ABC' company
Provides examples of the US GAAP taxonomy statements being rendered for ABC company.
References all the evidence package information and other stuff for US GAAP, XASB, IPSA, and IFRS:
The main XBRL specification
Specification defines the use of dimensions
XBRL Formulas is a collection of specifications. This a link to an index of the specification.
Examples of all the fact set renderings based on the conformance suite