U.S. Securities & Exchange Commission
SEC Seal
Home | Previous Page
U.S. Securities and Exchange Commission

EDGAR Information:
Reduced Content XFDL Specification
Version 2.0

Notice: Reduced Content Specification Change — See Appendices Section

Release Notes

This Release introduces minor updates to submission Templates 1, 2, and 3 and EDGARLink software that are based on recent SEC requests and rulemaking activities. EDGAR 8.2 supports backward compatibility with the 8.0 and 8.1 templates as long as the reporting requirements for specific form types have not changed. Edgar 8.2 server software supports all of the field identifiers that were valid in the 8.0 and 8.1 versions of the PureEdge templates as well as two new field identifiers, SubTable_depository_ added to Template 1 and SubTable_fiscalYear_ added to Template 3. New SEC form types (57) have been added and several SEC form types (14) are no longer supported and have been deleted from Templates 1, 2 and 3.

Table of New Form Types

Template 1 Template 2 Template 3
Various 1933 Securities Act Registration Statements Various Investment Company Submission Types Annual, Quarterly, and Periodic Reports
AW WD Williams Act Submission Types 40-F
Registration of Securities by Certain Investment Companies Pursuant to Rule 24f-2 CB/A 8-K12B
Submissions Pursuant to the Trust Indenture Act F-N 8-K12B/A
T-6/A SC13E4F  
Registration Statements for Foreign Issuers SC13E4F/A 1934 Securities Exchange Act Registration Statements
F-10 SC14D1F 25
F-10/A SC14D1F/A 25/A
F-10EF SC14D9F 40FR12B
F-10POS SC14D9F/A 40FR12B/A
F-4EF Miscellaneous 1933 Securities Act Submission Types 40FR12G
F-4EF/A F-X 40FR12G/A
F-4 POS F-X/A  
F-7/A Ownership Submissions Pursuant to Section 16 or Rule 144  
F-7 POS Development Bank Submission Types  
F-9 POS    

Table of Retired Form Types

Template 1 Template 2 Template 3
Various 1933 Securities Act Registration Statements

1934 Securities Exchange Act Proxy Materials and Information Statements Filed Pursuant to Section 14

Annual, Quarterly, and Periodic Reports




















Williams Act Submission Types



SC 13E4/A



SC 14D1/A



Other Changes By Template

The following changes are called out in the appendices. Please refer there for details.

Template 1

  1. T-3 submissions are no longer fee bearing
  2. The following pre-effective amendment form types cannot be 40 Act only submissions.
    1. N-1/A, N-1A/A, N-2/A, N-3/A, N-4/A, N-5/A, and N-6/A
  3. For submission types N-2 and N-5, offering and offset information is not allowed if the act is 40
  4. For submission types N-2/A and N-5/A, 40 is not a valid act
  5. SubTable_depository_ is a new mandatory field for the following submission types
    1. F-6, F-6/A, and F-6EF

Template 2

  1. Future period dates are now allowed for the following submission types
    1. N-23C-2, N-23C-2/A, N-23C3A, N-23C3A/A, N-23C3B, N-23C3B/A, N-23C3C, and N-23C3C/A.
  2. Future period dates are not allowed for submission types N-23C-1 and N-23C-1.
  3. The spelling of submission type SC 14D9-C is changed to SC14D9C.
  4. Coregistrant fields are replaced by subject company fields, SubCompany_filerId_, SubCompany_irsNumber_, SubCompany_filerName_, and when applicable, SubCompany_fileNumber_ for submission types
    1. 40-17F1, 40-17F1/A, 40-17F2, 40-17F2/A, N-27D-1, and N-27D-1/A.
  5. The SubFiler_fileNumber_ field is not valid for a subject company submission that is a confirming copy.

Template 3

  1. The following submission types are now single registrant forms. The coregistrant fields, SubCoreg_filerId_, SubCoreg_filerCcc_, and SubCoreg_fileNumber_ are not valid.
    1. 13F-HR, 13F-HR/A, 13F-NT, 13F-NT/A
  2. The following 8-K variants that specify the value "8" for the SubItem_itemId_ field must include a valid SubTable_fiscalYear_ field, unless the submission is a confirming copy.
    1. 8-K, 8-K/A, 8K12B, 8K12B/A,8K12G3,8K12G3/A,8K15D5, 8K15D5/A

1. Purpose

The EDGARlink portion of the EDGAR web-based filing environment is based on the PureEdge (formerly UWI.COM) XFDL forms specification, which is an extension of the XML specification. An EDGAR filer, from his client machine, must use the PureEdge Viewer application to open an XFDL Template and construct a file that he can then submit via Filer Web Server (FWS). The EDGAR server-side software uses the PureEdge Application Programming Interface (API) to parse the pertinent submission data from the filer's XFDL file.

Roughly 99% of the XFDL content of each EDGAR Template, as well as any submission file saved from the Template, is just needed for the rendering of the Graphical User Interface (GUI). The EDGAR Receipt Server only cares about the 1% of the XFDL that contains the submission-related data. The Server completely ignores all the GUI-related items.

This Specification provides, to those filers who are interested, a basis for creating XFDL filings without the use of the PureEdge Viewer. The expectation is that software developers, working on behalf of filers, will construct software that will generate filings that can be successfully parsed by the EDGAR Receipt Server. These generated filings will only contain the minimum set of XFDL data needed by the Server, hence the term "Reduced Content Filing".

The benefits of reduced content are twofold. First, these smaller files require less bandwidth for upload to FWS and therefore should upload quicker. Second, the server-side parser can process the filing quicker since all the GUI fluff has been removed from the reduced file.

This specification, by itself, is not sufficient to generate correct reduced content filings. We assume the reader is already familiar with the various SEC form types, filing act requirements, and SEC syntax rules. The following documents provide additional filing information and provide a resource for the XFDL specification.

NOTE: Although we used the PureEdge product suite to develop the EDGAR electronic forms, PureEdge did not participate in this process. Do NOT contact PureEdge for information specific to the SEC form templates or this reduced content specification.

2. Organization of this Specification

The remaining sections of this specification provide the framework for successfully constructing a "reduced content" XFDL filing.

Section 3 provides an overview of the six XFDL templates to which this specification applies.

Section 4 provides general rules concerning the XFDL file being created.

Section 5 details the specific rules for each type of XFDL node used to pass data to the EDGAR Server.

Section 6 describes a means of verifying that the structure of an XFDL file is correct. For example, you can use the described technique to find a missing end tag.

Section 7 describes the many appendices to this specification and how to use them. These appendices provide all the details concerning how to create a specific SEC form, which templates create which form types, and the set of valid values for several input fields.

Section 8 provides several examples (at least one for each template) of reduced content filings.

3. XFDL Templates

The six XFDL templates to which this Reduced Content Specification apply are:

NicknameFilename on FWSPurpose
Template1Subtemplate1.xfd107 submission types
Template2Subtemplate2.xfd128 submission types
Template3Subtemplate3.xfd148 submission types
Template4Subtemplate4.xfdCORRESPONDENCE submission
Template5Subtemplate5.xfdMODULE or SEGMENT submission
Template6Subtemplate6.xfdBULK submission

Template6 lets a filer collect multiple XFDL files created with the other five templates into a single bundle for a BULK submission. The only constraint here is that one BULK submission cannot include another BULK submission.

The controlled master versions of these templates that are available for download on the Filer Web site are saved in a PureEdge proprietary compressed file format. As such, they cannot be viewed or manipulated without the PureEdge Viewer. All submission files created via the Viewer are also saved in this same proprietary format.

The master templates are saved in this compressed format to improve file upload and download efficiency and as a measure of security.

XFDL forms are XML documents; the form definition is encoded using XML elements and attributes. The XFDL specification uses DTD notation to express nesting and sequence relationships between the elements and attributes; while the constraints on element contents and attribute values are given in the BNF notation found in the XML specification.

4. Reduced Content File Format

  1. A reduced content XFDL submission file must be ASCII text in either DOS or UNIX format.
    That is, lines must be terminated with either a carriage return and line feed (\r\n) or with just a line feed (\n). The PureEdge API does not support the Macintosh format of just a carriage return (\r).
  2. The PureEdge compression methodology is proprietary, so you can only compress a reduced content filing if you have access to the PureEdge Designer product.
    If you use the Designer to compress a submission, use ASCII compression rather than binary.
  3. A reduced content file cannot be digitally signed.
  4. A reduced content file name must end with either an .xfd or .frm extension.
    We recommend the .xfd extension, since several commercial software products use the .frm file type (for example, Visual Basic). Under Windows, a user may find the .frm file type already registered with another software program on his workstation.
  5. The names of attached document files must follow internal EDGAR file naming convention. The file naming convention is:
    • File names no longer than 32 characters, including the file extension.
    • Valid characters are lowercase letters, digits 0-9, up to one underscore, up to one hyphen, and up to one period.
    • First character must be a letter.
    • Spaces are not allowed.
    • File name must have a file type extension.
    • File extension must be .txt, .htm, .pdf, .fil, .jpg, or .gif
  6. Module and segment names referenced on page 4 of submissions must follow the internal EDGAR module/segment naming convention. The module/segment naming convention is:
    • Module/segment name must be no longer than 15 characters.
    • Valid characters are uppercase letters, digits 0-9, underscores, or hyphens (not periods).
    • First character must be a letter.
    • Spaces are not allowed.
  7. Date values can be specified in one of these formats:
    • MM/DD/YY 10/10/01
    • MM/DD/YYYY 10/10/2001
    • MM-DD-YY 10-10-01
    • MM-DD-YYYY 10-10-2001
    • MMM DD, YY October 10, 01
    • MMM DD, YYYY October 10, 2001

5. Reduced Content XFDL Elements

An XFDL scope identifier, or sid, uniquely identifies an element within the scope of its logical parent. An XFDL element may have a sid attribute which uniquely identifies the form within a system of forms in a large deployment. Each page element must have a sid attribute that uniquely identifies the page within the surrounding XFDL form element. An item element must have a sid attribute that uniquely identifies the item within the surrounding page element. The minimal set of XFDL elements required to create reduced content submissions are discussed in the following sections. Other XFDL elements used in the master EDGAR XFDL templates, such as those for GUI rendering, are not discussed.

NOTE: The following reduced content element definitions use example data to illustrate typical values. Remember to change these values as required when creating a reduced content filing. Valid values are provided where only a few are possible.

5.1 Version Nodes

Two version tags must be included as the first two lines of each submission. The current valid values are:

<?xml version="1.0"?>
<XFDL version="4.3.0">

5.2 End XFDL Node

To properly end a submission, this tag must be the last line of the submission.


5.3 Page Nodes

The <page> nodes are critical to EDGAR server-side processing and must be included. These pages contain the following data:

PageDescriptionTemplate1Template2 Template3Template4Template5Template6

1Header Dataxxxxx 
2 Enclosed Documents x x x x x x
3 Notification Data x x x x x  
4 Module/Segment References x x x x    
5 Offset Payments x x        
6 Offering Data x x        
7 Sales Shares Data x          

The rules governing the <page> nodes are:

  1. Valid values for a <page> sid are "PAGE1", "PAGE2", "PAGE3", "PAGE4", "PAGE5", "PAGE6", and "PAGE7".
  2. Pages must appear in sequential order, starting at PAGE1.
  3. All nodes except the two version nodes described in section 7.1 must be bounded by <page sid= > </page> nodes.
  4. You may completely exclude a page if none of the fields on that page contain any data.
    For example, if an S-1 submission has no module or segment references, the reduced content file does not need to contain a PAGE4.

5.4 Valid Scope (Node) Identifiers

This section lists the valid node, or scope (sid), identifiers as of EDGAR version 8.2. Only these sid's may be included in a submission. If any other sid is detected during processing, the EDGAR Receipt server will suspend the submission.

Appendix II provides a more detailed breakout of the valid sid's by Template and Page. The tables provided here are just alphabetical listings of the valid 8.2 sid's.

5.4.1 Valid Edgar 8.2 Scope Identifiers (sid's)





































































5.5 Submission Data Nodes

All data related to the submission is stored in five types of XFDL nodes. These five node types are:

<field>Text Field in the Viewer
<check>Checkbox in the Viewer
<radio>Radio Button in the Viewer
<popup>Popup in the Viewer
<combobox>  Combo Box in the Viewer

The rules for specifying one of these nodes are:

  1. The server-side parser is case-sensitive. You must use the sid names and valid values prescribed in the appendices and the attached master templates when constructing these nodes.
  2. A node must have a unique sid and a <value>.
    <field sid="SubTable_submissionType_"><value>S-1</value></field>
  3. The <value> tag is optional if a field has no value. However, we suggest including the <value></value> tag for consistency.
  4. A <value> node may only contain a single data item.
  5. The sid for these nodes must be of the form:
    The className and tagName portions must exactly match the names provided in the Appendices and the underscores must always be present. Append the recordNumber to a sid only when you need to report multiple values for a particular category of data, e.g., SRO values. The recordNumber is simply an increasing integer number used to uniquely identify the multiple values for a particular field. The first instance of any field does not get a recordNumber; zero is implied. The second instance gets a recordNumber of 1, the third instance a recordNumber of 2, and so on. A couple of examples will make this clear.
    For a field that has only a single value, such as the Submission Type combobox, the sid for the node will not have a recordNumber component. For this example, the node sid (field name) will be:
    SubTable_submissionType_    (the trailing underscore must be present)
    To report multiple values for a particular field, use the recordNumber to differentiate these values. For example, to report three SRO values, you would create these three node sid's:
  6. White space between nodes is ignored. These two specifications are equivalent.
    <field sid="SubTable_submissionType_"><value>S-1</value></field>
    <field sid="SubTable_submissionType_">
  7. The order of the nodes within a page only matters in two cases.
    1. For an enclosed document in Templates 1, 2, 3, 4, and 6,
      SubDocument_conformedName_ must precede the document's <data> node.
    2. For an enclosed document in Template 5,
      SubModSeg_ModSegFileName_ must precede the document's <data> node.
  8. The ampersand (&) and left angle bracket (<) are not permitted in character data content of XML elements. If there is a need to include these characters in character data, such as a value, you must enclose the character data in a CDATA section. For example, a value for a form name which contains an embedded ampersand would need to be expressed as:

    <value><![CDATA[EX-99.2I O&D BENEFTS]]></value>

5.6 Field Nodes

The only information required for a <field> node is a valid name and <value>. Appendix I lists all valid text field names.

<field sid="SubFiler_filerId_">

5.7 Checkbox Nodes

The only information required for a <check> node is a valid name and a <value>. Appendix I lists all valid checkbox names. Recommend always including a <value> tag for consistency. This prevents a scenario where a checkbox is mandatory but the user provides no value. The only valid values for a <check> node are "on" and "off".

<check sid="SubFlag_confirmingCopyFlag_">

5.8 Radio Button Nodes

The minimum information required for a <radio> node is a valid name and <value>. Valid values are "on" and "off". The only radio button in any of the templates is used to indicate if the submission is LIVE or TEST. A value of "on" means it is a LIVE submission. A value of "off" means it is a TEST submission. Recommend always including a <value> tag for consistency. The only valid values for a <radio> node are "on" and "off".

<radio sid=" SubTable_live_">

5.9 Popup Nodes

The only information required for a <popup> node is a valid name and <value>. Appendices IX - XIII list the valid values for all <popup> nodes.

<popup sid="SubFiler_formType_">

5.10 Combobox Nodes

The only information required for a <combobox> node is a valid name and <value>. Appendices IX - XIII list the valid values for all <combobox> nodes.

<combobox sid="SubTable_submissionType_">

5.11 Data Nodes - (Enclosed Documents)

Each document enclosed on Page 2 of the submission must have a <data> node of the following format:

<data sid="data1">








You may supply whatever you want as the sid for a data node, just as long as it is a valid XML name and it is unique to PAGE2 of the submission.

The <filename> is really the key item when defining a data node. It is the link to the SubDocument_conformedName_ or SubModSeg_ModSegFileName_ field that corresponds to this data node.

The <mimedata> block contains the MIME encoded document. A document must be encoded before you put it into the submission file. The MIME algorithm used by the PureEdge product is not proprietary, so any standard 64-character set based MIME encoding algorithm can be used.

Section 8.7 of this specification is a sample CORRESPONDENCE submission with one enclosed document. Section 8.9 is a sample BULK submission with three enclosed documents. In the case of bulk submissions using Template6, each enclosed MIME document is a complete XFDL submission file.

6. Verifying Reduced Content Structure

To verify that a Reduced Content file does not contain any structural errors, you can simply take advantage of the fact that the file is really XML. To verify the content:

  1. Rename the file, giving it an .xml suffix.
  2. Open the file in your browser.
  3. If the file contains structural errors, the browser will give you the offending line numbers.

7. How to use Appendices

Click Here To Download the Appendices
(MS Excel spreadsheet: approx. 188 KB)

Changes to Reduced Content Specification: Changes to the EDGAR 8.2 software have necessitated that changes be made to the associated reduced content specification appendices. The changes are red-lined (identified by strikethrough and bold, italicized fonts) in the attached xfdlappendix82.xls document. All developers that use this specification will need to download the file update to ensure any development work is consistent with the aforementioned changes.

This specification contains several appendices that define what is required for each electronic SEC form. These appendices are:

  1. Appendix I is a mapping of all EDGAR form types to the submission templates.
  2. Appendix II is a complete list of all the unique sid's used in the six submission templates.
    You should never have a sid that is not in this list in a reduced content file. This list also provides, for each sid, the node type (field, popup, combobox, check, or radio), a mapping of the node to the template(s) that use it, and whether the node is repeatable.
  3. Appendices III - VIII show which PAGE1 header fields, or sid's, are applicable to each form type for Templates 1 thru 6.

    Appendix IIITemplate1 form-type field dependencies
    Appendix IVTemplate2 form-type field dependencies
    Appendix VTemplate3 form-type field dependencies
    Appendix VITemplate4 form-type field dependencies
    Appendix VIITemplate5 form-type field dependencies
    Appendix VIII   Template6 form-type field dependencies

    The following table explains the numeric codes that appear in the matrices in these six appendices.

    Code Status

    1 Required
    2 Conditionally Required (if any field in group has a value, all fields in the group must have a value)
    3 When specifying a SubOffering entry, both the securityName and aggregatePrice are Required. The offeringShares and offeringAmountPerShare fields are optional.
    4 Optional
    5 Required for a confirming copy submission (i.e. for electronic submissions which are copies of official filings made in paper under a hardship exemption)

    The fields in Appendix II that have one of these numbers assigned are not included in Appendices III - VIII. These appendices only indicate which of a template's conditional fields are applicable to each form type handled by the template.
    To determine the complete set of valid sid's for a given form type, you must refer to both Appendix II as well as one of these template-specific Appendices.
  4. Appendices IX - XIII show the valid values for the <field>, <combobox>, and <popup> nodes that are limited to a set of prescribed values.

    Appendix IXTemplate1 choice lists
    Appendix XTemplate2 choice lists
    Appendix XITemplate3 choice lists
    Appendix XIITemplate4 choice lists
    Appendix XIIITemplate5 choice lists

Click Here To Continue Reading the Specification
(go to "8. Sample Forms")



Modified: 05/03/2002