Item — HN Reader

Transity isn't a single entry system. By using transactions to model financial flows it implicitly enforces that the amount is credited to the "from" account and debited to the "to" account. Therefore it's basically double entry by design.

I'm really interested if someone can show me a use case where this system is less powerful / safe than a classic double entry system.

2 comments

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)

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.

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.

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.

What you've described is literally not double-entry. Double-entry is based on the concepts of two accounts being modified by a related set of similarly-sized transactions (i.e., the credit and debit actions). The idea is that you can separately replay the sets of transactions for each account and at the end they reconcile (i.e., balance) because the accounts are modified separately.

You've presented a system in which one transaction modifies 2 accounts. If there's an error in the code, you've got no way of knowing it without manually checking the calculations by hand.

Not only that, you lose the ability to modify three accounts in a single transaction.

How do you handle recording sales taxes? In Canada, for a business, every transaction will require splitting the tax component into a separate account so that it can be fed into the quarterly GST return. This happens both on the sales side, where you record the taxes you collected, and on the purchases side, where you record the taxes you paid to your suppliers.