Hacker News Reader

Comment by wolfgang42 | Hacker News Reader

In addition to error checking, the process of double-entry bookkeeping also provides a way to get different views into the state of a business: balance sheets, P&L statements, transaction histories, and so on. A lot of the mechanics of doing it manually—journals, ledgers, day books, trial balances, etc.—are less important now that computers can slice-and-dice at the push of a button, but the fundamental idea of a business transaction as a set of balanced money movements between different accounts is still a useful way to structure financial data.

(“Double entry” is also something of a misnomer; it’s really “N-entry” accounting, where all N entries that make up a transaction have to balance out to make sure you know where the money came from and where it went to. It’s just that for simple transactions the minimum number of entries that makes sense is 2.)

View on HN

> “N-entry” accounting

it's called double entry bookkeeping because each value (each number) gets entered in two places, once as a debit, and once as a credit.

Yes, but in practice split transactions are common, where you will have 1 credit and 2 debit entries in a transaction. For example, if you work from home and pay rent out of one account, the you may want to claim back tax on the office portion of your rent:

1. Credit $1000 Cash account,

2. Debit $600 Personal Rent account and

3. Debit £400 Office Rent account, considered a tax-deductible Expense account.

Sum of credits = Sum of debits, but now you can account for different tax treatments.

That’s two credit entries in the cash account: one for 600$ and one for 400$.

The fact that you have an equal amounts of entries in debit and credit accounts is literally the point of double entry bookkeeping. If you could use consolidated entry, it would be a nightmare to cross check when you are looking for errors. If you were using a ledger rather than a piece of software, it would be so much more obvious.

I disagree with this. This might be fair and technically correct on paper, but we don't use paper anymore. Transactions with more than two line items are by far the most common method of recording transactions. In fact, I'd probably go so far as to say that the method you suggest isn't used at all in practice, especially since most transactions need some sort of recording of sales tax.

In the example of $1000 paid in rent, the technically correct method is actually worse for usability. If $1000 left the bank account and two transactions totalling $1000 were recording, how can you match the ledger to the bank account? Or if there are bank charges paid on a transaction (Paid $1000 with $5 in bank charges).

> If $1000 left the bank account and two transactions totalling $1000 were recording, how can you match the ledger to the bank account?

The ledger already matches the bank account. You have 1000$ leaving it in two lines. Charges will likely be accounted separately anyway if they exist.

You probably mean the bank statement. If that’s the case, the answer is you do what is called reconciliation and sum the accounting entries. Reconciliation will be more complicated anyway because you will have entries in your accounting for a month which might be on a different bank statement entirely due to outstanding checks and deposits and bank processing delays.

I did mean bank statement, thank you.

I'm aware of how reconciliation works. I'm actually an accountant by trade. $1000 is a trivial transaction of course, but reconciliation becomes challenging when its thousands of transactions per month of differing amounts. If anything, transactions not matching the bank statement is a good way of increasing your audit fees as the auditor struggles to make sense of what your accounting system has recorded.

> I disagree with this. This might be fair and technically correct on paper, but we don't use paper anymore.

here's a simple case you may have encountered yourself: you order a shopping cart of a fair amount of stuff (not even that much) from Amazon, and click purchase. Later you're wondering about an Amazon charge on your credit card so you look in your emails from Amazon and you log into your account on Amazon, and you can't match the charges on your card with any of your shopping transactions with Amazon, the numbers bear no resemblance to one another. Amazon is not bookkeeping in a way that's at all useful to you. Since you are the consumer of the data, they're not fulfilling their accounting obligation which is clear presentation of the record.

I have no doubt that their calculations are correct, but just as computers can free us from the burden of adding up numbers correctly, computers can also do other tasks we find burdensome, like double entry bookkeeping. When as a programmer I used to resist writing code that seemed inelegant, my old boss used to remind me that the computer was the drudge, a mere servant to the whims of the various humans using it. If Amazon wants to rejigger your shopping carts with respect to backorders and shipping, they could easily do it in a way that allowed you to reconcile your statements simply.

It depends on what you count as a "transaction". Some of my real transactions get recorded as multiple "virtual" transactions on the books, to make sure the money has visited all the relevant places for later summary purposes.

Example: I buy something with my salary. Two real transactions. However, on the books it goes in as income, it is moved to the household income, it goes into the cash reserve, then moves through the appropriate budget category before the actual expenditure is recorded as it happens.

This is indeed the right answer. I sometimes try to use simpler accounting mechanics than double entry (usually because the person I'm doing it for requests it) but it doesn't take long until I want to run a query against the data that becomes complicated under simpler systems but just falls out of the data under double entry.

Reply on news.ycombinator.com