Table of Contents

1 Introduction

XBRL reports are used by companies worldwide to meet regulatory and disclosure requirements such as the European Single Electronic Format (ESEF) in the EU, Interactive Data submissions through the US SEC's EDGAR system and over 200 other reporting implementations globally. XBRL reports are distributed as XBRL Report Packages which is a standardised format that contains all files that make up the report, including supporting documents such as an extension taxonomy, images or fonts. There are two types of XBRL Report Packages:

• Inline XBRL Report Package (.xbri) – used for Inline XBRL reports that combine human-readable and machine-readable data.
• Non-Inline XBRL Report Package (.xbr) – used for xBRL-XML, xBRL-JSON, and xBRL-CSV reports.

The XBRL Report Packages specification reached Recommendation status in September 2023, following the XBRL International governance process, several years of development, testing, and public review.

This guide will help IT security teams and security software vendors understand these XBRL Report Packages and the associated file types, their purpose, and the key policy considerations for safely handling and enabling their use within secure environments.

2 Distinct File Extensions

XBRL Report Packages have two file extensions — .xbri and .xbr — to distinguish between different types of XBRL reports. These files are ZIP files that contain the business report, its data, and all supporting resources. Much like Microsoft Office files (for example, .docx or .xlsx), which are also ZIP files holding structured content, XBRL Report Packages follow a similar design. Even though XBRL Report Packages use the ZIP format, they are not ordinary ZIP files. Their contents are structured and should only be opened or viewed using XBRL software; standard archive tools do not automatically recognise or expose the internal files. Manually editing XBRL Report Packages outside of XBRL certified software is discouraged as it might invalidate the package. A list of certified XBRL creation and consumption Software can be found on this page.

Distinct extensions help users and systems easily recognise the file type and discourage users from modifying the contents. This approach also addresses a common issue with traditional .zip files, where users could manually open, alter, and unintentionally invalidate the Report Package.

3 Allowing File Extensions

The .xbri and .xbr file extensions used by XBRL Report Packages may be unfamiliar to corporate IT systems. In some cases, these file types can be blocked by default security settings, preventing them from being shared through email or corporate networks. Such restrictions can disrupt essential business processes, including the submission of mandatory regulatory reports, the receipt of disclosures from stakeholders, and regular communication with banks, auditors, regulators, and external software vendors involved in the reporting process.

4 Structure of Report Packages

The XBRL Report Packages specification defines a standardised structure for how files and folders are organised within the Report Package. This ensures consistency in how reports are created, shared, and processed across different systems. The structure of a package can be validated by XBRL-compliant software to confirm that it follows the specification correctly. Further details about the Report Package structure are available in the technical specification and technical implementation FAQs published by XBRL International.

5 Contents of Report Packages

An Inline XBRL Report Package (.xbri extension) contains an HTML or XHTML file that represents the Inline XBRL report. The package may also include supporting resources such as images (in formats like PNG, JPG, GIF, or SVG), fonts (WOFF, WOFF2, or TTF), and stylesheets (CSS) stored as separate files within the package. These elements preserve the design, formatting, and accessibility of the report.

A Non-Inline XBRL Report Package (.xbr extension) generally contains XBRL data files in XML, JSON, or CSV formats.

Report Packages include JSON files that store metadata about the Report Package version, and, in future, digital signature details for enhanced authenticity and integrity. Additionally, a Report Package may contain XSD and XML files that define an extension taxonomy, which are used when a company introduces its own reporting concepts in addition to those defined in the base taxonomy.

Inline XBRL utilizes HTML/XHTML, which technically allows for JavaScript to enable web browser display of XBRL data. However, for regulatory submissions, executable content, including JavaScript, is typically forbidden by regulators. Inline XBRL reports submitted to regulators must contain only static data and resources, making it a compliance risk if JavaScript is inadvertently included in the XBRL Report Package.

6 Implementation Recommendations: Security Perspective

The following measures help maintain information security while ensuring that organisations can safely handle and exchange XBRL Report Packages as part of their regulatory and financial reporting obligations.

6.1 Recommendations for IT Security Teams

• Add to allowed extensions: Include .xbri and .xbr in the organisation’s list of permitted file types.
• Verify that email gateways, firewalls, proxies, and other filtering mechanisms do not block these extensions, ensuring smooth transmission of XBRL Report Packages.
• Update policy documentation: Add XBRL Report Package formats to the acceptable file type and data-handling policies.
• Train support staff: Educate help desk and security personnel that these are legitimate, standardised business files used for regulatory and financial submissions.

6.2 Recommendations for Security Software Vendors

• Recognise file types: Configure detection systems to correctly identify .xbri and .xbr as XBRL reports.
• Apply standard scanning: Treat these Report Packages like other ZIP-based document formats, applying standard antivirus and integrity scans, and ensuring that no executable content is embedded.
• Update file type databases: Add these extensions to trusted or safe file type lists to prevent unnecessary blocking or quarantining.