Importing transactions from a file

For a bank that will not connect, history older than a connection reaches, or an account you keep by hand. If your bank exports CSV, SageFin can read it.

Getting a file in

Open the account, choose to import, and pick the file. SageFin previews what it found before writing anything — nothing is imported until you have looked at it.

It works out the columns. Files disagree about what a date column is called and where the amount sits, so SageFin proposes a mapping and you correct it if it has guessed wrong.

It works out which way the amounts point. Some exports write a purchase as a positive number and some as a negative one. SageFin looks at the file and decides which convention it is in — worth glancing at in the preview, because a file read backwards turns a month of spending into a month of income, and it is obvious in the preview and confusing afterwards.

The three ways to handle overlap

The important choice, and the one that decides whether you end up with duplicates. It matters because a CSV row and a synced row share no identity — your bank does not put the same reference in both — so SageFin cannot simply match them up.

Skip what is already there

The default, and right nearly always.

It skips any row identical to one from a previous import, and any row dated inside the stretch your provider already covers. That second rule is coarse on purpose: rather than guessing whether a particular row is a duplicate, it declines to import into a period the connection already owns.

It errs toward importing too little, which is the recoverable direction. Missing rows can be imported; doubled history has to be found and removed.

The file is authoritative

Deletes every transaction in the account between the file's earliest and latest dates, then imports all of it.

This is the only option that removes data, and it is the right one when the file is better than what is there — a period that synced badly, or an account whose provider sent nonsense. Check the date range in the preview before you use it, because that range is exactly what gets deleted.

Import everything

No matching at all. Duplicates are the expected outcome rather than a failure.

The escape hatch for when the other two get it wrong — an unusual file, or an account where you know exactly what you are doing.

Where duplicates actually come from

Almost never from importing the same file twice: an identical row from a previous import is recognized.

They come from importing over a period your connection already covers, which the default is designed to prevent, or from reconnecting a bank in a way that creates a second account. SageFin treats an account reached through a different provider as a new account rather than the same one — so after a re-link you can see two of everything, and the fix is not to delete transactions but to move the history onto one account and keep that one.

After an import

The rows are ordinary transactions: they categorize, budget and report like any other, and you can edit them. If a batch has landed in the wrong categories, bulk edit is faster than one at a time — changing a transaction.