# 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.

```http
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.

```http
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.

```http
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: {}`:

```json
{
  "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](https://docs.arche.fi/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:

```bash
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:

```json
{
  "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

> **Warning:** 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.

## Next steps

- [Point-in-time research](https://docs.arche.fi/guides/point-in-time-research): Build research workflows that preserve historical knowability and reproducibility.
- [Rebuild a historical view](https://docs.arche.fi/guides/rebuild-historical-view): Reconstruct what a company statement looked like on a specific date.
- [Company resolution and statement retrieval](https://docs.arche.fi/guides/company-resolution-and-statement-retrieval): Resolve an issuer, fetch statements, and move from identifier lookup into analysis.