XBRL Custom Extension Taxonomy: 2026 How-To Guide

XBRL Custom Extension Taxonomy: 2026 Practitioner Guide

If you're staring at a disclosure that doesn't map cleanly to any US-GAAP or IFRS element, you're facing the most consequential judgment call in XBRL tagging: extend, or find a way to make a standard element work. Get it wrong in either direction and you're looking at an SEC comment letter, an ESMA enforcement finding, or corrupted time-series data that analysts can't aggregate.

This guide gives you the decision framework, the naming rules, the filing mechanics, and the specific errors regulators flag most often in 2026. It assumes you already know what XBRL is. If you need a broader primer on tagging errors that trigger SEC review, see our XBRL Tagging Errors That Trigger SEC Review guide first.

Key takeaway: Extension taxonomies are a last resort, not a default. The US-GAAP taxonomy contains over 18,000 elements; the IFRS Taxonomy contains approximately 4,000. Exhaust both before you extend.

What Is an XBRL Custom Extension Taxonomy?

An extension taxonomy is a set of schema and linkbase files that import a base taxonomy and add company-specific concepts, relationships, or labels that the base taxonomy doesn't cover. The XBRL International Glossary defines it as a taxonomy "typically created by a different entity from the author of the base taxonomy", in practice, the filer. It is submitted alongside the instance document, not in place of it.

Extension taxonomies do not modify the base taxonomy. They layer on top of it. The SEC EDGAR Filer Manual is explicit: filers may add new elements and new relationships, but they cannot alter the semantics of any existing US-GAAP element. That prohibition is absolute.

Technically, an extension taxonomy consists of:

• A schema file (.xsd) that imports the base taxonomy and declares new elements
• Linkbase files (.xml) for labels, references, presentation, calculation, and definition relationships
• A packaging structure (ZIP for EDGAR, XHTML package for ESEF) that the filing system can process

When to Create a Custom Extension Element

The answer to "should I extend?" is almost always: not yet. Follow this decision sequence before creating anything new.

Step 1: Search the base taxonomy thoroughly

The FASB US-GAAP taxonomy for 2025 contains over 18,000 elements. The FASB's Element Guidance resource provides plain-language descriptions to help you search by concept, not just by label string. Use the FASB XBRL Viewer and search synonyms, not just your exact disclosure wording.

For ESEF filers, the IFRS Taxonomy 2024 contains approximately 4,000 elements, including "common practice" elements that are not mandatory but are included because they appear frequently. Deloitte IAS Plus flags this as a persistent mistake: filers extend for line items already covered by common practice elements they simply didn't find.

Step 2: Consider a dimension or member instead

Before creating a new line-item element, ask whether a dimension/member combination on an existing element would capture the fact accurately. A standard element tagged with a custom domain member is far preferable to a new monetary concept. The XBRL International Filing Rules Checklist identifies domain members as the most common and least risky extension type; new dimensions and hypercubes are progressively more complex and error-prone.

Step 3: Extend only as a last resort

If no standard element fits, and no dimension/member combination works, then create a custom extension element. As Workiva's documentation puts it: "Sometimes standard taxonomy concepts do not fit a value in your report. To tag the value accurately, you need to create a custom (or extension) concept, which are unique to your company."

PwC's iXBRL guidance formalises the same hierarchy: search first, consider dimensions second, extend third.

Key takeaway: XBRL US DQC Rule 0011 automatically flags extension elements whose labels closely match an existing US-GAAP element label. It is consistently among the top five most-triggered DQC rules in SEC filing validation. If your extension label matches a standard element, you almost certainly don't need to extend.

Extension type decision table

How to Name Extension Elements Correctly

Naming errors are among the most common extension mistakes flagged by the SEC's Office of Structured Disclosure. Both the EFM and ESEF rules specify naming conventions; violating them produces technically invalid or non-interoperable filings.

Namespace format (SEC/EDGAR)

The SEC EDGAR Filer Manual requires that the extension namespace include the registrant's domain name or stock ticker and the period end date. The format looks like this:

Correct: http://www.company.com/20241231

Incorrect: http://www.company.com/extensions (no period date, not unique across filings)

This ensures each filing's extension namespace is unique and traceable. Nokia's EDGAR filing, for example, used http://www.nokia.com/20181231 as its namespace and http://www.nokia.com/role/StatementConsolidatedIncomeStatement as a link role, per the XBRL International Filing Rules Checklist.

Element naming: the LC3 convention

Extension element names must follow the LC3 (Lower Camel Case with Capitalised Components) convention used throughout the US-GAAP and IFRS taxonomies. Derive the element name from the standard label.

• Correct: DeferredRevenueFromLoyaltyPrograms
• Incorrect: deferred_revenue_loyalty or DeferredRevenueLoyaltyProg

For ESEF, element names must also follow LC3, and filing rules should specify how non-ASCII characters in non-English labels are handled.

Labels: what you must include

Every extension element needs at minimum:

• A standard label (used in rendering, must be unique across the extension taxonomy)
• A documentation label (verbose description, appears in the SEC Viewer and EDGAR)
• Optionally, a terse label for repeated captions in tables

The SEC's structured data review increasingly focuses on label quality. Missing or misleading documentation labels make extension elements uninterpretable to data consumers and are flagged in comment letters.

SEC EDGAR Rules and Consequences

The SEC's enforcement mechanism for extension quality is the comment letter, and those letters are public. The SEC's Office of Structured Disclosure (OSD) runs an ongoing structured data review programme. When it identifies problematic extensions, it issues a comment letter requesting explanation or correction. These letters appear on EDGAR and are visible to investors and analysts.

The most common extension errors the OSD flags include:

1. Over-extension: Creating a custom element for a concept that already exists in the US-GAAP taxonomy. This is the most frequent error and the one DQC Rule 0011 is designed to catch.
2. Wrong balance type: Marking a debit-balance monetary item as credit, or vice versa. For a gain/loss element, the balance type should reflect the positive value.
3. Wrong period type: Using instant for a flow concept (revenue, expense) or duration for a point-in-time concept (cash balance, shares outstanding).
4. Missing calculation relationships: Extension monetary elements that represent subtotals or totals must participate in calculation relationships. Omitting them breaks automated validation.
5. Inconsistent labels: Standard label doesn't match the disclosure text, or the documentation label is missing.

Since the SEC's Inline XBRL mandate was fully phased in (large accelerated filers by 2019, accelerated filers by 2020, all others by 2021), extension errors are embedded in the HTML filing itself, not buried in a separate exhibit. They are more visible than ever.

For AI-assisted tagging workflows, see our AI XBRL Tagging Automation guide for how extension decisions interact with automated tagging tools.

ESEF Rules: The Anchoring Requirement

ESEF has one extension rule that has no equivalent in the SEC framework: anchoring. Every extension element used for a primary financial statement line item must be linked to the nearest IFRS Taxonomy element using a "wider-narrower" relationship, per the ESMA ESEF Reporting Manual.

Anchoring tells data consumers how a company-specific concept relates to the closest standard IFRS concept. Without it, cross-filer comparison is impossible. ESMA's 2023 ESEF implementation report found that anchoring errors remained one of the most prevalent issues across EU filers, with a significant proportion of reviewed filings containing at least one anchoring deficiency.

Key anchoring rules:

• Extensions on primary statement line items must be anchored. This is a reportable error if omitted.
• Extensions used only in notes are not required to be anchored, but anchoring is still recommended.
• The anchoring relationship is defined in the definition linkbase, using the XBRL International guidance on leveraging XBRL relationships for anchoring.

National competent authorities (NCAs) in EU member states enforce ESEF compliance. ESMA coordinates and publishes annual implementation quality reports.

Packaging and Submitting Your Extension Taxonomy

The extension taxonomy must be packaged correctly or the filing system will reject it. The technical requirements differ between EDGAR and ESEF.

For SEC EDGAR filings

1. The .xsd schema file imports the base US-GAAP taxonomy schema and declares all new elements with their data types, balance types, period types, and abstract flags.
2. Separate linkbase .xml files define label, reference, presentation, calculation, and definition relationships.
3. The package is submitted as part of the iXBRL filing. The extension taxonomy files are referenced from the instance document.
4. The namespace in the schema must match the namespace used in the instance document.

For ESEF filings

1. The extension taxonomy is packaged within the XHTML report package (the .zip file submitted to the national filing system).
2. The schema and linkbase files follow the same structure as EDGAR but must also include the anchoring relationships in the definition linkbase.
3. The IFRS Taxonomy version used must be the one specified by ESMA for the reporting period.

Validate before you submit

Run XBRL US DQC rules before submission. The DQC rules are implemented in Arelle (open-source), Workiva, and other major tools. DQC Rule 0011 will flag over-extension; other rules will catch calculation inconsistencies and period type errors. A technically valid filing can still be semantically wrong, so DQC validation is a floor, not a ceiling.

The Annual Taxonomy Update Cycle

Extension maintenance is an ongoing obligation, not a one-time task. The FASB releases an updated US-GAAP taxonomy each October/November for the following fiscal year. The IFRS Foundation releases an updated IFRS Taxonomy annually.

When the base taxonomy updates, two things can happen to your extensions:

• A standard element is added that now covers a concept you previously extended for. You should retire the extension and map to the new standard element in your next filing.
• An existing standard element is modified in a way that affects your calculation or presentation relationships. Review and update accordingly.

Cross-period consistency matters for a separate reason: data consumers and analysts build time-series models on XBRL data. If you create a new extension element each year for the same concept instead of reusing the element from prior periods, you break the time series. Reuse the same extension element name and namespace (updated for the new period end date) across annual and interim filings for the same concept.

When Extensions Are Structurally Required

Extensions aren't always a choice. The SEC's Pay vs. Performance rules (effective 2022, first filings 2023) introduced the Executive Compensation Disclosure (ECD) taxonomy, which requires extension elements for company-specific compensation metrics. Filers must map those extensions back to the ECD taxonomy using the Disclosure Mapping attribute in their tagging tool.

This is a useful reminder that the extension framework exists to serve legitimate disclosure needs, not just to accommodate sloppy tagging.

AI Tools and Extension Decisions

AI-assisted XBRL tagging tools from vendors including Workiva and Donnelley Financial Solutions now include extension suggestion features that analyse disclosure text and recommend whether to use a standard element or create a custom one. These tools are useful for catching obvious over-extension cases, but they are not reliable enough to replace human review for complex or novel disclosures.

For a detailed look at where AI tagging tools help and where they fall short, see our AI XBRL Tagging Accuracy guide.

The XBRL International Filing Rules Checklist draws a distinction worth keeping in mind: filing rules are technical constraints; business validation rules enforce semantic correctness. A filing can pass every technical check and still tag the wrong concept. That judgment call remains human.

FAQ

Can I modify an existing US-GAAP or IFRS taxonomy element in my extension? No. The SEC EFM explicitly prohibits modifying or redefining existing base taxonomy elements. You can add new elements, new relationships, and new labels, but you cannot change the semantics of a standard element.

What happens if I over-extend and the SEC finds it? The SEC's Office of Structured Disclosure issues a comment letter requesting explanation or correction. These letters are publicly available on EDGAR. Depending on the severity, you may need to refile. The letters are also visible to investors and data analysts, making extension errors a reputational issue as well as a compliance one.

Do I need to anchor extension elements in EDGAR filings? No. Anchoring is an ESEF-specific requirement under ESMA's ESEF Reporting Manual. It has no equivalent in the SEC/EDGAR framework.

How do I know if a standard element already exists for my concept? Search the FASB XBRL Viewer and Element Guidance resource using synonyms and related terms, not just your exact label. For ESEF, also search the IFRS Taxonomy's common practice elements, which are frequently overlooked. Run DQC Rule 0011 validation after tagging to catch cases where your extension label closely matches a standard element label.

Should I create a new extension element each year for the same concept? No. Reuse the same extension element across reporting periods. Creating a new element each year breaks time-series comparability for data consumers and is a common error that regulators and analysts flag.

Who reviews extension taxonomy quality during an audit? XBRL International's taxonomy review guidance identifies preparers, auditors, and data collectors as having distinct roles. As XBRL becomes more embedded in the audit process, auditors are increasingly expected to review extension quality, not just the financial statements themselves. Discuss extension review scope with your audit team before the close.