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