Report Package Requirements 1.0

Requirements Document 9 December 2020

This version
Paul Warren, XBRL International <>
David Bell, UBPartner <>
Mark Goodhand, CoreFiling <>
Herm Fischer, Mark V Systems <>

Table of Contents

1 Abstract

The XBRL Taxonomy Packages specification defines a standard for distributing XBRL taxonomies within ZIP files. The specification was originally intended to be used only for the distribution of taxonomies, and not for iXBRL and XBRL reports (instance documents), but it is now recognised that this may be a useful application of the specification.

This document defines requirements for an extension to the Taxonomy Package specification that defines a standard mechanism for the inclusion of XBRL and Inline XBRL (iXBRL) reports within a taxonomy package. The resulting specification will be a formalisation of the Report Packages Working Group Note.

2 Introduction

XBRL and iXBRL reports frequently require additional files that are provided by the report preparer in order to be understood correctly. These can include (but are not limited to):

References to these resources is by means of a URL. This can be problematic as the resources may not be public, so it is not possible to use absolute URLs, and the use of relative URLs requires the relative locations of the reports and resources is maintained.

This document defines requirements for a standard mechanism for combining multiple files into a single package in a manner that allows references between them to be preserved.

3 Use cases

Report Packages are intended to address the requirements of a number of different use cases.

3.1 Portable XBRL Reports

XBRL and iXBRL reports can be very difficult for end-users to work with, due to the dependency on external resources noted above. By contrast, document formats such as PDF and Microsoft Word hide such complexities by embedding all resources into a single file. This provides a simple "user model" where a document is represented by a single file. The full contents of the document can be faithfully stored and exchanged by copying, emailing, or publishing that single file.

Report Packages should bring this simplicity of a single file representation of a document to XBRL and iXBRL reports by providing a "Portable XBRL Report" file format.

This should simplify various use cases for working with XBRL. For example:

3.2 Multi-report submission

Some reporting scenarios may require the submission of multiple separate reports. For example, a company tax filing might require the submission of a tax form, alongside one or more sets of accounts that between them cover the tax filing period.

Report Packages could provide a standard format for such multi-report submissions.

3.3 Multi-report publication

Regulators that collect XBRL reports from multiple entities may wish to publish these reports in bulk. For example, some regulators would publish daily archives of company filings.

Report Packages could provide a standard format for publishing such archives.

3.4 Non-XBRL files and attachments

Regulators often collect files which are associated with XBRL reports but which contain no XBRL content and are not linked to or related to XBRL reports. Sometimes called "attachments", these may be PDF files, non-iXBRL HTML files, or any other non-XBRL documents expected as part of a submission. Report Packages need not provide any special support for such files, but the specification must not forbid their inclusion (it is for regulators to decide whether such files are allowed or required).

4 Requirements

4.1 Support for multiple reports

The use cases for multiple report submission (Section 3.2) and multiple report publication (Section 3.3) require a report package to contain multiple XBRL or iXBRL reports.

4.2 Single report packages

The "Portable XBRL Reports" use case (Section 3.1) calls for a single file to represent a single report. A tool opening such a package should be able to locate a single XBRL or iXBRL report (or iXBRL document set) without additional input from the user.

4.3 Report discovery

It must be possible to automatically locate the report or reports within a package. A package may contain one or more reports, with each report being one of:

4.4 Multiple taxonomies

Where a package contains more than one report, each report must be free to use a different taxonomy.

4.5 Absolute URL remapping

It must be possible to refer to resources from an XBRL or iXBRL report by means of an absolute URL which is remapped to a location within the package.

4.6 Supporting resources

It must be possible to include other file types within the package that support the reports, for example, CSS, image, font, OIM metadata and parameter files.

Where multiple reports are included in a package, it must be possible to share these resources between reports (we should not force users to duplicate supporting resources).

4.7 Extension taxonomy

It must be possible to include an XBRL taxonomy within the package for use by reports.

4.8 iXBRL file types

It must be possible to use file extensions for iXBRL reports that indicate reports that are expected to be rendered as XHTML (.xhtml extension) and as HTML (.html or .htm ).

4.9 Report ordering

To ensure consistent, logical presentation of packages containing multiple reports, reports must have a well-defined order that is configurable by the report package author.

4.10 Report signing

The report package format must facilitate the application of digital signatures to reports and their supporting taxonomy information.

4.11 External dependencies

The report package must identify any external taxonomy packages needed for the correct processing of the reports it contains.

4.12 Document set ordering

It must be possible to control the ordering of documents within an iXBRL document set.

The Inline XBRL specification defines the behaviour of a document set, but does not provide a mechanism for locating the documents within a set, or defining an order between them.

Although the ordering of documents does not affect the process of extracting XBRL data from the report, this information is of use to viewers and other applications that need to present the documents in the report in a logical order. For example, a document set may include a cover page as a separate document, which should be presented before the main body of the report.

4.13 Report language documentation

Some filing programmes may require the same information to be provided in multiple languages - for example, an English and a French version of the annual financial statements.

If these alternatives appear as separate XBRL reports in a report package, it is useful for consuming applications to be able to present the appropriate report to users, without having to first load each report to determine the language(s) used within it.

Accordingly, the report package specification must allow language information to be expressed at report level.

A mechanism should be provided to express which reports are translations of each other, as opposed to completely separate reports.

4.14 Distinct file formats

The Portable XBRL Report use case requires a file format containing a single report that can reliably be opened without any further user interaction (per Section 4.2), whereas other use cases require a file format that can contain multiple reports.

The "ease of use" goals of the Portable XBRL Report use case call for a distinct file format that cannot easily be confused with other types of report package. This should most likely be identified by a dedicated file extension, such as .pxr.

4.15 Arbitrary report metadata

The report packages specification must allow package authors to associate custom metadata with reports, in addition to the core metadata defined by the specification.

Such metadata is important for the multi-report submission and multi-report publication use cases, to support both automated and interactive selection of reports of interest.

While report metadata can be included within the reports themselves, in the form of XBRL facts (such as the DEI tags used at the SEC), it is computationally expensive to load such information from the unordered collection of facts in a large report, so metadata that is used to guide the processing or selection of reports is best captured externally.

By providing a standard mechanism to associate user-defined or regulator-defined metadata with a report, we eliminate the need for users to capture such information using completely custom mechanisms, such as auxiliary files or file naming conventions.

If possible, the design should allow processors to easily validate that external report metadata matches internal report metadata, whenever the metadata is replicated.