Learning Objectives

  • Understand the end-to-end process of data exchange, from collection to analysis
  • Identify the different mechanisms for collecting XBRL reports
  • Recognise the importance of validation, submission, and storage in ensuring data quality
  • Learn mechanisms to render published reports for human readability

Introduction

Efficient data exchange is crucial for regulatory reporting, ensuring that structured information flows seamlessly between preparers, regulators, and stakeholders. This section explores the entire data exchange process.

Regulators use various mechanisms to collect XBRL reports, each offering different levels of automation and control. Once collected, these reports must be validated to ensure compliance with defined rules before being stored and analysed.

Another critical aspect of the data exchange process is rendering XBRL reports for human interpretation, allowing structured reports to be displayed in a human-readable format.

The Data Collection Process

The reporting process in an XBRL environment begins long before a file is submitted. It starts with a regulatory need, the definition of which information is required, how often it should be reported, and the decision to use XBRL as the standard for data collection and validation. From there, a series of coordinated actions between regulators and reporting entities ensure that data is not only exchanged but is meaningful, validated, and ready for use. Once the foundation is in place, the reporting process moves into the operational phase. The data collection process consists of three main stages: collection and validation; rendering and publishing; and finally storage and analysis.

Data collection and subsequent processes at the regulator’s end

Collection and Validation

This process represents formal exchange of data between the reporting entity and the regulator. From the preparer’s perspective, it involves compiling the required data, generating an XBRL document, and submitting it through the designated channel. From the regulator’s side, it refers to the collection of those reports using submission platforms.

Once a report is submitted, it must be validated to confirm it adheres to the XBRL technical specification, taxonomy definition, and regulator-specific rules. Automated validation prevents the intake of structurally incorrect or inconsistent reports and ensures that collected data is reliable and complete before storage and analysis.

Rendering and Publishing

Since XBRL reports are primarily machine-readable, the data within also needs to be accessible in a format that is easy for humans to understand. Users may be internal staff, or where reports are made publicly available, the public. The approach to rendering taken will depend on the format of the reports. The underlying law may require data collectors to publish the information they collect, either in full or in a specified form. In such cases, the collector must ensure the data is made accessible to the public or to a defined group of stakeholders, in line with the legal and regulatory requirements.

Storage and Analysis

Reports that have passed the automated validation process are then stored in secure databases or repositories. At this stage, the information becomes part of the regulatory data lake or data warehouse, where it is indexed and linked to metadata (e.g., submission date, entity identifier, reporting period). This centralised storage ensures long-term traceability and supports future audits or reprocessing needs. In many regulatory systems, this phase also includes digital archiving and backup protocols.

The final stage involves using the structured data for regulatory, supervisory, or policy purposes. Because XBRL reports are standardised and validated, they can be queried, aggregated, and compared across entities and time periods, enabling early warning systems, risk analysis, benchmarking, and informed decision-making. Advanced analytics or AI tools may also be applied at this stage to derive further insights from the data.

Read more about approaches to store and analyse data in this article.

Collecting XBRL Reports

XBRL reports can be collected via different mechanisms, depending on the regulatory environment, technical infrastructure, and level of maturity of the reporting entities. Each approach balances ease of use, scalability, and control.

Portal-Based Uploads

Manual submission through a secure web portal is one of the most common starting points for XBRL report collection. In this model, the reporting entity logs into an official platform, selects the relevant reporting form or taxonomy, and uploads the corresponding XBRL report.

API-Based Submission

In more advanced environments, regulators offer automated channels for submission through Application Programming Interfaces (APIs). This method allows reporting entities to integrate their internal systems directly with the regulator’s infrastructure, enabling seamless, real-time, and high-volume data transfer. It reduces human intervention and the risk of manual errors, while significantly improving scalability and speed.

Hybrid Approaches

Many regulators adopt a hybrid model that combines both manual and automated methods. This approach provides flexibility, allowing advanced entities to automate their processes via APIs while still offering a manual option for smaller or less technically equipped organisations.

A hybrid model also facilitates gradual digital transformation, enabling regulators to onboard a wide range of preparers without excluding those who are still in earlier stages of system development.

Authentication and Initial Checks

Regardless of the chosen approach, it is essential to enforce strong authentication mechanisms to ensure secure access and traceable submissions. Depending on the organisation’s security policy, this may involve credentials, digital certificates, or multi-factor authentication protocols.

The collection portal serves as the entry point to the processing platform. Automated gateway checks at the file upload stage help ensure only secure and valid files proceed, reducing risk and streamlining processing. Common checks include:

  • Malware check: Scans files to prevent malicious content from entering the platform or wider system.

  • Format check: Verifies that file types match the platform’s supported formats.

  • Taxonomy compliance: Confirms that submitted XBRL files use the correct taxonomy version for the reporting period, allowing early rejection of invalid reports.

Ensuring Data Quality and Compliance

To ensure that submitted data is accurate, complete, and fit for regulatory purposes, validation mechanisms must be applied systematically. These mechanisms assess whether reports comply with both the technical requirements of the XBRL specification and the specific expectations defined by the regulator.

Validation may occur at different points in the reporting lifecycle, each playing a distinct role in safeguarding data quality.

Pre-Submission vs. Post-Submission Validation

Pre-submission validation occurs on the side of the preparer. This allows entities to check for structural or logical errors before a report is formally submitted, helping avoid rejections and delays.

Post-submission validation is carried out by the regulator once a report has been received. This step serves as a second layer of control, ensuring that no faulty or non-compliant data enters the system, even if preparers have skipped or misused validation tools.

Both layers contribute to a robust data quality framework, particularly when aligned with clearly documented rule sets.

The XBRL standard itself includes built-in validation mechanisms such as schema consistency and dimensional checks. Additionally, the taxonomy may define business validation logic—such as calculation rules or cross-checks between data points—using XBRL Formula rules. On top of that, the regulator’s collection platform typically enforces filing rules that govern how and when reports can be submitted, including conditions related to accepted periods, naming conventions, and required disclosures.

Read more about validating XBRL reports in this article.

Rendering XBRL Reports

XBRL reports are designed primarily for machines. Although they offer a highly structured format ideal for validation and analysis, the raw data in an XBRL report is not easily interpretable by humans. While machines are optimised for processing structured data, humans rely on visual cues such as tables, labels, hierarchies, and summaries to understand reports. Rendering makes it possible to present structured facts in an intuitive layout without altering the integrity of the underlying data. This creates a need for human-readable views that make the information accessible to preparers, regulators, auditors, and the public.

Various tools support the rendering process, depending on the stage and intended use. These typically fall into three main categories. The first includes embedded viewers within supervisory portals, which offer web-based rendering directly from the collected data and allow users to browse, search, and review reports online. The second category comprises XBRL-specific rendering tools, which interpret taxonomy structures and apply reporting templates to generate human-readable views of XBRL reports.

In many cases, rendering tools provide additional features such as annotations, filtering, comparative views, and export options to enhance usability and facilitate communication across departments. The choice of rendering approach for XBRL reports depends on the format of the collected report.

iXBRL Rendering

Inline XBRL (iXBRL) is a format that combines structured data and human-readable HTML in a single file. It allows the same document to be both machine-readable and directly accessible in a web browser.

In order to make the XBRL data in Inline XBRL reports more readily accessible to users, collectors are recommended to make reports available in online, Inline XBRL viewer software, in addition to providing download links to the collected report package. Collectors may also consider providing additional interactive functions for searching and analysing the data in Inline XBRL reports.

Rendering With Reporting Templates

In environments where XBRL reports are collected as xBRL-XML, xBRL-JSON or xBRL-CSV, rendering can be achieved through predefined reporting templates provided by the regulator. XBRL Reporting Templates (Table Linkbase) provide a standard way for taxonomy authors to define business-user-friendly table structures to render XBRL reports. Table linkbase is most suited for a closed reporting environment where XBRL reports can be visualised in a standard template. These templates define how reported facts should be arranged, grouped, and labelled for human consumption.

Other Approaches

Rendering tools might use the taxonomy’s presentation and label linkbases to organise the data into readable tables or forms, often mirroring the structure of paper-based or spreadsheet-based reports. This approach allows regulators to present data in familiar layouts while maintaining consistency with the underlying taxonomy.

Business Intelligence and data visualisation platforms consume validated XBRL data—often after transformation—and present dashboards, charts, or summary tables for internal analysis and decision-making. These tools are particularly useful for supervisory and analytical functions once the data has been integrated into data warehouses.

Publishing Reports

Some data collectors choose to make collected XBRL or Inline XBRL reports publicly available. In doing so, it is essential that reports are published exactly as submitted by filers, without any modification. When reports are collected as Report Packages, they should be published in the same format to maintain consistency and support end-to-end usability. To enhance accessibility, collectors are encouraged to provide APIs that allow automated tools to retrieve, analyse, and integrate XBRL data programmatically. Publishing reports in xBRL-JSON—either alongside or in addition to formats like Inline XBRL—can further improve usability, as it offers a developer-friendly structure that is easier to adopt. Finally, collectors may also publish rendered views of XBRL reports to support human readability, as discussed in the above section.

Read more about data collection and processing in the XBRL International guidance.

Summary

Regulators must establish a clear end-to-end process for collecting XBRL reports—defining data requirements, enabling secure submission through portals or APIs, and validating reports against technical and business rules to ensure data quality. Strong authentication, gateway checks, and flexible submission methods (manual, automated, or hybrid) are key to supporting diverse reporting entities. Once validated and stored, rendering mechanisms are needed to make structured XBRL data human-readable, using tools such as inline viewers, reporting templates, or BI dashboards. The choice of rendering approach should align with the format of the collected reports and the needs of internal and external users. Where reports are published, they should be shared exactly as submitted—ideally with APIs and xBRL-JSON versions to maximise accessibility, automation, and usability for both technical and non-technical users.