XBRL vs iXBRL: What’s the Difference and Which Format Do You Need?

XBRL and inline XBRL (iXBRL) are two widely adopted global standards for financial reporting of business data. Both turn financial data into a form computers can read, and both share the same technical base, but they do different jobs and answer to different regulators.

Where reports are fixed data tables and lists, such as for prudential or statistical reporting to central banks, XBRL will usually be found. Where reports are meant to include human readable text, be formatted, or have open content, such as filing financial statements or to file company accounts to corporate registries, iXBRL is the de facto standard.

In practice, filers do not choose which one to use. The government agency and the report type settle the question and data collectors will reject filings submitted in the wrong format. 

This guide explains the technical differences, gives examples of both types of reporting, and helps to identify which one best applies to your data collections. CoreFiling are editors of much of the XBRL standard and official guidance, invented the iXBRL format and still maintain the specification, from this position, we are always happy to have more in depth discussions with regulators or other agencies on this and the broader digital data collection topic.

What Is XBRL? A Plain-English Definition?

XBRL stands for eXtensible Business Reporting Language. It is an open and free standard that is used to apply tags to financial figures and narrative and create machine-readable reports that software can process automatically. Each tag identifies what a number represents, for example, revenue, total assets, or a specific liability, and matches the value or text to a precise definition held in a shared dictionary called a taxonomy.

The standard first appeared in 1998, at a point when companies, regulators and analysts were all handling the same financial data in incompatible formats with no reliable way to process it by machine. 

XBRL replaced that patchwork with a single structured standard that any compliant system could read and write the same way. Today, XBRL International, a global not-for-profit consortium, governs the standard and its specifications.

In practice, an XBRL report is either a single file, usually with a .xbrl extension, or a multi-file report package with a .xbr extension. That file holds only the tagged data, written in one of the XBRL formats (XML, CSV or JSON). Open one, and you get raw code, since the file was never meant for people to read directly. 

This is the defining trait of plain XBRL, and it explains why XBRL reporting works so well for structured returns sent straight from one system to another. iXBRL was invented as the alternative when readable reports are required.

What XBRL is used for: the key regulatory contexts?

Plain XBRL remains very popular. It’s still the required format wherever a regulator wants large volumes of structured numbers and has no need for a human-readable document alongside them.

Banking and insurance supervision is the clearest case. For example, Banks across the EU file COREP and FINREP returns under the CRD IV framework, and insurers file their Solvency II returns, all in the pure XBRL format. 

These are dense, template-driven submissions that move from a firm’s systems straight into a regulator’s, so a formatted report would add nothing. The same logic applies across the world where central banks and regulators have a need for high-integrity, structured data.

Regulators take the raw tagged data here because they put it straight to work. They ingest the XBRL tags, run automated validation against the relevant taxonomy, and feed the results into their own analysis. For this kind of high-volume, often granular, system-to-system regulatory reporting, plain XBRL is still the right tool.

XBRL displayed in the Beacon view and review app. The layout in the taxonomy is also used in apps.

What Is iXBRL? Inline XBRL Explained?

Inline XBRL, or iXBRL, solves the one drawback of plain XBRL – it keeps the machine-readable tags but puts them where people can still read the report.

The name is short for Inline eXtensible Business Reporting Language, and it describes an extension of the XBRL standard. Instead of only a data file, the iXBRL format embeds the XBRL tags directly inside an HTML document.

The result is a single file, with either a .html (for a standalone file) or .xbri (for a report package) extensions. The report works in two ways: To a person, an iXBRL report opened in any browser, is a normally formatted report. To software, it is a source of structured data, since the embedded tags can be extracted exactly as they would from a plain XBRL file.

This dual nature is why iXBRL became the standard for published company reporting. A set of iXBRL accounts or a tagged annual report works for the accountant who prepares it, the regulator who collects it, and the analyst who later reads the report or extracts the figures.

Tags are not just for computers! With iXBRL, investors and stakeholders can easily review tagged data within a company’s formatted report using browser-based iXBRL viewers. This means people can search large reports based on where tags are applied and create normalised views of financial tables. It is becoming increasingly common for iXBRL to be published with an embedded viewer to enable these enhanced ways of reading reports.

CoreFiling invented the iXBRL format and still maintains the specification on behalf of XBRL International. The format was devised by Philip Allen, CoreFiling’s Executive Chairman, who is also the editor and author of the original Inline XBRL specification.

How iXBRL tagging works: tags embedded in a single document?

iXBRL tagging works by wrapping each reported figure in markup that the browser ignores, but software can read. The number a person sees on the page, and the tag attached to it, are the same element, held together inside the one HTML file.

Take a revenue figure of £4.2 million in an annual report. On screen, it looks like any other number. Underneath, the value is wrapped so that it carries the correct XBRL concept, the period it covers, the currency, and the scale.

In simplified form, the markup reads something like this:

<ix:nonFraction name=”Revenue” contextRef=”FY2025″ unitRef=”GBP”>4,200,000</ix:nonFraction>

The browser shows £4.2 million. A machine reads “revenue, full year 2025, 4,200,000 GBP.”

This is the structural break from plain XBRL. With XBRL, the tagged data and the readable document are two files. With iXBRL, the tags live inside the HTML document itself, so the report and its structured data are the same.

An iXBRL report in an interactive viewer. The structured, tagged data is visible and searchable.

XBRL vs iXBRL: The Key Differences Compared

The difference between XBRL and iXBRL is structural. XBRL has values and tags in a data file you need software to open. iXBRL embeds the same tags in an HTML document a person can read in a browser. Everything else about the two formats traces back to that.

Here is how the two formats compare:

Before iXBRL was introduced, a filer wanting to provide a formatted version of their report would have to manage two outputs, the machine-readable data (plain XBRL) and the human-readable report (usually PDF), and had to keep them consistent. With iXBRL, there is one file, so the report a person reads, and the data a regulator collects can never fall out of sync.

That single file pays off on both sides of a filing. The filer produces, validates, and submits one deliverable, with no separate data file to reconcile against the accounts.

It pays off for whoever receives the report, too. An auditor or analyst opens the HTML document on screen like any report and extracts its structured data from the same file, with no conversion step. 

This is why iXBRL took over published reporting while plain XBRL kept its place for high-volume statistical and regulatory returns.

Extension taxonomies and anchoring: the iXBRL-specific concepts

A standard XBRL taxonomy covers the disclosures most companies report, but no fixed list covers everything. This is particularly true for principal-based reporting such as those based on IFRS.

When a company reports a line item for which the standard concepts do not fit, the preparer creates an extension taxonomy, a set of company-specific tags. A mining firm reporting an unusual revenue line would build its own tag for it, and that tag still carries structured, machine-readable meaning.

Custom tags raise a problem. A tag invented by one company means nothing to an outside system, which is where anchoring comes in. Introduced to support the European Single Electronic Format (ESEF), every extension tag has to be anchored to the closest standard IFRS concept by accounting meaning: wider anchors cover multiple IFRS tags or narrower anchors which are more specific than the IFRS tag they reference. 

Anchor a custom mining-revenue tag to the standard revenue concept, and any system can understand the figure without knowing the company’s own label.

For preparers and auditors, this is one of the hardest parts of an ESEF filing, and the most frequent source of validation errors.

Case Study: UK Regulatory and Statutory Reporting

In the UK, iXBRL is collected by HMRC (tax authority), Companies House (corporate register) and the FCA (securities regulator). Anyone filing company tax returns or annual accounts is dealing with iXBRL, whether they tag it themselves or leave it to their accountant.

• HMRC: iXBRL is mandatory for every Corporation Tax return (the CT600) filed online, and online filing is itself compulsory. The company accounts and tax computations both have to be tagged, using the XBRL taxonomy for UK GAAP or IFRS.
• Companies House: Accounts filed with the registrar through commercial software are submitted as iXBRL accounts, tagged against the relevant Financial Reporting Council taxonomy for UK GAAP or IFRS.
• FCA: Issuers must submit their annual financial statements to the FCA in iXBRL format. This uses a taxonomy and rules known as UKSEF.

You can read more on iXBRL for HMRC and Companies House and how the mandates work in practice.

The UK has worked this way for years. HMRC’s iXBRL mandate dates to 2011, and tagged accounts are well into their second decade as standard practice. For most companies, the iXBRL requirements are built into the software that prepares their financial accounts. For others, inexpensive tagging software and services are readily available.

XBRL for UK financial institutions: FCA, Bank of England and the PRA

One group of UK filers uses plain XBRL for much of their reporting: banks, building societies, insurers and larger investment firms send prudential, supervisory and statistical returns to the UK regulators under a separate regime from HMRC and Companies House.

These are the COREP, FINREP and other returns under the CRD IV framework, or Solvency II returns for insurers. The UK regulators collect them as structured XBRL data, using UK versions of the European taxonomies that have diverged from those used in the EU’s since Brexit.

The XBRL format suits these returns because they are dense, template-based and built for system-to-system regulatory reporting. For these firms, XBRL and iXBRL run in parallel, prudential and statistical returns as plain XBRL, statutory accounts as iXBRL.

Case study : EU Regulatory Requirements and the Move to iXBRL in Europe

Several countries around the world have embraced digital reporting in iXBRL. None more so that the member states of the EU, with several regimes built on the same format, some examples are outlined below.

• ESEF, the European Single Electronic Format, requires every company on an EU-regulated market to file its annual financial report as an XHTML document with embedded iXBRL tags. It has applied to financial years starting on or after 1 January 2020, with consolidated IFRS statements tagged using the IFRS taxonomy plus extension tags. CoreFiling builds ESEF reporting software for this.
• UKSEF is the UK equivalent of ESEF, also iXBRL, used by UK-listed companies. Since Brexit, the UK has run its own variant, maintained by the Financial Reporting Council, which extends the ESEF taxonomy with UK-specific tags.
• KVK reporting in the Netherlands is the newest large scale iXBRL transition. Large companies filing annual accounts with the Dutch Chamber of Commerce now do so in iXBRL and smaller ones will follow in future years. See KVK iXBRL filing (Netherlands) for the details.
• CSRD, the Corporate Sustainability Reporting Directive, applies the same method to sustainability data, tagged against the ESRS taxonomy on the same iXBRL framework as ESEF. The 2025 Omnibus reforms narrowed who must report and delayed the timelines, and the digital tagging requirement is not yet in force, pending formal adoption of the ESRS digital taxonomy. Even so, companies already filing under ESEF will use the same format and tooling once sustainability tagging arrives.

All these digital data collections were transformational when they were introduced, and possible due to the foundation and broad support that the iXBRL specification enjoys.

Which Format Do You Need? A Practical Decision Guide

If you’re filing almost any published or statutory report, iXBRL is the answer. Tax agencies, corporate registers, securities regulators and stock exchanges around the world use it. For companies in mature mandates, it is often a standard format in the software that prepares the accounts. For others, tagging services are readily available or the data collectors provide additional assistance to create an iXBRL return.

You’ll need iXBRL if you’re:

• A company or accounting firm handling statutory or tax reporting requirements within an iXBRL mandated programme.
• A listed company with regulatory or listing requirements that include digital reporting in iXBRL.
• An auditor in the EU, where ESEF filings are part of the audit requirements. This also applies to providers of voluntary audit and review services for other jurisdictions.
• A government agency or other data collector looking to collect formatted digital reports either for a new purpose or to modernise current PDF or paper-based reporting.

If you’re a financial institution or handling tables or lists of data, the answer flips. Banks and insurers file their prudential returns in plain XBRL, with no inline version, because these are dense, template-based submissions built to move straight from one system to another. Current trends in reporting indicate a move towards granular data and the use of the xBRL-CSV format to simplify reporting and handle massive returns.

Plain XBRL is the format if you’re:

• A supervised financial institution filing prudential, supervisory or statistical returns where the regulator has mandated XBRL.
• A government agency or other data collector creating new new structured data collections or replacing Excel-based reporting.

In some cases you may need both, due to collecting different types of data, creating software for a broad range of reporting requirements or need to meet several reporting requirements, a situation familiar to most financial entities. In these cases, the investing in solutions that support the standard, rather than individual mandates, such as the CoreFiling apps and APIs, can give you an efficient means of handling reporting of several different types of data and jurisdictions in one solution.

If none of this maps cleanly to your situation, or you file in more than one regime, CoreFiling’s team can work out which format you need. Talk to us or explore our reporting solutions.

Can XBRL and iXBRL Be Used Together?

Yes. People often assume you have to pick one, but that’s not how it works. iXBRL is an extension of XBRL, not a rival to it.

Every iXBRL file holds valid XBRL data inside it. A regulator that accepts iXBRL is reading the same structured data, just wrapped in a document that a person can open.

They also work side by side. A bank might file its COREP returns in plain XBRL and publish its annual report in iXBRL the same year. One is a supervisory return only software reads. The other is a public document built for people and machines alike.

How CoreFiling Supports Both XBRL and iXBRL Reporting?

If you file in XBRL or iXBRL, the company behind your software matters. CoreFiling invented iXBRL and still maintains the specification on behalf of XBRL International, so the standard and the tools that serve it come from one place.

The True North Data Platform is applicable throughout data collection programmes for both XBRL and iXBRL, data collection, preparation, audit and consumption.

For example, on the production side, a few products handle the specific jobs required:

• Seahorse SaaS filing software gives companies and tagging teams fast, always-compliant iXBRL and XBRL output.

• Reporting solutions for XBRL and iXBRL suit corporates, accountants and software vendors who build or outsource their reporting.

• Auditor solutions for iXBRL assurance give firms automated checks and collaborative review of annual reports.

Whatever you need to file, you’ll be working in a format CoreFiling helped create, backed by the team that still maintains it. Talk to the team about your XBRL or iXBRL requirement.