Inline XBRL vs XBRL: The 2026 Comparison Finance Teams Need

If your team is still asking whether to use XBRL or Inline XBRL, the answer is already settled: traditional XBRL is effectively retired for every major regulatory mandate. The SEC replaced it with Inline XBRL (iXBRL) via Release No. 33-10514 in 2018, and the phase-in is long complete. What matters now is understanding exactly what iXBRL requires, where it is expanding, and what that means for your filing workflow, software stack, and ESG disclosure obligations in 2026.

This article is for CFOs, controllers, and ESG reporting teams at companies subject to SEC, ESMA/ESEF, HMRC, or JFSA filing requirements. If you want the tagging errors that trigger SEC comment letters, see our Inline XBRL Tagging Errors in 10-K Filings: 2026 Practitioner Guide.

What Is the Difference Between XBRL and Inline XBRL?

The core difference is structural: traditional XBRL required two separate documents; iXBRL produces one. Under the original XBRL mandate (adopted by the SEC in January 2009), filers had to generate an HTML financial statement for human readers and then tag a copy of that data to create a distinct XBRL exhibit (.xml file) attached as a filing exhibit. Those two documents had to match perfectly, and they frequently did not.

iXBRL solves this by embedding XBRL tags directly into the HTML document itself. The result is a single file that renders as a normal financial report in any standard browser while simultaneously carrying machine-readable structured data that regulators, analysts, and automated systems can extract without any additional conversion step.

As the SEC's EDGAR structured data page puts it:

"Inline XBRL is a structured data language that allows filers to prepare a single document that is both human-readable and machine-readable, so that filers need only prepare one Inline XBRL document rather than generate an HTML document of their financial statement information or risk/return summary information and then tag a copy of the data to create a separate XBRL exhibit."

The table below summarises the key differences at a glance.

Why Traditional XBRL Failed (and Why iXBRL Was Necessary)

The two-document problem was not a minor inconvenience; it was a systematic data quality failure. When filers had to maintain separate HTML and XBRL versions of the same financial statements, discrepancies crept in constantly. A number revised in the HTML draft would not always get updated in the XBRL exhibit. Taxonomy element choices made under deadline pressure were not always consistent with the human-readable presentation. The SEC's own structured data infrastructure was receiving XBRL exhibits that did not accurately reflect the filed financial statements.

This is why the SEC's 2018 rulemaking was not an incremental update. It was a structural fix. By requiring iXBRL, the Commission eliminated the reconciliation step entirely. There is now one document, one set of tagged values, and one source of truth for both human readers and automated systems.

The Workiva blog, widely cited at the time, described iXBRL as "voluntary" when it was published around 2018. That description is now factually incorrect and potentially misleading. iXBRL has been mandatory for large accelerated filers since fiscal years ending on or after June 15, 2019, for accelerated filers since June 15, 2020, and for all other filers since June 15, 2021.

What the SEC Actually Requires: iXBRL by Form

Every major SEC periodic report now requires iXBRL. Traditional separate XBRL exhibits are not accepted for covered filings.

The SEC's structured data page sets out the current scope:

Domestic operating companies:

• Form 10-K: full financial statements, footnotes, schedules, auditor information, and cover page
• Form 10-Q: financial statements and cover page
• Form 8-K: cover page and certain revised financial statements
• Proxy and information statements: certain specified disclosures
• Certain non-IPO registration statements

Foreign private issuers:

• Form 20-F: financial statements, footnotes, schedules, auditor information, and cover page
• Form 40-F: same scope
• Form 6-K: certain revised financial statements
• Certain non-IPO registration statements

Beyond financial statements, the SEC has extended iXBRL to:

• Pay versus performance disclosures
• Resource extraction payments
• Filing fee disclosures
• Employee stock purchase and savings plan annual reports

Investment companies face their own iXBRL scope:

• Open-end funds: risk/return summaries in Form N-1A prospectuses; tailored shareholder reports in Form N-CSR
• Closed-end funds and BDCs: specified Form N-2 prospectus items and cover pages; BDCs also tag Exchange Act reports to the same extent as operating companies
• Variable contract registrants: specified prospectus items on Forms N-3, N-4, and N-6
• Non-variable annuity issuers on Form N-4

The mandate has also reached broker-dealers, clearing agencies, security-based swap dealers (SBSDs), major security-based swap participants (MSBSPs), and national securities exchanges, each with specific iXBRL requirements for their annual reports and registration forms.

Key takeaway: If your organisation files any of the above forms with the SEC, you are already required to file in iXBRL. The question is not "which format do we use?" but "is our iXBRL compliant?"

How iXBRL Works Technically: Taxonomies, Tags, and Extensions

iXBRL takes the HTML standard used for web pages and embeds additional semantic tags that give meaning to figures and statements in a computer-readable format. Those tags reference a taxonomy, which is a dictionary of standardised concepts published by a recognised standard-setter.

For US GAAP filers, the relevant taxonomy is maintained by FASB and referenced through the US GAAP taxonomy. For IFRS reporters, the IFRS Foundation publishes the IFRS taxonomy, where concept names such as ifrs:Revenue provide globally consistent labels for financial data points.

Where a company's disclosures do not fit the base taxonomy, iXBRL supports extension taxonomies: entity-specific additions that allow companies to tag unique operating segments or custom disclosures. This flexibility addresses a key early criticism of XBRL, which was that it could not accommodate the real-world diversity of financial statements.

iXBRL also supports tagging of narrative text disclosures, not just numerical figures. This means qualitative footnote information can be machine-readable, a significant capability expansion over early XBRL implementations that focused almost exclusively on numbers.

Viewing iXBRL requires no specialised software. The SEC has built an open-source Inline XBRL Viewer directly into EDGAR, accessible via any modern browser (Chrome 90+, Firefox 88+, Safari iOS 14+, Edge 90+, IE 11). Users can click on individual tagged data points to see citations and hyperlinks to relevant accounting guidance, narrative definitions, and reporting period information. That contextual metadata was simply inaccessible in the old separate-exhibit structure.

iXBRL Around the World: SEC, ESEF, HMRC, and JFSA Compared

iXBRL is not a US-centric requirement. It is the de facto global standard for structured financial reporting, with meaningful differences in taxonomy, scope, and enforcement across jurisdictions.

Key practical differences for international filers:

• ESEF (EU): ESMA mandates iXBRL as the technical standard for all EU public companies reporting under IFRS for annual financial statement filings commencing on or after January 1, 2021. The ESEF taxonomy is an extension of the IFRS taxonomy, and companies must also tag primary financial statements with anchoring to the base taxonomy. Footnotes are tagged as blocks of text rather than at the individual element level in the initial phase.
• HMRC/Companies House (UK): The UK's iXBRL population is one of the largest in the world. Over 2 million companies file iXBRL annually, demonstrating that the standard scales well beyond large listed companies to mid-market and smaller entities.
• JFSA (Japan): Over 9,000 listed companies and investment funds submit iXBRL financial statements to the JFSA, confirming global adoption beyond Western markets.
• SEC vs ESEF taxonomy: US GAAP filers use the FASB-maintained US GAAP taxonomy; IFRS filers use the IFRS Foundation taxonomy. A foreign private issuer filing a Form 20-F under IFRS uses the IFRS taxonomy, not the US GAAP taxonomy. Getting this wrong is a common source of tagging errors.

iXBRL and ESG: The Next Wave of Mandatory Tagging

This is the gap that most existing articles on this topic miss entirely. iXBRL is no longer just a financial reporting format. Starting in 2023 and accelerating rapidly, securities regulators worldwide are mandating iXBRL for statutory sustainability disclosures.

XBRL International states explicitly: "Starting in 2023 and accelerating quickly across the world a wide range of securities regulators are obliging the use of XBRL in statutory sustainability disclosures."

What this means in practice for ESG teams in 2026:

• ESRS/CSRD: The European Sustainability Reporting Standards require structured digital tagging of sustainability disclosures. ESMA has developed a taxonomy for ESRS disclosures, and iXBRL is the technical format underpinning the digital reporting requirement for in-scope companies under the Corporate Sustainability Reporting Directive.
• ISSB S1 and S2: The IFRS Foundation, which publishes the IFRS taxonomy used for iXBRL financial statement tagging, is developing a sustainability disclosure taxonomy to support iXBRL tagging of IFRS S1 (general sustainability disclosures) and IFRS S2 (climate disclosures). This taxonomy will provide the structured vocabulary for machine-readable sustainability reporting in jurisdictions that have adopted or are adopting ISSB standards.
• Early voluntary filings: Aviva, the UK insurance company, has already published an integrated financial and sustainability report in iXBRL format, demonstrating that the technology is production-ready for sustainability data, not just financial statements.
• SEC climate disclosure: The SEC's climate disclosure rule remains stayed as of mid-2026, but the structured data infrastructure being built globally for sustainability reporting will inevitably intersect with any future SEC climate tagging requirements.

For CFOs and ESG teams, the practical implication is clear: the iXBRL tagging capability you build or procure for financial reporting will need to extend to sustainability disclosures. Teams that treat iXBRL as a finance-only compliance checkbox are already behind the curve.

For a detailed walkthrough of IFRS S1 disclosure requirements and how they interact with structured reporting, see our IFRS S1 Disclosure Requirements: 2026 Practitioner Walkthrough.

iXBRL and Your Audit Process: What Changes

The single-document structure of iXBRL changes the ICFR review process in ways that many audit teams have not fully worked through.

Under traditional XBRL, the XBRL exhibit was often treated as a back-office compliance task, reviewed separately (if at all) from the main financial statements. The reconciliation between the HTML and the XBRL exhibit was a control point that was frequently weak or missing.

With iXBRL, the tagged data and the human-readable presentation are the same document. This means:

• Tagging errors are disclosure errors. A wrong element selection or an incorrect value in an iXBRL tag is not just a technical filing defect; it is a misrepresentation in the filed document itself.
• ICFR scope should include iXBRL data quality. Controls over the tagging process, element selection, extension taxonomy use, and pre-submission validation should be part of your internal controls over financial reporting framework, not an afterthought.
• The XBRL US Data Quality Committee (DQC) rules are the de facto validation standard for iXBRL filings. Running DQC validation before submission catches the category of errors most likely to generate SEC comment letters. The XBRL US Data Quality Committee publishes these rules openly.
• Auditors are increasingly reviewing iXBRL tagging as part of the audit process, particularly for large accelerated filers. The question of whether iXBRL data is subject to audit attestation remains an evolving area, but the direction of travel is toward greater auditor involvement.

For a deeper treatment of AI-assisted tagging and accuracy evaluation, see our AI XBRL Tagging Accuracy: Evaluation Guide for SEC Filers (2026).

Software and Workflow: What iXBRL Actually Requires

You cannot produce compliant iXBRL by hand-coding HTML. The tagging process requires software that can apply taxonomy elements, manage extension taxonomies, validate against DQC rules, and generate the iXBRL output in a format EDGAR will accept.

The main options for most companies:

1. Filing agent with iXBRL capability: Outsourcing to a filing agent (Donnelley Financial Solutions, Workiva, Toppan Merrill, and others) is the most common approach for companies without dedicated XBRL resources. The agent handles tagging, validation, and EDGAR submission. The risk is that the finance team loses visibility into tagging decisions and may not catch errors before submission.

2. In-house iXBRL software: Platforms like Workiva allow finance teams to manage the tagging process internally, with built-in taxonomy management and validation. This gives more control but requires trained staff and ongoing taxonomy maintenance as FASB and IASB update their taxonomies annually.

3. AI-assisted tagging: Emerging tools use AI to automate element selection and tagging. Accuracy varies significantly by vendor and document complexity. If you are evaluating AI tagging tools, the evaluation framework in our AI XBRL Tagging Accuracy guide sets out what to test for.

Regardless of approach, the pre-submission checklist should include:

• EDGAR validation (the basic technical check)
• DQC rule validation (the substantive data quality check)
• Human review of tagged values against the human-readable financial statements
• Sign-off by someone with taxonomy knowledge, not just the preparer

FAQ

What is the difference between XBRL and iXBRL? Traditional XBRL required two separate files: an HTML financial statement and a distinct XBRL exhibit. iXBRL embeds structured data tags directly into the HTML document, producing a single file that is both human-readable and machine-readable. The SEC replaced the traditional two-document approach with mandatory iXBRL via Release No. 33-10514, adopted June 28, 2018.

Does my company still need to file traditional XBRL with the SEC? No. Traditional separate XBRL exhibits are no longer accepted for covered SEC filings. All domestic operating companies and foreign private issuers subject to the SEC's structured data requirements must file in iXBRL. The phase-in completed with all remaining filers required to comply for fiscal years ending on or after June 15, 2021.

What does an iXBRL instance document mean? An iXBRL instance document is the single HTML file that contains both the human-readable financial statements and the embedded XBRL tags. It is the complete filing document, not a separate exhibit. The tags within it reference a taxonomy (such as the US GAAP taxonomy or IFRS taxonomy) to give each data point a standardised, machine-readable meaning.

Is ESEF the same as iXBRL? ESEF (European Single Electronic Format) is ESMA's mandatory reporting format for EU public companies reporting under IFRS. iXBRL is the technical standard that ESEF is built on. So ESEF filings are iXBRL filings, but with an ESEF-specific taxonomy extension layered on top of the IFRS base taxonomy. The mandate applies to annual financial statement filings for reporting periods commencing on or after January 1, 2021.

Is iXBRL coming to sustainability and ESG reporting? Yes, and it is already arriving. XBRL International confirmed that from 2023 onward, a growing range of securities regulators are mandating iXBRL for statutory sustainability disclosures. ESMA has developed a taxonomy for ESRS disclosures under CSRD, and the IFRS Foundation is developing a sustainability taxonomy for ISSB S1 and S2 tagging. ESG teams should treat iXBRL capability as a sustainability reporting requirement, not just a financial reporting one.

Can investors and analysts actually use iXBRL data? Yes, and this is a primary driver of the mandate. The SEC's EDGAR iXBRL Viewer allows anyone with a modern browser to click on individual tagged data points and see the underlying accounting guidance, definitions, and reporting period context. Beyond the viewer, iXBRL data can be loaded into analytics engines, queried in databases, and processed into comparative reports, all while retaining a traceable link back to the original filed document. This auditability of data provenance is a material improvement over the traditional XBRL exhibit approach.