Importing a bank statement without creating a mess

Typing transactions by hand is how tracking dies. It is slow, and worse, it is incomplete, because the ones you forget to type are exactly the ones that break your reconciliation two months later.

So import. But an import touches hundreds of rows at once, which means a mistake at import time is a mistake several hundred times over. These are the ones worth knowing about before you click.

Before you import

Get the right file. CSV or a format your app reads. Not PDF. Most banks bury the export somewhere unhelpful: look for “download”, “export”, or a small spreadsheet icon near the date filter rather than the obvious “statement” button, which usually gives you a PDF designed for printing.

Pick the date range deliberately. Start from the day after your last import ended. Not the same day, the day after. An overlapping range is the single most common cause of duplicates, and duplicates are much harder to find later than to prevent now.

If this is your first import, start from your opening balance date and not a day earlier. Everything before that date is history you have chosen not to hold, and importing a partial slice of it will only make your first reconciliation fail for reasons that are not real.

Open the file once and look at it. Ten seconds. You are checking three things, and all three are covered below.

The six things that go wrong

1. Dates, and the 03/04 problem

Is 03/04/2026 the third of April or the fourth of March? Both readings are used by real banks, and the file rarely says which.

If you get it wrong the import still succeeds. Nothing errors. Your transactions simply land in the wrong months, and every monthly total you produce for the next year is quietly wrong.

Check it before importing: find a row whose day is above 12 and look at which position that number sits in. 25/04/2026 can only be day-first. If every row in the file is ambiguous, sort by date and see whether the sequence makes sense.

2. Signs, and which column means what

Banks disagree about how to express money leaving your account. Some use a negative number in one amount column. Some use two columns, debit and credit. Some use a positive number with a separate direction flag.

Get this backwards and every expense becomes income. It is obvious once you look at the result, which is why you should always look at the result.

3. Duplicates

They come from overlapping date ranges, from importing the same file twice, and from a pending transaction that you imported while pending and again once it settled.

The safest habit is simply never to overlap. If you suspect you already have duplicates, do not hunt them one by one. Sort by amount, look for pairs on the same date with the same value, and check those.

4. Transfers arriving as two expenses

This is the important one and it catches almost everyone.

Move AED 5,000 from your current account to your savings account, then import both statements, and you now have an expense of 5,000 leaving one account and income of 5,000 arriving in the other. Your spending for the month is overstated by 5,000 and your income is too.

They are not two transactions. They are one transfer, and a transfer is neither income nor expense: your net worth did not change, only the location of the money did. We wrote about why this matters more than anything else in a ledger.

So after every import, do one deliberate pass looking for movements between your own accounts. Payments to credit cards, money to savings, investment purchases, transfers abroad. Convert each into a single transfer.

Do this at import time. It takes five minutes when the rows are in front of you and it is genuinely painful to reconstruct six months later.

5. Foreign currency rows

If the account is in a currency that is not your base currency, the import should keep the amounts in the account’s own currency and let the conversion happen at display time.

What you do not want is a file where your bank has already converted everything into your home currency at a rate it does not disclose. If that is all your bank offers, at least record which account it came from so you know the figures are translated rather than native.

6. Everything landing in Uncategorised

That is what should happen, and it is fine. What is not fine is trying to fix all of it in one sitting.

After you import

Sort the big ones first. Categorise by descending amount. Twenty rows usually account for most of the value, and getting those right matters far more than the coffees.

Let the rules learn. Most of what you categorise now becomes a rule, so the next import arrives mostly pre-sorted. The first import is the expensive one. The fifth is nearly automatic.

Leave the unclear ones in Uncategorised. Do not agonise. Speed now, accuracy at the monthly review. A transaction sitting in Uncategorised is visible and fixable; a transaction you never recorded because you got tired is neither.

Then reconcile. This is the step that tells you whether the import actually worked. Take the closing balance the bank shows and compare it against what your ledger now says. If they match, the import was clean and complete. If they do not, the gap is a number, and the number is a clue: a round figure is usually a missed transfer, a small one is usually a single missing row, and exactly double a transaction you can see is a duplicate.

Do not move on until it ties. An import you have not reconciled is not finished, it is just optimistic.

The rhythm this settles into

After two or three months it stops being a task and becomes about ten minutes:

1. Export from the day after last time.
2. Import.
3. Check the dates and the signs on a couple of rows.
4. Fix the transfers.
5. Sort the big ones, leave the rest.
6. Reconcile until it ties.

That is the whole thing. The tedium is entirely in the first import, and it is finite. What you get in exchange is a complete record rather than an approximate one, and complete is the only version that can answer a question.