Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Accounting For Developers, Part I

moderntreasury.com

Post reply on HN
Print view View original

21–30 of 193 posts

Re: Accounting For Developers, Part I

#21

Post by kevmarsden »

mytailorisrich wrote: post #14
joshstrange wrote: post #5

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…

Liabilities (Edit: plus equity) must always equal assets. This is the basic accounting principle. Double entry enforces this and also ensures that nothing is lost into thin air by requiring that debits and credits match. So for instance, if you spend money to buy a new laptop that money hasn't disappeared into thin air, it has been used to buy a tangible asset so while your cash has decreased your tangible assets hav…

To be a bit more specific: Assets = Liabilities + Equity

Re: Accounting For Developers, Part I

#22

Post by jwsteigerwalt »

joshstrange wrote: post #5

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.

Re: Accounting For Developers, Part I

#23

Post by mikeyouse »

kevmarsden wrote: post #21
mytailorisrich wrote: post #14

Earlier quoted context omitted.

Liabilities (Edit: plus equity) must always equal assets. This is the basic accounting principle. Double entry enforces this and also ensures that nothing is lost into thin air by requiring that debits and credits match. So for instance, if you spend money to buy a new laptop that money hasn't disappeared into thin air, it has been used to buy a tangible asset so while your cash has decreased your tangible assets hav…

To be a bit more specific: Assets = Liabilities + Equity

Right. Was going to comment the same. If you sell a product for $100 that only cost you $90 to produce, that $10 isn't a 'liability', it's profit / retained earnings (an equity account).

Re: Accounting For Developers, Part I

#24

Post by matdehaast »

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

Re: Accounting For Developers, Part I

#25

Post by EvanAnderson »

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 credit is an entry in the right column." Without the context of the specific accounts being debited or credited the terms themselves mean nothing.

Aside: A 100-level knowledge of accounting can confer near "super powers" when it comes to dealing with finance and accounting people. Double-entry bookkeeping is one of the oldest and longest-practiced "IT" disciplines. Your work probably touches revenue / expenses for your employer and someday you'll need to interface with accounting or finance people. Being able to speak the language, even poorly, has helped me gain trust and credibility that I don't believe speaking only in IT terms would have.

Re: Accounting For Developers, Part I

#26

Post by jsmith45 »

cperciva wrote: post #9
joshstrange wrote: post #5

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…

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 constructing the ledgers from it is feasible. Under the constraints that all transactions debit from just one ledger, and credit to just one ledger, storing each transaction as tuple (id, amount, debited ledger, credited ledger) is feasible.

Double entry does have the slight advantage of being possible to generalize to allow one transaction to debit from multiple ledgers or credit to multiple ledgers, as long as all the debited amounts sum to the same as all the credited amounts.

It has a disadvantage in that the storage format does not guarantee validity, unlike the tuple method.

Re: Accounting For Developers, Part I

#27

Post by potamic »

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. and yet in my head I'm not able to envision the specific problem double entry can solve that single entry cannot.

Somewhere in my head I feel a double entry system makes sense if you have two different parties making respective entry. But if it's all with a single party, single entry system should be equivalent to a double entry system. My accounting concepts are weak so I'm unable to justify. Hoping someone with more expertise can shed some light here.

Re: Accounting For Developers, Part I

#28

Post by svat »

There's another very nice description, with useful pictures, by Martin Blais (as part of the documentation of Beancount) at https://beancount.github.io/docs/the_double_entry_counting_m... (example picture that I would say is the heart of the idea: https://beancount.github.io/docs/the_double_entry_counting_m... )

Another one, with completely different graphs, is by Martin Kleppman at https://martin.kleppmann.com/2011/03/07/accounting-for-compu... — despite the name ("Accounting for Computer Scientists"), on reflection / trying it out, I find it less useful than the Beancount one.

(Both of these are actually linked in the second paragraph of the posted article, but they're independently worth mentioning / good.)

Re: Accounting For Developers, Part I

#29

Post by alain94040 »

potamic wrote: 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…

Think of each transaction as a movement: it has a source and a destination. Therefore, you need to account for it in two places: where it came from, and where it went.

Does that make more sense?

Re: Accounting For Developers, Part I

#30

Post by 1autodev »

potamic wrote: 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…

Here's a free university textbook on Accounting if you'd like to dabble a bit :)

https://principlesofaccounting.com/

Post reply on HN