Live data from Hacker News

Accounting For Developers, Part I

moderntreasury.com

31–40 of 193 posts

Re: Accounting For Developers, Part I

#31
post #27

Any time the idea of double entry bookkeeping comes up there is nothing but unanimous advocacy for it. This thread echoes the same sentiment where there's several comments about the importance of double entry. And yet like all previous endorsements I've heard, I've not been able to take away why it is so important. The reasons are always around error tracking, tracing source of funds, standing the test of time etc. a…

Quite simply each entry contains both the "to" and "from" for the transaction. It's a construct to guarantee atomicity. The two "sides" of the transaction can never be out of balance with each other. If you lose an entire entry the system remains in balance-- you've lost a transaction but you're not in a situation wondering "where the money went" because nothing moves without both sides of the transaction.

Re: Accounting For Developers, Part I

#32
Can someone explain. From their definition it looks like the credits and debits column in their example transaction table is flipped e.g. the first "debit" to the cash (debit normal) account increases the value, while the "credit" to the equity (credit normal) account also increases the value. (edited for spelling)

Re: Accounting For Developers, Part I

#33

For those interested, Tigerbeetle[0] is a high-peformance purpose built accounting database. It supports - double entry transfer - two-phase transfers (ie reserve an amount and post it later) - linked transfers (move money across multiple accounts atomically) Worth looking at. [0] - https://www.tigerbeetle.com/ & https://github.com/coilhq/tigerbeetle

Also one of the bigger Zig codebases out there for you PL nerds.

Re: Accounting For Developers, Part I

#34
> A credit entry will always increase the balance of a credit normal account and decrease the balance of a debit normal account. Put differently:

Not sure if the author is reading comments here, but the diagram after this sentence shows the opposite!

Re: Accounting For Developers, Part I

#36
post #27

Any time the idea of double entry bookkeeping comes up there is nothing but unanimous advocacy for it. This thread echoes the same sentiment where there's several comments about the importance of double entry. And yet like all previous endorsements I've heard, I've not been able to take away why it is so important. The reasons are always around error tracking, tracing source of funds, standing the test of time etc. a…

Double entry bookkeeping simply represents flows of money as a directed graph, and that turns out to be a very useful thing.

Re: Accounting For Developers, Part I

#37
post #27

Any time the idea of double entry bookkeeping comes up there is nothing but unanimous advocacy for it. This thread echoes the same sentiment where there's several comments about the importance of double entry. And yet like all previous endorsements I've heard, I've not been able to take away why it is so important. The reasons are always around error tracking, tracing source of funds, standing the test of time etc. a…

This article [1] "Accounting for Computer Scientists" may help. Visualize money movement between Accounts / Nodes triggered by Transactions / Edges.

This model is used to construct a "Fund flow" representation of how money should be moved. One of the essential concepts we use to verify that money is moving through the system is "Clearing", where we add up all of the edges and the balance should equal 0 - that is money reached its intended destination.

[1] https://martin.kleppmann.com/2011/03/07/accounting-for-compu...

Re: Accounting For Developers, Part I

#38
post #9

Earlier quoted context omitted.

Double entry bookkeeping doesn't mean that you have two records for each transaction. In fact, it's the exact opposite! Transactions fundamentally have two parts -- where the money is coming from and where the money is going -- and double entry bookkeeping says that both of those entries are part of the same record .

My understanding was that historically double entry accounting very much had each entry stored separately (although tied together by some transaction identifier). You would normally add both at the same time, so one could consider it "one record" on that basis, but physically they were separate entries often in separate physical books. In computerized systems, having a single record in one place, and virtually constr…

You are right that there would traditionally be separate books. The first, a "day book" would be a list of transactions that a merchant (or his servant/employee) would write down as business took place. This would say something like "I sold 10 spools of yarn for 8 florins apiece to Mr. Lucio" (remember that this all started a system to keep track of the affairs of Florentine Renaissance merchants). Later, after business had concluded for the day, the merchant (or his bookkeeper) would "post" the transaction to the ledger, which was a book that had a page for each "account." He would go through the daybook and, for each transaction, post it to (at least) two accounts, debiting and crediting equal amounts so that the books "balanced." This left him with a single number for each account which represented the total net activity for that account. This is the account's "balance" and is a very interesting piece of information for a merchant, so much so that it warrants all the associated ceremony.

Today, the "posting" can usually be done by a computer. There is some human creativity/regulation involved in deciding which specific accounts to credit/debit, but this can be noted in the "daybook entry" (more likely a database record somewhere than something literally written in a book) instead of being put off until the posting step.

The important characteristic is what the grandparent noted, that each transaction (in the daybook) tracks completely where each cent (or florin) came from and where it went. If a system of bookkeeping has this characteristic, I think it can be called double-entry, at least in spirit. A hard requirement that a transaction occur between exactly two accounts makes some kinds of events difficult (or impossible) to model, but is still conceptually the same.

Re: Accounting For Developers, Part I

#39

Interesting, I'd heard of "double entry" before but I've never used it. I've written and maintain code that uses only 1 record per transaction and I'd love resources to look into that go into the "why" of double entry. For example my current "transactions" table has fromUserId and toUserId columns (1 user = 1 account) and so purchases/transfers/reloading your account all take just 1 row. For reloading the "fromUserId…

One sentence from the article should be emphasized: “Double-entry systems are more reliable at tracking money than any other viable alternative.” So true, 100’s of years and no better system has ever evolved. I would argue that any blockchain system that attempts to tackle this problem has a double entry aspect if it’s useful.

The blockchain is basically triple-entry accounting. Every transaction has a public record to go along with your own two column entry.

Re: Accounting For Developers, Part I

#40

Sometimes non-accounting people get hung-up on the words "debit" and "credit" and think they have to do with "owing" or "being owed" money. The effect of a debit or credit on the business depends on the accounts in the transaction and debit and credit don't have anything to do with the "direction" of a flow of money. My 100-level accounting instructor summarized it as: "A debit is the entry in the left column, and a…

Sadly, I gave up accounting in high school after failing to reason through the meaning of 'credit' and 'debit' (Yes, I went in too deep!). My epiphany came in B-school when I tackled it again, when I finally figured out what your instructor summarized.
Post reply on HN