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.
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.
Report Packages are intended to address the requirements of a number of different use cases.
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:
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.
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.
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).
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.
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.
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:
Where a package contains more than one report, each report must be free to use a different taxonomy.
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.
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).
It must be possible to include an XBRL taxonomy within the package for use by reports.
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 ).
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.
The report package format must facilitate the application of digital signatures to reports and their supporting taxonomy information.
The report package must identify any external taxonomy packages needed for the correct processing of the reports it contains.
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.
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.
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.
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.