Understanding Taxonomies and Reports
- 1 XBRL Glossary
- 2 Presentation
- 3 Calculation
- 3.1 Weight
- 3.2 Decimals
- 3.3 Limitations
- 4 Understanding Labels and Periods
- 4.1 Language
- 4.2 Preferred Labels
- 4.3 Periods
- 5 Formats
- 6 Dimensions
XBRL Glossary
Many terms used in this article have a very specific meaning in XBRL. If you are unsure about the meaning of a term mentioned here, please look into the official XBRL Glossary.
Presentation
XBRL taxonomies are built from several linkbases, each serving a different purpose. The presentation linkbase can be used to clarify the meaning of XBRL concepts in the context of that taxonomy. In the ESEF taxonomy, the Goodwill concept, for example, can be found in the Assets sub concept of the Statement of financial position, as showed in the image below.
Presentation linkbases have three different item types that matter for structuring:
Role: this term can be interpreted as “folders”, which "should distinguish between resources based on the nature of the information that they contain" (XBRL Specification), i.e. the different financial statements of a report.
Abstract concept: "present groups of Concepts" (XBRL Specification), i.e. the Assets group in the example given above.
Concept: "a definition of a kind of fact that can be reported about the activities or nature of a business activity." (XBRL Specification), i.e. an IFRS concept that can be tagged to the report.
The presentation of the ESEF taxonomy has been created by ESMA with the purpose of giving a clear and structured view over the concepts available in the taxonomy, so most users have an easy time looking for items. This does not mean that taxonomies created by companies together with the ESEF report need to follow this structure. In the reporting manual, ESMA states that "The presentation linkbase shall mirror the content and structure of the human-readable layer of the issuer’s report." (ESEF Guidance 3.4.6). This means that you are not obliged to change your report to fit the structure of ESMA's presentation, but rather have to create your own presentation based on your existing annual report.
The Tagger supports you in this requirement and automatically creates a presentation linkbase that resembles your annual report. It creates a role for each financial statement in the report and adds the mandatory abstract concept to this role. You can create additional layers of abstract groups by using the abstract hierarchy functionality of the Tagger.
If you just look at the human readable part of your iXBRL/ESEF report you might be wondering why this matters at all. It is still the same structure the report had at its creation. While that view might be prefered by some, XBRL enables analysts and investors to have a look at the report that is not impacted by graphical tricks and elegance. By opening different reports with the same XBRL software, they can get an overview of all the informations that are interesting.
The presentation of a taxonomy may be interpreted and displayed in different ways. The most common way is the tree structure, as seen in the taxonomy viewer in the Tagger (see screenshot above). If the actual report is opened together with the taxonomy, users will also see the values for each concept and period:
The same information can also be displayed in a more table-like fashion:
Even if softwares can display this information in a different way, you can be sure that softwares which are certified by XBRL international stick to the general structure of the presentation created with the report.
Calculation
ESEF compliant XBRL extension taxonomies must have a calculation linkbase (ESEF Guidance 3.1.1). Calculation links can be used to further clarify the meaning of concepts in the context of the report. Calculations are not intended as validations, they are defined by relationships between concepts. The Total of a calculation is the summation concept, while the Summands are included as contributing concepts. Like all linkbases in XBRL, these relationships can be visualized as a tree. In the example from the ESEF taxonomy below, you can see how the Profit (Loss) concept can be used in a calculation linkbase.
Weight
All the contributing concepts can be grouped up to the value of the summation concept. In an ideal case, these values are equal. As seen above, one concept can be both a contributing and a summation concept at the same time. The plus and minus icons indicate that the value of the concept is either to be added or subtracted to/from the total. In XBRL, this is called weight. This weight cannot be freely chosen, but has constraints defined in the XBRL specification:
Summation concept balance type | Contributing concept balance type | allowed weight |
|---|---|---|
|
| 1 |
|
| -1 |
|
| -1 |
|
| 1 |
The Tagger sets the weights automatically. Weights can only be adjusted manually, if the summation concept has the balance type Unknown, or each contributing concept with the balance type Unknown has a relationship.
Values can be adjusted by changing the Sign Logic property of items. Please visit https://amana.atlassian.net/wiki/spaces/XBRLD/pages/32212340/Tagging+of+Tables#Sign-Logic-(Reporting-of-Negative-Values) for more details.
Decimals
The total of a binding calculation is defined as the sum of the rounded values of the contributing Numeric Items in the binding, each multiplied by the value of the @weight attribute. (XBRL Specification)
Since most values in an annual report are rounded values, rounding errors may occur. To weaken that fact in calculations, the decimals attribute can be used on items. This attribute "specifies the number of decimal places to which the value of the fact represented may be considered accurate, possibly as a result of rounding or truncation." (XBRL Specification). A decimal value of 2 indicates that the value is correct to 2 decimal places. This is mostly used for percentage items. A decimal value of -2 on the other hand indicates that the value is accurate in the hundreds. Negative decimals values move the accuracy of values to the left, positive values to the right. The Tagger automatically sets decimal values based on the scale property of a value, meaning that values displayed in thousands have a default decimal value of -3. The decimal value of -3 is accepted by most auditors.
Decimals are used to infer the correctness of calculation relationships, as seen in the following example:
In this table, the default decimals are used. The original values are from a consolidation system, the rounded values are displayed in thousands in the actual annual report. With decimals set to -3 for all values, the calculated value of the total would be 8.001.000 and thus different to the 8.000.000 value in the report:
| Original value | Rounded value | Decimals | Calculated value |
|---|---|---|---|---|
Value 1 | 3.000.503 | 3.001 | -3 | 3.001.000 |
Value 2 | 4.999.601 | 5.000 | -3 | 5.000.000 |
Total | 8.000.104 | 8.000 | -3 | 8.000.000 |
This can be adjusted by changing the decimals attribute of one values:
| Original value | Rounded value | Decimals | Calculated value |
|---|---|---|---|---|
Value 1 | 3.000.503 | 3.001 | -4 | 3.000.000 |
Value 2 | 4.999.601 | 5.000 | -3 | 5.000.000 |
Total | 8.000.104 | 8.000 | -3 | 8.000.000 |
Limitations
XBRL 2.1 specification grants the possibility to document in the calculation linkbase arithmetic relationships between elements referring to the same context, i.e. same period and identical dimensional qualifiers. Therefore, the calculation linkbase is limited to calculations with a single context.
However, the Primary Financial Statements contain a number of cross-period arithmetic relationships that can not be reflected in the calculation linkbase. An example for cross-period arithmetic relationships is the statement of cash flows where the sum of inflows and outflows of the period corresponds to the change of the cash balance from the beginning of the period to the end of the period. Another example is the statement of changes in equity that contains reconciliations between the carrying amount at the beginning and the end of the period for each component of equity.
(ESEF Guidance 3.4.1)
While it may feel natural to create calculation relationships of the type Start Balance + Change during period = End balance, this is, as stated above, not possible due to the XBRL specification. Calculations are only possible for items with the same period type (duration or instant) in the same period. The equity table is an example for an exception of this.
The ESEF guidance does not specify the amount of calculations that are necessary for a valid report. It is only stated that a calculation linkbase is part of the extension taxonomy, thus mandating at least one calculation relationship. Invalid calculation relationships are furthermore just considered warnings and should not be the reason for a report to be rejected by any authority.
Understanding Labels and Periods
The Label linkbase is part of most XBRL taxonomies. Concepts from XBRL taxonomies are usually defined with a technical name, e.g. CostOfSales or Goodwill, which is language independent and has to follow certain rules regarding the allowed characters. Labels can be assigned to these concepts and enable additional human-readable information.
Labels can be defined with a role and a language. In the example below you can see the labels existing in the ESEF taxonomy for the Goodwill concept from the IFRS taxonomy. Not all roles are yet translated to all languages, due to the fact that the English labels are provided by the IFRS Foundation, while the translations to other European languages is done by ESMA.
Different roles do serve different purposes. For a detailed overview please check the XBRL specification. The most relevant for ESEF are the following:
Role | Meaning |
|---|---|
Standard | The default label for a concept |
PeriodStart | Used for concepts with the Instant period type presenting values at the start of a period, e.g. "Equity at beginning of period" for the Equity concept |
PeriodEnd | Used for concepts with the Instant period type presenting values at the end of a period, e.g. "Equity at end of period" for the Equity concept |
Documentation | Used to supply further more detailed information about a concept, e.g. when its usage is appropriate. |
Total | Used when presenting total values, e.g. "Total Assets" for the Assets concept |
Language
When creating the XBRL taxonomy extension for your annual report, the used labels should reflect the wording in your annual report. Therefore, the Tagger automatically uses the row label of a tagged element as the standard label in the defined reporting language. This way, when looking at your XBRL reports presentation view, not only the order but also the labels will be the same as in your XHTML version of the annual report. The company specific labels do not overwrite existing labels from the taxonomy. Viewers may still choose to display the labels from the original ESMA taxonomy to allow for a simplified view between different reports. They may also choose the language that suits them best. If your extended taxonomy does not contain labels for a particular language, the default labels from the ESMA taxonomy, if avaidable, will be displayed.
The Tagger allows to add additional labels in languages different from the language of the report, as seen at the Additional labels property of an element.
Preferred Labels
Some concepts might appear multiple times in the presentation linkbase, for example indicating a value at the beginning of a period and a value at the end of a period for the same concept. Another example would be Equity being shown for several product segments in addition to a Total Equity over all segments. To clarify these cases in the XBRL presentation of a report, Preferred Label Roles should be used. The Equity concept has several labels in different roles in the ESEF taxonomy. The presentation linkbase of the ESEF taxonomy also makes use of the preferred label role in the example below:
The first occurrence of the Equity concept uses the PeriodStart label, while the second occurrence of the same concept uses the PeriodEnd label. This clarifies that there is a change of that particular value during the reporting period.
The Preferred Label Role for a concept can be set in the details of the mapping to achieve a similar outcome in the company specific taxonomy.
Periods
A XBRL concept itself has generally no reference to any period, it only has a period type. The period type defines what type of period can be assigned to a fact.
Name | Description | Values |
|---|---|---|
instant | Specific point in time, e.g. beginning or end of a period. | instant |
duration | A duration for which the elements value is reported, from start to end date. | startDate and endDate |
The tagger automatically deduces the time period from the information in the report, if this is possible. There is no separate field for the instant date. If a concept has the period type instant, only the value from the "Instant/End Date" field will be used. If a concept has the period type duration, the "Period Start Date" value will be used as the start of the period and the "Instant/End Date" value as the end of the period.
The items Cash and Cash equivaltens at the begining of the period and Cash and Cash equivaltens at the end of the period are tagged with the same tag, ifrs-full:CashAndCashEquivalents, but the values at the begining and the end of the period are different. As the values are different this will create a duplicate mapping error. To avoid this error the periods have to be adjusted, so the tags are unique.
The period start value should have the date of the end of the previous period, e.g. January 1, 2021 has the date 31.12.2020. The label of this element is period start.
The period end date should have the date of the end of the current period, e.g. December 31, 2021 has the date 31.12.2021. The label of this element is period end.
Formats
Data types in XBRL only allow very specific formats for their values. As XBRL and ESEF are used in many different countries with different date and number formats, mandating a change for all annual reports to use a single format is neither practicable nor desired. Numbers and dates in iXBRL reports will always use the formats of the language they are published in. To make it easier to compare and aggregate data from multiple countries it is necessary to transform these formats into one single format for each data type which can be processed. For this purpose XBRL International is publishing an ever-improving https://www.xbrl.org/Specification/inlineXBRL-transformationRegistry/REC-2020-02-12/inlineXBRL-transformationRegistry-REC-2020-02-12.html . This registry describes transformation rules that can be applied to numbers and dates in a report. The numbers and dates can be transformed into a format that is compatible with plain XBRL data types.
For ESEF "ESMA recommends applying the Transformation Rules Registry 4" (ESEF Guidance 2.2.3) has simplified the available transformations for numbers, that should be used in comparison to prior versions. Basically the reprocessor has to choose between four different formats:
Name | Description | Example(s) |
|---|---|---|
fixed-zero | Can be applied to any value, always transforms to 0 | "-" | "N/A" |
num-comma-decimal | Any number with a comma fraction separator | 2.300,23 | 2 300,23 | 2'300,23 |
num-dot-decimal | Any number with a dot fraction separator | 2,300.23 | 2 300.23 | 2'300.23 |
num-unit-decimal | Any number that contains a unit string | 12 Euro 43 Cent |
Any number that is tagged with a format, has to satisfy the constraints of that format. A value with "-" can not have a format starting with "num-", because the transformation rule does not apply.
The Tagger automatically assigns a format for each number that can be applied to a transformation rule, depending on the Transformation Registry version set in the document settings. Most of the times this format is correct, but in some cases a manual change might be necessary.
Dimensions
While in XBRL the declaration of a reporting entity and the period also count as dimensions of a reported value, this section focuses on dimensions as described in the XBRL Dimensions specification.
This allows the definition of a table (also called hypercube) with a set of axes (also called dimensions) which have different members (or characteristics). A table can have one or more axes with different members.
The most common example can be found in the Statement of changes in equity:
Besides the line items this table has two axes that can be used: "Components of equity" and "Retrospective application and retrospective restatement". Each axis defines a hierarchy of members, where the first one usually is the default member.
If the default member should not be inferred for a fact that is part of a table, the desired dimension member has to be tagged explicitly.
It is possible and allowed to create extended axes and members. For example an additional member can be added to the Components of Equity axis if none of the members available in the taxonomy serve the purpose. It is also possible to create a whole new axis with members. In that case it is mandatory to assign a default member for that axis. Please refer to this section of the manual on how to do this in the Tagger.
The presentation linkbase structure from above could in combination with values from a report be displayed in a table layout shown below: