“Every transaction imported one day early”
A uniform one-day shift across every transaction is never a coincidence and never a bank error — it is a timezone conversion. OFX dates can carry a timezone offset, and when the time of day sits near midnight, converting to your local zone moves the calendar day.
Symptoms
Every imported transaction is exactly one day earlier (or later) than on the statement The shift is consistent, not random — a strong clue it is systematic Reconciliation fails at month boundaries because transactions land in the wrong month
What actually causes it
A timezone suffix on DTPOSTED
OFX dates may end with an offset in brackets, such as 20260801120000[-5:EST]. Software that converts this to your local zone can cross midnight and change the date, especially for transactions timestamped late in the evening or at 00:00.
A midnight timestamp with no timezone at all
When the bank writes 20260801000000 with no offset, some importers assume UTC and shift it into the previous day for users west of Greenwich.
Date-only values interpreted as UTC midnight
A plain 20260801 is unambiguous by the standard, but importers that internally treat it as a timestamp can still apply an offset to it.
How to fix it
- Drop the file into the fixer below and look at the reported dates — this tells you whether the file carries timezone suffixes at all.
- If it does, the shift is happening in your finance app, not in the file: check the app's timezone or date-handling preference.
- If the dates are plain YYYYMMDD and still shift, the app is assuming UTC; re-downloading rarely helps, and adjusting the app's timezone usually does.
- Do not bulk-edit dates in the file to compensate — the next download will shift too, and you will have two conventions in one register.
Related import problems
Skip the manual edit — fix it automatically
The fixer shows exactly what the date fields contain, which settles whether the file or the app is doing the shifting. Free, no signup, no upload.
Open the fixer