“What did we think we had on hand on March 31, given what we knew at the time?” is a question ordinary inventory systems cannot answer, because they overwrite the past. A bitemporal ledger can, by tracking two independent timelines. For audits, financial restatements, and dispute resolution, that capability is the difference between a defensible answer and a shrug.
Two timelines, not one
Most systems track one notion of time: what is true now. Bitemporal modeling tracks two:
- Valid time: when a fact was true in the real world (stock arrived on the 3rd).
- Transaction time: when the system recorded that fact (we entered it on the 5th).
The pair lets you reconstruct not just history, but your knowledge of history at any past moment, including corrections entered late.
Why the second timeline matters
Inventory corrections arrive after the fact constantly: a receipt booked two days late, a count adjustment, a return finally processed. With one timeline, applying those corrections rewrites the past, so “what did the March close show” changes every time someone fixes an old entry. With transaction time recorded, the March close as you believed it on March 31 stays answerable forever, even after later corrections, because the late entry has a transaction time of April, not March.
How to model it
Each row carries both intervals:
(sku, qty, valid_from, valid_to, recorded_at, superseded_at)A correction does not update the old row; it closes it (superseded_at = now) and inserts a new
one. To answer “stock as of valid date X, as known on date Y,” you query:
WHERE valid_from <= X AND valid_to > X -- true at X
AND recorded_at <= Y AND (superseded_at > Y OR superseded_at IS NULL) -- known by YThis is the natural partner of an event-sourced ledger: append-only events give you the history; bitemporal structure lets you query both time axes over it.
Where it earns its keep
- Audit and restatement: prove what the books showed at close, regardless of later fixes.
- Disputes: “we promised based on what we knew then” becomes verifiable, not anecdotal.
- Debugging: see exactly when a bad value entered and what it displaced.
It is not free: storage grows and queries are wordier. Reserve it for the records where “what did we believe, and when” actually matters, typically the valuation-bearing stock ledger, not every operational table.
The takeaway
A bitemporal ledger separates when stock was true from when you recorded it, so late corrections stop rewriting your past. For anything audited or disputed, that is the honest foundation for inventory control: you can always answer what you believed, as of when you believed it.
Implementing this at your scale?
The walkthrough above comes from production work. AvanSaber’s inventory practice has implemented variations of this pattern across multiple customer engagements.
If you are building this and want expert review of your design, or would rather have the team that built this build yours, book a discovery conversation or describe your situation at [email protected].