3 ms·

A quote from a related blog post: "Eventually I figured it out: basic accounting is just graph theory. Accounts = Nodes, Transactions = Edges" https://martin.k

by 3pm 4y ago

A quote from a related blog post: "Eventually I figured it out: basic accounting is just graph theory. Accounts = Nodes, Transactions = Edges" https://martin.kleppmann.com/2011/03/07/accounting-for-computer-scientists.html https://martin.kleppmann.com/2011/03/07/accounting-for-compu... Also probably worth checking out Martin Fowler's writing on accounting. https://martinfowler.com/apsupp/accounting.pdf https://martinfowler.com/apsupp/accounting.pdf https://www.amazon.com/Analysis-Patterns-Reusable-Object-paperback/dp/0134186052/ https://www.amazon.com/Analysis-Patterns-Reusable-Object-pap...

contingencies 4y ago
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 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-protocol/master/draft-ifex-00.txt https://raw.githubusercontent.com/globalcitizen/ifex-protoco...
- hum3hum3 4y ago
  Thank you. Those are some interesting references. I do like your reference of state machines at the edges of the accounting model. Definitely the case in payments systems. I don't like how Modern Ledger goes straight to credits and debits whereas Klepmann has a graduated approach. I have been thinking about writing a bit more about this.
- juskrey 4y ago
  On UTC: why so, as accounting periods are happening in local time
  - contingencies 4y ago
    We live in a global era. Any novel system should assume that it may in future be operated cross-border, distributed, etc. or used in combination with such systems. Many countries even have multiple timezones internally. Given such a circumstance, any use of local timezones is by definition a presentation layer concern. Not recognizing this at design time is a surefire way to create needless technical debt with zero functional benefit.
    - juskrey 4y ago
      The database will be always using utc, but according periods will be always local. Hence was my question, why emphasize this that is?
- redbar0n 4y ago
  > 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. True. But it doesn't actually matter. > Thus, a large number of transactions will always have hanging references. No, it doesn't need to be any dangling references. Because you model external accounts with an internal account (node) in your ledger.
  - contingencies 4y ago

by 3pm 4y ago

contingencies 4y ago

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 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-protocol/master/draft-ifex-00.txt https://raw.githubusercontent.com/globalcitizen/ifex-protoco...

hum3hum3 4y ago
Thank you. Those are some interesting references. I do like your reference of state machines at the edges of the accounting model. Definitely the case in payments systems. I don't like how Modern Ledger goes straight to credits and debits whereas Klepmann has a graduated approach. I have been thinking about writing a bit more about this.
juskrey 4y ago
On UTC: why so, as accounting periods are happening in local time
- contingencies 4y ago
  We live in a global era. Any novel system should assume that it may in future be operated cross-border, distributed, etc. or used in combination with such systems. Many countries even have multiple timezones internally. Given such a circumstance, any use of local timezones is by definition a presentation layer concern. Not recognizing this at design time is a surefire way to create needless technical debt with zero functional benefit.
  - juskrey 4y ago
    The database will be always using utc, but according periods will be always local. Hence was my question, why emphasize this that is?
redbar0n 4y ago
> 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. True. But it doesn't actually matter. > Thus, a large number of transactions will always have hanging references. No, it doesn't need to be any dangling references. Because you model external accounts with an internal account (node) in your ledger.
- contingencies 4y ago