This sounds like something I'd be interested in learning more about. Do you have a couple examples of said data reconciliation issues, and the corresponding accounting approaches?
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).
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.
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.
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.
Not the OP. But in my experience, a lot of people do not know about double entry bookkeeping, which solves a lot of problems people have trying a home made excel bookkeeping. It is not more work to do, but you have to learn a little bit about the concepts. Once you know them, it seems incomprehensible that others make errors that have been solved hundreds of years ago.