Table of Contents

1 Introduction

XBRL is an open international standard for digital business reporting. The standard allows the definition of meaning necessary to understand and validate machine-readable XBRL reports.

The XBRL standard was originally based on XML, as it was a natural choice for the syntax in the early 2000s. The standard has evolved over time and has developed a set of specifications that provide multiple, interoperable formats for representing digital reports to address different use cases.

The XBRL standard currently defines the following report formats:

1. xBRL-XML: The conventional XML format defined by the XBRL v2.1 specification.
2. Inline XBRL (iXBRL): A format for embedding XBRL tags within a human-readable, HTML document.
3. xBRL-JSON: A simple, JSON-based format for XBRL data.
4. xBRL-CSV: An efficient, CSV-based format, particularly well-suited for bulk data reporting.

Interoperability between the different formats is facilitated by the XBRL Open Information Model (OIM), a modernisation and simplification initiative which provides a syntax-independent definition of the content of an XBRL report.

Business reports can be represented in any the above formats, however each one is developed to address specific scenarios which is why it is necessary to find the right tool for the job. The formats are not mutually exclusive and data collectors can choose a mix of formats to suit different reporting requirements.

Data in all XBRL reports is backed by an XBRL taxonomy, which provides meaning for the facts in the report. The same taxonomy is used across all formats of XBRL report.

This document provides guidance to help users select the most appropriate format for a given reporting requirement. The guidance is targeted primarily towards data collectors and solution architects to help them identify the appropriate implementation choice but will be useful for anyone trying to get a basic understanding of different XBRL report formats.

2 Key factors impacting choice of format

2.1 Open or Closed Reporting Environment

One of the main factors which determines the choice of format is the characteristics of underlying reporting environment. Reporting environments can be classified as being "closed", where the set of data points that is to be reported is prescribed completely by the collector of the reports, or "open" where reporting requirements are expressed as a set of rules or principles, rather than a prescribed template. In an open report, the preparer has control over both the information that is reported, and how it is presented. The characteristics and differences between these environments are discussed in more detail in separate guidance on when to choose Inline XBRL.

2.2 Collecting or Publishing XBRL reports

XBRL is commonly used by data collectors such as tax authorities, securities market regulators and prudential regulators. In some environments, the reported data is private, and is used only by the data collector. In other environments, such as securities regulation or business registrars, the collected reports are published by the data collector, either as individual reports, or in aggregated form.

The different requirements of data collection and data publication may be better met by different XBRL report formats, and the interoperability between the different formats means that data collectors may choose to publish data in a different format to that in which it is collected.

2.3 Report size

The expected volume of data to be reported is a key factor to be considered to selecting an XBRL report format. The size of XBRL reports increases with the number of facts, however the size per fact is different across formats. For example, xBRL-CSV files are more size efficient than xBRL-XML. With large file size comes the challenges of file transmission, validation and consumption.

What constitutes a "large" report will depend on many factors, including the nature of the data and the computing hardware available to process it. An xBRL-XML report would typically have a size of between 100 and 1000 bytes per fact. At 500 bytes per fact, a 200,000 facts report would be 100MB in xBRL-XML By contrast, an xBRL-CSV report with a large number of numeric facts would typically be less than 10 bytes per fact, making a 200,000 fact report less than 2MB. Although XML reports much larger than 100MB can be processed successfully with suitable hardware, reports of this size would benefit from a more efficient representation such as xBRL-CSV.

3 Different Formats and Recommendations

3.1 xBRL-XML

xBRL-XML is the original, XML-based format for representing XBRL reports as defined in the base specifications (XBRL 2.1 and Dimension 1.0). The format leverages the strong validation capability offered by XML Schema. It enjoys a strong eco-system and community support. The format can be inefficient when working with large volumes of data owing to its verbose syntax and the need to parse the entire document in order to process a single fact.

3.2 Inline XBRL (iXBRL)

An Inline XBRL report is an XHTML document (a variant of HTML) with XBRL tags embedded in it. It can be viewed directly in a web browser and enables a single document to provide both tagged data and a human-readable report. The tagged data can be extracted using XBRL software for automated data consumption, or to provide interactive features when viewing the report. The extracted tagged data enjoys a strong validation capability as xBRL-XML.

Inline XBRL allows preparers to retain fine-grained control over the presentation of their report, which makes it suitable for open reporting. The format is quickly becoming the default choice for company financial reports, and other open reporting formats.

Figure 1 is an extract from an Inline XBRL report rendered using a viewer in a web browser. Explore the full sample in an interactive viewer on this link.

Figure 1: Extract from an iXBRL report

A separate guidance document on Inline XBRL features provides more details on the format.

3.3 xBRL-JSON

xBRL-JSON provides a simple representation of XBRL data in JSON format. The xBRL-JSON format closely follows the structure of the underlying Open Information Model, and JSON syntax is widely supported, lightweight, and very easy to work with in almost all programming languages. As such, xBRL-JSON is the ideal format for publishing XBRL data in a format that is easy for developers to work with. The format is intuitive and can be quickly understood by someone new to XBRL.

For regulators collecting XBRL data, publishing data in xBRL-JSON makes the data more readily accessible, and reduces the barrier to entry for consumers looking to take advantage of the collected, structured data. Note that where data is collected in Inline XBRL format, it is important that publication in xBRL-JSON is in addition to the original iXBRL, as the xBRL-JSON format contains only the raw data, and does not include the human-readable information in the report. As a relatively new standard, the tools market for xBRL-JSON is not as mature as for XBRL and iXBRL, but there are already a number of products that have been certified by XBRL International for the xBRL-JSON format. Detailed information about the format can be found in the xBRL-JSON tutorial.

3.4 xBRL-CSV

xBRL-CSV uses the widely supported CSV format, and has been optimised for the efficient reporting of very large datasets, particularly those consisting of many rows of repeating "records". The efficiency is achieved via a flexible, JSON-based metadata definition mechanism which allows the format of CSV tables to be tailored to the specific reporting requirements.

The metadata would typically be defined by the data collector, allowing preparers to focus on creation of CSV data tables.

As for xBRL-JSON, certified software is available, and we expect more to become available in the near future. Detailed information about the format can be found in the xBRL-CSV tutorial.

4 OIM constraints

In order to achieve a simplified model, some less commonly used complex features are not supported by the Open Information Model. These include:

• Reports containing tuples;
• Concepts using a fraction data type; and
• Various dimensional features, including complex typed dimensions, non-dimensional segment/scenario content and mixing segment and scenario container elements.

It is recommended that all new XBRL implementations adhere to these constraints, in order to benefit from new, OIM-based formats and tools.

For full details of the constraints, see xBRL-XML section v2.1.

5 Summary

The preferred choice of XBRL report format for different use-cases is summarised in Table 1¹