“I need a complete year of transactions for my tax return”
A tax year assembled from several downloads is only as good as its seams. Gaps and overlaps both hide at the boundaries between files, and both are far cheaper to find now than after a return has been filed on the totals.
Symptoms
The year had to be downloaded in several separate exports The closing balance does not match the final statement Some transactions around month ends appear twice or not at all
What actually causes it
Boundary dates included or excluded inconsistently
Exports differ on whether the end date is included. Two files that appear to join at the last day of a month may share it or skip it, and either way the error sits in exactly one day that nobody examines.
Posting date and transaction date differ
A purchase made on the last day of the year may post in the new one. Which date the export uses determines which year it falls in, and mixing exports that use different dates puts the same transaction on both sides of the boundary.
Pending transactions became final with different amounts
A pending amount imported in December can settle at a different figure in January. The ledger keeps the provisional value, and the difference never appears as its own line.
How to fix it
- Check each export with the tool below and note the transaction count, then compare the sum against your own count after import.
- Reconcile against the closing balance of each monthly statement rather than only the year end, so a break is localised to one month.
- Make export ranges touch exactly: begin each on the day after the previous one ended, and confirm the boundary day appears once.
- Re-download any period that contained pending transactions when you first exported it.
Related import problems
Skip the manual edit — fix it automatically
Recording each file’s transaction count before import gives you a figure to reconcile against, which is what turns a vague total into a check. Free, no signup, no upload.
Open the fixer