XBRL and iXBRL Explained: Digital Tagging for Financial Reporting

XBRL and iXBRL don't come up in everyday conversation, but almost every accountant in the UK and EU interacts with them without necessarily knowing it, because they're the standards behind digital, machine-readable financial reporting. If you've ever filed company accounts with Companies House or HMRC, an XBRL-based format was almost certainly involved. This guide explains what XBRL and iXBRL actually are, how they differ, and why regulators have standardised on them.

What is XBRL?

XBRL, short for eXtensible Business Reporting Language, is an open data standard that tags individual pieces of financial information with a machine-readable label identifying exactly what that figure represents, for example "revenue," "total current assets," or "cost of sales." Instead of a regulator receiving a PDF or spreadsheet that a human has to read and interpret, XBRL data can be processed automatically by software, because every number carries structured metadata describing its meaning. A standalone XBRL file is built purely for machine-to-machine submission; it isn't designed to be a readable document in its own right.

What is iXBRL, and how does it differ?

Inline XBRL (iXBRL) solves the readability problem. It embeds the same structured tags directly inside a normal HTML document, so the result is a single file that serves two audiences at once: a person can open it in a browser and read a normally formatted report, complete with layout and narrative, while the underlying tags let software extract the same data automatically. This dual-purpose design is why iXBRL, rather than standalone XBRL, has become the standard format for statutory filings: it means companies don't have to produce and maintain two separate versions of the same report.

Where digital reporting is actually mandated

Structured digital reporting isn't optional guidance, it's a hard filing requirement in several major jurisdictions. In the UK, all company accounts filed with HMRC and Companies House have needed to be submitted in iXBRL format since 2011, covering around five million companies. In the EU, the European Single Electronic Format (ESEF) requires companies listed on EU-regulated markets to file their annual financial reports in iXBRL. In the US, public companies file with the SEC through the EDGAR system using iXBRL as well. The pattern across all three is the same: regulators process enormous filing volumes (the UK's FCA alone processes roughly 500,000 records a year) and manual review at that scale simply isn't feasible, so structured, machine-readable data is now the baseline expectation rather than an advanced option.

Why regulators prefer it over PDFs and spreadsheets

Three things drive the shift to structured reporting. Consistency: standardised tags remove the ambiguity that comes from different companies presenting broadly similar information in different formats and layouts. Scale: with filing volumes in the hundreds of thousands, structured data is the only practical way for a regulator to process submissions without relying on manual sampling. And market-wide oversight: because every filing uses the same underlying tags, a regulator or analyst can meaningfully compare data across an entire market rather than reviewing one filing at a time.

What this means for finance teams in practice

For most finance professionals, iXBRL isn't something built manually. Accounting and tax software generates the required tagging automatically as part of the filing process, and most finance teams interact with it indirectly through their existing compliance workflow, whether that's Companies House accounts filing, Corporation Tax computations submitted to HMRC, or Irish Corporation Tax compliance filings. Where it does matter directly for finance teams is understanding why validation errors occur and what they mean: software-driven tagging still needs to map correctly onto a company's chart of accounts and reporting structure, and errors in that mapping are a common cause of rejected or delayed filings. This sits alongside the broader shift in financial reporting covered in our guide to IFRS and GAAP training, where standardisation and comparability are recurring themes well beyond just the reporting format.

FAQ

Is iXBRL the same as XBRL? No. XBRL is a standalone machine-readable data format; iXBRL embeds the same tagging inside a normal HTML document so it's readable by both humans and software.

Do I need to build iXBRL tagging manually? Almost never. Accounting and filing software handles the tagging automatically as part of generating statutory accounts or tax computations.

Why do regulators require it instead of a standard PDF? Structured data lets regulators process filings automatically at scale, ensures consistency across companies, and enables market-wide comparison that isn't possible with unstructured documents.

XBRL and iXBRL are easy to overlook because the tagging happens behind the scenes, but they're the quiet infrastructure underpinning almost every statutory filing finance teams in the UK and EU now produce.

The taxonomy behind the tags

XBRL tags aren't invented freely by each company. They come from a shared "taxonomy," a structured dictionary of standardised reporting concepts maintained by bodies like XBRL International and adapted for local reporting frameworks, such as the UK's FRC taxonomy for UK GAAP and IFRS filings. When a company's accounts are tagged, each line item is mapped to the closest matching concept in the relevant taxonomy, which is what makes the resulting data genuinely comparable across different companies and filing periods. Where a company has a figure that doesn't map neatly onto an existing taxonomy concept, it can usually create a company-specific "extension" tag, though regulators generally prefer filers to use standard taxonomy tags wherever possible, since extensions are harder to compare across the market.

Common pitfalls finance teams encounter

Even though tagging itself is largely automated, a few recurring issues cause problems at filing time. Mapping errors happen when a company's chart of accounts doesn't align cleanly with the taxonomy, leading software to tag a figure under the wrong concept. Overuse of custom extension tags, rather than standard taxonomy elements, can trigger validation warnings and make a filing harder for regulators and analysts to compare against peers. And filings prepared close to a deadline sometimes skip a proper validation check, only for the software's automated validation step to flag structural issues that then need fixing under time pressure. Building a short review step into the filing process, checking that key figures have tagged to the expected taxonomy concepts, catches most of these issues well before submission.