XBRL is nearly 20 years old and works great for machines. iXBRL is newer and works for both people and machines. That might seem like a minor detail. For regulators and implementing organizations, it changes the way they can view reports. Anyone who works with XBRL is familiar with the scenario: a mountain of tags, contexts, and dimensions that only make sense when you run them through a tool. The report that the submitting party sees is a PDF or Word file. The report that the recipient receives is an XML file. Two versions of the same story, with all the associated risk of discrepancies. iXBRL (Inline XBRL) superimposes those two versions. A single file—usually an HTML document—in which the tagged data is embedded directly within the readable report. The accountant reads the report. The receiving organization reads the tagged data. Everyone is looking at the same file.
The report is no longer a “black box” that can only be interpreted after processing. You open the file, see the annual report exactly as the institution intended, and can simultaneously overlay data analysis on top of it. Discussions about “what did the submitter actually mean?” decrease, because context and figures are literally on the same line.
Validation can be both stricter and more transparent. With XBRL, validation occurs in a separate layer that the submitter cannot see. With iXBRL, you can flag errors in the portal right where they occur, with a reference to the original passage. This reduces the number of correction rounds, because the submitter immediately understands what went wrong. Comparability between institutions becomes feasible without having to reconstruct data yourself. Everyone submits data using the same taxonomy, in the same format, with the same tags. Comparing data, benchmarking, and identifying outliers can be largely automated.
iXBRL does not guarantee better data quality. If the source is flawed, the file will be flawed too. What iXBRL does do is make it harder to conceal issues. Everything is contained in a single document, complete with tags. Ambiguities regarding origin or interpretation are more likely to stand out. Furthermore, iXBRL is no smaller a project than XBRL. The taxonomy must be accurate. The filing rules must be clear. The portal must provide proper guidance to submitters. And the recipient must know what is coming in and how that data stream fits into the existing process.
The Dutch Chamber of Commerce (KVK) is already using iXBRL for annual financial statements. At DUO, the pilot year for annual financial reporting in education started in September 2026. ESMA mandates iXBRL for publicly traded companies (ESEF). At the Dutch Tax and Customs Administration, iXBRL is in the pipeline for, among other things, inheritance and gift taxes. And if, as a company, you prepare your sustainability report in accordance with the CSRD and submit it to the regulator, you are required to do so in iXBRL. Any regulator or implementing organization that still processes data exclusively in XBRL will face challenges in this regard in the coming years.
iXBRL is not a technical decision you can leave up to a vendor. It affects how you structure your supervisory or implementation process: what errors you want to identify and when, how much guidance you provide to your data providers, and what you’ll ultimately do with the richer data. It’s best to have that discussion before you issue a request for proposals, not after.