Every property on every record is a date series, not a value. A rate, a limit, a fee, a tax residency, a bank account, a classification. What was it on 3 March? What if it steps up next month? What if you find on 10 March that it should have changed on 1 March?
The first version of a ledger stores the rate as a column. It is the first thing to break.
A column holds one value and no date. The moment a rate changes, the history is gone; the moment a change is back-dated, every accrual since is wrong and nobody knows by how much. Teams then bolt on a history table, a "current" flag and a batch job, and spend years reconciling the three. The engine does not have a column. It has a date series.
The rate is the example. The rule covers every property of every kind.
Numbers, text, flags, classifications, references to other records: all dated, on accounts, counterparties, operating entities, structures and relationships alike. There is no list of "financial" properties that get history while the rest do not, because any calculation may switch on any property.
Rate, margin, day count, limit, instalment, fee, interest method, collateral cover, the account that collects the instalment.
Tax residency, KYC status, hold, address, roles, the bank account payments go to.
Accounting currency, posting group, cost centre, the legal entity a structure reports into.
Who guarantees whom, from when, until when.
On every aggregate and for every kind of value: rates, limits, lookups, references, flags. If the caller gives none, the trading date is stamped. The date is captured at write time because not capturing it is irreversible.
There is no "current value" call. Current is expressed as "as of today's trading date", so an undated read can never feed a calculation by accident.
An entry dated next month is inert to every reader until the day walk reaches it. No scheduler, no batch job: the series answers the question and the date does the rest.
Enter a change with a value date in the past and the account replays from that date, computes the difference, and posts it as new value-dated events. The original entries are never edited.
On 10 March you find that a rate change agreed for 1 March, 8% to 9%, was never entered. You enter it now, with a value date of 1 March. The same mechanics serve a stepped rate plan agreed up front, a pricing discount or markup granted from a date, or a mistake found later.
| What you see | What happens |
|---|---|
| The change appears immediately in the change list | Recorded with value date 1 March, on the 10 March trading date |
| The account revalues | Nine days of accrual, 1 to 9 March, are recomputed at 9% and the difference is posted |
| A statement asked for 5 March shows 9% | The as-of read answers on the value date |
| An entry keyed to 10 March is untouched | Only days on or after the value date move |
| The same change dated 1 April instead | Nothing happens today. It sits on Staged Changes and takes effect when the day walk reaches 1 April |
Event sourcing records when we knew. Dated properties record when it was true.
Together they give a snapshot of any account, counterparty, entity or structure at any point on either clock: what the book looked like on 5 March as we understood it on 8 March, and as we understand it now. That is what makes value dating and transaction adjustments safe, and what an auditor asks for months later.
What this means for you: a late correction, a stepped rate, a dated discount: each is a dated entry, not a data fix. The statement, the accrual and the audit trail all agree, because they all read the same series.