[HN Gopher] Accounting For Developers, Part I
___________________________________________________________________
Accounting For Developers, Part I
Author : qin
Score : 442 points
Date : 2022-08-17 12:59 UTC (10 hours ago)
(HTM) web link (www.moderntreasury.com)
(TXT) w3m dump (www.moderntreasury.com)
| Naga wrote:
| This is a pretty good article about the basics! I'm a CPA who is
| now working in the tech space. I've helped work on some
| accounting software and other finance-type processes. I'm happy
| to answer any questions if anyone has them! Either here, or my
| email is in my profile.
| tbonesteaks wrote:
| Any resources you would recommend to learn the basics and/or
| fundamentals of accounting and finance?
| Naga wrote:
| Accounting is also a strange field because its a bunch of
| almost unrelated fields stuck together. Accounting covers
| financial accounting (dealing with recording transactions,
| representing reality, etc), tax, management and cost
| accounting (things like tracking performance, figuring out
| what the widget you produced actually costs you, once you've
| included the direct costs and an estimate of overhead) and a
| whole slew of other things like internal controls, governance
| questions (how do you align incentives in an organization?),
| etc. Picking up a textbook on financial accounting is
| probably a good starting place to get the basics of
| debits/credits, but from there it depends what your interests
| are.
|
| For books on finance, I recommend Niall Ferguson's Ascent of
| Money as a pretty good introduction into the history of
| finance and how it all sortof fits together.
| akersten wrote:
| > A credit entry will always increase the balance of a credit
| normal account and decrease the balance of a debit normal
| account. Put differently:
|
| Not sure if the author is reading comments here, but the diagram
| after this sentence shows the opposite!
| stocknoob wrote:
| Yes, that was quite confusing. Thanks for mentioning.
| lucasrocha259 wrote:
| Author here. We just pushed out a fix. Thank you for flagging!
| selljamhere wrote:
| I noticed this, too. The summary bullets at the end of the post
| also oppose the diagram. Probably a simple mixup of
| credit/debit in the left column. The rest of the article
| usually lists do it first.
| joshstrange wrote:
| 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" is a system user that is allowed
| to go "into the negative" since it's responsible in a way for
| "minting" money into the system.
|
| I'll be the first to agree that a double-entry system would make
| some of my code simpler. Currently listing out transactions is
| somewhat annoying since you need to know the context (the user
| requesting the list) so you display the data correctly. "Spent $X
| at vendor" makes sense as a description from the user's
| perspective but not from the vendor's. Double entry would solve
| this as I could generate a description specific to each user's
| perspective "Spent $X at vendor" "Sold $X to user" or something
| like that.
|
| But I'm sure there are other advantages to a double-entry system
| that I'm missing so any resources would be appreciated.
|
| I've got some time to rewrite that system and I think double-
| entry sounds like the right path forward. It probably was the
| right path from the start but I was busy building, not
| researching accounting methods like I probably should have been.
| That said, this project of mine has been very successful (from my
| perspective) and who knows if it would have been had I gotten
| mired down in accounting from the start.
| mytailorisrich wrote:
| Liabilities (Edit: plus equity) must always equal assets. This
| is the basic accounting principle.
|
| Double entry enforces this and also ensures that nothing is
| lost into thin air by requiring that debits and credits match.
|
| So for instance, if you spend money to buy a new laptop that
| money hasn't disappeared into thin air, it has been used to buy
| a tangible asset so while your cash has decreased your tangible
| assets have increased by the same amount (double entry) and
| your accounts are still balanced.
|
| Or, if you pay a bill then both your liabilities and your
| assets (double entry) have decreased by the same amount and,
| again, your accounts are still balanced.
|
| That's how you keep track of this and ensure (well, at least it
| helps) that your financial situation is accurately recorded.
| kevmarsden wrote:
| To be a bit more specific: Assets = Liabilities + Equity
| mikeyouse wrote:
| Right. Was going to comment the same. If you sell a product
| for $100 that only cost you $90 to produce, that $10 isn't
| a 'liability', it's profit / retained earnings (an equity
| account).
| mathgeek wrote:
| A pretty quick Google found what I feel are some decent/good
| resources that show the tradeoffs:
|
| https://en.wikipedia.org/wiki/Double-entry_bookkeeping
| (obviously the most technical as it's Wikipedia)
|
| https://anderscpa.com/accounting-102-startups-double-entry/
| (specifically startup-focused)
|
| https://www.nerdwallet.com/article/small-business/double-ent...
|
| https://www.fool.com/the-ascent/small-business/accounting/ar...
| jwsteigerwalt wrote:
| One sentence from the article should be emphasized: "Double-
| entry systems are more reliable at tracking money than any
| other viable alternative." So true, 100's of years and no
| better system has ever evolved. I would argue that any
| blockchain system that attempts to tackle this problem has a
| double entry aspect if it's useful.
| jedberg wrote:
| The blockchain is basically triple-entry accounting. Every
| transaction has a public record to go along with your own two
| column entry.
| rr888 wrote:
| Much of the Why is because bookkeeping predates computers, so
| its all about ledgers in books.
| realityking wrote:
| From my, very limited understanding, the big benefit is the
| representation of obligations and receivables.
|
| For example, if you take a bank loan of $1 you'd make an entry
| for your cash balance to be $1 and your obligations to your
| bank being $1. Your books are balanced.
|
| Now you use that $1 to buy a machine. $1 down from your cash,
| $1 up in your non-cash assets.
|
| For what if instead you pay someone for a service for $1? $1
| added to your expenses, $1 down from your cash.
|
| And so on, and so on. At the end of the day you have a fairly
| good idea where your money is coming from and where it's going
| as well as any outstanding obligations and receivables.
|
| One of the main aspect is that there's an element of validation
| in here. If your books aren't balanced, something is off.
| stanski wrote:
| I'm incorporated in Canada and have done my own corporate
| taxes in the past.
|
| There is no hope to get this done right unless you use double
| entry accounting as every dollar has to be accounted for.
| Unlike personal taxes, where you only declare your income and
| pay a tax on that, every dollar that enters or leaves the
| company, or becomes a different kind of asset (say computer
| hardware) has to be declared and everything has to balance at
| the end of year.
| drc500free wrote:
| 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.
| Naga wrote:
| One of the big advantages of double-entry accounting is that it
| lets you model pretty complicated events in a simple way. I
| think its a common misconception that transactions have two
| sides to them, debits and credits. It probably comes from the
| name, and that most simple examples only have one two sides.
| Really, its _at least_ two sides. The important characteristic
| is that the debits must equal the credits, in value not in
| quantity.
|
| In reality, its very infrequent that transactions will only
| have one debit and one credit. Lets say you sell a service to
| someone, a year of service for $100. This sounds simple, debit
| cash for $100 and credit sales revenue for $100. But was there
| sales tax on it? You might have actually collected $115 from
| them, in which case the entry is to "debit cash for $115,
| credit sales revenue for $100 and credit sales tax liability
| for $15". This impacts three different accounts, but really any
| transaction could impact n accounts. This both simplifies what
| you need to do to model it, but also acts as a shortcut to the
| user.
|
| It also has the side effect of being a signal that the sales
| tax collected and the sales revenue are related. You could also
| record two separate transactions, one for $100 and one for $15,
| but the bank statement probably has $115 instead of $100, so
| how could you ever know what was what? As a former auditor,
| this is crucial to understanding how past transactions occurred
| and what they were for.
| tenacious_tuna wrote:
| > Lets say you sell a service to someone, a year of service
| for $100. This sounds simple, debit cash for $100 and credit
| sales revenue for $100
|
| I'm confused, this seems like you would credit _both_ cash
| and sales revenue $100... since you 'd have received $100
| from whomever bought your service, so youd have $100 more
| cash, and for tax accounting, you'd have sold $100 worth of
| stuff as well.
| projektfu wrote:
| In the double-entry model, things follow the accounting
| identity:
|
| Assets = Liabilities + Equity
|
| and its more dynamic corollary since Equity = Capital +
| Income - Expenses, simplified to keep everything positive:
|
| Assets + Expenses = Liabilities + Equity + Income
|
| Assets and Expenses are considered to have a debit balance
| and the other three have a credit balance. Debit represents
| money "owed to" the business and credit represents money
| "owed by" the business. People get hung up on these terms
| because they think of credits as good things when their
| checking account gets credited and debits as bad things.
| But that terminology is because the bank has exactly the
| opposite relationship. Your checking account is their
| liability (and your mortgage is their asset).
|
| Thus, when you are paid $100 by bank transfer for a
| service, you credit "Sales" by $100 and debit "Checking" by
| $100 as well.
|
| In the accrual method, you might prefer to credit "Sales"
| by $8.33 and "Prepaid Sales" (a liability) by $92.67, and
| debit Checking by $100. Then each month you would debit
| "Prepaid Sales" by $100/12 and credit "Sales" the same
| amount. This would keep you from having weird ups and downs
| when looking at monthly income statements. It gets tedious
| to do by hand, but computers make it easy when they do it
| right.
| hundt wrote:
| As the article explains, debits increase the balance of
| debit normal accounts, whereas credits increase the balance
| of credit normal accounts.
| yobbo wrote:
| > 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
|
| This is what double-entry looks like in a database.
|
| Ironically, single-entry would have one column, and two records
| for each transaction.
| cperciva wrote:
| Double entry bookkeeping doesn't mean that you have two records
| for each transaction. In fact, it's the exact opposite!
| Transactions fundamentally have two parts -- where the money is
| coming from and where the money is going -- and double entry
| bookkeeping says that _both of those entries are part of the
| same record_.
| jsmith45 wrote:
| My understanding was that historically double entry
| accounting very much had each entry stored separately
| (although tied together by some transaction identifier). You
| would normally add both at the same time, so one could
| consider it "one record" on that basis, but physically they
| were separate entries often in separate physical books.
|
| In computerized systems, having a single record in one place,
| and virtually constructing the ledgers from it is feasible.
| Under the constraints that all transactions debit from just
| one ledger, and credit to just one ledger, storing each
| transaction as tuple (id, amount, debited ledger, credited
| ledger) is feasible.
|
| Double entry does have the slight advantage of being possible
| to generalize to allow one transaction to debit from multiple
| ledgers or credit to multiple ledgers, as long as all the
| debited amounts sum to the same as all the credited amounts.
|
| It has a disadvantage in that the storage format does not
| guarantee validity, unlike the tuple method.
| ElevenLathe wrote:
| You are right that there would traditionally be separate
| books. The first, a "day book" would be a list of
| transactions that a merchant (or his servant/employee)
| would write down as business took place. This would say
| something like "I sold 10 spools of yarn for 8 florins
| apiece to Mr. Lucio" (remember that this all started a
| system to keep track of the affairs of Florentine
| Renaissance merchants). Later, after business had concluded
| for the day, the merchant (or his bookkeeper) would "post"
| the transaction to the ledger, which was a book that had a
| page for each "account." He would go through the daybook
| and, for each transaction, post it to (at least) two
| accounts, debiting and crediting equal amounts so that the
| books "balanced." This left him with a single number for
| each account which represented the total net activity for
| that account. This is the account's "balance" and is a very
| interesting piece of information for a merchant, so much so
| that it warrants all the associated ceremony.
|
| Today, the "posting" can usually be done by a computer.
| There is some human creativity/regulation involved in
| deciding which specific accounts to credit/debit, but this
| can be noted in the "daybook entry" (more likely a database
| record somewhere than something literally written in a
| book) instead of being put off until the posting step.
|
| The important characteristic is what the grandparent noted,
| that each transaction (in the daybook) tracks completely
| where each cent (or florin) came from and where it went. If
| a system of bookkeeping has this characteristic, I think it
| can be called double-entry, at least in spirit. A hard
| requirement that a transaction occur between exactly two
| accounts makes some kinds of events difficult (or
| impossible) to model, but is still conceptually the same.
| neffy wrote:
| This is banking centric, but does have worked examples that may
| be useful.
|
| https://arxiv.org/abs/1204.1583
|
| Above and beyond other reasons, double entry book keeping has
| some very nice error detection properties (the original reason
| for its invention) that actually make it quite nice to use as a
| basis for this kind of software, as it provides a way to catch
| some bugs very quickly.
| mmcdermott wrote:
| In addition to the detail/rigor that most describe, double
| entry accounting acts as a checksum. If things don't balance
| there is a problem somewhere. It may or may not be malicious,
| but there is something wrong.
| remram wrote:
| This is a double-entry system. You are already doing it. Every
| transaction decreases an account and increases another.
| jedberg wrote:
| For those of you who like the blockchain, think of that as triple
| entry accounting -- you put one charge as credit in one column,
| debit in another, and a public record on the blockchain.
| sudhirj wrote:
| 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 credit normal and how transactions should flow first.
|
| So far I have the following accounts:
|
| * Per-apartment accounts, like the account for Apt#A1, Apt#A2,
| Apt#B1 etc.
|
| * A Maintenance Receivable account - the account for maintenance
| payments that should have come in.
|
| * A actual current operating account - account that reflects the
| building's bank account, showing money that came in from
| apartments for maintenance payments and also expenses.
|
| * An Expenses account. For expenses.
|
| So far the typical transactions I can think of are:
|
| * Beginning of every month the maintenance is due (say 100), so
| each apartment gets a -100 with a corresponding +100 on
| Maintenance Receivable.
|
| * When an apartment pays, they get a +100, but this is money that
| actually lands in the current operating bank account, so that's a
| +100 too? I'm guessing this is where the genius of not using plus
| or minus but using debit and credit comes in. That avoids the
| confusion, one is a debit and one is a credit, but which is which
| and which is a debit normal and credit normal account?
|
| * When there's an expense, I remove money from the bank account
| account and put it in the expenses account.
|
| Seems sort of ok, but the Maintenance receivable account is
| always increasing. How do I set this up so I can correctly
| represent what an apartment owes while also capturing what it
| paid as inputs to the buildin's bank account?
| epa wrote:
| Assets are +, Liabilities are -. So a receivable is an asset
| and +100 is correct. when the money comes in, you need to +100
| cash and -100 receivable.
| sudhirj wrote:
| So when an apartment pays, is 4 entries in the single
| transaction? Credit their apartment account, debit the bank
| account, credit cash and debit receivables? Never thought of
| making 4 entries for a single transaction.
| projektfu wrote:
| You would have accounts receivable as a super-account for
| all your apartments. Its value would be the sum of the sub-
| accounts. The bank account would be a sub-account of all
| your cash accounts. So you only need to make two entries,
| one to the apartment's AR and one to the bank account.
|
| You should do yourself a favor and read a good textbook.
| The online resources are not great and are mostly geared
| toward getting you to buy a product. For example:
|
| https://www.worldcat.org/title/accounting/oclc/1127092943&r
| e...
| mNovak wrote:
| I would recommend getting comfortable with some basic double-
| entry accounting software like GNUcash [1]. I found that
| extremely helpful in learning how to reason about these things,
| as well as grasp the purpose of different types of accounts
| (asset vs A/R vs income etc). They also have pretty good docs
| and tutorials as I recall.
|
| Also then it'll quickly show you where the existing software
| falls flat (and it does) in terms of scriptability, scaling,
| etc.
|
| [1] https://www.gnucash.org/
| rahimnathwani wrote:
| Maintenance invoice issued: DR accounts
| receivable CR income
|
| Maintenance paid DR bank account CR
| accounts receivable
|
| Each apartment is _part of_ accounts receivable.
|
| Normally accounts receivable has a DR balance (because
| apartment owners pay you AFTER you invoice them, so they are
| usually DEBTors).
| sudhirj wrote:
| > Each apartment is part of accounts receivable.
|
| Like a sub-account? This is probably the mindfuck part. So
| every apartment owner who opens up their statement is seeing
| a filtered balance?
| rahimnathwani wrote:
| You could implement it as either a subaccount per customer
| (in which case the balance is just the sum of all txns in
| that account) or have 'apartment' as another dimension
| (field) you store (optionally) for each transaction.
|
| Either way you can get a sum of all txns that have hit that
| apartment's AR account.
| sudhirj wrote:
| Thanks, let me think about this. This feels
| counterintuitive to me, and increases complexity a bit.
| rthomas6 wrote:
| If you are comfortable with a text editor, I recommend
| https://plaintextaccounting.org. I use Beancount with the Fava
| gui. It's great.
| andruby wrote:
| If you're serious about building a SaaS tool (and I encourage
| it!), make sure to find someone with an accounting background
| to help you / advise you. Maybe they can be a good co-founder.
|
| (I've been working on a SaaS in the accountancy space for 6
| years and our two co-founders are an accountant and a software
| engineer. It's a good match)
| sudhirj wrote:
| 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).
| Norgie93 wrote:
| 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.
| dllthomas wrote:
| There is no accounting for developers.
| jdasdf wrote:
| 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!
| sbuttgereit wrote:
| 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)
| jdasdf wrote:
| >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...
| drc500free wrote:
| 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.
| rest4thewicked wrote:
| 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.
| rthomas6 wrote:
| 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.
| jdasdf wrote:
| Wouldn't that lead to a negative inventory value when the
| number of widgets is still positive?
| rthomas6 wrote:
| 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.
| meekaaku wrote:
| 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
| ghoward wrote:
| 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
| andix wrote:
| Some practical cases where you really need such a system:
|
| A customer pays one product with two different sources of payment
| (gift card + visa, or one half with cash and the other with card)
|
| You want to verify if the balance in the cash register, or on the
| credit card account are correct.
|
| You already received money from a customer, but it will take some
| time until you can create the invoice (for example you want to
| print the serial number on it, and don't know it yet), but for
| legal reasons you are not allowed to change an invoice later. So
| you have to record a payment without having an invoice yet.
| jwsteigerwalt wrote:
| Great post. This is so overlooked. I had a career in accounting
| and finance before technology and consider myself so lucky that
| the accounting concepts important to business and financial
| database design are no problem for me.
| swyx wrote:
| former CFA turned developer here. I've been doing an informal
| workshop on "Finance for Developers", figured I should share my
| material here for people looking for more. Not selling anything..
| yet but this stuff is easy for me to pump out given my previous
| career haha
|
| Reading:
| https://docs.google.com/document/d/1imIgNckZ_kM564fpGgTBtsqi...
|
| 1hr Youtube workshop: https://www.youtube.com/watch?v=Lelq40jILA4
|
| 2hr Audio podcast discussion:
| https://share.transistor.fm/s/0b9270a5
|
| to make a point directly related to this post - i believe
| accounting is the starting point for finance - but you can learn
| "just enough" accounting to make it work.
| quelltext wrote:
| 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.
| lucasrocha259 wrote:
| 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
| transaction cash increases because it's a debit entry in a
| debit normal account (cash); and equity also increases because
| it's a credit entry in a credit normal account (equity).
| aktuel wrote:
| 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?
| matdehaast wrote:
| For those interested, Tigerbeetle[0] is a high-peformance purpose
| built accounting database. It supports - double entry transfer -
| two-phase transfers (ie reserve an amount and post it later) -
| linked transfers (move money across multiple accounts atomically)
|
| Worth looking at.
|
| [0] - https://www.tigerbeetle.com/ &
| https://github.com/coilhq/tigerbeetle
| kinleyd wrote:
| Interesting. And Zig too? Hmm.
| jorangreef wrote:
| Thanks! I don't think we could have done TigerBeetle the way
| we did, without Zig. It's been two years now, and looking
| back the choice has worked out well for our design decisions.
| For example:
|
| - single-threaded control plane (thread-per-core
| architecture),
|
| - static memory allocation at startup (we never call malloc()
| or free() thereafter--no UAFs) for extreme memory efficiency
| (TB can address 100 TiB storage using only 1 GiB statically
| allocated memory),
|
| - explicit memory alignment expressed in the type system (for
| Direct I/O), and of course,
|
| - Zig's comptime which is insane. We use it to do all kinds
| of things like optimize the creation of Eyztinger layouts, or
| to eliminate length prefixes in our on disk LSM table
| formats.
| jorangreef wrote:
| Thanks!
|
| What we realized for TigerBeetle, is that double-entry is often
| lifted and brought directly into the networked world of
| distributed systems as double-entry, as a ledger database.
|
| However, most distributed financial systems of record also
| spend alot of their time talking to other distributed financial
| systems of record. So there are all these different entities
| (e.g. banks) all running different infrastructure and all
| wanting not only to track money _within_ their own system but
| also to move money safely _between_ systems.
|
| Historically, double-entry is great at tracking transactions
| _within_ a system or entity, but it 's not great at this
| intersection between double-entry and distributed systems,
| because of the way that networks fail.
|
| We were seeing that these systems all end up with the
| equivalent of a two-phase commit coordinator, which is alot of
| work to implement correctly on top of double-entry. And
| everyone is building these ad hoc ledgers that are not only
| ledgers but also two-phase commit coordinators.
|
| So what we've done for TigerBeetle [1], is to take double-entry
| and marry it with distributed systems, to make it really easy
| to track transactions as money enters and leaves a system, by
| providing two-phase double-entry transfers out of the box. For
| example, not only a debits/credits balance, but also the
| concept of pending/posted debits/credits balance.
|
| And then to package this all up as a mission-critical safe and
| performant (1m TPS) open source database that the whole
| ecosystem can partner with and build on.
|
| [1] I did a deep dive into TigerBeetle in a recent talk at the
| Recurse Center called "Let's Remix Distributed Database
| Design!" going into the storage fault research that we've
| implemented for TigerBeetle. For example, the safety reasons
| for why we didn't pick RAFT as our consensus, or the latency
| reasons for why we don't use LevelDB or RocksDB, and how our
| testing is inspired by FoundationDB's Deterministic Simulation
| Testing -- https://www.youtube.com/watch?v=rNmZZLant9o
| eatonphil wrote:
| Also one of the bigger Zig codebases out there for you PL
| nerds.
| jorangreef wrote:
| After the Zig compiler that is, which dwarfs TB's code base.
| The Zig core team are all machines. ;)
| ubermonkey wrote:
| This is a huge blindspot for our tribe, and as such is a GREAT
| resource. Bookmarking!
| EvanAnderson wrote:
| 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 credit is an entry in the
| right column." Without the context of the specific accounts being
| debited or credited the terms themselves mean nothing.
|
| Aside: A 100-level knowledge of accounting can confer near "super
| powers" when it comes to dealing with finance and accounting
| people. Double-entry bookkeeping is one of the oldest and
| longest-practiced "IT" disciplines. Your work probably touches
| revenue / expenses for your employer and someday you'll need to
| interface with accounting or finance people. Being able to speak
| the language, even poorly, has helped me gain trust and
| credibility that I don't believe speaking only in IT terms would
| have.
| rahimnathwani wrote:
| > "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
| shareholders
|
| - company credits accounts receivable => company owns less in
| unpaid invoices > Without the context of the
| > specific accounts being debited > or credited the terms
| > themselves mean nothing.
|
| This seems incorrect to me. > A debit is the
| entry in the left > column, and a credit is an >
| entry in the right column.
|
| Debits/credits concepts can exist (and we can operate on them)
| without the existence of left/right columns.
| Max-q wrote:
| > This seems incorrect to me.
|
| That's because the system is not built by programmers. Some
| accounts (that's accounting accounts, not bank accounts) are
| positive for you and some are negative. You need to know what
| kind of account it is to know if debit is good or bad for
| you.
| rahimnathwani wrote:
| "That's because the system is not built by programmers."
|
| That's definitely _not_ the reason I consider GP 's comment
| incorrect.
|
| (I'm a qualified accountant.)
| tunesmith wrote:
| That makes sense to me in terms of assets and liabilities,
| but when I read https://beancount.github.io/docs/the_double_e
| ntry_counting_m... and it described income as being negative
| and expense as being positive, it broke my brain a little
| bit.
| rahimnathwani wrote:
| Maybe the following will help. It might not click
| immediately but, when it does, there will no longer be any
| need to memorize what debits/credits are in the context of
| each of assets/liabilities/equity.
|
| Think of "shareholder's equity" aka "owner's equity" as
| being a liability. After all, doesn't a company _owe_ all
| its earnings to its owners?
|
| Now, consider that:
|
| - all income is a liability owed to shareholders. So any
| new income is an increase in the amount owed to these
| shareholder 'creditors', represented by a credit entry
|
| - similar but opposite reasoning says that a new expense is
| represented by debit entry
|
| If you feel uncomfortable seeing shareholders in the same
| category as creditors, consider that companies can choose
| two ways to fund themselves: equity (which creates
| shareholders) or debt (which creates creditors).
| rapht wrote:
| An income is something you owe to your shareholders. So if
| you think of what you own as (+) and what you owe as (-),
| which is how debut/credit is conventionally shortcut, an
| income is a negative number.
| redandblack wrote:
| 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.
| rahimnathwani wrote:
| > I prefer not to ascribe semantics to accounting
| credit/debit
|
| I think most people agree with you. They prefer to memorize
| some rules, or just look them up. Personally, I find having
| a simple principle helps me reason about new situations
| (new transaction types).
| wruza wrote:
| 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.
| jessaustin wrote:
| _...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 enlisting the marketing department who
| claimed to believe that velocity was a good thing, but I
| too failed. Eventually I realized that if we didn 't give
| them primary keys they would have to lay off multiple
| people whose only function was to look at primary keys.
| Instead I should have invested more effort in
| programmatically generating the database entries that drove
| this whole boondoggle.
|
| Not the first, and also not the last, place I worked where
| the CFO could have been the least honest person in the
| building.
| WorldMaker wrote:
| 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.)
| tepitoperrito wrote:
| I think (would love to know if I'm wrong) of it as: debit =>
| from, credit => to
| lhuser123 wrote:
| It depends. You really need the context.
| rahimnathwani wrote:
| I don't understand what you mean well enough. So you might
| be right or you might be wrong :)
|
| Can you share a couple of example (or maybe use the same
| examples I did)?
| fuckstick wrote:
| > Debits/credits concepts can exist (and we can operate on
| them) without the existence of left/right columns.
|
| Taking this as sympathetically as possible - which is tough -
| because do you really think the person you are replying to on
| this forum with the given response does not understand
| principles in the abstract?? This really is quite
| condescending.
|
| The entire point of a statement like this is that debit and
| credit are fundamentally abstract - such that when they have
| no essential features above their effect on the account.
|
| I mean did you bother to read the clarifying following
| sentence before you selectively quoted?
| tunesmith wrote:
| That seems uncharitable - the person you're replying to is
| saying that debit/credit are more than fundamentally
| abstract, and that they have conceptual meaning consistent
| across all accounts.
| rahimnathwani wrote:
| "they have conceptual meaning consistent across all
| accounts"
|
| I like this phrasing. I wish I had used it!
| onefuncman wrote:
| > conceptual meaning consistent across all accounts.
|
| Except programmers quite often get the conceptual meaning
| wrong and incorrectly generalize further. Credit and
| debit just mean increase or decrease in account balance.
| You cannot know how it affects liabilities or assets
| without knowing what type of account is being modified.
| EvanAnderson wrote:
| > > Without the context of the specific accounts being
| debited or credited the terms themselves mean nothing."
|
| > This seems incorrect to me.
|
| You can't derive the change in assests, liabilities, or
| equity without know which accounts are being debited and
| credited. The terms "debit" and "credit" themselves don't
| tell you anything by themselves. Without the context of
| accounts the terms are meaningless. I think programmers get
| hung-up on thinking that they have meaning in isolation (i.e.
| thinking that "a debit means somebody owes us 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.
|
| That's my point. When you know they type of account being
| debited or credited you can reason about how it affects the
| balance of the account and the managerial context of the
| transaction (i.e. "somebody owes us money because the debit
| was to a receivable account").
| rahimnathwani wrote:
| "When you know they type of account being debited or
| credited you can reason about how it affects the balance of
| the account and the managerial context of the transaction"
|
| This is true, but it doesn't negate my point (that debit
| and credit have meaning independent of the type of
| account).
|
| I know this because I have used the principle many times in
| practice, to define charts of accounts, to define rules for
| posting different types of transactions etc.
| EvanAnderson wrote:
| I think we're talking past each other but I'm not sure
| how to rectify.
|
| Given a debit of $500 and two matching credits of $250
| how is the owner's equity position affected?
|
| A programmer, unfamiliar with accounting, might think
| that "debit" and "credit" carry enough meaning in this
| context to answer the question.
|
| You and I know that without knowing what account types
| are being debited and credited we have no way of
| explaining what the managerial result of that entry is.
| That's an unanswerable question w/o more context. That's
| my point.
| rahimnathwani wrote:
| "I think we're talking past each other but I'm not sure
| how to rectify."
|
| Let me give it one last try :)
|
| You're claiming the truth of two propositions:
|
| A) Without the context of the specific accounts being
| debited or credited the terms [debit and credit]
| themselves mean nothing.
|
| B) Without the context of the specific accounts being
| debited or credited we have no way of explaining what the
| managerial result of that entry is.
|
| I agree with B, but do not agree with A.
|
| 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).
|
| The two statements above are true as written. If you were
| to exchange the capitalized text (turning CREDITED into
| DEBITED and vice versa), the statements would no longer
| be true. Therefore credit and debit each have some
| distinct meaning.
|
| [0] I treat 'shareholders equity' as being a liability in
| favour of shareholders
| onefuncman wrote:
| > 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
| increasing assets.
| rahimnathwani wrote:
| "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#:....
| jessaustin wrote:
| Your link shows that AR is a subaccount of Assets and AP
| is a subaccount of Liabilities, so credits to each have
| the opposite effect with respect to a balance sheet. GP
| has a different understanding of the "polarity" of debits
| and credits, but if anything this seems to support rather
| than undermine proposition "A" above?
| rahimnathwani wrote:
| "so credits to each do indeed have the opposite effect
| with respect to a balance sheet"
|
| I think what you mean here is that a debit balance in an
| asset account is presented as a positive amount, whereas
| a debit balance in a liability account would show as a
| negative amount.
|
| This is true, but that doesn't mean a credit has the
| opposite effect depending on whether it's applied to an
| asset or liability account. Consider that you have two
| different accounts with your bank:
|
| - a current account (usually the bank owes you money,
| i.e. usually a credit balance from the bank's POV)
|
| - a loan account (you bought a car on credit, and owe the
| bank money, i.e. a debit balance from bank's POV)
|
| For the bank, the current account is a liability ($1,000)
| and the loan account is an asset ($25,000).
|
| When you deliver a bag containing $5,000 to the bank, the
| bank will credit one of these two accounts. They'll
| either increase the current account to $6,000, or
| decrease the loan account to $19,000.
|
| In either case, the credit has the same effect: your net
| debt to the bank is decreased by $5k.
| jwarden wrote:
| 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
| CSMastermind wrote:
| I was lucky enough to work on a billing system early in my
| career and pick up some rudimentary knowledge of accounting. I
| can confirm that even being able to 'speak the language' a
| little bit provides immense value to you as a developer.
| Mezzie wrote:
| Also can confirm as an accountant's kid.
|
| It's kind of like being given a cheat code.
| datavirtue wrote:
| You just look silly trying to build financial software without
| understanding and implementing double-entry or ledgers. You
| have to know when to employ debit and credit nomenclature and
| be able to easily explain the reactions in the system...or you
| look silly. Sort of like when accountants start talking about
| databases and APIs without proper training.
|
| I have had to train developers on the simple concept of a
| ledger, which totally baffled them. It is event sourcing. You
| write, never update. If you want to offset a previous
| transaction you just record a new one. Want to know the account
| balance, just add up every amount within the range of entries
| you care about.
|
| Once they grasped that they were wanting to use the terms debit
| and credit in that context. Not cool. If you are tracking
| single accounts you only need negative and positive amounts. If
| the account/ledger is not offsetting another debit/credit there
| is no need to introduce that concept and complicate things. If
| you do, the finance team is going to wonder what other accounts
| you are offsetting. If the answer is none, brows wrinkle and
| confusion sets in.
|
| And ffs don't ever send them a spreadsheet or report with
| currency symbols in it. Major peave.
|
| Accountants have been using event sourcing (immutable ledgers)
| for hundreds of years. Powerful.
|
| Every complex finance problem I have run into in software dev
| was easily and elegantly solved with immutable records.
| 0xdeadbeefbabe wrote:
| What is super powerful about thinking of income as a credit
| account?
| marcosdumay wrote:
| Yep, you debit or credit an specific account, and to make
| things extra confusing, a debit on one account is always the
| same as a credit on a different account (and the other way
| around).
|
| Somehow transaction intermediaries made some incredible
| bullshity product differentiation out of those words... and
| what makes everything worse is that, since they are
| intermediaries, every transaction is both a debit and a credit
| on their own accounting.
| tantalor wrote:
| > debit is the entry in the left column, and a credit is an
| entry in the right column
|
| Problem with this is it's a convention. Accountants in
| Australia could do it the other way (credit on left) and it
| works just as well.
| kinleyd wrote:
| Sadly, I gave up accounting in high school after failing to
| reason through the meaning of 'credit' and 'debit' (Yes, I went
| in too deep!). My epiphany came in B-school when I tackled it
| again, when I finally figured out what your instructor
| summarized.
| bgro wrote:
| It gets really confusing when you talk about "in the red" or
| the black / red coloring and it depends on which side of the
| books you're on for what it means. I get this mixed up with
| electrical engineering every time now. I never feel comfortable
| jumping a car.
|
| "Red means positive, as in I'm positively sure you owe me a lot
| of money."
| kojim wrote:
| 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
| about crediting one account and debiting another.
|
| 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.
|
| If your app lets Alice sends Bob $5, we remove $5 from Alice's
| account and add $5 to Bob's account. So it seems fair to say
| that if both user accounts started at $0, Alice's balance is
| -$5, and Bob's balance is $5. Let's represent it that way in
| your DB.
|
| Your CFO would disagree. From your company's perspective, what
| these balances mean is that Alice owes you $5, and the company
| owes Bob $5. In other words, if the company went out of
| business tomorrow, you'd have to go out to collect $5 from
| Alice so that you could give Bob the $5 he rightfully thinks
| he's holding inside of your app. Wouldn't it be more logical to
| show Alice's balance as $5 and Bob's balance as -$5?
|
| It gets even more confusing if your software deals with
| financial instruments like loans, investments, or invoices.
| Dealing with every balance in your application as a simple
| positive or negative number gets really confusing, and will
| cause both ledgering issues and communication breakdowns
| between your eng and financial teams.
| yobbo wrote:
| > Because of this, instead of counting money as positive or
| negative amounts, it uses the debits and credits.
|
| That's not quite the point of double-entry. When one account
| is credited, at least one other account must be debited.
|
| All debits and credits sum to zero, but the accounts will
| have positive or negative balance.
| withinboredom wrote:
| Uh. No. When I refund someone I issue a negative credit on my
| account. It isn't a debit, strictly speaking.
| lelanthran wrote:
| > Accounting was invented before negative numbers.
|
| Counting was invented before negative numbers, but "double-
| entry accounting", which is what people refer to when they
| say debit and credit, was only invented in the 18th century,
| IIRC.
| [deleted]
| vlmutolo wrote:
| It likely originated in late 13th century Italy.
|
| https://en.m.wikipedia.org/wiki/Double-entry_bookkeeping
| wruza wrote:
| _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)".
| fluoridation wrote:
| >Wouldn't it be more logical to show Alice's balance as $5
| and Bob's balance as -$5?
|
| That wouldn't make sense. Alice sent Bob $5, so now Alice's
| balance would be $5 and Bob's would be -$5? The amounts
| should display their balances within the app, and Alice and
| Bob should have their own personal balances which are
| independent of the app's. Before the transaction, both Alice
| and Bob were at $0 on their personal balances and afterwards
| they were still at $0, since neither of them had more dollar
| bills on their persons. The _difference_ between their
| personal balances and their balances in the app is the value
| you 're alluding to. $0-(-$5) for Alice and $0-$5 for Bob.
| This difference could be interpreted as the amount that each
| owes to the app (positive for Alice because she owes and
| negative for Bob because he is owed).
| kojim wrote:
| 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.
| fluoridation wrote:
| >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.
| WorldMaker wrote:
| 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.
| quacked wrote:
| This little comment chain has done more for my
| understanding of accounting than at least 3 hours of
| reading online and trying to have my accounting friends
| explain it.
| jimnotgym wrote:
| > 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. For instance if I have a loan I put it in an
| account called 'loan', and list it on my balance sheet as a
| creditor. It will always have a negative balance. If it
| doesn't there is a problem.
|
| Alice from above owes me 5 bucks so goes in the debtors (or
| receivables account).
|
| I owe bob five bucks it goes into creditors (or payables)
|
| One classic piece of error checking is to review debtors for
| credit balances. It means someone has overpaid, needs a
| refund or screwed up posting it.
| whatshisface wrote:
| That's like choosing whether +x is a rightward or leftward
| facing coordinate axis. You can still use negative numbers,
| but you have to indicate whether positive means left or
| right. See also: positive and negative longitudes vs. east or
| west longitudes.
| kojim wrote:
| Oh completely. The "agreeing on what's left or right" in
| every context is the tough part, and already a solved
| problem with debits and credits.
| [deleted]
| potamic wrote:
| 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. and yet
| in my head I'm not able to envision the specific problem double
| entry can solve that single entry cannot.
|
| Somewhere in my head I feel a double entry system makes sense if
| you have two different parties making respective entry. But if
| it's all with a single party, single entry system should be
| equivalent to a double entry system. My accounting concepts are
| weak so I'm unable to justify. Hoping someone with more expertise
| can shed some light here.
| sbuttgereit wrote:
| I'm going to chime in on this. Note, however, I'm not an
| accountant/CPA/etc. and in that sense my take is my own; I have
| spent the majority of my career working with accountants
| implementing accounting systems so have some practical
| experience with the subject.
|
| As others have mentioned a basic double-entry accounting
| transaction includes two pieces of information: "where did the
| value come from" and "where did it go". This aspect of double
| entry book keeping I think is the less interesting one and
| you'd be right in not seeing any big deal as compared to single
| entry accounting... a check register style accounting with
| categories fits that definition pretty well. The debit/credit
| recording of double entry book keeping is really about the next
| point. Note that I used the word "value" because that value
| isn't necessarily cash, though value is always expressed in
| money terms.
|
| The next aspect, and the important aspect, is not the
| transaction but the accounting equation: Assets = Shareholder's
| Equity + Liabilities. This is where the formalisms of double
| entry accounting start to differentiate itself from single
| entry accounting. This equation expresses what it is we ("the
| company") own (assets) and who has a claim on it (shareholders
| and others we owe such as lenders). All of our accounts are
| assigned into one of these three categories and whether we
| debit or credit an account depends on this categorization
| relative to the accounting equation. So if I buy a hot dog for
| lunch with my bank card I'll credit my bank account (an asset
| account) which reduces it's value and debit an expense account
| which is a special kind of shareholder's equity account.
| Shareholder's equity = retained earnings from prior years +
| (current revenue - current expenses). When I book the expense
| debit the result is that shareholder's equity decreases. On the
| other hand if I use the same bank account to buy a house... I
| still credit the bank account (an asset account) but now I
| debit a real estate account (a different asset account) which
| reflects that I changed the form of the property I had (cash to
| real estate), but I didn't change the shareholder's equity
| position or the liability position (yes, there are fees and
| most people buy houses with borrowed money... but ignore that
| for this discussion).
|
| In the single entry world everything aside from the transaction
| itself is simply left to you to figure out. There really aren't
| additional formalities which guide you in getting a deeper
| understanding of the accounting data you generate. You could
| emulate this stuff, but typically something like Quicken isn't
| going to help you be sure your following these formalities. For
| many interested in personal accounting, not having these
| formalities is fine. But in business, the accounting equation
| and the many expansions of that equation tell you about the
| business is a way that is (should be) reasonably consistent
| from business to business. It's more than: "do I have enough in
| the bank for the next transaction", it's really about a clear
| statement of health and direction derived from the
| transactions.
| epgui wrote:
| Double entry bookkeeping simply represents flows of money as a
| directed graph, and that turns out to be a very useful thing.
| helixfelix wrote:
| This article [1] "Accounting for Computer Scientists" may help.
| Visualize money movement between Accounts / Nodes triggered by
| Transactions / Edges.
|
| This model is used to construct a "Fund flow" representation of
| how money should be moved. One of the essential concepts we use
| to verify that money is moving through the system is
| "Clearing", where we add up all of the edges and the balance
| should equal 0 - that is money reached its intended
| destination.
|
| [1] https://martin.kleppmann.com/2011/03/07/accounting-for-
| compu...
| jldugger wrote:
| > 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 applies
| equally to the books as a whole as it does to the individual
| transactions, so you can validate one by validating the other.
| So at data entry time, you can be relatively sure that you did
| the right thing because the transactions balance. And later,
| when your bank statements come in, you can easily reconcile
| because you have them broken out by account already -- and
| given the double entry system was already in balance, we know
| that any mistake you detect at this stage likely means a
| mistake in another account!
|
| It also serves to disambiguate certain transactions. One
| example would be a cash advance from a credit card. In a single
| entry system, I don't have sufficient metadata to determine
| whether that is income, or a liability that needs to be repaid.
| In a double entry accounting system, I can simply check the
| source of that credit and see "ah, this came from a liability
| account".
|
| If it helps, you can think of it as a complicated form of
| transaction tagging, with some mathematical constraints on the
| sum of tags in any transaction.
| tantalor wrote:
| Easy: double entry is append only database (immutable data). To
| compute account value you sum() over all transactions. Each
| transaction is required to sum to zero (credits=debits), so the
| sum over all transactions is also zero (balanced). You store
| the history of transactions.
|
| If you instead update account values in place (stored as sums)
| then you can't check your accounts are balanced (missing money
| bad)
| rthomas6 wrote:
| 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.
| tunesmith wrote:
| For those who use single-entry systems, if you've ever had to
| "split" a transaction into multiple categories, you're halfway
| to understanding double-entry. Especially if your "split" has
| both income and expense categories. For instance, if you want
| to accurate categorize your paycheck, some of the categories
| will be income like "gross salary", and some will be expense
| like FICA and tax. The trick is that all those amounts,
| positive and negative, need to add up to the net deposit that
| hit your bank account. Whereas in double-entry accounting, the
| combined debits and credits need to add up to zero.
| vineyardmike wrote:
| You may not need double entry if you're just tracking your
| personal checking account to see if you can pay your bill...
| but it still may help.
|
| You answered your own questions though. It's useful for error
| tracking and consistency. As a simple example to explain how it
| can help from a consistency perspective - think about a tool
| like Mint or Personal Capital or Nerd Wallet. They let you sign
| into your bank account and use a GUI to track all of your
| transactions. Ignore any privacy concerns. If you have 5 credit
| cards (because points), 2 checking accounts (you+spouse), a
| savings account, brokerage, mortgage, etc - there's a lot of
| room for money to jump between accounts. Now imagine that you
| don't include your mortgage account in the app. Whenever you
| pay money... it looks like your net worth is decreasing. In
| these apps, it might show up as a "purchase". But you're
| actually getting richer (by paying off debt and gaining house
| equity). If you include the mortgage account, you get to bring
| "the other side" into scope - boom - you now have an accurate
| view of the world when you didn't before. That's kinda sorta
| ish comparable the value of double entry. One side doesn't tell
| the whole story, but always tracking both sides does.
|
| Of course, the error-correcting part comes when there was a
| mistake or a correction that needs to be added. (Mortgage
| lended says balance is wrong?Here's the sum of all transaction
| from checking acct to mortgage!). If double entry, both sides
| of a single tx have to match, and you don't track the balance,
| you derive the balance from the sum of all transactions. So you
| theoretically can't get a case where one ledger (eg mortgage)
| doesn't match the other (eg checking). Helps a lot more when
| you're a multinational bank with $1T and 50 million customer
| accounts.
|
| Another example is a cash registers in stores. There's a much
| higher chance the balance of cash is wrong (more room for human
| error). Being able to compute the balance over time based on
| the transaction history is useful for determining register 5
| keeps losing money. _Every change in cash balance should match
| another transaction so the total value of business's money
| doesn't change_. Or just confirming that once you bring the
| cash to the bank there will be enough balance to pay a loan.
|
| Does this directly impact you on a day to day basis? Maybe no.
| But I hope that's a super simple illustration of why it's
| conceptually useful and what "error tracking and consistency"
| means.
| Mister_Snuggles wrote:
| Double-entry is kind of a bad name, but the concept is sound.
|
| I like think of each entry as the complete journal entry - a
| set of debits (abbreviated DR) and credits (abbreviated CR)
| that describe an event. Debits and credits are, as many
| accounting instructors have taught many students, names that
| effectively mean "Left Side" and "Right Side". Some accounting
| systems represent debits as positive numbers and credits as
| negative numbers - this is perfectly valid too.
|
| Say somebody purchases a product for $60 and a service for $40
| from me. The product that I sold cost me $40 to purchase, and
| both the product and service have a 5% sales tax applied. This
| is a very common transaction - car repairs, for example, are
| usually a combination of products (e.g., oil, oil filter) and
| services (e.g., oil change and inspection).
| Account DR CR Cash in bank
| 105 Tax Payable 5 Sales
| Revenue 60 Services Revenue
| 40 Cost of Goods Sold 40 Inventory
| 40
|
| In this example, I collected $105 in cash from my customer
| which will go into my bank account. Because of this sale, I now
| owe the relevant tax agency $5 because I collected sales tax on
| their behalf. I recognized sales revenue of $60 and services
| revenue of $40. Since I sold some physical goods that I had in
| inventory, I also reduced the value of my inventory by the cost
| of what I sold.
|
| This is, in my mind, one "entry" which has six detail lines to
| recognize all of the different things that need to be recorded
| for this event. The important point is that everything
| balances, credits always equal debits.
|
| Some businesses might not do the Cost of Goods Sold / Inventory
| entries with each transaction, instead they might count their
| inventory once a month and calculate out how much they sold
| (inventory at start + inventory purchased - inventory at end =
| cost of goods sold) and just do one entry a month to get the
| books in sync with reality.
| projektfu wrote:
| "Single-entry accounting" usually means that you have one
| account that is the source of truth for the whole operation.
| For example, you use the checking account balance. When you
| take in sales, you put it in the sales column and increase the
| balance. When you pay the electric bill you put it in the
| electric column and decrease the balance. You have a couple
| issues:
|
| 1. How do you keep track of unpaid invoices and bills?
|
| 2. How do you account for things like asset values,
| depreciation, etc.?
|
| 3. If you have income or expenses that register multiple
| accounts, you have to sum the right columns.
|
| 4. If you missed a leg of a complicated transaction (recording
| the income and sales tax liability for the day across multiple
| payment forms, for example), you might never know it, e.g., you
| might accidentally record the sales tax payable as income.
|
| Using the accrual accounting method (as opposed to the cash
| method), where you book sales at the time they occur, is next
| to impossible with single-entry accounting. If you have a
| mostly inventory-based business, you have to use the accrual
| method in the US. Most businesses that must make financial
| statements available to investors will use the accrual method.
| vishnugupta wrote:
| > But if it's all with a single party
|
| If you dig in deeper you'll see that there's never a single
| party. Money always moves from someone to someone else. So even
| if it's a single party the money is moving from marketing
| department to customer acquisition. Let's say you are giving
| customer 10$ signup bonus. That money has to come from
| somewhere and has to be accounted for.
|
| One just can't create or destroy money. And the best way to
| ensure that is double entry accounts.
| svat wrote:
| 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 / decreases. That's single-entry. When you
| withdraw cash from your account at an ATM, your bank balance
| decreases, and when you buy something with cash your balance
| doesn't change -- this is probably not what you want. With
| double-entry bookkeeping, you track separate "accounts" for
| (say) "bank account", "cash" and "outside world", and every
| transaction is an _edge_ in this graph (or in general,
| hyperedge in hypergraph). (E.g. withdrawing $100 cash means a
| transaction that is -$100 on "bank account", and +$100 on your
| "cash" account, which add up to 0.)
|
| * Similarly, with your bank account and credit-card account,
| when you pay your credit-card bill it's a transaction between
| your bank account and credit-card account, and when you buy
| something with your credit card it's a transaction between your
| credit-card account and the "outside world" account (which you
| can break down more granularly if you want to track your
| expenses).
|
| Summary: double-entry bookkeeping means that instead of
| entering "this balance decreased" or "this balance increased"
| (without a direct way of linking where the money came from or
| went), you enter _transactions_ that track all the changes as
| one unit, and in each transaction the sum of the "postings" is
| 0.
|
| Or just read this by Martin Blais, it's still the best:
| https://beancount.github.io/docs/the_double_entry_counting_m...
| simonw wrote:
| This is such a clear explanation of double entry accounting,
| thanks for this.
| alain94040 wrote:
| 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?
| rr888 wrote:
| 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.
| meekaaku wrote:
| > 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
| chucktingle wrote:
| If you are interested in error-preventing and tamper-proof fund
| tracking systems, have a look at the UTXO model. Bitcoin and
| many cryptocurrencies use it, but the actual model predates
| Bitcoin.
|
| https://en.wikipedia.org/wiki/Unspent_transaction_output
| 1autodev wrote:
| Here's a free university textbook on Accounting if you'd like
| to dabble a bit :)
|
| https://principlesofaccounting.com/
| EvanAnderson wrote:
| Quite simply each entry contains both the "to" and "from" for
| the transaction. It's a construct to guarantee atomicity. The
| two "sides" of the transaction can never be out of balance with
| each other. If you lose an entire entry the system remains in
| balance-- you've lost a transaction but you're not in a
| situation wondering "where the money went" because nothing
| moves without both sides of the transaction.
| svat wrote:
| There's another very nice description, with useful pictures, by
| Martin Blais (as part of the documentation of Beancount) at
| https://beancount.github.io/docs/the_double_entry_counting_m...
| (example picture that I would say is the heart of the idea:
| https://beancount.github.io/docs/the_double_entry_counting_m... )
|
| Another one, with completely different graphs, is by Martin
| Kleppman at https://martin.kleppmann.com/2011/03/07/accounting-
| for-compu... -- despite the name ("Accounting for Computer
| Scientists"), on reflection / trying it out, I find it less
| useful than the Beancount one.
|
| (Both of these are actually linked in the second paragraph of the
| posted article, but they're independently worth mentioning /
| good.)
| umrashrf wrote:
| If you are in Canada, you might find this helpful
| https://www.youtube.com/watch?v=WV-vNltqasA
| biznickman wrote:
| I cannot upvote this enough. I worked at a fintech company that
| was vehemently opposed to using double entry accounting and it
| created an incredible amount of inefficiencies and massive errors
| and expenses at the company. If you are dealing with money in any
| system and tracking it in a database, double-entry accounting is
| not an option.
| mguerville wrote:
| Great article by a company that's honestly been great to work
| with, I think it's interesting that they write such an entry
| level piece when their solution is enterprise grade but it shows
| their dedication to educating not just the users and stakeholders
| of the end product but also the implementers, which very few
| software companies do.
| cupachabra wrote:
| Ok this is an interesting post but I as understand it, its more
| like "what can go wrong when developing accounting software" and
| not that developers need a special type of accountant?
| wholien wrote:
| Yes this post is about developing accounting or other kinds of
| software that tracks money (from the subtitle: "... we walk
| through basic accounting principles for anyone building
| products that move and track money").
|
| One can treat it as a primer on double-entry accounting as
| well.
| zdw wrote:
| 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
| dugmartin wrote:
| More info here on other like-minded systems like hledger and
| Beancount: https://plaintextaccounting.org/
| fabianhjr wrote:
| I have tried several (like https://hledger.org/ ) but would
| prefer some REA/ValueFlows accounting software.
| NoboruWataya wrote:
| Also GnuCash, which I feel requires no elaboration on HN as it
| is so frequently its own topic of discussion.
| rthomas6 wrote:
| 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.
| retetr wrote:
| Can someone explain. From their definition it looks like the
| credits and debits column in their example transaction table is
| flipped e.g. the first "debit" to the cash (debit normal) account
| increases the value, while the "credit" to the equity (credit
| normal) account also increases the value. (edited for spelling)
| projektfu wrote:
| See my other comment here:
| https://news.ycombinator.com/item?id=32499123
| HatchedLake721 wrote:
| I had a pleasure to dive deep into this topic and we built a
| double-entry bookkeeping system from scratch in a heavily
| regulated industry that tracked debt consolidation for thousands
| of customers with payouts to thousands of creditors.
|
| I think this is one of the most proudest things I was ever was
| involved in architecting, designing and building. I left before
| it got to prod, but from people still there, I've been told it's
| been working flawlessly!
___________________________________________________________________
(page generated 2022-08-17 23:00 UTC)