Thursday, March 5, 2026

How Arche Handles Financial Restatements

SourcesRaw filings and corrections become versioned eventsEDGAR filingsAccessioned, timestampedAmendments / restatementsNew versions, never overwritesProvider correctionsExplicit change eventsVersioned ledgerImmutable versions with provenanceStatement: AAPL • 2024-12-31source=edgar • accession=0000320193-25-000010version=v3 • ingested_at=2025-02-05T02:14:31Zprovenance: strongVersions over timev1v2v3Contract-first APIVersioned routes, machine-readable schemasGET /v1/…Deterministic orderingExplicit paginationCanonical error envelopesStable schema contractsReady for MCP tool usemcp

Financial restatements are an unavoidable part of corporate reporting.

Companies periodically revise previously issued financial statements due to accounting corrections, changes in reporting standards, or updated interpretations of financial disclosures. These revisions can affect historical financial values years after the original filings were published.

For financial data systems, restatements create a difficult challenge.

How should historical data change when financial statements are revised?

The common approach

Most financial datasets handle restatements by replacing previously reported values with the most recent version of the statement.

This approach simplifies the dataset but introduces a critical problem: it removes the historical context of the original filings.

When historical values are overwritten:

  • it becomes difficult to reproduce past research results
  • financial models may unknowingly incorporate revised data
  • analysts lose visibility into how financial statements evolved over time

For systems that rely on reproducible historical analysis, this behavior introduces ambiguity.

Preserving financial lineage

Arche approaches restatements by preserving the lineage of financial disclosures rather than replacing them.

Each financial value in Arche remains connected to the filing that produced it. When a restatement occurs, the revised values are recorded alongside the original statements rather than overwriting them.

This creates a structured history of financial disclosures that allows developers to analyze both the original reporting and the revised interpretation.

Point-in-time financial queries

Because Arche preserves filing lineage, financial queries can be executed against a specific historical date.

For example, a system can request financial statements exactly as they were known on a particular day, before any later amendments or corrections were issued.

This capability ensures that:

  • backtests use only information available at the time
  • historical research remains reproducible
  • financial systems can explain how past results were generated

Point-in-time querying is a core property of deterministic financial datasets.

Transparency in financial data

Restatements are not anomalies; they are part of the financial reporting process.

By preserving both the original disclosures and their revisions, Arche provides a transparent view of how financial statements evolve over time. Developers can analyze historical financial data with full visibility into the filings that produced it.

This approach allows financial systems to rely on regulatory disclosures without sacrificing reproducibility.