3 ms·
There exists cases where it is problematic, but your example is fine. In this case, you would use individual transaction lines to represent payments, rather tha
by yobbo 4y ago
There exists cases where it is problematic, but your example is fine. In this case, you would use individual transaction lines to represent payments, rather than sales, which is closer to reality. But you can group transactions in any way you want.
With sales tax, you would have:
cr: sales, dr: cash, $100
cr: cash, dr: tax, $10
- meekaaku 4y agoThe above looks like $70 was taken from cash and deposited to bank. Thats not whats happening in the real world. Since cash is fungible, one could ignore that. But if it was cheque + bank-transfer or something else that leaves a record, then that wont work. Or when you include VAT/GST/Sales tax. Or when you pay a loan monthly payment of $1000 that needs to be split to principal and interest. etc.
- yobbo 4y agoYes, it is best if transactions correspond to verifiable events. Complicated situations can be modelled by letting events be represented by their own "accounts", in a separate charter. In your example, you might let the monthly payment be represented by its own account, with three transactions (bank payment, interest, principal). The purpose is to make the database constraints enforce double entry verification. If you don't need this, it can be made simpler as you suggest.