Table of Contents

1 Abstract

Inline XBRL (iXBRL) enables a single document to provide both a preparer-driven human-readable presentation of a business report and structured, machine-readable XBRL data. The data format requirements for human-readability and automated machine consumption vary in some cases. This guidance explains how iXBRL features¹ address this gap. This guidance is primarily targeted towards software developers or anyone seeking a basic understanding of iXBRL tagging.

2 Introduction

Certain types of business report allow the report's preparer significant control over layout and presentation. For example, Figure 1 shows a number of different extracts from company financial reports. It can be seen that although the content of the reports is similar, the layout and presentation differ for each entity.

Figure 1: Sample extract of financial reports

An iXBRL report allows preparers to retain this fine-grained control over the presentation of their report. We refer to this human-readable view of the report as the "preparer's presentation".

An iXBRL report is a preparer's presentation of a business report with XBRL tagged data embedded in it. At a technical level an iXBRL report is an HTML ² document that can be viewed directly in a web browser. The XBRL data can be extracted using XBRL software for automated data consumption, or to provide interactive features when viewing the report.

A key feature of iXBRL is that there is a direct connection between figures and text in the preparer's presentation, and the values of the XBRL facts that are extracted from it. This connection is very powerful, allowing consumers to navigate between different views of the reported data, and to understand where values in derived, analytic reports are coming from. As described in the examples below, this direct connection can also create some challenges, as the facts and figures in the preparer's presentation report do not always match exactly the formats required for XBRL. iXBRL provides mechanisms for addressing this challenge, allowing the transformation of presented values. This document focuses on the transformations and other iXBRL tagging features that need to be applied in particular reporting situations. It does not go into detail of the other aspects of tagging a fact in iXBRL, such as specifying the concept, period or units.

2.1 iXBRL tagging details

This document shows the technical details required to tag examples that demonstrate specific iXBRL features. Although these may appear complex, it should be noted that these technical details should largely be taken care of by iXBRL software which should make provision of this information a very quick and efficient process.

Where the information in a report is generated from a source system, for example using "accounts preparation" software, the generation of iXBRL can be completely automated, with tagging information being provided either by the software, or as part of a one-off setup process.

3 Scaling numeric values

Numeric figures are often scaled in order to make them more readable. For example, Figure 2 and Figure 3 show monetary amounts presented in millions of pounds and thousands of dollars, respectively.

Figure 2: Extract of financial report presented in millions of pounds

Figure 3: Extract of financial report presented in thousands of dollar

When tagging numbers in iXBRL, it is necessary to specify the scale to which they are reported so that they can be transformed into the correct, unscaled value when XBRL data is extracted. The scale factor is expressed as a power of ten and denotes the amount by which the presented figure must be multiplied. Table 1 gives examples of the required scale factor for various reported numeric values.

It should be noted that the scale factor used in iXBRL is separate from the XBRL "accuracy" mechanism (expressed using "decimals" or "precision"). For example, the value "$12.34 million" is expressed in millions (a scale factor of "6"), but is accurate to the nearest $10,000 (which would be denoted by a decimals value of "-4")

Table 2 shows the complete set of iXBRL tagging information required for the 'Revenue' value highlighted in Figure 4.

Figure 4: Extract of Income Statement

The following terms are used in Table 2 and in other tagging examples in the guidance.

• iXBRL Tagged Value - This is the text chosen in the preparer's presentation for tagging.
• XBRL Transformed Value – This is the value of XBRL fact extracted from the tagged data in the iXBRL report
• iXBRL Attributes – These are additional attributes specified by the preparer, in order to achieve the correct transformation of the value.
• Dimensions – This section lists dimensions (XBRL aspects) applicable to the tagged value. They are included for completeness, and example values are used for Concept, Period, Identifier, and Scheme.

The tagging in Table 2 specifies a scale attribute to indicate the scale of the number.

4 Formatting Values

The values in a preparer's presentation, particularly those for numbers and dates, may not match the technical formats required for XBRL data. For example, a preparer might present a date as '28th February 2018" whereas XBRL requires the standard ISO format of 2018-02-28 to be used. To address this, iXBRL includes a set of transformation rules that transform commonly used formats, including regional variations, into the required technical formats.

The rules are maintained in a registry, known as the Transformation Rules Registry (TRR). The registry is updated periodically by XBRL International in order to support additional formats. Specific transformations are discussed in more detail in the following sections.

4.1 Number formats

Numbers are typically presented according to regional conventions, which may include using different characters for the decimal separator, and different conventions for grouping digits to aid the readability of large numbers.

Table 3 shows common variations for representing the same number.

In some cases, the same representation would be understood differently under these differing conventions. For example, the number 12,001 could be understood as either twelve thousand and one or twelve and one thousandth. In order to avoid misinterpretation when extracting data from a report, iXBRL requires the format of a number to be stated explicitly.

A number represented as ‘28,813,396.08' in the iXBRL report would use the numdotdecimal format from the registry. This format indicates that a "dot" is used as decimal separators and comma or space is allowed as an optional thousands separator.

Another commonly used number format is numcommadecimal which indicates that a "comma" is used as the decimal separator and dot or space can be used as an optional thousands separator.

Table 4 lists the transforms formats used in iXBRL for the number variations shown in Table 3.

The registry also has transformationss for numbers with units expressed as words, such as 10 euro 5 cent.

The iXBRL tagging required for the highlighted 'Revenue' value in Figure 5 is shown in Table 5.

Figure 5: Extract of Income Statement

4.2 Date formats

The formats used to represent dates vary even more widely than those used for numbers. Table 6 gives a few examples of different representations of the same date.

XBRL uses the ISO 8601 format of "YYYY-MM-DD". As this format is not commonly used in human-readable reports, dates will typically require transformation, using one of the formats in the registry. For example, a date represented as '31-Dec-16' in an iXBRL report would use the datedaymonthyearen format. This indicates that the date components are in the order day, month, then year, with the month name being given in English. This enables a processor to correctly and unambiguously understand the date.

The registry also provides transformations for partial dates, such as those that specify only a day and a month. For example, a date such as "1st February" can be transformed using the datedaymonthen transformation. It should be noted that these transformations can only be used where the XBRL concept being tagged requires a partial date; they cannot be used to transform a partial date into a complete date. Table 7 list the transforms formats used in iXBRL for date variations discussed in Table 6. The date transforms listed here accepts any non-numerical character (e.g. dot, space or dash) as date separators.

The table above does not provide an exhaustive list of date transforms available in the registry. The registry also has transforms for regional variants, including Japanese, Chinese and Korean dates.

The iXBRL tagging required for the highlighted Date in Figure 6 is shown in Table 8.

Figure 6: Extract from Balance Sheet

4.3 Dash Format

Some reports use the convention of presenting zero values as '–'(dash). Figure 7 gives an extract of a Balance Sheet in which the figure for 'Goodwill' is stated as '–', indicating a zero value. In XBRL the number has to represented as '0' (zero).

iXBRL provides a transformation (numdash) which converts dashes into a zero value. This dash transformation in iXBRL can be used for a number of dash variants such as hyphen-minus (-), en dash (–), em dash (—) and small hyphen-minus (﹣).

Figure 7: Extract of a Balance Sheet

The iXBRL tagging required for the highlighted 'Dash' text in Figure 7 is shown in Table 9.

4.4 Tagging Boolean values

XBRL taxonomies may include Boolean (or "true/false") concepts. Such concepts may be used to indicate that specific, legally-required statements have been included in the report.

For example, Figure 8 shows an example from a set of UK accounts of a legally required statement regarding the preparation of the Directors' Remuneration Report.

Figure 8: Extract of a legally required declaration

This is modelled in the taxonomy as a Boolean concept; a simple true/false value is used to indicate whether this statement has been included in the report.In order to create a link between the statement made in the preparer's presentation and the value tagged as XBRL data, iXBRL provides transforms for converting any block of text into a "true" or "false" value. The above text would be tagged using the ixt:booleantrue transform, resulting in a "true" value in the XBRL data.

The iXBRL tagging required for the text in Figure 8 is shown in Table 10.

5 Sign

As discussed in separate guidance on positive and negative values in XBRL, the sign conventions used to present numbers by preparers do not always match the approach required by XBRL. iXBRL provides mechanisms to indicate the correct signs to be used while extracting data in XBRL.

Figure 9 gives an extract of an income statement from a financial report.

Figure 9: Extract of Income Statement from a financial report

The numeric value for 'Cost of sales' is presented as a negative value (i.e. in brackets) to show that 'Cost of sales' is subtracted from 'Revenue' to calculate 'Gross Profit'. The taxonomy definition of a 'Cost of sales' concept would typically require this to be reported as a positive value. iXBRL provides a mechanism, known as the sign attribute, to control the sign of the value in XBRL.

Values in iXBRL will be transformed into positive values in the XBRL unless the sign attribute is specified, regardless of how they are presented. In this case, a positive value for "Cost of sales" is required and so the sign attribute is omitted.

The numeric value for 'Profit/(Loss) for financial year' is presented as a negative amount as it represents a loss. This is the same sign convention as used by a "Profit (Loss)" concept in XBRL. In this case, the sign attribute is required, in order to create a negative value in the XBRL.

The iXBRL tagging required for tagging the "Cost of Sales" value in Figure 9 is shown in Table 11. No additional attributes are required to obtain a positive value in the XBRL even though the value is presented in the iXBRL report in parentheses. The value selected for tagging in the preparer's presentation does not include the parentheses.

The iXBRL tagging required for for the "(Loss)/profit for the financial year" value in Figure 9 is shown in Table 12. The tagging specifies an additional sign attribute to indicate the value should be transformed to a negative value in the XBRL. The value selected for tagging in the preparer's presentation does not include the parentheses.

6 Textual data

When tagging textual information from a preparer's presentation, it may be that the text does not form a single, continuous block. For example, Figure 10 shows an extract of an inventory policy. Here the preparer may not want to include the highlighted text when tagging the paragraph as "Inventories Policy".

iXBRL provides two mechanisms, known as "continuation" and "exclude", which can be used to construct a single text tag from separate sections of a document. The "continuation" feature allows multiple, non-contiguous sections of text to be combined into a single tag. The "exclude" feature allows a subsection of a piece of text to be removed from the tag. Which feature is more appropriate in a given situation will depend on the technical structure of the underlying XHTML document, and the choice between them should typically be taken care of by iXBRL tagging software.

Figure 10: Sample Textual Disclosure

6.1 Continuation

iXBRL tagging using the "continuation" mechanism for tagging the "Inventory Policy" in Figure 10 is shown in Table 13 and Table 14. The required text to be tagged is split into separate tags and then connected by the continuation attribute. The XBRL transformed value concatenates all connected text. Table 13 specifies the tagging for the first part of text, indicating that the text to be transformed will be continued at a different tag using the "Continued At" attribute.

Table 14 specifies the tagging for the next part of text. The tag is given an ID attribute of 'InventoryPolicy2', which matches with the 'continued at' attribute value specified in the Table 13.

It should be noted that no dimensions (XBRL aspects) are specified for the second part of the split text, as these are all shared with the tag for the first part of the text.

It is possible to use a "continued at" attribute on a tag which is itself a continuation, allowing the text content to be constructed from as many parts as required.

In the example above, the link between the sections of the text is established by reference to the ID attribute on the continuation tag. All tags in an iXBRL report can have an ID attribute. It is recommended that all iXBRL tags have an ID attribute, but this has been omitted from other examples in this document for clarity.

6.2 Exclude

iXBRL tagging using the "exclude" mechanism for tagging the "Inventory Policy" in Figure 10 is shown in Table 15. The entire paragraph is tagged, and the subsections to be removed are additionally tagged using an "exclude" tag. The XBRL transformed value excludes this text.

Table 15 shows the tagging of the entire "Inventory Policy" from Figure 10. It should be noted that the tagged iXBRL value also contains the text to be excluded. This is shown as strike through text. The text to be excluded is additionally tagged using an "exclude tag". It should be noted no dimensions are specified for the exclude tag.

7 Relationships - facts and footnotes

A preparer's presentation will often contain cross-references between sections of a report in the form of footnotes. Such cross-references typically provide more detailed information about a particular disclosure. In order to capture the link between such sections in the XBRL data, iXBRL provides the "relationship" feature which can be used to create XBRL footnotes.

Figure 11 shows an extract of a financial disclosure for "Trade and Other Payables". The breakdown of the "Accruals and deferred income" value is disclosed as a footnote. The cross linking of the footnote (31 March 2015 amount includes accruals of £161 million and deferred income of £123 million) with the fact (284) is achieved with the help of numbered footnotes in the report.

In iXBRL the 'relationship' construct creates a link between the fact ("284") and the footnote ("31 March 2015 amount includes…."). This relationship link created in the iXBRL is transformed to the XBRL report.

Figure 11: Sample of cross-referenced financial disclosure

The relationship construct of iXBRL can be used either to connect facts to text footnotes, or to create links between facts (known as XBRL "fact footnotes"). The relationship construct helps iXBRL software to provide navigation between the linked contents in the iXBRL report.

The iXBRL tagging required for constructing a fact to footnote relationship between the highlighted text and numbers in Figure 11 is shown in Tables 16a, 16 b and 16c.

The text required to be created as a footnote is tagged and identified as "Footnote1" as shown in Table 16a.

The fact to which the footnote needs to be attached is tagged and identified as "Fact1" as shown in Table 16b.

The separately tagged fact ("Fact1") and footnote ("Footnote1") are connected using a relationship, as shown in Table 16c. The relationship uses the standard arcrole for connecting facts with text footnotes.

8 Tags embedded within tagged blocks of text

In some reports, numeric figures or smaller text disclosures are embedded within a larger block of text. iXBRL provides mechanisms to tag subsections of text with different tags by allowing tags to be "nested". Figure 12 shows an extract of the content that needs to be tagged as a block of text for the concept "Acquisition of interests from non-controlling shareholders". Within the text content there is a highlighted numeric fact ("Aggregate fair value of goodwill acquired") which also requires separate tagging. In this case the numeric tag can be nested within the textual tag.

Figure 12: Sample of numeric value embedded in a textual disclosure

The iXBRL tagging for the embedded tags in Figure 12 is shown in Tables 17 and 18.

It should be noted that there are no special attributes required for embedded tags. Syntactically the tags are nested in the iXBRL document. This tagging example simply demonstrates that text and numbers embedded within tagged text can be tagged as separate facts. Table 17 shows the tagging of the entire text of block.

Table 18 shows the tagging of a numeric value within the already tagged block of text.

9 Multiple tags for a value

In a preparer's presentation, a single value may represent multiple facts, corresponding to different concepts or periods. In such cases the same piece of numeric data needs be tagged multiple times.

Figure 13 shows an extract of an Earnings Per Share (EPS) disclosure. The disclosure has reported a Basic EPS value of 1.60 and provided a footnote explaining that this is also the value of Diluted EPS. iXBRL allows the 1.60 value to be tagged multiple times in order to represent this additional information.

Figure 13: Extract of Earnings Per Share disclosure

The iXBRL tagging for the highlighted value in Figure 13 is shown in Tables 19 and 20.

It should be noted that there are no special attributes to indicate that there are multiple tags attached to the value. The multiple tagging is achieved by nesting tags in the iXBRL document. The same numeric figure is tagged twice in Table 19 and Table 20 using different concepts.

10 Hidden tags

A collector may require data which either does not exist in the preparer's presentation or which cannot be transformed into the required format using the available transformations. iXBRL facilitates reporting of such data using the hidden tags feature. This allows the inclusion of XBRL tags in the report without linking them to any value in the preparer's presentation.

For example, the collector may require the name of the software used to prepare the iXBRL document to be reported but such information is unlikely to be presented in the preparer's presentation. Hidden tags may be used to include such facts in XBRL reports.

It should be noted that the links between XBRL tags and the corresponding information in the preparer's presentation are an important feature of iXBRL, and as such the use of hidden tags should be minimised. The use of hidden tags is often restricted by filing rules.

10.1 Extensible enumerations

The extensible enumerations feature of XBRL allows the reporting of facts whose values are taken from an enumerated list of options defined in the taxonomy. The value reported in XBRL is the name of a taxonomy element. Preparers will typically include a piece of human readable text, rather than the technical element name required by XBRL, and it is not currently possible to obtain the required value via a transformation. In such cases, facts using extensible enumeration concepts can be tagged as hidden tags.

Figure 14 shows an extract describing the accounting standards used in the preparation of financial statements. In the taxonomy, the list of possible accounting standards could be represented as an extensible enumeration, with element names such as "eg:IFRS" and "eg:LocalGAAP". Clearly these element names do not appear in the report, and so it would be necessary to include this fact as a hidden tag.

Figure 14: Extract of accounting standard disclosure

The iXBRL tagging for the statement in Figure 14 is explained in Table 21. It should be noted that there is no text selected from the preparer's presentation.

11 Duplicate tagging

Preparers often include the same value multiple times in different sections of the report. Figure 15 and Figure 16 show a value for 'Profit' reported in both the Income Statement and the Statement of Comprehensive Income in an annual financial statement. Tagging both occurrences of this fact ensures that the values are consistent and allows consumers to use iXBRL software to navigate between these different occurrences and drill down into the details of the figure.

Figure 15: Extract of Income Statement from a financial report

Figure 16: Extract of Cash Flow Statement from a financial report

In some cases, a numeric fact may be reported multiple times with differing accuracy. For example, profit may be reported to the nearest thousand on the Income Statement of a report but only to the nearest million when included in the Director's Report. Provided that the accuracy of such facts is tagged correctly (using the XBRL precision or decimals feature) inclusion of all such occurrences should not create an issue, as the values will be consistent according to their stated accuracy.

In the case of repeated text facts, there is a possibility that there are inconsequential differences between the different occurrences, such as capitalisation, spacing or abbreviation. Such differences would result in multiple facts which could not be automatically deduplicated by XBRL software. In such cases, it is generally acceptable to leave additional occurrences of non-numeric (text) facts untagged although this will depend on any relevant filing rules.

For more information on this topic, see the working group note on handling duplicate facts in XBRL and iXBRL

12 Multiple documents

It is possible to generate one single XBRL output from multiple iXBRL HTML documents. The splitting of iXBRL report into multiple HTML documents, known as an iXBRL document set, may be required to manage the size of file or to logically divide the content of the report. For example, a combined XBRL output can be generated from two different iXBRL reports for financial statement and corporate governance. It is also possible to generate multiple XBRL reports from a single iXBRL document, but this feature is not in common use.

13 Conclusion

The guidance covers the most common iXBRL features required for creating iXBRL reports. The guidance explains how iXBRL addresses format mismatches and specific reporting presentation scenarios to extract structured data from a preparer's presentation. iXBRL's approach of embedding tags into the human-readable report enables a greater degree of interactivity when viewing reports, and simplifies the task of ensuring that human-readable and machine-readable data is consistent.