Form 485BXT Files Dataset

The Form 485BXT Files Dataset packages every Form 485BXT post-effective amendment filed to EDGAR by registered investment companies from September 1996 to the present. Form 485BXT is a procedural amendment filed under Rule 485(b)(1)(iii) of the Securities Act of 1933 by mutual fund trusts, ETF trusts, and insurance company separate accounts to designate a new effective date for a previously filed Rule 485(a) post-effective amendment — a scheduling tool used when staff comments on the underlying amendment cannot be cleared in time, or when fund complexes need to align effective dates across series, share classes, or related trusts. Each record corresponds to one EDGAR submission under a unique accession number, materialized as an accession folder containing a structured metadata.json describing the EDGAR submission header and a primary .htm document carrying the Form N-1A (or N-2/N-3/N-4/N-6/N-14) facing page wrapped in EDGAR's SGML envelope. The dataset is distributed as a ZIP archive grouped into one monthly container per calendar month, with file types TXT, JSON, HTML, and PDF.

Update Frequency
Daily
Updated at
2026-05-09
Earliest Sample Date
1996-09-01
Total Size
265.8 MB
Total Records
38,311
Container Format
ZIP
Content Types
TXT, JSON, HTML, PDF
Form Types
485BXT

Dataset APIs

Programmatically retrieve the full list of dataset archive files, download URLs and dataset metadata.

Dataset Index JSON API

Download the entire dataset as a single archive file.

Download Entire Dataset:

Download a single container file (e.g. monthly archive) from the dataset.

Download Single Container:

Dataset Files

351 files · 265.8 MB
Download All
2026-05.zip683.8 KB243 records
2026-04.zip2.0 MB820 records
2026-03.zip2.2 MB491 records
2026-02.zip2.3 MB517 records
2026-01.zip2.5 MB541 records
2025-12.zip1.8 MB380 records
2025-11.zip1.5 MB236 records
2025-10.zip932.0 KB197 records
2025-09.zip849.1 KB191 records
2025-08.zip837.2 KB184 records
2025-07.zip797.9 KB166 records
2025-06.zip788.2 KB150 records
2025-05.zip893.0 KB166 records
2025-04.zip973.2 KB171 records
2025-03.zip935.0 KB189 records
2025-02.zip833.2 KB181 records
2025-01.zip786.4 KB150 records
2024-12.zip807.4 KB142 records
2024-11.zip650.8 KB140 records
2024-10.zip934.3 KB190 records
2024-09.zip927.1 KB193 records
2024-08.zip929.3 KB193 records
2024-07.zip669.5 KB138 records
2024-06.zip1.1 MB131 records
2024-05.zip598.2 KB121 records
2024-04.zip683.4 KB134 records
2024-03.zip658.7 KB139 records
2024-02.zip774.2 KB147 records
2024-01.zip741.3 KB158 records
2023-12.zip592.3 KB120 records
2023-11.zip726.5 KB157 records
2023-10.zip881.0 KB177 records
2023-09.zip880.1 KB173 records
2023-08.zip891.6 KB176 records
2023-07.zip731.1 KB135 records
2023-06.zip1.3 MB147 records
2023-05.zip1.8 MB156 records
2023-04.zip1.2 MB146 records
2023-03.zip768.8 KB151 records
2023-02.zip615.3 KB117 records
2023-01.zip695.3 KB138 records
2022-12.zip852.9 KB167 records
2022-11.zip865.1 KB144 records
2022-10.zip671.9 KB135 records
2022-09.zip788.8 KB154 records
2022-08.zip692.5 KB153 records
2022-07.zip711.5 KB149 records
2022-06.zip817.0 KB153 records
2022-05.zip820.0 KB133 records
2022-04.zip1.3 MB218 records
2022-03.zip3.8 MB258 records
2022-02.zip1.4 MB187 records
2022-01.zip2.2 MB186 records
2021-12.zip2.3 MB207 records
2021-11.zip1.5 MB162 records
2021-10.zip949.7 KB165 records
2021-09.zip1.1 MB170 records
2021-08.zip807.2 KB151 records
2021-07.zip855.2 KB160 records
2021-06.zip1.4 MB176 records
2021-05.zip622.0 KB117 records
2021-04.zip1.6 MB211 records
2021-03.zip993.2 KB196 records
2021-02.zip828.4 KB158 records
2021-01.zip1.1 MB163 records
2020-12.zip966.8 KB159 records
2020-11.zip851.3 KB122 records
2020-10.zip674.9 KB120 records
2020-09.zip669.5 KB121 records
2020-08.zip648.6 KB117 records
2020-07.zip743.5 KB126 records
2020-06.zip666.3 KB111 records
2020-05.zip660.8 KB112 records
2020-04.zip711.2 KB128 records
2020-03.zip442.4 KB93 records
2020-02.zip505.1 KB108 records
2020-01.zip555.5 KB116 records
2019-12.zip487.9 KB106 records
2019-11.zip495.9 KB103 records
2019-10.zip619.5 KB128 records
2019-09.zip456.9 KB92 records
2019-08.zip558.8 KB112 records
2019-07.zip427.6 KB88 records
2019-06.zip462.1 KB96 records
2019-05.zip670.2 KB144 records
2019-04.zip609.2 KB122 records
2019-03.zip624.2 KB115 records
2019-02.zip578.8 KB106 records
2019-01.zip591.3 KB112 records
2018-12.zip782.5 KB138 records
2018-11.zip573.1 KB115 records
2018-10.zip537.5 KB118 records
2018-09.zip531.0 KB111 records
2018-08.zip636.4 KB133 records
2018-07.zip499.1 KB107 records
2018-06.zip1.2 MB149 records
2018-05.zip1.2 MB182 records
2018-04.zip1.2 MB202 records
2018-03.zip1.0 MB199 records
2018-02.zip837.7 KB174 records
2018-01.zip840.9 KB178 records
2017-12.zip905.8 KB179 records
2017-11.zip943.2 KB185 records
2017-10.zip1.1 MB201 records
2017-09.zip1.3 MB210 records
2017-08.zip1.1 MB217 records
2017-07.zip835.9 KB170 records
2017-06.zip1.0 MB219 records
2017-05.zip1.5 MB198 records
2017-04.zip1.0 MB201 records
2017-03.zip1.2 MB249 records
2017-02.zip861.1 KB178 records
2017-01.zip861.2 KB155 records
2016-12.zip1.4 MB226 records
2016-11.zip718.6 KB152 records
2016-10.zip846.1 KB155 records
2016-09.zip935.2 KB170 records
2016-08.zip959.6 KB196 records
2016-07.zip829.2 KB165 records
2016-06.zip1.3 MB210 records
2016-05.zip825.2 KB163 records
2016-04.zip13.0 MB270 records
2016-03.zip1.2 MB239 records
2016-02.zip1.3 MB213 records
2016-01.zip1.1 MB214 records
2015-12.zip1.2 MB218 records
2015-11.zip894.7 KB188 records
2015-10.zip1.0 MB201 records
2015-09.zip756.9 KB166 records
2015-08.zip1.2 MB191 records
2015-07.zip835.1 KB174 records
2015-06.zip909.2 KB186 records
2015-05.zip780.7 KB175 records
2015-04.zip1.0 MB207 records
2015-03.zip838.8 KB183 records
2015-02.zip602.7 KB136 records
2015-01.zip843.1 KB171 records
2014-12.zip884.9 KB198 records
2014-11.zip732.4 KB160 records
2014-10.zip939.2 KB203 records
2014-09.zip812.0 KB174 records
2014-08.zip767.2 KB165 records
2014-07.zip927.1 KB200 records
2014-06.zip831.6 KB176 records
2014-05.zip704.3 KB161 records
2014-04.zip1.2 MB202 records
2014-03.zip831.9 KB170 records
2014-02.zip577.8 KB121 records
2014-01.zip707.0 KB146 records
2013-12.zip1.3 MB158 records
2013-11.zip634.5 KB137 records
2013-10.zip760.4 KB123 records
2013-09.zip655.8 KB141 records
2013-08.zip858.4 KB150 records
2013-07.zip728.1 KB138 records
2013-06.zip823.8 KB155 records
2013-05.zip813.6 KB187 records
2013-04.zip894.4 KB201 records
2013-03.zip944.7 KB177 records
2013-02.zip665.8 KB136 records
2013-01.zip537.2 KB123 records
2012-12.zip525.3 KB121 records
2012-11.zip570.0 KB127 records
2012-10.zip644.6 KB95 records
2012-09.zip508.7 KB110 records
2012-08.zip687.7 KB126 records
2012-07.zip642.4 KB114 records
2012-06.zip784.3 KB131 records
2012-05.zip538.8 KB113 records
2012-04.zip944.2 KB178 records
2012-03.zip681.1 KB150 records
2012-02.zip3.2 MB172 records
2012-01.zip613.3 KB112 records
2011-12.zip818.2 KB147 records
2011-11.zip760.9 KB136 records
2011-10.zip661.0 KB132 records
2011-09.zip553.4 KB112 records
2011-08.zip546.4 KB105 records
2011-07.zip331.4 KB78 records
2011-06.zip360.6 KB75 records
2011-05.zip389.6 KB86 records
2011-04.zip720.7 KB136 records
2011-03.zip480.6 KB99 records
2011-02.zip347.6 KB69 records
2011-01.zip415.0 KB62 records
2010-12.zip485.4 KB99 records
2010-11.zip385.9 KB66 records
2010-10.zip454.6 KB64 records
2010-09.zip344.9 KB70 records
2010-08.zip359.7 KB69 records
2010-07.zip265.8 KB54 records
2010-06.zip266.3 KB49 records
2010-05.zip231.8 KB38 records
2010-04.zip1.1 MB149 records
2010-03.zip482.9 KB95 records
2010-02.zip765.7 KB106 records
2010-01.zip468.9 KB77 records
2009-12.zip683.1 KB88 records
2009-11.zip380.9 KB64 records
2009-10.zip571.9 KB78 records
2009-09.zip385.7 KB71 records
2009-08.zip809.4 KB113 records
2009-07.zip522.3 KB92 records
2009-06.zip699.7 KB49 records
2009-05.zip278.0 KB55 records
2009-04.zip580.5 KB93 records
2009-03.zip486.4 KB70 records
2009-02.zip600.8 KB85 records
2009-01.zip353.4 KB72 records
2008-12.zip386.8 KB72 records
2008-11.zip352.9 KB64 records
2008-10.zip1.9 MB89 records
2008-09.zip342.6 KB70 records
2008-08.zip331.2 KB63 records
2008-07.zip635.6 KB81 records
2008-06.zip506.9 KB63 records
2008-05.zip253.8 KB44 records
2008-04.zip3.1 MB149 records
2008-03.zip832.5 KB86 records
2008-02.zip417.1 KB84 records
2008-01.zip218.0 KB40 records
2007-12.zip409.0 KB44 records
2007-11.zip369.9 KB61 records
2007-10.zip217.7 KB41 records
2007-09.zip534.1 KB35 records
2007-08.zip201.9 KB26 records
2007-07.zip374.1 KB32 records
2007-06.zip336.6 KB36 records
2007-05.zip225.5 KB34 records
2007-04.zip805.9 KB67 records
2007-03.zip550.4 KB54 records
2007-02.zip210.1 KB32 records
2007-01.zip320.8 KB44 records
2006-12.zip383.1 KB54 records
2006-11.zip304.1 KB40 records
2006-10.zip795.9 KB44 records
2006-09.zip456.1 KB48 records
2006-08.zip256.7 KB29 records
2006-07.zip99.0 KB17 records
2006-06.zip415.2 KB37 records
2006-05.zip873.9 KB45 records
2006-04.zip2.7 MB138 records
2006-03.zip242.9 KB30 records
2006-02.zip109.2 KB20 records
2006-01.zip120.7 KB23 records
2005-12.zip713.8 KB40 records
2005-11.zip247.0 KB30 records
2005-10.zip573.7 KB57 records
2005-09.zip883.0 KB85 records
2005-08.zip347.2 KB32 records
2005-07.zip1.6 MB83 records
2005-06.zip134.8 KB17 records
2005-05.zip195.8 KB12 records
2005-04.zip7.5 MB388 records
2005-03.zip2.2 MB139 records
2005-02.zip3.9 MB103 records
2005-01.zip855.1 KB48 records
2004-12.zip582.0 KB38 records
2004-11.zip386.0 KB27 records
2004-10.zip588.7 KB93 records
2004-09.zip201.4 KB31 records
2004-08.zip189.1 KB22 records
2004-07.zip132.4 KB18 records
2004-06.zip333.7 KB22 records
2004-05.zip237.4 KB17 records
2004-04.zip1.6 MB83 records
2004-03.zip223.5 KB19 records
2004-02.zip3.3 MB210 records
2004-01.zip319.0 KB29 records
2003-12.zip107.1 KB26 records
2003-11.zip64.9 KB17 records
2003-10.zip1.1 MB22 records
2003-09.zip98.3 KB16 records
2003-08.zip641.4 KB50 records
2003-07.zip286.0 KB32 records
2003-06.zip217.9 KB7 records
2003-05.zip164.3 KB8 records
2003-04.zip774.7 KB140 records
2003-03.zip101.4 KB21 records
2003-02.zip286.8 KB28 records
2003-01.zip242.9 KB10 records
2002-12.zip712.1 KB35 records
2002-11.zip1.0 MB28 records
2002-10.zip416.1 KB27 records
2002-09.zip1.1 MB50 records
2002-08.zip290.1 KB15 records
2002-07.zip571.7 KB28 records
2002-06.zip153.2 KB6 records
2002-05.zip144.9 KB3 records
2002-04.zip1.8 MB62 records
2002-03.zip62.4 KB16 records
2002-02.zip547.7 KB49 records
2002-01.zip534.6 KB46 records
2001-12.zip696.5 KB25 records
2001-11.zip897.0 KB25 records
2001-10.zip488.9 KB12 records
2001-09.zip609.3 KB44 records
2001-08.zip508.4 KB45 records
2001-07.zip54.8 KB12 records
2001-06.zip43.2 KB10 records
2001-05.zip229.6 KB24 records
2001-04.zip1.1 MB72 records
2001-03.zip500.0 KB103 records
2001-02.zip229.9 KB20 records
2001-01.zip45.5 KB15 records
2000-12.zip425.3 KB29 records
2000-11.zip177.0 KB20 records
2000-10.zip137.3 KB23 records
2000-09.zip33.8 KB9 records
2000-08.zip553.9 KB56 records
2000-07.zip52.6 KB11 records
2000-06.zip45.9 KB9 records
2000-05.zip121.2 KB12 records
2000-04.zip191.2 KB13 records
2000-03.zip56.7 KB11 records
2000-02.zip126.0 KB7 records
2000-01.zip624.9 KB51 records
1999-12.zip321.1 KB23 records
1999-11.zip922.2 KB39 records
1999-10.zip1.3 MB42 records
1999-09.zip164.1 KB25 records
1999-08.zip32.1 KB5 records
1999-07.zip84.5 KB9 records
1999-06.zip209.1 KB21 records
1999-05.zip7.5 KB3 records
1999-04.zip798.5 KB63 records
1999-03.zip52.4 KB22 records
1999-02.zip68.1 KB15 records
1999-01.zip274.4 KB59 records
1998-12.zip257.0 KB38 records
1998-11.zip108.9 KB14 records
1998-10.zip117.2 KB22 records
1998-09.zip116.6 KB23 records
1998-08.zip238.2 KB22 records
1998-07.zip596.9 KB86 records
1998-06.zip356.4 KB26 records
1998-04.zip80.8 KB11 records
1998-03.zip6.1 KB2 records
1998-02.zip63.0 KB3 records
1998-01.zip11.1 KB1 records
1997-12.zip22.7 KB3 records
1997-11.zip59.3 KB7 records
1997-10.zip3.2 KB1 records
1997-08.zip265.7 KB17 records
1997-04.zip6.3 KB2 records
1997-03.zip120.3 KB2 records
1997-02.zip22.0 KB3 records
1997-01.zip24.2 KB6 records
1996-12.zip136.2 KB2 records
1996-11.zip3.6 KB1 records
1996-09.zip4.6 KB1 records

What This Dataset Contains

The Form 485BXT Files Dataset is built from the universe of EDGAR submissions whose form type is 485BXT — the post-effective amendment to a Securities Act registration statement filed pursuant to Rule 485(b)(1)(iii). Form 485BXT is itself administrative in character: it does not republish the prospectus or the statement of additional information, but instead carries a facing page that re-designates the effective date of an earlier Rule 485(a) post-effective amendment, identifies that prior amendment by number and filing date, and is signed by trust officers. The substantive prospectus and SAI content remain housed in the underlying 485(a) amendment to which the 485BXT relates.

The dataset covers all Form 485BXT filings submitted to EDGAR from September 1996 — coinciding with mandatory EDGAR filing for investment companies — to the present. For each accession number the archive includes a metadata file and all documents in the original EDGAR submission except image files; image binaries (entries of type GRAPHIC) are stripped, while their EDGAR URLs remain inside metadata.json for retrieval. Records are grouped chronologically into one ZIP per calendar month under a year directory, producing the path shape <year>/<year>-<month>.zip -> <year>-<month>/<accession>/. The container format is ZIP and the file types found in the dataset are TXT, JSON, HTML, and PDF, accommodating older ASCII submissions and any auxiliary PDF documents alongside the universal metadata.json and the modern .htm primary document.

Content Structure of a Single Record

What one record represents

A single record in the Form 485BXT Files Dataset corresponds to one EDGAR submission of Form 485BXT under a unique accession number. Each record is materialized as one folder named with the 18-digit, zero-padded accession number with the dashes stripped (for example 000182912625004769, which corresponds to EDGAR accession 0001829126-25-004769). Inside that folder are exactly two files: a structured metadata.json describing the EDGAR submission header and document inventory, and a single primary .htm document that carries the Form 485BXT facing-page content wrapped in EDGAR's SGML envelope.

One record therefore equals one filing event, not one fund, not one share class, and not one registration statement. A single 485BXT may, however, designate a new effective date for a post-effective amendment that simultaneously covers many fund series and many share classes belonging to the same registrant trust; the per-record metadata.json enumerates all of those series and class identifiers under the same accession.

What the underlying filing is

Form 485BXT is a post-effective amendment to a registration statement filed by an open-end management investment company (typically a mutual fund trust, ETF trust, or unit investment trust) on Form N-1A, Form N-2, Form N-3, Form N-4, Form N-6, or Form N-14. The form is filed under Rule 485(b)(1)(iii) of the Securities Act of 1933, which permits a registrant that has previously filed a Rule 485(a) post-effective amendment to designate a new, later effective date for that earlier amendment. The mechanism is most often used to give the registrant additional time to negotiate SEC staff comments on the underlying 485(a) filing, to align prospectus effectiveness with a fiscal calendar, to coordinate the launch of new share classes or new series, or to delay an effective date that would otherwise occur automatically under the staggered effectiveness regime of Rule 485(a).

The 485BXT filing itself is administrative in character. It does not republish the prospectus or the statement of additional information; it consists chiefly of the Form N-1A (or N-2/N-3/N-4/N-6/N-14) facing page, the relevant pre-effective and post-effective amendment numbering, the explicit Rule 485(b)(1)(iii) designation of the new effective date, an identification of the prior 485(a) post-effective amendment being delayed, and a signature page. The substantive prospectus and SAI content remain housed in the underlying 485(a) amendment to which the 485BXT relates.

Two parallel layers of a record

Each record is built from two parallel layers:

  1. A machine-readable EDGAR submission-header layer in metadata.json carrying submission-level identifiers, filer entity information, fund series and class identifiers, the EDGAR document inventory, and canonical public URLs.
  2. A document layer consisting of one .htm file holding EDGAR's SGML <DOCUMENT> wrapper around the filer-rendered HTML of the Form N-1A (or sibling form) facing page.

There is no separate XBRL payload, no financial-data file, and no separate exhibit document. Image binaries that may be referenced from the EDGAR filing-index page (typically logos, signature graphics, or scanned exhibits tagged as GRAPHIC in the document inventory) are intentionally excluded from the archived record; only their URL references remain inside metadata.json. The complete-submission .txt SGML wrapper produced by EDGAR's submission system is likewise not packaged as a separate file inside the record, although its public URL is exposed via linkToTxt.

The accession folder

The folder is the unit of a record. Its name is purely numeric (the 18-digit accession with dashes removed) and serves as the join key both to the dashed accessionNo inside metadata.json and to the linkToFilingDetails URL on sec.gov/Archives/edgar/data/<cik>/<accession-digits>/. There is no nested directory structure beneath the accession folder.

metadata.json

metadata.json is a single JSON object that describes the filing at the level EDGAR's submission header records it. The intentional fields are:

  • formType - the literal string "485BXT".
  • accessionNo - the EDGAR accession number in dashed form (e.g. "0001829126-25-004769").
  • description - the canonical human-readable form label, consistently "Form 485BXT - New effective date for post-effective amendment [Rule 485(b)(1)(iii)]".
  • filedAt - the ISO-8601 acceptance timestamp, including the EDGAR Eastern-time UTC offset (e.g. "2025-06-27T16:44:52-04:00").
  • linkToFilingDetails - URL of the primary 485BXT .htm document on sec.gov.
  • linkToTxt - URL of the full SGML submission wrapper on EDGAR.
  • linkToHtml - URL of the EDGAR filing-index HTML page for the accession.
  • linkToXbrl - empty string for this form, because Form 485BXT carries no XBRL payload.
  • id - a 32-character hexadecimal identifier internal to the dataset.
  • documentFormatFiles[] - an inventory of every document EDGAR registered as part of the original submission. Each element exposes sequence (string; may be " " for the SGML wrapper), size in bytes (string), documentUrl, description, and type. Typical type values are "485BXT" for the primary content document, "GRAPHIC" for image attachments referenced from inside the HTML, and " " for the complete-submission TXT wrapper itself.
  • dataFiles[] - inventory of structured/financial data files; consistently empty ([]) for this form.
  • entities[] - one or more filer entries. The same registrant frequently appears twice in this array, once with act: "40" (Investment Company Act of 1940 registration, file-number prefix 811-) and once with act: "33" (Securities Act of 1933 registration, file-number prefix 333-), because the post-effective amendment is filed against both registration statements simultaneously. Per-entity fields include companyName (suffixed with (Filer)), cik, fileNo, filmNo, irsNo (sometimes all zeros), stateOfIncorporation, act, type ("485BXT"), and optionally fiscalYearEnd (a four-digit MMDD string such as "0331" or "0531").
  • seriesAndClassesContractsInformation[] - the SEC's series-and-class taxonomy for fund offerings. Each element is a { series, name, classesContracts[] } triple where series is the SEC-assigned series identifier (S followed by nine digits), and each entry inside classesContracts[] is a { name, classContract } pair where classContract is the SEC-assigned class/contract identifier (C followed by nine digits). Class entries may additionally carry a ticker. A single 485BXT may enumerate anywhere from one series with one class to many series with multiple classes each, depending on how many funds the underlying registration statement covers.

The primary .htm document

The primary document is named by the filing agent (examples include bondbloxxetf_485bxt.htm, d944651d485bxt.htm, tm2517256d7_485bxt.htm, ea0247002-01_485bxt.htm, and the generic f485bxtfacingpage.htm); the only consistent convention is the .htm extension, often with the literal token 485bxt somewhere in the basename. Although the extension is .htm, the file is not pure HTML. It is wrapped in EDGAR's SGML document envelope:

1 <DOCUMENT>
2 <TYPE>485BXT
3 <SEQUENCE>1
4 <FILENAME>...
5 <DESCRIPTION>485BXT
6 <TEXT>
7 <HTML>...filer-rendered facing page...</HTML>
8 </TEXT>
9 </DOCUMENT>

The <TYPE>, <SEQUENCE>, <FILENAME>, and <DESCRIPTION> lines are EDGAR header tags inserted by the submission system; the actual prose lives inside <TEXT> as a self-contained HTML document. Inside that inner HTML, the content is structured as the facing page of a Form N-1A registration statement (or the analogous facing page of N-2, N-3, N-4, N-6, or N-14), and typically presents the following blocks in approximately this order:

  • A header line of the form "As filed with the Securities and Exchange Commission on <date>".
  • The Securities Act of 1933 file number (the 333- series) and the Investment Company Act of 1940 file number (the 811- series), often arranged in a left/right cap structure at the top of the page.
  • A title block identifying the United States Securities and Exchange Commission and Washington, D.C. as the recipient.
  • The form name (e.g. FORM N-1A) and the legend "REGISTRATION STATEMENT UNDER THE SECURITIES ACT OF 1933" and/or "REGISTRATION STATEMENT UNDER THE INVESTMENT COMPANY ACT OF 1940".
  • A checkbox-style enumeration of Pre-Effective Amendment numbers and Post-Effective Amendment numbers, with the appropriate numbers filled in (e.g. "Post-Effective Amendment No. 64" against the 1933 Act registration statement and "Amendment No. 67" against the 1940 Act registration statement).
  • The exact registrant name as it appears on the registration statement, the principal-executive-office address, the registrant's telephone number, and the name and address of the agent for service of process.
  • The substantive Rule 485(b)(1)(iii) language: a paragraph designating the new effective date for the previously filed Rule 485(a) post-effective amendment, identifying that prior amendment by number and filing date, and stating that the new effective date is being designated pursuant to Rule 485(b)(1)(iii).
  • An optional explanatory note describing the purpose of the redesignation (for example, additional time for staff review, alignment with a fiscal-year date, or coordination with a related filing).
  • A signature block executed by trust officers (commonly the principal executive officer and principal financial officer of the registrant), often accompanied by powers-of-attorney references to a previously filed registration-statement amendment.

Document length varies materially with the amount of cover-page boilerplate the filer chooses to include. Lean ETF facing pages can be on the order of tens of kilobytes, while filings from large fund complexes that incorporate fuller signature pages, explanatory notes, or extensive series tables can reach several hundred kilobytes. Markup style varies by filing agent: Donnelley/Toppan-style filings rely on dense inline <P STYLE="..."> paragraph formatting, while Workiva/RDG-style filings use <div style="..."> flow blocks with absolute positioning, but both produce semantically equivalent facing-page content.

What the dataset record includes

The record includes, for each accession:

  • The full structured EDGAR submission header in metadata.json, including filer identity (CIK, IRS number, state of incorporation), the dual 33/40 Act file-number registrations and corresponding film numbers, fund series and class identifiers with optional tickers, fiscal year end, the complete EDGAR document inventory, and the canonical public URLs for the filing index, the SGML submission, and the primary document.
  • The complete primary 485BXT .htm document with its EDGAR SGML wrapper intact, preserving both the EDGAR-injected <DOCUMENT> metadata lines and the filer's full inner HTML facing page.

What is excluded or structurally separate

  • Image binaries (entries of type GRAPHIC listed in documentFormatFiles[]) are stripped from the archived record. Their EDGAR URLs remain inside metadata.json for retrieval, but the bytes themselves are not packaged.
  • The complete-submission .txt SGML submission envelope wrapper produced by EDGAR (typically the entry whose type is " " in documentFormatFiles[]) is not carried as a separate file inside the record; only its URL is exposed via linkToTxt.
  • The underlying Rule 485(a) post-effective amendment that the 485BXT delays is a different EDGAR filing under a different accession number and is not bundled into this record. The 485BXT references that prior amendment only by amendment number and filing date.
  • The prospectus and statement of additional information themselves are not part of the 485BXT — they live with the related 485(a) or 485(b) effective filing.
  • There is no XBRL payload (linkToXbrl is empty and dataFiles[] is empty); risk/return summary XBRL, where it exists for a fund, is associated with the substantive prospectus filings, not with the administrative 485BXT designation.
  • Subsequent or superseding filings (e.g., a later 485BPOS that ultimately becomes effective, or another 485BXT that further redesignates the effective date) are separate accessions and are not linked from inside the record.

Stability of required content and structure

The substantive content required on a Form 485BXT facing page has been remarkably stable since Rule 485 was adopted in its modern form. The amendment-numbering convention, the dual 33/40 Act file-number presentation, the Rule 485(b)(1)(iii) designation paragraph, and the signature block have all persisted across the dataset's full coverage from the mid-1990s to the present. The most material structural change at the registrant-information layer was the introduction of SEC series and class identifiers (the S and C IDs) in 2006 under the EDGAR series-and-class reporting regime; for filings on or after that adoption, the seriesAndClassesContractsInformation[] block in metadata.json becomes populated, whereas earlier filings carry only registrant-level identifiers. Tickers within class entries became progressively more complete as filers populated the EDGAR class-ticker field. The form's amendment-numbering practice — separately tracking 1933 Act post-effective amendment numbers and 1940 Act amendment numbers on the same facing page — has not changed.

Format evolution of the primary document

EDGAR began accepting electronic Form 485BXT filings in the mid-1990s as plain ASCII text inside the SGML submission envelope, and through the late 1990s and into the early 2000s the primary document was typically delivered as a .txt body. Beginning in the early 2000s, filing agents shifted Form 485BXT primary documents to inline HTML wrapped in the same SGML <DOCUMENT> envelope, which is the convention that has dominated the dataset for the last two decades. Modern filings are almost exclusively .htm documents. The file-types found in the dataset are TXT, HTML, PDF, and JSON, accommodating older ASCII submissions and any auxiliary PDF documents that may appear in particular filings, alongside the universal metadata.json.

Throughout these format transitions the EDGAR SGML wrapper (the outer <DOCUMENT>/<TYPE>/<SEQUENCE>/<FILENAME>/<DESCRIPTION>/<TEXT> block) has remained the canonical container around the primary document body, so a parser that strips the SGML envelope first and then dispatches on the inner content type works uniformly across the time range. Form 485BXT carries no XBRL, so no inline XBRL transition is relevant to this record type.

Interpretation and extraction notes

  • The accession folder name and the dashed accessionNo inside metadata.json are the same identifier in two notations; either can be used to join records across systems.
  • A single registrant frequently appears twice in entities[] because the same trust is registered both under the Securities Act of 1933 (act "33", file-number prefix 333-) and under the Investment Company Act of 1940 (act "40", file-number prefix 811-). These are not duplicate filers; they are two distinct registration statements being amended simultaneously, each with its own fileNo and filmNo.
  • The seriesAndClassesContractsInformation[] array is the authoritative enumeration of which fund offerings the 485BXT covers. A single accession can span many series and many classes; treating one record as one fund will misrepresent multi-series amendments. Conversely, the absence of this block on older filings does not mean the filing covered no series — it means series/class IDs predated the EDGAR taxonomy.
  • Because the substance of a 485BXT is the redesignation of an effective date for a prior 485(a) filing, full interpretation of any record generally requires resolving the cross-reference to that earlier accession. The prior amendment is identified inside the inner HTML body (by amendment number and filing date) but is not stored as a structured field in metadata.json; the cross-reference must be parsed from the prose or matched on registrant CIK and amendment numbering.
  • The .htm extension on the primary document is misleading for naive HTML parsers: the file begins with EDGAR SGML header lines (<DOCUMENT>, <TYPE>, <SEQUENCE>, <FILENAME>, <DESCRIPTION>, <TEXT>) before the inner <HTML> element starts, and ends with the matching </TEXT></DOCUMENT> after </HTML>. Robust extraction should isolate the inner <TEXT>...</TEXT> region before applying HTML parsing.
  • Image attachments referenced inside the inner HTML may resolve to URLs that point back to sec.gov rather than to local files inside the accession folder, because graphic binaries are deliberately excluded from the archive. Resolving those references requires fetching from EDGAR.
  • Filing-agent variation in HTML markup (Donnelley/Toppan inline-paragraph styles versus Workiva/RDG flow-and-position styles) does not change the semantics of the facing page but does affect reliable text extraction; rendering the HTML and then extracting text is generally more stable than parsing styled paragraph blocks directly.
  • A 485BXT that is itself superseded or further redesignated by another 485BXT, or that is ultimately replaced by an effective 485BPOS, is visible only by comparing successive accessions for the same registrant and the same underlying 485(a) — there is no in-record forward link to later filings.

Who Files or Publishes This Dataset, and When

Who files the record

Each Form 485BXT is filed by a registered investment company — the registrant on whose registration statement the underlying amendment was filed — for the sole purpose of designating a new effective date for a previously filed Rule 485(a) post-effective amendment. The filer is the trust, corporation, or separate account that holds the registration statement, acting through its officers and counsel. The filing is procedural: it does not introduce new prospectus disclosure, it controls when an earlier 485APOS becomes effective. Each 485BXT is therefore tied to a specific prior 485APOS and typically references that filing's accession number, file number, and proposed amendments.

Filer population

Form 485APOS filers are limited to investment companies eligible to use the Rule 485 regime under the Securities Act of 1933 and the Investment Company Act of 1940:

  • Open-end mutual funds registered on Form N-1A. This is the dominant population, driven by large fund families managing many series and share classes on a single registration statement.
  • Open-end ETFs, also registered on Form N-1A.
  • Insurance company separate accounts offering variable annuity and variable life contracts, registered on Form N-3, N-4, or N-6.

The legal filer is always the registrant. Investment advisers, sub-advisers, principal underwriters, insurance depositors, and individual portfolios discussed in the amendment are not filers of record, even when the delayed disclosure concerns them directly.

Closed-end funds, business development companies, and operating-company issuers do not use Rule 485 and do not produce 485BXT records. Closed-end interval funds with continuous offerings file under Rule 486 instead.

Triggering event and timing

Form 485BXT is filed under Rule 485(b)(1)(iii) of the Securities Act, which lets a registrant designate a new effective date for a previously filed 485APOS. A 485APOS otherwise becomes effective automatically 60 days after filing (or 75 days for amendments adding a new series). The 485BXT delays or relocates that automatic date.

The form is purely event-driven, with no periodic or calendar cadence. It arises only when a registrant has an outstanding 485APOS whose default effective date it wishes to move. Common triggers:

  • Unresolved SEC staff comments on the underlying 485APOS that cannot be cleared before automatic effectiveness.
  • Coordination across a fund complex to align effective dates for multiple series, share classes, or related trusts.
  • Operational and printing logistics, including alignment with composite prospectuses, summary prospectus delivery under Rule 498, or new share class launches.
  • Pending material developments such as board action, sub-adviser changes, fee restructurings, or fund reorganizations still being finalized.

Timing constraints:

  • A 485BXT must be filed after the related 485APOS but before that amendment's automatic effective date.
  • The newly designated date must comply with Rule 485(b)(1)(iii).
  • Multiple successive 485BXT filings against the same 485APOS are permitted if further re-designation is needed.

Filing volume across a fund complex tends to cluster around annual prospectus update cycles tied to fiscal year-end and the Section 10(a)(3) 120-day update obligation.

Important distinctions

  • 485BXT vs 485APOS vs 485BPOS. The 485APOS is the substantive amendment subject to staff review. The Form 485BPOS is the immediately effective amendment used for non-material updates or to bring a cleared 485APOS to final effectiveness. The 485BXT is neither: it only re-designates the effective date of a prior 485APOS.
  • No standalone disclosure value. A 485BXT is a pointer to the underlying 485APOS, not a source of new prospectus content. Substantive changes must be read from the referenced 485APOS and the eventual 485BPOS.
  • Filer versus affected parties. Sub-advisers, underwriters, insurance depositors, and individual portfolios are not filers of the 485BXT even when the delayed disclosure concerns them.
  • Excluded registrants. Closed-end funds, BDCs, and operating companies are systematically absent from this dataset because Rule 485 does not apply to them.
  • EDGAR coverage. Form 485BXT exists only in the EDGAR era; the dataset's earliest records (September 1996) coincide with mandatory EDGAR filing for investment companies, with no meaningful paper analog.

How This Dataset Differs From Similar Datasets or Filings

Form 485BXT serves a narrow procedural function under Rule 485(b)(1)(iii): redesignating the effective date of a previously filed post-effective amendment. It shares filer population with the rest of the 485-series and the underlying N-series registration statements, but its role is timing, not disclosure. The most useful comparisons are to the other 485 variants, the N-series originals they amend, and the Rule 497 definitive-materials family that follows effectiveness.

Form 485APOS (post-effective amendment under Rule 485(a))

485APOS is the substantive amendment that 485BXT exists to defer. It carries material prospectus or SAI changes — new strategies, fee changes, fund mergers, new share classes — and triggers an automatic 60-day (or longer) delayed effectiveness window for staff review.

485BXT carries no disclosure content. It is paired with a specific prior 485APOS (typically referencing its accession number) and only shifts when that amendment becomes effective. Use 485APOS for what changed; use 485BXT for when it takes effect.

Form 485BPOS (immediately effective amendment under Rule 485(b))

485BPOS is the standard annual update vehicle, effective immediately or on a near-term designated date because it contains only non-material changes (annual financials, conformity edits, or revisions previously cleared by staff). It carries the full updated prospectus and SAI.

The contrast with 485BXT is twofold: 485BPOS contains the substantive document and is filed under Rule 485(b)(1)(i)(ii); 485BXT contains no document and is filed solely under Rule 485(b)(1)(iii) to reset an effective date. Funds pushing out a routine annual update file 485BPOS; funds delaying a pending substantive amendment file 485BXT.

Forms 485A24E and 485B24E (Rule 24e-2 amendments)

These are the legacy Rule 24e-2 counterparts used to register additional shares for open-end funds before modernization of registration mechanics. They share the post-effective amendment lineage but operate under a different statute (Investment Company Act share-count registration, not Securities Act effective-date timing). They appear infrequently today and rarely overlap with 485BXT use cases.

Underlying N-1A, N-2, N-3, N-4, and N-6 registration statements

These are the foundational registration forms every 485-series filing amends — N-1A for open-end funds and most ETFs, N-2 for closed-end funds, N-3/N-4/N-6 for variable insurance separate accounts. They contain the complete prospectus, SAI, and Part C exhibits.

A 485BXT presupposes one of these as its base registration; it cannot exist without an effective N-series filing and a pending 485APOS to defer. To reconstruct current prospectus content, researchers need the N-series original plus the most recent effective 485BPOS or 485APOS. 485BXT alone reveals timing, never substance.

Form 497 (definitive materials under Rule 497)

Form 497 and its variants (497K summary prospectus, 497J certification) deliver the final investor-facing prospectus and sticker supplements after a registration or amendment becomes effective.

497 and 485BXT sit on opposite sides of effectiveness. 485BXT is pre-effectiveness scheduling; 497 is post-effectiveness delivery. A fund that defers a 485APOS via 485BXT will, once effective, follow up with 497 filings carrying the definitive text. The two are sequential, not substitutable.

Re-filing under Rule 485(a) versus filing 485BXT

A fund could withdraw a pending 485APOS and submit a fresh one, but that restarts the 60-day staff review clock and discards review progress already made. 485BXT preserves the existing 485APOS and ongoing staff dialogue while sliding the effective date forward — to accommodate unresolved comments, align with a fiscal-year boundary, coordinate with related fund launches, or sync with distribution timelines. It is the lightweight scheduling tool inside an otherwise heavy-review process.

Boundary summary

The Form 485BXT Files Dataset is distinct because it isolates a single procedurally narrow filing whose function is calendar management, not disclosure. It is event-driven rather than periodic, and always paired with a 485APOS that carries the actual content. It does not substitute for 485APOS or 485BPOS in reconstructing prospectus changes, for the N-series in establishing fund structure, or for Form 497 in capturing definitive investor materials. Its analytical value lies in tracing the timing and friction of fund registration amendments — staff-comment cycles, deferred effectiveness, and the choreography of mutual fund disclosure updates — not in the disclosures themselves.

Who Uses This Dataset

The Form 485BXT Files Dataset is consumed by specialists in fund registration mechanics who care about a small set of fields: the prior 485(a) accession reference, the new effective date, registrant CIK and series/class identifiers, and the gap between original and revised effectiveness.

'40 Act fund counsel

In-house and outside attorneys specializing in the Investment Company Act use the dataset as a precedent library when drafting their own 485BXT filings. They study cover-page conventions for citing the prior 485(a) amendment, accepted phrasing for new effective dates, and how peer registrants sequence multiple redesignations on a single registration statement. The cover page text and EDGAR header metadata are the load-bearing fields.

Fund compliance officers

CCOs and registration compliance staff at fund complexes track their own 485BXT history to measure how often prospectus updates slip past the originally designated effective date. The spread between the 485(a) date, the original effective date, and the new effective date set in 485BXT exposes weaknesses in internal drafting calendars and disclosure controls.

Filing operations at fund administrators

Filing agents and registration operations staff at third-party fund administrators prepare and transmit 485BXT filings on behalf of multiple fund clients under tight, comment-cycle-driven deadlines. They use the dataset to validate template accuracy, confirm header tag values, check date formatting against accepted EDGAR conventions, and reconcile internal filing calendars with what EDGAR actually accepted.

Product and registration project managers

Product managers launching new share classes, repricing fees, or reorganizing fund lineups use the dataset to set realistic launch timelines. Each 485BXT signals a delayed product change, so the filing date versus new effective date and the frequency of redesignations per registrant inform internal schedules and expectations communicated to distribution, marketing, and the board.

SEC staff and policy researchers

Examination, enforcement, and policy analysts use the dataset to study aggregate use of Rule 485(b)(1)(iii): frequency per registrant, repeated redesignations on the same 485(a), length of delay, and clustering around comment cycles. This supports examination scoping and rule-review work on Rule 485 mechanics.

Reference-data and prospectus-library vendors

Vendors maintaining fund reference databases and prospectus-status feeds parse 485BXT filings to refresh "prospectus effective as of" fields and linkage records between amendments. The metadata file, the new effective date, and the prior 485(a) accession reference drive downstream updates and subscriber notifications keyed to CIK and series.

Competitive-intelligence and fund analytics teams

Strategy teams at asset managers and consulting firms aggregate 485BXT filings by registrant, year, and underlying amendment type to estimate how much staff-comment friction peer complexes encounter and which product categories (index, alternatives, new asset classes) face the longest reviews. They typically join CIK, registrant name, filing date, and prior 485(a) reference to N-1A and 485APOS data.

Academic researchers on SEC review cycles

Finance, accounting, and law researchers treat 485BXT as a clean proxy for comment-driven delay, since its sole purpose is to redesignate an effective date. They construct review-duration measures, test which fund characteristics correlate with longer reviews, and track shifts across regulatory regimes using the dataset's near-three-decade span back to September 1996.

Across all these users the load-bearing fields are the same: registrant CIK and name, filing date, prior 485(a) accession reference, and the new designated effective date. Lawyers and compliance officers draft and supervise the filings, operations teams transmit them, product and analytics teams read them as friction signals, regulators and academics study the review process in aggregate, and data vendors keep downstream effective-date records aligned.

Specific Use Cases

The Form 485BXT Files Dataset supports a small set of operational and analytical workflows centered on fund registration timing. The use cases below tie directly to fields in metadata.json (filer CIK, series/class IDs, filedAt, prior 485(a) reference) and to the Rule 485(b)(1)(iii) designation paragraph inside the primary .htm facing page.

  • Building a fund-registration delay panel. Researchers and compliance analysts join accessionNo, filedAt, registrant CIK from entities[], and the prior 485(a) amendment number and filing date parsed from the inner HTML to compute the gap between originally designated and redesignated effective dates. The resulting panel is used to measure staff-comment friction per registrant and per fund family across the dataset's coverage from the mid-1990s onward.

  • Maintaining "prospectus effective as of" reference data. Reference-data vendors parse the new effective date from the Rule 485(b)(1)(iii) paragraph and use seriesAndClassesContractsInformation[] to fan that date out to every affected series ID (S followed by nine digits) and class ID (C followed by nine digits, with optional ticker). This refreshes downstream subscriber feeds keyed to CIK and series without waiting for the eventual 485BPOS.

  • Drafting precedent library for 485BXT filings. Outside fund counsel and filing agents query the dataset by registrant peer group to retrieve the inner <TEXT> HTML of facing pages, extracting accepted phrasing for the new-effective-date designation, the dual 333-/811- file-number cap structure, and the post-effective amendment numbering convention. They reuse these patterns when preparing their own 485BXT cover pages and signature blocks.

  • Monitoring repeated redesignations on the same 485(a). Examination staff and CCOs cluster filings by registrant CIK plus referenced prior 485(a) accession to detect cases where the same underlying amendment is delayed two or more times. The count of redesignations and total elapsed delay flags amendments with unusual staff-comment cycles for examination scoping or internal disclosure-controls review.

  • Reconciling EDGAR-accepted submissions against internal filing calendars. Filing operations teams at fund administrators diff the filedAt timestamp, formType, dual act: "33" / act: "40" entity entries, and documentFormatFiles[] inventory in metadata.json against their internal ticketing system to confirm each transmitted 485BXT was accepted with the correct amendment numbers and series coverage.

  • Estimating product-launch timing for new share classes. Product managers filter records where seriesAndClassesContractsInformation[] contains newly assigned class IDs or tickers and compute the distribution of delay between original and redesignated effective dates. The output calibrates realistic launch windows communicated to distribution, marketing, and the board for analogous future share-class rollouts.

Dataset Access

Dataset Index JSON API: https://api.sec-api.io/datasets/form-485bxt-files.json This endpoint returns dataset metadata including the name, description, last updated timestamp, earliest sample date (1996-09-01), total records and total size, covered form types (485BXT), container format (ZIP), and file types (TXT, JSON, HTML, PDF). It also returns the full dataset download URL and the list of monthly container files, each with its key, size, record count, updated timestamp, and download URL. Use this endpoint to monitor which containers were updated in the latest refresh run and decide on a daily basis which containers to download. This endpoint does not require an API key.

Example response:

Example
1 {
2 "datasetId": "1f13365b-9ae0-690a-95a0-53fd3a111f24",
3 "datasetDownloadUrl": "https://api.sec-api.io/datasets/form-485bxt-files.zip",
4 "name": "Form 485BXT Files Dataset",
5 "updatedAt": "2026-04-28T02:58:03.574Z",
6 "earliestSampleDate": "1996-09-01",
7 "totalRecords": 37940,
8 "totalSize": 264806586,
9 "formTypes": ["485BXT"],
10 "containerFormat": "ZIP",
11 "fileTypes": ["TXT", "JSON", "HTML", "PDF"],
12 "containers": [
13 {
14 "downloadUrl": "https://api.sec-api.io/datasets/form-485bxt-files/2026/2026-04.zip",
15 "key": "2026/2026-04.zip",
16 "size": 13818783,
17 "records": 154,
18 "updatedAt": "2026-04-28T02:58:03.574Z"
19 }
20 ]
21 }

Download Entire Dataset: https://api.sec-api.io/datasets/form-485bxt-files.zip?token=YOUR_API_KEY Downloads the complete Form 485BXT Files Dataset as a single ZIP archive containing all monthly containers from September 1996 to present. This endpoint requires an API key.

Download Single Container: https://api.sec-api.io/datasets/form-485bxt-files/2026/2026-04.zip?token=YOUR_API_KEY Downloads one monthly container ZIP, allowing you to retrieve only the filings for a specific month rather than the full dataset. This endpoint requires an API key.

Frequently Asked Questions

What form does this dataset cover?

The dataset covers Form 485BXT, a post-effective amendment to a registered investment company's registration statement filed pursuant to Rule 485(b)(1)(iii) of the Securities Act of 1933. Its sole purpose is to designate a new effective date for a previously filed Rule 485(a) post-effective amendment.

What does one record in this dataset represent?

One record corresponds to a single EDGAR submission of Form 485BXT under a unique accession number, materialized as one folder named with the 18-digit zero-padded accession number with dashes stripped. Each folder contains a metadata.json describing the EDGAR submission header and a primary .htm document carrying the Form N-1A (or sibling N-form) facing page wrapped in EDGAR's SGML envelope.

Who is required to file Form 485BXT?

Filers are registered investment companies eligible to use the Rule 485 regime: open-end mutual funds and ETFs registered on Form N-1A, and insurance company separate accounts registered on Form N-3, N-4, or N-6. Closed-end funds, business development companies, and operating-company issuers do not use Rule 485 and do not appear in the dataset.

When is Form 485BXT filed?

Form 485BXT is purely event-driven; it is filed after a 485APOS but before that amendment's automatic effective date (typically 60 days after filing, or 75 days for amendments adding a new series). Common triggers include unresolved SEC staff comments, coordination across a fund complex, prospectus printing logistics, and pending board or sub-adviser actions.

How does this dataset differ from the Form 485APOS or 485BPOS datasets?

485APOS is the substantive amendment carrying material prospectus or SAI changes; 485BPOS is the immediately effective amendment used for routine annual updates. 485BXT carries no disclosure content and is filed solely under Rule 485(b)(1)(iii) to reset the effective date of a prior 485APOS, so it should be used to study timing and friction in the registration cycle, not to reconstruct prospectus changes.

What time period does the dataset cover, and what file format is it distributed in?

The dataset covers all Form 485BXT filings submitted to EDGAR from September 1996 to the present, with September 1996 coinciding with mandatory EDGAR filing for investment companies. It is distributed as ZIP containers grouped one per calendar month under a year directory, and the file types found inside are TXT, JSON, HTML, and PDF.

Are image attachments and the underlying 485(a) amendment included?

No. Image binaries (entries of type GRAPHIC in documentFormatFiles[]) are stripped from the archive, though their EDGAR URLs remain inside metadata.json. The underlying Rule 485(a) post-effective amendment that the 485BXT delays is a separate EDGAR filing under a different accession and is not bundled into this record; the 485BXT references that prior amendment only by amendment number and filing date.