You want a full year of spending history, but your new bank connection only returns recent transactions. The answer is a controlled historical import, followed by a clearly defined handover to live sync.
The difficult part is not opening a CSV. It is knowing which source owns each period and proving that the combined ledger is complete.
This guide uses an illustrative boundary: historical records through 31 August, with live records from 1 September where your available source and app controls permit that separation. Inspect what has actually arrived before choosing your boundary.
Reviewed on 1 November 2026 against Actual Budget and BankSync documentation.
Write down the handover before importing
| Period | Intended source | Control |
|---|---|---|
| Before the earliest ledger date | Opening balance | Represents money already present |
| Historical period through 31 August | Bank export | One account, bounded dates |
| From 1 September | Live connection | Inspect earliest delivered record |
| Any overlap | Both sources may contain the same payment | Review and reconcile explicitly |
1. Inspect the live history you already have
Open the Actual account and record its earliest imported date, latest date and reconciled position. Do the same for each account separately. Do not use one account's available history as a promise for another.
BankSync's UK bank guide describes approximately 60 days of initial history, with availability dependent on the connection. Actual also has its own import behaviour. Neither means that a new connection automatically reconstructs a full year.
If your live import already includes August, a CSV through 31 August overlaps. Move your planned boundary or deliberately review the overlap. A boundary written in a note does not change what an app imports.
Preserve a backup before bulk changes and keep the original bank export unchanged. Work on a separate copy if you need to restrict dates or adjust columns.
2. Inspect the file before committing
Choose the correct account
Export from the bank account that corresponds to the Actual ledger you will open.
Confirm the date range
Check the first and last records, including whether boundary dates are inclusive.
Check date interpretation
Use an unambiguous example such as 23 August, then inspect ambiguous dates such as 4 May.
Check amount direction
Compare one known purchase and one incoming payment with the bank.
Inspect the preview
Map the fields and review the interpreted values before importing.
Actual's import documentation supports CSV and financial file formats including OFX/QFX. It recommends OFX/QFX where available because transaction identifiers help duplicate detection. For CSV, the import screen lets you map fields and adjust date, delimiter and amount handling.
Use the options that match your file, rather than toggling “Flip amount” simply because a total looks wrong. Some exports use one signed amount; others use separate debit and credit columns.
Keep currency consistent. An approximate multiplier is not a substitute for an agreed currency-conversion method when you need precise records.
Preview checks for a UK CSV
| Bank record | Correct interpretation | Problem to catch |
|---|---|---|
| 04/05/2026 purchase | 4 May, if the file uses day/month/year | Accidental 5 April |
| Debit 45.00 | £45 outflow | Positive income |
| Credit 120.00 | £120 inflow | Negative expense |
| Blank merchant, description present | Usable description retained | A missing payee mistaken for a missing row |
| 31 August boundary row | Included in exactly the intended period | Gap or unexplained overlap |
3. Reconcile the combined ledger
After import, compare the opening position, incoming money, outgoing money and closing position over a known period.
For example, £900 opening balance plus £2,400 received minus £2,050 paid gives £1,250. A ledger ending at £1,300 has a £50 difference to explain. Search for missing or repeated £50 movements, but also check the opening balance and dates.
Adding historical transactions can change what your starting-balance entry needs to represent. Do not retain an opening balance that already includes those movements and then count them again through the imported rows. Define the balance immediately before the first included transaction.
Follow Actual's reconciliation workflow to compare the ledger with the bank. Complete the final locking step only after the relevant records agree.
4. Resolve overlap carefully
Two equal payments are not necessarily duplicates. Check the account, date, payee and context before merging.
Actual's duplicate-merging guide explains that the merge action applies to two selected matching-amount transactions and describes which record is retained. Review fields such as category and notes afterwards, especially if you previously entered a payment manually.
Keep a short import log: filename, account, covered dates, import date, reviewer and the reconciliation result. This makes the next historical batch easier and prevents another household member from importing the same file without realising it.
Avoid repeated trial imports into your working ledger. Test a small, well-understood set and resolve the mapping before proceeding with the remainder.
Finish with an acceptance checklist
| Question | Ready when |
|---|---|
| Does every imported row belong to this account? | Account identity is confirmed |
| Are dates and signs correct? | Known examples agree with the bank |
| Is the opening balance defined? | It precedes the included transaction period |
| Are overlaps explained? | Duplicates reviewed without merging legitimate repeats |
| Does the closing position agree? | Reconciliation is complete |
| Is future ownership clear? | The live connection is the ongoing source |