Prepared by SEC Staff
Agency decision
Ask Donna
What actually matters in this document.
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 <DOCTYPE> declaration not supported .............................................................................. 181
Inline XBRL validation................................................................................................................ 181
Element <head> 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:
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:ix="http://www.xbrl.org/2013/inlineXBRL"
xmlns:link="http://www.xbrl.org/2003/linkbase"
xmlns:dei="http://xbrl.sec.gov/dei/2024">
<head><title></title><meta http-equiv="Content-Type" content="text/html"/>
<body style="width: 7in"><div style="display: none">
<ix:header>
<ix:references>
<link:schemaRef xlink:type="simple"
xlink:href="https://xbrl.sec.gov/dei/2024/dei-sub-2024.xsd" />
</ix:references>
…
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:EntityAddressAddressLine3
#
{1}
{2}
{3}
Type or regex
xs:normalizedString
xs:normalizedString
xs:normalizedString
Meaning
Address line 2 should only appear if the first line does, likewise, address line 3 only if address line 2 does.
This should hold in any context.
Validations:
Incl
s: ALL
s: FAST,
i: RD.CEF
43
Excl
c Check
If a {2} fact is
a present, then a {1}
fact is present.
If {2} facts are
r present, then at least
one is visible.
f
On failure
{1} {2}
EFM v68 Ref
§ 6.5.48
W OL1*,
§ 6.5.51 OL1*
{2} in
Facts Not
Visible
W § 6.5.48 O
1 Dependency
s
Incl
s: ALL
Excl
s: FAST, 6K, R34,
i: RD.CEF, R33.US,
R33.FPI, EBP
s: ALL
s: FAST,
i: RD.CEF
s: ALL
s: FAST, 6K, R34,
i: RD.CEF, R33.US,
R33.FPI, EBP
c Check
r
f
A {2} fact is absent.
If a {3} fact is
a present, then a {2}
fact is also present.
If {3} facts are
r present, then at least
one is visible.
r
A {3} fact is absent.
On failure
s
{2}
Unexpected
W § 6.5.48 []
{2} {3}
Dependency
§ 6.5.48 OL2,
W OL2* § 6.5.51
OL2, OL2*
{3} in
Facts Not
Visible
W § 6.5.48 OL2
{3}
Unexpected
W
EFM v68 Ref
§ 6.5.48 [],
OL2*
Notes and special cases:
1. Condition OL1 is satisfied if address line 2 is present; address line 1 is already required.
3.1.22.3 State or Province and Country
Concept
dei:EntityAddressStateOrProvince
dei:EntityAddressCountry
#
Type or regex Meaning
Postal state or province. Inline XBRL transformations
{1} [A-Z][A-Z]
that convert state and province names to postal codes
(e.g., TX, ON) shown in § 11.12.
ISO 3166-1 alpha 2 (IANA) country code. Inline XBRL
{2} [A-Z][A-Z]
transformations convert country names to IANA () codes
(e.g., US, JP) are shown in § 11.12.
Validations:
Incl
Excl
s: FAST,
i: RD.CEF
i: AF.FPI
s: FAST,
i: RD.CEF
i: AF.FPI
s: FAST,
i: RD.CEF
s: ALL
s: ALL
s: FAST, R34,
R33, i: RD.CEF,
EBP
s: FAST, 6K, R34,
i: R33.US,
R33.FPI, EBP
Notes and special cases: none.
44
c Check
One or both {1}
r and {2} facts are
present.
If {1} facts are
r present, then at
least one is visible.
A {2} fact is
r
present.
If {2} facts are
r present, then at
least one is visible.
f
Codes
s
{1} {2}
W § 6.5.48 O2
1 Inclusive
EFM v68 Ref
§ 6.5.48 O,
O2
{1} in Facts
Not Visible
W
{2} Missing
W § 6.5.48 Ri
{2} in Facts
Not Visible
W
§ 6.5.48 O2,
Ri
r
A {1} fact is absent.
{1}
Unexpected
W
§ 6.5.48 [],
O*
r
A {2} fact is absent.
{2}
Unexpected
W
§ 6.5.48 [],
O*
3.1.22.4 Phone
Concept
dei:CityAreaCode
dei:LocalPhoneNumber
#
{1}
{2}
Type or regex
xs:normalizedString
xs:normalizedString
Meaning
Validations:
Types
i: R34.US,
R34.CA,
R33.US,
R33.FPI,
AF.FPI,
RD.CEF
s: 8K, QF,
i: AF.US,
AF.BDC,
RD.CEF, AF.CA
s: 8K, QF,
i: AF.US,
AF.BDC,
RD.CEF, AF.CA
s: ALL
s: 8K, QF,
i: AF.US,
AF.BDC,
RD.CEF, AF.CA
s: 8K, QF,
i: AF.US,
AF.BDC,
RD.CEF, AF.CA
s: ALL
Excl
c Check
Neither or
both of {1}
a
and {2} facts
are present.
f
1,
2
On failure
s
EFM v68 Ref
{1} {2}
Dependency
§ 6.5.48
Oph*,
W
§ 6.5.51 Oph,
Oph*
r
A {1} fact is
present.
{1} Missing
W § 6.5.48 Ri
i: QF.SEF
r
{1} in
Facts Not
Visible
W § 6.5.48 Ri
s: 8K, QF,
i: AF.US, AF.BDC,
RD.CEF, AF.CA,
R34.US, R34.CA,
R33.US, R33.FPI,
EBP
If {1} facts
are present,
then at least
one is visible.
r
A {1} fact is
absent.
{1}
Unexpected
W
i: QF.SEF
r
A {2} fact is
present.
{2} Missing
W § 6.5.48 Ri
i: QF.SEF
r
{2} in
Facts Not
Visible
W § 6.5.48 Ri
s: 8K, QF,
i: AF.US, AF.BDC,
RD.CEF, AF.CA,
R34.US, R34.CA,
R33.US, R33.FPI,
EBP
If {2} facts
are present,
then at least
one is visible.
r
A {2} fact is
absent.
{2}
Unexpected
W
i: QF.SEF
§ 6.5.48 [],
Oph*
§ 6.5.48 [],
O*
Notes and special cases:
1. Check is waived when the submission type matches POS*
2. Check applies in all contexts, and appears in both 6.5.48 and 6.5.51 (business address)
3.1.23 Submission Flags
Submission flags are grouped below when they have mutually dependent or exclusive values.
45
3.1.23.1 Annual Report, Transition Report, Quarterly Report
Concept
dei:DocumentAnnualReport
dei:DocumentTransitionReport
dei:DocumentShellCompanyReport
dei:DocumentShellCompanyEventDate
dei:DocumentQuarterlyReport
#
{1}
{2}
{3}
{4}
{5}
Type or regex Meaning
xs:boolean
xs:boolean
xs:boolean
xs:date
xs:boolean
When certain of the above concepts are expected, only one can have the value true.
Validations:
Incl
i: AF.US,
AF.BDC,
AF.CA
s: TF,
R34.FPI,
R34.CA
Excl
c Check
s: TF
r
A {1} fact valued
true is present.
{1} Value
Missing
W § 6.5.49 Y
s: QF, EBP
r
A {1} fact valued
false is present.
{1} Value
Missing
W
{1} {2}
Value
Dependency
W § 6.5.49 TF3
{1} {3}
Value
Dependency
W § 6.5.49 TF3
{2} {3}
Value
Dependency
W § 6.5.49 TF3
{2} {3}
Value
Dependency
W § 6.5.49 TF3
{3} {2}
Value
Dependency
W § 6.5.49 TF3
{3} {2}
Value
Dependency
W § 6.5.49 TF3
i: AF.FPI
r
i: AF.FPI
r
i: AF.FPI
r
i: AF.FPI
r
i: AF.FPI
r
i: AF.FPI
r
46
If a {1} fact valued
true is present,
then a {2} fact
valued false is
present.
If a {1} fact valued
true is present,
then a {3} fact
valued false is
present.
If a {2} fact valued
true is present,
then a {1} fact
valued false is
present.
If a {2} fact valued
true is present,
then a {3} fact
valued false is
present.
If a {3} fact valued
true is present,
then a {1} fact
valued false is
present.
If a {3} fact valued
true is present,
then a {2} fact
valued false is
present.
f On failure
s
EFM v68 Ref
§ 6.5.49 N,
N*
Incl
i: AF.US,
AF.BDC,
AF.CA
s: QF,
i: AF.US,
AF.BDC,
AF.CA
Excl
c Check
If {1} facts are
r present, then at
least one is visible.
r
{2} in Facts
Not Visible
W
§ 6.5.49 Y, N,
TF3
r
A {1} fact is
absent.
{1}
Unexpected
W § 6.5.49 []
r
A {2} fact is
absent.
{2}
Unexpected
W § 6.5.49 []
If {3} facts valued
true are present,
then {4} is present.
If {3} facts valued
false are present,
then {4} is absent.
If {4} facts are
present, then at
least one is visible.
A {4} fact is
absent.
A {5} fact valued
false is present.
A {5} fact valued
true is present.
If {5} facts are
present, then at
least one is visible.
A {5} fact is
absent.
{3} {4}
Value
Dependency
W § 6.5.49 SR
{3} {4}
Value
Dependency
W § 6.5.49 SR
{4} in Facts
Not Visible
W § 6.5.49 SR
{4}
Unexpected
W § 6.5.49 []
r
i: AF.FPI
r
i: AF.FPI
r
s: ALL
i: AF.FPI, EBP
r
s: QF
s: TF
r
s: TF
s: AF, EBP
r
r
s: QF
§ 6.5.49 Y, N,
TF3
W § 6.5.49 N*
i: AF.FPI
s: ALL
W
{2} Value
Unexpected
r
s: QF
{1} in Facts
Not Visible
W § 6.5.49 TF3
R34.CA
s: ALL
EFM v68 Ref
{3} in Facts
Not Visible
r
s: ALL
If {2} facts are
present, then at
least one is visible.
s
If {3} facts are
present, then at
least one is visible.
A {1} fact valued
false is present.
i: AF.FPI
s: QF, i: AF.US,
AF.BDC, AF.CA,
AF.FPI, R34.CA,
EBP
s: QF, i: AF.US,
AF.BDC, AF.CA,
AF.FPI, EBP
f On failure
r
{5} Value
Missing
W § 6.5.49 N
{5} Value
Missing
W § 6.5.49 Y
{5} in Facts
Not Visible
W § 6.5.49 Y, N
{5}
Unexpected
W § 6.5.49 []
Notes and special cases: none.
3.1.23.2 Financial Statement Error Correction, Recovery Analysis
Concept
dei:DocumentFinStmtErrorCorrectionFlag
dei:DocumentFinStmtRestatementRecoveryAnalysisFlag
47
#
{1}
{2}
Type or regex Meaning
Annual reports expect a flag indicating error
xs:boolean
correction.
If error correction is true, then a flag
xs:boolean
indicating whether the restatement resulted in
an analysis of compensation recovery.
Validations:
Incl
i: AF.US,
AF.BDC,
AF.FPI, AF.CA
i: AF.US,
AF.BDC,
AF.FPI, AF.CA
s: ALL
Excl
c Check
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
i: AF.US,
AF.BDC,
AF.FPI, AF.CA
s: ALL
i: AF.US,
AF.BDC,
AF.FPI, AF.CA
f On failure
s
EFM v68 Ref
r
A {1} fact is
present.
{1} Missing
W § 6.5.49 R
r
If {1} facts are
present, then at least
one is visible.
{1} in Facts
Not Visible
W § 6.5.49 R
r
A {1} fact is absent.
{1}
Unexpected
W § 6.5.49 []
{1} {2} Value
Dependency
W § 6.5.49 RT
{1} {2} Value
Dependency
W § 6.5.49 RT
{2} in Facts
Not Visible
W § 6.5.49 RT
{2}
Unexpected
W § 6.5.49 []
If a {1} fact valued
true is present,
a
then {2} is
present.
If a {1} fact valued
a false is present,
then {2} is absent.
If {2} facts are
r present, then at least
one is visible.
r
A {2} fact is
absent.
Notes and special cases: none.
3.1.23.3 Non-US Filer Flags
Miscellaneous flags apply only to non-US filers.
Concept
#
dei:DocumentAccountingStandard
{3}
dei:OtherReportingStandardItemNumber
{4}
Item (17|18)
dei:DocumentRegistrationStatement
{5}
xs:boolean
dei:AnnualInformationForm
dei:AuditedAnnualFinancialStatements
{1}
{2}
Type or regex
xs:boolean
xs:boolean
U.S. GAAP|International
Financial Reporting
Standards|Other
Meaning
Note that the values are case
sensitive and contain spaces.
Note that the values are case
sensitive and contain spaces.
Validations:
Incl
s: AF.CA
Excl
s: AF.CA
s: ALL
s: AF.CA
c Check
r A {1} fact is present.
If {1} facts are present, then at
r
least one is visible.
r
s: AF.CA
r
s: AF.CA
r
48
A {1} fact is absent.
A {2} fact is present.
If {2} facts are present, then at
least one is visible.
f On failure
{1} Missing
{1} in
Facts Not
Visible
{1}
Unexpected
{2} Missing
{2} in
Facts Not
Visible
s
EFM v68 Ref
W § 6.5.49 Ri
W § 6.5.49 Ri
W § 6.5.49 []
W § 6.5.49 Ri
W § 6.5.49 Ri
Incl
Excl
c Check
s: ALL
s: AF.CA
r
i: AF.FPI
r
i: AF.FPI
r
i: AF.FPI,
R34.FPI
f On failure
A {2} fact is absent.
A {3} fact is present.
If {3} facts are present, then at
least one is visible.
r
A {3} fact is absent.
i: AF.FPI,
R34.FP
r
If a {3} fact valued Other is
present, then {4} is present.
i: AF.FPI,
R34.FP
r
If a {3} fact valued Other is
absent, then {4} is absent.
i: AF.FPI
r
If {4} facts are present, then at
least one is visible.
r
A {4} fact is absent.
s: ALL
s: ALL
i: AF.FPI,
AF.CA
i: AF.FPI,
AF.CA
i: R34.CA,
R34.FPI
s: ALL
i: AF.FPI,
R34.FPI
If a {5} fact is present, it is
valued false.
If {5} facts are present, then at
least one is visible.
If a {5} fact is present, it is
valued true.
r
r
r
i: AF.FPI,
AF.CA.
R34.FPI,
R34.CA
{2}
Unexpected
{3} Missing
{3} in
Facts Not
Visible
{3}
Unexpected
{3} {4}
Value
Dependency
{3} {4}
Value
Dependency
{4} in
Facts Not
Visible
{4}
Unexpected
{5} Value
Missing
{5} in
Facts Not
Visible
{5} Value
Missing
{5}
Unexpected
A {5} fact is absent.
r
s
EFM v68 Ref
W § 6.5.49 []
W § 6.5.50 Ri
W § 6.5.50 Ri
§ 6.5.50 [],
O*
§ 6.5.50 Oth,
W
Oth*
W
W
§ 6.5.50 Oth,
Oth*
W § 6.5.50 Oth
W § 6.5.50 []
W § 6.5.49 N
W § 6.5.49 N
W § 6.5.49 Y*
W § 6.5.49 []
Notes and special cases: none.
3.1.23.4 Period Start Date
Concept
dei:DocumentTransitionReport
dei:DocumentPeriodStartDate
#
{1}
{2}
Type or regex Meaning
xs:boolean
xs:date
The period start date fact is required only for transition reports. In the case of Form 20-F, a transition
report cannot always be determined from the submission type alone.
Validations:
Incl
i: AF.FPI
s: TF
s: TF,
i: AF.FPI
s: ALL
Excl
c Check
If a {1} fact valued true is
r
present, then a {2} fact is present.
r A {2} fact is present.
If {2} facts are present, then at
r
least one is visible.
s: TF,
r
i: AF.FPI
A {2} fact is absent.
Notes and special cases: none.
49
f On failure
{1} {2}
Value
Dependency
{2} Missing
{1} in Facts
Not Visible
{2}
Unexpected
s
EFM v68 Ref
W § 6.5.49 TR
W § 6.5.49 Ri
§ 6.5.49 Ri,
W
TR
W § 6.5.49 []
3.1.23.5 Bankruptcy Proceedings Flag
Concept
#
dei:EntityBankruptcyProceedingsReportingCurrent
{1}
Type or regex Meaning
xs:boolean
Validations:
Incl
s: QF,
i: AF.US,
AF.BDC,
AF.FPI
Excl
i: QF.SEF
s: QF, i: AF.US,
AF.BDC, AF.FPI,
R33.FPI, EBP
s: ALL
c Check
If {1} facts are
present, then at
r
least one is
visible.
f On failure
A {1} fact is
absent.
r
s
EFM v68 Ref
{1} in Facts
Not Visible
W § 6.5.49 O
{1}
Unexpected
W
§ 6.5.49 [],
O*
Notes and special cases: none.
3.1.23.6 Documents Incorporated by Reference
Form 10-K text describing documents incorporated by reference should appear in a text block fact.
Concept
dei:DocumentsIncorporatedByReferenceTextBlock
#
{1}
Type or regex
Text block (see 9.1.1, HTML restrictions on
Text Block facts, below)
Meaning
Validations:
Incl
Excl
c Check
If {1} facts are present, then at
i: AF.US,
r
AF.BDC
least one is visible.
i: AF.US,
s: ALL
r A {1} fact is absent.
AF.BDC
f On failure
{1} in Facts
Not Visible
{1}
Unexpected
s
EFM v68 Ref
W § 6.5.49 O
W § 6.5.49 []
Notes and special cases: none.
3.1.23.7 Current Report
Concept
#
Type or regex
dei:WrittenCommunications
{1}
xs:boolean
{3}
xs:boolean
dei:SolicitingMaterial
dei:PreCommencementTenderOffer
dei:PreCommencementIssuerTenderOffer
dei:EntityInformationFormerLegalOrRegisteredName
{2}
{4}
{5}
Meaning
xs:boolean
xs:boolean
xs:normalizedString
(e.g., “OLDCO Inc.”)
Validations:
Incl
s: 8K
Excl
s: 8K
s: ALL
s: 8K
50
s: 8K
c Check
r A {1} fact is present.
If {1} facts are present, then
r
at least one is visible.
r A {1} fact is absent.
r A {2} fact is present.
f On failure
{1} Missing
{1} in Facts Not
Visible
{1} Unexpected
{2} Missing
s
EFM v68 Ref
W § 6.5.52 Ri
W § 6.5.52 Ri
W § 6.5.52 []
W § 6.5.52 Ri
Incl
Excl
s: 8K
s: ALL
s: 8K
s: 8K
s: 8K
s: ALL
s: 8K
s: 8K
s: 8K
s: ALL
s: 8K,
QF
s: ALL
s: 8K
i:
QF.SEF
s: 8K,
QF
c Check
If {2} facts are present, then
r
at least one is visible.
r A {2} fact is absent.
r A {3} fact is present.
If {3} facts are present, then
r
at least one is visible.
r A {3} fact is absent.
r A {4} fact is present.
If {4} facts are present, then
r
at least one is visible.
r A {4} fact is absent.
If {5} facts are present, then
r
at least one is visible.
r
f On failure
{2} in Facts Not
Visible
{2} Unexpected
{3} Missing
{3} in Facts Not
Visible
{3} Unexpected
{4} Missing
{4} in Facts Not
Visible
{4} Unexpected
{5} in Facts Not
Visible
{5} Unexpected
A {5} fact is absent.
s
EFM v68 Ref
W § 6.5.52 Ri
W § 6.5.52 []
W § 6.5.52 Ri
W § 6.5.52 Ri
W § 6.5.52 []
W § 6.5.52 Ri
W § 6.5.52 Ri
W § 6.5.52 []
W § 6.5.52 O
W § 6.5.52 []
Notes and special cases: none
3.1.23.8 Material Cybersecurity Incident Disclosure
Concept
#
Type or regex
Meaning
Values of element item in
submission header
{1}
Several values all matching
Form 8-K Item
number
[1-9].[0-9][1-9]
Validations:
Incl
Excl c Check
If any value of {1} is 1.05, then a non-nil,
s: 8K
r
non-empty CYD fact is present.
f
1
On failure
No CYD facts present
for Item 1.05
s
W
Notes and special cases:
1. CYD concepts are defined in 10.8.9 below.
3.1.24 Closed-end fund registration
The cover page of Form N-2 has over 30 check box, date, amendment, and file number facts, many of
which have interdependent values or are mutually exclusive. The subsections below break these facts into
related groups.
Note that unlike other Checks involving facts in the required context, violation of these is more likely to
raise an error, not a warning.
Most concepts related to these Checks are in the dei namespace; a few are specific to closed-end funds
and thus appear in the cef taxonomy.
3.1.24.1 N-2 Registration file numbers
Concept
Submission type from EDGAR header
dei:DocumentRegistrationStatement
dei:InvestmentCompanyActRegistration
51
#
{1}
{2}
{3}
Type or regex
xs:boolean
xs:boolean
Meaning
Concept
dei:EntityFileNumber
dei:InvestmentCompanyActFileNumber
cef:BdcFileNumber
#
{4}
{5}
{6}
Type or regex
\d{1,3}-\d{1,8}(-.{1,4})?
\d{1,3}-\d{1,8}(-.{1,4})?
\d{1,3}-\d{1,8}(-.{1,4})?
Meaning
Form N-2, when submitted to EDGAR as submission type N-2, represents an initial filing in which no
SEC file number has yet been assigned. All subsequent submissions will have one or more file numbers
appearing on the cover page.
Validations:
Incl
i: RD.CEF
i: RD.CEF
i: RD.CEF
i: RD.CEF
i: RD.CEF
i: RD.CEF
i: RD.CEF
i: RD.CEF
i: RD.CEF
i: RD.CEF
i: RD.CEF
i: RD.CEF
i: RD.CEF
i: RD.CEF
Excl c Check
If {1} is N-2, then a {4} fact is
r
absent.
If {1} is N-2, then a {5} fact is
r
absent.
If {1} is N-2, then a {6} fact is
r
absent.
Either or both a {2} fact valued
a true or a {3} fact valued true
must be present.
Neither or both a {2} fact valued
a
true and a {4} fact exist.
If {2} facts are present, then at
r
least one is visible.
If {4} facts are present, then at
r
least one is visible.
Neither or both a {3} fact valued
a
true and a {5} fact exist.
If {3} facts are present, then at
r
least one is visible.
If {5} facts are present, then at
r
least one is visible.
At most one of {5} or {6} are
a
present.
If {5} facts are present, then at
r
least one is visible.
If {6} facts are present, then at
r
least one is visible.
If {6} facts are present, their
a
value must begin with 814-
f
On failure
s
EFM v68 Ref
1 {4} Unexpected
W § 6.5.55 []
1 {5} Unexpected
W § 6.5.55 []
1 {6} Unexpected
W § 6.5.55 []
{3} {4}
Inclusive
E
§ 6.5.55 n2c
{2} {4} Value
Dependency
E
§ 6.5.55 n2sn
E
§ 6.5.55 n2sn
E
§ 6.5.55 n2sn
E
§ 6.5.55 n2in
E
§ 6.5.55 n2in
E
§ 6.5.55 n2in
E
§ 6.5.55 n2bn
E
§ 6.5.55 n2bn
{6} in Facts
Not Visible
E
§ 6.5.55 n2bn
{6} Value
E
§ 6.5.55 n2bn
{2} in Facts
Not Visible
{2} in Facts
Not Visible
{3} {5} Value
Dependency
{3} in Facts
Not Visible
{5} in Facts
Not Visible
{5} {6}
Exclusive
{5} in Facts
Not Visible
Notes and special cases:
1. In general, the first form N-2 submission is not an amendment and will have no file numbers.
2. The file number regex is less restrictive than that used in EDGAR submission headers.
3.1.24.2 N-2 Registration Amendment Numbers
Subsequent submissions after the first Form N-2 will have amendment numbers that are different
depending on whether the registration is under the Securities Act or the Investment Company Act and
whether they occur before or after the registration becomes effective.
52
Concept
Submission type from EDGAR header
#
{1}
{2}
{3}
{4}
{5}
{6}
{7}
{8}
{9}
dei:DocumentRegistrationStatement
dei:PreEffectiveAmendment
dei:PreEffectiveAmendmentNumber
dei:PostEffectiveAmendment
dei:PostEffectiveAmendmentNumber
dei:InvestmentCompanyActRegistration
dei:InvestmentCompanyRegistrationAmendment
dei:InvestmentCompanyRegistrationAmendmentNumber
Type or regex
Meaning
xs:boolean
xs:boolean
xs:positiveInteger
xs:boolean
xs: positiveInteger
xs:boolean
xs:boolean
xs:positiveInteger
Note that these tend to be errors, not warnings.
Validations:
Incl
i: RD.CEF
i: RD.CEF
i: RD.CEF
i: RD.CEF
i: RD.CEF
i: RD.CEF
i: RD.CEF
i: RD.CEF
i: RD.CEF
i: RD.CEF
i: RD.CEF
i: RD.CEF
i: RD.CEF
i: RD.CEF
i: RD.CEF
53
Excl c Check
If {1} is N-2, then a {3} fact is
r
absent.
If {1} is N-2, then a {5} fact is
r
absent.
If a {3} fact value is true, then
a
there is a {2} fact valued true.
If a {5} fact value is true, then
a
there is a {2} fact valued true.
If a {8} fact value is true, then
a
there is a {7} fact valued true.
Neither or both {3} fact has the
r
value true and a {4} fact exists.
Neither or both {5} fact has the
r
value true and a {6} fact exists.
Neither or both {8} fact has the
r
value true and a {9} fact exists.
If {2} facts valued true are
r present, then at least one is
visible.
If {3} facts valued true are
r present, then at least one is
visible.
If {4} facts are present, then at
r
least one is visible.
If {5} facts valued true are
r present, then at least one is
visible.
If {6} facts are present, then at
r
least one is visible.
If {7} facts valued true are
r present, then at least one is
visible.
If {8} facts valued true are
r present, then at least one is
visible.
f
On failure
s
{3} Unexpected
W § 6.5.55 []
{5} Unexpected
W § 6.5.55 []
{3} {2} Value
Dependency
E
§ 6.5.55 n2d
E
§ 6.5.55 n2f
E
§ 6.5.55 n2h
E
§ 6.5.55 n2e
E
§ 6.5.55 n2g
E
§ 6.5.55 n2i
{2} in Facts Not
E
§ 6.5.55 n2d
{3} in Facts Not
E
§ 6.5.55 n2d
{4} in Facts Not
E
§ 6.5.55 n2e
{5} in Facts Not
E
§ 6.5.55 n2f
{6} in Facts Not
E
§ 6.5.55 n2g
{7} in Facts Not
E
§ 6.5.55 n2h
{8} in Facts Not
E
§ 6.5.55 n2h
{5} {2} Value
Dependency
{8} {7} Value
Dependency
{3} {4} Value
Dependency
{5} {6} Value
Dependency
{8} {9} Value
Dependency
1 Visible
1 Visible
1 Visible
1 Visible
1 Visible
1 Visible
1 Visible
EFM v68 Ref
Incl
Excl c Check
If {9} facts are present, then at
i: RD.CEF
r
least one is visible.
f
On failure
{9} in Facts Not
Visible
1
s
EFM v68 Ref
E
§ 6.5.55 n2i
Notes and special cases:
1. There are no checks for the absence of these facts in instance types other than RD.CEF.
3.1.24.3 N-2 Commencement of Sales
Concept
#
Type or regex
dei:ApproximateDateOfCommencementOfProposedSaleToThePublic
{1}
(As soon as practicable|From time to
time) after the effective date of this
Registration Statement\.?)|(20\d\d-(0[19]|1[0-2])-(3[01]|[012]\d))
Meaning
Note that the
text values
contain
spaces.
Validations:
Incl
Excl c Check
f On failure
s
Ref
i: RD.CEF
r A {1} fact is present. 1 {1} Missing W § 6.5.55 Ri
Notes and special cases:
1. There is no check for the absence of this fact in instance types other than RD.CEF.
3.1.24.4 N-2 Rule Flags
Concept
dei:DividendOrInterestReinvestmentPlanOnly
dei:DelayedOrContinuousOffering
cef:PrimaryShelfFlag
dei:EffectiveUponFiling462e
dei:AdditionalSecuritiesEffective413b
#
{1}
{2}
{3}
{4}
{5}
Type or regex Meaning
xs:boolean
xs:boolean
xs:boolean
xs:boolean
xs:boolean
Validations:
Incl
i: RD.CEF
i: RD.CEF
i: RD.CEF
i: RD.CEF
i: RD.CEF
Excl c Check
If {1} facts valued true are
r present, then at least one is
visible.
If {2} facts valued true are
r present, then at least one is
visible.
If {3} facts valued true are
r present, then at least one is
visible.
If {4} facts valued true are
r present, then at least one is
visible.
If {5} facts valued true are
r present, then at least one is
visible.
f
On failure
s
{1} in Facts
E § 6.5.55 B
{2} in Facts
E § 6.5.55 B
{3} in Facts
E § 6.5.55 B
{4} in Facts
E § 6.5.55 B
{5} in Facts
E § 6.5.55 B
1 Not Visible
1 Not Visible
1 Not Visible
1 Not Visible
1 Not Visible
Notes and special cases:
1. There is no check for the absence of this fact in instance types other than RD.CEF.
54
EFM v68 Ref
3.1.24.5 N-2 Effectiveness Dates
Concept
dei:EffectiveWhenDeclaredSection8c
dei:EffectiveUponFiling486b
dei:EffectiveOnSetDate486b
dei:EffectiveOnDate486b
dei:EffectiveAfter60Days486a
dei:EffectiveOnSetDate486a
dei:EffectiveOnDate486a
#
{1}
{2}
{3}
{4}
{5}
{6}
{7}
Type or regex Meaning
xs:boolean
xs:boolean
xs:boolean
xs:date
xs:boolean
xs:boolean
xs:date
Validations:
Incl
i: RD.CEF
i: RD.CEF
i: RD.CEF
i: RD.CEF
i: RD.CEF
i: RD.CEF
i: RD.CEF
i: RD.CEF
i: RD.CEF
Excl c Check
If {1} facts valued true are
r present, then at least one is
visible.
If {2} facts valued true are
r present, then at least one is
visible.
If {3} facts valued true are
r present, then at least one is
visible.
Neither or both {3} fact has the
a
value true and a {4} fact exists.
If {4} facts are present, then at
r
least one is visible.
If {5} facts valued true are
r present, then at least one is
visible.
If {6} facts valued true are
r present, then at least one is
visible.
Neither or both {6} fact has the
a
value true and a {7} fact exists.
If {7} facts are present, then at
r
least one is visible.
f
On failure
s
{1} in Facts Not
E § 6.5.55 B
{2} in Facts Not
E § 6.5.55 B
{3} in Facts Not
E § 6.5.55 B
1 Visible
1 Visible
1 Visible
{3} {4} Value
Dependency
EFM v68 Ref
E § 6.5.55 n2j
{4} in Facts Not
E § 6.5.55 n2j
{5} in Facts Not
E § 6.5.55 B
{6} in Facts Not
E § 6.5.55 B
1 Visible
1 Visible
1 Visible
{6} {7} Value
Dependency
{7} in Facts Not
1 Visible
E § 6.5.55 n2k
E § 6.5.55 n2k
Notes and special cases:
1. There is no check for the absence of this fact in instance types other than RD.CEF.
3.1.24.6 N-2 Other Flags
Concept
dei:NewEffectiveDateForPreviousFiling
dei:AdditionalSecurities462b
dei:AdditionalSecurities462bFileNumber
dei:NoSubstantiveChanges462c
dei:NoSubstantiveChanges462cFileNumber
dei:ExhibitsOnly462d
dei:ExhibitOnly462dFileNumber
55
#
{1}
{2}
{3}
{4}
{5}
{6}
{7}
Type or regex
xs:date
xs:boolean
\d{1,3}-\d{1,8}(-.{1,4})?
xs:boolean
\d{1,3}-\d{1,8}(-.{1,4})?
xs:boolean
\d{1,3}-\d{1,8}(-.{1,4})?
Meaning
Validations:
Incl
i: RD.CEF
i: RD.CEF
i: RD.CEF
i: RD.CEF
i: RD.CEF
i: RD.CEF
i: RD.CEF
i: RD.CEF
i: RD.CEF
i: RD.CEF
Excl c Check
If {1} facts are present, then at
r
least one is visible.
If {2} facts valued true are
r present, then at least one is
visible.
Neither or both {2} fact has the
a
value true and a {3} fact exists.
If {3} facts are present, then at
r
least one is visible.
If {4} facts valued true are
r present, then at least one is
visible.
Neither or both {4} fact has the
a
value true and a {5} fact exists.
If {5} facts are present, then at
r
least one is visible.
If {6} facts valued true are
r present, then at least one is
visible.
Neither or both {6} fact has the
a
value true and a {7} fact exists.
If {7} facts are present, then at
r
least one is visible.
f
On failure
{1} in Facts Not
Visible
1
{2} in Facts Not
1 Visible
{2} {3} Value
Dependency
s
EFM v68 Ref
E § 6.5.55 B
E § 6.5.55 B
E § 6.5.55 n2l
{3} in Facts Not
E § 6.5.55 n2l
{4} in Facts Not
E § 6.5.55 B
1 Visible
1 Visible
{4} {5} Value
Dependency
E § 6.5.55 n2m
{5} in Facts Not
E § 6.5.55 n2m
{6} in Facts Not
E § 6.5.55 B
1 Visible
1 Visible
{6} {7} Value
Dependency
{7} in Facts Not
1 Visible
E § 6.5.55 n2o
E § 6.5.55 n2o
Notes and special cases:
1. There is no check for the absence of this fact in instance types other than RD.CEF.
3.1.24.7 N-2 Registrant Type Flags
Concept
cef:RegisteredClosedEndFundFlag
cef:BusinessDevelopmentCompanyFlag
cef:IntervalFundFlag
cef:PrimaryShelfQualifiedFlag
dei:EntityWellKnownSeasonedIssuer
dei:EntityEmergingGrowthCompany
dei:EntityExTransitionPeriod
cef:NewCefOrBdcRegistrantFlag
#
{1}
{2}
{3}
{4}
{5}
{6}
{7}
{8}
Type or regex Meaning
xs:boolean
xs:boolean
xs:boolean
xs:boolean
Yes|No
xs:boolean
xs:boolean
xs:boolean
Validations:
Incl
Excl c Check
If {1} facts valued true are
i: RD.CEF
r
present, then at least one is visible.
At most one of {1} and {2} has the
i: RD.CEF
r
value true.
If {2} facts valued true are
i: RD.CEF
r
present, then at least one is visible.
56
f
On failure
{1} in Facts Not
1
Visible
s
1 Exclusive Values
{2} in Facts Not
1
Visible
E § 6.5.55 n2p
{1} {2}
EFM v68 Ref
E § 6.5.55 n2p
E § 6.5.55 B
Incl
i: RD.CEF
i: RD.CEF
i: RD.CEF
i: RD.CEF
i: RD.CEF
i: RD.CEF
Excl c Check
If {3} facts valued true are
r
present, then at least one is visible.
If {4} facts valued true are
r
present, then at least one is visible.
If {5} facts valued true are
r
present, then at least one is visible.
If {6} facts valued true are
r
present, then at least one is visible.
If {7} facts valued true are
r
present, then at least one is visible.
If {8} facts valued true are
r
present, then at least one is visible.
f
On failure
{3} in Facts Not
1
Visible
{4} in Facts Not
1
Visible
{5} in Facts Not
Visible
{6} in Facts Not
Visible
{7} in Facts Not
2
Visible
{8} in Facts Not
Visible
s
EFM v68 Ref
E § 6.5.55 B
E § 6.5.55 B
E § 6.5.55 B
E § 6.5.55 B
E § 6.5.55 B
E § 6.5.55 B
Notes and special cases:
1. Some concepts in this section are drawn from the cef namespace, not dei.
2. See 3.1.11 above for checks related to this fact value for other instance types.
3.2 Expected Facts with Dimensions
Taxonomy-defined dimensions, as introduced in section 1 above, are used to define XBRL hypercubes. In
this document as in all SEC standard taxonomies a taxonomy-defined dimension is called an Axis.
Members of an axis may be its default member, a standard member, or a custom member defined by the
filer. In addition to indicators such as names and indentations within tables, concept types used in this
document are additionally color-coded as shown in Figure 1.
Figure 1. Dimension figures color-coding legend
Concept or value type
Concept core dimension and concepts
Other core dimensions and their members
Fact values
Taxonomy-defined dimension (Axis)
Standard members
Custom members
Abstract placeholder concepts not appearing in instances, such as hypercubes,
line items, domain defaults, and non-usable domain members.
Color
Green
Gray
None
Orange
Medium Blue
Purple
Light Blue
A hypercube of only a single taxonomy-defined dimension can be visualized as a table presented in a
disclosure as illustrated in Figure 2. Note that if not specified as region 1 or 2, the value is the sum across
the two regions.
Figure 2. Example showing nine facts with a single taxonomy-defined dimension
entity: Example01
period: FY30
units: USD
Region 1
Region Axis Region 2
57
Concepts Dimension
Product Revenue
23
17
40
Service Revenue
12
8
20
Combined Revenue
35
25
60
Layout and formatting for presentation of the data to a human reader does not change the meaning and
therefore does not change the characterization of each of the nine facts. Figure 3 shows the same facts,
with the concept dimension presented as rows, and the class dimension as columns.
Figure 3. Example showing a different presentation of the same nine facts
entity: Example01
period: FY30
units: USD
Product Revenue
Concepts
Service Revenue
Dimension
Combined Revenue
Region Axis
Region 1
Region 2
23
12
35
17
8
25
40
20
60
Data in in instances is organized into hypercubes having zero or more axes; as the previous two figures
show, they are usually thought of – and referred to as – Tables. Some axes have a set of members fixed by
a taxonomy, others are empty in the taxonomy and are populated only by custom members. Although
filers may define facts that use additional axes beyond those in the table, some taxonomy tables are closed
and restrict the facts to use only certain axes.
The representation of individual facts in Figure 2 and Figure 3 can be understood as a table whose
columns represent each dimension and the value of the fact, and each row representing a separate fact.
Where a taxonomy defined dimension (in this case, Region) is blank, that indicates it is the default of that
dimension.
Figure 4. Example showing the nine individual facts
Entity
Example01
Example01
Example01
Example01
Example01
Example01
Example01
Example01
Example01
Period
FY30
FY30
FY30
FY30
FY30
FY30
FY30
FY30
FY30
Unit
USD
USD
USD
USD
USD
USD
USD
USD
USD
Concept
Product Revenue
Service Revenue
Combined Revenue
Product Revenue
Service Revenue
Combined Revenue
Product Revenue
Service Revenue
Combined Revenue
Region
Value
Region 1
23
Region 1
12
Region 1
35
Region 2
17
Region 2
8
Region 2
25
40
20
60
The appearance of a concept and a set of facts with or without members of a given dimension may be
interpreted in various ways. The first common case is as detailed above: a numeric fact without a
dimension equaling the sum of other facts having members of that dimension. The axis represents a
disaggregation of a total.
The second common case, less common for numeric facts, but prevalent for non-numeric facts such as
text and dates, is that a fact can be inferred from the relationship between the Axis default (representing
the whole) and the absence of a member on the axis:
Entity
Period
Concept
Region
Value
Example01 FY30
Best Seller
Example01 FY30
Best Seller Region 2 Product B
Product A
This case implies that product A is the company’s best seller overall and in region 1, but region 2 is an
exception where product B is the best seller; although different, it is not contradictory.
58
A third case is the appearance of non-numeric facts, each with a different member of the axis, but no
default:
Entity
Period
Concept
Region
Value
Example01 FY30
Sponsored Team Region 1 Red Sox
Example01 FY30
Sponsored Team Region 2 White Sox
It would be meaningless to sum, merge, average or concatenate text values for this non-numeric concept
to come up with a sponsored team for the whole company. A software program might expect a sponsored
team for the whole company, or for each of its individual regions, but signal a problem if it receives
values for both the whole and the parts. In this case, the use of the axis default, and the use of individual
members, are mutually exclusive.
The interpretation of a given combination of concept and axis always impacts the expected and
unexpected facts in an instance; this is particularly true for the mostly non-numeric expected facts.
3.2.1 Business contact
When a business contact is expected, the facts are present in the business contact (bc) context defined as
the required context plus a single dimension dei:EntityAddressesAddressTypeAxis with standard
member dei:BusinessContactMember.
3.2.1.1
Contact Person
Concept
#
dei:ContactPersonnelName
dei:LocalPhoneNumber
dei:ContactPersonnelFax
dei:ContactPersonnelEmailAddress
{1}
{2}
{3}
{4}
Type or regex
Meaning
xs:normalizedString
xs:normalizedString
xs:normalizedString
xs:normalizedString
Validations:
Incl
i: AF.FPI,
RD.CEF,
AF.CA
Excl
i: AF.FPI,
RD.CEF,
AF.CA
s: ALL
c
Check
bc
A {1} fact is
present.
bc
i: R34.FPI, R34.CA,
R33.FPI, R33.US
bc
i: AF.FPI,
RD.CEF
bc
i: AF.CA
bc
i: AF.CA
bc
59
If {1} facts are
present, then at
least one is
visible.
A {1} fact is
absent.
One, two, or all
three {2}, {3}
or {4} facts are
present.
A {2} fact is
present.
If {2} facts are
present, then at
least one is
visible.
f On failure
s
EFM v68 Ref
{1} Missing
W § 6.5.51 Ri
{1} in Facts
Not Visible
W § 6.5.51 Ri
{1}
Unexpected
W
{2} {3} {4}
Missing
W § 6.5.51 O3
{2} Missing
W § 6.5.51 Ri
{2} in Facts
Not Visible
W § 6.5.51 O3
§ 6.5.51 [],
O*
Incl
Excl
i: AF.FPI, RD.CEF,
AF.CA, R34.FPI,
R34.CA, R33.FPI,
R33.US
s: ALL
i: AF.FPI,
RD.CEF
i: AF.FPI,
RD.CEF
bc
A {2} fact is
absent.
bc
bc
i: AF.FPI, RD.CEF,
R34.FPI, R34.CA
s: ALL
Check
bc
i: AF.FPI, RD.CEF,
R34.FPI, R34.CA
s: ALL
c
bc
f On failure
If {3} facts are
present, then at
least one is
visible.
A {3} fact is
absent.
If {4} facts are
present, then at
least one is
visible.
A {4} fact is
absent.
s
EFM v68 Ref
{2}
Unexpected
W
§ 6.5.51 [],
O*
{3} in Facts
Not Visible
W § 6.5.51 O3
{3}
Unexpected
W
{4} in Facts
Not Visible
W § 6.5.51 O3
{4}
Unexpected
W
§ 6.5.51 [],
O*
§ 6.5.51 [],
O*
Notes and special cases: none.
3.2.1.2
Street, City and Zip
A business contact will have similar facts to the principal address.
Concept
#
dei:EntityAddressAddressLine1
dei:EntityAddressCityOrTown
dei:EntityAddressPostalZipCode
{1}
{2}
{3}
Type or regex
Meaning
xs:normalizedString
xs:normalizedString
xs:normalizedString
The first line of the address, the city or town, and postal or zip code, share similar validations:
Incl
i: AF.FPI,
RD.CEF,
AF.CA
Excl
i: AF.FPI,
RD.CEF,
AF.CA
s: ALL
i: AF.FPI,
RD.CEF,
AF.CA
i: AF.FPI,
RD.CEF,
AF.CA
60
i: AF.FPI, RD.CEF,
AF.CA, R34.FPI,
R34.CA R33.FPI
R33.US
c
Check
f On failure
s
EFM v68 Ref
bc
A {1} fact is
present.
{1} Missing
W § 6.5.51 Ri
If {1} facts are
present, then at
bc
least one is
visible.
{1} in Facts
Not Visible
W § 6.5.51 Ri
bc
A {1} fact is
absent.
{1}
Unexpected
W
bc
A {2} fact is
present.
{2} Missing
W § 6.5.51 Ri
If {2} facts are
present, then at
bc
least one is
visible.
{2} in Facts
Not Visible
W § 6.5.51 Ri
§ 6.5.51 [],
O*
Incl
s: ALL
i: AF.FPI,
RD.CEF,
AF.CA
Excl
i: AF.FPI, RD.CEF,
AF.CA, R34.FPI,
R34.CA R33.FPI
R33.US
i: AF.FPI,
RD.CEF,
AF.CA
i: AF.FPI, RD.CEF,
AF.CA, R34.FPI,
R34.CA R33.FPI
R33.US
s: ALL
c
Check
f On failure
s
EFM v68 Ref
bc
A {2} fact is
absent.
{2}
Unexpected
W § 6.5.51 []
bc A {3} fact is
present.
{3} Missing
W § 6.5.51 Ri
bc If {3} facts are
present, then at
least one is
visible.
bc A {3} fact is
absent.
{3} in Facts
Not Visible
W § 6.5.51 Ri
{3}
Unexpected
W § 6.5.51 [],
O*
Notes and special cases: none.
3.2.1.3
State or Province and Country
Concept
#
Type or regex
dei:EntityAddressStateOrProvince
{1}
Postal state or
province
dei:EntityAddressCountry
{2}
Valid IANA
country code
Meaning
XBRL transformations that convert state and
province names to postal codes (e.g., TX, ON) are
shown in § 11.2.
XBRL transformations that country names to ISO
3166-1 alpha 2 (IANA) codes (e.g., US, JP) are
shown in § 11.2.
Validations:
Incl
Excl
c
i: AF.FPI,
RD.CEF
bc
i: AF.CA
bc
i: AF.FPI,
RD.CEF,
AF.CA
bc
i: R34.CA
bc
s: ALL
i: AF.FPI,
RD.CEF
61
i: AF.FPI,
RD.CEF, AF.CA,
R34.CA, R33.US
Check
One or both {1}
and {2} facts are
present.
A {1} fact
representing a US
state is present.
If {1} facts are
present, then at
least one is visible.
A {1} fact
representing a
Canadian province
is present.
f Codes
s
EFM v68 Ref
{1} {2}
Inclusive
W § 6.5.51 O2
{1} Value
W § 6.5.51 Ru
{1} in Facts
Not Visible
W
{1} Value
W § 6.5.51 Ou*
bc A {1} fact is absent.
{1}
Unexpected
W
If {2} facts are
bc present, then at
least one is visible.
{2} in Facts
Not Visible
W § 6.5.51 O2
§ 6.5.51 O2,
Ru
§ 6.5.51 [],
O*
Incl
Excl
i: R33.FPI,
R34.FPI
s: ALL
c
Check
f Codes
{2}
Unexpected
bc A {2} fact is absent.
s
EFM v68 Ref
W § 6.5.51 []
Notes and special cases: none.
3.2.1.4
Phone
Concept
dei:CityAreaCode
dei:LocalPhoneNumber
#
Type or regex
{1}
{2}
Meaning
xs:normalizedString
xs:normalizedString
Validations:
Incl
Excl
i: AF.CA
i: AF.CA,
AF.FPI,
RD.CEF
i: AF.CA, AF.FPI,
RD.CEF, R34.FPI,
R34.CA, R33.FPI,
R33.US
s: ALL
i: AF.CA
Check
A {1} fact is
bc
present.
If {1} facts are
present, then at
bc
least one is
visible.
bc
A {1} fact is
absent.
A {2} fact is
present.
If {2} facts are
present, then at
bc
least one is
visible.
bc
i: AF.CA,
AF.FPI,
RD.CEF
s: ALL
c
i: AF.CA, AF.FPI,
RD.CEF, R34.FPI,
R34.CA, R33.FPI,
R33.US
bc
A {2} fact is
absent.
f
On failure
s
EFM v68 Ref
{1} Missing
W § 6.5.51 Ri
1
{1} in Facts
Not Visible
W § 6.5.51 Oph
1
{1}
Unexpected
W
{2} Missing
W § 6.5.51 Ri
{2} in Facts
Not Visible
W
§ 6.5.51 O3,
Ri
{2}
Unexpected
W
§ 6.5.51 [],
O*
§ 6.5.51 [],
Oph*
Notes and special cases:
1. Neither or both CityAreaCode and LocalPhoneNumber should be present in any context, not just
the business contact context; see 3.1.22.4 above.
3.2.2 Former address
To report a former address, the facts are present in the Former Address (fa) context defined as the required
context plus a single dimension dei:EntityAddressesAddressTypeAxis with member dei:FormerAddressMember.
3.2.2.1
Concept
Former Street, City and Zip
dei:EntityAddressAddressLine1
dei:EntityAddressAddressLine2
dei:EntityAddressAddressLine3
dei:EntityAddressCityOrTown
dei:EntityAddressPostalZipCode
62
#
{1}
{2}
{3}
{4}
{5}
Type or regex
xs:normalizedString
xs:normalizedString
xs:normalizedString
xs:normalizedString
xs:normalizedString
Meaning
The first line of the address, the city or town, and postal or zip code, share similar validations.
Validations:
Incl
s: 8K,
QF
Excl
s: 8K,
QF
s: ALL
s: 8K,
QF
s: 8K,
QF
c
Check
If {1} facts are present, then
fa
at least one is visible.
s: 8K,
QF
s: 8K,
QF
s: 8K,
QF
s: 8K,
QF
s: 8K,
QF
s: 8K,
QF
s: 8K,
QF
s: 8K,
QF
s: 8K,
QF
W § 6.5.53 O
If {2} facts are present, then
at least one is visible.
If a {2} fact is present, then
fa
a {1} fact is present.
{2} in Facts Not
Visible
W § 6.5.53 OL1
{1} {2}
Dependency
W § 6.5.53 OL1
fa A {2} fact is absent.
{2} Unexpected
W § 6.5.53 []
If a {3} fact is present, then
a {2} fact is present.
If {3} facts are present, then
fa
at least one is visible.
{2} {3}
Dependency
W § 6.5.53 OL2
{3} in Facts Not
Visible
W § 6.5.53 OL2
fa A {3} fact is absent.
{3} Unexpected
W
{4} {5} Inclusive
W § 6.5.53 F2
{4} in Facts Not
Visible
W § 6.5.53 F2
{4} Unexpected
W § 6.5.53 []
{5}
This text is long and has been trimmed here. Open the source document for the complete record.
This is a copy of a public record, reproduced as it was published. It is not legal advice, and it may not be the version a court would rely on. Check the official source before you cite it.