top | item 42273072

(no title)

rkharsan64 | 1 year ago

Most of the comments here echo what the article is criticising. I can see countless threads of back-and-forth defending single-entry bookkeeping.

Sure, single-entry bookkeeping might be easier and more normalized, but sometimes it is a good idea to just stick with the systems and abstractions that have been developed over centuries.

Just use double-entry bookkeeping unless you definitely need something else. Sure, it might be icky for the programmer inside you, but I think you'll be thankful if you ever need to get actual accountants involved to sort out a mismatch.

On a related note: does anybody know of any good resources for programmers in payments and adjacent fields? Something like an "Accounting for Programmers"?

discuss

order

karanbhangui|1 year ago

inopinatus|1 year ago

I read an article from Modern Treasury that advocated for mutable pending transactions to vary entry amounts by replacing entries¹, which is just about the worst idea I ever heard in the design of a DE system, and their reasoning boiled down to: if you're running a settlement system but are too lazy to implement a clearinghouse layer separately, no worries, just violate the entire DE covenant instead. So I'd take anything they write with a pinch of salt.

[1] https://www.moderntreasury.com/journal/how-to-scale-a-ledger...

fragmede|1 year ago

I consider that first link, Accounting for Computer Scientists, as the canonical guide for computer scientists as to wtf double entry accounting is and why it's the right way to do it.

rambambram|1 year ago

> On a related note: does anybody know of any good resources for programmers in payments and adjacent fields? Something like an "Accounting for Programmers"?

Get a grip on the accounting basics first. I built my own bookkeeping system with double entries and realized the design and the programming was the easy part.