Importing CSV and QIF files

Where it lives

On the Accounts page, next to Add Account, sits Import CSV/QIF (currently in beta). Pick the Endute account the transactions belong to (an active bank, cash, credit card or loan account; an investment account takes security transactions, not a statement of cash rows, so it is not offered), drop in a file (.csv, .tsv or .qif, up to 5MB), and the flow adapts to what you gave it: QIF files describe themselves and go straight through, CSV files get a mapping step first.

The CSV mapping step

A CSV is just columns, so Endute needs to know which column is the date, which is the description, and how amounts work. Most of the time you will not do this by hand. Formats you have imported before are recognised from their headers (Using your saved format), several common bank exports are known outright (Detected bank format), and unfamiliar files get an AI-suggested mapping you confirm rather than build. Date format and decimal separator are detected from the data, with a warning when a date format is genuinely ambiguous, and a preview of sample rows shows what the suggested mapping produces.

Tick Save this format for future imports on the first upload for an account, and later files with exactly the same layout skip the mapping step entirely, going straight to staging with the saved mapping applied. (A partial match or an ambiguous date format still shows the step, prefilled, so nothing lands unchecked.) Otherwise, click Confirm and Stage when everything looks right.

If your file has categories

Files exported from other finance apps often carry categories. When Endute finds them it asks one question: Import categories pre-fills the payee and category from the file, creating categories as needed, which is the right choice when migrating from an app whose categorisation you trusted. Ignore categories imports the payee only and lets Endute categorise, the right choice when the old app's categories were half the reason you left.

How duplicates are kept out

File import is built to be safe to repeat. Two protections run on every batch:

• Rows identical to ones already imported from a previous file are skipped silently and reported as duplicates skipped, so re-uploading an overlapping export does not double anything. Genuine repeat transactions, two identical coffees on the same day, are recognised by count and both come through.
• Rows that look like transactions already in your ledger, typically overlap between a file and a bank feed on the same account, are not dropped but flagged as potential duplicates flagged for review, so you make the call instead of the importer guessing.

Everything else is staged with enrichment, payee matching and transfer pairing run on the batch, exactly as for bank-synced rows, and the results step offers two ways on: import the whole file in one go, or review it one row at a time.

Importing the whole file in one go

Import all opens the same preview the bank history import uses: money in and out per month, the merchants recognised, and how many rows already carry a category. A large file is categorised in the background first and the preview says so; it is ready in about a minute. One tap then puts the file into your ledger, and the finished screen tells you what landed. Your rules fill in the payee, category, description and tags of the rows it brings in; whether a rule imports automatically or sends to review makes no difference here.

Rows that need a decision stay in the review queue, and the preview says which and why: possible duplicates of rows already in your ledger, rows that match something you entered by hand, rows that match a scheduled transaction, and transfer pairs we could not settle. Everything else imports. A row we cannot categorise still lands, without a category, so nothing is stranded; the finished screen counts those so you can fill them in from Transactions. Transfers between two of your own accounts are matched up when both halves are in your uploaded files with the same amount.

If the file reaches back before the account's opening balance date, the opening balance moves back so today's balance does not change. Undo import on the finished screen puts every row back into the queue and restores the opening balance, as long as the imported transactions have not been edited since. The same button sits on the review page of any account with file rows waiting, so a queue uploaded earlier can be imported the same way.

QIF notes

• Supported QIF types are bank, credit card and cash accounts; investment QIF files are not supported, and multi-account files need exporting one account at a time.
• QIF carries more structure than CSV, and the import reads its categories and split details. Transfers marked inside the file arrive as ordinary transactions, ready to pair up in review.
• QIF import requires an active subscription or trial; CSV import does not.

What next

A file import ends either in the one-go import above or in the same review flow as a bank sync. If a file refuses to parse, or your bank's export looks unusual, send it to support and we will likely add it to the recognised formats, which fixes it for everyone after you.