Prepared by SEC Staff
Agency decision
Ask Donna
What actually matters in this document.
Text
EDGAR XBRL Guide
Prepared by SEC Staff
March 2024
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 ............................................................................................................... 8
2
XBRL SPECIFICATIONS ................................................................................................ 10
3
INSTANCE CONTENT ..................................................................................................... 11
3.1
3.1.1
3.1.2
3.1.3
3.1.4
3.1.5
3.1.6
3.1.7
3.1.8
3.1.9
3.1.10
3.1.11
3.1.12
3.1.13
3.1.14
3.1.15
3.1.16
3.1.17
3.1.18
3.1.19
3.1.20
3.1.21
3.1.22
3.1.23
3.1.24
3.2
3.2.1
3.2.2
3.2.3
3.2.4
3.2.5
3.2.6
3.3
3.3.1
3.3.2
3.3.3
3.3.4
3.3.5
3
Expected Facts in the Required Context ........................................................................................ 12
Notation and Terminology ............................................................................................................. 12
Required Context validation .......................................................................................................... 13
Central Index Key .......................................................................................................................... 14
Registrant Name ............................................................................................................................ 14
Form or Exhibit Type..................................................................................................................... 15
Amendment Flag and Description ................................................................................................. 16
Document Period End Date ........................................................................................................... 17
Document Fiscal Year and Period Focus ....................................................................................... 18
Current Reporting Status and Interactive Data Current ................................................................. 19
Voluntary Filers, Shell Companies, and Well-known Seasoned Issuers ................................... 19
Small Business, Emerging Growth Company ........................................................................... 21
Current Fiscal Year End Date .................................................................................................... 22
Filer Category (Accelerated / Non-Accelerated) ....................................................................... 23
ICFR Auditor Attestation Flag .................................................................................................. 24
Public Float................................................................................................................................ 25
Auditor Name, Location, and Firm ID ...................................................................................... 25
Investment Company Type........................................................................................................ 27
File Number (Securities Act File Number) ............................................................................... 28
Incorporation State / Country Code ........................................................................................... 28
Tax Identification Number ........................................................................................................ 28
Primary SIC (Standard Industrial Code) Number ..................................................................... 29
Principal Office Address ........................................................................................................... 29
Submission Flags ....................................................................................................................... 32
Closed-end fund registration ..................................................................................................... 37
Expected Facts with Dimensions ................................................................................................... 43
Business contact ............................................................................................................................. 45
Former address ............................................................................................................................... 48
Common Stock Shares Outstanding .............................................................................................. 50
Registered Securities...................................................................................................................... 51
Open-end Fund Series .................................................................................................................... 54
Open-end Fund Shareholder Reports ............................................................................................. 54
Resource Extraction Payments Disclosure .................................................................................... 56
Currency and Total Payments ........................................................................................................ 56
Payments Axis ............................................................................................................................... 56
Boolean, Numeric and String Valued Facts ................................................................................... 56
Member-valued Facts..................................................................................................................... 57
Payment Contexts .......................................................................................................................... 58
3.3.6
3.3.7
Government Aggregate Contexts ................................................................................................... 60
Project Aggregate Contexts ........................................................................................................... 61
4
FILING FEE EXHIBITS ................................................................................................... 61
5
CUSTOM TAXONOMIES ................................................................................................ 82
4.1
4.1.1
4.1.2
4.1.3
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.5.1
5.5.2
4
Filing Fee Inline XBRL Attachments ............................................................................................ 61
Security Types Based on Rule ....................................................................................................... 62
Offering & Transaction Valuation Rules Applicable for Submission Types ................................ 62
Offset Table & Combined Prospectus Rules Applicable for Submission Types ........................... 64
Submission Table ........................................................................................................................... 66
Fees Summary Table...................................................................................................................... 67
Offering Table................................................................................................................................ 69
Offering Table Rule Flags ............................................................................................................. 69
Rule 457(a) Lines........................................................................................................................... 69
Rule 457(o) Lines .......................................................................................................................... 70
Rule 457(r) Lines ........................................................................................................................... 71
Rule 457(s) Lines ........................................................................................................................... 72
Rule 457(u) Lines .......................................................................................................................... 73
Rule “Other” Lines ........................................................................................................................ 74
Rule 415(a)(6) Lines ...................................................................................................................... 75
Rule 0-11 Lines .............................................................................................................................. 76
Rule 457(f) Lines ........................................................................................................................... 77
General Instructions II.H (Exchange Offers) and II.I (Business Combinations)....................... 78
Offset Table ................................................................................................................................... 78
Offset Table Rule Flags ................................................................................................................. 78
Rule 457(b) or 0-11(a)(2)) Lines ................................................................................................... 78
Rule 457(p) Lines .......................................................................................................................... 79
Combined Prospectus Table .......................................................................................................... 80
Combined Prospectus Table Rule Flags ........................................................................................ 80
Combined Prospectus Lines Specifying Rule 429 ......................................................................... 80
Securities, 424I .............................................................................................................................. 81
Securities, 424I Table Rule Flags .................................................................................................. 81
Submission Type 424I Table Lines ............................................................................................... 81
Submission Type 424I Entries in the Submission Table ............................................................... 82
Custom presentation and label relationships for standard concepts............................................... 83
File attachments for custom relationships...................................................................................... 83
Custom presentation and label relationships.................................................................................. 83
Custom relationships for standard concepts, with dimensions ...................................................... 84
File attachments for custom members ........................................................................................... 84
Dimensional relationships.............................................................................................................. 85
Presentation and label relationships ............................................................................................... 87
Validation of custom relationships ................................................................................................ 87
Validations resulting in Errors ....................................................................................................... 87
Validations resulting in Warnings ................................................................................................. 88
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
6
6.1
6.2
6.3
6.3.1
6.3.2
6.3.3
6.4
6.5
6.6
6.7
6.8
6.9
6.10
6.11
6.12
6.13
6.14
6.15
5
Custom Concept Declarations in General ...................................................................................... 88
Do not duplicate pre-existing concept declarations ....................................................................... 88
Avoid changes in declarations from period to period .................................................................... 89
Custom concept naming................................................................................................................. 89
Custom concept declarations ......................................................................................................... 89
Custom Domain Member Declarations.......................................................................................... 89
Custom Presentation and Label Relationships ............................................................................... 91
Instance type 8K.A example – custom members ........................................................................... 91
Custom Calculation Relationships for Standard Concepts ............................................................ 91
When calculation relationships are required .................................................................................. 93
Avoid calculation relationship redundancy.................................................................................... 93
A single concept may have alternate calculations ......................................................................... 94
Custom Numeric Concepts ............................................................................................................ 94
Do not duplicate numeric concepts ........................................................................................... 94
Monetary concepts..................................................................................................................... 94
Share (unit of ownership) type concepts ................................................................................... 95
Per-share type concepts ............................................................................................................. 95
Pure number type concepts ........................................................................................................ 96
Percent type concepts ................................................................................................................ 96
Custom Non-Numeric Concepts .................................................................................................... 96
Custom Non-member Abstract concepts ................................................................................... 96
Custom text block type concepts ............................................................................................... 96
Custom dimensional concepts ................................................................................................... 97
Other custom non-numeric types............................................................................................... 97
Other custom taxonomy components............................................................................................. 98
INSTANCE RENDERING ................................................................................................ 98
Motivation for Standardized Rendering......................................................................................... 98
Presentation groups ........................................................................................................................ 99
Fact selection ................................................................................................................................. 99
Period Selection ........................................................................................................................... 100
Unit Selection .............................................................................................................................. 100
The Primary Axis ......................................................................................................................... 100
Basic Layout using Core and Taxonomy-Defined Dimensions ................................................... 100
Ordering members along a dimension ......................................................................................... 101
Merged columns .......................................................................................................................... 102
Period Start labels ........................................................................................................................ 102
Column Headings and Promotion ................................................................................................ 103
Row Headings and Promotion ..................................................................................................... 103
Footnotes and Merging ................................................................................................................ 103
Flow Through Suppression on Statements................................................................................... 104
Cash Flow Statements .................................................................................................................. 104
Statements of Changes in Shareholder Equity ............................................................................. 104
Layout Qualifiers ......................................................................................................................... 105
Uncategorized Facts ..................................................................................................................... 106
6.16
6.17
6.18
6.19
6.20
6.21
6.22
6.22.1
6.22.2
Numeric Formatting ..................................................................................................................... 106
Non-numeric Formatting ............................................................................................................. 106
The Filing Summary .................................................................................................................... 107
Multiple Instances ........................................................................................................................ 108
Workbook Output ........................................................................................................................ 108
Resource Extraction Payment Rendering .................................................................................... 108
Rendering of Mutual Fund Risk/Return Summary Interactive Data ........................................... 109
Embedding Commands............................................................................................................ 109
Bar Charts ................................................................................................................................ 109
7
VALIDATION DETAILS ON ALL XBRL ATTACHMENTS ................................... 110
8
VALIDATION DETAILS ON XBRL INSTANCES ..................................................... 114
9
VALIDATION DETAILS ON CUSTOM TAXONOMIES.......................................... 120
7.1
7.2
7.3
7.4
7.5
7.6
7.7
7.8
8.1
8.1.1
8.1.2
8.1.3
8.2
8.3
8.4
8.5
8.6
8.7
8.8
8.9
8.10
9.1
9.2
9.3
9.4
9.5
9.6
9.7
9.7.1
9.7.2
9.7.3
6
File names and character encodings............................................................................................. 110
Standard namespace prefixes ....................................................................................................... 111
Standard locations ........................................................................................................................ 112
Compatible Taxonomies .............................................................................................................. 112
Elements....................................................................................................................................... 113
Element attributes ........................................................................................................................ 113
Element attribute values............................................................................................................... 114
Attribute value lengths ................................................................................................................. 114
XHTML Validations .................................................................................................................... 115
HTML restrictions on Text Block facts ....................................................................................... 115
HTML restrictions on XBRL footnotes ....................................................................................... 116
HTML restrictions on Inline XBRL ............................................................................................ 116
Labels ........................................................................................................................................... 116
Presentation .................................................................................................................................. 116
Footnote Links ............................................................................................................................. 116
Decimals ...................................................................................................................................... 117
Contexts ....................................................................................................................................... 117
Periods ......................................................................................................................................... 118
Units ............................................................................................................................................. 118
Non-US English Facts.................................................................................................................. 119
Duplicate facts ............................................................................................................................. 119
Custom namespace and role URIs ............................................................................................... 120
Roles ............................................................................................................................................ 121
Concepts....................................................................................................................................... 122
Relationships ................................................................................................................................ 123
Concept types and relationships................................................................................................... 125
Concept labels and roles .............................................................................................................. 125
Rendering validations .................................................................................................................. 126
Each axis that is presented requires at least one child element. ................................................... 126
Matching instant and duration facts ............................................................................................. 127
Changes in Equity presentation instant and duration type facts. ................................................. 127
9.7.4
9.7.5
9.7.6
9.7.7
9.7.8
9.8
9.8.1
9.8.2
9.8.3
9.8.4
9.8.5
9.8.6
9.8.7
Text blocks containing embedding commands. ........................................................................... 127
Rows and columns both required. ................................................................................................ 128
Completeness of axes in an embedding command. ..................................................................... 128
Bar Chart selected Annual Return facts ....................................................................................... 129
The {Elements} token implies "column primary" embedding. ................................................... 129
Namespace-specific Customizations............................................................................................ 129
CEF Customization ...................................................................................................................... 130
ECD Customization ..................................................................................................................... 130
FFD Customization ...................................................................................................................... 130
OEF Customization...................................................................................................................... 130
RXP Customization ..................................................................................................................... 131
VIP Customization ....................................................................................................................... 131
SRO Customization ..................................................................................................................... 132
10
INLINE XBRL RESTRICTIONS ................................................................................... 132
11
TABLES FROM FILER MANUAL VOLUME II CHAPTER 6................................. 132
Figure 1. Dimension figures color-coding legend ........................................................................ 43
Figure 2. Example showing nine facts with a single taxonomy-defined dimension ................... 43
Figure 3. Example showing different presentation of the same nine facts .................................. 44
Figure 4. Example showing the nine individual facts .................................................................. 44
Figure 5. Custom presentation and label relationships, no dimensions ........................................ 84
Figure 6. Dimensional relationships example 1............................................................................ 86
Figure 7. Dimensional relationships example 2............................................................................ 86
Figure 8. Presentation example ..................................................................................................... 87
Figure 9. Definition relationships with a custom member ............................................................ 90
Figure 10. Examples of custom domain members ....................................................................... 90
Figure 11. Custom presentation and label relationships with a custom member.......................... 91
Figure 12. Standard calculation relationships example ................................................................ 92
Figure 13. Custom calculation relationships with standard concepts. ......................................... 93
Introduc�on
This EDGAR XBRL Guide provides detailed technical specifications of XBRL formatting and validation
for use in connection with making submissions on EDGAR.
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.
7
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 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
“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.
8
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.
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:
9
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.
2 XBRL Specifica�ons
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.
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:
•
•
•
10
XBRL Data Types Registry (DTR), versions 2020-01-21 and 2022-03-31 – all entries
XBRL Unit Types Registry (UTR), versions 2022-07-20 – all entries
Transformation Registries (TR) versions 2015-02-26, 2020-02-12, and 2022 – all entries
•
XBRL Link Role Registry (LRR) version 2022-09-28 – only those URIs starting
http://www.xbrl.org/lrr/
XII also creates and publishes taxonomies. Currently none of the XII taxonomies are EDGAR standard
taxonomies.
3 Instance Content
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];
•
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 [§ 5.2.5] 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.
11
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.
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.
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
co-registrants 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 [§ 5.2.5.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
Nota�on and Terminology
This guide describes each fragment of expected content in two tables, a Concepts table and a Validations
table.
The Concepts table shows:
12
•
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:
•
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.)
•
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 column.
3.1.2
Required Context valida�on
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
13
#
Type or regex
Meaning
{1}
\d{1,10}
EDGAR CIK
{2}
\d{1,2}-\d{1,2}-\d{4}
Reporting period if present
The filing date of the
submission
{3}
Filing date, which may be
the same or later than the
acceptance date.
\d{1,2}-\d{1,2}-\d{4}
Validations:
Incl
Excl c Check
All contexts have an identifier element value
i:ALL
equal to {1}.
There is a context having endDate value
i:ALL
matching either {2} or {3}, and no segment
element.
f On failure s
Non
Matching
Cik
Required
Context
EFM v68 Ref
§ 6.5.3
E § 6.5.19
Notes and special cases: none.
3.1.3
Central Index Key
Concept
#
Type or regex
Meaning
dei:EntityCentralIndexKey
{1}
\d{10}
EDGAR CIK
Validations:
Incl
Excl
i: ALL
c Assertion
r
i: K.SDR,
L.SDR
r
i: K.SDR,
L.SDR
i: ALL
r
f
A {1} fact is present.
A {1} fact with value a full
ten-digit CIK from among
the co-registrants in the
submission header or equal
to 0000000000.
A {1} fact with value a full
ten-digit 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:
14
Incl
Excl
c Check
i: ALL
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: AF.CA,
AF.FPI,
r
R33.FPI,
R34.FPI
i:ALL
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
{1}
Validations:
15
Type or regex
Meaning
(Up to 20 characters)
Form or Exhibit Type (often differs
from the submission type).
[A-Z0-9]+([/A-Z0-9 \.\]*[A-Z0-9])?|Other
Incl
Excl
c Check
f
i:ALL FE
r
A {1} fact is present.
i:ALL FE
r
The {1} fact value is among the Form
types permitted for the submission type as
shown in EFM § 3.
i:FE
r
A {1} fact is absent.
On failure
1,
2,
3
s
EFM v68 Ref
E
§ 6.5.20 X*
{1} Value
E
§ 6.5.20
{1}
Unexpected
W § 6.5.20 []
{1}
Missing
Notes and special cases:
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, using the value of the underlying
form type (without /A) for dei:DocumentType is always preferred.
3.1.6
Amendment Flag and Descrip�on
Concept
dei:AmendmentFlag
dei:AmendmentDescription
Validations:
16
#
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.
Incl
i: ALL
i: FE.A
Excl
i: FE.A
c
Check
f
On failure
{1}
Missing
r A {1} fact is present.
{1} Unexpected
r A {1} fact is absent.
If a {1} fact with value true is
{1} {2} Value
r present, then a {2} fact is
Dependency
present.
{1} {2} Value
r If a {1} fact with value false is
Dependency
present, then a {2} fact is absent.
i: ALL
i: ALL
i: ALL
i: FE.A,
OA.RXP,
OA.SDR
r
If {2} is present, it is visible.
{2} in Facts
Not Visible
s EFM v68 Ref
W § 6.5.20 R*
W § 6.5.20 []
W § 6.5.20 A
W § 6.5.20 A
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
17
s: 8K
c Check
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
A {1} fact is present.
4,
5
{1}
Missing
{1}
Missing
W § 6.5.20 R
W § 6.5.20 R*
W
§ 6.5.20 R*,
O*
Incl
s: FAST,
AF.OEF,
HF.OEF, 6K,
R33, R34, R40,
6K, RD, R33,
R34, R40,
i: OA.SDR
s: ALL
Excl
c Check
r
f
If the submission header
field periodOfReport is
present, then its date
matches the value of
On failure
s
EFM v68 Ref
{1} Value
W
§ 6.5.40 Case
(2)
{1}
Unexpected
W
§ 6.5.20 [],
O*
{1}.
s: FAST,
AF.OEF,
HF.OEF,
6K, R33,
R34, R40, r
6K, RD,
R33, R34,
R40,
i: OA.SDR
A {1} fact is absent.
5
Notes and special cases:
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 filing date.
5. Check is waived when the submission type matches POS*
3.1.8
Document Fiscal Year and Period Focus
Concept
#
dei:DocumentFiscalPeriodFocus
{2}
dei:DocumentFiscalYearFocus
{1}
Type or regex
xs:gYear (matches YYYY)
Q1|Q2|Q3|FY
Meaning
Filer’s fiscal year.
Fiscal period of the report.
Validations:
Incl
s: AF
Excl
i: AF.OEF
s: ALL
c Check
r A {1} fact is present.
On failure
{1} Missing
r
{1} {2} Mutual
Neither or both {1} and
1 Dependency
{2} are present.
s: ALL
s: FAST, R33,
R34
r
A {1} fact is absent.
s: AF
i: AF.OEF
r
A {2} fact is
present.
s: ALL
s: FAST, R33,
R34
r
A {2} fact is absent.
Notes and special cases:
1. Waived for submission types matching POS.*.
18
f
1 {1} Unexpected
{2} Missing
1 {2} Unexpected
s
EFM v68 Ref
W § 6.5.20 R*
W § 6.5.20 Op*
W
§ 6.5.20 [],
Op*
W § 6.5.20 R*
W
§ 6.5.20 [],
Op*
3.1.9
Current Repor�ng Status and Interac�ve 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
#
dei:EntityCurrentReportingStatus
dei:EntityInteractiveDataCurrent
{1}
{2}
Type or regex Meaning
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.
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
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:
19
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
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
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 []
r
A {2} fact is present.
{2} Missing
W § 6.5.21 R
r
If {2} facts are present, then at
least one is visible.
{2} in Facts
Not Visible
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
Not Visible
W § 6.5.45 R
shellCompanyFlag has a value,
then it is equivalent to the {3} fact
{3} Value
W
A {3} fact is absent.
{3}
Unexpected
W § 6.5.21 []
r
r
r
i: AF.US,
AF.BDC, r
AF.FPI
i: AF.US,
AF.BDC, r
AF.FPI
Not Visible
If header element
r
value.
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.
Notes and special cases: none.
20
f On failure
{1} {2}
Exclusive
Value
{2} {3}
Exclusive
Value
§ 6.5.40
Item 3
§ 6.5.40
Item 4
§ 6.5.40
Item 5
W § 6.5.21 WV
W § 6.5.21 WS
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
Type or regex Meaning
Indicates that the company is a Smaller Reporting
{1} xs:boolean
Company (SRC).
Validations:
Incl
i: AF.US,
AF.BDC,
AF.OEF,
QF.US,
R33.US,
R34.US
Excl
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
s: ALL
21
c Check
f
On failure
s
EFM v68 Ref
r
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
r
r
i: AF.US,
AF.BDC,
AF.OEF,
QF.US,
R33.US,
R34.US
A {1} fact is present.
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.
1
r
If {1} facts are present, then
at least one is visible.
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*
1
{2}
Submission
Value
W
§ 6.5.40
Item 6
If there is a value for
r
emergingGrowthCompanyFlag in the header for the
filer with the CIK of the
required context, then a {2}
fact is present with that
value.
Incl
Excl
s: FAST
s: ALL
s: FAST,
R34,
i: R33.US,
R33.FPI,
s: FAST,
i: R33.US,
R33.FPI,
R34
s: FAST,
i: R33.US,
R33.FPI,
R34
s: FAST
s: ALL
s: FAST,
R34,
i: R33.US,
R33.FPI
c Check
If {2} facts are present, then
r
at least one is visible.
f
r
1
A {2} fact is absent.
s
{1} in
Facts Not
Visible
EFM v68 Ref
W § 6.5.40 R
{2}
Unexpected
W § 6.5.40 []
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}
§ 6.5.40 ET,
1, {2}
Value
W
ET*
2 Dependency
r
If {3} facts are present, then
at least one is visible.
r
A {3} fact is absent.
§ 6.5.40 ET
§ 6.5.40 ET,
§ 6.5.45
{3}
Unexpected
W
1
{3}
Unexpected
W § 6.5.40 []
1
{3}
Submission
Value
W
If there is a value for
exTransitionPeriodFlag
s: ALL
On failure
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
22
Excl
c Check
f
i: AF.OEF,
AF.CEF
r
A {1} fact is present.
1
i: AF.OEF,
AF.CEF
r
If {1} facts are present, then
at least one is visible.
On failure
s
{1}
W § 6.5.21 R, R*
Missing
{1} in
Facts Not
Visible
W
EFM v68 Ref
§ 6.5.21 R
§ 6.5.45
Incl
Excl
s: 8K, AF,
QF, 6K,
i: K.SDR,
L.SDR
s: ALL
s: AF, QF,
6K,
i: R34.FPI,
R34.CA,
K.SDR,
L.SDR
c Check
If {1} is present, and there is
a value for fiscalYearEnd
in the header for the filer
r
with the CIK of the required
context, then the {1} fact is
present with that value.
r
s: 8K
r
s: 8K
r
f
On failure
EFM v68 Ref
{1}
2, Submission
§ 6.5.21 [], O*,
W
3 Value
§ 6.5.40 Item 1
{1}
A {1} fact is absent.
If Item 5.03 is indicated in
the header, then {1} is
present.
If Item 5.03 is not indicated
in the header, then {1} is
absent.
s
Unexpected
W § 6.5.21 [], O*
{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, 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
23
Excl
c Check
f
On failure
s
EFM v68 Ref
r
A {1} fact is present.
1
{1}
Missing
W
§ 6.5.21 R,
R*
r
If {1} facts are present, then at least
one is visible.
{1} in
Facts Not
Visible
W
§ 6.5.21 R
§ 6.5.45
Incl
s: ALL
Excl
i: AF.US,
AF.BDC,
QF.US,
AF.FPI,
R33.US,
R34.US
c Check
r
i: AF.US,
AF.BDC,
QF.US,
AF.FPI,
R33.US,
R34.US
r
i: AF.US,
AF.BDC,
QF.US,
AF.FPI,
R33.US,
R34.US
r
i: AF.US,
AF.BDC,
QF.US,
AF.FPI,
R33.US,
R34.US
r
i: AF.US,
AF.BDC,
QF.US,
AF.FPI,
R33.US,
R34.US
r
An {1} fact is absent.
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.
If the value of acceleratedFilerStatus in the header for the
filer with the CIK of the required
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
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.
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
{1}
Unexpected
W § 6.5.21 []
{1}
§ 6.5.40 Item
1 Submission W
10
Value
{1}
§ 6.5.40 Item
1 Submission W
11
Value
{1}
§ 6.5.40 Item
1 Submission W
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 Atesta�on 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
24
Meaning
Note that the
possible values
have spaces and
a dash.
dei:IcfrAuditorAttestationFlag
{2}
xs:boolean
Validations:
Incl
i: AF.US,
AF.BDC,
AF.FPI
r
i: AF.US,
AF.BDC,
AF.FPI,
AF.CA
Check
If the value of {1} is “Large
Accelerated Filer” or
“Accelerated Filer”, then a
{2} fact is present.
r
If {2} facts are present in the
required context, then at least
one is visible.
s: ALL
Excl
c
i: AF.US,
AF.BDC,
AF.FPI,
AF.CA
a A {2} fact is absent.
f On failure
s
EFM v68 Ref
{2}
Missing
W § 6.5.21 Ra
{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
{1}
Unexpected
W § 6.5.21 []
se A {1} fact is absent.
§ 6.5.21 R
§ 6.5.45
Notes and special cases: none.
3.1.16 Auditor Name, Loca�on, and Firm ID
Three facts must appear together for annual financial statements for periods ending after 12/31/2020.
Concept
#
dei:AuditorName
{1}
25
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.
zeroes.
Validations:
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
in the required context,
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
in the required context,
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
in the required context,
then at least one is
visible.
2
{3} in Facts
Not Visible
W
§ 6.5.21 H
§ 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
26
Incl
Excl
i: AF.US,
AF.BDC,
AF.FPI,
AF.CA
s: ALL
c Check
r
A {3} fact is absent.
If any of {1}, {2}, or
a {3}, are present, then all
three are present.
s: ALL
f
On failure
s
EFM v68 Ref
1
{3}
Unexpected
E
§ 6.5.21 []
{2} {3}
1, {1}
Mutual
3 Dependency
E
§ 6.5.54
Notes and special cases:
1.
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.
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
s: RD
Excl
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.
Notes and special cases:
1. Checks waived for submission types matching POS.*.
27
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
3.1.18 File Number (Securi�es 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,
i: R34.FPI, R34.CA
c Assertion
r 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: none.
3.1.19 Incorpora�on 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 (EFM §
5.2.5.12) transforms the full names of countries and
Canadian provinces to their EDGAR codes.
Validations:
Incl
s: FAST
Excl
s: FAST
s: ALL
s: FAST,
R33, R34
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 Iden�fica�on Number
Concept
dei:EntityTaxIdentificationNumber
#
Type or regex Meaning
Shown on forms as “IRS Employer
{1} \d{2}-\d{7}
ID”.
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: ALL
s: FAST, R34,
i: AF.CA
Notes and special cases: none.
28
s
EFM v68 Ref
§ 6.5.47 Ri,
W
O
§ 6.5.47 Ri,
W
O
§ 6.5.47 [],
W
O*
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
c Assertion
If {1} are present, then
r
at least one is visible.
r
A {1} fact is absent.
f On failure
{1} in Facts
Not Visible
{1} Unexpected
s
EFM v68 Ref
W § 6.5.47 O
W
§ 6.5.47 [],
O*
Notes and special cases: none
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
s: FAST
s: ALL
s: FAST
r
A {1} fact is absent.
r
A {2} fact is present.
If {2} facts are present in
the required context, then
at least one is visible.
r
s: FAST, 6K, R34,
R33
s: FAST
s: ALL
c Check
r A {1} fact is present.
If {1} facts are present in
r the required context, then
at least one is visible.
r
A {2} fact is absent.
r
A {3} fact is present.
If {3} facts are present in
the required context, then
at least one is visible.
r
s: FAST, 6K, R34,
R33
r
f On failure
A {3} fact is absent.
{1} Missing
{1} in
Facts Not
Visible
29
#
{1}
Type or regex
xs:normalizedString
§ 6.5.48 [],
O*
W § 6.5.48 Ri
W
{2} in
Facts Not
Visible
W § 6.5.48 Ri
{2} Missing
§ 6.5.48 [],
O*
W § 6.5.48 Ri
{2}
Unexpected
W
{3} in
Facts Not
Visible
W § 6.5.48 Ri
{3} Missing
{3}
Unexpected
3.1.22.2 Street Address Lines 2 and 3
dei:EntityAddressAddressLine1
W § 6.5.48 Ri
{1}
Unexpected
Notes and special cases: none.
Concept
s
EFM v68 Ref
W § 6.5.48 Ri
Meaning
W
§ 6.5.48 [],
O*
Concept
#
dei:EntityAddressAddressLine2
dei:EntityAddressAddressLine3
{2}
{3}
Type or regex
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:
c Check
f
s: ALL
If a {2} fact is
a present, then a {1}
fact is also present.
1 Dependency
s: FAST,
i: RD.CEF
r
If {2} facts are
present, then at least
one is visible.
{2} in
Facts Not
Visible
r
A {2} fact is absent.
{2}
Unexpected
W § 6.5.48 []
s: ALL
If a {3} fact is
a present, then a {2}
fact is also present.
{2} {3}
Dependency
s: FAST,
i: RD.CEF
r
If {3} facts are
present, then at least
one is visible.
{3} in
Facts Not
Visible
§ 6.5.48
OL2, OL2*
§ 6.5.51
OL2, OL2*
W § 6.5.48 OL2
r
A {3} fact is absent.
{3}
Unexpected
W
Incl
s: ALL
s: ALL
Excl
s: FAST, 6K, R34,
i: RD.CEF, R33.US,
R33.FPI
s: FAST, 6K, R34,
i: RD.CEF, R33.US,
R33.FPI
On failure
{1} {2}
s
EFM v68 Ref
§ 6.5.48
OL1*
W
§ 6.5.51
OL1*
W § 6.5.48 O
§ 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 EFM § 5.2.5.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 EFM § 5.2.5.12.
Validations:
Incl
Excl
s: FAST,
i: RD.CEF
i: AF.FPI
s: FAST,
i: RD.CEF
30
c Check
One or both {1}
r and {2} facts are
present.
If {1} facts are
r present, then at
least one is visible.
f
Codes
s
{1} {2}
W § 6.5.48 O2
1 Inclusive
{1} in Facts
Not Visible
W
EFM v68 Ref
§ 6.5.48 O,
O2
Incl
Excl
i: AF.FPI
s: FAST,
i: RD.CEF
s: ALL
s: ALL
s: FAST, R34,
R33, i: RD.CEF
s: FAST, 6K, R34,
i: R33.US,
R33.FPI
c Check
A {2} fact is
r
present.
If {2} facts are
r present, then at
least one is visible.
f
Codes
s
EFM v68 Ref
{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*
EFM v68 Ref
Notes and special cases: none.
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
31
Excl
s: 8K, QF, i: AF.US,
AF.BDC, RD.CEF,
AF.CA, R34.US,
R34.CA, R33.US,
R33.FPI
c Check
f
On failure
s
Neither or
both of a {1}
a
fact and a {2}
fact is present.
1,
2
{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
r
If {1} facts
are present,
then at least
one is visible.
{1} in
Facts Not
Visible
W § 6.5.48 Ri
r
A {1} fact is
absent.
{1}
Unexpected
W
r
A {2} fact is
present.
{2} Missing
W § 6.5.48 Ri
r
If {2} facts
are present,
then at least
one is visible.
{2} in
Facts Not
Visible
W § 6.5.48 Ri
§ 6.5.48 [],
Oph*
Types
s: ALL
Excl
s: 8K, QF, i: AF.US,
AF.BDC, RD.CEF,
AF.CA, R34.US,
R34.CA, R33.US,
R33.FPI
c Check
r
f
A {2} fact is
absent.
On failure
s
EFM v68 Ref
{2}
Unexpected
W
§ 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.
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
i: AF.FPI
r
i: AF.FPI
r
i: AF.FPI
r
i: AF.FPI
r
32
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.
f On failure
s
EFM v68 Ref
§ 6.5.49 N,
N*
Incl
Excl
i: AF.FPI
i: AF.FPI
i: AF.US,
AF.BDC,
AF.CA
s: QF,
i: AF.US,
AF.BDC,
AF.CA
c Check
If a {3} fact valued
true is present, then
r
a {1} fact valued
false is present.
If a {3} fact valued
true is present, then
r
a {2} fact valued
false is present.
If {1} facts are
r present, then at least
one is visible.
r
i: AF.FPI
r
R34.CA
r
s: ALL
s: ALL
s: QF, i: AF.US,
AF.BDC,
AF.CA, AF.FPI,
R34.CA
s: QF, i: AF.US,
AF.BDC,
AF.CA, AF.FPI
{3} {2}
Value
Dependency
W § 6.5.49 TF3
{1} in Facts
Not Visible
W
§ 6.5.49 Y, N,
TF3
{2} in Facts
Not Visible
W
§ 6.5.49 Y, N,
TF3
{3} in Facts
Not Visible
W § 6.5.49 TF3
{2} Value
Unexpected
W § 6.5.49 N*
r
A {2} fact is absent
{2}
Unexpected
W § 6.5.49 []
{4} Value
Dependency
§ 6.5.49 SR
{4} Value
Dependency
§ 6.5.49 SR
i: AF.FPI
r
s: ALL
i: AF.FPI
r
s: QF
s: TF
r
s: TF
s: AF, EBP
r
33
W § 6.5.49 TF3
W § 6.5.49 []
r
r
Notes and special cases: none.
{3} {2}
Value
Dependency
{1}
Unexpected
i: AF.FPI
s: QF
EFM v68 Ref
A {1} fact is absent.
r
s: ALL
If {3} facts are
present, then at least
one is visible.
A {1} fact valued
false is present.
s
r
i: AF.FPI
s: QF
If {2} facts are
present, then at least
one is visible.
f On failure
r
If {3} valued true is
present, then {4} is
present.
If {3} valued false
is 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.
{4} in Facts
Not Visible
{4}
Unexpected
{5} Value
Missing
W § 6.5.49 SR
W § 6.5.49 []
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 []
3.1.23.2 Financial Statement Error Correction, Recovery Analysis
Concept
dei:DocumentFinStmtErrorCorrectionFlag
dei:DocumentFinStmtRestatementRecoveryAnalysisFlag
#
{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
Excl
AF.US,
AF.BDC,
AF.FPI, AF.CA
AF.US,
AF.BDC,
AF.FPI, AF.CA
AF.US,
s: ALL
AF.BDC,
AF.FPI, AF.CA
AF.US,
AF.BDC,
AF.FPI, AF.CA
AF.US,
AF.BDC,
AF.FPI, AF.CA
AF.US,
AF.BDC,
AF.FPI, AF.CA
AF.US,
s: ALL
AF.BDC,
AF.FPI, AF.CA
c Check
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
a true is present,
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 applying only to non-US filers.
Concept
#
Type or regex
{2}
xs:boolean
DocumentAccountingStandard
{3}
U.S. GAAP|International
Financial Reporting
Standards|Other
OtherReportingStandardItemNumber
{4}
Item (17|18)
DocumentRegistrationStatement
{5}
xs:boolean
AnnualInformationForm
AuditedAnnualFinancialStatements
34
{1}
xs:boolean
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
c Check
r A {1} fact is present.
If {1} facts are present, then at
r
least one is visible.
r
A {1} fact is absent.
s: AF.CA
r
s: AF.CA
r
A {2} fact is present.
If {2} facts are present, then at
least one is visible.
s: ALL
s: ALL
s: AF.CA
s: AF.CA
r
i: AF.FPI
A {3} fact is present.
If {3} facts are present, then at
least one is visible.
i: AF.FPI
s: ALL
A {2} fact is absent.
i: AF.FPI,
R34.FPI
A {3} fact is absent.
i: AF.FPI,
R34.FP
If a {3} fact valued Other is
present, then {4} is present.
i: AF.FPI,
R34.FP
If a {3} fact valued Other is
absent, then {4} is absent.
i: AF.FPI
If {4} facts are present, then at
least one is visible.
s: ALL
i: AF.FPI,
AF.CA
i: AF.FPI,
AF.CA
i: R34.CA,
R34.FPI
s: ALL
i: AF.FPI,
R34.FPI
i: AF.FPI,
AF.CA.
R34.FPI,
R34.CA
A {4} fact is absent.
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.
A {5} fact is absent.
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
{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
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
W § 6.5.49 []
W § 6.5.50 Ri
§ 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
DocumentTransitionReport
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.
35
Validations:
Incl
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.
i: AF.FPI
s: TF
s: TF,
i: AF.FPI
s: ALL
s: TF,
r
i: AF.FPI
f On failure
{1} {2}
Value
Dependency
{2} Missing
{1} in Facts
Not Visible
{2}
Unexpected
A {2} fact is absent.
s
EFM v68 Ref
W § 6.5.49 TR
W § 6.5.49 Ri
§ 6.5.49 Ri,
W
TR
W § 6.5.49 []
Notes and special cases: none.
3.1.23.5 Bankruptcy Proceedings Flag
Concept
EntityBankruptcyProceedingsCurrent
#
{1}
Type or regex Meaning
xs:boolean
Validations:
Incl
s: QF,
i: AF.US,
AF.BDC,
AF.FPI
s: ALL
Excl
s: QF, i: AF.US,
AF.BDC, AF.FPI,
R33.FPI
c Check
If {1} facts are
present, then at
r
least one is
visible.
r
f On failure
A {1} fact is
absent.
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
DocumentsIncorporatedByReferenceTextBlock
#
{1}
Type or regex
Meaning
Text block (see 8.1.1 below)
Validations:
Incl
Excl
c Check
i: AF.US,
If {1} facts are present, then at
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
WrittenCommunications
{1}
xs:boolean
{3}
xs:boolean
SolicitingMaterial
PreCommencementTenderOffer
36
{2}
xs:boolean
Meaning
Concept
#
Type or regex
PreCommencementIssuerTenderOffer
{4}
xs:boolean
{5}
(e.g., “OLDCO Inc.”)
EntityInformationFormerLegalOrRegisteredName
Meaning
xs:normalizedString
Validations:
Incl
s: 8K
Excl
s: 8K
s: ALL
s: 8K
s: 8K
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
s: 8K,
QF
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.
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
{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
{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 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 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.24 Closed-end fund registra�on
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
dei:EntityFileNumber
dei:InvestmentCompanyActFileNumber
cef:BdcFileNumber
37
#
{1}
{2}
{3}
{4}
{5}
{6}
Type or regex
xs:boolean
xs:boolean
\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.
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.
Concept
Submission type from EDGAR header
dei:DocumentRegistrationStatement
dei:PreEffectiveAmendment
dei:PreEffectiveAmendmentNumber
dei:PostEffectiveAmendment
38
#
{1}
{2}
{3}
{4}
{5}
Type or regex
xs:boolean
xs:boolean
xs:positiveInteger
xs:boolean
Meaning
Concept
#
dei:PostEffectiveAmendmentNumber
dei:InvestmentCompanyActRegistration
dei:InvestmentCompanyRegistrationAmendment
dei:InvestmentCompanyRegistrationAmendmentNumber
{6}
{7}
{8}
{9}
Type or regex
xs: positiveInteger
xs:boolean
xs:boolean
xs:positiveInteger
Meaning
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
i: RD.CEF
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.
If {9} facts are present, then at
r
least one is visible.
Notes and special cases:
39
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
{8} {7} Value
Dependency
E
§ 6.5.55, n2h
{3} {4} Value
Dependency
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
{9} in Facts Not
E
§ 6.5.55 n2i
{5} {2} Value
Dependency
{5} {6} Value
Dependency
{8} {9} Value
Dependency
1 Visible
1 Visible
1 Visible
1 Visible
1 Visible
1 Visible
1 Visible
1 Visible
EFM v68 Ref
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.
3.1.24.5 N-2 Effectiveness Dates
Concept
dei:EffectiveWhenDeclaredSection8c
dei:EffectiveUponFiling486b
40
#
{1}
{2}
Type or regex Meaning
xs:boolean
xs:boolean
EFM v68 Ref
Concept
dei:EffectiveOnSetDate486b
dei:EffectiveOnDate486b
dei:EffectiveAfter60Days486a
dei:EffectiveOnSetDate486a
dei:EffectiveOnDate486a
#
Type or regex Meaning
{3}
{4}
{5}
{6}
{7}
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
Validations:
41
#
{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
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
i: RD.CEF
i: RD.CEF
i: RD.CEF
i: RD.CEF
42
Excl c Check
If {1} facts valued true are
r
present, then at least one is visible.
At most one of {1} and {2} has the
r
value true.
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.
f
On failure
{1} in Facts Not
1
Visible
s
1 Exclusive Values
{2} in Facts Not
1
Visible
{3} 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
E § 6.5.55 B
Incl
i: RD.CEF
i: RD.CEF
i: RD.CEF
i: RD.CEF
i: RD.CEF
Excl c Check
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
{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
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
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.
43
Figure 3. Example showing 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.
A third case is the appearance of non-numeric facts, each with a different member of the axis, but no
default:
44
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
45
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
bc
A {2} fact is
absent.
bc
i: AF.FPI,
RD.CEF
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
i: AF.FPI,
RD.CEF,
AF.CA
s: ALL
i: AF.FPI,
RD.CEF,
AF.CA
i: AF.FPI,
RD.CEF,
AF.CA
s: ALL
46
Excl
i: AF.FPI,
RD.CEF, AF.CA,
R34.FPI, R34.CA
R33.FPI R33.US
i: AF.FPI,
RD.CEF, AF.CA,
R34.FPI, R34.CA
R33.FPI R33.US
c
Check
bc
A {1} fact is
present.
{1} Missing
W § 6.5.51 Ri
If {1} facts are
bc present, then at
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
bc present, then at
least one is visible.
{2} in Facts
Not Visible
W § 6.5.51 Ri
A {2} fact is
absent.
{2}
Unexpected
W § 6.5.51 []
bc
f On failure
s
EFM v68 Ref
§ 6.5.51 [],
O*
Incl
i: AF.FPI,
RD.CEF,
AF.CA
Excl
c Check
bc A {3} fact is
present.
i: AF.FPI,
RD.CEF,
AF.CA
i: AF.FPI,
RD.CEF, AF.CA,
R34.FPI, R34.CA
R33.FPI R33.US
s: ALL
bc If {3} facts are
present in the
required context,
then at least one is
visible.
bc A {3} fact is
absent.
f On failure
{3} Missing
s
EFM v68 Ref
W § 6.5.51 Ri
{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 EFM § 5.2.5.12.
XBRL transformations that country names to ISO
3166-1 alpha 2 (IANA) codes (e.g., US, JP) are
shown in EFM 5.2.5.12.
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
s: ALL
i: AF.FPI,
RD.CEF, AF.CA, bc A {1} fact is absent.
R34.CA, R33.US
If {2} facts are
bc present, then at
least one is visible.
i: R33.FPI,
bc A {2} fact is absent.
R34.FPI
Notes and special cases: none.
47
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*
{1}
Unexpected
W
{2} in Facts
Not Visible
W § 6.5.51 O2
{2}
Unexpected
W § 6.5.51 []
§ 6.5.51 O2,
Ru
§ 6.5.51 [],
O*
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
i: AF.CA, AF.FPI,
RD.CEF, R34.FPI,
R34.CA, R33.FPI,
R33.US
s: ALL
c
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
Former Street, City and Zip
Concept
dei:EntityAddressAddressLine1
dei:EntityAddressAddressLine2
dei:EntityAddressAddressLine3
dei:EntityAddressCityOrTown
dei:EntityAddressPostalZipCode
#
{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:
48
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.
f On failure
{1} in Facts Not
Visible
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} in Facts Not
Visible
W § 6.5.53 F2
{5} Unexpected
W § 6.5.53 []
One or both {4} and {5}
facts are present
If {4} facts are present, then
fa
at least one is visible.
fa
s: 8K,
QF
s: ALL
s: 8K,
QF
fa A {4} fact is absent.
If {5} facts are present, then
at least one is visible.
fa
s: 8K,
QF
s: ALL
W § 6.5.53 O
{1} Unexpected
fa
s: ALL
EFM v68 Ref
fa A {1} fact is absent.
fa
s: ALL
s
fa A {5} fact is absent.
§ 6.5.53 [],
OL2
Notes and special cases: none.
3.2.2.2
Former State or Province and Country
Concept
#
Type or regex
{1}
xs:normalizedString
dei:EntityAddressStateOrProvince
{2}
Postal state or province
dei:EntityAddressCountry
{3}
dei:EntityAddressAddressLine1
Valid IANA country
code
Meaning
XBRL transformations that convert state and
province names to postal codes (e.g., TX, ON)
are shown in EFM § 5.2.5.12.
XBRL transformations that country names to
ISO 3166-1 alpha 2 (IANA) codes (e.g., US,
JP) are shown in EFM 5.2.5.12.
Validations:
Incl
s: 8K,
QF
s: 8K,
QF
49
Excl
c
Check
If a {1} is present, then one or both
fa
of {2} and {3} facts are present.
fa
If a {2} fact is absent, then {1} is
absent.
f On failure
{1} {2} {3}
Inclusive
Dependency
{2} {1}
Inclusive
Dependency
s
EFM v68 Ref
W § 6.5.53 F2
W § 6.5.53 F2
Incl
s: 8K,
QF
Excl
s: 8K,
QF
c
Check
If a {3} fact is absent, then {1} is
fa
absent.
fa
s: 8K,
QF
s: ALL
s: 8K,
QF
s: 8K,
QF
If {2} facts are present, then at least
one is visible.
fa A {2} fact is absent.
fa
s: ALL
f On failure
If {3} facts are present, then at least
one is visible.
fa A {3} fact is absent.
{3} {1}
Inclusive
Dependency
{2} in
Facts Not
Visible
{2}
Unexpected
{3} in
Facts Not
Visible
{3}
Unexpected
s
EFM v68 Ref
W § 6.5.53 F2
W § 6.5.53 F2
W § 6.5.53 []
W § 6.5.53 F2
W § 6.5.53 []
Notes and special cases: none.
3.2.3
Common Stock Shares Outstanding
Common stock shares, like public float, appears in a context that is an instant period, not a duration.
Concept
dei:EntityCommonStockSharesOutstanding
#
{1}
Type or regex Meaning
decimal
Depending on whether the entity represented in the required context has zero, one, or more than one, class
of common shares or ownership units outstanding, the instance will have exactly one of the following
permitted sets of facts:
Case
Axis in any
standard namespace
Members in
distinct contexts
1
No dimensions
N/A
2
StatementClassOfStockAxis
At least two
3
ClassesOfShareCapitalAxis
At least two
Period
An instant on or after the end of the
required context
An instant on or after the end of the
required context
An instant on or after the end of the
required context
The cases are mutually exclusive. Cases 2 and 3 require that the instance be accompanied by a custom
taxonomy as covered below in section 4. The validations apply to a subsequent event (se) context as
defined above in 3.1.15, “Public Float”.
Validations:
Incl
Excl
s: FAST i: AF.CA
s: FAST
s: ALL
s: FAST,
i: R33.FPI
c
Check
A {1} fact is present in each
se context of exactly one of the
cases 1, 2 or 3.
If {1} facts are present in a
se context, at least one is
visible.
A {1} fact is not present in
se
any context.
f
On failure
s
EFM v68 Ref
{1} Missing
W § 6.5.26
{1} in Facts
Not Visible
W § 6.5.45
{1} Unexpected
W § 6.5.26
Notes and special cases:
1. A filer having no common stock will have 0 common stock shares outstanding under case 1, not nil.
50
3.2.4
Registered Securi�es
Depending on whether the entity represented in the required context has zero, one, or more than one type
or class of registered securities (not limited to common shares as in the previous section), an instance may
have one of the following mutually exclusive cases of permitted sets of facts about those securities:
Case
1
2
3
Axis in any standard namespace
No dimensions (the required context)
StatementClassOfStockAxis
ClassesOfShareCapitalAxis
Distinct members in contexts
N/A (there is only one class)
At least two
At least two
Period
Required context
Required context
Required context
Notes:
1. No instance type requires either dei:Security12bTitle or dei:Security12gTitle. The Checks
concern only whether they are consistent with each other and other facts if they are present.
2. Members on StatementClassOfStockAxis and ClassesOfShareCapitalAxis are expected only
when there is need to distinguish different securities. An American Depositary Receipt (ADR) is an
exception: it may be the only registered security, yet still requires a dimension to indicate this.
3. The presence of members on axes other than StatementClassOfStockAxis or ClassesOfShareCapitalAxis does not change which of the three cases is being represented in an instance.
3.2.4.1
Security Title
The presence of facts for either of two concepts determines which of the three cases apply:
Concept
dei:Security12bTitle
dei:Security12gTitle
#
{1}
{2}
Type or regex
xs:normalizedString up to 150 characters
xs:normalizedString up to 150 characters
Meaning
Validations:
Incl
Excl
s: FAST,
R34
s: FAST,
R34
s: FAST,
R34
s: FAST
s: FAST
s: ALL
s: ALL
s: FAST,
R34
s: FAST,
R34
c Check
A {1} fact value is present
r in at most one of the cases
1-3.
A {2} fact value is present
r in at most one of the cases
1-3.
At most one {1} or {2}
a
fact is present.
If {1} facts are present in a
r context, at least one is
visible.
If {2} fact values are
r present in a context, at
least one is visible.
A {1} fact is absent from
r
all contexts.
A {2} fact is absent from
r
all contexts.
Notes and special cases: none.
51
f On failure
s
EFM v68 Ref
{1} Security
Axes
W
§ 6.5.46 Ot1,
Ot1*
{2} Security
Axes
W
§ 6.5.46 Ot1,
Ot1*
{1} {2}
Exclusive
W
§ 6.5.46 Ot1,
Ot1*
{1} in Facts
Not Visible
W
§ 6.5.45
§ 6.5.46 Ot1
{2} in Facts
Not Visible
W
§ 6.5.45
§ 6.5.46 Ot1
{1} Unexpected
W § 6.5.46 []
{2} Unexpected
W § 6.5.46 []
3.2.4.2
Exchanges Axis
A security may be traded on more than one exchange. Much like the exclusivity of cases 1, 2, and 3,
EntityListingsExchangeAxis permits only one listing for the security and the listings axis does not
appear, or there are multiple listings, and more than one member of the axis appears.
Concept
dei:Security12bTitle
dei:Security12gTitle
#
{1}
{2}
Type or regex
xs:normalizedString up to 150 characters
xs:normalizedString up to 150 characters
Meaning
.
Sub Case Axes in a standard namespace
Members in distinct contexts Period
a
No axes
N/A
Required context
EntityListingsExchangeAxis At least two
b
Required context
Validations:
Incl
s: FAST,
R34
Excl c Check
If a {1} fact is present in a context with
no member of EntityListingExchanger Axis, then there are no {1} facts in
contexts the same except for also having a
member of EntityListingExchange-
f On failure
s
EFM v68 Ref
{1}
Security
Axes
W § 6.5.46
If a {1} fact is present in a context with a
member of EntityListingExchangeAxis, then there are no {1} facts in
contexts the same except without a
member of EntityListingExchange-
{1}
Security
Axes
W § 6.5.46
If a {2} fact is present in a context with
no member of EntityListingExchangeAxis, then there are no {2} facts in
contexts the same except for also having a
member of EntityListingExchange-
{2}
Security
Axes
W § 6.5.46
If a {2} fact is present in a context with a
member of EntityListingExchangeAxis, then there are no {2} facts in
contexts the same except without a
member of EntityListingExchange-
{2}
Security
Axes
W § 6.5.46
Axis.
s: FAST,
R34
r
Axis.
s: FAST,
R34
r
Axis.
s: FAST,
R34
r
Axis.
Notes and special cases: none.
3.2.4.3
Security Exchange Name
One security of a company could be traded on no national exchanges, another security on one national
exchange, and a third on several exchanges. Regardless, the presence of a dei:Security12bTitle fact
is paired with the name of the Exchange in the same context, and only that same context.
52
Concept
dei:Security12bTitle
dei:SecurityExchangeName
#
Type or regex
{1}
Meaning
xs:normalizedString up to 150 characters
NYSE|NASDAQ|CHX|BOX|BX|MIAX|MRX|NYSEAMER|
NYSEArca|NYSENAT|PEARL|Phlx|AF
{3}
National Exchanges.
Other than National
Exchanges are not
tagged.
Validations:
Incl
Excl
s: FAST,
R34
s: FAST,
R34
s: FAST
s: FAST
s: FAST,
R34,
i: AF.CEF
All
c Check
If a {1} fact is present in a case
a 1 context, then a {3} fact value
is present in the same context.
If a {1} fact is present in a case
2 or 3 context and
dei:AdrMember is not a
a
member of either axis, then a
{3} fact value is present in the
same context.
If {3} facts are present in a
a case 1 context, then they are
visible.
If {3} facts are present in a
a case 2 or 3 context, then they
are visible.
a
A {3} fact is absent from a
context.
f
On failure
s
1,
2
{1} {3}
Dependency
W § 6.5.46 Te
1,
2,
3
{1} (3}
Dependency
W § 6.5.46 Te
{3} in
Facts Not
Visible
W § 6.5.46 Te
{3} in
Facts Not
Visible
W § 6.5.46 Te
{3}
Unexpected
W § 6.5.46 []
2
EFM v68 Ref
Notes and special cases:
1. An exchange name is relevant only to 12b securities; 12g securities are not traded on national
exchanges.
2. The values of dei:SecurityExchangeName are EDGAR-defined acronyms. Inline XBRL
transformation ixt-sec:exchnameen described in EFM section 5.2.5.12 transforms commonly
displayed textual names of exchanges to these values.
3. The exchange name is neither expected nor unexpected for an ADR member on the StatementClassOfStockAxis or ClassesOfShareCapitalAxis.
3.2.4.4
Trading Symbol / No Trading Symbol
Whether a security has a trading symbol is represented in two mutually exclusive concepts:
Concept
dei:NoTradingSymbolFlag
dei:TradingSymbol
#
{1}
{2}
Type or regex
Fixed value true
Meaning
xs:normalizedString up to 25 characters.
Validations:
Incl
s: FAST, R34,
i: AF.CEF
53
Excl
c Check
At most one {1}
a or {2} fact
exists.
f
On failure
{1} {2}
1 Exclusive
s
EFM v68 Ref
§ 6.5.46 T1,
W T1*
§ 6.5.57
Incl
Excl
s: FAST, R34,
RD, i: AF.CEF
s: FAST, R34,
RD, i: AF.CEF
s: ALL
s: ALL
c Check
A {1} fact is
r
absent.
A {2} fact is
r
absent.
f
2
On failure
{1}
Unexpected
{2}
2 Unexpected
s
EFM v68 Ref
W § 6.5.46 [], O*
W § 6.5.46 [], O*
Notes and special cases:
1. Concepts dei:NoTradingSymbol and dei:TradingSymbol may be present in AF.CEF instances but
only in class contexts.
2. Concept dei:TradingSymbol is neither expected nor unexpected in RD submissions.
3.2.4.5
Security Reporting Obligation
Concept
dei:SecurityReportingObligation
#
{1}
Type or regex
Meaning
Fixed value 15(d)
Validations:
Incl
Excl
c Check
If {1} facts are present, at least
i: AF.FPI,
r
AF.CA
one is visible.
i: AF.FPI,
AF.CA,
s: ALL
r A {1} fact is absent.
R34.FPI,
R34.CA
f On failure
{1} in Facts
Not Visible
{1}
Unexpected
s
EFM v68 Ref
W § 6.5.45 O
W
§ 6.5.46 [],
O*
Notes and special cases: none.
3.2.5
Open-end Fund Series
Open-end Funds (N-1A funds) and Separate Accounts Registered as Open End Funds (N-3 registrants)
contain facts for distinct series. The set of series identifiers in the scope of a submission is determined by
the content of the EDGAR Submission header element seriesClasses:
•
•
Each seriesId results in one series;
Each rptIncludeAllSeriesFlag results in a series for every active series.
For each series, there should be at least one additional Series Context (sc) for each Series ID reported in
the submission. Each such context will have an explicit member of the dimension with local name
LegalEntityAxis in a standard namespace. That axis should have a custom member for every series ID,
such as S000000987, named S000000987Member (EFM v68 § 6.5.41).
3.2.6
Open-end Fund Shareholder Reports
Form N-CSR contains one shareholder report per class. The set of class identifiers in the scope of a
submission is determined by the content of the EDGAR submission header element seriesClasses:
•
•
•
Each rptClassId results in one class;
Each rptIncludeAllClassesFlag results in a class for every active class in that series; and
Each rptIncludeAllSeriesFlag results in a class for every active class in all series of the filer CIK.
For each shareholder report per class, there should be at least one additional Class Context (cc) for each
Class ID reported in the submission. Each such context will have an explicit member of the dimension
with local name ClassAxis in a standard namespace. That axis should have a custom member for every
class ID, such as C000000123, named C000000123Member.
54
Concept
oef:ShareholderReportAnnualOrSemiAnnual
oef:FundName
oef:ClassName
dei:NoTradingSymbolFlag
dei:TradingSymbol
dei:SecurityExchangeName
#
Type or regex
{1}
([Ss]emi[^A-Zaz0-9]+)?[Aa]nnual\s+[Ss]hareholder\s+[Rr]eport
{2}
{3}
xs:normalizedString
xs:normalizedString
{5}
xs:normalizedString up to 25 characters.
{4}
{6}
Meaning
xs:boolean
NONE | BOX | BX | C2 | CBOE | CHX |
Cboe(BYX|BZX|EDGA|EDGX) | GEMX | IEX | ISE | MIAX
| MRX | NASDAQ | NYSE(AMER|Arca|NAT)? | PEARL |
Phlx
EDGAR
National
Exchange
Code
Validations:
Incl
Excl
i: AF.CEF,
HF
i: AF.CEF,
HF
i: AF.CEF,
s: ALL
HF
i: AF.CEF,
HF
i: AF.CEF,
HF
s: ALL
i: AF.CEF,
HF
i: AF.CEF,
HF
s: ALL
Check
On failure
s
r
A {1} fact is present.
{1} Missing
W § 6.5.57 R
r
If {1} facts are present, then
at least one is visible.
{1} in Facts
Not Visible
W § 6.5.57 R
r
A {1} fact is absent.
{1}
Unexpected
W § 6.5.57 []
cc A {2} fact is present.
{2} Missing
W § 6.5.57 R
{2} in Facts
Not Visible
W § 6.5.57 R
cc
If {2} facts are present, then
at least one is visible.
i: AF.CEF,
cc A {2} fact is absent.
HF
cc A {3} fact is present.
cc
If {3} facts are present, then
at least one is visible.
i: AF.CEF,
cc A {3} fact is absent.
HF
i: AF.CEF,
HF
i: AF.CEF,
HF
i: AF.CEF,
HF
i: AF.CEF,
HF
Notes and special cases:
55
c
If a {1} fact is present, then
cc either {4} or a {5} fact exist
but not both.
If {4} facts are present, then
cc
at least one is visible.
If {5} facts are present, then
cc
at least one is visible.
cc
Neither or both of {5} and
{6} facts are present.
f
EFM v68 Ref
{2}
Unexpected
W § 6.5.57 []
{3} Missing
W § 6.5.57 R
{3} in Facts
Not Visible
W § 6.5.57 R
{3}
Unexpected
{1} {2} {3}
1 Exclusive
Dependency
{4} in Facts
Not Visible
W § 6.5.57 []
E
§ 6.5.57 T2*,
T2
W § 6.5.57 T2
{5} in Facts
Not Visible
W § 6.5.57 T2
{5} {6}
Mutual
Dependency
W § 6.5.57 T3
1. See also 3.2.4.4 above that requires dei:NoTradingSymbolFlag and dei:TradingSymbol to be
mutually exclusive in all contexts.
3.3 Resource Extrac�on Payments Disclosure
Exhibit 2.01 of Form SD consists of exactly two attachment types: EX-2.01.INS, an XBRL Instance, and
EX-2.01.SCH, an XBRL Schema, with custom elements and embedded linkbases. Exhibit 2.01.INS is not
an Inline XBRL document.
3.3.1
Currency and Total Payments
Concept
dei:EntityReportingCurrencyISOCode
rxp:TotalPayments
#
{1}
{2}
Type or regex Meaning
[A-Z]{3}
ISO 4217 currency code
Monetary
Validations:
Incl
Excl
i: RXP.US,
RXP.FPI
i: RXP.US,
s: ALL
RXP.FPI
i: RXP.US,
RXP.FPI
i: RXP.US,
s: ALL
RXP.FPI
c Check
A {1} fact is
r
present.
A {1} fact is
r
absent.
A {2} fact is
r
present.
A {2} fact is
r
absent.
f On failure
s
EFM v68 Ref
{1} Missing
W 6.5.58 R*
{1} Unexpected
W 6.5.58 []
{2} TotalPayments
Missing
W 6.5.58 R*
{2} TotalPayments
Unexpected
W 6.5.58 []
Notes and special cases: none.
3.3.2
Payments Axis
A Payment Context (pc) is a context having a typed dimension member of rxp:PmtAxis, an integer value
of the rxp:pmt element and a period matching the required context. There is one payment context for
each payment reported in the disclosure.
3.3.3
Boolean, Numeric and String Valued Facts
The table below lists concepts in the RXP taxonomy that characterizes a single payment or group of
similar payments. These are restricted to basic data types and may only appear in payment contexts.
Concept
#
rxp:M
rxp:Cm
rxp:K
rxp:Km
rxp:A
Type or regex
Monetary
Meaning
Amount
{2}
Well|Open
Pit|Underground Mining
Method of Extraction. Note that there are three
distinct values of M, two of them containing spaces.
{3}
{4}
{5}
xs:normalizedString
true
xs:normalizedString
Currency Conversion Method
In-kind Payment flag
In-kind calculation method
{1}
Validations:
Incl
i: RXP.US,
RXP.FPI
i: RXP.US,
RXP.FPI
56
Excl c
Check
If a {1} fact is present, then a {2}
pc
fact is present.
If a {2} fact is present, then a {1}
pc
fact is present.
f On failure
1 {1} {2} Value
1
Dependency
{2} {1} Value
Dependency
s
EFM v68 Ref
W § 6.5.58 Item
3
W § 6.5.58 Item
3
Incl
i: RXP.US,
RXP.FPI
i: RXP.US,
RXP.FPI
i: RXP.US,
RXP.FPI
i: RXP.US,
RXP.FPI
i: RXP.US,
RXP.FPI
Excl c
Check
If a {3} fact is present, then a {1}
fact is present.
If a {4} fact is present, then a {1}
fact is present.
If a {4} fact present, then a {5}
fact is present.
If a {5} fact present, then a {4}
fact is present.
If a {1} fact is present with
unitRef matching the value of
pc
pc
pc
pc
pc
EntityReportingCurrencyISOCode in the required context,
then a {3} fact should not be
present.
pc At least one {1} fact is present in
the instance with period matching
the 12-month reporting period
and unit matching the value of
i: RXP.US,
RXP.FPI
f On failure
1 {3} {1} Value
Dependency
1 {4} {1} Value
Dependency
1 {4} {5} Value
Dependency
1 {5} {4} Value
Dependency
{3}
Unexpected
2 Amount for
Required 12
Months Period
s
EFM v68 Ref
W § 6.5.58 Item
3
W § 6.5.58 Item
3
W § 6.5.58 Item
3
W § 6.5.58 Item
3
W § 6.5.58 Item
4
W § 6.5.58 Item
5
EntityReportingCurrencyISOCode in the required context.
Notes and special cases:
1. There are no checks for absence of these facts in other submission types or contexts.
2. Only one such fact is needed; the check does not apply to every individual payment context.
3.3.4
Member-valued Facts
The table below lists concepts in the RXP taxonomy restricted by the taxonomy to have values that are
declared custom members (see 5.7 below) of one of the standard domains:
Concept
#
rxp:Sn
{4}
rxp:Gv
rxp:Pr
{5}
{6}
rxp:A
rxp:E
rxp:Co
rxp:P
rxp:R
rxp:Sg
{1}
{2}
{3}
{7}
{8}
{9}
Type or regex
Monetary
Custom member of dei:EntityDomain
Standard member of country:AllCountriesDomain
Standard member of snj:AllSubnationalJurisdictionsDomain
Custom member of rxp:AllGovernmentsMember
Custom member of rxp:AllProjectsMember
Custom member of rxp:AllPaymentTypesMember
Custom member of rxp:AllResourcesMember
Custom member of rxp:AllSegmentsMember
Meaning
Amount
Entity
Country
Subnational
Jurisdiction
Government
Project
Payment Type
Resource
Segment
Validations:
Incl
i: RXP.US,
RXP.FPI
i: RXP.US,
RXP.FPI
i: RXP.US,
RXP.FPI
57
Excl c
Check
If a {1} fact is present,
pc
then a {5} fact is present.
If a {1} fact is present,
pc
then a {3} fact is present.
If a {1} fact is present,
pc
then a {8} fact is present.
f On failure
1 {1} {5} Value
1
Dependency
{1} {3} Value
Dependency
1 {1} {8} Value
Dependency
s
EFM v68 Ref
W § 6.5.58 Item
3
W § 6.5.58 Item
3
W § 6.5.58 Item
3
Incl
i: RXP.US,
RXP.FPI
i: RXP.US,
RXP.FPI
i: RXP.US,
RXP.FPI
i: RXP.US,
RXP.FPI
i: RXP.US,
RXP.FPI
i: RXP.US,
RXP.FPI
i: RXP.US,
RXP.FPI
i: RXP.US,
RXP.FPI
Excl c
Check
If a {2} fact present, then
a {1} fact is present.
If a {3} fact present, then
a {1} fact is present.
If a {4} fact is present,
then a {3} fact is present.
If a {5} fact is present,
then a {3} fact is present.
If a {6} fact present, then
a {5} fact is present.
If a {7} fact present, then
a {1} fact is present.
If a {8} fact present, then
a {1} fact is present.
If a {9} fact present, then
a {1} fact is present.
pc
pc
pc
pc
pc
pc
pc
pc
f On failure
1 {2} {1} Value
Dependency
1 {3} {1} Value
Dependency
1 {4} {3} Value
Dependency
1 {5} {3} Value
Dependency
1 {6} {5} Value
Dependency
1 {7} {1} Value
Dependency
1 {8} {1} Value
Dependency
1 {9} {1} Value
Dependency
s
EFM v68 Ref
W § 6.5.58 Item
3
W § 6.5.58 Item
3
W § 6.5.58 Item
3
W § 6.5.58 Item
3
W § 6.5.58 Item
3
W § 6.5.58 Item
3
W § 6.5.58 Item
3
W § 6.5.58 Item
3
Notes and special cases:
1. There are no checks for absence of these facts in other submission sets, instance types, or contexts.
3.3.5
Payment Contexts
An RXP.US or RXP.FPI instance is likely to have more than one payment, and therefore more than one
payment context. The existence of even a single payment context fact requires that there exist facts to
represent the aggregated sum of individual payments by project, by government, and in total.
A set of concepts in the RXP taxonomy characterizes aggregate payments of nine types. In each case, the
existence of a non-null fact value for that aggregate concept in any context should be accompanied by at
least one Payment fact in some context with the matching member as value.
Concept
#
rxp:P
{1}
rxp:Taxes
rxp:Royalties
rxp:Fees
rxp:ProductionEntitlements
rxp:Bonuses
rxp:Dividends
{2}
{3}
{4}
{5}
rxp:InfrastructureImprovements
rxp:CommunityAndSocial
rxp:OtherPayments
{6}
{7}
Type or regex
Custom member of rxp:AllPaymentTypesMember
Monetary
Monetary
Monetary
{9}
Monetary
{10}
Production Entitlements
Monetary
Monetary
Monetary
Payment Type
Taxes
Royalties
Fees
Monetary
{8}
Meaning
Bonuses
Dividends
Infrastructure
Improvements
Community and Social
Monetary
Other Payments
Validations:
Incl
i: RXP.US,
RXP.FPI
58
Excl c
pc,
r
Check
If a {1} fact valued rxp:Taxes is
present, then at least one {2} fact
is present in the required context.
f
1
On failure
{1} {2}
Value
Dependency
s
EFM v68 Ref
W
§ 6.5.58 Item
7
Incl
Excl c
i: RXP.US,
RXP.FPI
r,
pc
i: RXP.US,
RXP.FPI
pc,
r
i: RXP.US,
RXP.FPI
r,
pc
i: RXP.US,
RXP.FPI
pc,
r
i: RXP.US,
RXP.FPI
r,
pc
i: RXP.US,
RXP.FPI
pc,
r
i: RXP.US,
RXP.FPI
r,
pc
i: RXP.US,
RXP.FPI
pc,
r
i: RXP.US,
RXP.FPI
r,
pc
i: RXP.US,
RXP.FPI
pc,
r
i: RXP.US,
RXP.FPI
r,
pc
59
Check
If a {2} fact is present, then a
{1} fact valued rxp:Taxes is
present in at least one payment
context.
If a {1} fact valued
rxp:Royalties is present, then at
least one {3} fact is present in the
required context.
If a {3} fact is present, then a
{1} fact valued rxp:Royalties
is present in at least one payment
context.
If a {1} fact valued rxp:Fees is
present, then at least one {4} fact
is present in the required context.
If a {4} fact is present, then a
{1} fact valued rxp:Fees is
present in at least one payment
context.
If a {1} fact valued
f
is present, then at least one {5}
fact is present in the required
context.
If a {5} fact is present, then a
{1} fact valued
1 Value
rxp:ProductionEntitlements
rxp:ProductionEntitlements
is present in at least one payment
context.
If a {1} fact valued rxp:Bonuses
is present, then at least one {6}
fact is present in the required
context.
If a {6} fact is present, then a
{1} fact valued rxp:Bonuses is
present in at least one payment
context.
If a {1} fact valued
rxp:Dividends is present, then at
least one {7} fact is present in the
required context.
If a {7} fact is present, then a
{1} fact valued rxp:Dividends
is present in at least one payment
context.
On failure
{2} {1}
1 Value
Dependency
{1} {3}
1 Value
Dependency
{3} {1}
1 Value
Dependency
{1} {4}
1 Value
Dependency
{4} {1}
1 Value
Dependency
{1} {5}
Dependency
{5} {1}
1 Value
Dependency
{1} {6}
1 Value
Dependency
{6} {1}
1 Value
Dependency
{1} {7}
1 Value
Dependency
{7} {1}
1 Value
Dependency
s
EFM v68 Ref
W
§ 6.5.58 Item
6
W
§ 6.5.58 Item
7
W
§ 6.5.58 Item
6
W
§ 6.5.58 Item
7
W
§ 6.5.58 Item
6
W
§ 6.5.58 Item
7
W
§ 6.5.58 Item
6
W
§ 6.5.58 Item
7
W
§ 6.5.58 Item
6
W
§ 6.5.58 Item
7
W
§ 6.5.58 Item
6
Incl
Excl c
i: RXP.US,
RXP.FPI
pc,
r
i: RXP.US,
RXP.FPI
r,
pc
i: RXP.US,
RXP.FPI
pc,
r
i: RXP.US,
RXP.FPI
r,
pc
i: RXP.US,
RXP.FPI
pc,
r
i: RXP.US,
RXP.FPI
r,
pc
Check
If a {1} fact valued rxp:
f
is present, then at least one {8}
fact is present in the required
context.
If a {8} fact is present, then a
{1} fact valued rxp:
1 Value
InfrastructureImprovements
InfrastructureImprovements
is present in at least one payment
context.
If a {1} fact valued rxp:
CommunityAndSocial is present,
then at least one {9} fact is
present in the required context.
If a {9} fact is present, then a
{1} fact valued rxp:
CommunityAndSocial is present
in at least one payment context.
If a {1} fact valued rxp:OtherPayments is present, then at least
one {10} fact is present in the
required context.
If a {10} fact is present, then a
{1} fact valued rxp:OtherPayments is present in at least
one payment context.
On failure
{1} {8}
Dependency
{8} {1}
1 Value
Dependency
{1} {9}
1 Value
Dependency
{9} {1}
1 Value
Dependency
{1} {10}
1 Value
Dependency
{10} {1}
1 Value
Dependency
s
EFM v68 Ref
W
§ 6.5.58 Item
7
W
§ 6.5.58 Item
6
W
§ 6.5.58 Item
7
W
§ 6.5.58 Item
6
W
§ 6.5.58 Item
7
W
§ 6.5.58 Item
6
Notes and special cases:
1. The contexts of the monetary and the member-valued facts are distinct. The values of Amount rxp:A
facts may be reasonably expected to arithmetically sum by payment type to the aggregate fact in the
required context, but the validation process requires only that the corresponding aggregate facts exist.
3.3.6
Government Aggregate Contexts
A Government Aggregate Context (gac) is a context having a custom member of rxp:GovernmentAxis.
Concept
#
rxp:Gv
{1}
Type or regex
Meaning
Custom member of rxp:AllGovernmentsMember Government
Validations:
Incl
i: RXP.US,
RXP.FPI
Excl c
gac,
pc
Notes and special cases:
60
Check
If a government aggregate
context (gac) exists, then at
least one payment context (pc)
exists with a {1} fact having
that member value.
f
On failure
{1} {2}
1 Value
Dependency
s
EFM v68 Ref
W
§ 6.5.58 Item
8
1. The contexts of the monetary and the member-valued facts are distinct. The values of Amount rxp:A
facts may be reasonably expected to arithmetically sum across all members of the government axis,
but the validation process requires only that the corresponding aggregate facts exist.
3.3.7
Project Aggregate Contexts
A Project Aggregate Context (pac) is a context having a custom member of rxp:GovernmentAxis.
Concept
#
rxp:Pr
Type or regex
Meaning
Custom member of rxp:AllProjectsMember Project
{1}
Validations:
Incl
Excl c
i: RXP.US,
RXP.FPI
pac,
pc
Check
If a project aggregate context
(pac) exists, then at least one
payment context (pc) exists
with a {1} fact having that
member value.
f
On failure
{1} {2}
1 Value
Dependency
s
EFM v68 Ref
W
§ 6.5.58 Item
8
Notes and special cases:
1. The contexts of the monetary and the member-valued facts are distinct. The values of Amount rxp:A
facts may be reasonably expected to arithmetically sum across all members of the project axis, but the
validation process requires only that the corresponding aggregate facts exist.
4 Filing Fee Exhibits
4.1 Filing Fee Inline XBRL Atachments
An Inline XBRL Filing Fee exhibit may be prepared using EDGAR’s Fee Exhibit Preparation Tool
(FEPT) as part of EDGAR Link Online (ELO) or by a third-party Inline XBRL document preparation
tool.
The Inline XBRL Filing Fee exhibit is identified as the “EX-FILING FEES” attachment document type.
(The Inline XBRL Filing Fee exhibit (EX-Filing Fees) is a separate XBRL instance identified as
“EX-FILING FEES.”) EX-Filing Fees is independent of any primary document attachments comprising
an Inline XBRL Document Set (such as for a 10-K exhibit) or any other Inline XBRL instance. The
EX-Filing Fee taxonomy, facts, units, and their supporting contexts, should not be comingled with any
other Inline XBRL instances. Selecting a different document type will result in the submission being
suspended.
The exhibit is viewed and prepared as tables (specified by the link roles of the FFD taxonomy dimensions
hypercubes). These tables may have more than one line use per a line number typed dimension to identify
which facts are logically grouped on that line. (The line number is an integer with no constraints, it could
be sequential or anything else meaningful to the author.)
The Tables are:
Table (link role name)
Submission Table
Fees Summary Table
Fees, by Offering
Fees, by Offset
61
Table has lines (lineNo dimension members)
No
No
Yes
Yes
Fees, by Combined Prospectus Yes
Securities, 424I
Yes
The words “must” or “must not” mean that if the validation fails, an error will be raised, and the
submission will be suspended.
The words “should” or “should not” mean that if the validation fails, the exhibit will be accepted, and a
warning message will be issued.
The words “may” or “may not” mean that there is no validation that would result in a warning or error.
4.1.1
Security Types Based on Rule
The following table shows the security types applicable to each rule:
Rules
457(a)
Yes
Yes
Yes
Yes
Yes
No
Yes
Yes
Yes
Yes
No
Security Type
Asset-Backed Securities
Debt
Debt Convertible into Equity
Equity
Exchange-Traded Vehicle Securities
Face Amount Certificates
Limited Partnership Interests
Mortgage-Backed Securities
Non-Convertible Debt
Other
Unallocated (Universal) Shelf
4.1.2
457(o)
Yes
Yes
Yes
Yes
Yes
No
Yes
Yes
Yes
Yes
Yes
457(f)
Yes
Yes
Yes
Yes
Yes
No
Yes
Yes
Yes
Yes
No
457(u)
No
No
No
No
Yes
No
No
No
No
No
No
457(r)
No
Yes
Yes
Yes
Yes
No
Yes
No
Yes
Yes
No
457(s)
Yes
No
No
No
No
No
No
Yes
No
No
No
Offering & Transac�on Valua�on Rules Applicable for Submission Types
Rules
Submission Types
424I
F-1
F-3
F-3ASR
F-3D
N-2
N-2ASR
S-1
S-3
S-3D
S-3ASR
S-11
SF-1
SF-3
F-1/A
62
457(a)
457(o)
Other
No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
415(a)(6)
457(f)
457(u)
457(r)
457(s)
0-11**
No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No
Yes
No
No
No
No
No
Yes
No
No
No
Yes
No
No
Yes
Yes*
Yes
Yes
No
Yes
No
No
No
No
No
Yes
No
No
Yes
No
No
No
No
No
No
No
No
No
No
No
No
No
No
Yes
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
Yes
Yes
Yes
Yes
Yes
No
No
No
No
Yes
No
No
Yes
No
No
No
No
Other
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No
Rules
Submission Types
F-3/A
N-2/A
N-2 POSASR
POSASR
POS AM
S-1/A
S-3/A
S-11/A
SF-1/A
SF-3/A
F-4
F-10
F-10EF
N-14 8C
S-4
S-4EF
F-4/A
F-10/A
N-14 8C/A
S-4/A
PREM14A
PREM14C
SC 13E1
SC 13E3
SC TO-I
SC TO-T
SC13E4F
SC14D1F
PRER14A
PRER14C
SC 13E1/A
SC 13E3/A
SC13E4F/A
SC14D1F/A
SC TO-I/A
SC TO-T/A
F-3MEF
N-2MEF
63
457(a)
457(o)
Other
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
Yes
Yes
415(a)(6)
457(f)
457(u)
457(r)
457(s)
0-11**
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No
No
No
No
Yes
Yes
No
Yes
No
No
Yes
No
No
Yes
Yes
Yes
Yes
No
Yes
Yes
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
Yes
No
No
No
No
No
No
Yes
Yes
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
Yes
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No
No
No
Yes
Yes
No
No
No
Yes
Yes
Yes
No
No
Yes
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
Yes
Yes
Yes
Yes
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
Rules
Submission Types
S-3MEF
SF-1MEF
SF-3MEF
F-1MEF
F-4MEF
S-4MEF
N-14MEF
S-1MEF
S-11MEF
424B1
424B2
424B3
424B4
424B5
424B7
424B8
424H
424H/A
S-8
457(a)
457(o)
Other
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
415(a)(6)
457(f)
457(u)
457(r)
457(s)
0-11**
Yes
No
Yes
Yes
Yes
Yes
No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No
No
No
No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No
No
No
No
No
No
No
No
No
No
No
No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
*Rule 457(u) is inferred on 424I submissions.
** Rule 0-11 is inferred for applicable submission types as described in section 4.5.
4.1.3
Offset Table & Combined Prospectus Rules Applicable for Submission Types
Rules
Submission
Types
424I
F-1
F-3
F-3ASR
F-3D
N-2
N-2ASR
S-1
S-3
S-3D
S-3ASR
S-11
64
457(b)
0-11(a)(2)
457(p)
429
No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No
Yes
Yes
Yes
No
Yes
Yes
Yes
Yes
No
Yes
Yes
Yes**
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Rules
Submission
Types
SF-1
SF-3
F-1/A
F-3/A
N-2/A
N-2 POSASR
POSASR
POS AM
S-1/A
S-3/A
S-11/A
SF-1/A
SF-3/A
F-4
F-10
F-10EF
N-14 8C
S-4
S-4EF
F-4/A
F-10/A
N-14 8C/A
S-4/A
PREM14A
PREM14C
SC 13E1
SC 13E3
SC TO-I
SC TO-T
SC13E4F
SC14D1F
PRER14A
PRER14C
SC 13E1/A
SC 13E3/A
SC13E4F/A
SC14D1F/A
SC TO-I/A
SC TO-T/A
F-3MEF
65
457(b)
0-11(a)(2)
457(p)
429
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
Yes
No
No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No
No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
Yes
Rules
Submission
Types
N-2MEF
S-3MEF
SF-1MEF
SF-3MEF
F-1MEF
F-4MEF
S-4MEF
N-14MEF
S-1MEF
S-11MEF
424B1
424B2
424B3
424B4
424B5
424B7
424B8
424H
424H/A
S-8
457(b)
0-11(a)(2)
457(p)
429
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No
Yes
Yes
No
No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No
No
No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No
** Offset sources are not required for 424I submission type.
4.2 Submission Table
The following submission table facts are currently specified by EFM version 68, § 6.5.21 as follows:
Exhibit Type
DEI Element
EntityRegistrantName
EX-FILING FEE
X*
X*
EntityCentralIndexKey
In the required context:
•
X* –
A non-null fact must exist.
The remainder of this section specifies table facts specific to Filing Fee attachments:
FFD Element
RegnFileNb
W
SubmissnTp
X*
FormTp
66
Submission
Type 424I
XS
Others*
WA
FFD Element
Submission
Type 424I
FeeExhibitTp
XF
IssrBizAdrStrt1
W
IssrNm
IssrBizAdrStrt2
IssrBizAdrCity
IssrBizAdrStatOrCtryCd
IssrBizAdrZipCd
CeasedOprsDt
RptgFsclYrEndDt
Others*
W, T
W2
W
W2
W
O, o
WD, DB,
Future
In the required context:
•
X* –
A non-null fact should exist.
•
W–
A non-null fact should exist (warning).
•
WA – For Amendment/MEF Filings, non-null fact should exist (submission types S-1/A, S-3/A,
S-11/A, N-2/A, F-1/A, F-3/A, SF-1/A, SF-3/A, N-2 POSASR, POS AM, POSASR, S-4/A, N-14
8C/A, F-4/A, F-10/A, SF-1MEF, SF-3MEF, N-2MEF, S-3MEF, F-3MEF, F-1MEF, F-4MEF, N14MEF, S-1MEF, S-4MEF, S-11MEF, 424B1, 424B2, 424B3, 424B4, 424B5, 424B7, 424B8,
424H, 424H/A) (warning).
•
W2 –
Only when IssrBizAdrStrt1 is provided.
•
O–
A non-null fact may or may not exist.
•
XS – FormTp must match an allowed form type for the submission type (e.g., F-4 for F-4/A or
F-4MEF Submission Types).
•
XF –
•
D–
EDGAR date field validations, expected Value between 1980-01-01 and 2050-12-31
(warning).
•
T–
FeeExhibitTp has the value EX-FILING FEES.
EDGAR text field validations, regex:
[0-9A-Za-z`~!@#$%&*(). [\]{}|\\:;"'<>,_?/=\t\n\r\f+-]{1,150} (warning).
•
WD –
Required if CeasedOprsDt is not provided (warning).
•
DB –
When provided, must match Database record of filer registration.
•
Future – Must not be a future date.
•
Blank – A non-null fact should not exist.
•
Others* – All submission types specified in section 4.1.2 excluding 424I.
4.3 Fees Summary Table
This table has no dimensions. This table shows the validations.
67
Submission Type
424I
SC*
Others*
FFD Element
TtlOfferingAmt = Sum of
MaxAggtOfferingPric [1]
TtlOfferingAmt
NR*, TtlPrevslyPdAmt not greater than TtlFeeAmt
[3]
TtlPrevslyPdAmt
NR*, Sum of
FeeAmt [2]
TtlFeeAmt
TtlTxValtn
FeeIntrstAmt
TtlFeeAmt ×
intrstRate ×
yrs late
TtlOffsetAmt
NR*, TtlFeeAmt +
FeeIntrstAmt
NetFeeAmt
NR*, TtlFeeAmt TtlOffsetAmt +
FeeIntrstAmt
TtlFeeAndIntrstAmt
NR*, Sum of FeeAmt [1]
Sum of
TxValtn [1]
NR*, TtlOffsetAmt not greater than
TtlFeeAmt - TtlPrevslyPdAmt
NR*, TtlFeeAmt – TtlOffsetAmt TtlPrevslyPdAmt
TtlFeeAmt +
FeeIntrstAmt
•
SC* – SC 13E1, SC 13E3, SC13E4F, PREM14A, PREM14C, SC TO-I, SC TO-T, SC14D1F,
SC 13E1/A, SC 13E3/A, SC 13E4F/A, PRER14A, PRER14C, SC14D1F/A, SC TO-T/A, SC TOI/A.
•
Others* - All submission types specified in section 4.1.2 excluding 424I and SC*.
•
NR* - Must be a number ranging from 0 to 99,999,999,999,999.99 inclusive.
•
[1] –
From the Offerings table.
•
[2]–
From the 424I table.
•
[3] –
Regardless of whether the filer is claiming an offset or not.
Submission
Type
FFD Element
NrrtvDsclsr
NrrtvMaxAggtOfferingPric
NrrtvMaxAggtAmt
FnlPrspctsFlg
68
POS* –
ND,
HTML
ND
NP,
NR
NP,
NR
O
In the required context:
•
POS* 424B* Validation
POS AM, POSASR, N-2 POSASR.
Either
ND or NP
•
424B* –
424B1, 424B2, 424B3, 424B4, 424B5, 424B7, 424B8
•
HTML – XHTML encoded text block (^ and non-ASCII characters must be &#-encoded).
•
NR –
Number ranging from 0 to 99,999,999,999,999.99 inclusive.
•
ND –
Narrative disclosure.
•
NP –
Narrative price.
4.4 Offering Table
Offering table facts are grouped by lineNo integer values of the Offerings Axis into lines. Validations are
performed by line (on the facts of the table which have the same lineNo member). Missing lineNo
members results in an XBRL Dimensional syntax error.
Offering table lines are grouped into two Offering Types: Fees to be Paid and Fees Previously Paid. A
Fees to be Paid line has a value of false for the PrevslyPdFlg element. A Fees Previously Paid line has a
value of true for the PrevslyPdFlg element.
4.5 Offering Table Rule Flags
The rule flags identify the rule applicable to a line, one of Rule457aFlg, Rule457oFlg, Rule457uFlg,
Rule457rFlg, Rule457sFlg, Rule011Flg, FeesOthrRuleFlg, or Rule415a6Flg may be specified for a
line, except when Rule011Flg can be deemed to be defaulted. Rule011Flg is deemed to have the value
true when none of the other flags are true in submission types applicable to Rule 0-11 as specified in
section 4.1.2 above.
4.5.1
Rule 457(a) Lines
The following validations are provided for lines specifying Rule457aFlg, for applicable submission types
as specified in section 4.1.2 above.
Offering Type Fees to be
paid
FFD Element
PrevslyPdFlg
W
OfferingSctyTitl [1]
W, T
MaxOfferingPricPerScty
[1]
W, NR1
Should be a valid EDGAR Security
Type for this rule as specified in the
“Security Types Based on Rule”
section 4.1.1
W, NR3
MaxAggtOfferingPric [1]
W, NR
DB
FeeRate [1]
W, FD
UO
OfferingNote
HTML
FeeAmt [1]
W, NR2
In a context with lineNo dimensions:
69
Validation*
W, FA
OfferingSctyTp [1]
AmtSctiesRegd [1]
Fees
previously
paid
AmtSctiesRegd ×
MaxOfferingPricPerScty
MaxAggtOfferingPric × FeeRate
•
1
–
Not applicable when Rule 457(f) is specified for the same context (see 4.5.9 Rule 457(f)).
•
W–
Required, including any additional validation in adjacent column (warning).
•
T–
EDGAR text field validations, regex:
[0-9A-Za-z`~!@#$%&*(). [\]{}|\\:;"'<>,_?/=\t\n\r\f+-]{1,150} (warning).
•
HTML – XHTML encoded text block (^ and non-ASCII must also be &#-encoded)
•
FA – Should be false for non-amendment submission types (S-1, S-3, S-3ASR, S-3D, S-11,
N-2, N-2ASR, F-1, F-3, F-3ASR, F-3D, SF-1, SF-3, S-4, S-4EF, N-14 8C, F-4, F-10, F-10EF,
SF-1MEF, SF-3MEF, N-2MEF, S-3MEF, F-3MEF, F-1MEF, F-4MEF, N-14MEF, S-1MEF,
S-4MEF, S-11MEF, S-8)
•
FD –
Should match the fee rate of the day submitted.
•
NR –
Number ranging from 0 to 99,999,999,999,999.99 inclusive.
•
NR1 – Number ranging from 0 to 999,999,999,999.9999 inclusive.
•
NR2 – Number ranging from 0 to 999,999,999,999.99 inclusive.
•
NR3 – Number ranging from 0 to 999,999,999,999 inclusive.
•
DB – Maximum Aggregate Offering Price (MAOP) amount provided should match the prior
filing using the Security Type and Security Class Title combination for the file number specified
on the filing.
•
UO –
•
Validation* – Excluding and unexpected for submission types not specified in section 4.1.2.
4.5.2
Unexpected, may be omitted.
Rule 457(o) Lines
The following validations are provided for lines specifying Rule457oFlg, for applicable submission types
as specified in section 4.1.2.
Offering Type
FFD Element
Fees to be
paid
PrevslyPdFlg
W, FA
OfferingSctyTp [1]
W
OfferingSctyTitl [1]
W, T
AmtSctiesRegd [1]
MaxOfferingPricPerScty
[1]
NR1, UO
W, NR
FeeRate [1]
W, FD
OfferingNote
HTML
70
W, NR2
Validation*
Should be a valid EDGAR
Security Type for this rule as
specified in the “Security Types
Based on Rule” section 4.1.1
NR3, UO
MaxAggtOfferingPric [1]
FeeAmt [1]
Fees
previously
paid
UO
In a context with lineNo dimensions:
–
Not applicable when Rule457fFlg is specified for the same context (see 4.5.9 Rule
457(f))
•
1
•
W–
Required, including any additional validation in adjacent column (warning).
•
T–
EDGAR text field validations, regex:
[0-9A-Za-z`~!@#$%&*(). [\]{}|\\:;"'<>,_?/=\t\n\r\f+-]{1,150} (warning).
•
HTML – XHTML encoded text block (^ and non-ASCII must also be &#-encoded).
•
FA – Should be false for non-amendment submission types (S-1, S-3, S-3ASR, S-3D, S-11,
N-2, N-2ASR, F-1, F-3, F-3ASR, F-3D, SF-1, SF-3, S-4, S-4EF, N-14 8C, F-4, F-10, F-10EF,
SF-1MEF, SF-3MEF, N-2MEF, S-3MEF, F-3MEF, F-1MEF, F-4MEF, N-14MEF, S-1MEF,
S-4MEF, S-11MEF, S-8).
•
FD –
Should match the fee rate of the day submitted.
•
NR –
Number ranging from 0 to 99,999,999,999,999.99 inclusive.
•
NR1 – Number ranging from 0 to 999,999,999,999.9999.
•
NR2 – Number ranging from 0 to 999,999,999,999.99 inclusive.
•
NR3 – Number ranging from 0 to 999,999,999,999 inclusive.
•
UO –
•
Validation* – Excluding and unexpected for submission types not specified in section 4.1.2.
4.5.3
Unexpected, may be omitted.
Rule 457(r) Lines
The following validations are provided for lines specifying Rule457rFlg, for applicable submission types
as specified in section 4.1.2.
Offering Type
FFD Element
Fees to be
paid
PrevslyPdFlg
W, FA
OfferingSctyTp
W
OfferingSctyTitl
W, T
AmtSctiesRegd
NR3, UO
MaxOfferingPricPerScty
NR1, UO
MaxAggtOfferingPric
NR, UO
FeeRate
O, FD
FeeAmt
O, NR2
71
Fees
previously
paid
Validation*
Should be a valid EDGAR
Security Type for this rule as
specified in section 4.1.1
UO
Offering Type
FFD Element
OfferingNote
Fees
previously
paid
Fees to be
paid
Validation*
W, HTML
In a context with lineNo dimensions:
•
W–
Required, including any additional validation in adjacent column (warning).
•
O–
Optional.
•
T–
EDGAR text field validations, regex:
[0-9A-Za-z`~!@#$%&*(). [\]{}|\\:;"'<>,_?/=\t\n\r\f+-]{1,150} (warning).
•
HTML – XHTML encoded text block (^ and non-ASCII must also be &#-encoded).
•
FA – Should be false for non-amendment submission types (S-1, S-3, S-3ASR, S-3D, S-11, N2, N-2ASR, F-1, F-3, F-3ASR, F-3D, SF-1, SF-3, S-4, S-4EF, N-14 8C, F-4, F-10, F-10EF, SF1MEF, SF-3MEF, N-2MEF, S-3MEF, F-3MEF, F-1MEF, F-4MEF, N-14MEF, S-1MEF, S-4MEF,
S-11MEF, S-8).
•
FD –
Should match the fee rate of the day submitted.
•
NR –
Number ranging from 0 to 99,999,999,999,999.99 inclusive.
•
NR1 – Number ranging from 0 to 999,999,999,999.9999.
•
NR2 – Number ranging from 0 to 999,999,999,999.99 inclusive.
•
NR3 – Number ranging from 0 to 999,999,999,999 inclusive.
•
UO –
•
Validation* – Excluding and unexpected for submission types not specified in section 4.1.2.
4.5.4
Unexpected, may be omitted.
Rule 457(s) Lines
The following validations are provided for lines specifying Rule457sFlg, for applicable submission types
as specified in section 4.1.2.
Offering Type
FFD Element
Fees to
be paid
PrevslyPdFlg
W, FA
OfferingSctyTp
W
OfferingSctyTitl
W, T
MaxOfferingPricPerScty
NR1, UO
AmtSctiesRegd
Validation*
Should be a valid EDGAR Security
Type for this rule as specified in section
4.1.1
NR3, UO
MaxAggtOfferingPric
NR, UO
FeeRate
O, FD
72
Fees
previously
paid
AmtSctiesRegd ×
MaxOfferingPricPerScty; 0 is
UO
allowed.
Offering Type
FFD Element
FeeAmt
Fees to
be paid
O, NR2
OfferingNote
Fees
previously
paid
Validation*
W, HTML
In a context with lineNo dimensions:
•
W–
Required, including any additional validation in adjacent column (warning).
•
O–
Optional.
•
T–
EDGAR text field validations, regex:
[0-9A-Za-z`~!@#$%&*(). [\]{}|\\:;"'<>,_?/=\t\n\r\f+-]{1,150} (warning).
•
HTML – XHTML encoded text block (^ and non-ASCII must also be &#-encoded).
•
FA –
Should be false for non-amendment submission types (SF-3).
•
FD –
Should match the fee rate of the day submitted.
•
NR –
Number ranging from 0 to 99,999,999,999,999.99 inc
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.