I maintain this Actor. This is an AI-assisted technical walkthrough, fact-checked against its accepted source contract and saved acceptance evidence.
Two feeds can report the same filing with slightly different company labels, dates, or document links. Concatenating the rows creates duplicate alerts. Keeping the last row hides disagreements. The useful intermediate product is a timeline that keeps the source observations together and makes the disagreement inspectable.
The SEC Filing CIK Timeline Reconciler processes supplied snapshots. It does not fetch EDGAR or run the upstream Actors. Its grouping key is an explicit CIK, normalized to ten digits. A company name is retained as an observation, rather than promoted into a company identifier. That distinction matters when a source changes punctuation, abbreviates a name, or reports a former name.
Keep filing identity separate from company identity
An accession number identifies a filing observation within the relevant CIK group. The accepted forms are SEC's hyphenated 10-2-6 representation and its exact eighteen-digit representation. Repeated observations of that accession can be reconciled without counting each feed row as another filing. An accession observed under two different CIKs stays in separate groups and produces a collision signal.
This gives an ingestion pipeline a safer decision point. A downstream importer can hold dossiers with conflicts, while continuing to index dossiers that need ordinary timeline review. It should preserve both the normalized key and the source evidence. Using the company label as the database key would throw away the exact separation this Actor provides.
Read the result as a bounded dossier
The saved acceptance example contains a useful result with status timeline_reconciled, action review_timeline, and medium confidence. These are the Actor's output fields from that saved example, not a statement that a live company has been independently verified today. Relevant fields include filingCount, filings, conflictCount, collisionCount, and sourceRowsMissingFilingsField.
Inspect filingsOmittedCount before treating the displayed list as the entire reconciled group. Evidence display is bounded. A dossier can preserve a count while showing only part of the supporting detail. Likewise, partial source rows and unrecognized adapters remain coverage information; they are not silently converted into a complete EDGAR history.
Two dates answer different questions
The filing date describes the reported business event. An observation or check timestamp describes when the source captured it. A dashboard that substitutes processing time for filing time can make an old filing appear new every time the pipeline runs. Keep the event date, the observation window, and the new run's processing time in different columns.
Before connecting alerts, test three small cases with your own snapshots: one accession repeated twice, one accession carrying contradictory dates, and one accession observed under different CIKs. Confirm that duplicates do not inflate the timeline, conflicting values remain visible, and the cross-CIK case is flagged. Label any invented test rows as synthetic. The resulting timeline covers supplied observations; it is not an exhaustive filings service or an investment recommendation.
Run a small saved snapshot
Start with an existing Dataset you are authorized to read. Replace the Dataset placeholder below with its actual ID. Supported input can also use a source run ID or inline records; choose one explicit source. This Actor does not launch the upstream collection for you.
curl --request POST \
'https://api.apify.com/v2/acts/zinin~sec-filing-cik-timeline-reconciler/runs?maxTotalChargeUsd=0.10' \
--header "Authorization: Bearer $APIFY_TOKEN" \
--header 'Content-Type: application/json' \
--data '{"datasetId":"REPLACE_WITH_YOUR_DATASET_ID","maxInputRows":100,"maxResults":10}'
The response identifies an asynchronous run. Save that run ID and check its status before reading its default Dataset. A client timeout does not cancel a server run; inspect the existing ID before starting another one. maxInputRows bounds ingestion and maxResults caps useful output. Neither option establishes complete coverage of a larger source. The API charge limit is a ceiling, not a promise that ten results will fit.
Price and evidence limits
On 15 October 2026 the observed FREE-plan price is $0.03 per filing dossier, with no paid start event for this Actor. Other subscription tiers can have different prices; verify the current Actor page before use. Source collection is a separate activity and may carry its own charges. Free diagnostic rows do not count as paid useful assessments.
The examples discussed here come from saved owner acceptance runs. They show specific observed behavior, rather than customer acceptance, profitability, or an exhaustive guarantee for every input. A new run of identical input can be charged again without adding new source evidence. Retain input provenance, the actual build ID, and the source observation window when comparing results over time.
Top comments (1)
Keeping the CIK as the key and the name as an observation is the right split. One thing to check on the "same accession under different CIKs" signal: on EDGAR that is not always a collision. A Schedule 13D/G, or a Form 3/4/5, is one accession listed under both the issuer's CIK and each reporting person's CIK, and the same goes for co-registrant filings. The first ten digits of an accession number are the filer agent or submitter, so they don't tell you which company the filing belongs to either.
So I'd expect that case to fire on ordinary ownership filings. Do you tell a legitimate multi-party filing from a real conflict, for example by form type, or by whether the two CIKs appear together in the filing's header? And does the dossier keep the acceptance timestamp apart from the filing date? In our measurements the same filing's acceptanceDateTime differed between two EDGAR files for some companies, so "two dates" can really be three.