How to properly organize balances and personal accounts in the system?

Question

Database design

I am developing an internal product, something like a ticket system. The question arose about the implementation of the system of personal accounts of clients. I couldn’t really find any complete information, so I figured out the following logic from scraps:
There are tables (the most basic structures are described)
company - the company itself (id | name)
payments - company payments, in fact revenues (id | company_id | amount | timestamp)
write_offs - write-offs from a set of companies, in fact expenses (id | company_id | user_id | ticket_id | amount | timestamp)
company_balances - table of company balances (id | company_id | balance | action | action_id | checksum | timestamp)
The last table is needed in order not to calculate the entire history every time a check is required.
The latest entry in the company_balances table for a particular company_id is considered current . Every time an accrual or write-off is made, the system looks at the current balance and calculates the salted hash based on the data in the action ( payment or write_ofs ) and action_id (id in the corresponding table specified in action ) fields ( company_balances table ) and compares with the existing value checksumin the same table. If the result matches, then the operation can be performed, if not, then the balance has been changed bypassing the algorithm (for example, through PMA) and such an account is blocked, the administrator is notified and the reasons are already being clarified, while let it be in manual mode by the administrator / authorized employee.
When an operation is allowed, a new balance and its checksum are calculated, an entry is made in the corresponding operation table and in the balance table. All this in transactions and with locks of the corresponding tables by itself.
Actually, the question is how true such an algorithm is, whether it is safe and how it can be simplified (not to the detriment of security) or improved (to increase security, but not to the detriment of performance). There was also an idea to make the current checksum dependent on the previous one, for example, use it as part of the salt when calculating a new amount, but I'm not sure about the need for this step yet.
Now a similar system has been implemented, but the balance is calculated from income / expenses that are stored in one table in one column, which is very long with a huge amount of data. Well, and accordingly, when accessing the database, any balance in any period is easily corrected, which is not permissible.
If there are articles / books on this topic, not abstract, but with examples of algorithms and a description of the reasons for certain decisions, I would be extremely grateful. Thank you!

Answer 1

Well, if we add shipments (sales) and receipts of goods and materials, then it actually turns out that the balance is calculated from the sums of all payments / shipments. Well, sometimes you may need some helper in the form of a ready-made value so that you don’t summarize each time.
p / s / perhaps it will sound more like "balance"

Answer 2

Calculate balance totals once a week (once a day, once a month) and save to a balance sheet.
And the current (for the last day, week, month, that is, those after the record is entered in the balance sheet) income-expenses, nevertheless, should be counted every time.
Thus:
current balance = balance for the previous period + a small amount of income-expenses that after the "previous period" are made.
It is convenient because you can always perform a full recalculation of the balance (by choosing idle time like the server).
Resetting the balance (in the summary table) in case of manual editing can be done in the trigger.
Thus, with manual editing, you just have to recalculate the totals.
In the same place, in the trigger, you can prohibit changing income-expenses for already calculated periods.
Your option "block until showdown" also has its advantages, but it means waiting for these "before showdown", maybe a couple of days. And the client needs to work.