How should I handle charges which are one sum when they are pulled from my bank account, but then later change?

Question

1. I order groceries including some bananas.
2. The store charges my bank account with $150, which shows up as -$150 in my bank account.
3. Some days pass and the delivery takes place. I don't get any bananas in spite of having paid for them.
4. The charge in my bank account changes into -$145, because they at least spotted the lack of bananas and noted this in their system.
5. Now the single transaction as "settled". They don't make a "real" transaction and then another one to give me back those $5 worth of bananas.

If I had manually entered -$150 into my own "bookkeeping" (in lack of a better word) database table, then how do I handle the fact that it's no longer -$150, but -$145?

Do I:

1. Actually modify the existing record after it's been entered?
2. Add a new record called "Adjustment for previous food order" which is +$5? I'm worried that it may be misleading/problematic as it looks like I've gained $5 somehow, when that's not really the case.
3. Wait until the entire thing has "settled" until I actually enter it into my bookkeeping? That also seems misleading and problematic in many ways.

All three ways seem fundamentally flawed to me. What's the recommended practice for this? Why must they use such a "fluid" and "volatile" method for transactions where they can be "reserved" and "settled"?

Also, "my" bank is extremely non-helpful in terms of providing zero "identifier" of any kind, even when downloading the data as CSV. All I have is the description, amount and date (not even time). So it's going to be very difficult to automate this somehow, such as simply using an identifier for the "transaction" which is the same for both the initial charge and the "reverse charge" (which to me shows up as the same unit which just has an updated amount).

Answer 1

You could mark the original transaction as voided, and then add the replacement correct transaction. This presumes your bookkeeping system supports the concept of voiding an entry (or that you could extend it to.)

This way, you keep some record of the incorrect transaction — but without any impact on your account balance — as well as the correct transaction, which is the "live" one that does impact your account balance. You don't need to calculate any compensating amounts, etc. which may not reflect actual transaction amounts.