Simply put if you make a mistake you don't correct it with tipex but with another entry to adjust the mistake. This means all mistakes are accounted for and balanced back to normality.
Also worth noting that banks love to process debits before they process credits so you could have 100 units of money in yoru account with another 200 going in and 200 going out. You will then see that on your statment that they have the 100 then the -200 and then the +200, so indicating that you are -100 for a period, evil are they not.
I've had this happen to me, and a few years ago I happened to work for a short time with someone who had formerly been the president of a small regional bank. He confirmed that some banks do intentionally do that, and that many of the banking software systems had configuration options to decide what order to process data (debits or credits first) and that banks looking to make more money could just flip that switch and start raking in more fees.
It's really annoying to have people say that it doesn't happen when a) I've had it happen to me and b) I've had it confirmed by a banking executive.
Opening Balance: 100
Withdraw 50 --> 50
Deposit 200 --> 250
Withdraw 150 --> 100
Opening Balance: 100
Subtract sum of Withdrawals: 200 --> -100
Subtract penalties: 50 --> -150
Add sum of Deposits: 200 --> 50I'm no longer a KeyBank customer (in between that and them cancelling my card for a $1 Roku pre-auth charge as 'suspicious' - but not notifying me, calling, etc, just popping a letter in the mail which arrived three days after I discovered for myself it was cancelled), unsurprisingly, as they refused to budge on waiving the fees (except for one - "you get one courtesy fee waiver per calendar year". The mind boggles).
I believe this resulted in class action law suits, and regulations preventing this behavior, but I can't find any news article about it at the moment.
Worth noting that is not the case in countries != America, and is in fact illegal in many countries.
I read about another case in australia where an ATM was issuing $50 notes in place of $20 notes so once word got out a ton of people turned up to withdraw $80 - it came out as 4 x $50s = $200 ... but they were also asked to pay it back to the bank...
http://www.couriermail.com.au/news/commonwealth-bank-atm-dis...
I really don't know what they expected to get from this to be honest: I mean, I'm pretty sure when you open the account you recognise somewhere, somehow, that if you overdraw your account it's your responsibility to pay it back...
Also according to a ISO standard on magnetic cards with used by banks - track 4 as will have stored the last amount taken out. So even if you have say 1000 units of money in your account and take it all out and then try to take it out again, the cashpoint (even in batch mode) will know. Now if you cloned your own card prior to the transaction and then used that clone, you may or may not be able to withdraw that money again - but would also have to use a different ATM is the one you just used will have a record itself.
Bottom line you can defraud banks out of there money, but it involves breaking the law like any other form of imoral gains. Only true way to rob a bank is to be another bank somebody once said, may very well be the thruest and with that sadly the only way legaly.
That's how I prefer to design my schemas as well. Meaning answers are determined during query vs during load. If I see an UPDATE statement, I assume it's a bad design.
I don't have a firm line on the etymology, but it seems to me that what we computer science types call a transaction is so called because of the accounting concept of a transaction.
In book entry you must always enter two items: a credit and a debit. Always. Before you make the transaction, the books are supposed to be consistent. And after, they are consistent.
One thing accountants do differently is that there are no deletes. You may only update. There are specialised transactions for correcting errors. Again: even if an error has been made, the erroneous state is still consistent before and after an erroneous transaction. And it is consistent before and after the correcting transaction.