Feature catalogue

Value dating

Every change to an account, counterparty, operating entity, structure or relationship carries the date it takes effect — its value date. That date is not the date somebody typed it in.

Three consequences follow, and they are the whole of the model:

Worked example

A customer tells you on 10 March that their rate changed on 1 March, from 8% to 9%. You enter the change with a value date of 1 March.

What you see What happens
The change appears immediately in the change list Recorded with value date 1 March
The account revalues Nine days of accrual, 1–9 March, are recomputed at 9%
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

Enter the same change dated 1 April instead, and none of that happens today. The change sits pending, shows on the Staged Changes panel, and takes effect when the day walk reaches 1 April.

What each operation will accept

An operation declares which direction of dating makes sense for it, so the date picker never invites a date the operation cannot mean:

Policy The picker offers Typical use
None No date picker; takes effect now An action with no meaningful history
Forward Today or later An address change, a nominated account change
Backward Today or earlier Correcting something that already happened
Any Any date A rate change, which needs both

Fixing a dated change

A dated entry has a lifecycle. A forward-dated change that has not yet taken effect can be cancelled or re-dated from the Staged Changes panel. A backdated change with the wrong value is corrected by writing the right value at the same date. Correcting a backdated change re-triggers revaluation, on the same rule as the original.

Day count conventions are value-dated like everything else — see day count conventions.