Tax authorities, corporate registries, capital markets regulators and financial supervisors around the world collect enormous volumes of data from the organisations they oversee. Increasingly, XBRL and iXBRL are used within digital reporting mandates that require organisations to submit structured, machine-readable information to regulators and other data collectors.

For authorities introducing or expanding digital reporting requirements, the challenge goes beyond choosing a technical standard. Reporting obligations, taxonomy design, implementation and the practical impact on reporting entities all need to be considered if a mandate is to deliver reliable, usable data.

This guide looks at what XBRL and iXBRL reporting mandates actually involve, surveys a representative set of established programmes by region, and sets out what a regulator or data collector should think about before launching or expanding one of its own.

What are XBRL and iXBRL reporting mandates?

XBRL (eXtensible Business Reporting Language) is an open, global standard for exchanging business and financial data in a structured, machine-readable format. It is maintained by XBRL International, and the current core specification, XBRL 2.1, was finalised in December 2003. Each figure in an XBRL report is tagged against a shared taxonomy, so a reported number carries its meaning, context and unit wherever it is used.

Inline XBRL (iXBRL) embeds those same machine-readable tags inside an ordinary HTML document, so the same file displays as a normal, readable report in a browser while still carrying the full set of structured tags underneath. It removes the need to maintain two separate versions of the same report. For this reason, regulators have increasingly favoured iXBRL over plain XBRL.

Inline XBRL itself has a CoreFiling connection worth noting. According to specification documents published by XBRL International, CoreFiling’s Philip Allen is the named editor of the Inline XBRL specification, and CoreFiling describes itself as the originator of the concept.

It’s worth clarifying what these mandates are not. XBRL and iXBRL reporting programmes are distinct from the VAT and e-invoicing digital reporting rules many countries have introduced for transactional tax data. This guide is concerned with structured reporting of financial statements, regulatory returns and similar disclosures to a data collector, not real-time invoice reporting to a tax authority.

Why regulators and data collectors introduce structured digital reporting

The case for structured reporting is essentially the same wherever it appears: a regulator that receives thousands, or millions, of documents each year in PDF format cannot realistically analyse them at scale. Figures have to be read and re-keyed by hand before any comparison, validation or trend analysis is possible.

South Africa’s CIPC made this point directly when introducing its own mandate, explaining that XBRL allows automated validation and in-depth analysis across the large volume of financial statements it processes each year. For any data collector, structured data means submissions can be checked automatically, filings compared across entities, and the register analysed as a whole rather than one filing at a time.

The UK government made a similar case when confirming its move to software-only, iXBRL-tagged company accounts filing at Companies House: the stated aim is to improve the transparency, accuracy and reliability of the data held on the companies register. ESMA’s rationale for the European Single Electronic Format follows the same logic from the capital markets side, aiming to make annual financial reports more accessible, more comparable and easier to analyse across the EU’s regulated markets.

Across each of these examples, digitisation is a means rather than an end. What matters is the capacity it gives regulators to extract greater value from data they already gather.

XBRL and iXBRL reporting programmes around the world

The examples below are a representative sample, not an exhaustive list. They’re drawn from established, working XBRL and iXBRL programmes and chosen to show a mix of data collector types and regions.

Europe: established XBRL and iXBRL reporting programmes

UK: Companies House

Data collector: Companies House, the UK’s registrar of companies
Reporting programme: Annual accounts filing
Format: iXBRL
Who reports: Companies filing statutory accounts with the registrar
What it demonstrates: How a registry moves from partial, voluntary digital filing to a universal mandatory regime

Companies House already accepts annual accounts filed in iXBRL, and the government has confirmed that from 1 April 2028 all companies will be required to file their accounts using commercial software, tagged in iXBRL, with the existing web and paper filing routes closed. For a data collector already handling a mix of voluntary digital and paper-based filings, this shows what a full transition to a mandatory, software-only structured filing regime looks like in practice, and how far in advance such a change can be signalled.

UK: HMRC Corporation Tax (iXBRL)

Data collector: HMRC, the UK’s tax authority
Reporting programme: Corporation Tax (CT600) returns
Format: iXBRL
Who reports: Companies filing a Company Tax Return
What it demonstrates: A long-running tax-authority iXBRL mandate that runs alongside a separate registry mandate on the same underlying accounts

HMRC requires companies to file their Company Tax Return together with accounts and tax computations in iXBRL format. The requirement has applied to returns delivered on or after 1 April 2011 for accounting periods ending after 31 March 2010, and with very limited exceptions, PDF accounts are not accepted. It’s one of the longest-running tax-authority iXBRL mandates in the world. It shows a model where the tax authority and the corporate registry can each receive iXBRL-tagged accounts from the same underlying filing.

EU: ESMA / European Single Electronic Format (ESEF)

Data collector: ESMA, the EU’s securities and markets regulator
Reporting programme: European Single Electronic Format (ESEF)
Format: iXBRL (within an XHTML document)
Who reports: Issuers on EU-regulated markets
What it demonstrates: A shared taxonomy making thousands of issuers across many jurisdictions genuinely comparable

ESMA requires issuers on EU-regulated markets to publish annual financial reports in XHTML, with Inline XBRL tagging of consolidated IFRS financial statements against a taxonomy based on the IFRS Taxonomy. The mandate applied to financial years beginning on or after 1 January 2020, although member states were permitted to defer it by one year, and many did.

EU: EBA COREP and FINREP

Data collector: European Banking Authority, with data collected by national competent authorities across the EU
Reporting programme: COREP (prudential data) and FINREP (financial data)
Format: xBRL-CSV (replacing xBRL-XML from the 31 March 2026 reference date)
Who reports: Credit institutions and certain investment firms
What it demonstrates: A highly granular, recurring reporting cycle built around a detailed, jointly maintained taxonomy, rather than a single annual filing

COREP and FINREP are built around a common XBRL-based Data Point Model. This is a useful example for prudential regulators specifically, since the reporting cycle and level of technical detail differ significantly from a once-a-year accounts filing.

Netherlands: KVK / Standard Business Reporting

Data collector: KVK, the Dutch Chamber of Commerce
Reporting programme: Standard Business Reporting (SBR)
Format: XBRL, with iXBRL as an alternative (required where sustainability reporting is included)
Who reports: Dutch-registered legal entities, scaled by size
What it demonstrates: A registry rolling out a structured mandate in stages, by company size, over several years

KVK has required annual financial statements to be filed via SBR in XBRL format from financial year 2016 for small and micro entities, extended to medium-sized entities from financial year 2017. From financial year 2025, large entities must also file via SBR, so their first mandatory digital filings are being made from 2026. Large entities can choose between an XBRL instance and an Inline XBRL report package, and iXBRL is mandatory where a CSRD sustainability report forms part of the filing.

Americas: structured financial reporting programmes

US: SEC structured financial reporting

Data collector: US Securities and Exchange Commission
Reporting programme: Structured financial reporting (periodic filings)
Format: iXBRL (plain XBRL from 2009 until the Inline XBRL phase-in)
Who reports: US-listed public companies
What it demonstrates: One of the earliest large-scale capital markets XBRL mandates, and a widely referenced example of phasing by filer size

The SEC mandated XBRL for periodic financial statements from 2009, starting with the largest filers and extending to all remaining US GAAP filers, including smaller reporting companies, for fiscal periods ending on or after 15 June 2011. Foreign private issuers reporting under IFRS followed once the SEC accepted the IFRS Taxonomy in 2017. The SEC then moved to Inline XBRL, again phased by filer size: large accelerated filers from fiscal periods ending on or after 15 June 2019, accelerated filers from 2020, and all remaining filers from 2021. The SEC has phased by size twice, which makes it a strong example for regulators planning a move from XBRL to iXBRL as well as an initial mandate.

Asia-Pacific: XBRL reporting programmes

Singapore: ACRA / BizFinx

Data collector: Accounting and Corporate Regulatory Authority (ACRA)
Reporting programme: BizFinx XBRL filing
Format: XBRL
Who reports: Most Singapore-incorporated companies, filed alongside the annual return
What it demonstrates: How a single registry mandate can scale its data requirements to the size of the reporting entity

ACRA requires financial statements to be tagged against the ACRA Taxonomy, prepared using ACRA’s free BizFinx preparation tool and lodged through its Bizfile portal. ACRA recognises several filing options: Full XBRL for most companies; Simplified XBRL, accompanied by a PDF of the financial statements, for smaller, non-publicly accountable companies; and Financial Statement Highlights templates for certain regulated entities such as banks and insurers.

Africa: XBRL reporting programmes

South Africa: CIPC XBRL reporting

Data collector: Companies and Intellectual Property Commission (CIPC)
Reporting programme: XBRL reporting of Annual Financial Statements
Format: iXBRL
Who reports: Public and state-owned companies, and private companies, close corporations and non-profit entities required to be audited; co-operatives required to be audited from 2022
What it demonstrates: A mandate that started with one population and was deliberately widened once the platform was established

CIPC made iXBRL submission of Annual Financial Statements mandatory from 1 July 2018 for companies filing audited statements alongside their annual returns, extending the requirement to co-operatives from 1 October 2022. CIPC’s own reasoning: PDF submissions could not be analysed at the scale or speed the regulator needed.

What regulators can learn from established XBRL programmes

Taken together, these programmes, drawn from different jurisdictions, point to a small number of patterns that are actually visible in the evidence, rather than assumptions about how digitisation “should” work.

Phased implementation by size or threshold is a recurring approach. The SEC began with its largest filers before extending the mandate to everyone else. KVK moved from small and micro entities, to medium-sized entities, to large companies over the best part of a decade. CIPC launched with one population and added co-operatives four years later. Companies House is moving from a position where software filing is one option among several to a universal software-only mandate, with several years’ notice. None of these authorities asked their entire reporting population to adopt structured reporting on day one.

A mandate’s initial population doesn’t have to be its final one. CIPC’s extension to co-operatives, and Companies House’s move from voluntary software filing to a universal software-only mandate, both show that a data collector can start narrower than its eventual goal and expand once the first phase is working. This gives authorities scope to test their systems, collection processes and compliance requirements before extending reporting obligations to a wider population.

Tiered reporting requirements let a single mandate cover a varied population. ACRA’s Full and Simplified XBRL templates, and the size-based thresholds used by KVK, both show that “one mandate” doesn’t have to mean “one format for everyone.” Matching the level of detail required to the size or complexity of the reporting entity is a workable way to bring smaller organisations into a structured reporting regime without over-burdening them.

What to consider before introducing an XBRL reporting programme

Before any technical work begins, a data collector considering a new or expanded XBRL or iXBRL mandate needs clarity on a few strategic questions.

What exactly needs to be collected, and from whom. Annual accounts, prudential returns and periodic financial statements are each governed by different regulations and place different demands on a taxonomy and a filing population. Getting this scope right early avoids rework later.

Which taxonomy to use, or adapt. Building a taxonomy from scratch is a significant undertaking. Established technical standards, such as the IFRS Taxonomy that underpins ESEF, or a Data Point Model approach similar to EBA’s, give a new programme a proven starting point rather than a blank page.

How much validation and data quality checking the programme needs at launch. Structured data is only as useful as its accuracy. Deciding how filings will be validated, and what happens when a submission fails validation, shapes both the filer experience and the quality of the resulting register.

How the mandate will scale beyond its first population. As the CIPC and Companies House examples show, a mandate may expand beyond its original scope. Planning, even loosely, for how the reporting population or the range of filing types might grow avoids designing a system that has to be rebuilt the moment it succeeds.

A checklist for launching or expanding an XBRL reporting programme

1. Define what you need to collect, and why. Set out the reporting population, the filing types in scope, the required frequency, and the outcome the data is meant to support, whether that’s supervisory analysis, register transparency or something else.

2. Choose or build the right taxonomy and validation rules. Where a suitable existing taxonomy exists, adapting it is usually faster and more interoperable than building a proprietary one. Decide early how submissions will be validated, and how filers will be told when something fails.

3. Plan the rollout. Consider whether to pilot with a subset of filers, phase the mandate in by entity size as several of the programmes above have done, or run a voluntary period before enforcement begins. Give filers realistic notice, in line with the multi-year lead times seen in several of the examples above.

4. Plan for what comes after the first mandate. An XBRL reporting programme may expand beyond its initial filing requirement. Consider, even at the design stage, whether the platform and taxonomy choices made now will support additional filing types or an expanded population later.

Why choose CoreFiling for XBRL reporting programmes?

CoreFiling has worked with XBRL for more than two decades. Its connection to the standard goes deeper than most vendors in the space: according to the specification documents published by XBRL International, CoreFiling’s Philip Allen is the named editor of the Inline XBRL specification, and CoreFiling describes itself as the originator of the underlying concept.

CoreFiling states that its software supports a range of established XBRL and iXBRL programmes, including HMRC’s iXBRL submissions, Companies House accounts, ESEF and CSRD/ESRS filings in the EU, and KVK filings in the Netherlands.

Two products sit behind this experience. Seahorse, CoreFiling’s SaaS platform, helps filers create, tag and validate reports against the rules of a given filing programme, flagging missing data or tagging errors before submission. The True North Data Platform provides the underlying processing technology, available to regulators and software vendors directly through APIs, as well as powering Seahorse itself.

CoreFiling staff also contribute to XBRL specifications and official guidance, giving the company a direct line into how the standard continues to develop. For a regulator or data collector weighing up how to launch or expand a structured reporting programme, that combination of standards involvement and delivery experience is worth having at the table early.

Get in touch with CoreFiling to explore what a new or expanded XBRL or iXBRL reporting programme could look like for your organisation.