How should I deal with how the bank/VISA/companies deal with "flexible" charges?

Question

After my bank made it impossible to auto-fetch any data, requiring an extremely tedious and manual process each time I need to log in to their website, I was forced to give up my "automated bookkeeping" system which I had programmed. Instead, I started keeping a manual or semi-automated bookkeeping local system. For example, any time I make a transaction, I manually enter it. For the recurring food deliveries, I parse their e-mails/PDF receipts, so those are basically automated.

Every three months, sometimes more often, I perform the chore to log in to the bank and download the CSV data for the last three months. Then I feed it into my custom script which goes through the items one by one and checks if they exist in my bookkeeping system and if they match. If not, it checks if there are similar amounts with similar dates, and ask me interactively for all possible "candidates". This is an annoying but necessary process to keep things accurate.

My biggest issue is that the charges on the account seem very "flexible". I don't know when they started doing this. Maybe it's been done for decades. Either way, the charges are not "final" or "set in stone" until what seems like several weeks. For example:

1. I order and pay for groceries to be delivered on 2022-01-01, for $123 USD.
2. The food is delivered at 2022-01-05, and they have changed the amount to $120. My system handles this.
3. When I finally log in to my bank account and check, the "reservation" and "final" charges often have completely different dates from when they actually happened. They may now be saying 2022-01-03 and 2022-01-15 or something like that.

Should I be updating the dates in my bookkeeping system to match those from the bank's CSV data? Technically, they are lies, since I did not order the food on the 3rd of January and it was not delivered and thus "finalized" on the 15th. That's just when the bank has "settled" them, or something. I'm very confused by this "flexible" style of transactions. I wish they were fixed and nonambiguous. I don't understand this system at all, why it was introduced or how long it has been going on.

If I decide to say: "Nope. I'll keep the timestamp which I know are the real ones!", then my local data suddenly no longer matches the bank's data. I suppose I could add another column called "settled at" or something, if that's what it means? But even if I do this, it becomes really messy. I'd like to understand this before implementing this.

Since I have so far been updating my local dates, I'm really bothered by how my bookkeeping is now "kinda off" since some dates are "lying" in terms of when I actually made the purchases versus what the bank has later "corrected" them to say through the CSV data.

Maybe there are no legal implications of having the dates not match perfectly, but it sure annoys me.

Answer 1

If you use a double-entry accounting system from the plaintext accounting community, you can post two dates to a transaction, the second date being called an effective or secondary date (see manuals for ledger or hledger).

Here are some examples from the links above:

From the ledger manual:

In the real world, transactions do not take place instantaneously. Purchases can take several days to post to a bank account. And you may pay ahead for something for which you want to distribute costs. With Ledger you can control every aspect of the timing of a transaction.

Say you’re in business. If you bill a customer, you can enter something like

2008/01/01=2008/01/14 Client invoice  ;  estimated date you'll be paid
    Assets:Accounts Receivable            $100.00
    Income: Client name

Then, when you receive the payment, you change it to

2008/01/01=2008/01/15 Client invoice ;  actual date money received
    Assets:Accounts Receivable            $100.00
    Income: Client name

and add something like

2008/01/15 Client payment
    Assets:Checking                       $100.00
    Assets:Accounts Receivable

From the hledger manual:

The meaning of secondary dates is up to you, but it's best to follow a consistent rule. Eg "primary = the bank's clearing date, secondary = date the transaction was initiated, if different", as shown here:

2010/2/23=2/19 movie ticket
  expenses:cinema                   $10
  assets:checking

This is what I use when a manual transaction I record doesn't match the eventual posted date from a purchase on my credit card.

If you're using a spreadsheet like it sounds you are, then you I guess you'd have to add another column for this date.