[joshstrange]

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.

[Naga]

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]

> 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]

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.

[projektfu]

91.67

[hundt]

As the article explains, debits increase the balance of debit normal accounts, whereas credits increase the balance of credit normal accounts.

[cperciva]

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]

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]

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.

[mytailorisrich]

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]

To be a bit more specific: Assets = Liabilities + Equity

[mikeyouse]

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).

[realityking]

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]

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.

[remram]

This is a double-entry system. You are already doing it. Every transaction decreases an account and increases another.

[neffy]

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.

[mathgeek]

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...

[yobbo]

> 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.

[drc500free]

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.

[mmcdermott]

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.

[jwsteigerwalt]

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]

The blockchain is basically triple-entry accounting. Every transaction has a public record to go along with your own two column entry.

[rr888]

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