[kdmtctl]

An account could be only on one side. The side and chapter is the meaning of this account. Account on the left just negates the increase/decrease direction.

In a bank ledger when a loan appears on a checking account, both increased. Loan on the left, checking on the right. DT Loan → CT Checking. Loan is an asset for a bank, Clients money is a liability.

On a client's balance sheet everything is mirrored. Checking is an asset, Loan is a liability.

Queries are quite simple. Volumes are problematic. In a big institution you would find several ledgers included in the general ledger by totals. You just don't need all the details in one place.

[bvrmn]

As I understand parent comment it assumes following transaction records: (source_account, dest_account, amount). I argue it complicates things.

You talk more about how to make db data simultaneously a representation of final reports. I believe it's not related to this thread.

[kdmtctl]

You’re right. Missed it while scrolling. Regarding the parent discussion, a classic statement is also two-sided. So, you need to collect sources (debit) and destinations (credit).

It is definitely possible to make each side of transaction a different record, but you have to link them, so there would be another ID for a transaction to group later. It is always there in any case, but you are either joining while getting a balance or grouping while reconstructing transactions for reports. So, it depends on the primary load: lots of transactions to register or lots of reports to provide. Both are used.