Form N14AE24 Files Dataset

The Form N14AE24 Files Dataset is a closed historical corpus of EDGAR filings made on the SEC submission types N14AE24 and N14AE24/A — the auto-effective Form N-14 registration statements (and their pre-effective amendments) used by open-end management investment companies to register shares issued in fund-to-fund business combinations under Rule 488 of the Securities Act and Section 24(f) of the Investment Company Act. Each record represents a single EDGAR submission keyed by accession number and bundles a structured metadata.json index together with the extracted plain-text bodies of every document in the original submission, with embedded image files omitted. Filers are registered open-end mutual funds — typically Massachusetts business trusts, Delaware statutory trusts, or Maryland corporations — acting as the acquiring fund issuing new shares to the shareholders of an acquired fund. The dataset covers a closed window from April 1994, when EDGAR was rolled out for fund filings, through January 1998, when the SEC retired the N14AE24 and N14AE24/A submission codes and migrated equivalent filings to the consolidated N-14 family. Containers are distributed as monthly ZIP archives carrying JSON and TXT files.

Dataset APIs

Dataset Files

What This Dataset Contains

The dataset captures every EDGAR submission filed under the N14AE24 and N14AE24/A codes during the form's full lifespan from April 1994 through January 1998. Form N-14 is the Securities Act registration statement used by open-end management investment companys (mutual funds) to register securities issued in business-combination transactions — most often fund mergers, fund reorganizations into a successor entity, and master-feeder restructurings. The N14AE24 submission type is the variant used when registration is auto-effective under Rule 488 of the Securities Act of 1933, with registration fees calculated under Section 24(f) of the Investment Company Act of 1940; such filings became effective automatically on the thirtieth day after filing without staff review, conditional on satisfying Rule 488(b)'s eligibility requirements. The N14AE24/A variant carries pre-effective amendments to those filings.

The substantive content of a Form N-14 is built around a combined prospectus and proxy statement that solicits target-fund shareholder approval of the reorganization while simultaneously serving as the disclosure document for the new shares to be issued. Around that core, the registration statement carries the standard cover page, contents/cross-reference sheet, Part B (statement of additional information), Part C (other information, undertakings, signatures, exhibit list), and an exhibit package that typically includes the agreement and plan of reorganization, opinions of counsel as to legality of the shares, tax opinions on the tax-free nature of the reorganization, consents of independent accountants, and pro forma and historical financial statements for both the acquiring and acquired funds.

The dataset is distributed as a hierarchy of monthly ZIP archives carrying JSON and TXT files. Because the form's lifespan ended before HTML filings became prevalent on EDGAR, document bodies are pre-HTML plain ASCII rather than HTML or PDF. The dataset is a closed historical corpus — no new records will be added under these submission codes.

Content Structure of a Single Record

What one record represents

One record in the Form N14AE24 Files Dataset is a single EDGAR submission of an auto-effective Form N-14 registration statement (form type N14AE24) or a pre-effective amendment to one (form type N14AE24/A), keyed by its EDGAR accession number. Each record bundles a structured metadata.json index together with the extracted plain-text bodies of the individual documents that made up the original submission, with embedded image files omitted. The unit of granularity is therefore the filing — not the underlying fund-reorganization transaction (a single business combination commonly produces multiple filings across the original statement and successive amendments) and not the individual exhibit document (those are sub-files inside one record).

Container and on-disk layout

The dataset is distributed as a hierarchy of monthly ZIP archives organized as YYYY/YYYY-MM.zip. Each ZIP, when expanded, yields a YYYY-MM/ directory containing one subfolder per filing in that calendar month. The subfolder name is the EDGAR digits-only accession number, zero-padded to eighteen digits — for example, accession 0000729968-97-000012 becomes folder 000072996897000012/. The hyphenated XXXXXXXXXX-YY-NNNNNN form appears only inside metadata.json and in the EDGAR URLs.

Inside each accession folder the file inventory is:

• exactly one metadata.json, the structured index of the filing, and
• one or more document-<sequence>.txt files, where <sequence> is the EDGAR document sequence number (1, 2, 3, ...) of the corresponding document inside the original submission.

The file-types found in the dataset are JSON and TXT. The form's lifespan ended before HTML filings became prevalent on EDGAR, so document bodies are pre-HTML plain ASCII rather than HTML or PDF. The number of document-<n>.txt files varies per record: minimal filings carry just document-1.txt (the Form N-14 itself with the prospectus/proxy embedded); richer filings add sequenced documents for the agreement and plan of reorganization, legal opinions, tax opinions, accountant consents, and financial statements.

metadata.json structure

The metadata file is the authoritative index for the record. Its top-level keys are:

• formType — "N14AE24" or "N14AE24/A".
• accessionNo — canonical hyphenated accession number (e.g. "0000729968-97-000012").
• linkToFilingDetails — URL of the EDGAR archive folder for the filer CIK.
• description — the static EDGAR descriptive label for the form type, e.g. "Form N14AE24/A - Registration statements of open end investment companies (business combinations): [Amend]".
• linkToTxt — URL of the original complete-submission .txt on EDGAR (the SGML envelope concatenating every document).
• linkToHtml — URL of the EDGAR *-index.htm landing page for the filing.
• linkToXbrl — empty string for every record; XBRL did not exist for this form era.
• filedAt — ISO 8601 filing timestamp with US/Eastern offset; the time-of-day component is typically 00:00:00 because EDGAR did not record sub-day filing times for this era.
• id — internal hash identifier for the record.
• documentFormatFiles — array describing every document in the EDGAR submission (see below).
• entities — array describing the registrant/filer header rows from the EDGAR submission (see below).
• seriesAndClassesContractsInformation — empty array; the EDGAR Series/Class identifier system was introduced after this form's discontinuation.
• dataFiles — empty array; no XBRL or other structured data files were attached to filings of this vintage.

documentFormatFiles[]

Each element corresponds to one document inside the EDGAR submission. The fields are:

• sequence — string "1", "2", ..., matching the EDGAR <SEQUENCE> tag in the submission SGML; one terminal row uses a single space " " to denote the synthetic complete-submission .txt row.
• size — byte size of the document on EDGAR, as a string.
• documentUrl — for sequenced documents, the CIK archive folder URL; for the complete-submission row, the full .txt URL.
• description — free-text label entered by the filer, e.g. "FORM N-14 POST-EFFECTIVE AMENDMENT #1", "KPMG TAX OPINION", "Complete submission text file". Often blank or absent.
• type — EDGAR document-type code: N14AE24 or N14AE24/A for the registration statement itself, or exhibit codes such as EX-8 (tax opinion), EX-5 (legal opinion), EX-23 (accountant consent), EX-99 (miscellaneous), and so on. The complete-submission row uses " " as type.

The on-disk document-<n>.txt corresponds to the row whose sequence equals <n>. The sequence: " " row is meta-only and is not extracted to a separate file in the ZIP — the complete-submission .txt exists only as a URL pointer back to EDGAR.

entities[]

Each element corresponds to one registrant/filer row in the EDGAR header. Multi-entity rows are common because a Form N-14 commonly identifies both the acquiring fund (filer) and the acquired fund (additional registrant), and corporate fund families frequently file as series of registrants. Fields:

• companyName — registrant name with the EDGAR header role appended in parentheses, e.g. "OPPENHEIMER MULTIPLE STRATEGIES FUND (Filer)".
• cik — numeric CIK as a string.
• irsNo — IRS Employer Identification Number; sometimes absent.
• fileNo — SEC file number assigned to the registration (e.g. "333-23867" for 1933 Act registrations).
• filmNo — SEC film number assigned at filing.
• type — entity-level form type, mirroring the top-level formType.
• act — Securities Act under which the filing is made; "33" (1933 Act) for these registration statements.
• stateOfIncorporation — two-letter US state code (commonly "MA", "MD", "DE").
• fiscalYearEnd — MMDD string.
• sic — SIC industry code as a string; for fund filings this is often "0000" and is sometimes absent.

How the Form N-14 content maps onto files

Within a record the document-to-file mapping follows the EDGAR sequence ordering used by the filer. The first document (document-1.txt) is almost always the Form N-14 itself, which internally carries:

• Cover page. The SEC cover-page boilerplate: form title FORM N-14, registration-act checkboxes (rendered in the body as /X/ and / / glyphs), pre- and post-effective amendment-number lines, exact name of registrant, address of principal executive offices, registrant telephone number, name and address of agent for service, approximate date of proposed public offering, and the Section 24(f) / Rule 24f-2 declaration regarding registration of an indefinite number of shares.
• Contents / cross-reference sheet. A table linking Form N-14 captions (Items 1 through 17, distributed across Parts A, B, and C) to the location of the corresponding disclosure inside the prospectus/proxy statement and the statement of additional information.
• Part A — combined prospectus and proxy statement. The longest narrative block. Typically includes a notice of meeting and proxy solicitation, a synopsis or Q&A summary of the proposed reorganization, comparative fund-by-fund summaries (investment objectives, principal investment strategies, principal risks, fee tables and expense examples, performance history), the description of the agreement and plan of reorganization (mechanics, exchange ratio, conditions, termination), reasons for the reorganization, federal income-tax consequences (typically representations of tax-free reorganization status under Section 368(a)), capitalization tables, voting information, and information about the funds' service providers.
• Part B — statement of additional information. For the registrant; frequently supplied by incorporation by reference to existing fund SAIs filed under separate accession numbers.
• Part C — other information. Indemnification disclosure, business and other connections of the investment adviser, principal underwriters, location of accounts and records, management services not discussed in Part A, undertakings, the exhibit list, signatures of officers and a majority of trustees/directors, and powers of attorney.

Subsequent document-N.txt files materialize the exhibits referenced in the Part C exhibit list. Common exhibit types in this dataset include EX-1 (charter / declaration of trust), EX-2 (bylaws), EX-4 (form of agreement and plan of reorganization), EX-5 (opinion and consent of counsel as to legality of shares), EX-8 (tax opinion), EX-11 and EX-23 (consents of independent accountants), EX-14 (other consents), EX-16 (powers of attorney), EX-17 (financial data schedule), and EX-99 (miscellaneous, including pro forma and historical financial statements when filed as discrete exhibits). Each exhibit is a discrete document in the EDGAR submission, given its own sequence number, and accordingly written to its own document-<n>.txt in the record.

Body-file format

The document-<n>.txt files contain only the inner body of each EDGAR document. The SGML envelope (<DOCUMENT>, <TYPE>, <SEQUENCE>, <FILENAME>, <DESCRIPTION>, <TEXT> tags) that wraps each document inside the original complete-submission .txt is stripped during extraction. Consumers must therefore use metadata.json.documentFormatFiles[n-1].type and .description to identify the document type and intended role; the body itself does not carry those header fields.

The bodies are plain ASCII text in essentially every record. Form N-14 cover pages reproduce the SEC heading block in monospaced layout with manual whitespace alignment; registration-act checkboxes render as /X/ and / /; section headings are expressed as ALL-CAPS lines or hand-formatted underlines. Tables — fee tables, expense examples, capitalization tables, pro forma balance sheets, financial data schedules — are rendered as fixed-width column ASCII, often with rows of dashes as horizontal rules. Exhibit documents (legal opinions, tax opinions, accountant consents) are rendered as raw letterhead-and-prose text terminating in a typed signature line. Body sizes range from a few hundred lines for short opinions and consents to several thousand lines for full Form N-14 statements that incorporate the prospectus/proxy and pro forma financials inline.

What is included

A record contains:

• the structured metadata.json index, including the full filer/co-registrant entity list, the document inventory with EDGAR types and descriptions, the filing timestamp, the accession number, and source URLs;
• the plain-text body of every sequenced document in the original EDGAR submission for which a textual body exists — the Form N-14 itself, every textual exhibit, every legal/tax opinion, every consent, every pro forma or historical financial schedule, and any cover letter;
• enough URL pointers (linkToTxt, linkToHtml, linkToFilingDetails, plus per-document documentUrl) to retrieve the original complete-submission .txt, the EDGAR filing-index landing page, and the CIK archive on demand.

What is excluded or kept only as a pointer

A record does not contain:

• Image files (GIF, JPG) attached to the EDGAR submission. Some Form N-14 filings of this era included scanned signature pages, fund logos, or graphical performance charts as image documents in the submission; those are intentionally omitted, and any such sequence number will be missing from the on-disk document-<n>.txt set even though it remains listed in documentFormatFiles.
• The concatenated complete-submission .txt as a materialized file. The documentFormatFiles array carries a synthetic terminal row with sequence: " " whose documentUrl points to the .txt on EDGAR, but the file itself is not extracted into the ZIP.
• The SGML wrappers around each document. The <DOCUMENT> envelope with its <TYPE>, <SEQUENCE>, <FILENAME>, <DESCRIPTION>, and <TEXT> tags is stripped; only the inner payload is written to document-<n>.txt.
• Fund series and classes structured metadata. The EDGAR Series/Class identifier system was introduced after this form's discontinuation, so seriesAndClassesContractsInformation is empty for every record.
• Disclosure incorporated by reference into other accession numbers. Part B (the SAI) and significant portions of Part A frequently incorporate by reference into pre-existing fund prospectuses and SAIs filed under separate accession numbers; the bodies of those incorporated documents live in different filings outside this dataset.

Structural and format evolution across the 1994–1998 lifespan

The Form N14AE24 submission code existed from EDGAR's general-purpose rollout in 1993–1994 through January 1998. Across that window:

• The on-the-wire document format remained essentially unchanged: complete-submission .txt files in EDGAR SGML with plain-ASCII document bodies. HTML filings were not yet permitted for this submission type during its lifetime, so no record in the dataset is HTML-bodied.
• The Form N-14 disclosure obligations themselves (Items 1–17, the prospectus/proxy combination, the Part C exhibit list) were stable across the window. Most variation across records arises from issuer-level differences (single-fund vs. multi-fund families, presence or absence of master-feeder structures, choice of incorporation by reference for Part B SAIs) rather than from regulatory amendment within the period.
• The N14AE24/A pre-effective amendment variant is used when filers correct or supplement an original N14AE24 registration statement before automatic effectiveness. The body content of an /A record is structurally identical to the original — same Form N-14 cover, same Part A/B/C, same exhibit conventions — but the cover-page checkbox indicates pre-effective amendment status, and filers frequently file only the amended exhibits or only the amended Part A sections rather than restating the entire registration.

The form's January 1998 discontinuation means there is no post-1998 evolution to describe. Substantively equivalent filings filed after January 1998 appear under different EDGAR submission codes (the N-14 family) and are out of scope for this dataset.

Interpretation notes

Several quirks matter for downstream consumers:

• Document identification depends on the metadata index, not the body. Because the SGML envelope is stripped from document-<n>.txt, the only reliable way to know whether document-2.txt is a tax opinion, a legal opinion, or pro forma financials is to look up documentFormatFiles[n-1].type and .description in metadata.json. The body text does include human-readable headings, but those vary by filer.
• documentFormatFiles may list rows whose body is not on disk. Image-typed documents are listed in the index but absent from the document-*.txt set, so iterating files by directory listing and iterating rows in documentFormatFiles may yield different cardinalities. The on-disk file is authoritative for body text; the index is authoritative for the EDGAR submission's full inventory.
• The sequence: " " row is a pointer-only row. Code that maps rows to files must skip the row whose sequence is a single space; it has no corresponding extracted file.
• Accession-folder naming uses the digits-only form. Joining records back to EDGAR URLs requires reinserting the dashes (XXXXXXXXXX-YY-NNNNNN) or using the accessionNo field directly from metadata.json rather than the folder name.
• Multi-entity records are normal. A single Form N-14 commonly carries two or more registrant rows in entities[] — one for the acquiring fund (issuer of the new shares) and one for the acquired fund (whose shareholders are voting on the reorganization). Both are valid co-registrants and appear with their own CIKs, file numbers, and film numbers.
• The same registrant can have multiple records in the same monthly container. Successive amendments, or simultaneously filed reorganizations affecting different acquired funds, generate multiple accession numbers and therefore multiple folders for the same filer.
• Body text is fixed-width ASCII. Tabular content (fee tables, capitalization tables, pro forma balance sheets, financial data schedules) relies on whitespace alignment and will not parse correctly under whitespace-collapsing tokenizers; preserve column structure when extracting numeric tables.
• Incorporation by reference is heavy. Part B (the SAI) and significant portions of Part A frequently incorporate by reference into pre-existing fund prospectuses and SAIs filed under separate accession numbers. The body of a Form N-14 record may therefore omit content that is logically part of the disclosure package; reconstructing the full prospectus/proxy may require following the incorporation-by-reference pointers into other EDGAR filings outside this dataset.
• N14AE24/A does not always restate the entire registration. Pre-effective amendments may file only the amended exhibits or only the amended Part A sections, depending on the filer's choice. The number and types of document-<n>.txt files in an /A record can therefore be substantially smaller than in the corresponding original N14AE24 record.
• Signatures appear as typed text only. The signature blocks for officers, trustees/directors, and powers-of-attorney holders required at the end of Part C are reproduced as typed names on signature lines; manuscript signatures, where they existed in the original paper-equivalent filings, are not preserved in the textual body.

Who Files or Publishes This Dataset, and When

Who files the record

The filer is always a registered open-end management investment company (an open-end mutual fund) registered with the SEC under the Investment Company Act of 1940. More specifically, the filer is the acquiring fund in a fund-to-fund business combination — i.e., the fund whose shares are being registered for issuance to the shareholders of another fund (the target or acquired fund) as consideration in the transaction.

The registrant on EDGAR is the legal issuer: typically a Massachusetts business trust, Delaware statutory trust, or Maryland corporation, with the relevant series or portfolio identified inside the filing. Where the trust contains multiple series, the same trust may appear as the filer across many separate N14AE24 submissions for different reorganizations.

The acquired fund and its shareholders are the subjects of disclosure and the audience for the proxy solicitation, but they are not the filer. The filer is the issuer of the new shares.

Form N14AE24 is not used by:

• closed-end funds (which file Form N-14 under different EDGAR codes such as N-14 8C / N-14 8C/A);
• unit investment trusts outside the open-end management company path;
• foreign investment companies;
• operating companies (which register merger securities on Form S-4);
• business development companys that do not qualify under the form's open-end management company conditions.

What triggers the record

The filing is transaction-driven, not periodic. It is created when an acquiring fund needs to register shares to be issued in a business combination among investment companies described in Rule 145(a) under the Securities Act and the General Instructions to Form N-14. Typical triggering events:

• Fund mergers where a target fund merges into an acquiring fund and target shareholders receive acquiring-fund shares;
• Reorganizations transferring the assets and liabilities of one fund to another in exchange for shares;
• Consolidations of two or more funds within or across complexes;
• Master-feeder restructurings where a feeder is reorganized into a successor fund;
• Shell redomiciliations (e.g., Massachusetts trust to Delaware statutory trust) where the successor is technically a new registrant issuing shares to predecessor shareholders.

Because acquired-fund shareholders generally must approve the transaction, Form N-14 functions as a combined prospectus and proxy statement: it is both the Securities Act registration statement for the new shares and the proxy/information statement delivered to acquired-fund shareholders.

Regulatory framework — what "N14AE24" encodes

Three legal layers define this submission type:

Securities Act of 1933 — Form N-14. The shares to be issued in the reorganization are securities offered and sold (Rule 145 treats the exchange as an offer and sale). Form N-14 is the prescribed registration form when the acquiring and acquired entities are registered investment companies or BDCs. The statement must include fund descriptions, risks, fee tables (including pro forma), terms of the reorganization, tax consequences, and historical and pro forma financial statements.

Rule 488 of the Securities Act of 1933 — auto-effectiveness ("AE"). Rule 488 lets a Form N-14 filed by a registered open-end management investment company (or qualifying UIT) for shares issued in a Rule 145(a) business combination become effective automatically on the 30th day after filing (with shorter periods in limited circumstances), provided the registrant is eligible, no stop-order proceeding is pending, and the filing is not amended in a way that resets timing beyond what the rule allows. The "AE" in the form code signals reliance on Rule 488 — no staff acceleration is required; effectiveness occurs by operation of the rule.

Section 24(f) of the 1940 Act — fee mechanics ("24"). Section 24(f) lets open-end management companies (and qualifying UITs) register an indefinite number of shares and pay Securities Act registration fees on net sales, computed and remitted on Rule 24f-2 notices filed annually, rather than per-filing at registration. The "24" in the code identifies this fee regime; the cover page reflects the 24(f) mechanism rather than a conventional fee table tied to dollar amount registered.

Form N-14 + Rule 488 + Section 24(f) is precisely what N14AE24 identifies on EDGAR.

Timing and the role of the /A amendment

Initial filing. Filed when the boards have approved the transaction and the acquiring fund is ready to begin registration and proxy solicitation. There is no statutory deadline; the filing is event-driven.

Rule 488 waiting period. The registration statement is built to go effective automatically on the 30th day after filing. During that period, SEC staff may review and comment, and may take action that prevents auto-effectiveness if disclosure is deficient.

Pre-effective amendments — N14AE24/A. If the filer revises the registration statement before effectiveness — to address staff comments, add financial statements, update fee tables, or correct disclosure — it files a pre-effective amendment as N14AE24/A. Each /A in the dataset is a pre-effective amendment to a previously filed N14AE24 and may delay the auto-effective date depending on its nature.

Effectiveness. Once effective, the combined prospectus/proxy is delivered to acquired-fund shareholders for the special meeting; closing follows shareholder approval and any remaining conditions.

Dataset window: April 1994 to January 1998

The dataset's earliest record is from April 1994, reflecting the roll-out of EDGAR for fund filings. The latest records are from January 1998, when the SEC retired N14AE24 and N14AE24/A as distinct EDGAR submission types. Subsequent fund business-combination registrations were filed under the consolidated N-14 family of submission types, with auto-effectiveness and Section 24(f) status signaled through filing content rather than a dedicated submission code. The dataset is a closed historical corpus — no new records will be added under these codes.

Important distinctions

Acquiring vs. acquired fund. The filer is always the acquiring fund (issuer of the new shares). The acquired fund is described extensively inside the filing but is not the registrant. In intra-complex reorganizations, the same trust may sit on both sides; the trust is the filer, with the acquiring series identified.

Form N-14 outside the AE24 path. Closed-end funds and other Form N-14 filers that cannot use Rule 488 or Section 24(f) file under different EDGAR codes (N-14, N-14/A, N-14 8C, N-14 8C/A). Those filings are not in this dataset.

Form S-4 contrast. Operating-company mergers register their consideration shares on Form S-4, not Form N-14. No operating-company merger registrations appear in this dataset.

Post-effective amendments. Annual prospectus updates and other post-effective amendments use the 485 family (e.g., 485APOS, 485BPOS) and are excluded. The /A records here are exclusively pre-effective amendments.

Stand-alone proxy filings. Routine fund proxy matters filed on Schedule 14A (PRE 14A, DEF 14A) unrelated to a reorganization are a separate population and are not part of this dataset.

How This Dataset Differs From Similar Datasets or Filings

Form N14AE24 sits at the intersection of three regimes: Securities Act registration of new shares, Investment Company Act fund regulation, and Exchange Act proxy solicitation. That overlap creates a small set of forms that are easily confused with N14AE24 but differ on a specific axis: legal trigger, fee mechanism, review posture, issuer type, or time period.

Closest related forms

Form N-14 (consolidated submission type, post-1998). N14AE24 is a historical submission code used on EDGAR from April 1994 through January 1998 to flag open-end fund reorganization registrations that became effective automatically under Rule 488. After January 1998, the SEC collapsed the auto-effective and standard N-14 codes into the current N-14 submission family, which no longer flags the Rule 488 path at the form-code level. The N14AE24 dataset is therefore a sealed historical subset of today's N-14 universe; for any reorganization filed after January 1998, analysts must work from the consolidated N-14 codes.

Form N-14 (non-auto-effective filings, same window). Inside the 1994 to 1998 window, N-14 filings that did not satisfy Rule 488's conditions (typically because the acquired and acquiring funds had materially different investment policies or fundamental restrictions) used the plain N-14 header and went through pre-effective amendment review. N14AE24 captures only the auto-effective slice, biasing the population toward reorganizations that registrants and counsel viewed as routine intra-family consolidations rather than substantive policy changes.

Form N-14 8C (closed-end fund business combinations). N-14 8C registers shares issued by a closed-end management investment company in a business combination. The disclosure architecture (combined prospectus and proxy describing a fund reorganization) is structurally similar to N14AE24, but the issuer populations do not overlap: N14AE24 is exclusive to open-end funds because Rule 488 and the Section 24(f) indefinite-shares fee mechanism are tied to the open-end product structure. Closed-end mergers cannot use that combination.

Form S-4 (operating-company business combinations). S-4 is the Securities Act registration statement for shares issued in mergers and exchanges by operating companies outside the 1940 Act. It shares N14AE24's combined prospectus/proxy character but covers a wholly different issuer population. Two mechanical distinctions matter: S-4 fees are computed transaction-by-transaction under Rule 457, while N14AE24 fees ride on the Section 24(f) indefinite-registration mechanism reconciled through Rule 24f-2; and S-4 has no auto-effective lane analogous to Rule 488.

Form N-1A (open-end fund standing registration). N-1A and N14AE24 share an issuer population (open-end management investment companies) but differ in purpose. N-1A is a steady-state document describing investment objectives, strategies, risks, fees, and management for continuous offering. N14AE24 is transaction-specific, registering shares for a one-time reorganization and adding a proxy layer plus financial statements for the acquired fund. N14AE24 filings typically incorporate or echo N-1A prospectus content for the acquiring fund.

Form N-2 (closed-end fund standing registration). N-2 is the closed-end analogue to N-1A. It is relevant only as a structural parallel: the N-1A / N-2 split mirrors the N14AE24 / N-14 8C split between open-end and closed-end fund regulation. N-2 itself is not substitutable for N14AE24.

Schedule 14A / DEF 14A (proxy statements). Fund reorganizations require shareholder approval, so they trigger proxy rules. The defining feature of N14AE24 is that a single document satisfies both the 1933 Act registration of new acquiring-fund shares and the 1934 Act proxy solicitation for the acquired fund's shareholder vote. A 14A dataset captures the broader fund-proxy universe (board elections, advisory contract approvals, policy votes) that does not register securities; N14AE24 captures only proxy events tied to a share registration. The two are complementary rather than overlapping.

Forms 485APOS and 485BPOS (post-effective amendments to fund registration). The 485 series amends N-1A (and certain other fund registration statements): 485APOS is reviewable, 485BPOS is auto-effective under Rule 485(b). The conceptual parallel to N14AE24 is the existence of an auto-effective lane, but the purpose is different. 485 filings update a fund's standing prospectus and SAI on an ongoing basis; N14AE24 registers shares for a discrete business-combination event.

Rule 24f-2 notice (fee true-up). The "24" in N14AE24 reflects Section 24(f) of the Investment Company Act, which lets open-end funds register an indefinite number of shares and reconcile fees in arrears through an annual Rule 24f-2 notice. The 24f-2 notice itself is a narrow fee-reconciliation filing with no prospectus, proxy, or transactional content. It is the fee-mechanic counterpart to N14AE24, not a substantive disclosure peer.

Key differences at a glance

• Auto-effective vs. reviewed: N14AE24 vs. plain N-14, S-4
• Open-end vs. closed-end issuer: N14AE24 vs. N-14 8C, N-2
• 1940 Act vs. operating company: N14AE24 vs. S-4
• Transaction-specific vs. steady-state: N14AE24 vs. N-1A, 485APOS / 485BPOS
• Combined prospectus + proxy vs. proxy only: N14AE24 vs. Schedule 14A / DEF 14A
• Substantive disclosure vs. fee notice: N14AE24 vs. Rule 24f-2 notice
• Pre-1998 EDGAR code vs. consolidated post-1998 code: N14AE24 vs. current N-14 family

Boundary summary

N14AE24 is distinct because it combines four properties that no neighboring form holds simultaneously: open-end fund issuers, Rule 488 auto-effectiveness, Section 24(f) indefinite-shares fee treatment, and a single document that serves as both prospectus and proxy for a one-time reorganization, all within a closed April 1994 to January 1998 EDGAR coding window. For 1990s open-end fund mergers filed under Rule 488, this dataset is the direct source. For post-1998 reorganizations, use the consolidated N-14 codes. For closed-end mergers, use N-14 8C. For steady-state disclosure of the same issuers, use N-1A and the 485 amendment series. For fund proxy events that do not register securities, use Schedule 14A / DEF 14A. None of these substitutes for N14AE24 within its window; each complements it at a defined boundary.

Who Uses This Dataset

The Form N14AE24 corpus is used across legal, fund-operations, research, data-engineering, and machine-learning workflows. The same record components carry the load across these audiences: metadata.json.entities[] for identifier and genealogy work, the combined prospectus/proxy for substantive disclosure and fee tables, the fairness and tax exhibits for transaction structure, and /A amendments for the evolution of disclosure between filing and effectiveness.

Fund counsel and registration attorneys

Attorneys drafting current N-14 filings mine the combined prospectus/proxy for precedent language: merger rationale recitals, investment-objective compatibility analyses, board-approval narratives, and shareholder-vote mechanics. The fee and expense comparison tables anchor benchmarking of disclosed expense impact, and the tax-opinion and merger-agreement exhibits inform structural choices (reorganization vs. asset transfer, treatment of unrealized gains). N14AE24/A amendments are read against the original filing to see how staff comments reshaped disclosure pre-effectiveness.

Asset-manager product and corporate-development teams

Strategy teams scoping a present-day fund reorganization use historical analogues to model shareholder communications, proxy timelines, and contested-vote risk. They focus on proxy sections covering solicitation methods, vote thresholds, and failure-to-approve contingencies, and on the acquired/acquiring funds' statements of assets and schedules of investments to frame messaging on scale, expense rationalization, and diversification.

Compliance and fund-administration staff

Compliance teams auditing legacy filings or responding to regulator inquiries use metadata.json entities[] — particularly CIK pairings between acquired and surviving registrants — to reconstruct CIK genealogy across fund families that absorbed multiple predecessor trusts. Because the form was retired in January 1998, the universe is a closed archive and a fixed reference point for legacy lookups.

Mutual-fund consolidation researchers

Academics studying the mid-1990s fund-merger wave treat the dataset as a near-complete census of the Rule 488 path during the period. They pull acquirer/target identifiers from entities[] and extract fund age, size, prior performance, and stated rationale from the prospectus/proxy text to build panel datasets on consolidation determinants and within- vs. cross-family mergers.

Quantitative researchers correcting survivorship bias

Quants reattach disappearing-fund returns and AUM to merger events using entities[] to identify the acquired CIK and the prospectus/proxy disclosure of pre-merger performance histories. This corrects 1990s fund-universe samples used for skill, persistence, and category-benchmark studies.

Fee and expense-ratio analysts

Analysts building long-horizon fee panels extract management fees, 12b-1 fees, other expenses, total expense ratios, and pro forma combined ratios from the prospectus/proxy fee tables for both funds at the merger date — a window that is otherwise difficult to recover from post-merger annual reports.

Market-data and reference-data engineers

Vendors building fund identifier crosswalks and corporate-action timelines parse metadata.json for filer CIKs, then extract series, class, and ticker identifiers of retiring funds and surviving share classes from the prospectus/proxy. This supports NAV time-series stitching, retired-CUSIP mapping, and joins between vintage and modern series/class identifiers.

Litigation support and expert witnesses

Litigation teams handling disputes over 1990s-era fund mergers — disclosure adequacy, exchange-ratio fairness, legacy-shareholder dilution, post-merger expense changes — retrieve the contemporaneous filing as effective. Fairness opinion exhibits, board-process narratives in the proxy, and pro forma fee tables are the core evidentiary artifacts; diffs between N14AE24 and N14AE24/A document what disclosure changed and when.

Financial historians and archivists

Historians use the prospectus/proxy narrative as a primary source on how sponsors explained reorganizations to retail shareholders and how disclosure conventions evolved during the early auto-effective Rule 488 regime.

LLM and RAG developers working with fund disclosure

Teams building extraction systems use the corpus as a bounded, structurally homogeneous training set for fund-merger event classification, CIK entity-linking, and structured extraction of fee tables and exchange ratios from the prospectus/proxy.

Specific Use Cases

The Form N14AE24 Files Dataset supports a small set of concrete workflows built around the combined prospectus/proxy text, the exhibit package, the entities[] block in metadata.json, and the diff between original N14AE24 filings and their N14AE24/A pre-effective amendments.

Building a CIK genealogy of 1990s open-end fund mergers

Pair the acquiring-fund and acquired-fund rows from metadata.json.entities[] (the companyName strings tagged (Filer) versus additional registrant rows, plus their cik and fileNo fields) into directed edges from acquired CIK to surviving CIK. Joined across the 1994 to 1998 universe of records, this yields a closed-window genealogy table that downstream pipelines use to stitch retired-fund NAV and AUM histories onto surviving share classes and to back-fill disappearing returns into survivorship-corrected panels.

Extracting pre-merger fee and expense ratios for long-horizon panels

Parse the fee tables and expense examples in document-1.txt (the Form N-14 itself) for the acquired fund, the acquiring fund, and the pro forma combined entity. The fixed-width ASCII tables expose management fees, 12b-1 fees, other expenses, total expense ratios, and the pro forma combined ratio at the reorganization date — a snapshot that is otherwise unrecoverable once the acquired fund disappears from post-merger annual reports. Output feeds long-horizon expense-ratio time series and fee-rationalization studies of the mid-1990s consolidation wave.

Mining precedent language for current N-14 drafting

Fund counsel preparing a present-day reorganization filing query the prospectus/proxy text in document-1.txt for reusable templates: merger-rationale recitals, investment-objective compatibility findings, board-approval narratives, Section 368(a) of the Internal Revenue Code tax-free reorganization representations, and Rule 488 reliance language. Tax opinions (EX-8), legal opinions on share legality (EX-5), and the agreement and plan of reorganization (EX-4) supply structural precedents for asset-transfer mechanics, exchange-ratio formulas, and conditions to closing.

Reconstructing staff-comment-driven disclosure changes from /A amendments

For each accession that has both an N14AE24 original and one or more N14AE24/A pre-effective amendments under the same fileNo, diff the body text of the corresponding document-<n>.txt files. Because amendments often refile only the changed Part A sections or specific exhibits, the surviving documents in the /A record concentrate exactly the disclosure that moved between filing and effectiveness. Litigation experts and compliance teams use these diffs as evidence of what risk, fee, or fairness disclosure was added, removed, or softened pre-effectiveness.

Training extraction models for fund-merger events

Use the corpus as a bounded, structurally homogeneous training set: metadata.json.entities[] provides ground-truth acquirer/target CIK pairs, documentFormatFiles[].type labels each document-<n>.txt body as registration statement, tax opinion, legal opinion, accountant consent, or merger agreement, and the prospectus/proxy text supplies labeled instances of exchange ratios, vote thresholds, record dates, and fee tables. Models trained here transfer to the post-1998 consolidated N-14 family with minimal adaptation.

Recovering fairness-opinion and board-process evidence for litigation

For disputes over exchange-ratio fairness, legacy-shareholder dilution, or post-merger expense changes, pull the contemporaneous filing as it became effective: the board-process narrative and reasons-for-the-reorganization section in document-1.txt, the fairness or tax opinion exhibits (EX-8, EX-99), the pro forma capitalization tables, and the typed-signature trustee block in Part C. The filedAt timestamp and accessionNo anchor the evidentiary record to a specific date and EDGAR submission, and the linkToTxt pointer back to the original complete-submission .txt supports authentication.

Dataset Access

Dataset Index JSON API: https://api.sec-api.io/datasets/form-n14ae24-files.json

This endpoint returns the dataset's metadata and the list of all container files. The metadata includes the dataset name, description, last updated timestamp, earliest sample date (1994-04-01), total record and size counters, covered form types (N14AE24, N14AE24/A), the container format (ZIP), and the file types contained inside each archive (TXT, JSON). The containers[] array lists each monthly container with its key, size, record count, last updated timestamp, and direct download URL. This endpoint does not require an API key, which makes it suitable for polling on a schedule to detect which containers were updated in the most recent refresh run and to download only those containers on a day-by-day basis.

Example response:

          1
          {
        

          2
            "datasetId": "1f13365b-9ae0-69e4-afec-b73bea0f4ee3",
        

          3
            "datasetDownloadUrl": "https://api.sec-api.io/datasets/form-n14ae24-files.zip",
        

          4
            "name": "Form N14AE24 Files Dataset",
        

          5
            "updatedAt": "2026-04-15T18:09:35.595Z",
        

          6
            "earliestSampleDate": "1994-04-01",
        

          7
            "totalRecords": 2107,
        

          8
            "totalSize": 54563439,
        

          9
            "formTypes": ["N14AE24", "N14AE24/A"],
        

          10
            "containerFormat": "ZIP",
        

          11
            "fileTypes": ["TXT", "JSON"],
        

          12
            "containers": [
        

          13
              {
        

          14
                "downloadUrl": "https://api.sec-api.io/datasets/form-n14ae24-files/1996/1996-12.zip",
        

          15
                "key": "1996/1996-12.zip",
        

          16
                "size": 1842311,
        

          17
                "records": 71,
        

          18
                "updatedAt": "2026-04-15T18:09:35.595Z"
        

          19
              }
        

          20
            ]
        

          21
          }
        

Download Entire Dataset: https://api.sec-api.io/datasets/form-n14ae24-files.zip?token=YOUR_API_KEY

Downloads the complete dataset as a single ZIP archive containing every monthly container from April 1994 through January 1998. This endpoint requires an API key passed via the token query parameter.

Download Single Container: https://api.sec-api.io/datasets/form-n14ae24-files/1996/1996-12.zip?token=YOUR_API_KEY

Downloads one individual monthly container ZIP instead of the full dataset, which is useful for incremental syncs of recently updated months identified through the index JSON. This endpoint requires an API key passed via the token query parameter.

Frequently Asked Questions

What form does this dataset cover?

The dataset covers EDGAR submissions filed under the N14AE24 and N14AE24/A form codes — the auto-effective variant of Form N-14 (and its pre-effective amendments) used by open-end management investment companies to register shares issued in business-combination transactions under Rule 488 of the Securities Act, with fees handled under Section 24(f) of the Investment Company Act of 1940.

What does one record in this dataset represent?

One record represents a single EDGAR submission keyed by accession number, containing a metadata.json index plus the extracted plain-text bodies of every sequenced document in the original submission as document-<sequence>.txt files. The unit of granularity is the filing, not the underlying reorganization transaction (which can span multiple filings) and not the individual exhibit document (which is a sub-file inside one record).

Who is required to file this form?

The filer is always a registered open-end management investment company acting as the acquiring fund — the issuer of new shares — in a fund-to-fund business combination such as a merger, reorganization, consolidation, master-feeder restructuring, or shell redomiciliation. Registrants are typically Massachusetts business trusts, Delaware statutory trusts, or Maryland corporations. Closed-end funds, operating companies, and unit investment trusts outside the open-end management company path do not file under this code.

What time period does the dataset cover?

The dataset spans April 1994, when EDGAR was rolled out for fund filings, through January 1998, when the SEC retired the N14AE24 and N14AE24/A submission codes. It is a closed historical corpus; substantively equivalent post-1998 filings appear under the consolidated N-14 family of submission codes and are out of scope.

What file format is the dataset distributed in?

The dataset is distributed as a hierarchy of monthly ZIP archives organized as YYYY/YYYY-MM.zip. Each archive contains one folder per filing, named with the digits-only accession number, holding one metadata.json and one or more document-<n>.txt files. Document bodies are pre-HTML plain ASCII text because the form's lifespan ended before HTML filings became prevalent on EDGAR.

How does this dataset differ from the post-1998 N-14 dataset?

After January 1998, the SEC collapsed the auto-effective and standard N-14 codes into the consolidated N-14 submission family, which no longer flags the Rule 488 path at the form-code level. The N14AE24 dataset is therefore a sealed historical subset: it contains only the auto-effective slice of open-end fund reorganizations from April 1994 through January 1998. For any reorganization filed after January 1998, analysts must work from the consolidated N-14 codes.

What is the difference between an N14AE24 and an N14AE24/A record?

N14AE24 is the original auto-effective Form N-14 registration statement. N14AE24/A is a pre-effective amendment to a previously filed N14AE24 — used to address staff comments, add financial statements, update fee tables, or correct disclosure before the registration becomes effective on the thirtieth day after filing. The body content of an /A is structurally identical to the original, but filers frequently file only the amended exhibits or only the amended Part A sections rather than restating the entire registration, so an /A record may contain substantially fewer document-<n>.txt files than the original.