# Prepared by SEC Staff > Briefs, arguments, decisions, and more. URL: https://www.frixlaw.com/law-library/documents/agency%3Asec%3A43f8ee8bfc54673d ## Record - **Collection:** Agency decision - **Document type:** Agency decision ## Text EDGAR XBRL Guide Prepared by SEC Staff June 2026 Disclaimer The Securities and Exchange Commission (“SEC” or “Commission”) staff is making available to the public this EDGAR Extensible Business Reporting Language (“XBRL”) Guide to assist filers with preparing submissions on EDGAR using XBRL. This guide should not be relied upon for any other purpose. Filers may consult the separate EDGAR XBRL Guide (Filing Fee Extract) for references in connection with preparing fee-related submissions on EDGAR using XBRL. The SEC has not approved, may approve or disapprove, and may revise any of the content of this EDGAR XBRL Guide. SEC staff’s provision of this guide does not indicate Commission approval or disapproval of any changes relating to the EDGAR system or the rules and regulations related to EDGAR, including but not limited to the EDGAR Filer Manual. Filers are reminded that they must comply with the requirements of the EDGAR Filer Manual. EDGAR® and EDGARLink® are registered trademarks of the Securities and Exchange Commission. All other product brand names mentioned herein are trademarks or registered trademarks of their respective holders. 2 Contents 1 FUNDAMENTALS ......................................................................................................... 11 2 XBRL SPECIFICATIONS ............................................................................................ 23 3 INSTANCE VALIDATIONS......................................................................................... 24 1.1 1.1.1 1.1.2 1.1.3 1.2 1.2.1 1.2.2 1.3 1.4 1.5 1.6 Set Definitions ............................................................................................................................... 13 Submission Sets ............................................................................................................................. 14 Entity Sets ...................................................................................................................................... 16 Instance Types ............................................................................................................................... 16 Taxonomy Entry Points ................................................................................................................. 18 Entry Point Name and URL Conventions ...................................................................................... 18 Standard Taxonomies..................................................................................................................... 19 Instance Types and Standard Taxonomies ..................................................................................... 20 Attachment types ........................................................................................................................... 21 Restrictions on EDGAR Modules .................................................................................................. 22 Errors, Suspension, and Rendering ................................................................................................ 23 3.1 Expected Facts in the Required Context ........................................................................................ 25 3.1.1 Notation and Terminology ............................................................................................................. 26 3.1.2 Required Context validation .......................................................................................................... 27 3.1.3 Central Index Key .......................................................................................................................... 28 3.1.4 Registrant Name ............................................................................................................................ 28 3.1.5 Form or Exhibit Type..................................................................................................................... 29 3.1.6 Amendment Flag and Description ................................................................................................. 30 3.1.7 Document Period End Date ........................................................................................................... 31 3.1.8 Document Fiscal Year and Period Focus ....................................................................................... 32 3.1.9 Current Reporting Status and Interactive Data Current ................................................................. 32 3.1.10 Voluntary Filers, Shell Companies, and Well-known Seasoned Issuers ................................... 33 3.1.11 Small Business, Emerging Growth Company ........................................................................... 34 3.1.12 Current Fiscal Year End Date .................................................................................................... 36 3.1.13 Filer Category (Accelerated / Non-Accelerated) ....................................................................... 37 3.1.14 ICFR Auditor Attestation Flag .................................................................................................. 38 3.1.15 Public Float ................................................................................................................................ 39 3.1.16 Auditor Name, Location, and Firm ID ...................................................................................... 39 3.1.17 Investment Company Type........................................................................................................ 41 3.1.18 File Number (Securities Act File Number) ............................................................................... 41 3.1.19 Incorporation State / Country Code ........................................................................................... 42 3.1.20 Tax Identification Number ........................................................................................................ 42 3.1.21 Primary SIC (Standard Industrial Code) Number ..................................................................... 42 3.1.22 Principal Office Address ........................................................................................................... 43 3.1.22.1 Street, City and Zip.................................................................................................................... 43 3.1.22.2 Street Address Lines 2 and 3 ..................................................................................................... 43 3.1.22.3 State or Province and Country ................................................................................................... 44 3.1.22.4 Phone ......................................................................................................................................... 45 3 3.1.23 Submission Flags ....................................................................................................................... 45 3.1.23.1 Annual Report, Transition Report, Quarterly Report ................................................................ 46 3.1.23.2 Financial Statement Error Correction, Recovery Analysis........................................................ 47 3.1.23.3 Non-US Filer Flags.................................................................................................................... 48 3.1.23.4 Period Start Date........................................................................................................................ 49 3.1.23.5 Bankruptcy Proceedings Flag .................................................................................................... 50 3.1.23.6 Documents Incorporated by Reference ..................................................................................... 50 3.1.23.7 Current Report ........................................................................................................................... 50 3.1.23.8 Material Cybersecurity Incident Disclosure .............................................................................. 51 3.1.24 Closed-end fund registration ..................................................................................................... 51 3.1.24.1 N-2 Registration file numbers ................................................................................................... 51 3.1.24.2 N-2 Registration Amendment Numbers .................................................................................... 52 3.1.24.3 N-2 Commencement of Sales .................................................................................................... 54 3.1.24.4 N-2 Rule Flags ........................................................................................................................... 54 3.1.24.5 N-2 Effectiveness Dates ............................................................................................................ 55 3.1.24.6 N-2 Other Flags ......................................................................................................................... 55 3.1.24.7 N-2 Registrant Type Flags......................................................................................................... 56 3.2 Expected Facts with Dimensions ................................................................................................... 57 3.2.1 Business contact ............................................................................................................................. 59 3.2.1.1 Contact Person ........................................................................................................................... 59 3.2.1.2 Street, City and Zip.................................................................................................................... 60 3.2.1.3 State or Province and Country ................................................................................................... 61 3.2.1.4 Phone ......................................................................................................................................... 62 3.2.2 Former address ............................................................................................................................... 62 3.2.2.1 Former Street, City and Zip ....................................................................................................... 62 3.2.2.2 Former State or Province and Country ...................................................................................... 63 3.2.3 Common Stock Shares Outstanding .............................................................................................. 64 3.2.4 Registered Securities...................................................................................................................... 65 3.2.4.1 Security Title ............................................................................................................................. 65 3.2.4.2 Exchanges Axis ......................................................................................................................... 66 3.2.4.3 Security Exchange Name........................................................................................................... 66 3.2.4.4 Trading Symbol / No Trading Symbol ...................................................................................... 67 3.2.4.5 Security Reporting Obligation ................................................................................................... 68 3.2.5 Open-end Fund Series .................................................................................................................... 68 3.2.6 Open-end Fund Shareholder Reports ............................................................................................. 68 3.2.7 Employee Benefit Plans ................................................................................................................. 70 3.3 Resource Extraction Payments Disclosure .................................................................................... 70 3.3.1 Alternative Reporting Regime ....................................................................................................... 70 3.3.2 Currency and Total Payments ........................................................................................................ 71 3.3.3 Payments Axis ............................................................................................................................... 71 3.3.4 Boolean, Numeric and String Valued Facts ................................................................................... 71 3.3.5 Member-valued Facts..................................................................................................................... 72 3.3.6 Payment Contexts .......................................................................................................................... 74 3.3.7 Government Aggregate Contexts ................................................................................................... 76 4 3.3.8 3.4 3.5 Project Aggregate Contexts ........................................................................................................... 76 Self-Regulatory Organization (SRO) Disclosures ......................................................................... 77 Special Purpose Acquisition Company (SPAC) Disclosures......................................................... 77 4 FILING FEE EXHIBITS ............................................................................................... 79 5 CUSTOM TAXONOMIES .......................................................................................... 105 4.1 4.1.1 4.1.2 4.1.3 4.1.4 4.2 4.3 4.4 4.5 4.5.1 4.5.2 4.5.3 4.5.4 4.5.5 4.5.6 4.5.7 4.5.8 4.5.9 4.5.10 4.6 4.6.1 4.6.2 4.6.3 4.7 4.7.1 4.7.2 4.8 4.8.1 4.8.2 4.8.3 5.1 5.2 5.3 5.4 5.4.1 5.4.2 5.4.3 5.5 5 Filing Fee Inline XBRL Attachments ............................................................................................ 79 Security Types Based on Rule ....................................................................................................... 80 Offering & Transaction Valuation Rules Applicable for Submission Types................................. 81 Offset Table & Combined Prospectus Rules Applicable for Submission Types ........................... 83 Submission Type to Form or Filing Type mapping ....................................................................... 84 Submission Table ........................................................................................................................... 86 Fees Summary Table...................................................................................................................... 88 Offering Table................................................................................................................................ 90 Offering Table Rule Flags ............................................................................................................. 90 Rule 457(a) Lines........................................................................................................................... 91 Rule 457(o) Lines .......................................................................................................................... 92 Rule 457(r) Lines ........................................................................................................................... 93 Rule 457(s) Lines ........................................................................................................................... 94 Rule 457(u) Lines .......................................................................................................................... 95 Rule “Other” Lines ........................................................................................................................ 96 Rule 415(a)(6) Lines ...................................................................................................................... 97 Rule 0-11 Lines .............................................................................................................................. 98 Rule 457(f) Lines ........................................................................................................................... 99 General Instructions II.H (Exchange Offers) and II.I (Business Combinations)..................... 100 Offset Table ................................................................................................................................. 100 Offset Table Rule Flags ............................................................................................................... 101 Rule 457(b) or 0-11(a)(2)) Lines ................................................................................................. 101 Rule 457(p) Lines ........................................................................................................................ 102 Combined Prospectus Table ........................................................................................................ 103 Combined Prospectus Table Rule Flags ...................................................................................... 103 Combined Prospectus Lines Specifying Rule 429 ....................................................................... 103 Securities, 424I ............................................................................................................................ 104 Securities, 424I Table Rule Flags ................................................................................................ 104 Submission Type 424I Table Lines ............................................................................................. 104 Submission Type 424I Entries in the Submission Table ............................................................. 105 Custom presentation and label relationships for standard concepts............................................. 105 File attachments for custom relationships .................................................................................... 106 Custom presentation and label relationships................................................................................ 106 Custom relationships for standard concepts, with dimensions .................................................... 107 File attachments for custom members ......................................................................................... 107 Dimensional relationships ............................................................................................................ 108 Presentation and label relationships ............................................................................................. 110 Validation of custom relationships .............................................................................................. 110 5.5.1 5.5.2 5.6 5.6.1 5.6.2 5.6.3 5.6.4 5.7 5.8 5.8.1 5.9 5.9.1 5.9.2 5.9.3 5.10 5.10.1 5.10.2 5.10.3 5.10.4 5.10.5 5.10.6 5.11 5.11.1 5.11.2 5.11.3 5.11.4 5.12 Validations resulting in Errors ..................................................................................................... 110 Validations resulting in Warnings ............................................................................................... 111 Custom Concept Declarations in General .................................................................................... 111 Do not duplicate pre-existing concept declarations ..................................................................... 111 Avoid changes in declarations from period to period .................................................................. 111 Custom concept naming ............................................................................................................... 112 Custom concept declarations ....................................................................................................... 112 Custom Domain Member Declarations........................................................................................ 112 Custom Presentation and Label Relationships ............................................................................. 113 Instance type 8K.A example – custom members ......................................................................... 113 Custom Calculation Relationships for Standard Concepts .......................................................... 114 When calculation relationships are required ................................................................................ 115 Avoid calculation relationship redundancy.................................................................................. 117 A single concept may have alternate calculations ....................................................................... 117 Custom Numeric Concepts .......................................................................................................... 118 Do not duplicate numeric concepts ......................................................................................... 118 Monetary concepts................................................................................................................... 118 Share (unit of ownership) type concepts ................................................................................. 119 Per-share type concepts ........................................................................................................... 119 Pure number type concepts ...................................................................................................... 119 Percent type concepts .............................................................................................................. 119 Custom Non-Numeric Concepts .................................................................................................. 120 Custom Non-member Abstract concepts ................................................................................. 120 Custom text block type concepts ............................................................................................. 120 Custom dimensional concepts ................................................................................................. 121 Other custom non-numeric types ............................................................................................. 121 Other Custom Taxonomy Components ....................................................................................... 121 6 INSTANCE CONTENT ............................................................................................... 122 6.1 6.2 6.2.1 6.2.2 6.2.3 6.2.4 6.2.5 6.2.6 6.2.7 6.2.8 6.3 6.3.1 6.3.2 6.3.3 6.4 6.4.1 6 The Related Official Document ................................................................................................... 122 Entities in Instances ..................................................................................................................... 123 Default legal entities .................................................................................................................... 123 Consolidating entities and subsidiaries ........................................................................................ 123 Consolidated entities .................................................................................................................... 123 Contexts for subsidiaries in a consolidating instance .................................................................. 125 Contexts for a consolidating instance .......................................................................................... 125 Contexts for consolidating eliminations ...................................................................................... 126 Dual (or multiple) registrants ....................................................................................................... 126 Employee benefit plan-specific members .................................................................................... 126 Periods in Instances...................................................................................................................... 126 Period types.................................................................................................................................. 126 Reporting periods for non-numeric facts ..................................................................................... 126 Contexts for different reporting assumptions............................................................................... 127 Classes of Stock in Instances ....................................................................................................... 127 Contexts for all classes of stock ................................................................................................... 127 6.4.2 Contexts for a single class of stock .............................................................................................. 127 6.5 Concept Selection for Instances ................................................................................................... 128 6.5.1 Precedence when selecting elements ........................................................................................... 128 6.5.2 Selecting elements based on authoritative references .................................................................. 128 6.5.3 Selecting elements based on data types ....................................................................................... 128 6.5.4 Selecting signs based on the balance attribute ............................................................................. 129 6.5.5 Monetary element negating labels ............................................................................................... 129 6.5.6 Selecting elements based on documentation labels ..................................................................... 130 6.5.7 Changes in elements from period to period ................................................................................. 130 6.5.8 Terse and verbose labels .............................................................................................................. 130 6.6 Units and Decimals in Instances .................................................................................................. 131 6.6.1 The content of a numeric fact never has a scale factor ................................................................ 131 6.6.2 Do not define or use units that imply a scale factor on a currency .............................................. 131 6.6.3 Non-currency units must appear with only one implicit power-of-ten scale factor per instance . 131 6.6.4 Selecting the decimals attribute ................................................................................................... 132 6.7 Inline XBRL Facts in Instances ................................................................................................... 133 6.7.1 Present facts according to location and position in related official documents ........................... 133 6.7.2 Line item element labels .............................................................................................................. 133 6.7.3 Labels for numeric totals ............................................................................................................. 134 6.7.4 Numeric element period start/end labels...................................................................................... 134 6.7.5 When a numeric element label requires a unit designation.......................................................... 135 6.7.6 Do not insert digits that do not appear in visible text .................................................................. 135 6.7.7 No extra facts ............................................................................................................................... 135 6.7.8 No page headers and footer facts ................................................................................................. 135 6.7.9 Multi-tagging ............................................................................................................................... 135 6.7.10 Narrative amounts ................................................................................................................... 136 6.7.11 Nil facts ................................................................................................................................... 136 6.8 Concepts and Facts in Financial Statement Instances .................................................................. 136 6.8.1 Level 1 (Statement and Notes) ..................................................................................................... 137 6.8.1.1 Facts on the face of financial statements ................................................................................. 137 6.8.1.2 Custom elements requiring a balance attribute........................................................................ 140 6.8.1.3 Custom monetary elements without a balance attribute .......................................................... 140 6.8.1.4 Distinct page level footnote facts ............................................................................................ 140 6.8.1.5 Facts for parenthetical disclosures on the face of financial statements ................................... 140 6.8.1.6 Parenthetical item element labels ............................................................................................ 141 6.8.1.7 Presentation groups for parenthetical facts .............................................................................. 141 6.8.1.8 Page level footnotes of the face financials .............................................................................. 141 6.8.1.9 Financial statement Note and Schedule Text Blocks .............................................................. 141 6.8.1.10 Dashes...................................................................................................................................... 142 6.8.2 Level 2 (Policy) Tagging ............................................................................................................. 143 6.8.3 Level 3 (Table) Tagging .............................................................................................................. 143 6.8.4 Level 4 (Detail) Tagging .............................................................................................................. 143 7 7.1 7 INSTANCE RENDERING .......................................................................................... 144 Motivation for Standardized Rendering....................................................................................... 144 7.2 7.3 7.3.1 7.3.2 7.3.3 7.3.4 7.4 7.5 7.6 7.7 7.8 7.9 7.10 7.11 7.12 7.13 7.14 7.15 7.16 7.17 7.18 7.19 7.20 7.21 7.22 7.22.1 7.22.2 Presentation groups ...................................................................................................................... 144 Fact selection ............................................................................................................................... 145 Period Selection ........................................................................................................................... 145 Unit Selection .............................................................................................................................. 146 The Primary Axis ......................................................................................................................... 146 Unselected Facts .......................................................................................................................... 146 Basic Layout using Core and Taxonomy-Defined Dimensions ................................................... 146 Ordering members along a dimension ......................................................................................... 147 Merged columns .......................................................................................................................... 148 Period Start labels ........................................................................................................................ 148 Column Headings and Promotion ................................................................................................ 149 Row Headings and Promotion ..................................................................................................... 149 Footnotes and Merging ................................................................................................................ 149 Flow Through Suppression on Statements................................................................................... 150 Cash Flow Statements .................................................................................................................. 150 Statements of Changes in Shareholder Equity ............................................................................. 150 Layout Qualifiers ......................................................................................................................... 151 Uncategorized Facts ..................................................................................................................... 152 Numeric Formatting ..................................................................................................................... 152 Non-numeric Formatting ............................................................................................................. 152 The Filing Summary .................................................................................................................... 153 Multiple Instances ........................................................................................................................ 154 Workbook Output ........................................................................................................................ 154 Resource Extraction Payment Rendering .................................................................................... 154 Rendering of Mutual Fund Risk/Return Summary Interactive Data ........................................... 155 Embedding Commands............................................................................................................ 155 Bar Charts ................................................................................................................................ 155 8 VALIDATION DETAILS ON ALL XBRL ATTACHMENTS ............................... 156 9 VALIDATION DETAILS ON XBRL INSTANCES ................................................. 161 8.1 8.2 8.3 8.4 8.5 8.6 8.7 8.8 9.1 9.1.1 9.1.2 9.1.3 9.2 9.3 8 File names and character encodings............................................................................................. 156 Standard namespace prefixes ....................................................................................................... 157 Standard locations ........................................................................................................................ 158 Compatible Taxonomies .............................................................................................................. 159 Elements....................................................................................................................................... 159 Element attributes ........................................................................................................................ 160 Element attribute values ............................................................................................................... 160 Attribute value lengths ................................................................................................................. 161 XHTML Validations .................................................................................................................... 161 HTML restrictions on Text Block facts ....................................................................................... 162 HTML restrictions on XBRL footnotes ....................................................................................... 162 HTML restrictions on Inline XBRL ............................................................................................ 162 Labels ........................................................................................................................................... 163 Presentation .................................................................................................................................. 163 9.4 9.5 9.6 9.7 9.8 9.9 9.10 9.11 9.12 Footnote Links ............................................................................................................................. 163 Decimals ...................................................................................................................................... 164 Contexts ....................................................................................................................................... 164 Periods ......................................................................................................................................... 165 Units ............................................................................................................................................. 165 Non-US English Facts.................................................................................................................. 165 Duplicate facts ............................................................................................................................. 166 Linkbase References .................................................................................................................... 167 Deprecated Concepts ................................................................................................................... 167 10 VALIDATION DETAILS ON CUSTOM TAXONOMIES...................................... 167 11 INLINE XBRL RESTRICTIONS ............................................................................... 180 10.1 Custom namespace and role URIs ............................................................................................... 167 10.2 Roles ............................................................................................................................................ 168 10.3 Concepts....................................................................................................................................... 170 10.4 Relationships ................................................................................................................................ 171 10.5 Concept types and relationships................................................................................................... 172 10.6 Concept labels and roles .............................................................................................................. 173 10.7 Rendering validations .................................................................................................................. 174 10.7.1 Each axis that is presented requires at least one child element. .............................................. 174 10.7.2 Matching instant and duration facts......................................................................................... 174 10.7.3 Changes in Equity presentation instant and duration type facts. ............................................. 175 10.7.4 Text blocks containing embedding commands........................................................................ 175 10.7.5 Rows and columns are both required. ..................................................................................... 176 10.7.6 Completeness of axes in an embedding command. ................................................................. 176 10.7.7 Bar Chart selected Annual Return facts................................................................................... 177 10.7.8 The {Elements} token implies "column primary" embedding. ............................................... 177 10.8 Namespace-specific Customizations............................................................................................ 177 10.8.1 CEF (Closed-end Fund) Customization................................................................................... 177 10.8.2 ECD (Executive Compensation Disclosure) Customization ................................................... 178 10.8.3 FFD (Filing Fee Disclosure) Customization............................................................................ 178 10.8.4 OEF (Open-end Fund) Customization ..................................................................................... 178 10.8.5 RXP (Resource Extraction Payments) Customization ............................................................ 179 10.8.6 VIP (Variable Insurance Products) Customization.................................................................. 179 10.8.7 SRO (Self-regulatory Organization) Customization ............................................................... 180 10.8.8 SBS (Security-based Swaps) Customization ........................................................................... 180 10.8.9 CYD (Cybersecurity Disclosure) Customization .................................................................... 180 10.8.10 EBP (Employee Benefit Plan) Customization ......................................................................... 180 10.8.11 SPAC (Special Purpose Acquisition Company) Customization.............................................. 180 11.1 11.2 11.3 11.4 11.5 9 The declaration not supported .............................................................................. 181 Inline XBRL validation................................................................................................................ 181 Element content .............................................................................................................. 181 HTML syntax not allowed in Inline XBRL Documents in EDGAR ........................................... 181 HTML elements allowed in Inline XBRL Documents ................................................................ 182 11.6 11.7 11.8 11.9 11.10 11.11 11.12 11.13 11.14 11.15 11.16 11.17 HTML elements that are not allowed in Inline XBRL Documents ............................................. 183 Nested HTML table elements are not allowed............................................................................. 184 Restrictions on HTML bookmark positions................................................................................. 184 HTML attributes allowed in Inline XBRL Documents ............................................................... 184 HTML attribute values that are not allowed in Inline XBRL Documents............................... 185 Inline XBRL 1.1 features that are not supported by EDGAR ................................................. 185 Inline XBRL Transformation Registries supported by EDGAR ............................................. 185 Other Inline XBRL restrictions ............................................................................................... 187 Hidden element restriction....................................................................................................... 187 Bar Charts in Risk/Return Summary filings ............................................................................ 188 Redlining in Inline XBRL ....................................................................................................... 188 Redaction in Inline XBRL ....................................................................................................... 188 12 CHANGE LOGS ........................................................................................................... 189 12.1 12.2 12.3 Change Log, 2024 ........................................................................................................................ 189 Change Log, 2025 ........................................................................................................................ 192 Change Log, 2026 ........................................................................................................................ 194 Figure 1. Dimension figures color-coding legend ........................................................................ 57 Figure 2. Example showing nine facts with a single taxonomy-defined dimension .................... 57 Figure 3. Example showing a different presentation of the same nine facts ................................ 58 Figure 4. Example showing the nine individual facts ................................................................... 58 Figure 5. Submission types vs EX-98 attachment requirements .................................................. 77 Figure 6. Consequences of absent or invalid EX-98..................................................................... 78 Figure 7. Custom presentation and label relationships, no dimensions ...................................... 107 Figure 8. Dimensional relationships example 1 .......................................................................... 108 Figure 9. Dimensional relationships example 2.......................................................................... 109 Figure 10. Presentation example ................................................................................................. 110 Figure 11. Definition relationships with a custom member........................................................ 113 Figure 12. Examples of custom domain members ...................................................................... 113 Figure 13. Custom presentation and label relationships with a custom member........................ 114 Figure 14. Standard calculation relationships example .............................................................. 115 Figure 15. Custom calculation relationships with standard concepts. ........................................ 115 Figure 16. Fragment of Regulation S-T Definitions ................................................................... 122 Figure 17. Fragment of Rule S-T 405 ......................................................................................... 136 Introduction This EDGAR XBRL Guide provides detailed technical specifications of XBRL formatting and validation for use in connection with making submissions on EDGAR. 10 For all submissions, filers should refer to and must comply with the requirements in the EDGAR Filer Manual (“EFM”). Chapter 6, Volume II of the EFM, Interactive Data, contains requirements for Interactive Data submissions in EDGAR using XBRL. That chapter also explains the use of taxonomies and instances that comprise the XBRL model. Chapter 3, Volume II of the EFM, Index to Forms, contains a discussion of different XBRL formatted documents associated with relevant EDGAR form and submission types. 1 Fundamentals Interactive Data submissions in EDGAR use the Extensible Business Reporting Language (XBRL) information model. To understand the preparation and processing of Interactive Data in EDGAR it is important to be familiar with XBRL’s key ideas and terminology, as well as how XBRL differs from other formats. Facts and Concepts. XBRL defines computer-readable facts for business reporting. A fact represents a single numeric item, or an arbitrarily sized section of text (a non-numeric fact). In EDGAR, a fact that appears in a submission is an assertion being made by a filer to satisfy an SEC disclosure requirement. Each fact is characterized by a set of core standard dimensions: • • • • the period for which the fact is asserted, the business entity that it is about, the human language in which the text is written (US English, in EDGAR), for numeric facts, the unit of measure and number of decimal places that are not significant. Each fact is an occurrence of a concept that makes it comparable to other facts. For example, “Public Float” could be an SEC-defined concept for which a fact “10 billion US dollars, with nine digits (zeroes) not shown” has the same meaning whether it is a fact about entity ABC as of February 14, 2030, or a fact about entity XYZ as of January 12, 2025. Concepts have a data type and validations that constrain their possible values. Continuing the example, facts of the Public Float concept value should not be negative and must be expressed in US Dollars. Instances and Formats. A set of XBRL facts is called an XBRL instance. An instance is computerreadable data that may be stored or transmitted written out in its original XML-based file format (“xBRL-XML”) or embedded into HTML documents (“Inline XBRL”). In XBRL formats currently used in EDGAR, the location of facts within a file has no impact on their meaning. Also, an instance is not necessarily one EDGAR file attachment; Inline XBRL allows instances to be distributed across, and embedded into, more than one file attachment within a submission. XBRL defines the facts of an instance – its information model, not just file formats – and this is a unique defining characteristic of XBRL specifically intended to support technology changes. Taxonomies and Dimensions. Another defining characteristic of XBRL is how concepts are defined via XBRL taxonomies. A taxonomy consists of concepts, along with relationships among concepts and with other computer-readable data. Relationships can be thought of as arcs in a graph, each with a source (or parent) concept and target (or child). The type of relationship is called role of the arc, i.e., its arc role. Some of these relationships describe the various dimensions along which a fact may be characterized. A fact may have any number of taxonomy-defined dimensions, conventionally called axes, each of which has a domain of possible values. As a mnemonic for axes and dimensions, it may be helpful to visualize a physical object such as a book. It has three axes: height, width, and depth. The dimensions of the book might be seven inches high, five inches wide, and one inch deep. Each of the book’s axes has the same domain: positive numbers. Domains may be infinite, like the number of inches, or may have a set of explicit members. For example, a taxonomy might define a “Country” axis, whose explicit members are countries. In this way, the facts 11 “ABC Inc’s Bermuda 2025 Revenue is $10m” and “ABC Inc’s Bonaire 2025 revenue is $10m” are distinct. Their “dimensions” are “country Bermuda” and “country Bonaire”, respectively. For a fact that does not specify an explicit member of an axis, there may be an unstated default member that represents all members of that axis collectively. The fact “ABC Inc’s 2025 Revenue is $20m” therefore refers to its global revenue. A taxonomy specifies for every concept what dimensions are required, permitted, or forbidden for facts of every concept. EDGAR validates each XBRL instance against the relevant taxonomies to ensure that every fact has all the required dimensions and none of those dimensions are forbidden. Modularity and Documentation. EDGAR taxonomies that support specific SEC rule releases are accompanied by technical documents called taxonomy guides that detail the concepts and other aspects of how the taxonomy is used. Since their introduction in 2009, new EDGAR taxonomies have been introduced and have evolved, resulting in differences in naming conventions, organization of files, and other matters. All EDGAR taxonomies are currently updated at least annually, for the most part via an EDGAR release occurring in the first quarter of each calendar year and removed from use after two years. All taxonomies used in an instance must be from the same calendar year but are otherwise technically independent and can be mixed and matched to suit the regulatory disclosures present in a submission. This organization of taxonomies is a different approach than EDGAR’s technical guides for online forms. Meta data. Taxonomies contain several computer-readable relationships other than the dimensiondefining relationships outlined above. A concept in a taxonomy will be annotated with text labels, authoritative references, data quality validations, simple arithmetic calculations, and ordering and nesting relationships among concepts that that detail how software should create a tabular presentation of facts extracted from an instance. These relationships are ideally independent of which SEC Form, EDGAR Submission Type, or Exhibit the concepts will be used for. For example, the concept “Entity Filer Category” has an authoritative reference to the Exchange Act 240.12b-2 which contains definitions of the terms. The Entity Filer Category concept also appears in a presentation link that provides a conventional order of presentation with respect to related concepts such as “Entity Voluntary Filers” and “Entity Well Known Seasoned Issuers” that may appear on the cover page of several different Forms in the same relative positions. In XBRL taxonomies, these relationships are stored in linkbases and may be embedded in XML Schemas; informally, these additional relationships and annotations are taxonomy metadata. They are often first created, reviewed, and used in various tabular styles, leaving the details of the technical syntax to software. Many submission types and exhibits require a filer-constructed custom taxonomy as part of the submission. Validation. An EDGAR submission with XBRL attachments proceeds through multiple validation steps prior to acceptance. The validations are defined at several levels: (a) file format syntax, be that defined by the syntax of XML, XML Schema, XHTML, or XBRL specifications; (b) syntax restrictions that are specific to EDGAR – for example, limitation on the XHTML tags that may appear in Inline XBRL; (c) semantic consistency of the instance – for example, ABC Inc’s Bonaire 2025 cannot be $10m one location in an instance and $11m in another; (d) semantic consistency of the facts and the meta data – for example, if country Barbados is not a dimension, there can be no fact “ABC Inc’s Barbados Inventory”, and if it is present, Inventory should not be a negative number; and (e) submission-, form- and exhibit-specific checks – for example, instance type QF.US should have a reporting period consistent with the 1st, 2nd or 3rd quarter of the company’s fiscal year. 12 All levels contribute to data quality although the term is mainly associated with levels (c), (d) and (e). Generally, the consequences of failed validations are either XBRL Errors, which may cause suspension, or XBRL Warnings, which do not cause suspension. XBRL Submissions. Disclosure requirements that detail which entities are required to make what disclosures at what times and under what circumstances are ultimately to be found in the SEC rules and/or Form instructions. This document covers the steps for making those disclosures, and it details the relevant validations. In that way this document supplements the EDGAR Filer Manual and XBRL specifications, while providing a background for each individual Taxonomy Guide. The high-level steps for an EDGAR submission with XBRL attachments are listed below: 1. Identify the correct Form type, submission type, and exhibits; this determines the instance type [§ 6.1]. 2. The relevant taxonomy entry points for that instance type [§ 6.3]. 3. Identify the permitted formats for the instance attachments [§ 6.4]; choose valid mnemonic file names. 4. Identify the facts that are expected; their absence could result in EDGAR suspending the submission. 5. Identify the facts required for the disclosure, especially those with EDGAR validation warnings. 6. Determine where there will be concepts reported for more than one event, asset class, business segment or any disaggregation represented in the taxonomy and required in the disclosure. 7. Determine any non-standard (“custom”) concepts needed and their supporting properties. 8. Create the custom taxonomy (if needed) and files for the instance. 9. Validate the instance, interpret errors and warnings, and correct them. 10. Preview the submission as it will be rendered on the SEC.gov web site. 11. Validate the entire submission and all its attachments, usually as a TEST submission. 12. Resolve the errors and warnings, repeat 11 as needed, then submit as a LIVE submission. Summary. Interactive Data submissions in EDGAR use the Extensible Business Reporting Language (XBRL) information model. The XBRL information model consists of taxonomies and instances. An instance represents a single Exhibit or Form, even though it may comprise multiple files attached to a submission. Those attached files may be in an XML-based syntax, or in an enhanced kind of XHTML called Inline XBRL. A taxonomy defines a set of reporting concepts and relationships among them, for use in any number of different Forms and Exhibits. EDGAR uses taxonomies to perform a variety of validations on incoming instances; failed instance validations may result in suspension or warnings depending on the submission type and other factors. Taxonomies are further distinguished between standard taxonomies built into EDGAR and updated at least annually, and custom taxonomies that filers themselves create and attach to each submission. 1.1 Set Definitions EDGAR Filer Manual Chapter 3 “Index to Forms” details the correspondence between SEC Forms and EDGAR Submission types. EDGAR accepts or requires Interactive Data for many, but not all submission types in Filer Manual Tables 3-1 through 3-7 where the “tool/template” column shows “EDGARLink Online.” 13 To determine the XBRL files that may be attached to such submissions, more detail is usually needed: the submission type, the form type of the submission, the registrant type, the exhibits to the submission, and in some cases the content of disclosures being made in that submission. Keeping in mind that an XBRL instance may involve multiple attachments, the tables below define the EDGAR XBRL-specific technical terms entity set, submission set, and instance type. The terms entity set, submission set, and instance type are EDGAR specific and have no formal regulatory implications. 1.1.1 Submission Sets Submission sets as defined in Table 6-1 below do not include all EDGAR submission types, only those that permit or require XBRL file attachments. A single EDGAR submission type may appear in one or more submission sets. Table 6-1. Submission Sets Code 6K Definition Report of FPI 8K Current Report AF Annual Financial AM Amending EBP Employee Benefit Plan Annual FAST FAST Act covered FE Fee Exhibit HF Semi-annual (half year) Financial OA Other Annual PRO Prospectus 14 Submission Types 6-K, 6-K/A 8-K, 8-K/A, 8-K12B, 8-K12B/A, 8-K12G3, 8-K12G3/A, 8-K15D5, 8-K15D5/A 10-K, 10-K/A, 10-KT, 10-KT/A, 20-F, 20-F/A, 40-F, 40-F/A, N-CSR, N-CSR/A, SP 15D2, SP 15D2/A 6-K/A, 8-K/A, 8-K12B/A, 8-K12G3/A, 8-K15D5/A, 10-K/A, 10-KT/A, 11-K/A, 11-KT/A, 20-F/A, 20FR12B/A, 20FR12G/A, 40-F/A, N-CSR/A, SP 15D2/A, N-CSRS/A, 17AD-27/A, SD/A#201, 424H/A, 10-Q/A, 10-QT/A, F-1/A, F-10/A, F-3/A, F-4/A, N-14 8C/A, S-1/A, S-11/A, S-3/A, S-4/A, S-6/A, SF-1/A, SF-3/A, 10-12B/A, 10-12G/A, 40FR12B/A, 40FR12G/A, SC 13E1/A, SC 13E3/A, SC TO-I/A, SC TO-T/A, SC13E4F/A, SC14D1F/A, N-8B 2/A, N-1A/A, N-2/A, N-3/A, N-4/A, N-6/A, SBSEF/A, SDR/A, SBSEF-CCO-RPT/A, SBSEF-FIN-QTR/A, SBSEF-FIN-REQ/A, SC14D1F/A, SC 14D9/A 11K, 11-K/A, 11-KT, 11-K 8-K, 8-K/A, 8-K12B, 8-K12B/A, 8-K12G3, 8-K12G3/A, 8-K15D5, 8-K15D5/A, 10-K, 10-K/A, 10-KT, 10-KT/A, 20-F, 20-F/A, 40-F, 40-F/A, 10-Q, 10-Q/A, 10-QT, 10-QT/A POS AM, F-1, F-1/A, F-10, F-10/A, F-10EF, F-1MEF, F-3, F-3/A, F-3ASR, F-3D, F-3MEF, F-4, F-4/A, F-4MEF, N-14 8C, N-14 8C/A, N-14MEF, N-2, N-2 POSASR, N-2/A, N-2ASR, N-2MEF, POSASR, S-1, S-1/A, S-11, S-11/A, S-11MEF, S-1MEF, S-3, S-3/A, S-3ASR, S-3D, S-3MEF, S-4, S-4/A, S-4EF, S-4MEF, S-8, SF-1, SF-1/A, SF-1MEF, SF-3, SF-3/A, SF-3MEF, PREM14A, PREM14C, PRER14A, PRER14C, 424B1, 424B2, 424B3, 424B4, 424B5, 424B7, 424B8, 424H, 424H/A, 424I, SC 13E1, SC 13E1/A, SC 13E3, SC 13E3/A, SC TO-I, SC TO-I/A, SC TO-T, SC TO-T/A, SC13E4F, SC13E4F/A, SC14D1F, SC14D1F/A N-CSRS, N-CSRS/A 17AD-27, 17AD-27/A, SD%201, SD/A%201, SDR#KL, SDR/A#KL, SBSEF-CCO-RPT, SBSEF-CCO-RPT/A 424A, 424B1, 424B2, 424B3, 424B4, 424B5, 424B7, 424B8, 424H, 424I, 425 Code Definition PX Proxy QF Quarterly Financial R33 33 Act Registration Only R34 34 Act Registration Only R40 40 Act Registration Only RD RF SE TF TO 33 and/or 40 Act (dual) registration Requested Financial Reg. SE Registration Transitional Financial Tender Offer Submission Types DEF 14A, DEF 14C, DEFA14A, DEFA14C, DEFC14A, DEFC14C, DEFM14A, DEFM14C, DEFR14A, DEFR14C, PRE 14A, PRE 14C, PREC14A, PREC14C, PREM14A, PREM14C, PRER14A, PRER14C 10-Q, 10-Q/A, 10-QT, 10-QT/A, SBSEF-FIN-QTR, SBSEF-FIN-QTR/A F-1, F-1/A, F-10, F-10/A, F-10EF, F-1MEF, F-3, F-3/A, F-3ASR, F-3D, F-3MEF, F-4, F-4/A, F-4MEF, N-14 8C, N-14 8C/A, N-14MEF, POS AM#S1, POS AM#S3, POS462B#S1, POS462B#S3, POS462C#S1, POS462C#S3, POSASR#F3, POSASR#S3, S-1, S-1/A, S-11, S-11/A, S-11MEF, S-1MEF, S-3, S-3/A, S-3ASR, S-3D, S-3MEF, S-4, S-4/A, S-4EF, S-4MEF, S-6, S-6/A, S-8, SF-1, SF-1/A, SF-1MEF, SF-3, SF-3/A, SF-3MEF 10-12B, 10-12B/A, 10-12G, 10-12G/A, 20FR12B, 20FR12B/A, 20FR12G, 20FR12G/A, 40FR12B, 40FR12B/A, 40FR12G, 40FR12G/A, SC 13E1, SC 13E1/A, SC 13E3, SC 13E3/A, SC TO-I, SC TO-I/A, SC TO-T, SC TO-T/A, SC13E4F, SC13E4F/A, SC14D1F, SC14D1F/A N-8B-2, N-8B-2/A 485APOS#N1, 485APOS#N3, 485APOS#N4, 485APOS#N6, 485BPOS#N1, 485BPOS#N3, 485BPOS#N4, 485BPOS#N6, 485BXT#N1, 485BXT#N3, 485BXT#N4, 485BXT#N6, 486APOS#N2, 486BPOS#N2, 486BXT#N2, 497#N1, 497#N3, 497#N4, 497#N6, N-1A, N-1A/A, N-2, N-2 POSASR, N-2/A, N-2ASR, N-2MEF, N-3, N-3/A, N-4, N-4/A, N-6, N-6/A, POS 8C#N1, POS 8C#N2, POS 8C#N3, POS 8C#N4, POS 8C#N6, POS AMI#N1, POS AMI#N2, POS AMI#N3, POS AMI#N4, POS AMI#N6 SBSEF-FIN-REQ, SBSEF-FIN-REQ/A SBSEF, SBSEF/A 10-KT, 10-KT/A, 10-QT, 10-QT/A, 11-KT, 11-KT/A SC14D1F, SC14D1F/A, SC 14D9, SC 14D9/A, SC14D9C, SC13E4F, SC13E4F/A, SC TO-I, SC TO-I/A, SC TO-C, SC TO-C/A, SC TO-T, SC TO-T/A Most submissions in a set can be completely characterized by the submission type, but a few submission types have distinct XBRL related requirements depending on the form that they contain or the presence of an exhibit. Table 6-2 below shows how the # and % characters are used to distinguish these different uses of a common submission type such as 485BPOS. Table 6-2. Submission Set Suffixes Suffix #N1 #N2 #N3 #N4 #N6 15 Meaning The Form is an N-1A. The Form is an N-2. The Form is an N-3. The Form is an N-4. The Form is an N-6. Suffix #S1 #S3 #F1 #F3 %201 %KL %98 Meaning The Form is an S-1. The Form is an S-3. The Form is an F-1. The Form is an F-3. There is an Exhibit 2.01 in the submission. There is an exhibit K SDR or L SDR in the submission. There is an Exhibit 98 in the submission. 1.1.2 Entity Sets Entity sets as defined in Table 6-3 below do not include all types of SEC registrants, only those with electronic submission requirements that may permit or require XBRL file attachments. Table 6-3. Entity Sets Code ALL BDC CA FPI OEF CEF V3 V4 V6 RT SBSEF SDR SF SPAC SRO UIT US Description Any registrant Business Development Company Canadian Issuer Foreign Private Issuer Open-end Fund Closed-end Fund Separate Account Registered as Open-end Fund Variable Annuity UIT Separate Account Variable Life UIT Separate Account Real Estate Investment Trust Security-based Swap Execution Facility Security-based Swap Data Repository Structured Finance Company Special Purpose Acquisition Company Self-regulatory Organization Unit Investment Trust US Operating Company While most companies fall into just one of the entity sets, they are all in the “ALL” set. It is possible for a company to fall into additional sets. The sets do not cover SEC submissions or registrant types having no EDGAR XBRL requirements. Entity set names that are suggestive of the relevant registration form (N2, N3, etc.) do not have dashes or spaces, and refer to the entity, not the forms. Likewise, entity sets may not distinguish between funds registered under the 33 Act, the 40 Act, or both, nor among companies distinguished by size or other characteristics. 1.1.3 Instance Types Table 6-4 below relates a submission sets, the relevant entity sets, and the exhibit types (if relevant), to yield a code for an instance type. Rows of the table are cumulative; that is, given a submission, every row that matches yields an instance type. For example, a Foreign Private Issuer (FPI) submitting a Form F-3 amendment via Submission type F-3/A will have both an R33.FPI instance and may also have an FE.A instance. Where ALL appears as the Entity set, it means that the instance type does not depend on the kind of entity making the submission. Entity sets in the Exclude column refer to entity sets covered in a 16 different row. In most cases, the instance type is simply the “submission set” “dot” “entity set,” such as QF.US for quarterly financial statements of US operating companies, with few exceptions. Table 6-4. Instance Types Submission Set 6K 8K 8K AF AF AF AF AF AF EBP FE HF OA OA OA OA OA OA OA PRO PRO PX PX QF QF QF R33 R33 R33 R33 R33 R34 R34 R34 R34 R40 RD RD RD RD RD RD RF 17 Included Entity Set FPI ALL SPAC BDC CA CEF FPI OEF US ALL ALL OEF CA FPI SDR SRO US SBSEF SDR ALL CEF ALL SPAC BDC SBSEF US FPI RT UIT US SPAC CA FPI US SPAC UIT CEF OEF V3 V4 V4 V6 SBSEF Excluded Entity Sets Exhibit Type EX-98 EX-FILING FEES EX-2.01 EX-2.01 EX-99.L SDR EX-2.01 CEF EX-99.K SDR EX-98 EX-98 EX-98 EX-99.4r HISTORIC Instance Type 6K.FPI 8K.A EX98.SPAC AF.BDC AF.CA AF.CEF AF.FPI AF.OEF AF.US EBP.A FE.A HF.OEF RXP.CA RXP.FPI L.SDR OA.SRO RXP.US CCO.SEF K.SDR PRO.ANC PRO.CEF PX.A EX98.SPAC QF.BDC QF.SEF QF.US R33.FPI R33.RT R33.UIT R33.US EX98.SPAC R34.CA R34.FPI R34.US EX98.SPAC R40.UIT RD.CEF RD.OEF RD.V3 RD.V4 RD.H99 RD.V6 RF.SEF Submission Set SE SE SE SE SE SE SE SE SE SE SE SE SE TO Included Entity Set SBSEF SBSEF SBSEF SBSEF SBSEF SBSEF SBSEF SBSEF SBSEF SBSEF SBSEF SBSEF SBSEF SPAC Excluded Entity Sets Exhibit Type EX-99.C.SBSEF EX-99.D.SBSEF EX-99.E.SBSEF EX-99.F.SBSEF EX-99.H.SBSEF EX-99.I.SBSEF EX-99.J.SBSEF EX-99.K.SBSEF EX-99.L.SBSEF EX-99.P.SBSEF EX-99.Q.SBSEF EX-99.R.SBSEF EX-99.S.SBSEF EX-98 Instance Type SE.OCX SE.OCX SE.OCX SE.OCX SE.OCX SE.FEX SE.FEX SE.OCX SE.OCX SE.OCX SE.OCX SE.OCX SE.OCX EX98.SPAC Some instance type codes will appear redundant where the submission types may only be submitted by entities of a particular set – form 6-K, for example, is filed only by foreign private issuers. 1.2 Taxonomy Entry Points Each taxonomy has one or more entry points to define a set of concepts and relationships for different purposes. Every instance has a reference to at least one entry point and will frequently have references to several. Conventionally, EDGAR taxonomies always have at least two entry points: a base entry point that contains the minimum set of concepts and relationships that an instance can use in a submission, and one entry point that contains the maximum set of all concepts and their meta data, even some meta data that should not appear directly in a submission. Additional entry points meet various needs; for example, a taxonomy might have two different entry points intended for two different Forms having a substantial set of concepts in common. 1.2.1 Entry Point Name and URL Conventions Each entry point has a unique Uniform Resource Locator (URL) and namespace. Generally, the URL of any entry point of any version of an EDGAR taxonomy conveys its content, its intended usage, and the version. An EDGAR specific taxonomy URL for taxonomy “XYZ” starts with https://xbrl.sec.gov/xyz/. All entry points of the 2025 version of taxonomy XYZ (colloquially, “xyz-2025”) would have URLs that begin https://xbrl.sec.gov/xyz/2025/, representing a folder of files. The base entry point URL would be https://xbrl.sec.gov/xyz/2025/xyz-2025.xsd and the entry point for the entire set of all concepts and meta data would be https://xbrl.sec.gov/xyz/2025/xyz-entire-2025.xsd. Some taxonomies are accompanied by a Taxonomy Guide document located in the same folder as the taxonomy entry point files. Even if there were no substantive difference in a taxonomy from one year to the next, there would still be a new version and annual entry points starting with https://xbrl.sec.gov/xyz/2026/, https://xbrl.sec.gov/xyz/2027/, and so on. If a concept or some meta data were to unavoidably require an incompatible change or mid-year addition, a new taxonomy would be published at https://xbrl.sec.gov/xyz/2025q2/xyz-2025q2.xsd (or xyz-2025q3, or xyz-2025q4). In the same way that the token -entire- appearing in an entry point name denotes the entry point for all meta data, other conventions are used consistently in entry point names: 18 cal def dep doc Calculation relationships Dimensional definitions Deprecated concepts Documentation labels lab pre ref sub Standard labels Presentation relationships Authoritative references All relationships needed for a basic submission 1.2.2 Standard Taxonomies The entry points of all taxonomy versions that may be required or permitted for any instance type are collectively called the Standard Taxonomies 1. The set of standard taxonomies changes periodically to reflect the addition of new taxonomies, new versions of existing taxonomies, various other published files, and removal of obsolete taxonomies. The set of standard taxonomies accepted by EDGAR at any given moment are listed at two locations: Human readable webpage: https://www.sec.gov/info/edgar/edgartaxonomies.shtml Computer readable data file: https://www.sec.gov/info/edgar/edgartaxonomies.xml Naming conventions may vary from taxonomy to taxonomy, but the general point remains that the content of a taxonomy version entry point does not change, it is the set of entry point versions accepted by EDGAR that changes. The association between an entry point version and its URL is permanent. For example, the content of https://xbrl.sec.gov/xyz/2025/xyz-2025.xsd should not change once published, or if it must change for any reason, it cannot change in a way that invalidates any previous references or usage. Table 6-5 and Table 6-6 below show the standard taxonomies having entry points. Most are located with a URL starting with https://xbrl.sec.gov/; the others are maintained by standards bodies under other URL conventions. For current information, refer to the standard taxonomy webpage and data links above. Table 6-5. Standard Taxonomies on xbrl.sec.gov Abbreviation cef country currency cyd dei ecd exch ffd fnd naics oef rr rxp sbs sic snj spac sro Taxonomies on xbrl.sec.gov Closed-end Fund Country (ISO 3166-1) Currency (ISO 4217) Cybersecurity Disclosure Document and Entity Information Executive Compensation Disclosure Exchanges (ISO 10383 MIC) Filing Fee Disclosures Funds North American Industry Classification System Open-end Fund Risk/Return (Deprecated as of 2023) Resource Extraction Payments Security-Based Swap Standardized Industrial Codes Subnational Jurisdiction (ISO 3166-2) Special Purpose Acquisition Company Self-regulating Organizations yes Guide yes yes yes yes yes yes yes yes yes (in rxp guide) yes yes Although evocative of its original purpose in EDGAR submissions and disseminated filings, the name is no longer entirely accurate, since it now a set of URL entry points within taxonomies. 1 19 Abbreviation stpr vip Taxonomies on xbrl.sec.gov States and Provinces Variable Insurance Products Guide yes Table 6-6. Standard Taxonomies not on xbrl.sec.gov Abbreviation ifrs 2 ebp (or us-gaap-ebp) srt us-gaap Taxonomies located elsewhere International Financial Reporting Standards yes Employee Benefit Plan Financial Reporting yes SEC Reporting US GAAP Financial Reporting yes yes Guide 1.3 Instance Types and Standard Taxonomies Each instance type is associated with a set of standard taxonomy entry points. In general, the instance type will have one required entry point that it must reference, and a larger set of permitted entry points that the instance may reference depending on the filer’s disclosures within the submission. The association between instance types and taxonomies is shown in Table 6-7. Where there is more than one entry point required, it means that the filer chooses one. The table does not show where an entry point automatically references another entry point. Table 6-7. Instance Types Mapped to Entry Points Instance Type Included ALL 6K.FPI 8K.A AF.BDC AF.CA AF.FPI AF.CEF AF.OEF AF.US EBP.A EX98.SPAC FE.A HF.OEF K.SDR L.SDR OA.SRO CCO.SEF PRO.A Instance Types Excluded Entry Point Required (Exactly one of) Entry Points Permitted (Any or all) FE.A dei 1 dei dei us-gaap us-gaap, ifrs us-gaap, ifrs us-gaap oef-sr us-gaap ebp spac-despac ffd oef-sr us-gaap us-gaap sro-17ad27 sbs-sbsef-cco dei 2 2 2 2 dei-sub, dei-lab, dei-def, dei-pre, cef, cef-pre, country, country-def, currency, cyd, exch, naics, sic, snj, spac, sro, srt, stpr us-gaap, ifrs us-gaap cef us-gaap, ifrs, ecd us-gaap, ifrs, ecd cef, ifrs ifrs, ecd 2 3 us-gaap, ifrs, ecd 3 3 2 us-gaap, ifrs, ecd Version 2024-03-27 of the IFRS Accounting taxonomy had an incorrect URL for the extensible-enumerations-2.0 schema. Although handled internally within EDGAR, this may require workarounds for preparers and users of instance types that use an ifrs entry point with either or both of us-gaap and srt. 2 20 Instance Type Included PRO.CEF PX.A QF.BDC QF.US QF.SEF R33.FPI R33.UIT R33.US R34.CA R34.FPI R34.US R40.UIT RD.CEF RD.OEF RD.V3 RD.V4 RD.V6 RF.SEF RXP.CA RXP.FPI RXP.US SE.FEX SE.OCX Instance Types Excluded Entry Point Required (Exactly one of) dei dei us-gaap us-gaap sbs-sbsef-fin dei fnd-uit us-gaap dei dei us-gaap fnd-uit fnd-cef, cef fnd-oef, oef-rr, rr vip-n3 vip-n4 vip-n6 sbs-sbsef-fin rxp rxp rxp sbs-sbsef-fex sbs-sbsef-ocx Entry Points Permitted (Any or all) 2 2 2 2 cef, us-gaap, ecd us-gaap, ifrs, ecd cef, ecd ecd, ifrs us-gaap, ifrs us-gaap, ifrs us-gaap, ifrs us-gaap, ifrs ifrs 4 2 3 us-gaap, ifrs 3 3 3 1 These required and permitted entry points apply to all instance types; they are mutually compatible when their year versions match. 2 A company reporting under US Generally Accepted Accounting Principles (GAAP) will mainly use us-gaap and may reference ifrs and other taxonomies if needed; a company reporting under International Financial Reporting Standards (IFRS) will mainly use ifrs and may reference us-gaap and other taxonomies if needed. 3 In practice, these instance types require no other standard taxonomy references. 4 The rr entry point was deprecated as of January 2023. 1.4 Attachment types The instance type determines the permitted file formats of attachments. Every EDGAR submission type has a primary document that is an attachment type matching the submission type. For example, a submission of type 8-K/A must have one file attachment of type 8-K/A. File attachment names and sizes are all limited by the same restrictions defined in EFM 5.1.1. The naming convention for XBRL format files consists of a mnemonic code chosen by the filer, such as a trading symbol, followed by a dash, followed by a date in the format YYYYMMDD, and a three-character suffix. For example, a 10-K submission type for the period ending 12/31/2025 of a company with ticker WXY would be attached as document type “10-K” with file name “wxy-20251231.htm.” 21 In general, all Inline XBRL files attached to a submission are processed and validated together as an Inline XBRL Document Set (IXDS). For example, the WXY 10-K might have additional content requiring XBRL content in an Inline XBRL formatted exhibit EX-99. There are exceptions; certain exhibit types are Inline XBRL that is processed and validated separately from the IXDS of the primary document. Table 6-19 summarizes the general case and its exceptions. Table 6-8. Instance Type – Attachment Types and Acceptable Formats Included Instance Types FE.A RXP.CA, RXP.FPI, RXP.US RXP.CA, RXP.FPI, RXP.US K.SDR L.SDR OA.SRO EX98.SPAC Excluded Instance Types Suffix .htm Inline XBRL attachment EX-FILING FEES Processed as IXDS No Inline Redaction Allowed No - .xml - - - EX-2.01.INS .htm EX-2.01 No No - .xml .xml .htm .htm 17AD-27 EX-98 EX-99.I.SBSEF, EX-99.J.SBSEF EX-99.C.SBSEF, EX-99.D.SBSEF, EX-99.E.SBSEF, EX-99.F.SBSEF, EX-99.H.SBSEF, EX-99.K.SBSEF, EX-99.L.SBSEF, EX-99.P.SBSEF, EX-99.Q.SBSEF, EX-99.R.SBSEF, EX-99.S.SBSEF EX-99.4R HISTORIC Yes No Yes No EX-99.K SDR.INS EX-99.L SDR.INS - No Yes - No Yes - No No Yes No SE.FEX .htm SE.OCX .htm RD.H99 ALL FE.A, RXP.CA, RXP.FPI, RXP.US K.SDR, L.SDR, OA.SRO, EX98.SPAC, SE.FEX, SE.OCX, RD.H99 .htm .htm The primary document and exhibits other than EX-FILING FEES xBRL-XML attachment - For most instance types, additional XBRL file attachments are needed in addition to those listed in the table above; these attachments and the validations that apply to them are detailed in the XBRL technical guide. 1.5 Restrictions on EDGAR Modules EDGAR Type 2 Modules (complete documents) may be submitted in XBRL formats. EDGAR currently supports up to ten EDGAR Module files per CIK. These ten Modules may be used to store any 22 combination of files and may be managed by the filer using the EDGAR Filing Website. These files may be uploaded before the official filing. Using EDGAR Type 2 Module references to these XBRL documents, EDGAR can assemble documents into the submission without delaying the receipt of the entire filing. Filers may include XBRL documents as attachments to an EDGAR Module submission, Template #5 and a master submission may reference the XBRL EDGAR Module in a normal Type 2 fashion. EDGAR Type 1 Modules (partial documents) are not supported for any XBRL document. EDGAR “segment” processing as it is defined in EFM 5.3.3 is not supported for any XBRL document. 1.6 Errors, Suspension, and Rendering Every EDGAR submission is validated prior to being accepted, regardless of whether it has any XBRL instances or not. Errors such as incorrect syntax in the submission header or in the primary document, and other errors such as dates outside of an acceptable range, or duplicate submissions will cause the submission to be suspended, that is, not accepted (see EFM 2.1.3 and the EDGARLink Online technical guide). Usually, file attachments other than the primary document having errors only yield EDGAR warnings; those attachments will be removed (“stripped”) from the submission and the remainder of the submission accepted. A submission in which the primary document had syntax errors that, had it been an exhibit would have resulted in removal, is not accepted. If validation of an instance produces an “XBRL Error,” it is considered an EDGAR warning, and all the file attachments comprising that instance are normally removed. Whether the XBRL error and consequent EDGAR warning results in suspension can vary. Special cases are covered in the table below. Table 6-9. Instance Type – Consequences of XBRL Errors Included Instance Types FE.A K.SDR, L.SDR Excluded Instance Types Consequences of XBRL Errors in the Instance See EFM 7.3.9.2. Suspend. Remove EX-2.01.INS and EX-2.01.SCH file RXP.CA, RXP.FPI, attachments and EX-2.01 if it is Inline XBRL. If there RXP.US are no other exhibits in the submission, then suspend. FE.A, K.SDR, L.SDR, Remove all attachments in the Inline XBRL ALL RXP.CA, RXP.FPI, Document Set. If that included the primary document, RXP.US, RD.H99 then suspend. In addition to validating each XBRL instance, EDGAR also renders the XBRL content of the instance in a standardized fashion for display in a web browser via the SEC web site. EDGAR rendering of different instance types is covered in the Guide. HTML tags in an Inline XBRL file that the filer has requested to be removed using the -sec-ix-redline property are neither rendered nor disseminated; only their enclosed text remains. For some instance types, filers may request confidential treatment for sections of an Inline XBRL file using the -sec-ix-redact property. Any XBRL exhibits outside of the IXDS that failed validation and were removed, but did not cause suspension, are also neither rendered nor disseminated. 2 XBRL Specifications XBRL International Inc. (XII) defines and updates the technical specifications, primers, test cases, and other resources for XBRL syntax, via committees and working groups whose draft publications are open to the public. EDGAR processes XBRL formatted files in submissions to create instances and validates that they conform to specifications. 23 New versions of specifications are published at https://specifications.xbrl.org from time to time. EDGAR does not use all parts nor the latest of all XII specifications. New specifications are not permitted in EDGAR submissions until finalized. New specifications are permitted only through the periodic EDGAR release and the filer manual update processes. The specifications currently governing the technical syntax of all EDGAR instances are: • • • • • • • XBRL version 2.1 XBRL Calculations version 1.1 XBRL Dimensions version 1.1 XBRL Extensible Enumerations version 1.0 XBRL Extensible Enumerations version 2.0 XBRL Open Information Model (OIM) 1.0 Common xBRL-XML Mapping for OIM 1.0 Additionally, the current XII specification governing the Inline XBRL format of instances is: • Inline XBRL version 1.1 XII publishes widely shared enhancements that do not require new specifications via registries. EDGAR currently permits use of entries in these registries: Registry XBRL Data Types (DTR) http://www.xbrl.org/dtr/ XBRL Unit Types (UTR) https://www.xbrl.org/utr/ From version To version includes 2020-01-21 2024-01-31 all entries 2024-10-24 2025-03-18 all entries Inline XBRL Transformation (TR) 2020-02-12 2022-02-16 all entries † XBRL Link Role (LRR) URIs starting with 2022-09-28 2023-01-04 only http://www.xbrl.org/lrr/ † All are listed at https://specifications.xbrl.org/spec-group-index-inline-xbrl.html ; note that only the versions at https://www.sec.gov/info/edgar/ix brl-transform-registries.json are allowed. XII also creates and publishes taxonomies. Currently none of the XII taxonomies are EDGAR standard taxonomies. 3 Instance Validations The content of an instance is illustrated here using Form 6-K. EFM § 3 shows that Form 6-K may be submitted either as submission type 6-K or, if an amendment of a prior 6-K, submission type 6-K/A. The tables in EFM v68 § 6 (duplicated in this document in section 11 below), show that: • Submission types 6-K and 6-K/A are in submission set 6K [§ 6.1.1]; • Submission set 6K is paired only with entity set FPI and maps to instance type 6K.A [§ 6.1.3]; • Instance type 6K.A requires entry point dei and may use us-gaap or ifrs and any of the other entry points on the row labeled ALL [§ 6.3]; 24 Instance type 6K.A is not one of the exceptions to the general requirement that the format be Inline XBRL, so it is an Inline XBRL attachment. [§ 6.4]. • The first few lines of the file shown below have a root html element and a namespace prefix ix that establish it is an Inline XBRL file; see [§ 11.2 Inline XBRL validation] for more detail. The link:schemaRef attribute xlink:href means that it uses the dei-sub entry point that contains labels, presentation, and definition links of the 2024 version of the dei taxonomy: … Regarding the Inline XBRL markup, the preparer of a 6K.A instance needs to know the following data points: • The form type, as distinct from the submission type; • The company CIK and its EDGAR conformed name; • The month and day of the current fiscal year end; • For current reports in submission sets 8K and 6K, the date of the earliest event reported; • In an amending submission (a submission type in submission set AM), whether the content of any XBRL facts have changed; and • If the content of any XBRL facts changed, how. Each of these data points is represented in an instance as a fact in the same context. 3.1 Expected Facts in the Required Context Every instance type has some facts that are expected to be present and have specific values in the instance. Each such fact has a concept from a standard taxonomy as defined in EFM v68 § 6.2.2. The context of the fact will have: 1. an entity identifier matching the filing CIK, and 2. either a. no taxonomy-defined dimensions, or b. a dimension from a standard taxonomy, and 3. either a period whose end date matches the reporting period end, which may be a. an instant, or b. a duration matching the quarter or year of the submission reporting period, or c. a duration of one day representing the intended date of submission. Conditions 1, 2.a, and either 3b or 3c jointly define the required context. There may be more than one context that matches all four conditions, in which case 3.c takes precedence over 3.b. 25 Every instance type has expected facts in a required context. For example, every instance must have a fact in the required context having concept dei:EntityCentralIndexKey whose value is the 10-digit CIK matching the CIK described in condition 1. One CIK must be chosen even when there are multiple coregistrants in the submission. Other contexts meeting conditions 1.b, 2, and 3 are defined below in relation to certain expected facts. For example, some expected facts for multi-series filers expect a context with an explicit member of dei:LegalEntityAxis and otherwise identical to the Required Context. Expected facts may also be subject to additional conditions: 4. The fact may be required to be either present or absent (attribute xsi:nil = true is normally the same as being absent). 5. The fact value may be expected to have a value that is consistent with a. EDGAR’s existing data for a company, or b. data from the EDGAR submission header, or c. other facts in the same instance. 6. The fact may be expected outside of element ix:header of an Inline XBRL file [§ 11.14]. Inline XBRL permits the same concept to appear more than once in the same context, possibly inside and outside of ix:header; in that case the condition of one occurrence appearing outside ix:header is sufficient. Symmetrically, there are also validations for unexpected facts. Facts that are expected for one instance type may be unexpected (resulting in an XBRL warning or error) or optional (no warning or error is produced) or for other instance types. These conditions vary by instance type. 3.1.1 Notation and Terminology This guide describes each fragment of expected content in two tables, a Concepts table and a Validations table. The Concepts table shows: • The concept with its standard namespace prefix (sometimes, an EDGAR header field); • A concept # in the style {1}, {2}, etc. to be referenced in the Validations table; • An XML or XBRL data type, or a POSIX regular expression (regex) of possible string values; • A short indication of the concept meaning, which is often apparent from the concept name, along with any detail notes such as related Inline XBRL transformations (in some tables the cell is blank because the concept has been defined in a previous Concepts table). An example Concepts table is shown below. Concept # Type or regex Meaning dei:EntityCentralIndexKey {1} \d{10} EDGAR CIK The Validations table shows: 26 • Included submission sets (prefixed by “s: ”) and included instance types (prefixed by “i: ”) • Excluded submission sets (prefixed by “s: ”) and excluded instance types (prefixed by “i: ”) • c - a code indicating the contexts to which it applies (r: required; a: all; etc.) This implies that even if a fact is expected in a restricted context, it may or may not appear in other contexts. • Check - the condition to be tested • f - a footnote indication for special cases, exceptions, or additional detail notes, • On failure – the condition raised when the check fails, • s - the severity of the violation (E: Error, W: Warning), • and (in this version of the guide) a reference to version 68 of the EDGAR Filer Manual (for example, “§ 6.5.21 X” refers to the code X appearing in the table of section 6.5.21; “§ 6.5.46 []” refers to a blank cell in the table of section 6.5.46). An example validations table is shown below. Incl i: ALL Excl c r Check A {1} fact is present. f On failure {1} Missing s E EFM v68 Ref § 6.5.21 X* The consequences of an XBRL Error may vary depending on the instance type, as discussed in [§ 6.6]. However, an XML syntax error (such as a five-digit number where a ten-digit number is required or an unknown country code) always results in an XBRL Error. Failed validations of expected facts may be Errors or Warnings. XBRL Warnings indicate that facts found in the instance are in some way incomplete, inconsistent with each other, misleading, ambiguous, or unreliable and this will have undesirable downstream consequences for users of the data. Filers should avoid XBRL warnings by correcting the data prior to live submission. Within the validations table, a fact is visible in an Inline XBRL file if it is not located within the ix:hidden element. If the fact has duplicates, at least one must be located outside of ix:hidden. A fact is present in a context if it has a non-nil value; a fact is deemed to be absent if it either does not exist or exists only with a nil value. Each validations table is followed by notes or special cases from the footnote (f) column. 3.1.2 Required Context validation There is a check for the existence of a required context applying to all instances: Concept The CIK of any one company in the submission header The period of the submission header The filing date of the submission # Type or regex Meaning {1} \d{1,10} EDGAR CIK {2} \d{1,2}-\d{1,2}-\d{4} Reporting period if present {3} \d{1,2}-\d{1,2}-\d{4} Filing date, which may be the same or later than the acceptance date. Validations: Incl Excl c Check All contexts have an identifier element i:ALL value equal to {1}. There is a context having endDate value i:ALL matching either {2} or {3}, and no segment element. f 1 On failure s EFM v68 Ref Non Matching Cik E § 6.5.3 Required Context E § 6.5.19 Notes and special cases: 1. Most XBRL authoring software tends to create contexts for EDGAR files following the order of facts appearing in the Official Related Document [§ 6.1]. Facts such as the document type and registrant name appear on the first page; therefore the required context therefore typically appears as the first one in the 27 emitted file. While not required, following this convention can be helpful when diagnosing validation errors. 3.1.3 Central Index Key Concept # Type or regex Meaning dei:EntityCentralIndexKey {1} \d{10} EDGAR CIK Validations: Incl Excl c Assertion i: ALL r i: K.SDR, L.SDR i: ALL r i: K.SDR, L.SDR r f A {1} fact is present. A {1} fact with value a full tendigit CIK from among the coregistrants in the submission header or equal to 0000000000. A {1} fact with value a full tendigit CIK other than 0000000000 from among the co-registrants in the submission header. On failure {1} Missing {1} Value {1} 1 Value s EFM v68 Ref E § 6.5.21 X* E § 6.5.23 E § 6.5.23 Notes and special cases: 1. Instance types K.SDR and L.SDR permit a CIK value of 0000000000 that could not appear in the submission header. 00000000000 represents an entity that is not an EDGAR registrant. 3.1.4 Registrant Name Concept # Type or regex Meaning dei:EntityRegistrantName {1} xs:normalizedString EDGAR registrant conformed name, with some differences permitted Validations: Incl Excl c Check r A {1} fact is present. i: ALL r A value of {1} matches the EDGAR conformed name of the company whose CIK is. s: FAST r i: AF.CA, AF.FPI, R33.FPI, R34.FPI r i: ALL i:ALL 28 i: AF.CA, AF.FPI, r R33.FPI, R34.FPI If {1} facts are present, then at least one is visible. If no {1} fact with xml:lang value en-US matches, then a matching {1} fact with a language not starting with en- is present. The matching {1} fact has xml:lang value en-US. f On failure {1} Missing s EFM v68 Ref E § 6.5.21 X, X* 1, {1} Submission E 2 Value 3 § 6.5.24 X {1} in Facts Not Visible W § 6.5.21 X*, 6.5.45 X - E § 6.5.24 {1} Submission Value E § 6.5.24 X Notes and special cases: 1. The conformed name must be a case-insensitive prefix of the fact value. For example, conformed name "SMITH" would match fact text "Smith, John". These differences are ignored: a. Differences in whitespace or punctuation; hyphen characters (-, -) may either match whitespace or nothing. For example, "ABC Real-time" will match both "A.B.C. RealTime" and "ABC, Real Time". b. Single-character words are ignored; "A. B. SMITH" will match "SMITH A". c. Text entered between "//", such as "ABC CO /DE/", matches "ABC CO". d. Matching abbreviations that EDGAR imposes, such as truncating CORPORATION to CORP, shortening "and" to ampersand "&", and dropping the word "The" at the beginning. For example, "The Smith and Jones Corporation" matches "SMITH & JONES CORP". 2. When the required context CIK is 00000000000, the name match is waived. 3. The cover pages of certain forms distinguish the "Exact name of Registrant as specified in its charter" from the "Translation of Registrant’s name into English". If either differs from the conformed name, then an additional dei:EntityRegistrantName fact with an xml:lang attribute value not starting with en is expected. 3.1.5 Form or Exhibit Type Concept dei:DocumentType # Type or regex {1} [A-Z0-9]+([/A-Z0-9 \.\]*[A-Z0-9])?|Other Meaning Form, Schedule, or Exhibit Type (often differs from the submission type). The data type dei:submissionTypeItemType covers all such names, not just submissions. (Up to 20 characters) Validations: Incl i: ALL Excl s: FE c Check r A {1} fact is present. The {1} fact value is s: FE, among the Form types i: ALL i: SE.OCX, r permitted for the SE.FEX submission type as shown in EFM § 3. The {1} fact value is EX-99.SDR.I or i: SE.FEX r EX-99.SDR.J as shown in EFM § 3. The {1} fact value is among the Exhibits C-F, H, i: SE.OCX r K-L, P-S as shown in EFM § 3. A {1} fact value is i:RD.H99 r EX-99.4R HISTORIC i: FE r A {1} fact is absent. Notes and special cases: 29 f On failure {1} Missing s E EFM v68 Ref § 6.5.20 X* 1, 2, 3 {1} Value E § 6.5.20 {1} Value E § 6.5.20 {1} Value E § 6.5.20 {1} Value E {1} Unexpected W § 6.5.20 [] 4 1. For compatibility with earlier EDGAR releases, dei:DocumentType may match the submission type without a warning, but this usage is discouraged and may soon be deprecated and result in a warning or error. 2. In some cases, there may be an inferred entity set and inferred submission set based on the combination of submission type, the value of DocumentType, and the value of submission header field investmentCompanyType, with or without a warning (previously § 6.5.56). Submission types 485APOS, 485BPOS 485APOS, 485BPOS 485APOS, 485BPOS 485APOS, 485BPOS, 485BXT POS AM, POS EX POS AM, POS EX POS AM, POS EX POS AM, POS EX POS AM, POS EX POS AM, POS EX POS AM, POS EX All other cases Value of dei:DocumentType N-3 N-4 N-6 Not N-3, not N-4 and not N-6 Matches POS.* Matches POS.* Matches POS.* Matches POS.* Matches POS.* Matches POS.* Matches POS.* Value of investmentCompanyType S-1 or S-3 N-1A N-2 N-3 N-4 N-6 (absent) Inferred entity sets V3 V4 V6 Inferred submission sets [§ 6.1] [§ 6.1] [§ 6.1] OEF [§ 6.1] W US OEF CEF V3 V4 V6 US RD RD RD RD RD RD R33 [§ 6.1] W W W W W W W Severity W W W 3. Note that the entity and/or submission set, when inferred from dei:DocumentType, may not be what the filer intended; this can lead to other warnings or errors; therefore, it is preferable for dei:DocumentType to have the value of the underlying form or schedule type (without /A or other amendment indicator), or the exhibit type, when it is a separate instance. 4. In release 24.4, dei:DocumentType has uppercase “R” even though the exhibit type has lowercase “r”. 3.1.6 Amendment Flag and Description Concept # dei:AmendmentFlag dei:AmendmentDescription Type or regex Meaning Value is true if the content of an instance changed from a previous submission that this amends, and false otherwise. This is not the same as the “/A” indicator on {1} xs:boolean an EDGAR submission type; it is possible for an “/A” submission to amend only material that was not XBRL tagged content. {2} xs:string A description of the changes in the amendment. Validations: Incl i: ALL i: FE.A i: ALL 30 Excl i: FE.A c Check r A {1} fact is present. r A {1} fact is absent. If a {1} fact with value true is r present, then a {2} fact is present. f On failure {1} Missing {1} Unexpected {1} {2} Value Dependency s EFM v68 Ref W § 6.5.20 R* W § 6.5.20 [] W § 6.5.20 A Incl Excl c i: ALL i: ALL i: FE.A, RXP.US, RXP.FPI, OA.SDR r Check If a {1} fact with value false is present, then a {2} fact is absent. r If {2} facts are present, then at least one is visible. f On failure s EFM v68 Ref {1} {2} Value Dependency W § 6.5.20 A {2} in Facts Not Visible W § 6.5.20 A Notes and special cases: none. 3.1.7 Document Period End Date Concept dei:DocumentPeriodEndDate # Type or regex Meaning Many EDGAR submission types have a header field periodOfReport. For most of these, it represents the end {1} xs:date date of a reporting or transition period. For current reports (8K, 6K submission types) it represents the date of the earliest event reported. Validations: Incl Excl s: 8K s: FAST, AF.OEF, HF.OEF s: FAST, AF.OEF, HF.OEF s: 6K, i: OA.SDR s: RD, R33, R34, R40 s: FAST, AF.OEF, HF.OEF, 6K, R33, R34, R40, 6K, RD, R33, R34, R40, EBP, i: OA.SDR s: ALL s: 8K f On failure s EFM v68 Ref r A {1} fact is present. 1 {1} Missing r A {1} fact is present. 2 {1} Missing W § 6.5.20 R r If {1} facts are present, then at least one is visible. {1} in Facts Not Visible W § 6.5.45 R r A {1} fact is present. 3 r A {1} fact is present. r If a {1} fact is present, and the submission header field periodOfReport is present, then its date matches the value of 4, 5 s: FAST, 6K, R33, R34, R40, 6K, RD, R33, R34, r R40, SE, EBP i: AF.OEF, HF.OEF, OA.SDR Notes and special cases: 31 c Check {1} Missing W § 6.5.20 R W § 6.5.20 R* {1} Missing W § 6.5.20 R*, O* {1} Value W § 6.5.40 Item 2 {1} Unexpected W § 6.5.20 [], O* {1}. A {1} fact is absent. 5 1. Use the date of earliest event reported. 2. Use the end of the reporting or transition period. 3. Use the end of the period reported. 4. Use the date of the filing in which the fact appears. 5. Check is waived when the submission type matches POS* 3.1.8 Document Fiscal Year and Period Focus Concept # {1} Type or regex xs:gYear (matches YYYY) dei:DocumentFiscalPeriodFocus {2} Q1|Q2|Q3|FY dei:DocumentFiscalYearFocus Meaning Filer’s fiscal year. Fiscal period of the report; use FY for an annual report that includes the 4th quarter, or for a transition report such as a 10-KT. Validations: Incl s: AF Excl i: AF.OEF c Check r A {1} fact is present. s: ALL f On failure {1} Missing s EFM v68 Ref W § 6.5.20 R* {1} {2} Mutual r Neither or both of {1} and {2} facts are present. 1 Dependency W § 6.5.20 Op* W s: ALL s: FAST, R33, R34, EBP r A {1} fact is absent. 1 {1} Unexpected s: AF i: AF.OEF r A {2} fact is present. {2} Missing s: ALL s: FAST, R33, R34, EBP r A {2} fact is absent. 1 {2} Unexpected § 6.5.20 [], Op* W § 6.5.20 R* W § 6.5.20 [], Op* Notes and special cases: 1. Waived for submission types matching POS.*. 3.1.9 Current Reporting Status and Interactive Data Current Both dei:EntityCurrentReportingStatus and dei:EntityInteractiveDataCurrent facts in the required context are expected for most financial statements and optional for certain FPI instances. Concept # Type or regex Meaning dei:EntityCurrentReportingStatus {1} Yes|No Registrant has (1) filed all reports required to be filed by Section 13 or 15(d) of the Securities Exchange Act of 1934 during the preceding 12 months (or for such shorter period that registrants were required to file such reports), and (2) have been subject to such filing requirements for the past 90 days. dei:EntityInteractiveDataCurrent {2} Yes|No The registrant has submitted electronically every Interactive Data File required to be submitted pursuant to Rule 405 of Regulation S-T during the preceding 12 months (or for such 32 shorter period that the registrant was required to submit such files). Validations: Incl s: AF Excl i: AF.OEF s: AF i: AF.OEF c Check r A {1} fact is present. If {1} facts are present, r then at least one is visible. s: AF i: R34.CA, r R34.FPI i: AF.OEF r s: AF i: AF.OEF s: ALL i: R34.CA, r R34.FPI s: ALL r f On failure {1} Missing s EFM v68 Ref W § 6.5.21 R {1} in Facts Not Visible W § 6.5.21 R A {1} fact is absent. {1} Unexpected W A {2} fact is present. If {2} facts are present, then at least one is visible. {2} Missing A {2} fact is absent. § 6.5.21 [], O* W § 6.5.21 R {2} in Facts Not Visible W § 6.5.21 R {2} Unexpected W § 6.5.21 [], O* Notes and special cases: none 3.1.10 Voluntary Filers, Shell Companies, and Well-known Seasoned Issuers Concept # Type or regex Meaning dei:EntityVoluntaryFilers {1} Yes|No Registrant is “not required to file”. dei:EntityWellKnownSeasonedIssuer {2} Yes|No Registrant is a well-known seasoned issuer, as defined in Rule 405 of the Securities Act dei:EntityShellCompany {3} xs:boolean Registrant is a shell company as defined in Rule 12b-2 of the Exchange Act Validations: Incl Excl i: AF.US, AF.BDC, AF.FPI i: AF.US, AF.FPI i: AF.US, AF.BDC, AF.FPI s: ALL i: AF.US, AF.BDC, AF.FPI 33 c Check r r r i: AF.US, AF.BDC, r AF.FPI r f On failure s EFM v68 Ref A {1} fact is present. {1} Missing W § 6.5.21 R If {1} facts are present, then at least one is visible. If header element voluntaryFilerFlag has a value, then it is equivalent to the {1} fact value. {1} in Facts W § 6.5.45 R {1} Value W A {1} fact is absent. {1} Unexpected W § 6.5.21 [] A {2} fact is present. {2} Missing W § 6.5.21 R Not Visible § 6.5.40 Item 3 Incl Excl i: AF.US, AF.BDC, AF.FPI i: AF.US, AF.BDC, AF.FPI s: ALL i: AF.US, AF.BDC, AF.FPI i: AF.US, AF.BDC, AF.FPI i: AF.US, AF.BDC, AF.FPI c Check f On failure s EFM v68 Ref r If {2} facts are present, then at least one is visible. {2} in Facts W § 6.5.45 R r If header element wellKnownSeasonedIssuerFlag has a value, then it is equivalent to the {2} fact value. {2} Value W A {2} fact is absent. {2} Unexpected W § 6.5.21 [] r A {3} fact is present. {3} Missing W § 6.5.21 R r If {3} facts are present, then at least one is visible. {3} in Facts W § 6.5.45 R {3} Value W {3} Unexpected W § 6.5.21 [] i: AF.US, AF.BDC, r AF.FPI Not Visible Not Visible If header element shellCompanyFlag has a value, then it is equivalent to the {3} fact value. r s: ALL i: AF.US, AF.BDC, r AF.FPI s: ALL a At most one of {1} and {2} has the value Yes or true. s: ALL a At most one of {2} and {3} has the value Yes or true. A {3} fact is absent. {1} {2} Exclusive Values {2} {3} Exclusive Values § 6.5.40 Item 4 § 6.5.40 Item 5 W § 6.5.21 WV W § 6.5.21 WS Notes and special cases: none. 3.1.11 Small Business, Emerging Growth Company Concept # dei:EntityEmergingGrowthCompany {2} xs:boolean Indicates a registrant that meets the emerging growth company criteria. dei:EntityExTransitionPeriod {3} xs:boolean Indicates an emerging growth company has elected not to use the extended transition period for complying with any new or revised financial accounting standards. dei:EntitySmallBusiness Validations: 34 Type or regex Meaning Indicates that the company is a Smaller Reporting {1} xs:boolean Company (SRC). Incl i: AF.US, AF.BDC, AF.OEF, QF.US, R33.US, R34.US Excl r i: AF.BDC i: AF.US, AF.BDC, AF.OEF, QF.US, R33.US, R34.US i: AF.US, AF.BDC, QF.US s: ALL s: FAST, i: R33.US, R33.FPI, R34 c Check r r i: AF.US, AF.BDC, AF.OEF, QF.US, R33.US, R34.US EFM v68 Ref 1 {1} Missing W § 6.5.40 R, R* {1} Value W § 6.5.40 SB {1} Value W § 6.5.40 Item 9 {1} in Facts Not Visible W § 6.5.40 R, § 6.5.45 1 r A {1} fact is absent. 1 {1} Unexpected W § 6.5.40 [] r A {2} fact is present. 1 {2} Missing W § 6.5.40 R, R* filer with the CIK of the required context, then a {2} fact is present with that value. If {2} facts are present, then at least one is visible. 1 {2} Submission Value W § 6.5.40 Item 6 {1} in Facts Not Visible W § 6.5.40 R A {2} fact is absent. 1 {2} Unexpected W § 6.5.40 [] If there is a value for s: FAST r 35 s If {1} facts are present, then at least one is visible. r s: FAST, i: R33.US, R33.FPI, R34 s: FAST, i: R33.US, R33.FPI, R34 A {1} fact with value true is absent. If header element smallBusinessFlag for the filer with the CIK of the required context, then a {1} fact is present with that fact value. On failure r s: ALL s: ALL A {1} fact is present. f s: FAST, R34, i: R33.US, R33.FPI, r emergingGrowthCompanyFlag in the header for the If a {2} fact valued true is a present, then a {3} fact is present. {3} 1, {2} Value E 2 Dependency If a {2} fact does not have a value true, then a {3} fact is absent. {3} 1, {2} § 6.5.40 ET, Value W 2 Dependency ET* § 6.5.40 ET Incl Excl s: FAST s: ALL s: FAST, R34, i: R33.US, R33.FPI c Check If {3} facts are present, then r at least one is visible. A {3} fact is absent. r f On failure s 1 {3} Unexpected W § 6.5.40 [] 1 {3} Submission Value W If there is a value for exTransitionPeriodFlag s: ALL EFM v68 Ref § 6.5.40 ET, W § 6.5.45 {3} Unexpected in the header for the filer with the CIK of the required context, then a {3} fact is present with that value. r § 6.5.40 Item 7 Notes and special cases: 1. Check is waived when the submission type matches POS.*. 2. Check does not apply to instance type RD.CEF; see 3.1.24.7 below. 3.1.12 Current Fiscal Year End Date Concept # {1} dei:CurrentFiscalYearEndDate Type or regex xs:gMonthDay (matches --MM-DD) Meaning Month and day marking the end of the company’s fiscal year; it normally does not change from year to year. Validations: Incl s: AF, QF, 6K, i: K.SDR, L.SDR s: AF Excl i: AF.OEF, AF.CEF, AF.SEF, QF.SEF i: AF.OEF, AF.CEF s: 8K, AF, QF, 6K, i: K.SDR, L.SDR, EBP s: ALL 36 c Check r r r s: AF, QF, RF, 6K, EBP, i: R34.FPI, R34.CA, K.SDR, L.SDR r A {1} fact is present. If {1} facts are present, then at least one is visible. If {1} is present, and there is a value for fiscalYearEnd in the header for the filer with the CIK of the required context, then the {1} fact is present with that value. A {1} fact is absent. f On failure s 1 {1} W § 6.5.21 R, R* Missing {1} in Facts Not Visible W EFM v68 Ref § 6.5.21 R, § 6.5.45 2, {1} § 6.5.21 [], O*, Submission W 3 Value § 6.5.40 Item 1 {1} Unexpected W § 6.5.21 [], O* Incl Excl c Check If Item 5.03 is indicated in r the header, then {1} is present. If Item 5.03 is not indicated r in the header, then {1} is absent. s: 8K s: 8K f On failure s EFM v68 Ref 1, {1} Submission W § 6.5.21 E503 2 Value {1} Unexpected W § 6.5.21 E503 Notes and special cases: 1. Co-registrants in the header may have different fiscal year ends; only one is relevant to value tests. 2. The header field fiscalYearEnd is in format MM/DD, and in XBRL data type gMonthDay as --MMDD. 3. L.SDR instances with CIK of 0000000000 are exempt from the fiscal year end date value check. 3.1.13 Filer Category (Accelerated / Non-Accelerated) Concept dei:EntityFilerCategory # Type or regex Meaning {1} (Large Accelerated|Accelerated|Nonaccelerated) Filer Accelerated Filer Status. Note that the possible values are case-sensitive and have spaces and a dash. Validations: Incl i: AF.US, AF.BDC, QF.US, AF.FPI, R33.US, R34.US i: AF.US, AF.BDC, QF.US, AF.FPI s: ALL i: AF.US, AF.BDC, QF.US, AF.FPI, R33.US, R34.US 37 Excl i: AF.US, AF.BDC, QF.US, AF.FPI, R33.US, R34.US c Check f On failure s EFM v68 Ref 1 {1} Missing W § 6.5.21 R, R* {1} in Facts Not Visible W § 6.5.21 R, § 6.5.45 {1} Unexpected W § 6.5.21 [] r A {1} fact is present. r If {1} facts are present, then at least one is visible. r A {1} fact is absent. 1 r If the value of acceleratedFilerStatus in the header for the filer with the CIK of the required context is Large Accelerated Filer, then a {1} fact value starting with Large Accelerated Filer is present. {1} § 6.5.40 1 Submission W Item 10 Value Incl i: AF.US, AF.BDC, QF.US, AF.FPI, R33.US, R34.US Excl i: AF.US, AF.BDC, QF.US, AF.FPI, R33.US, R34.US i: AF.US, AF.BDC, QF.US, AF.FPI, R33.US, R34.US c Check If the value of acceleratedFilerStatus in the header for the filer with the CIK of the required r context is Accelerated Filer, then a {1} fact value starting with Accelerated Filer is present. If the value of acceleratedFilerStatus in the header for the filer with the CIK of the required context is neither Large Accelerated Filer nor r Accelerated Filer, then a {1} fact is present in the required context with a value that starts with neither Large Accelerated Filer nor Accelerated Filer. r If there is no acceleratedFilerStatus in the header for the filer with the CIK of the required context, then a {1} fact is absent. f On failure s EFM v68 Ref {1} § 6.5.40 1 Submission W Item 11 Value {1} § 6.5.40 1 Submission W Item 12 Value 1 {1} Unexpected W § 6.5.40 Item 13 Notes and special cases: 1. Checks waived when the submission type matches POS.*. 3.1.14 ICFR Auditor Attestation Flag A dei:IcfrAuditorAttestationFlag fact is expected for US and FPI financial statements of accelerated and large accelerated filers, but optional for Canadian and Non-accelerated filers. Concept # Type or regex dei:EntityFilerCategory {1} (Large Accelerated|Accelerated|Nonaccelerated) Filer dei:IcfrAuditorAttestationFlag {2} xs:boolean Meaning Note that the possible values have spaces and a dash. Validations: Incl i: AF.US, AF.BDC, AF.FPI 38 Excl c r Check If the value of {1} is “Large Accelerated Filer” or “Accelerated Filer”, then a {2} fact is present. f On failure {2} Missing s EFM v68 Ref W § 6.5.21 Ra Incl i: AF.US, AF.BDC, AF.FPI, AF.CA s: ALL Excl i: AF.US, AF.BDC, AF.FPI, AF.CA c Check f On failure r If {2} facts are present, then at least one is visible. a A {2} fact is absent. s EFM v68 Ref {2} in Facts Not Visible W § 6.5.45 Ra {2} Unexpected W § 6.5.21 [], O Notes and special cases: none. 3.1.15 Public Float A dei:EntityPublicFloat fact is expected for certain instance types in an instant (not duration) context. Concept # dei:EntityPublicFloat Type or regex Meaning A filer having no common shares outstanding will have {1} xs:decimal a $0 public float fact, not nil; debt and other tiers of equity are not measured in the public float. A context that has period type instant, no taxonomy-defined dimensions, and a date equal to or after the end date of the period of the required context is called a Subsequent Event (se) context. Validations: Incl i: AF.US, AF.BDC Excl c i: AF.US, AF.BDC s: ALL i: AF.US, AF.BDC Assertion f On failure s EFM v68 Ref se A {1} fact is present. {1} Missing W § 6.5.21 R If {1} facts are se present, then at least one is visible. {1} in Facts Not Visible W se A {1} fact is absent. {1} Unexpected W § 6.5.21 [] § 6.5.21 R, § 6.5.45 Notes and special cases: none. 3.1.16 Auditor Name, Location, and Firm ID Three facts must appear together for annual financial statements for periods ending after 12/31/2020. Concept # dei:AuditorName {1} Type or regex [\p{L}\p{N}].* up to 150 characters; \p{L} matches a single letter and \p{N} matches any kind of numeric character in any language. Meaning The plain text (not logo nor signature) name of the auditor dei:AuditorLocation {2} [\p{L}\p{N}].* up to 150 characters. City along with either or both of country, US state, or Canadian province dei:AuditorFirmId {3} [1-9]\d* an integer with no leading sign or The auditor’s Firm ID as assigned by the US PCAOB. Validations: 39 zeroes. Incl i: AF.US, AF.BDC, AF.FPI, AF.CA Excl c Check f On failure s EFM v68 Ref s: AM r A {1} fact is present. 1 {1} Missing E § 6.5.21 H, § 6.5.54 r If {1} facts are present, then at least one is visible. 2 {1} in Facts Not Visible W § 6.5.21 H, § 6.5.54 s: ALL i: AF.US, AF.BDC, AF.FPI, AF.CA r A {1} fact is absent. 1 {1} Unexpected E § 6.5.21 [] i: AF.US, AF.BDC, AF.FPI, AF.CA s: AM r A {2} fact is present. 1 {2} Missing E § 6.5.21 H, § 6.5.54 r If {2} facts are present, then at least one is visible. 2 {2} in Facts Not Visible W § 6.5.21 H, § 6.5.54 s: ALL i: AF.US, AF.BDC, AF.FPI, AF.CA r A {2} fact is absent. 1 {2} Unexpected E § 6.5.21 [] i: AF.US, AF.BDC, AF.FPI, AF.CA s: AM r A {3} fact is present. 1 {3} Missing E § 6.5.21 H § 6.5.54 r If {3} facts are present, then at least one is visible. 2 {3} in Facts Not Visible W § 6.5.21 H § 6.5.54 r A {3} fact is absent. 1 {3} Unexpected E § 6.5.21 [] {2} {3} 1, {1} Mutual 3 Dependency E § 6.5.54 i: AF.US, AF.BDC, AF.FPI, AF.CA i: AF.US, AF.BDC, AF.FPI, AF.CA i: AF.US, AF.BDC, AF.FPI, AF.CA s: ALL i: AF.US, AF.BDC, AF.FPI, AF.CA, EBP s: ALL If any of {1}, {2}, or a {3}, are present, then all three are present. Notes and special cases: 1. 40 Absence (or unexpected presence) has severity Error, not Warning as it is for most expected facts. 2. The code {_} in Facts Not Visible does not mean that auditor information must literally appear on a cover page. These facts should appear in an Inline XBRL file where they normally appear, adjacent to the auditors’ opinions. 3. In addition to the primary auditor in the required context, additional auditor names, locations and firm IDs should be tagged in other contexts distinguished by the relevant reporting period of that audit opinion, and/or a distinct member of one of the following axes in a standard namespace: a. ConsolidatedEntitiesAxis for subsidiaries, b. ScheduleOfEquityMethodInvestmentEquityMethodInvesteeNameAxis for investments, c. LegalEntityAxis for branches, d. OwnershipAxis for components, e. CounterpartyNameAxis for all others. 4. As the “Excl” column indicates, certain facts are optional in amending submissions. 3.1.17 Investment Company Type Concept # Type or regex dei:EntityInvCompanyType {1} N-1A|N-1|N-2|N3|N-4|N-6|S-1 or S-3|S-6 Meaning Investment Company Type. Note that one of the possible values is the literal token S-1 or S-3, these are not alternative values. Validations: Incl s: RD s: ALL Excl s: RD s: RD c r r r Check A {1} fact is present. A {1} fact is absent. If header element invCompanyType for the filer with the CIK of the required context, then a {1} fact is present with that fact value. f 1 1 On failure {1} Missing {1} Value s W W EFM v68 Ref § 6.5.40 R* § 6.5.40 [] 1 {1} Value W § 6.5.40 Item 8 Notes and special cases: 1. Checks waived for submission types matching POS.*. 3.1.18 File Number (Securities Act File Number) Concept # Type or regex dei:EntityFileNumber {1} \d{1,3}-\d{1,8}(-.{1,4})? Meaning Securities (“33”) Act file number. Validations: Incl s: FAST s: ALL Excl s: FAST, 6K, EBP i: R34.FPI, R34.CA c r Assertion A {1} fact is present. r A {1} fact is absent. f On failure {1} Missing {1} Unexpected s W W EFM v68 Ref § 6.5.47 Ri § 6.5.47 [], O* § 6.5.55 n2sn Notes and special cases: • 41 The regex is less restrictive than that governing file numbers in an EDGAR submission header. 3.1.19 Incorporation State / Country Code Concept # dei:EntityIncorporationStateCountryCode Type or regex Meaning Two-character EDGAR code. US States and Canadian provinces are represented by their postal code (e.g., WA, BC); other countries by a code matching [A-Z]\d. {1} [A-Z][A-Z0-9] Transformation ixt-sec:edgarprovcountry [§ 11.12] transforms the full names of countries and Canadian provinces to their EDGAR codes. Validations: Incl s: FAST Excl s: FAST s: FAST, R33, R34 s: ALL c Check r A {1} fact is present. If {1} facts are present, r then at least one is visible. r A {1} fact is absent. f On failure {1} Missing {1} in Facts Not Visible {1} Unexpected s EFM v68 Ref W § 6.5.47 Ri W § 6.5.47 Ri W § 6.5.47 [], O* Notes and special cases: none. 3.1.20 Tax Identification Number Concept # Type or regex Meaning Shown on forms as “IRS Employer {1} \d{2}-\d{7} ID”. dei:EntityTaxIdentificationNumber Validations: Types Excl c Assertion f On failure s: FAST i: AF.CA r A {1} fact is present. {1} Missing s: FAST r If {1} facts are present, then at least one is visible. {1} in Facts Not Visible r A {1} fact is absent. {1} Unexpected s: FAST, R34, i: AF.CA s: ALL s EFM v68 Ref § 6.5.47 Ri, W O § 6.5.47 Ri, W O § 6.5.47 [], W O* Notes and special cases: none. 3.1.21 Primary SIC (Standard Industrial Code) Number Concept dei:EntityPrimarySicNumber # {1} Type or regex \d{4} Meaning SEC-assigned Standard Industrial Code Validations: Incl Excl AF.CA s: ALL s: R34, i: AF.CA Notes and special cases: none 42 c Assertion If {1} facts are present, r then at least one is visible. r A {1} fact is absent. f On failure s EFM v68 Ref {1} in Facts Not Visible W § 6.5.47 O {1} Unexpected W § 6.5.47 [], O* 3.1.22 Principal Office Address The facts expected for the principal office address vary across instance types. 3.1.22.1 Street, City and Zip Concept dei:EntityAddressAddressLine1 dei:EntityAddressCityOrTown dei:EntityAddressPostalZipCode # {1} {2} {3} Type or regex xs:normalizedString xs:normalizedString xs:normalizedString Meaning The first line of the address, the city or town, and postal or zip code, share identical checks. Validations: Incl Excl s: FAST s: FAST s: ALL s: FAST s: FAST, 6K, R34, R33, EBP s: FAST s: ALL s: FAST r A {1} fact is absent. r A {2} fact is present. If {2} facts are present, then at least one is visible. r s: FAST, 6K, R34, R33, EBP s: FAST s: ALL c Check r A {1} fact is present. If {1} facts are present, r then at least one is visible. r A {2} fact is absent. r A {3} fact is present. If {3} facts are present, then at least one is visible. r s: FAST, 6K, R34, R33, EBP r f On failure {1} Missing {1} in Facts Not Visible {1} Unexpected {2} Missing {2} in Facts Not Visible {2} Unexpected {3} Missing {3} in Facts Not Visible {3} Unexpected A {3} fact is absent. s EFM v68 Ref W § 6.5.48 Ri W § 6.5.48 Ri § 6.5.48 [], O* W § 6.5.48 Ri W W § 6.5.48 Ri § 6.5.48 [], O* W § 6.5.48 Ri W W § 6.5.48 Ri W § 6.5.48 [], O* Notes and special cases: none. 3.1.22.2 Street Address Lines 2 and 3 Concept dei:EntityAddressAddressLine1 dei:EntityAddressAddressLine2 dei:EntityAddress [Text truncated at 120,000 characters. The full text is on the page linked above.] --- Source: Frix Law Library, https://www.frixlaw.com/law-library/documents/agency%3Asec%3A43f8ee8bfc54673d. Public record. Not legal advice.