Accounting For Developers, Part I • Hacker News Board

Re: Accounting For Developers, Part I

#171

Post by rendaw » Thu, Aug 18, 2022, 3:38 AM UTC

svat wrote: post #41

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…

The name "double-entry bookkeeping" may be misleading: what matters is not how many times / in how many places you do entry , but whether you're tracking both (or all) sides of a transaction. (With a computer you only need to enter the transaction once, as long as you track the "from"/"to".) A couple of examples from personal money-tracking: • say you have a bank account, and you track when the bank balance increases…

That manual skips over the reasoning too:

> This is called the single-entry method of accounting. But we’re not going to do it this way;

Why? So you have a graph now, what does that allow you to solve? What issues will you hit with single-entry (maybe with tags)?

I _think_ the simple answer is that if you have multiple accounts, any transaction moving money between them needs to decrease one if you increase another or else you'll magically gain/lose money in your records. Then if you use it to answer something like "do I have enough money to buy X" you'll get an incorrect answer. It doesn't seem to be a suggestion/improvement/technique and more of a mathematical reality for this model.

The double entry requirement for money entering/exiting the system (salary, sales, payments) doesn't seem to matter for that though.

Re: Accounting For Developers, Part I

#172

Post by rendaw » Thu, Aug 18, 2022, 3:44 AM UTC

darcys22 wrote: post #155

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…

Single entry bookkeeping is essentially a list of your income/expenses. A list of this nature means you can't be certain you got everything, if an item is missing or has been double counted it wont be obvious at first glance that it is wrong. Double Entry bookkeeping adds a layer to your lists to ensure that everything has been accounted for, you are creating the same list but also tracking the opposite side which is…

How does it make sure something hasn't been double counted? I assume you mean this situation:

1. Debit for X added 2. Credit for X added 3. Debit for X added again

Then you'll get a discrepancy when you sum them.

In a computerized system though you wouldn't make that mistake though, or else you could make it with double entry accounting too (just, you'll have double credit entries as well).

The only way to prevent duplicates is to associate upstream payment/transaction ids with records and make sure every entry is unique (which can be done for single entry accounting too).

Re: Accounting For Developers, Part I

#173

Post by phil-martin » Thu, Aug 18, 2022, 4:12 AM UTC

One of my favorite resources on accounting is https://www.ledger-cli.org/3.0/doc/ledger3.html It's application specific, but has enough examples in there to remind me of accounting principles from years past.

Combined with the other plain text accounting resources, it was the first resource that made everything "click" for me, well, for varying definitions of "click". I often refer back to it when I need to remind myself of things.

One thing on my todo list to expierment with is modelling double entry accounting as a graph, with nodes of the graph an account, and edges of the graph a transaction with the two amounts on the edge.

That's nice and all but the part I'm really interested in experimenting is modelling reconciliation as equivalencies of graphs. I have a separate graph that models the real world bank accounts and flow of cash, and organisational flow of money, and then I have my accounting graph that models all the transactions. For reconciliation I would go "these whole bunch of edges in this graph A are the same as all these other edges in graph B"

I just want to see what falls out the other end...

Re: Accounting For Developers, Part I

#174

Post by GeorgeDewar » Thu, Aug 18, 2022, 5:13 AM UTC

jdasdf wrote: post #131

I have 2 main issues with understanding double entry accounting, that i haven't really been able to grasp properly: 1 - How do i use it to keep track of multiple "currencies"? It's simple enough to remove 1$ from the cash account into the inventory account, but that 1$ i now have in the inventory isn't actually cash... How can i use this to keep track of the number of widgets i actually have in storage? Rather than t…

I can help with number 2.

Two transactions are happening at the same time. Your "sales" revenue account is going up (Credit) by $2 and your cash asset account is going up (Debit) by the same $2. That is the first balanced transaction.

The second transaction is that your inventory asset account is going down (Credit) by $0.50 as you have less inventory now, and an expense account called "Cost of Goods Sold" is Debited by the same $0.50.

Your profit gets calculated on demand. There are two ways to do it, both yielding the same result. You can look at revenue minus expenses over a period, giving $2 sales minus $0.50 cost of goods sold = $1.50 profit for the period. Or, you can look at how your equity (assets minus liabilities) has changed over that period. In this example, no liabilities have changed and your assets (bank account) have increased by $1.50 because bank has gone up by $2 while inventory has gone down by $0.50.

Re: Accounting For Developers, Part I

#175

Post by imgabe » Thu, Aug 18, 2022, 5:38 AM UTC

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…

It is essentially a checksum for transactions. You record where money came from and where it went to. All those entries should balance out to zero if you have recorded them correctly. If you haven't, you can detect an error because you'll have more money going in than going out or vice versa.

Re: Accounting For Developers, Part I

#176

Post by juped » Thu, Aug 18, 2022, 5:39 AM UTC

tunesmith wrote: post #103

rahimnathwani wrote: post #56

Earlier quoted context omitted.

> "debit" and "credit" and > think they have to do with > "owing" or "being owed" money. I think of it as 'owing' (liability) or 'owning' (asset). When you credit an account, you either increase what you 'owe' on that account OR decrease what you 'own' on that account. Examples: - bank credits a customer account => bank owes more to its customers - company credits income account => company owes more to its shareholde…

That makes sense to me in terms of assets and liabilities, but when I read https://beancount.github.io/docs/the_double_entry_counting_m... and it described income as being negative and expense as being positive, it broke my brain a little bit.

That's because it's just wrong, like everything from the docs of ledger and its descendants (and every "accounting for developers" article, except surprisingly not TFA here!), and accountants are just correct to use unsigned numbers.

A credit entry is a source, and a debit entry is a sink. When I do $4000 worth of consulting services work for Joe Bloggs, this gets entered as a $4000 credit to Income - Consulting Services (the source of the flow of funds), and a $4000 debit to Accounts Receivable (the destination of the flow of funds). Income, here, represents the outside world from the perspective of my business. Later, the receivable becomes cash when Mr Bloggs writes me a check, so I credit Accounts Receivable $4000 and debit cash (actually something like Assets - Coolbank Business Checking) $4000.

Re: Accounting For Developers, Part I

#177

Post by ParkGrove » Thu, Aug 18, 2022, 5:39 AM UTC

tunesmith wrote: post #103

rahimnathwani wrote: post #56

Earlier quoted context omitted.

> "debit" and "credit" and > think they have to do with > "owing" or "being owed" money. I think of it as 'owing' (liability) or 'owning' (asset). When you credit an account, you either increase what you 'owe' on that account OR decrease what you 'own' on that account. Examples: - bank credits a customer account => bank owes more to its customers - company credits income account => company owes more to its shareholde…

That makes sense to me in terms of assets and liabilities, but when I read https://beancount.github.io/docs/the_double_entry_counting_m... and it described income as being negative and expense as being positive, it broke my brain a little bit.

[flagged]

Re: Accounting For Developers, Part I

#178

Post by 2143 » Thu, Aug 18, 2022, 5:56 AM UTC

EvanAnderson wrote: post #25

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…

> Sometimes non-accounting people get hung-up on the words "debit" and "credit"

In took an undergrad accounting class centuries ago. I'm a CS major, but we were required to take a beginner class in accounting, which in retrospect was a good thing.

In the accounting class (the double-entry bookkeeping part), for any transaction two accounts were involved:

- Money was "debited" into one account. ie., money came into that amount (balance increased)

- That same money was "credited" from another account. ie., money left that account (balance decreased).

However, my bank seems to use the terminology in the opposite way. If $10 comes into my bank account, I get a message saying "$10 was credited into your account".

Likewise, if I send money elsewhere the message would be "$10 was debited from my account".

I'm told that if you look at it in some convoluted way the meaning of "debit" and "credit" is infact the same, even though at first glance is seems to be the opposite.

Now that I think about it, there was something to do with "asset", "liability" etc, on which the meaning of the terms depended on.

Re: Accounting For Developers, Part I

#179

Post by sudhirj » Thu, Aug 18, 2022, 5:57 AM UTC

Norgie93 wrote: post #117

sudhirj wrote: post #68

Earlier quoted context omitted.

This is currently just a side project, but yeah, if I have more than 10 buildings using it I'll probably take it seriously and bring in an (accountant cofounder).

Just chiming in - I'm an engineer who is also a CPA :). I'd be happy to attempt to answer any questions you might have. It's been a few years since I was accounting professionally, but maybe I can still be helpful.

Thanks! I can't find contact details on your profile, though could you mail sudhir.j@gmail.com or tweet @sudhirj?

Re: Accounting For Developers, Part I

#180

Post by wrycoder » Thu, Aug 18, 2022, 5:59 AM UTC

jldugger wrote: post #90

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…

> And yet like all previous endorsements I've heard, I've not been able to take away why it is so important. Double entry accounting is basically a shorthand for the Fundamental Equation of Accounting: Income - Expenses = (Assets - Liabilities) + Equity. We call it "double entry" accounting because within the constraints of that equation you cannot adjust one account without also adjusting at least one other account.…

It's usually expressed as

Assets + Expense = Liabilities + Equity + Income

The two accounts on the left normally carry a debit balance, and three on the right normally carry a credit balance.

At the end of the accounting period, subtract the Expense balance from both sides of the equation, and close out (Income - Expense) into Equity, i.e. if that was positive, Equity increases.

Or, in a computerized system,

Assets + Expense - Liabilities - Equity - Income = 0