3 ms·

The problem is that this breaks down when faced with problems more complex than simple examples. What about cases where there are multiple "to" accounts? For

The problem is that this breaks down when faced with problems more complex than simple examples. What about cases where there are multiple "to" accounts? For example, you might go to Best Buy and purchase a computer and a video game. In this case, the "to" would be split between two separate accounts (assuming you do your books this way). This is a contrived example, but in the business world this type of transaction is very common. An example involving selling a taxable service (think of a haircut) might look like: Debit Cash Credit Service Income Credit Sales Tax Payable (this is remitted to the government)

captainmuon 8y ago
I don't know if it is implemented in this tool, but there is no reason that you could not have multiple "to" fields in a transaction. In double bookkeeping, you must have balanced books, but you do not note which bookings occur together. The transactional scheme seems strictly superior because you automatically know which debits and credits or losses and gains go together. You automatically have balanced books. I think you sould be able to even generate double bookkeeping from transactional bookkeeping automatically.
- Mister_Snuggles 8y ago
  The data model is somewhat secondary to the accounting model, however the data model has to be rich enough to support the accounting model. In the traditional accounting model you have two major things: 1. The Ledger, which is the current state of your accounts. Generally each account is a page (or more) in the ledger which lists the debits and credits for that account. 2. The Journal Entries, which are the source documents that feed into the Ledger. Each Journal Entry groups all of the related debits and credits into one balanced entry. Since each Journal Entry is balanced, the Ledger ends up balanced. Some software packages follow the accounting model very closely in their data model, others make some different choices. Some software, usually professional software, has a Ledger of accounts and uses Journal Entries to record activity in those accounts and requires that you run a process to post the journal entries. Professional software typically has modules for sales, purchasing, etc, that create the Journal Entries for you. Other software "fakes" some or all of the Ledger (typically the Asset/Liability accounts are in the Ledger and the Income/Expense accounts are "fake"), this type of software is usually aimed at home users. In both cases, all entries are done as a balanced journal entry with multiple lines. Back to the accounting model: A sale involving VAT, for example, might look like this in Journal Entry form: 2018-06-06 Sold a haircut and shampoo to Bob Cash DR $21.00 Haircut Sales CR $10.00 Product Sales CR $10.00 VAT Collected CR $1.00 Cost of Goods Sold DR $8.00 Inventory On Hand CR $8.00 The first line is basically the header and it groups all of the entries related to that one sale. In this case, a customer paid cash for a product and a service. Because they bought a product, we also reduced the value of the inventory that we have on hand. And, because I'm in Canada, both of these items are eligible for VAT, so I had to record how much VAT I collected on behalf of the Government - I'll need these records later when it's time to pay up. You can't really support that kind of entry if your data model has only one From field and only one To field - you've be creating five entries that aren't tied together. To support this, your data model needs to let you create one entry with multiple From and To fields. Once you get to this point, you're at the journal entry model that real accounting software uses.
  - captainmuon 8y ago
    Thanks for your very clear answer! My point was basically, most or all of the interesting information is stored in the journal. You could hide the legder from a non-technical user, or even generate it on-the-fly. I think this is the distinguishing idea in OP's program. That the data model has only one "from" and one "to" field is incidential and could be fixed.

captainmuon 8y ago

I don't know if it is implemented in this tool, but there is no reason that you could not have multiple "to" fields in a transaction. In double bookkeeping, you must have balanced books, but you do not note which bookings occur together. The transactional scheme seems strictly superior because you automatically know which debits and credits or losses and gains go together. You automatically have balanced books. I think you sould be able to even generate double bookkeeping from transactional bookkeeping automatically.

Mister_Snuggles 8y ago
The data model is somewhat secondary to the accounting model, however the data model has to be rich enough to support the accounting model. In the traditional accounting model you have two major things: 1. The Ledger, which is the current state of your accounts. Generally each account is a page (or more) in the ledger which lists the debits and credits for that account. 2. The Journal Entries, which are the source documents that feed into the Ledger. Each Journal Entry groups all of the related debits and credits into one balanced entry. Since each Journal Entry is balanced, the Ledger ends up balanced. Some software packages follow the accounting model very closely in their data model, others make some different choices. Some software, usually professional software, has a Ledger of accounts and uses Journal Entries to record activity in those accounts and requires that you run a process to post the journal entries. Professional software typically has modules for sales, purchasing, etc, that create the Journal Entries for you. Other software "fakes" some or all of the Ledger (typically the Asset/Liability accounts are in the Ledger and the Income/Expense accounts are "fake"), this type of software is usually aimed at home users. In both cases, all entries are done as a balanced journal entry with multiple lines. Back to the accounting model: A sale involving VAT, for example, might look like this in Journal Entry form: 2018-06-06 Sold a haircut and shampoo to Bob Cash DR $21.00 Haircut Sales CR $10.00 Product Sales CR $10.00 VAT Collected CR $1.00 Cost of Goods Sold DR $8.00 Inventory On Hand CR $8.00 The first line is basically the header and it groups all of the entries related to that one sale. In this case, a customer paid cash for a product and a service. Because they bought a product, we also reduced the value of the inventory that we have on hand. And, because I'm in Canada, both of these items are eligible for VAT, so I had to record how much VAT I collected on behalf of the Government - I'll need these records later when it's time to pay up. You can't really support that kind of entry if your data model has only one From field and only one To field - you've be creating five entries that aren't tied together. To support this, your data model needs to let you create one entry with multiple From and To fields. Once you get to this point, you're at the journal entry model that real accounting software uses.
- captainmuon 8y ago
  Thanks for your very clear answer! My point was basically, most or all of the interesting information is stored in the journal. You could hide the legder from a non-technical user, or even generate it on-the-fly. I think this is the distinguishing idea in OP's program. That the data model has only one "from" and one "to" field is incidential and could be fixed.