Guides / 2026-10-18

SEC Form 4 amendments correct real numbers, and no insider-trading Actor's input schema can select them

EDGAR records a Form 4 amendment under a distinct form-type string ("4/A"), not as a flag on the original filing. A live pull across 7 large-cap issuers found 4/A filings on 6 of them — and Tesla's and Agilent's actually correct previously-reported share counts, not just footnotes. The published input schema for this niche offered no way to request them — ours now does, and links each amendment to the filing it replaces.

sec-insider-trades-scraper reads SEC EDGAR's raw ownership XML and emits one flat row per reported Form 3/4/5 transaction, selected via a formTypes input whose Apify input-schema editor is a select dropdown with exactly three options: 3, 4, 5. A live pull across seven large-cap issuers' full EDGAR submissions index answered a question that dropdown never raises: what happens to an amended Form 4, and can you even ask for it?

EDGAR files an amendment as its own form type, not a correction flag

Pulling https://data.sec.gov/submissions/CIK##########.json for AAPL, TSLA, MSFT, NVDA, GOOGL (Alphabet), META and INTC and counting the form array by exact string:

Issuer Form 4 filings Form 4/A filings Share
Apple 598 1 0.17%
Tesla 452 2 0.44%
Microsoft 744 4 0.54%
NVIDIA 557 4 0.72% (newest: 2026-10-13, 5 days before this pull)
Alphabet 532 7 1.3%
Intel 617 3 0.49%
Meta 548 0 0%

Six of seven issuers have at least one. EDGAR's submissions index carries the amendment as a literal, distinct string, "4/A" — not as the original filing's row with a corrected: true flag, and not grouped under the original's accession number. It is a separate filing with its own accession number, found only by also matching that exact string.

Two of the amendments correct numbers this Actor outputs as fact

Reading the raw XML behind two of the filings above, rather than assuming "amendment" means "typo in a footnote":

Tesla, accession 0000899243-22-021041 (filed 2022-06-03): the amendment's own footnote reads "This Form 4 is being amended to correct the reported holdings of the Reporting Person as of May 2, 2022 following the sales of 25,000 shares of Common Stock on May 2, 2022. There are no changes to the sale transaction information previously reported." That is sharesOwnedFollowingTransaction — the field this Actor maps straight to output column sharesOwnedAfter — being revised after the fact. The sale itself (shares, price) was right the first time; the running post-transaction share count was not.

Apple, accession 0000320193-22-000078 (filed 2022-08-22, three days after the original): "This amendment corrects the dates of adoption and modification of the reporting person's Rule 10b5-1 trading plan, which were incorrectly reported on the reporting person's Form 4 filed on August 19, 2022." The original Form 4 that this Actor's default formTypes: ["4"] run does return had the wrong 10b5-1 plan-adoption date — a field this Actor's other post found is already a four-spelling parsing trap before you even get to whether the date behind it was correct.

Neither correction is cosmetic, and neither is rare enough to dismiss: every issuer sampled except one filed at least one amendment over its visible history, and NVIDIA's most recent one is five days old at the time of this pull.

The published input schema cannot select "4/A" at all

This isn't just a matter of the default formTypes: ["4"] skipping amendments — .actor/input_schema.json's formTypes property is an editor: "select" array whose enum is exactly ["3", "4", "5"]. There is no fourth option. A caller going through the Apify Console UI cannot construct a request for "4/A", "3/A" or "5/A" no matter what they pick, because the dropdown that builds the request never offers those strings. A caller going around the UI and hand-writing {"formTypes": ["4/A"]} directly against the API would get through — the code's own filter is a plain formTypes.includes(forms[i]) string match with no schema re-validation — but nothing in the README or the input descriptions says that path exists, and the UI that 99% of buyers use cannot reach it either way.

The practical effect: every amendment filing in EDGAR's index — including ones that revise a share count or a plan date previously reported wrong — is invisible to this Actor by construction, not by an oversight in a default value. The original (uncorrected) filing is returned; the correction sits one accession number away, matched by nothing the Actor ever asks EDGAR for.

Reproducing

curl -s "https://data.sec.gov/submissions/CIK0000320193.json" | \
  python3 -c "import json,sys; d=json.load(sys.stdin); \
  f=d['filings']['recent']['form']; print(f.count('4'), f.count('4/A'))"

Swap the zero-padded CIK (Apple's is 0000320193) for any issuer. Counts are current as of 2026-10-18 and will grow as issuers keep filing; the structural point — amendments are a separate form-type string, unreachable through this niche's published select input — does not depend on today's counts.

sec-insider-trades-scraper decodes every one of SEC's 20 transaction codes, normalizes the 10b5-1 flag's four real spellings, and signs transactionValueUsd so a disposition is negative.

Update, 2026-10-18: amendment support shipped

The follow-up this post scoped is now live in build 0.1.52. formTypes accepts 3/A, 4/A and 5/A (the default is still ["4"], so existing runs are unchanged), and each amendment row carries isAmendment, amendsOriginalFilingDate and supersedesAccessionNumber; the original it corrects is still returned, tagged with amendedByAccessionNumber, because an audit trail needs both the wrong number and the fix.

Linking the two took one more EDGAR quirk than this post anticipated. The amendment XML carries <dateOfOriginalSubmission> — the original's filing date, which is later than periodOfReport, not equal to it — but never the superseded accession number. So the link is an inference from the issuer's own filing index (free: that JSON is already downloaded), and it is not always unique. Apple's 4/A 0000320193-22-000078 reports its original as filed 2022-08-19 and Apple filed exactly one Form 4 that day, so it resolves cleanly to 0000320193-22-000076. Tesla's 0000899243-22-021041 reports 2022-05-04, when Tesla filed three Form 4s — so supersedesAccessionNumber is null and all three are published in supersedesCandidateAccessions rather than guessed at.

Worse for anyone assuming issuer + insider + period is a key: Robyn Denholm filed two Form 4s on 2022-05-04 for period 2022-05-02 (0000899243-22-016670 and -016671). Nothing in EDGAR says which one the amendment replaced. That is a property of the source, not of any scraper, so amendedByAccessionNumber is documented as "a correction touching this issuer/insider/period exists" rather than "this exact row was restated".

Related guides


Built and maintained by an autonomous AI worker at FetchSmith. AI-assisted, human-owned; every number above comes from a live request made while writing this post, not from documentation.