Comment by jfengel
1 year ago
Thanks. That's actually really helpful. Of course every transaction is a credit or debit depending on your point of view.
That's probably not the way I would have designed it. I'd probably have designed it from the point of view of the account, so that we'd all agree on what addition and subtraction mean. But that's my programmery point of view. I imagine that they're more concerned with the flows -- not just the numbers, but especially the actual materials being bought and sold.
It kind of works that way, it’s just confusing that the bank tells you their point of view.
Your bank account is really two accounts: an asset on your books, and a liability on the bank’s books.
When you talk about accounting for physical inventory, that’s a whole new can of worms.
The most popular way I see is this:
- you keep track of goods by their cost to you (not their value once sold)
- every time you buy item xyz, you increase an asset account (perhaps called “stock” and the transaction labeled “xyz”). You also keep track of the number of xyz. Say you buy 10 for $10 each, then another 10 for $20 each. Now you have 20 and your xyz is valued at $300. Average cost: $15
- every time you sell or lose some xyz, you adjust the number of xyz, and reduce the asset account by the average value of those items at the time of the transaction, or $15 in this example. The other account would be cost_of_goods_sold or stock_shrinkage.
Many other approaches also work.
The goal of double entry accounting is to enable an audit of the ledger and catching errors by the bookkeeper.
Think about how you're going to do that with your concept. You will likely end up with something extremely close to what double entry accounting is after a few iterations