The Filings EDGAR's Live Feed Won't Show You Until Tomorrow

On the evening of September 3, 2026, a news pipeline I run over live SEC filings scored 114 8-Ks in the two hours ending at 4:00 pm Eastern, 61 in the window ending at 4:15, 34 at 4:30, 24, 14, 5, and then zero. It stayed at zero for every 15-minute run until it shut down for the night at 10:00 pm. By the next morning, the same database held eleven 8-Ks and 6-Ks accepted between 6:30 and 10:00 pm that night, including Flex's 9:40 pm filing (accession 0001193125-26-382492) and News Corp's at 9:12 pm (0001564708-26-000195). Every one of them carried a real acceptance timestamp. None of them had been visible while the evening was happening.

I went back through three months of runs and found the same shape every single night since the pipeline launched in June. If you poll EDGAR's current-filings feed for anything, an alerting bot, a research cache, a training-data crawler, you are running on the same feed, and it has the same hole. This post is what I learned about the hole and the three traps I fell into on the way to understanding it.

What the SEC EDGAR current filings feed withholds

EDGAR's public live feed is the getcurrent page, an Atom feed of the most recent acceptances, newest first, one hundred per page. It is the source behind every way of getting SEC filings that claims to be real-time, including EdgarTools' own get_current_filings().

What the feed lists is filings by their filing date, and filing date is not acceptance time. Regulation S-T Rule 13 says a submission received after 5:30 pm Eastern is deemed filed on the next business day. So an 8-K accepted at 8:15 pm on Friday, August 28 is dated Monday, August 31, and EDGAR does not put Monday-dated filings on Friday's live feed while they are arriving. It holds them and releases the batch later. Breeze Acquisition Corp. II's restatement 8-K (0001213900-26-095265) is exactly that case: accepted 2026-08-28 20:15:23, filed 2026-08-31.

Both clocks are in the SGML header of every filing, and EdgarTools reads them:

from edgar import Filing, set_identity
set_identity("Your Name your@email.com")

f = Filing(form="8-K", filing_date="2026-08-31",
           company="Breeze Acquisition Corp. II",
           cik=2095443, accession_no="0001213900-26-095265")

h = f.header
print(h.acceptance_datetime)   # 2026-08-28 20:15:23
print(h.filing_date)           # 2026-08-31

A few forms keep a later cutoff. Section 16 forms (3, 4, 5), Rule 144 notices, and since 2024 Schedules 13D and 13G are deemed filed the same day if received by 10:00 pm. That detail matters for the trap below, because it means the evening feed is not empty, it is selectively empty: insider forms keep flowing in real time while the 8-Ks accepted in the same minutes are held.

The rule is public and old. What I had not internalised is what it does to a pipeline that assumes the feed is a stream of acceptances in order.

Trap one: the timestamps are Eastern, and they compare as strings

The <updated> element on each feed entry is the acceptance time with an Eastern offset: 2026-08-28T20:15:23-04:00. I stored it verbatim, which is the right thing to do, and then queried it with a UTC bound, which is not.

The database compared accepted >= since lexicographically. A UTC since of 2026-08-28T22:00:00Z sorts after 2026-08-28T20:15:23-04:00 even though the second instant is later in real time, because 20 comes before 22 as text. For a two-hour trailing window that skew is larger than the window, so the query returned nothing, always, and it did so silently.

The fix that shipped pads the query bound by six hours and applies the real bound client-side on Date.parse, which handles both the offset form and the Z form. The lesson generalises: if you keep the feed's strings, never let a string comparison stand in for a time comparison, and never trust an empty result from a time-windowed query without checking the bound against one known row.

Trap two: the release is a burst, and page zero is a hundred rows

When EDGAR releases the held filings it does not trickle them. On July 30 it released 288 next-day-dated entries in one go, starting around 8:24 pm, and because each carries its true acceptance time they land interleaved among the same-day filings already captured across that span, rather than at the top of the feed.

My poller fetched one page of 100 every ten seconds and drained further pages only when every entry on page zero was new. A burst of 288 arriving among held rows never trips that: the poll that saw it had 49 new entries out of 100, so the drain stayed off and the poller kept what fit on page zero. It captured the newest 120 and lost the oldest 168, with 163 of the 168 misses strictly older than every captured entry, which is textbook newest-first truncation. The misses ran from 5:31:25 pm, one minute past the cutoff, to 8:29 pm. Over a month that was about 170 filings a night, recovered roughly 37 hours later by a reconciler against the daily index, or 85 hours over a weekend.

The overflow test now fires when the page is saturated and the oldest entry on it is new, which is the signature of a delayed release landing under rows you already hold, and cannot false-positive in steady state because new arrivals are always newer than everything held. Since that change the reconciler finds three to sixteen missing filings a night instead of 170. If you page a newest-first feed, the question to ask is not "is everything new" but "is the bottom of the page new", because the bottom is where a backlog shows up.

Trap three: windowing on acceptance time

This is the one from the opening paragraph, and it survived the first two fixes. Once the poller was capturing the release reliably, the rows arrived with their true acceptance times, hours old. The pipeline's window was two hours of acceptance time. A filing accepted at 8:15 pm that lands in the database at 6:00 am is ten hours old on arrival and outside every window the pipeline will ever look at. It was never dropped, it was simply never eligible.

The tell was in the run logs the whole time: the number of filings in the window decayed to zero as the window's lower edge crossed 5:30 pm, night after night, because after that minute the feed had nothing dated today left to give. I had read those zeros as a quiet evening.

The fix is to window on when a row arrived, not when EDGAR accepted it. That means recording an insertion timestamp of your own, in UTC, and sweeping on that, which also retires the timezone padding from trap one. A row that lands at 6:00 am gets scored at 6:15 am whatever its acceptance time says.

Reading the two clocks in Python

If you are building on the feed rather than on a daily index, the practical rules are short. Keep both timestamps. Compare instants, not strings. Page to the bottom when the bottom is new. Window on your own arrival clock. And know which forms are still live after 5:30.

EdgarTools gives you the pieces. The live feed comes with the acceptance time already parsed as a datetime:

from edgar import get_current_filings, set_identity
from datetime import time
set_identity("Your Name your@email.com")

current = get_current_filings(form="8-K", page_size=100)
df = current.to_pandas()
# columns: form, company, cik, filing_date, accession_number, accepted

after_cutoff = df[df["accepted"].dt.time > time(17, 30)]
print(len(after_cutoff), "8-Ks accepted after 5:30 pm on this page")

On an ordinary weekday afternoon that count is zero, not because nobody files after 5:30 but because the feed is not showing them to you yet. Run it again the next morning against the same accession numbers and they are there, dated tomorrow, timestamped last night. The quick way into 8-K filings works the same way for the historical side once the batch has landed.

For a single filing, Filing.header carries the SGML header, so the check for "did this one roll" is one comparison:

rolled = h.acceptance_datetime.date() != h.filing_date

Across the 48 weekdays I measured this summer, the 8-Ks accepted per minute fell from 50 at 5:29 pm and 33 at 5:30 to seven at 5:31, and 82 distress-shaped 8-Ks in total, auditor changes, restatements, listing notices, departures, were accepted after the cutoff. That is the population a feed-based pipeline structurally sees a day late, and it is the population most worth seeing on time.