[jimnotgym]

An easy example. In a well designed database that represents an accounting ledger, debits are positive numbers credits are negative. With double entry accounting, if everything is correct the entire ledger sums to zero at all times. It is trivial therefore to know if an error crept in to your system, maybe something posted only half the entry before erroring (btw always post a complete double entry inside a database transaction).

[dugmartin]

You can also design your schema using unified ledger accounting (https://en.wikipedia.org/wiki/Unified_ledger_accounting) which captures both the transaction's debit and credit in a single row in a single table negating the need for a transaction.

[jimnotgym]

The problem comes with trying to quickly find the balance of sub-accounts. It is common to need to find the balance of all of the general ledger accounts repeatedly and quickly when preparing accounts, or having to find all customer balances to see who has paid. Once you have 10m rows of data (easily done at an sme) this gets very slow indeed. It is common to have a second table that records running balances or balances at period ends to speed this up. This is why transactions are important or you find the individual accounts of the sales ledger control don't add up to the total. Some systems have an 'audit' tool that adds them all back up from the general ledger.

[cheradenine_uk]

If you're interested, you can always check out the code to GNUcash;

IIRC it has a SQL Schema that can be imported into most databases.

https://wiki.gnucash.org/wiki/SQL

[augiemagic]

Ah that makes sense. Thanks!