Klepmann is correct but practically you don't control external accounts thus cannot authoritatively determine if they either exist, have ceased to exit, or the contents of their ledgers. Thus, a large number of transactions will always have hanging references. This ultimately dictates the need for a "settlement state", which should be modeled as a state machine with careful transitions. Reversible transactions, fees, taxes and discounts then come in to play, some of which may be shared between parties, some of which are not calculable before the fact.

Fowler's approach is amusing in that, in classic UML style, he models things which are optional in an authoritative way as if they are requirements, thus muddying the waters even further. While his adjustment implementations are interesting as a basis for feature comparison, there's a lot to be said for simplicity, and this effectively requires throwing out what the bean-counters are used to and reconsidering the need from scratch. The default correction is another transaction, and this requires no special implementation.

New systems recommendation:

(1) For account identification, use IIBAN which provides IBAN-compatible account identification and checksums and is an open system @ https://github.com/globalcitizen/iiban

(2) For all accounting, use UTC.

(3) For transaction identification, use UTC second of origination (UTCSO) + account of interest (AOI; eg. IIBAN) + intra-second transaction identifier (ISTI).

Free thoughts on forward-looking accounting systems @ https://raw.githubusercontent.com/globalcitizen/ifex-protoco...