---
title: "Point-in-time memory for accounting AI"
description: "Accounting AI needs balances, policies and client facts as of specific dates, with supporting evidence. Learn how a temporal memory API supports these queries."
canonical: https://past.dev/industries/accounting
last-updated: 2026-08-31
---
# Memory infrastructure for accounting AI

Source: https://past.dev/industries/accounting

Accounting AI requires point-in-time information. Trial balances have effective dates, restatements preserve earlier reports and workpapers connect values to evidence. past.dev stores facts with validity dates, retains superseded values and returns dated sources for accounting agents. Applications can query the current value or the value supported on an earlier reporting date.

## The memory problems inside accounting work

- **As-of reporting.** What the balance said at close versus what it says now, after adjustments. Answering both requires keeping both, with dates. This is the [bitemporal model](/glossary/bitemporal-memory), which accounting used before software did.
- **Client-specific rules.** GL coding habits, materiality thresholds, and recurring accrual treatments may be known by one staff member. Store them as dated, queryable facts so other authorized staff and agents can retrieve them.
- **Workpaper evidence.** Every figure needs a source and a date an auditor can follow. An answer without provenance is not usable in an engagement file.
- **Policy periods.** Revenue-recognition judgments need validity windows that identify the applicable period.
- **Restatements.** A prior-period adjustment changes the reported value while the original filing remains part of the historical record.

## What agents can do with temporal memory

- Answer what changed since the previous close from validity windows, with the source for each change.
- Reconstruct what was known at signing, for review and for defense, via [point-in-time recall](/glossary/point-in-time-recall).
- Keep client-specific treatment knowledge current across staff turnover: the current preference, when it changed, and on whose instruction.
- Flag conflicting instructions explicitly. When the controller and the engagement letter disagree, recall returns `Conflicted` with both sides, instead of silently picking one.
- Return `NoKnownSupport` when the supplied records do not establish an answer.

## How the integration works

past.dev provides memory through an API and does not replace an accounting system. Agents send engagement notes, client email, close checklists and decisions through `POST /api/v1/ingest` with each record's original timestamp. past.dev performs extraction, entity resolution and temporal storage. `POST /api/v1/recall` returns ranked, dated evidence with a status value.

```bash
curl -X POST https://api.past.dev/api/v1/recall \
  -H "Authorization: Bearer $PAST_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"query": "What materiality threshold applies to the Hollis engagement?"}'
```

The [quickstart](/docs/memory-api/quickstart) reaches a first recall in four calls, from any framework your agents already use, including [LangGraph](/integrations/langgraph) and [n8n](/integrations/n8n).

## Evidence, retention and controls

Recall returns each claim with its source and date. Deletion and retention are explicit operations. The [security page](/security) documents certifications and controls. Regulatory obligations under SOX and ICFR remain with the filer and firm. past.dev makes supporting records queryable but does not transfer those obligations.

How recall quality is measured, including update handling and abstention, is documented with the method on the [benchmarks page](/benchmarks).

## Frequently asked questions

### Is past.dev an accounting or bookkeeping tool?

No. It is memory infrastructure for the AI systems accounting teams and vendors build: agents for close management, AP coding, client service and audit support. The ledgers stay in your systems of record; past.dev keeps the queryable history of facts, decisions and changes around them.

### Can it reproduce what was known at a past date?

Yes. Facts carry validity windows and ingestion preserves original timestamps, so recall can answer as of a chosen date and return the evidence that was current then. That is the point-in-time behavior accounting questions assume.

### How does it handle a restated figure?

Record a restatement as supersession. The new fact closes and links the previous fact's validity window. Current queries use the restated value, while historical queries retain both dated values.

## Related

- [Bitemporal memory](https://past.dev/glossary/bitemporal-memory)
- [Point-in-time recall](https://past.dev/glossary/point-in-time-recall)
- [Memory for healthcare AI](https://past.dev/industries/healthcare)
- [What is agent memory?](https://past.dev/what-is-agent-memory)
- [Quickstart](https://past.dev/docs/memory-api/quickstart)
- [Security and certifications](https://past.dev/security)