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

131–140 of 193 posts

Re: Accounting For Developers, Part I

#131

Post by jdasdf »

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 the cost it took me to get them there.

2 - How do i account for profits? Back to the example, i move the 1$ from my cash onto the inventory. Great now i have 1$ in inventory. I sell half my inventory for 2$. How exactly do i account for this? I still have presumably 0.5$ in inventory, and now i got 2$ in cash, but where did that come from and go?

Presumably i'd take 2$ from the inventory and put it in a client account, but does that mean i now have negative 1$ inventory? Sure the client account would also have another transaction putting the 2$ into my cash account. And wouldn't this make one transaction into actually 2 transactions? One from inventory to client, and one from client to cash?

If you can help me grasp this i would really appreciate it!

Re: Accounting For Developers, Part I

#132

Post by rr888 »

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…

Much of the Why is because bookkeeping predates computers, so its all about ledgers in books.

Re: Accounting For Developers, Part I

#133

Post by WorldMaker »

fluoridation wrote: post #122
kojim wrote: post #116

Earlier quoted context omitted.

I agree that from a developer's perspective and certainly in the frontend it doesn't make sense to show a positive user balance as negative. But to a finance team, cash on your company's books (debits) needs to have the opposite polarity of money that your users hold (credits). My underlying point is that it's really hard to make that the case without using the credits and debits language.

>But to a finance team, cash on your company's books (debits) needs to have the opposite polarity of money that your users hold (credits). Then you're arguing how the value should be displayed . There's no reason to prefer one sign or the other in the codebase, as long as it's always displayed correctly to the correct actors.

Having been involved in various roles of double entry accounting adjacent tools, the next level up is realizing that it is easier to display the correct sign if you store things unsigned and use debit/credit nomenclature even in your DB model/codebase. It's not just that this makes it easier to talk to the accountants using your system about the internals of that system, but that showing the right sign becomes simple "pattern matching" based on entirely on the type of account and the user's type. There's no "math" involved to switch signs based on how it is "stored" in the codebase, the displayed signs are always a UI element that is clearly dependent on its inputs.

The centuries of accountant's aversion to using negative numbers in day to day accounting usage has abstraction uses even in your codebase.

Re: Accounting For Developers, Part I

#134

Post by sbuttgereit »

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…

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 revenue - expenses in prior years.

Transactions assuming you start with $1 in cash.

When you buy the inventory you credit the Cash Account (asset) by $1 and debit the Inventory Account (asset) by $1. In essence you've converted the cash asset into an inventory asset.

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.

In the end you remove the inventory as an expense to Costs of Goods Sold and you have new cash from sales revenue. From the accounting equation perspective it looks like:

Before inventory purchase:

$1 (Asset/Cash) = $1 (Equity, assuming it wasn't borrowed) + $0 (Liabilities)

After Inventory Purchase:

$1 (Asset/Inventory) = $1 (Equity) + $0 (Liabilities)

After Sale:

$2 (Asset/Cash) = $1 (Equity) + ($2 (Revenue/Sales) - $1 (Expense/COGS)) + $0 (Liabilities)

Re: Accounting For Developers, Part I

#135

Post by WorldMaker »

jessaustin wrote: post #125
redandblack wrote: post #89

Earlier quoted context omitted.

I prefer not to ascribe semantics to accounting credit/debit - only thing that matters is it is consistently applied and balances out. I think of this as being similar to primary key constraints - my rule is primary keys should not have a business meaning. I have walked into many situation where they would have implemented so - and usually will fail to convincing them otherwise.

...my rule is primary keys should not have a business meaning. OMG I so agree with this. I worked at a company where we wasted so much time, and moved so much more slowly, just because some previous technical person hadn't completely thought through the implications of ever including primary keys on the GL feed. The whole time I was there I begged the accounting drones to forget about this concept, repeatedly enlisti…

It certainly depends on if you are working with natural keys or artificial ones. Somewhere in the decades of applied relational calculus we lost sight of natural keys and what those even are. In part because they are hard and it turns out that few natural keys seem to exist "naturally" in real life because everything is mutable, everything is a ship of Theseus, names/addressses/everything changes. So we've turned to artificial keys for primary keys and out of momentum most of these artificial keys are simple auto-incrementing numbers and a dumb part of brain looks at simple auto-incrementing numbers and thinks "I understand these" and "I see the patterns in these" and runs off and starts using them everywhere for business logic and corporate procedure and potentially information disclosing URLs and so forth.

(And then simple auto-incrementing numbers turn out to be not so simple indeed the first time you need to shard or otherwise decentralize your database for whatever reason.)

I don't think there's an easy answer here. We can't return to the ideal of natural keys, because reality has shown that's a pipe-dream. We can focus on using more artificial primary keys that don't look like simple auto-incrementing numbers like GUIDs and Snowflakes and ULIDs and string slugs and more, but those aren't without overhead or tradeoffs both at the database level in the raw and in the user experience and these business processes that we don't want to use our raw database IDs but we can't just give a more natural equivalent either. ("How can I refer to Issue 6D038E7E-A0D8-45EB-AAC6-1E3FEC9DA5B8 on the phone or in a meeting?" "How can I excel spreadsheet my way through the system's data without being lost?" Etc and so forth. On the one hand it feels like a failure in the system if so many processes still need to work outside of and around the system, but on the other hand humans and businesses are social creatures and these side processes arise naturally like breathing to that combination of humans inside a business.)

Re: Accounting For Developers, Part I

#136

Post by jdasdf »

sbuttgereit wrote: post #134
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…

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 address question 1 at all.

You statement works if you're zero-ing out your inventory account, but what happens if you have 3 dollars, and put them into your inventory account in 2 transactions, one for 1$ and one for 2$. Both transactions actually added the exact same number of widgets to your actual inventory, say 2 widgets one cost 1$ the other 2$. They are otherwise in differentiable.

When you go to credit the COGS account because you sold 1 widget, how much do you credit? 1$ (the cheapest you bought), 2$ (the most expensive), or 1.5$ (the average)? Whichever one you pick, you're going to have issues later on when you buy/sell additional widgets...

Re: Accounting For Developers, Part I

#137

Post by aktuel »

lucasrocha259 wrote: post #57
quelltext wrote: post #53

I think the figure / chart in "Effect on balance by account type" is wrong / flipped. It says that debits decrease debit normal account balance which doesn't match the text description or subsequent examples.

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 understanding this right?

Re: Accounting For Developers, Part I

#138

Post by wruza »

kojim wrote: post #83
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…

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?

Because debit and credit may be looked at differently in fee calculation. You may not be able to un-debit the same amount easily. This is just a historical/established practice, but you cannot squash the two into +/-, because you would lose “cancellation” in cases when a mistake is discovered but the quarter is done and already git-pushed to IRS/etc. See “storno (accounting)”.

Re: Accounting For Developers, Part I

#139

Post by wruza »

redandblack wrote: post #89
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…

I prefer not to ascribe semantics to accounting credit/debit - only thing that matters is it is consistently applied and balances out. I think of this as being similar to primary key constraints - my rule is primary keys should not have a business meaning. I have walked into many situation where they would have implemented so - and usually will fail to convincing them otherwise.

This is correct. There are some sensible business defaults, but pure debit and credit have no specific meaning. It’s just yet another analytical dimension handily entangled with double-entry.

This fact is rarely mentioned in business talks so people have a whole variety of ideas what they mean, as you can see itt.

Re: Accounting For Developers, Part I

#140

Post by rthomas6 »

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…

People are making this too complicated.

I transfer money from savings to checking. That is a double entry. Money comes out of savings and goes into checking. Savings->Checking

I need to use the food money envelope to buy clothing. Double entry is just keeping track of what I did. Food Envelope->Clothing. Then 6 months later I can see where my money actually went, and how much I spent on food, and clothing, separate from how much I put in the food money envelope.

Post reply on HN