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

141–150 of 193 posts

Re: Accounting For Developers, Part I

#141

Post by rthomas6 »

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

I use this, except I use Beancount. It's written in Python and is easier to write your own little extensions. There's also a GUI called Fava that goes along with it and is really good.

Re: Accounting For Developers, Part I

#142

Post by jwarden »

rahimnathwani wrote: post #101
onefuncman wrote: post #97

Earlier quoted context omitted.

> When an account is CREDITED, this always represents an increase in liabilities[0] (or equivalently, a decrease in assets). > When an account is DEBITED, this always represents an increase in assets (or equivalently, a decrease in liabilities). This is where you're wrong. You can credit and debit Accounts Payable and Accounts Receivable. If you credit AP, you're increasing liability, if you credit AR, you're increas…

"If you credit AP, you're increasing liability, if you credit AR, you're increasing assets." This is incorrect. If you credit AR, you're decreasing assets.[0] [0] https://www.freshbooks.com/hub/accounting/debit-and-credit#:... .

rahimnathwani is correct here and has explained himself well. I generally don’t think of equity as a liability, but if you think of it is money owed to shareholders, then a credit can indeed be seen as an increase in money owed. Since debits always equal credits,

money OWNed = money OWed

And thus:

Assets = Liabilities + Equity

Re: Accounting For Developers, Part I

#143

Post by [deleted] »

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…

[deleted]

Re: Accounting For Developers, Part I

#144

Post by rthomas6 »

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…

My non-expert understanding for number 1 is that you would record the widget account in denominations of widgets, and separately, record the widget cost for that transaction. That's what you do in beancount anyway, which is what I use for home budgeting. Like this:

  2022-08-17 * "Purchase Widgets"
    Assets:Cash                  -100.00 USD
    Assets:Inventory:Widgets      10 WIDGET {10 USD}
Number 2 is just the reverse:

  2022-08-18 * "Sell Widget"
    Assets:Cash                   20 USD
    Assets:Inventory:Widgets      -1 WIDGET {20 USD}
Probably there's some other more professional way to do it, but this is what makes sense to me, and it's double entry.

Re: Accounting For Developers, Part I

#145

Post by rthomas6 »

sudhirj wrote: post #58

Can someone help with a few ideas on this topic? I've been volunteered to be the treasurer at my building home owner's association, and trying to keep accounts for the whole building on a single excel sheet is a shitshow. So obviously I'm building a SaaS that will handle all the accounts for every HOA in the whole world and become a trillion dollar product. But I need to figure out which accounts are debit normal and…

If you are comfortable with a text editor, I recommend https://plaintextaccounting.org. I use Beancount with the Fava gui. It's great.

Re: Accounting For Developers, Part I

#146

Post by jdasdf »

rthomas6 wrote: post #144
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…

My non-expert understanding for number 1 is that you would record the widget account in denominations of widgets, and separately, record the widget cost for that transaction. That's what you do in beancount anyway, which is what I use for home budgeting. Like this: 2022-08-17 * "Purchase Widgets" Assets:Cash -100.00 USD Assets:Inventory:Widgets 10 WIDGET {10 USD} Number 2 is just the reverse: 2022-08-18 * "Sell Widge…

Wouldn't that lead to a negative inventory value when the number of widgets is still positive?

Re: Accounting For Developers, Part I

#147

Post by rthomas6 »

jdasdf wrote: post #146
rthomas6 wrote: post #144

Earlier quoted context omitted.

My non-expert understanding for number 1 is that you would record the widget account in denominations of widgets, and separately, record the widget cost for that transaction. That's what you do in beancount anyway, which is what I use for home budgeting. Like this: 2022-08-17 * "Purchase Widgets" Assets:Cash -100.00 USD Assets:Inventory:Widgets 10 WIDGET {10 USD} Number 2 is just the reverse: 2022-08-18 * "Sell Widge…

Wouldn't that lead to a negative inventory value when the number of widgets is still positive?

No, because the inventory value is denominated in widgets, not USD.

What's important is that each transaction balances to zero. It doesn't have to balance across transactions.

Re: Accounting For Developers, Part I

#148

Post by rest4thewicked »

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…

It depends on the accounting treatment that you need to track under. Average cost is easier to track with a Ledger type solution.

You keep track of inventory in two ways on two different Ledger Accounts under different "currencies." Inventory in dollars and inventory in units.

When you make a sale calculate average per unit value by dividing inventory USD value by number of units. Then your COGS value is driven by that average * units.

Each purchase adds to both the USD and the units accounts.

Re: Accounting For Developers, Part I

#149

Post by meekaaku »

rr888 wrote: post #130
alain94040 wrote: post #29

Earlier quoted context omitted.

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?

I think you can expand this explanation with database terminology. In modern RDBMS, you could have naive implementation with two account's balance, and increment one decrement the other. But without transactions it just isn't safe, its better to have one row in a table with a debit and credit. Now if you're doing accounts by hand you really need that single line transaction record.

> its better to have one row in a table with a debit and credit.

No. Some transactions have 3 lines, eg: two debits and one credit. Some examples: - Split payment at a shop, $100 item bought with $70 cheque and $30 cash would be credit sales $100 debit cash $30 debit bank $70

Now if you introduce sales tax or VAT/GST, its more complicated. Say the $100 item is actually $90 + $10 VAT, then entries goes: credit sales $90 credit vat-payable $10 debit cash $30 debit bank $70

Re: Accounting For Developers, Part I

#150

Post by drc500free »

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 is helpful when you have a large number of internal accounts that regularly transact with each other. The primary benefit is that you can determine the balance of any given account by just looking at that one account, and the business as a whole by combining all transactions across all accounts.

In an accounting sense, it's useful for implementing accrual bookkeeping. Accrual bookkeeping matches every dollar of revenue with all associated expenses by hiding cashflows in asset and liability accounts, until it's time to match them all up and recognize them simultaneously.

If you're not working with a system where you have a lot of transactions flowing between accounts where you control both ends, you might not get as much benefit from double-entry.

Post reply on HN