Strasmore Research
Deep Dives · Matt ConnorBy Matt Connor · · Updated 2026-07-25

SEC EDGAR 申報索引月末缺口

2026年3月31日、4月30日與6月30日，SEC申報索引近乎空白，僅十幾份文件，與相鄰工作日數千份形成強烈對比，且缺口僅發生在月末落在週間的月份。

一個月的最後一個交易日，通常是 SEC 申報索引最繁忙的日子之一——該索引記錄了公司向監管機關提交的每一份文件。到了 2026 年，這個索引卻有三次幾乎是空的。3 月 31 日、4 月 30 日與 6 月 30 日，各自只有寥寥十幾份申報，而前後相鄰的日子卻有數千份，而且這個模式完全跟著日曆走：2026 年裡，凡是月曆最後一天落在週間的月份，全都出現申報缺口；凡是月曆最後一天落在週末的月份，則完全正常。下方內容包括：實際收件記錄、界定問題發生時間點的收件時間戳、先前一個出現相同情況的日子，以及觸及這些日期的申報數量所代表的意義。

這個缺口最初是在我們整理第 2 季回顧與上半年回顧時，以季末問題的形式浮現——這也是本頁網址的由來。進一步追查後，我們將其重新界定為月末問題；本頁內容會在同一網址下就地更新。

哪些日期缺失

查詢2026年各月最後工作日申報筆數，並以去年同期工作日月底為對照
每個數據背後的精確 SQL 語法
SELECT d, filings, month_ends_on FROM (
    SELECT '2026-01-30' AS d, (SELECT uniqExact(accession_number) FROM global_markets.stocks_sec_edgar_index WHERE filing_date = toDate('2026-01-30')) AS filings, 'Saturday' AS month_ends_on, 1 AS ord
    UNION ALL SELECT '2026-02-27', (SELECT uniqExact(accession_number) FROM global_markets.stocks_sec_edgar_index WHERE filing_date = toDate('2026-02-27')), 'Saturday', 2
    UNION ALL SELECT '2026-03-31', (SELECT uniqExact(accession_number) FROM global_markets.stocks_sec_edgar_index WHERE filing_date = toDate('2026-03-31')), 'weekday (the gap day)', 3
    UNION ALL SELECT '2026-04-30', (SELECT uniqExact(accession_number) FROM global_markets.stocks_sec_edgar_index WHERE filing_date = toDate('2026-04-30')), 'weekday (the gap day)', 4
    UNION ALL SELECT '2026-05-29', (SELECT uniqExact(accession_number) FROM global_markets.stocks_sec_edgar_index WHERE filing_date = toDate('2026-05-29')), 'Sunday', 5
    UNION ALL SELECT '2026-06-30', (SELECT uniqExact(accession_number) FROM global_markets.stocks_sec_edgar_index WHERE filing_date = toDate('2026-06-30')), 'weekday (the gap day)', 6
    UNION ALL SELECT '2025-09-30', (SELECT uniqExact(accession_number) FROM global_markets.stocks_sec_edgar_index WHERE filing_date = toDate('2025-09-30')), 'weekday, full in the prior year', 7
    UNION ALL SELECT '2025-12-31', (SELECT uniqExact(accession_number) FROM global_markets.stocks_sec_edgar_index WHERE filing_date = toDate('2025-12-31')), 'weekday, full in the prior year', 8
) ORDER BY ord

規律直接沿著面板往下讀。1月的最後一個工作日承載 4332 申報，2月的最後一個工作日承載 7870 —— 這兩個月的最終日曆日都落在星期六，因此最後一個工作日落在月內倒數一兩天。接著是3月31日的 55、4月30日的 34，再回到5月29日的 5527（5月結束於星期日），以及6月30日的 31。前一年度的對照組落在 3460 與 2289 申報 —— 同樣的工作日月末型態，完整填滿。只有在2026年某個月份的最終日曆日本身就是工作日時，才會出現近乎空白的狀況，而且僅限於此。

用白話說，這個洞到底有多大

只看原始件數會低估這次的劇烈程度。以下是自 2020 年以來，每個落在週間的月底，且申報件數低於一千件的日子，各自與其前後五日內指數日的平均值對比。

查詢2020年以來申報筆數低於1,000筆的各工作日月底——筆數、涉及公司數及鄰近日均值
每個數據背後的精確 SQL 語法
WITH daily AS (
    SELECT
        filing_date,
        uniqExact(accession_number) AS filings,
        uniqExact(cik) AS companies,
        max(_ingest_time) AS last_arrived
    FROM global_markets.stocks_sec_edgar_index
    WHERE filing_date >= toDate('2019-12-20') AND filing_date <= toDate('2026-07-06')
    GROUP BY filing_date
),
month_ends AS (
    SELECT arrayJoin(arrayMap(i -> toLastDayOfMonth(addMonths(toDate('2020-01-01'), i)), range(78))) AS me
),
sparse AS (
    SELECT
        e.me AS me,
        toUInt32(ifNull(d.filings, 0)) AS filings,
        toUInt32(ifNull(d.companies, 0)) AS companies,
        d.last_arrived AS last_arrived
    FROM month_ends AS e
    LEFT JOIN daily AS d ON d.filing_date = e.me
    WHERE toDayOfWeek(e.me) <= 5 AND toUInt32(ifNull(d.filings, 0)) < 1000
)
SELECT
    toString(s.me) AS month_end,
    any(s.filings) AS filings,
    any(s.companies) AS companies,
    toUInt32(round(avgIf(n.filings, abs(dateDiff('day', n.filing_date, s.me)) <= 5 AND n.filing_date != s.me))) AS neighbour_day_avg,
    round(100 * any(s.filings) / avgIf(n.filings, abs(dateDiff('day', n.filing_date, s.me)) <= 5 AND n.filing_date != s.me), 1) AS pct_of_normal,
    toString(toDate(any(s.last_arrived))) AS last_row_arrived
FROM sparse AS s
CROSS JOIN daily AS n
GROUP BY s.me
ORDER BY s.me

六年半裡只有 6 天。2026 年的三個日子墊底：6 月 30 日有 31 件申報，而鄰近日的平均值是 4443 件——僅為正常日的 0.7%，短少幅度超過 99%。4 月 30 日落在 0.6%，3 月 31 日則是 1.2%。若以公司數而非文件數來看：2026 年 6 月 30 日當天，整個指數只列出 27 家不同的申報人。

另外三列則說明了這並非一個單純「只有 2026 年」的故事。其中兩天是普通的聯邦休市日：2021 年 5 月 31 日是陣亡將士紀念日，2021 年 12 月 31 日是 2022 年元旦的聯邦假日（1 月 1 日落在週六）。EDGAR 遵循聯邦假日曆，因此這兩天近乎歸零的件數——0 件和 1 件——反映的是申報窗口關閉的樣貌，而非系統缺陷。

第三列則很有意思。2025 年 4 月 30 日有 928 件申報，是鄰近日的 19.1%——部分缺漏，並非完全空白。這是自 2020 年以來，唯一一個遠低於正常水準、卻沒有假日可以解釋的週間月底，而且比 2026 年的三個低谷早了一年：是同一種邊界行為的較溫和版本，大約是正常日的五分之一，而不是百分之一。

2020年以來每個月末

查詢2020年以來各工作日月底：以當月最後日曆日為索引的申報筆數
每個數據背後的精確 SQL 語法
WITH month_ends AS (
    SELECT arrayJoin(arrayMap(i -> toLastDayOfMonth(addMonths(toDate('2020-01-01'), i)), range(78))) AS me
),
daily AS (
    SELECT filing_date, uniqExact(accession_number) AS filings
    FROM global_markets.stocks_sec_edgar_index
    WHERE filing_date >= toDate('2020-01-01') AND filing_date <= toDate('2026-06-30')
    GROUP BY filing_date
)
SELECT toString(e.me) AS month_end, toUInt32(ifNull(d.filings, 0)) AS filings
FROM month_ends AS e
LEFT JOIN daily AS d ON d.filing_date = e.me
WHERE toDayOfWeek(e.me) <= 5
ORDER BY e.me

這條長序列是整個論證的對照組。在2020年1月至2026年6月間的 55 個週日月末中，線條在數千筆的水準持平，然後在右側邊緣急墜。一個月的最後一個週日本身並不會讓申報量變得稀少——截止日正是集中在這一天。

消失的那一天究竟少了什麼

查詢缺口日（2026年6月30日）與前一交易日之申報類型分布
每個數據背後的精確 SQL 語法
SELECT
    form_type,
    uniqExactIf(accession_number, filing_date = toDate('2026-06-29')) AS normal_day_jun29,
    uniqExactIf(accession_number, filing_date = toDate('2026-06-30')) AS gap_day_jun30
FROM global_markets.stocks_sec_edgar_index
WHERE filing_date IN (toDate('2026-06-29'), toDate('2026-06-30'))
GROUP BY form_type
ORDER BY gap_day_jun30 DESC, normal_day_jun29 DESC, form_type
LIMIT 14

這張表直接點出缺陷所在。6 月 30 日當天有任何資料列的表單都列在上方：15 EFFECT 則通知——也就是 SEC 自行發出的註冊聲明生效確認——加上市政顧問註冊、發行資格與交易場所通知。這些都是 SEC 系統產出的文件，不是公司提交的文件。構成正常交易日大宗的所有表單類型，全都顯示 0 列：926 424B2 份公開說明書補充文件出現在 6 月 29 日，隔天卻一份都沒有；595 筆內部人交易申報的 Form 4 在 6 月 29 日出現，隔天卻一筆都沒有；223 8-K 份公司事件報告在 6 月 29 日出現，隔天卻一份都沒有。一個季末的星期二，8-K 申報掛零、內部人申報表掛零，這不是市場現象，而是遺失的檔案。

當資料列送達時

查詢6月26日至前沿期間，每日資料實際入庫時間
每個數據背後的精確 SQL 語法
SELECT
    toString(filing_date) AS d,
    uniqExact(accession_number) AS filings,
    formatDateTime(min(_ingest_time), '%Y-%m-%d %H:%i') AS first_arrived
FROM global_markets.stocks_sec_edgar_index
WHERE filing_date >= toDate('2026-06-26') AND filing_date <= toDate('2026-07-10')
GROUP BY filing_date
ORDER BY filing_date

送達時間戳記是這裡最接近指紋的東西。6月每一天直到29日的資料，都在同一個作業中送達倉儲——2026-07-01 09:38 UTC，單一批次涵蓋了整個月份。6月30日則在隔天早上單獨送達，時間為2026-07-02 09:12，攜帶了31筆行政資料列，而它前一天的那筆則攜帶了4439筆。3月與4月的邊界日也呈現完全相同的模式，只是提早了一個月。

查詢狀態接收：3月與4月交界日、其到達時間及本次執行時之筆數
每個數據背後的精確 SQL 語法
SELECT
    (SELECT toString(toDate(min(_ingest_time))) FROM global_markets.stocks_sec_edgar_index WHERE filing_date = toDate('2026-04-01')) AS apr1_first_arrived,
    (SELECT toString(toDate(min(_ingest_time))) FROM global_markets.stocks_sec_edgar_index WHERE filing_date = toDate('2026-04-30')) AS apr30_first_arrived,
    (SELECT uniqExact(accession_number) FROM global_markets.stocks_sec_edgar_index WHERE filing_date = toDate('2026-03-31')) AS mar31_filings_now,
    (SELECT uniqExact(accession_number) FROM global_markets.stocks_sec_edgar_index WHERE filing_date = toDate('2026-04-30')) AS apr30_filings_now,
    (SELECT uniqExact(accession_number) FROM global_markets.stocks_sec_edgar_index WHERE filing_date = toDate('2026-06-30')) AS jun30_filings_now,
    (SELECT uniqExact(form_type) FROM global_markets.stocks_sec_edgar_index WHERE filing_date = toDate('2026-06-30')) AS jun30_form_types

4月1日的資料列首次送達時間為2026-05-01——這是4月的月度批次，在5月交接時執行。4月30日的資料列則在2026-05-02送達，比理應包含它們的批次晚了一天。這一天的差距本身就是一個數字就能說明的完整診斷：載入一個月份的作業，在月底前一天就停止了，而邊界日則由另一條顯然不完整的路徑拾取。當月份的最後一個日曆日是週末時，這個遺漏不會造成任何損失（因為沒有東西需要申報），而當它是交易日時，該月份最繁忙的交易日之一，就會被換成零散分布在6種申報表格類型中的幾份SEC發布的通知。

這個差一格的邊界究竟存在於供應商的資料管線中，還是存在於我們對其的攝取過程中，從這個倉儲內部無法判定——要解決這個問題，需要那三個日期的SEC原始每日索引檔案進行比對，而本頁面無法執行這項比對。收據所能確定的是：有三個特定日期無法用於申報數量統計。

截至本次修訂的狀態

尚未修正。本頁所有計數在每次頁面生成時重新計算，截至本次執行，3月31日仍顯示 55 筆申報，4月30日 34 筆，6月30日 31 筆——這些是該缺口首次記錄時所擷取的數字。其餘索引狀態正常：2026-07-10 載有 2198 筆申報，如期送達。此處的合理性邊界將這三天維持在近乎為零的數值，因此一旦回補資料就會觸發邊界，強制重新生成。

還有其他遺漏嗎？

一個載入器的邊界錯誤，不代表其他載入器也有問題。倉庫裡還有其他地方在 6 月 30 日這天資料量偏少嗎？

查詢2026年6月30日是否在其他地方缺失？五個日期鍵結資料集中同一日的比對
每個數據背後的精確 SQL 語法
SELECT dataset, jun29, jun30 FROM (
    SELECT 'SEC filing index (filings)' AS dataset,
        (SELECT uniqExact(accession_number) FROM global_markets.stocks_sec_edgar_index WHERE filing_date = toDate('2026-06-29')) AS jun29,
        (SELECT uniqExact(accession_number) FROM global_markets.stocks_sec_edgar_index WHERE filing_date = toDate('2026-06-30')) AS jun30, 1 AS ord
    UNION ALL SELECT 'Minute bars (tickers)',
        (SELECT uniqExact(ticker) FROM global_markets.delayed_stocks_minute_aggs WHERE window_start >= toDateTime('2026-06-29 04:00:00') AND window_start < toDateTime('2026-06-30 04:00:00')),
        (SELECT uniqExact(ticker) FROM global_markets.delayed_stocks_minute_aggs WHERE window_start >= toDateTime('2026-06-30 04:00:00') AND window_start < toDateTime('2026-07-01 04:00:00')), 2
    UNION ALL SELECT 'Dividends (ex-div records)',
        (SELECT count() FROM global_markets.stocks_dividends WHERE ex_dividend_date = toDate('2026-06-29')),
        (SELECT count() FROM global_markets.stocks_dividends WHERE ex_dividend_date = toDate('2026-06-30')), 3
    UNION ALL SELECT 'News articles',
        (SELECT count() FROM global_markets.stocks_news WHERE toDate(published_utc) = toDate('2026-06-29')),
        (SELECT count() FROM global_markets.stocks_news WHERE toDate(published_utc) = toDate('2026-06-30')), 4
    UNION ALL SELECT 'Treasury curve rows',
        (SELECT count() FROM global_markets.treasury_yields WHERE date = toDate('2026-06-29')),
        (SELECT count() FROM global_markets.treasury_yields WHERE date = toDate('2026-06-30')), 5
) ORDER BY ord

沒有。分鐘線資料涵蓋 11982 檔標的（6 月 30 日），相較前一天的 11903 檔；704 筆除息紀錄、215 篇新聞文章，以及完整的公債殖利率曲線，當天也都有進倉。只有申報索引——31 筆對比 4439 筆——出現缺口。週報回顧記錄了當日交易明細：2026 年 6 月 30 日是星期二，全天正常交易。

以申報文件數量來看的意義

任何統計區間若涵蓋2026年3月31日、4月30日或6月30日，其數據都會被低估，且誤差幅度遠不止於捨入誤差：三個申報量極大的日子被近乎歸零的數字所取代。這會削減3月、4月及6月的月度總量、第1季與第2季的季度總量，以及上半年總量。我們自家的6月回顧在發布申報數量時，已將此揭露事項一併附上，同樣的但書也適用於你向任何終端機（包括我們的終端機）查詢涉及這些日期的申報數量問題。若查詢2026年各月份的申報量，六個答案中有三個會短少約一整天的文件量。

各類申報文件簡介

  • 8-K — 公司事件報告：企業向市場通報某項已發生的事件。
  • Form 4 — 內部人（高階主管、董事、大股東）申報其自身持股的交易。
  • 10-Q — 季度財務報告。
  • 424B2 — 公開說明書補充文件：證券發行的定價文件。
  • NPORT-P — 基金每月投資組合持倉報告。
  • EFFECT / QUALIF / MA-I / ATS-N — SEC 自有系統產生的行政通知：註冊生效、發行資格取得、市政顧問註冊、交易場所申報揭露。這些是空窗期內仍存留的類型。哪些 SEC 申報文件最常出現 詳細分析了整體分布狀況。

常見問題

SEC EDGAR 申報索引的缺口修復了嗎？

截至本次修訂為止尚未修復。我們索引副本中，2026年3月31日、4月30日及6月30日仍分別載有 55、34 與 31 筆申報記錄。本頁面會在數據變動時自動重新生成，其合理性檢查邊界設定為：一旦發生回補即觸發失敗——這正是公開原始數據而非備忘錄的用意所在。

這是否意味著 SEC 遺失了申報文件？

否。文件確實存在於 EDGAR 系統上；缺失的是其下游副本中一整天的索引記錄——送達時間顯示載入程式按時運行，卻只載入了近乎空白的單日數據。這個偏差究竟出在數據供應商還是我們載入環節，需要取得 SEC 該三日的官方每日索引檔案才能釐清。

什麼是 SEC EDGAR 申報索引？

EDGAR 是 SEC 的公開申報系統，其每日索引會列出當日提交的每一份文件：公司名稱、表格類型、唯一識別該申報的登錄編號，以及文件連結。它是所有申報統計的基礎——包括內部人交易篩選、8-K 事件推送、公開說明書追蹤等。

2026年6月30日缺少了哪些表格類型？

所有公司提交的表格類型。當日僅有 6 種表格類型，全部為 SEC 自動生成的行政通知。前一交易日的 926 份 424B2 申報、595 份 Form 4 內部人報告，以及 223 份 8-K 事件報告，在該缺口日均降至 0。

2026年之前發生過類似情況嗎？

發生過一次，程度較輕。2025年4月30日的申報量僅為正常交易日的 19.1%——屬於部分缺失而非完全空白，且無法以任何假日解釋。自2020年以來，其他低於1,000筆的平日月底僅有2021年5月31日（陣亡將士紀念日）與2021年12月31日（元旦聯邦假日），兩者均為真正的休市日，而非數據異常。

方法說明

  • 所有計數均以登錄編號去重：同一份申報文件可能歸入多個實體名下。
  • 「鄰近日均值」係指該日前後五個日曆日內所有指數日的計數平均值，不含該日本身。
  • 送達時間採用本資料庫自身的 _ingest_time 數值，而非 SEC 標示的時間——衡量的是本頁讀者實際經歷的資訊傳遞過程。
  • 週間月終日係指每個月最後一個落在週一至週五的日曆日；其中兩天為聯邦假日，已於上方標註。
  • 本註記採原地更新；原先以季末為框架的呈現方式，已由同一網址上的月終證據所取代。每一項數字均為儲存查詢的結果，每次重新生成時皆經由唯讀管制路徑重新執行——你可自行在 Strasmore 終端機上執行相同的查詢。
#sec filings#edgar#data quality#forensics