Form POS462B Files Dataset

The Form POS462B Files Dataset is a collection of every EDGAR submission filed under form type POS462B — post-effective amendments to registration statements made pursuant to Rule 462(b) of the Securities Act of 1933. Each record is one complete EDGAR accession packaged as a subfolder inside a monthly ZIP container, containing a parsed metadata.json header alongside the original SGML-wrapped HTML submission documents and, where present, the EDGAR complete-submission text file. The form is filed by operating-company issuers — domestic registrants on Forms S-1, S-3, or S-11, foreign private issuers on F-1 or F-3 — to register additional securities of the same class as those covered by an earlier effective registration statement, subject to a 20 percent cap on the original maximum aggregate offering price. The dataset covers all POS462B accessions filed on EDGAR from July 1995 (the inception of mandatory EDGAR filing) through the present.

Update Frequency
Daily
Updated at
2026-04-15
Earliest Sample Date
1995-07-01
Total Size
3.0 MB
Total Records
634
Container Format
ZIP
Content Types
TXT, JSON, HTML
Form Types
POS462B

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

132 files · 3.0 MB
Download All
2023-11.zip5.9 KB1 records
2022-08.zip196.4 KB4 records
2022-07.zip72.3 KB2 records
2022-06.zip4.9 KB1 records
2021-08.zip10.9 KB4 records
2020-12.zip28.8 KB10 records
2020-04.zip4.7 KB1 records
2019-04.zip10.1 KB2 records
2019-03.zip5.2 KB1 records
2018-12.zip15.4 KB3 records
2018-10.zip4.9 KB1 records
2018-05.zip5.0 KB1 records
2018-03.zip4.7 KB1 records
2018-02.zip7.4 KB3 records
2017-09.zip10.2 KB2 records
2016-11.zip4.6 KB1 records
2016-09.zip4.4 KB1 records
2016-08.zip5.4 KB1 records
2016-07.zip4.4 KB1 records
2016-05.zip5.1 KB1 records
2016-04.zip4.4 KB1 records
2016-01.zip4.9 KB1 records
2015-07.zip4.6 KB1 records
2015-03.zip10.3 KB3 records
2015-02.zip4.3 KB1 records
2014-12.zip12.8 KB3 records
2013-11.zip16.4 KB4 records
2013-09.zip4.5 KB1 records
2012-10.zip13.9 KB4 records
2012-08.zip27.2 KB8 records
2012-02.zip9.6 KB3 records
2011-09.zip9.3 KB3 records
2011-04.zip16.6 KB4 records
2011-03.zip10.5 KB3 records
2011-02.zip4.0 KB1 records
2011-01.zip10.1 KB3 records
2010-11.zip11.4 KB3 records
2010-03.zip4.8 KB1 records
2010-02.zip5.9 KB1 records
2010-01.zip10.1 KB3 records
2009-11.zip9.3 KB4 records
2009-10.zip8.8 KB2 records
2009-07.zip5.0 KB1 records
2009-05.zip4.6 KB1 records
2008-12.zip9.2 KB3 records
2008-07.zip8.9 KB2 records
2007-12.zip4.4 KB1 records
2007-08.zip10.0 KB3 records
2007-06.zip122.5 KB2 records
2007-04.zip17.3 KB10 records
2006-11.zip53.8 KB8 records
2006-10.zip8.1 KB3 records
2006-07.zip4.8 KB1 records
2006-03.zip5.5 KB2 records
2005-12.zip10.6 KB4 records
2005-11.zip449.1 KB4 records
2005-08.zip28.6 KB7 records
2005-07.zip8.1 KB2 records
2005-05.zip9.0 KB3 records
2005-03.zip4.7 KB1 records
2005-02.zip14.1 KB5 records
2005-01.zip9.9 KB4 records
2004-10.zip19.8 KB5 records
2004-08.zip7.9 KB3 records
2004-01.zip14.9 KB4 records
2003-09.zip3.7 KB1 records
2003-07.zip10.2 KB3 records
2003-05.zip7.9 KB3 records
2003-01.zip17.0 KB6 records
2002-12.zip14.6 KB6 records
2002-10.zip17.1 KB3 records
2002-09.zip3.9 KB2 records
2002-08.zip10.3 KB4 records
2002-05.zip9.6 KB4 records
2002-04.zip11.3 KB4 records
2002-03.zip15.3 KB9 records
2001-11.zip8.8 KB5 records
2001-10.zip58.3 KB1 records
2001-09.zip41.4 KB15 records
2001-08.zip17.9 KB8 records
2001-07.zip14.6 KB6 records
2001-06.zip10.5 KB3 records
2001-05.zip3.3 KB1 records
2001-01.zip26.1 KB10 records
2000-10.zip28.7 KB14 records
2000-09.zip257.1 KB30 records
2000-08.zip5.8 KB3 records
2000-07.zip15.8 KB7 records
2000-05.zip5.9 KB3 records
2000-04.zip6.6 KB4 records
2000-03.zip9.7 KB5 records
2000-02.zip16.3 KB5 records
2000-01.zip3.9 KB1 records
1999-12.zip21.2 KB9 records
1999-11.zip18.0 KB11 records
1999-10.zip5.3 KB3 records
1999-09.zip21.3 KB12 records
1999-07.zip5.9 KB3 records
1999-05.zip49.0 KB5 records
1999-03.zip4.7 KB3 records
1999-02.zip5.5 KB3 records
1999-01.zip22.1 KB8 records
1998-12.zip30.6 KB9 records
1998-10.zip3.1 KB1 records
1998-08.zip4.7 KB2 records
1998-07.zip156.0 KB14 records
1998-06.zip6.5 KB3 records
1998-05.zip6.4 KB3 records
1998-04.zip9.3 KB2 records
1998-03.zip9.8 KB6 records
1998-02.zip5.9 KB3 records
1998-01.zip50.3 KB1 records
1997-12.zip139.1 KB8 records
1997-11.zip18.2 KB8 records
1997-10.zip44.4 KB24 records
1997-09.zip6.7 KB4 records
1997-08.zip15.9 KB7 records
1997-07.zip20.9 KB12 records
1997-06.zip21.2 KB10 records
1997-05.zip8.2 KB8 records
1997-03.zip14.1 KB11 records
1997-02.zip30.0 KB18 records
1996-12.zip15.8 KB12 records
1996-11.zip3.6 KB1 records
1996-10.zip40.2 KB24 records
1996-08.zip17.6 KB10 records
1996-06.zip5.7 KB3 records
1996-05.zip23.4 KB14 records
1996-03.zip5.8 KB3 records
1995-10.zip8.4 KB5 records
1995-09.zip8.1 KB3 records
1995-07.zip4.9 KB3 records

What This Dataset Contains

The dataset packages every POS462B submission made to EDGAR since July 1995. A single record is one accession — not a filing-index page and not an individual exhibit — and carries every document the registrant submitted under that accession number (other than image binaries), together with a parsed metadata header.

Physically, records are organized into monthly ZIP containers named YYYY-MM.zip. The internal path layout is YYYY-MM/<accession-no-dashes>/, where the folder name is the 18-digit, dash-stripped EDGAR accession number (for example, accession 0001104659-20-043986 becomes 000110465920043986/). The accession folder is flat — there are no nested subfolders. Inside sit a metadata.json describing the EDGAR submission header and the original submission documents as separate files. The container format is ZIP, and the file types found in the dataset are JSON (the metadata header), HTML (the SGML-wrapped .htm/.html documents the registrant filed), and TXT (the EDGAR complete-submission concatenated text file, when materialized). Image attachments (.jpg, .gif) are deliberately excluded; metadata.json is always present.

Form POS462B is itself a narrow administrative vehicle. Rule 462(b) lets a registrant register additional securities of the same class as those covered by an already-effective registration statement, provided the aggregate offering price of the additional securities does not exceed 20 percent of the maximum aggregate offering price set forth in the original "Calculation of Registration Fee" table. A 462(b) filing is immediately effective upon filing — no Staff review, no acceleration request — and is keyed to the original registration's file number rather than receiving a new one. In practice the POS462B form-type code is used for two structurally distinct purposes, both of which appear in this dataset:

  1. Additive 462(b) registrations — the orthodox use of the rule: registering an incremental quantity of the same class of securities (typically common stock for an IPO or follow-on offering that has been upsized) on top of a still-effective S-1, S-3, or F-1.
  2. Deregistration / termination amendments — using the post-effective amendment vehicle to remove unsold securities from registration after a completed offering, a merger that has caused the offering to terminate, or an abandonment of the issuer's intent to issue. The 462(b) tag is reused here for any post-effective amendment that touches the original 462(b)-related registration; substantively the body is a Rule 478 termination certificate rather than a registration of new securities.

Volume is modest because Rule 462(b) is itself narrow, used only when an issuer needs to top up or terminate a prior registration during a live or closing offering.

Content Structure of a Single Record

A record has three content layers, from outermost to innermost:

  1. The accession folder — the outer structural unit, named with the 18-digit dash-stripped accession number. All files belonging to the EDGAR submission live here as a flat list.
  2. metadata.json — a flat JSON object that mirrors and parses the EDGAR filing header for the accession. This is the structured-data face of the record.
  3. The submission documents — one or more SGML-wrapped HTML files (and, when present, a complete-submission text file), each carrying the rendered content the registrant filed. This is the human-readable, legally operative face of the record.

metadata.json and the submission documents are linked through the documentFormatFiles[] array inside the metadata, which lists one entry per filed document with its EDGAR sequence number, byte size, documentUrl on sec.gov, free-text description, and EDGAR document type. The filenames in documentFormatFiles[] correspond to the files sitting next to metadata.json on disk.

metadata.json schema

metadata.json is a flat JSON object summarizing the EDGAR header. The top-level keys are:

KeyMeaning
formTypeEDGAR form-type code; always "POS462B" in this dataset.
accessionNoDashed accession number, e.g. "0001104659-20-043986".
linkToFilingDetailsURL of the primary filing document on sec.gov.
descriptionStatic human-readable description: "Form POS462B - Post-effective amendment to registration statement [Rule 462(b)]".
linkToTxtURL of the EDGAR complete-submission .txt file.
filedAtISO-8601 filing timestamp with timezone offset, e.g. "2020-04-07T08:49:54-04:00".
linkToHtmlURL of the EDGAR filing-index HTML page.
linkToXbrlURL of XBRL data; empty string "" for POS462B filings.
idInternal 32-character hex content identifier, e.g. "5a0a0f86eff76f31438baa68f08a5219".
documentFormatFilesArray — one entry per document in the EDGAR submission.
entitiesArray of filer/registrant entities derived from the EDGAR header.
seriesAndClassesContractsInformationArray; empty for POS462B (used only by investment-company series/class filings).
dataFilesArray; empty for POS462B (used for XBRL exhibit files on form types that carry them).

documentFormatFiles[]

Each element describes one document in the EDGAR submission. Fields:

  • sequence — EDGAR sequence number as a string ("1", "2", …). For ancillary entries such as the complete-submission text file, this field is " " (a single space).
  • size — byte count as a string.
  • documentUrlsec.gov URL of the document.
  • description — free-text description supplied at filing time.
  • type — EDGAR document type ("POS462B" for the primary form document, "EX-5.1", "EX-23.1", etc. for opinions and consents, and " " for the complete-submission text file).

A typical primary-document entry looks like:

Example
1 {
2 "sequence": "1",
3 "size": "29644",
4 "documentUrl": "https://www.sec.gov/Archives/edgar/data/1667633/000110465920043986/a20-14980_5pos462b.htm",
5 "description": "POS462B",
6 "type": "POS462B"
7 }

A complete-submission text entry appears with "sequence": " ", "type": " ", and description: "Complete submission text file", pointing at the <accession>.txt concatenated submission file (e.g., 0001104659-20-043986.txt).

entities[]

One element per role-bearing entity in the EDGAR header. Most POS462B accessions have a single registrant and therefore a single entity element. Per-entity keys:

  • companyName — display name with the EDGAR role suffix in parentheses, e.g. "Forty Seven, Inc. (Filer)".
  • cik — 10-digit zero-padded Central Index Key, e.g. "0001667633".
  • irsNo — Employer Identification Number digits, e.g. "474065674".
  • fileNo — SEC file number, e.g. "333-235458". For POS462B this is the registration number of the earlier effective registration being amended; a new file number is never assigned to the 462(b) itself.
  • filmNo — EDGAR film number, e.g. "20778509".
  • formType"POS462B", matching the top-level value.
  • act — Securities Act under which filed, "33" (Securities Act of 1933).
  • fiscalYearEndMMDD, e.g. "1231".
  • stateOfIncorporation — two-letter U.S. state or jurisdiction code, e.g. "DE".
  • sicSIC code and label, e.g. "2834 Pharmaceutical Preparations".
  • tickers — array of ticker strings, e.g. ["FTSV"].

Submission document anatomy

Each submission document inside the accession folder is an EDGAR SGML-wrapped HTML file. The outer envelope is the canonical EDGAR <DOCUMENT> wrapper, holding a small typed header followed by <TEXT> containing the rendered HTML body:

1 <DOCUMENT>
2 <TYPE>POS462B
3 <SEQUENCE>1
4 <FILENAME>a20-14980_5pos462b.htm
5 <DESCRIPTION>POS462B
6 <TEXT>
7 <html>... full HTML body ...</html>
8 </TEXT>
9 </DOCUMENT>

<TYPE> carries the EDGAR document type (POS462B, EX-5.1, EX-23.1, etc.); <SEQUENCE> mirrors the documentFormatFiles[].sequence value; <FILENAME> is the on-disk filename inside the accession folder; <DESCRIPTION> is the filer-supplied free-text description.

The inner HTML body is heavily inline-styled (Times New Roman, explicit point sizes on every <p> and <font> element, Wingdings glyphs for checkbox marks) and is broken into page sections using <div style="page-break-before:always;">. HTML comments such as <!-- SEQ.=1,FOLIO='',FILE='C:\JMS\...',USER='105537',CD='Apr 6 20:13 2020' --> are Workiva, Donnelley, or Toppan filing-tool artifacts placed at page boundaries and carry no legal content.

The inner submission, section by section

The body of the primary POS462B document follows a stable layout. In document order:

  1. Facing page. A boilerplate header block identifying the filing. Includes the phrase "As filed with the Securities and Exchange Commission on [date]"; the line "Registration No. 333-XXXXXX" (the file number of the original registration being amended); the headline "POST-EFFECTIVE AMENDMENT NO. [N] TO FORM [S-1/S-3/F-1] REGISTRATION STATEMENT NO. 333-XXXXXX / UNDER THE SECURITIES ACT OF 1933"; the registrant name in large caps; state of incorporation; IRS Employer Identification Number; principal-office address and telephone; the name and address of the agent for service; and a "Copies to:" block listing outside counsel. A checkbox section then walks the standard Rule 415, Rule 462(b), Rule 462(c), Rule 462(e), and General Instruction I.D. paragraphs (rendered with Wingdings o/x glyphs), and a separate checkbox table marks accelerated-filer, smaller-reporting-company, and emerging-growth-company status.

  2. Incorporation-by-reference statement. A short paragraph stating that the contents of the earlier effective registration statement (identified by file number) are incorporated by reference into the post-effective amendment. For additive 462(b) filings this statement is the legal hinge of the form: rather than reproducing the prospectus, the filing imports it wholesale and merely registers the incremental securities on top.

  3. Calculation of Registration Fee table. Present on additive 462(b) filings. This is the Rule 457(o) "Calculation of Registration Fee" table, with columns for title of each class of securities to be registered, amount being registered, proposed maximum offering price per unit, proposed maximum aggregate offering price, and amount of registration fee. The amounts here represent only the incremental top-up (capped at 20 percent of the original maximum aggregate offering price), not the original registration. Footnotes typically state the rule under which the fee is calculated and reference the original registration's fee.

  4. Explanatory Note. Present on deregistration/termination amendments and on many additive filings. The subtitle indicates the purpose — e.g. "DEREGISTRATION OF SECURITIES" on a termination filing — and the body recites the prior registration (file number, total aggregate offering price, class and par value of securities), the event triggering the amendment (completed offering, merger closing, abandonment of the offering), and the action taken (termination of the offering and removal of unsold securities from registration).

  5. Exhibits — opinions and consents. Additive 462(b) filings must carry the legal opinion of counsel as to the validity of the additional securities being registered (filed as Exhibit 5.1) and the written consent of the registrant's independent registered public accounting firm (Exhibit 23.1), plus the implicit consent of counsel embedded in Exhibit 5.1. Each exhibit is filed as a separate .htm document within the same accession folder, each with its own <DOCUMENT> wrapper and its own entry in documentFormatFiles[] carrying an EDGAR exhibit type such as EX-5.1 or EX-23.1. Filenames follow the registrant's local convention (ex5-1.htm, ex23-1.htm, etc.). Deregistration/termination filings generally omit all exhibits.

  6. Signatures. A short-form signature block governed by Rule 478, which permits a post-effective amendment under Rule 462(b) to be signed by a more limited slate of persons than a full registration statement. The boilerplate runs "Pursuant to the requirements of the Securities Act of 1933, as amended, the Registrant certifies that it has reasonable grounds to believe that it meets all of the requirements for filing on Form [S-1/S-3/F-1] and has duly caused this post-effective amendment to be signed on its behalf by the undersigned …", followed by a two-column table of /s/ <Name> lines with Name: and Title: rows. The block closes with "No other person is required to sign this Post-Effective Amendment in reliance upon Rule 478 under the Securities Act of 1933, as amended."

When the accession contains exhibits, each exhibit sits in its own <DOCUMENT> wrapper after the primary POS462B document, in EDGAR sequence order. The complete-submission .txt file, when present, is the EDGAR concatenation of all those <DOCUMENT> blocks back-to-back.

Included content

Each record includes:

  • The parsed EDGAR header as metadata.json, with the schema above.
  • Every SGML-wrapped submission document the filer submitted under the accession — at minimum the primary POS462B document, and where applicable any Exhibit 5 opinion of counsel, Exhibit 23 consents of auditors and counsel, and any additional narrative exhibits — each delivered as its own .htm file preserving the original EDGAR <DOCUMENT> envelope and the filer's submission filename.
  • Where present, the EDGAR complete-submission .txt concatenation, referenced through linkToTxt and through a documentFormatFiles[] entry with type: " ".

Excluded or separate content

  • Image binaries. .jpg and .gif graphics referenced from the HTML (corporate logos, signature scans, exhibit images) are deliberately excluded.
  • The original underlying registration statement. The earlier S-1 / S-3 / F-1 being amended is not bundled into the POS462B record. Its prospectus is reachable only via the file-number link to that earlier accession on EDGAR.
  • Series/class information. The seriesAndClassesContractsInformation array is empty for this form type; that schema slot is reserved for investment-company filings.
  • XBRL exhibit files. POS462B does not carry XBRL; linkToXbrl is empty and dataFiles is empty.

Structural variation across filings

The two stylistic flavors of POS462B produce visibly different records:

  • Additive 462(b) records are multi-document: a primary POS462B HTML plus one or more exhibit HTML files (opinions and consents). They carry the Calculation of Registration Fee table, the incorporation-by-reference statement, and often an Explanatory Note describing the top-up. They are larger by file count, though each individual file is short because the prospectus itself is incorporated by reference rather than reproduced.
  • Deregistration / termination records are typically single-document: one short primary POS462B HTML containing the facing page, an Explanatory Note titled along the lines of "Deregistration of Securities", and the Rule 478 signature block. No fee table, no opinion, no consent. Filings of this flavor are commonly in the 25–35 KB range.

The container layout, metadata.json schema, and SGML <DOCUMENT> envelope are identical across both flavors; only the document count, the EDGAR exhibit types in documentFormatFiles[], and the presence or absence of the fee/opinion/consent sections in the body differ.

Changes in required content over time

The Rule 462(b) regime has been substantively stable since adoption: a 462(b) filing has always served to register up to 20 percent additional securities of the same class as a still-effective registration, has always been immediately effective on filing, and has always relied on Rule 478 for its abbreviated signature block. The qualitative content of a POS462B body — facing page, incorporation-by-reference, fee table (when additive), and Rule 478 signatures — has therefore been largely constant across the dataset's 1995-to-present span.

Disclosures within those sections have nevertheless evolved with broader SEC rulemaking:

  • Filer-status checkboxes on the facing page. The accelerated-filer checkbox set was introduced by the SEC's 2005 acceleration rules; the smaller-reporting-company checkbox was added in 2008; the emerging-growth-company checkbox was added after the JOBS Act in 2012. Facing pages on POS462B filings inherit these checkboxes from the underlying registration form (S-1, S-3, F-1, etc.), so older records lack one or more of them.
  • Fee calculation presentation. The Calculation of Registration Fee table has been continuously required for additive filings, but its column structure and footnote conventions tightened over time, and the SEC's 2022 fee-disclosure modernization (Rule 457 amendments and the introduction of the structured Exhibit 107 fee-calculation exhibit on most registration forms) shifted the locus of fee disclosure. POS462B filings have nevertheless tended to continue carrying the fee table inline within the body of the amendment rather than as a separate Exhibit 107.
  • Rule 478 signature scope. The short-form Rule 478 signature block has been a stable feature, but the precise boilerplate text and the universe of officers required to sign have shifted slightly with technical SEC rule changes; older filings often show terser language.

Changes in data format over time

The dataset's records span the full EDGAR document-format era. The format trajectory relevant to POS462B is:

  • 1995 to early 2000s: ASCII / plain-text SGML. Early POS462B filings were typically submitted as plain-text documents inside the same <DOCUMENT> SGML envelope used today, but with <TEXT> blocks holding ASCII bodies rather than HTML. Tables in the fee calculation were rendered as fixed-width text with character-cell alignment.
  • Late 1990s to mid-2000s: HTML adoption. EDGAR began accepting HTML-based submissions, and filers progressively migrated their primary documents to <TYPE>POS462B-wrapped HTML bodies with inline styling. By the mid-2000s HTML had become dominant for both the primary document and the exhibits.
  • Mid-2000s to present: HTML with heavy inline styling. Modern records uniformly carry HTML bodies styled in Times New Roman with explicit point sizes, page-break <div>s, Wingdings checkbox glyphs, and filing-agent tool comments at page boundaries.
  • Complete-submission .txt. Throughout the period, EDGAR has continued to generate a concatenated complete-submission text file for every accession, referenced in the dataset through the linkToTxt URL and through the type: " " entry in documentFormatFiles[].

Interpretation notes

  • The file number identifies the registration being amended, not the amendment itself. entities[].fileNo and the cover-page "Registration No. 333-XXXXXX" both point to the underlying S-1/S-3/F-1; the POS462B does not receive its own file number. Joining a POS462B record back to the original prospectus and fee table requires looking up that file number on EDGAR.
  • The form-type code alone does not distinguish additive from termination filings. Both flavors carry formType: "POS462B". The flavor can be inferred from the document count in documentFormatFiles[] (a single primary document with no exhibits strongly suggests a termination), the file size, and the presence or absence of a Calculation of Registration Fee table in the primary document.
  • Incorporation by reference is load-bearing. The substantive disclosure for an additive 462(b) lives in the prior registration statement, not in the POS462B body. Treating the POS462B record as self-contained will under-read what securities are being offered and on what terms.
  • Exhibits live as separate documents in the same accession folder. Exhibit 5 and Exhibit 23 are separately wrapped in their own <DOCUMENT> envelopes, separately listed in documentFormatFiles[], and separately materialized as .htm files alongside metadata.json. They are not embedded inside the primary POS462B document.
  • SGML wrapper metadata duplicates JSON metadata. Each <DOCUMENT> block's <TYPE>, <SEQUENCE>, <FILENAME>, and <DESCRIPTION> mirror the corresponding documentFormatFiles[] entry. Either source can be used for document-level extraction; the JSON is canonical for parsing.
  • Filing-tool comments are noise. HTML comments such as <!-- SEQ.=...,FOLIO=...,FILE=...,USER=...,CD=... --> reflect the filer's preparation software (Workiva, Donnelley, Toppan, in-house tools) and should be stripped for content extraction.
  • Filenames are filer-chosen. Filenames such as a20-14980_5pos462b.htm follow each registrant's filing-agent conventions and are not standardized across the dataset. The reliable handles for joining files to metadata are the EDGAR sequence number and the documentUrl, not the filename pattern.
  • Sequence ordering vs. ancillary entries. Numeric sequence values in documentFormatFiles[] order the primary and exhibit documents; the complete-submission text file entry uses sequence: " " and is not part of that ordering. Sort by numeric sequence (treating " " as last) when reconstructing document order.

Who Files or Publishes This Dataset, and When

Who files the record

Each POS462B is a post-effective amendment filed by the issuer/registrant that already has an effective Securities Act registration statement on file. The filing is made by the same registrant that filed the original statement, attached to the same 333- file number, and signed by the same officers and directors (or attorney-in-fact under existing powers of attorney). The form's purpose is to register additional securities of the same class as those covered by the earlier effective registration statement so that sales of those incremental securities comply with Section 5 of the Securities Act of 1933.

The filer is the issuer, not the underwriter. The underwriter's pricing-night decision to upsize or to exercise an over-allotment is the commercial driver, but the POS462B is the registrant's filing under the registrant's CIK.

Filing population

POS462B is exclusively a Securities Act device used by operating-company-style registrants. Typical filers include:

  • Domestic operating companies pricing an IPO or follow-on off a Form S-1 or S-3.
  • Foreign private issuers pricing off a Form F-1 or F-3.
  • Real estate and similar issuers using Form S-11.
  • Issuers in firm-commitment underwritten deals whose underwriting agreement contains a Rule 10b-21 / Regulation M over-allotment ("green shoe") option, where exercise or upsizing pushes the aggregate offering above the dollar amount originally registered.

The dataset does not include investment company filings (1940 Act registrants use Rule 485 amendments such as 485APOS / 485BPOS) or BDC N-2 amendments.

Triggering event

The form is event-driven, not periodic. It is triggered when the registrant determines, at or immediately before pricing, that additional securities of the same class must be registered beyond the amount in the earlier effective registration statement. Common trigger patterns:

  • Underwriter exercise (or anticipated exercise) of the over-allotment / green-shoe option that would cause aggregate sales to exceed the registered maximum aggregate offering price.
  • A pricing-night upsize where the issuer and bookrunners agree to sell more shares than were registered due to oversubscription.
  • A price increase between effectiveness and pricing that pushes the dollar value of the offering above what was previously registered, even at the same share count.
  • A last-minute secondary allocation adding shares of the same class at pricing.

Regulatory framework

  • Securities Act of 1933, Section 5: prohibits sales of unregistered securities and supplies the underlying obligation.
  • Rule 462(b): authorizes a registrant with a previously effective registration statement to register additional securities of the same class via an immediately effective filing, provided the additional securities do not exceed 20 percent of the maximum aggregate offering price in the "Calculation of Registration Fee" table of the earlier statement. The filing is effective on filing, not subject to staff review or Section 8(a) acceleration.
  • Rule 457: governs fee calculation, including Rule 457(o) for offerings registered on the basis of maximum aggregate offering price and Rule 457(r) for ASR pay-as-you-go takedowns. Rule 111 governs fee payment mechanics.
  • Rule 478: permits incorporation by reference of the earlier registration statement, so the POS462B body is short.
  • Item 512 of Regulation S-K: the standard undertakings carried forward into the amendment.

Because effectiveness is automatic, the registrant self-certifies on the facing page that the filing is made pursuant to Rule 462(b) and that the additional registered amount is within the 20 percent cap.

The 20 percent cap mechanics

The cap is measured in dollars (maximum aggregate offering price), not in shares, and is measured against the earlier registration statement's registered dollar amount, not against amounts actually sold. If the incremental dollar amount would exceed 20 percent, Rule 462(b) is unavailable and the issuer must use a conventional post-effective amendment or a new registration statement, neither of which is automatically effective.

Timing window

The filing is effective immediately upon EDGAR acceptance. Rule 462(b) requires transmission to EDGAR no later than the date of first sale of the additional securities. In practice:

  • Pricings occur after market close; allocations and the underwriting agreement are executed that evening.
  • The POS462B is filed the evening of pricing or in the early hours after pricing, almost always concurrently with the Rule 424(b) prospectus supplement for the deal.
  • The registration fee for the incremental securities is paid contemporaneously under Rule 111 / Rule 457.

The functional deadline is the moment of first sale of the additional securities; the practical window is the few hours between pricing and settlement.

Important distinctions

  • POS462B vs. "MEF" forms: A Rule 462(b) registration can alternatively be filed as a stand-alone short-form registration statement (S-1MEF, S-3MEF, F-1MEF, F-3MEF, S-11MEF) taking a new 333- file number. POS462B is the post-effective amendment variant attached to the original file number. Both rely on the same Rule 462(b) automatic-effectiveness mechanism and the same 20 percent cap.
  • POS462B vs. POS AM / POS AMI: POS AM and POS AMI are non-automatic, reviewable amendments used for substantive changes; they do not invoke Rule 462(b).
  • POS462B vs. Rule 462(c) and 462(d) filings: 462(c) covers automatic effectiveness for certain amendments to immediately effective statements; Rule 462(d) covers immediate effectiveness for exhibit-only amendments. Different mechanisms, different filings.
  • Investment companies: 1940 Act registrants use the Rule 485 regime (485APOS / 485BPOS), not POS462B.
  • WKSIs: Well-known seasoned issuers on an automatic shelf can register additional securities under Rule 413(b) with pay-as-you-go fees under Rule 456(b) / 457(r) without invoking Rule 462(b) at all. POS462B usage therefore skews to IPOs, follow-ons on Form S-1, and non-WKSI seasoned issuer deals.

How This Dataset Differs From Similar Datasets or Filings

Form POS462B occupies a narrow corner of the Securities Act registration framework defined by five properties at once: a post-effective amendment, filed by an operating-company issuer, that adds new securities of the same class as an earlier effective registration, capped at 20 percent of the original maximum aggregate offering price, and immediately effective upon filing. Each neighbor below shares some of those properties but breaks at least one.

S-1MEF, S-3MEF, F-1MEF, F-3MEF (freestanding Rule 462(b) registrations)

The MEF forms are the closest functional twins. They invoke the same Rule 462(b), share the same 20 percent cap, are limited to additional securities of the same class, and become effective immediately on filing. Issuers typically choose between them and POS462B during an upsize at or near pricing.

Distinction: form structure and file number. POS462B is styled as a post-effective amendment and keeps the file number of the underlying S-1/S-3/F-1/F-3. The MEF variants are freestanding new registration statements with their own file numbers that incorporate the prior registration by reference. The legal cap, immediate effectiveness, and same-class requirement are otherwise identical. To capture the full population of Rule 462(b) upsizes, pair POS462B with the four MEF datasets.

POS AM (general operating-company post-effective amendment)

POS AM is the catch-all post-effective amendment for operating-company registration statements. Both POS AM and POS AMI amend an already-effective registration.

Distinctions: (1) POS AM is generally not immediately effective and is subject to staff review or Commission order; (2) POS AM has no 20 percent cap and no same-class limitation; (3) POS AM is used for substantive disclosure updates, Section 10(a)(3) annual updates, adding offerings, or registering different classes of securities. POS462B is the mechanical, immediately-effective, capped, same-class subset.

Rule 462(d) post-effective amendments

Rule 462(d) amendments are also immediately effective without staff review, matching POS462B on timing.

Distinction: purpose. Rule 462(d) cannot register additional securities. It is reserved for technical, non-substantive changes (adding exhibits, clerical corrections). POS462B expands the registered offering size; 462(d) preserves it.

POS EX (exhibits-only post-effective amendment)

POS EX is the operational sibling to Rule 462(d): a post-effective amendment whose sole purpose is to add exhibits to an effective registration.

Distinction: POS EX registers no new securities, has no cap, and is dominated by legal exhibits. POS462B includes exhibits (opinions, consents, fee table) only as supporting documentation for the share-count expansion that is its actual purpose.

POS AMI and POS 8C (investment-company post-effective amendments)

POS AMI and POS 8C are post-effective amendments filed by investment companies and closed-end funds, respectively.

Distinction: filer population. Rule 462(b) and POS462B are operating-company instruments and do not apply to investment companies. POS AMI and POS 8C are useful only to confirm exclusion — any record in those datasets is, by definition, outside the POS462B population.

485APOS and 485BPOS (Rule 485 post-effective amendments)

485APOS (delayed effective date) and 485BPOS (immediately effective) are the Rule 485 post-effective amendments used by open-end funds, variable insurance products, and other investment-company registrants on Forms N-1A, N-3, N-4, and N-6.

Distinction: 485BPOS shares the immediate-effectiveness feature with POS462B, but lives under Rule 485 rather than Rule 462, applies to a different filer population, and has no 20 percent same-class cap. There is no operating-company analog to 485BPOS, and no investment-company analog to POS462B; the two regimes are parallel, not overlapping.

424B variants (prospectus supplements)

The 424B family (424B1 through 424B8, 424A) supplements the prospectus of an already-effective registration with pricing, plan of distribution, takedown, or risk-factor updates. They are frequently filed in the same pricing window as a POS462B.

Distinction: 424B filings update prospectus content; they do not register additional securities. A POS462B can raise the share ceiling; a paired 424B then reflects the final priced terms. Reconstructing an upsized deal typically requires both.

S-1, S-3, F-1, F-3 (underlying registration statements)

These are the base registrations that POS462B amends. They contain the full prospectus, financial statements, risk factors, and Securities Act disclosure package and undergo staff review (or automatic effectiveness for WKSI shelves).

Distinction: scope and content. POS462B is a thin overlay incorporating the base by reference; it adds only the incremental share count, updated fee table, opinions, and consents. The substantive offering documentation lives in the base form (and any 424B), not in the POS462B.

RW and AW (withdrawal requests)

RW (registration withdrawal) and AW (amendment withdrawal) remove filings from effectiveness or pending status.

Distinction: direction. RW and AW contract or terminate a registration; POS462B expands one. They share only the file-number lineage and are useful for assembling a full registration-statement history, not for identifying upsizes.

Boundary summary

POS462B is uniquely identified by the conjunction of all five properties: post-effective amendment + Rule 462(b) immediate effectiveness + 20 percent same-class cap + operating-company issuer + adds new securities. Drop any one property and a different form takes over:

  • Drop "post-effective amendment" (keep freestanding) — S-1MEF / S-3MEF / F-1MEF / F-3MEF.
  • Drop "immediate effectiveness" — POS AM.
  • Drop "20 percent same-class cap" — POS AM, or the underlying S-1/S-3/F-1/F-3.
  • Drop "adds new securities" — Rule 462(d) amendments, POS EX, or 424B supplements.
  • Drop "operating-company issuer" — POS AMI, POS 8C, 485APOS, 485BPOS.

The POS462B dataset is therefore the cleanest signal for operating-company offerings upsized at or near pricing through the post-effective-amendment branch of Rule 462(b). It is not a substitute for the base prospectus (use S-1/S-3/F-1/F-3 plus 424B) and does not cover the freestanding MEF branch of Rule 462(b) (pair with the MEF datasets for a complete Rule 462(b) view).

Who Uses This Dataset

The narrow mechanic of Form POS462B — additional securities of the same class, capped at 20 percent of the original maximum aggregate offering price, effective immediately on filing — concentrates the audience around pricing-day deal sizing, drafting precedent, and over-allotment tracking.

Equity capital markets bankers and syndicate desks

Used to flag IPOs and follow-ons that upsized at pricing or required incremental registration for green-shoe exercise. Bankers pull filedAt to align the amendment with the pricing date, entities to identify the issuer, and the fee calculation table for the additional shares and incremental aggregate offering price. The 333- file number ties the POS462B back to the underlying S-1 or S-3, letting them compute the percentage of the 20 percent headroom consumed. Output: upsize hit-rate analytics and league-table adjustments.

Securities lawyers and capital markets counsel

Used as a precedent library for drafting POS462B amendments. Counsel search prior filings for facing-page language, the Rule 462(b) recitation, legality opinions, and auditor consents tied to the additional securities. The fee calculation table and the underlying 333- reference are checked to verify 20 percent cap arithmetic and incorporation-by-reference wording. Output: first drafts, pricing-day filing checklists, and Rule 462(b) know-how.

Underwriters' counsel and syndicate operations

Used to track over-allotment mechanics where the green-shoe pushes the deal beyond what the base registration covers. They compare filedAt against the underlying registration's effective date, read the incremental share count from the fee table, and confirm signatory authority. Output: closing checklists and post-closing reconciliation of gross deal size against registered shares.

Offering market-data and league-table analysts

Used as a structured signal of upsizing and green-shoe exercise. Analysts ingest accessionNo, filedAt, entities, and fee-table line items to compute the share of IPOs invoking Rule 462(b), the average uptake of the 20 percent cap, and sector or season patterns. Output: IPO calendar reconstruction and reports comparing filed, priced, and final allotted size.

Issuer in-house counsel and corporate secretaries

Used both as sector precedent and to retrieve the company's own prior POS462B filings ahead of a new offering. They template from the facing page, incorporation-by-reference statement, signatures, and consent exhibits to shorten pricing-day turnaround.

Financial regulators and Commission staff

Used to monitor compliance with the 20 percent ceiling and to study how Rule 462(b) is invoked across issuers. The fee calculation table and the 333- file number tying back to the parent registration are the critical fields for verifying that the incremental aggregate offering price stays within the statutory cap. Aggregated counts inform policy review of the immediate-effectiveness mechanic.

Academic researchers in finance and securities law

Used in empirical studies of IPO underpricing, over-allotment exercise, and deal upsizing. POS462B is a clean indicator of pricing-day demand exceeding the filed size. Researchers merge filedAt, entities, the fee table, and the linked underlying registration with pricing and aftermarket data to build panel datasets.

Investment banking competitive intelligence

Used to attribute upsized deals to specific underwriting syndicates by cross-referencing entities and the underlying S-1 or S-3 (and its underwriting agreement exhibits). Output: pitch materials and benchmarking on which firms most often leave pricing headroom consumed via Rule 462(b).

EDGAR data engineering teams

Used to ingest POS462B as a discrete form type into filing warehouses. Engineers key off accessionNo, formTypes, filedAt, and documentFormatFiles to link each amendment to its parent registration accession via the 333- file number. The dataset also serves as a controlled corpus for fee-table parsing and incorporation-by-reference link resolution.

Specific Use Cases

IPO and follow-on upsize analytics

Build a panel of pricing-day upsizes by reading entities[].cik, entities[].tickers, and filedAt from metadata.json and joining each accession to its parent registration through entities[].fileNo (the underlying 333- number). Parse the incremental "amount being registered" and "proposed maximum aggregate offering price" out of the Calculation of Registration Fee table in the primary HTML, divide by the parent registration's original maximum aggregate offering price, and report the share of the 20 percent headroom consumed. Output: hit-rate dashboards of upsized IPOs by quarter, sector (entities[].sic), and lead underwriter.

Green-shoe and over-allotment monitoring

Detect cases where the over-allotment option pushed gross deal size beyond what the base registration covered. Filter to additive 462(b) records (multi-document accessions carrying an EX-5.1 opinion entry in documentFormatFiles[]), align filedAt to the underlying offering's pricing 424B, and use the fee-table delta as the registered green-shoe top-up. Output: closing-checklist reconciliation between gross allotted size and registered share count, plus a clean signal for empirical studies of shoe exercise.

Drafting precedent library for capital markets counsel

Search across primary POS462B HTML bodies for the Rule 462(b) recitation, incorporation-by-reference paragraph, Rule 478 short-form signature block, and matching EX-5.1 opinion and EX-23.1 consent exhibits. Filter precedents by entities[].stateOfIncorporation, entities[].sic, and underlying form type (recovered from the facing-page "POST-EFFECTIVE AMENDMENT NO. [N] TO FORM [S-1/S-3/F-1]" heading). Output: first-draft kits and pricing-day filing checklists keyed to comparable issuers.

20 percent cap compliance verification

Replay the statutory cap arithmetic across the dataset. For every additive record, extract the incremental aggregate offering price from the fee table, retrieve the parent registration's original maximum aggregate offering price via the fileNo lookup, and flag accessions where the incremental amount exceeds 20 percent. Output: an exception list for Commission staff review and an audit trail confirming that immediate effectiveness was properly invoked.

Deregistration and offering-termination tracking

Isolate the deregistration flavor of POS462B by selecting accessions with a single document and no EX-5.1 / EX-23.1 entries in documentFormatFiles[], then key on the "DEREGISTRATION OF SECURITIES" subtitle and Rule 478 boilerplate in the body. Capture the recited triggering event (completed offering, merger closing, abandonment) and the file number being closed out. Output: a registration-statement lifecycle table that pairs each base S-1/S-3 with its eventual termination, useful for shelf-utilization studies and corporate-action histories.

League-table-adjusted deal sizing

Adjust final deal-size attributions for upsizes that occurred after the base registration. Join POS462B filedAt and fee-table increments to deal records from S-1/S-3 plus paired 424B prospectus supplements, then recompute gross proceeds per syndicate. Output: corrected league-table credits that reflect the priced and registered size rather than the originally filed amount.

Empirical research on pricing-day demand

Use POS462B as a clean indicator of demand exceeding filed size on the day of pricing. Researchers merge filedAt, entities[].cik, the fee-table top-up, and the parent 333- registration with CRSP/Compustat pricing and aftermarket data to study underpricing, allocation, and shoe exercise. Output: panel datasets where Rule 462(b) invocation is a binary or continuous (percentage of cap consumed) covariate.

Filing-warehouse ingestion and fee-table parsing

Onboard POS462B as a discrete form type in an EDGAR pipeline. Engineers key on accessionNo, formType, and filedAt, traverse documentFormatFiles[] to materialize each .htm exhibit, and resolve incorporation-by-reference links by extracting the cover-page 333- number and joining back to the parent accession. The dataset doubles as a bounded corpus for training fee-table extractors, since the Calculation of Registration Fee table appears in a stable position on every additive filing.

Dataset Access

The Form POS462B Files Dataset is available through three access methods: a dataset index JSON API for metadata and container enumeration, a single archive download for the entire dataset, and individual container downloads for incremental retrieval.

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

This endpoint returns dataset-level metadata along with the list of all available container files. It does not require an API key. The response includes the dataset name, description, last update timestamp, earliest sample date (1995-07-01), total record count, total size, form types covered (POS462B), the container format (ZIP), and the file types contained within each container (TXT, JSON, HTML). Each container entry includes its download URL, object key, size, record count, and last updated timestamp. Use this endpoint to monitor which containers were refreshed in the most recent run and to decide which ones to fetch on a daily basis.

Example JSON response:

Example
1 {
2 "datasetId": "1f13365b-9ae0-69e6-ba7e-60ec4605dc4b",
3 "datasetDownloadUrl": "https://api.sec-api.io/datasets/form-pos462b-files.zip",
4 "name": "Form POS462B Files Dataset",
5 "description": "Form POS462B filings are post-effective amendments to registration statements filed pursuant to Rule 462(b) under the Securities Act of 1933.",
6 "updatedAt": "2026-04-15T18:10:31.024Z",
7 "earliestSampleDate": "1995-07-01",
8 "totalRecords": 634,
9 "totalSize": 2994806,
10 "formTypes": ["POS462B"],
11 "containerFormat": "ZIP",
12 "fileTypes": ["TXT", "JSON", "HTML"],
13 "containers": [
14 {
15 "downloadUrl": "https://api.sec-api.io/datasets/form-pos462b-files/2026/2026-03.zip",
16 "key": "2026/2026-03.zip",
17 "size": 13818783,
18 "records": 154,
19 "updatedAt": "2026-03-21T02:51:19.000Z"
20 }
21 ]
22 }

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

Downloads the full dataset as a single ZIP archive containing all POS462B filing files since 1995. This endpoint requires an API key passed via the token query parameter.

Download Single Container: https://api.sec-api.io/datasets/form-pos462b-files/2026/2026-03.zip?token=YOUR_API_KEY

Downloads one monthly container ZIP file instead of the full dataset. Container paths follow the YYYY/YYYY-MM.zip convention and are listed in the dataset index JSON. This endpoint requires an API key.

To enumerate and fetch containers programmatically, retrieve the dataset index, iterate over the containers array, and download each downloadUrl with your API key appended.

Python example:

1 import requests
2
3 API_KEY = "YOUR_API_KEY"
4 INDEX_URL = "https://api.sec-api.io/datasets/form-pos462b-files.json"
5
6 index = requests.get(INDEX_URL).json()
7
8 for container in index["containers"]:
9 url = f"{container['downloadUrl']}?token={API_KEY}"
10 response = requests.get(url)
11 filename = container["key"].replace("/", "_")
12 with open(filename, "wb") as f:
13 f.write(response.content)
14 print(f"Downloaded {container['key']} ({container['records']} records)")

Bash example using curl and jq:

1 API_KEY="YOUR_API_KEY"
2 curl -s https://api.sec-api.io/datasets/form-pos462b-files.json \
3 | jq -r '.containers[].downloadUrl' \
4 | while read url; do
5 curl -O "${url}?token=${API_KEY}"
6 done

Frequently Asked Questions

What form does this dataset cover?

The dataset covers EDGAR form type POS462B — post-effective amendments to registration statements filed pursuant to Rule 462(b) of the Securities Act of 1933. Both flavors of POS462B accession appear: additive 462(b) registrations that add new securities of the same class, and deregistration/termination amendments that close out unsold securities on a prior 462(b)-related registration.

What does one record in the Form POS462B Files Dataset represent?

One record is one complete EDGAR submission — one accession — for a POS462B filing. The record unit is the accession, not the EDGAR filing-index page and not an individual exhibit; every document the registrant submitted under that accession number (other than image binaries) is included, alongside a parsed metadata.json header.

Who is required to file Form POS462B?

The form is filed by the issuer/registrant that already has an effective Securities Act registration statement, typically domestic operating companies pricing an IPO or follow-on off Form S-1 or S-3, foreign private issuers on F-1 or F-3, and real estate or similar issuers on S-11. Investment companies do not use POS462B; 1940 Act registrants file under the Rule 485 regime (485APOS, 485BPOS) instead.

When are POS462B filings submitted to EDGAR?

The filing is event-driven and tied to pricing. It is transmitted to EDGAR no later than the date of first sale of the additional securities, and in practice is filed the evening of pricing or in the early hours after pricing, almost always concurrently with the Rule 424(b) prospectus supplement for the deal. The filing is immediately effective on acceptance, with no Staff review or acceleration request.

What time period does the dataset cover?

The dataset covers all POS462B accessions on EDGAR from July 1995 (the inception of mandatory EDGAR filing) through the present, with the earliest sample dated 1995-07-01. Volume is modest because Rule 462(b) is itself narrow.

What file formats are in each record?

Each accession folder contains a metadata.json header (always present), the SGML-wrapped .htm/.html submission documents the registrant filed, and, where present, the EDGAR complete-submission .txt concatenation. Containers are distributed as monthly ZIPs named YYYY-MM.zip. Image attachments (.jpg, .gif) and XBRL files are deliberately excluded.

How does this dataset differ from the MEF datasets (S-1MEF, S-3MEF, F-1MEF, F-3MEF)?

The MEF forms are the closest functional twins: they invoke the same Rule 462(b), share the same 20 percent cap, are limited to additional securities of the same class, and are immediately effective. The structural difference is that POS462B is styled as a post-effective amendment and keeps the file number of the underlying S-1/S-3/F-1/F-3, while the MEF variants are freestanding new registration statements with their own 333- file numbers. To capture the full population of Rule 462(b) upsizes, pair this dataset with the four MEF datasets.

How do I distinguish additive POS462B filings from deregistration filings?

The form-type code alone does not distinguish them — both carry formType: "POS462B". The flavor can be inferred from the document count in documentFormatFiles[]: additive records are multi-document and typically include EX-5.1 (legality opinion) and EX-23.1 (auditor consent) entries plus a Calculation of Registration Fee table in the body, while deregistration records are usually single-document, carry no exhibits, and contain a "DEREGISTRATION OF SECURITIES" explanatory note in the primary HTML body.