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

151–160 of 193 posts

Re: Accounting For Developers, Part I

#151

Post by ghoward »

Funny that this would show up when a month ago, GnuCash was submitted on this site. [1]

I decided then that I would take the opportunity to learn how to use it and learn accounting properly for my family budget, mostly because I want to start a small business eventually, and double-entry accounting will be necessary for that.

So I did.

It went extremely well. The GnuCash Tutorial and Concepts Guide [2] was exactly what I needed.

For all you developers wanting to learn double-entry accounting, I have one piece of advice: actually learn to use the terms that accountants use.

Sure, it may be annoying that you have to say that something is a "debit" or a "credit" versus just saying that it's a positive or a negative amount.

But in my experience, that annoyance passes quickly once it clicks.

Do take the time to learn it right. And if you use GnuCash, set it to use the standard terms.

[1]: https://news.ycombinator.com/item?id=32136384

[2]: https://www.gnucash.org/docs/v4/C/gnucash-guide/index.html

Re: Accounting For Developers, Part I

#152

Post by NoboruWataya »

zdw wrote: post #4

Whenever accounting comes up in geek circles, it's worth mentioning ledger and similar systems it inspired which use plain text files to implement double entry accounting: https://www.ledger-cli.org I used this system for years as a consultant - it's also pretty easy to extend - I did this using the Python API to implement an arbitrary RPN calculator on top of it: https://github.com/zdw/ledgercalc

Also GnuCash, which I feel requires no elaboration on HN as it is so frequently its own topic of discussion.

Re: Accounting For Developers, Part I

#153

Post by drc500free »

jdasdf wrote: post #136
sbuttgereit wrote: post #134

Earlier quoted context omitted.

This is going to be quick, dirty, and simplistic. I've explained deeper in a different comment. But this should help. Things to keep in mind... The accounting equation: Assets = Shareholder Equity + Liabilities. This expresses what we own (assets) and who has a claim over what we own (shareholders, creditors). Shareholder's equity can be expanded as: Retained Earnings + (Revenue - Expenses); retained earnings is reve…

>When you sell the inventory you have a multi-part transaction. Inventory movement: Credit the Inventory Account (asset) by $1 and Debit the Costs of Goods Sold Account (Expense) by $1. You no longer have the inventory. The Sale part: Debit the Cash Account (asset) by $2 and Credit the Sales Account (Revenue) by $2. You have received a new $2. So that answers part of question 2, but not entirely. And it doesn't addre…

Under GAAP rules, you could use FIFO, LIFO, or average for inventory costs. IIRC firms generally use LIFO, since that usually results in higher cost of goods sold, and therefore lower taxes. They can't do exactly "most expensive first," but LIFO is pretty close to that since inventory prices tend to increase.

Tracking how many units were bought at each time at each price is not part of the core accounting ledgers of debits and credits, that would be supplemental info that helps you determine how large the debits and credits should be whenever you use up inventory.

Re: Accounting For Developers, Part I

#154

Post by meekaaku »

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…

Inventory is not a second currency. Multiple currencies are handled using Exchange loss/gain accounts. I will try running your example from scratch. You begin business with $100 capital which is deposited to your bank account. I am using Cr for credit, Db for Debit

1. Starting capital: Capital Cr $100, Bank Db $100

2. Purchase widgets worth $50: Bank Cr $50, Inventory Db $50

3. You sell half of this inventory (valued $25) for $75 in cash:

Sales Cr $75, Cash Db $75

Inventory Cr $25, Cost of goods sold Db $25

4. You sell rest of your inventory on credit to John for $110:

Sales Cr $110, Accounts Receivable-John Db $110,

Inventory Cr $25, Cost of goods sold Db $25

5. You pay $30 salaries via cheque: Bank Cr $30, Expense-Salary Db $30

At the end of all this your PL (profit loss statement) would look like this

Sales: $185 (110 + 75)

Cost of goods sold: $50 (as you sold all of the inventory)

Gross profit = sales - cost of goods sold = 185 - 50 = $135

Expenses = $30 (salaries only)

Net profit = gross profit - expenses = 135 - 30 = $105

Your balance sheet at the end of all this will be :

Capital: Cr $100

Accumulated profit: Cr $105

Bank: Db $20

Cash: Db $75

AR John: Db $110

Inventory: 0 (as you sold all).

Note the balance sheet balances nicely as Capital + Accumulated profit = bank + cash + AR + inventory

Re: Accounting For Developers, Part I

#155

Post by darcys22 »

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 what it affected.

The most simple case here is that the income/expense also affects your bank account. By tracking the bank account you now can check that your "Predicted" bank balance according to your list is actually what is in the bank account. If they don't match then you know for certain something got missed.

It doesn't solve all the errors that can possibly occur, but it makes sure that the basics are at least covered.

Re: Accounting For Developers, Part I

#156

Post by jwarden »

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…

It's correct that "debit" and "credit" don't have to do with "owing/being owed" money. But they do have to do with "OWNing/being owed". This apparently subtle difference provides powerful insight.

If you look at equity as money owed to shareholders, then the left side of the balance sheet is money owned, and the right side of the balance sheet is money owed.

  Money OWNEd = Money OWEd

  Assets      = Liabilities + Equity
A debit either increases money OWNed on the left side of the balance sheet, or decreases money OWEd on the right side.

Re: Accounting For Developers, Part I

#157

Post by candiddevmike »

jimnotgym wrote: post #123
kojim wrote: post #83

Earlier quoted context omitted.

Debits and credits is the only way to give your team a common, consistent "language" for dealing with money, and being able to speak this language as a dev gives you superpowers. Accounting was invented before negative numbers. Because of this, instead of counting money as positive or negative amounts, it uses the debits and credits. Instead of subtracting funds from one account and adding them to another, we talk ab…

> But it’s the 21st century and we have negative numbers now - why not just use positive and negative numbers? Using positive and negative numbers gets ambiguous. In computerised accounting it is completely normal to use negative numbers for credits and positive numbers for debits. That way a whole trial balance sums to zero. Very neat indeed. What is missing above is the concept of accounts to put the balance in. Fo…

What you're describing is accrual accounting (accounts payable/receivable). It is one method of bookkeeping, but a lot of other businesses tend to use cash (which deals in absolutes, you spent 5, you earned 5, etc).

Re: Accounting For Developers, Part I

#158

Post by hooverd »

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…

Thanks for the examples!

Re: Accounting For Developers, Part I

#159

Post by lucasrocha259 »

aktuel wrote: post #137
lucasrocha259 wrote: post #57

Earlier quoted context omitted.

Author here. This is helpful feedback, we could have perhaps taken more time before jumping in on the Modern Bagelry example. A common misconception is that one account needs to increase while the other needs to decrease. But what we are actually showing that they can both increase or decrease in tandem, depending on the debit and credit entries in the transaction and the direction of the accounts. In the first trans…

So you basically have these two types of account, because you want all accounts to have a positive balance in general? If we would not care about certain types of accounts having negative balances, then we could say that for each transaction the sum of all account changes would always have to add up to zero. We could then still -depending on the account type- flip the sign after calculating the account balance. Am I…

Part of the idea here is that debits = credits is a cleaner way to depict balances 'netting out to zero' than using positive or negative balances.

Re: Accounting For Developers, Part I

#160

Post by barking_biscuit »

candiddevmike wrote: post #157
jimnotgym wrote: post #123

Earlier quoted context omitted.

> But it’s the 21st century and we have negative numbers now - why not just use positive and negative numbers? Using positive and negative numbers gets ambiguous. In computerised accounting it is completely normal to use negative numbers for credits and positive numbers for debits. That way a whole trial balance sums to zero. Very neat indeed. What is missing above is the concept of accounts to put the balance in. Fo…

What you're describing is accrual accounting (accounts payable/receivable). It is one method of bookkeeping, but a lot of other businesses tend to use cash (which deals in absolutes, you spent 5, you earned 5, etc).

You can model the data in such a way that the recorded transactions can be reported on in either accrual or cash basis.
Post reply on HN