Hacker News Reader

Comment by 3pm | Hacker News Reader

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-compu...

Also probably worth checking out Martin Fowler's writing on accounting.

https://martinfowler.com/apsupp/accounting.pdf

https://www.amazon.com/Analysis-Patterns-Reusable-Object-pap...

View on HN

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...

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.

On UTC: why so, as accounting periods are happening in local time

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.

The database will be always using utc, but according periods will be always local. Hence was my question, why emphasize this that is?

> 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.

you model external accounts with an internal account (node) in your ledger.

... achieving what, exactly? How is the set of outbound transactions already stored associated with a given external destination not precisely the same information? This is needless data duplication, AKA database design no-no 101.

Achieving an internal record that balances out, and has no dangling references. Later inter-company audits can also verify that neither company has unilaterally corrupted their books. To be clear: I’m just talking about the standard accounting practise here (as normally done with tables/books), nothing fancy. Just applied to graphs, so the graph has no dangling references/edges.

In the database world it is generally recognized that doing data duplication to 'flatten' a particular view is a special case of normalization (adapting data to a model) which is encouraged to be done dynamically (eg. as an SQL view) and not in stored data (as this would create redundant information, which negatively affects the database in terms of ongoing management, authority and clarity). Generating reports in whatever format users prefer is generally a very cheap and fast operation.

Also, duplicating the data does not make it more correct or more authoritative. Do not confuse presentation with data. A rose by any other name would smell as sweet.

Edit: I can't reply to your response so will reply here. I suggest reading some basic database design books. Good luck.

How does that relate to what I said?

Reply on news.ycombinator.com