Restatement drift

This guide shows why historical results drift when a dataset exposes only the latest corrected history.

Problem setup

Assume a strategy includes a company when annual net income is above 96.9B.

If you evaluate that rule on the current latest history, the answer can change after a restatement arrives.

Original historical view

Ask what was knowable at a historical boundary.

GET /v1/edgar/as-of/2024-03-31/financials/0000320193

The response carries as_of_date, as_of_timestamp, snapshot_hash and statements, each statement with its figures in values.

Restated view

Now run the same analysis after a later amendment is in history.

GET /v1/edgar/as-of/2024-06-01/financials/0000320193

If a filing restated a period between those dates, the later snapshot can point at a different filing's statement than the earlier one.

Inspect the lineage

Use the restatement timeline route to make the change explicit.

GET /v1/edgar/companies/{cik}/statements/restatement-timeline?statement_type=INCOME_STATEMENT&fiscal_year=2023&fiscal_period=FY

That route tells you:

  • how many versions exist for the statement
  • how often key metrics changed
  • how severe the timeline is for that reporting slice
  • which metrics changed most across the timeline
  • how many hops exist between versions

A period with no metric changes returns 200 with an empty timeline rather than an error: by_metric is {} and timeline_severity is NONE. Read that as "no restatement occurred", not as missing data.

total_hops counts the versions traversed, not the changes found, so it can be non-zero on a period nothing changed in. Apple's FY2023 income statement returns total_hops: 2 with by_metric: {}:

{
  "data": {
    "cik": "0000320193",
    "statement_type": "INCOME_STATEMENT",
    "fiscal_year": 2023,
    "fiscal_period": "FY",
    "by_metric": {},
    "restatement_frequency": {},
    "per_metric_max_delta": {},
    "total_hops": 2,
    "timeline_severity": "NONE"
  }
}

Judge change from by_metric and timeline_severity. A period the filer never reported answers the same way with total_hops: 0 — also a 200, not a 404. A 404 here means the CIK has no statements at all. See Errors.

One fiscal identity can hold several period ends, because a quarter is sometimes labelled FY. A timeline covers the revisions of a single period: the one the serving layer returns for that identity.

Compare the original with the amendment

The timeline tells you that a period changed and how much. To see exactly what an amendment changed, compare the two filings with the restatement delta. With no selector it compares the first filing for the period with the latest one:

curl -X GET "https://api.arche.fi/v1/edgar/statements/restatements/delta?cik=0001069183&statement_type=BALANCE_SHEET&fiscal_year=2024&fiscal_period=FY" \
  -H "X-Api-Key: $ARCHE_API_KEY" \
  -H "X-Request-ID: $(uuidgen)" \
  -H "Accept: application/json"

Axon's FY2024 10-K/A moved $680,289,000 out of long-term debt and into current liabilities:

{
  "data": {
    "cik": "0001069183",
    "statement_type": "BALANCE_SHEET",
    "fiscal_year": 2024,
    "fiscal_period": "FY",
    "from_version": {
      "accession_id": "0001069183-25-000019",
      "form_type": "10-K",
      "accepted_at": "2025-02-28T21:22:06Z"
    },
    "to_version": {
      "accession_id": "0001069183-25-000075",
      "form_type": "10-K/A",
      "accepted_at": "2025-05-07T20:38:11Z"
    },
    "summary": {
      "total_metrics_compared": 20,
      "total_metrics_changed": 2,
      "has_material_change": true
    },
    "deltas": [
      {
        "metric": "LONG_TERM_DEBT",
        "old_value": "680289000",
        "new_value": "0",
        "diff": "-680289000"
      },
      {
        "metric": "TOTAL_CURRENT_LIABILITIES",
        "old_value": "997586000",
        "new_value": "1677875000",
        "diff": "680289000"
      }
    ],
    "metrics_only_in_from": [],
    "metrics_only_in_to": ["CURRENT_PORTION_OF_LONG_TERM_DEBT"],
    "comparability_warning": true
  }
}

from_version and to_version name the two filings compared, the original 10-K and its 10-K/A amendment, by SEC accession. deltas lists the metrics both filings carry whose values changed. The amendment also reports CURRENT_PORTION_OF_LONG_TERM_DEBT, a line the original did not carry, so it appears in metrics_only_in_to and comparability_warning is true. Read the one-sided metrics alongside deltas before treating the two filings as like for like.

The default comparison moves when a later amendment is filed. To pin this one, pass the two accessions as from_accession and to_accession.

Correct workflow

When the decision date matters:

  1. choose the decision boundary first
  2. query Arche with an as_of route anchored to that boundary
  3. preserve the request inputs and returned version identifiers
  4. only then join with downstream market or model data

The wrong comparison is not old data versus new data. It is latest corrected history versus what was actually knowable at the historical decision date.

Was this page helpful?