CSV imports

Sure supports importing financial data from CSV files, making it easy to migrate from other financial apps or add bulk data.

Importing older history

A historical export can fill gaps left by a bank connection. File imports use the dates in the file rather than a bank-feed lookback window. See Transaction history and import limits to check your source first.

Export only the missing date range where possible, and check for overlapping transactions already in Sure.
Choose the importer matching the file format, verify the destination account and currency, and review the preview before publishing.
Do not assume that file imports automatically deduplicate transactions already received from a provider.

The general transaction-import account mapping dropdown currently lists manual accounts only. Although the backend supports an account-specific import targeting a linked account, that path has not been browser-verified for this guide. These instructions do not promise that an existing linked account will appear in the dropdown. Do not create a duplicate account or unlink an existing connection merely to bypass this limitation.

Supported import types

You can import the following types of data via CSV:

Accounts: Create multiple accounts with opening balances
Actual Budget transactions: Import transaction history exported from Actual Budget
Mint transactions: Import transaction history exported from Mint
Merchants: Create merchant records in bulk
Transactions: Import transaction history
Trades: Import investment trades
Categories: Set up your category structure
Rules: Import transaction rules

Importing accounts

Account imports let you quickly set up multiple accounts with their opening balances.

CSV format

Your CSV file should include these columns:

Column	Required	Description	Example
Account type	Yes	Type of account	Checking, Savings, Credit Card
Name	Yes	Account name	Main Checking Account
Balance	Yes	Opening balance	1000.00
Currency	No	Currency code (defaults to family currency)	USD
Balance Date	No	Date for the opening balance	01/01/2024

Example CSV

Account type,Name,Balance,Currency,Balance Date
Checking,Main Checking Account,1000.00,USD,01/01/2024
Savings,Emergency Fund,5000.00,USD,01/15/2024
Credit Card,Rewards Card,-500.00,USD,02/01/2024

Balance date column

The optional Balance Date column lets you specify when the opening balance should be recorded. This is useful when:

Migrating historical data from another app
Setting up accounts with balances from a specific date
Maintaining accurate historical balance tracking

If you don’t provide a balance date, Sure will use the current date for the opening balance.

The date format should match your import settings. Common formats include MM/DD/YYYY, DD/MM/YYYY, YYYY-MM-DD, and DD/MM/YY. The DD/MM/YY format (two-digit year) is available for CSV imports only. Two-digit years are interpreted as 1969–2068, so verify the parsed preview before confirming the import.

Supported account types

Checking
Savings
Credit Card
Investment
Loan
Property
Vehicle
Crypto
Other Asset
Other Liability

Importing transactions

Transaction imports let you add historical transaction data to your accounts.

CSV format

Your CSV file should include these columns:

Column	Required	Description
Date	Yes	Transaction date
Amount	Yes	Transaction amount
Name	Yes	Transaction description
Account	Yes	Account name
Category	No	Category name
Notes	No	Additional notes

Example CSV

Date,Amount,Name,Account,Category,Notes
01/15/2024,-45.50,Grocery Store,Main Checking,Groceries,Weekly shopping
01/16/2024,-12.00,Coffee Shop,Main Checking,Dining Out,Morning coffee
01/20/2024,2500.00,Paycheck,Main Checking,Income,Bi-weekly salary

Importing merchants

Merchant imports create new merchant records in bulk. Sure creates every row as a family-owned merchant, so the color column applies and a hex value is accepted. Provider-detected merchants (created automatically during bank sync or AI enrichment) are managed by Sure and do not support a color.

CSV format

Column	Required	Description
name	Yes	Merchant name
color	No	Hex color code (e.g. `#e99537`). A random color is assigned if omitted.
website_url	No	Merchant website URL

Example CSV

name,color,website_url
Coffee Shop,#e99537,https://coffeeshop.com
Pizza Palace,#4da568,https://pizzapalace.com
Bookstore,,

How duplicate names are handled

If a merchant with the same name already exists in your family, that row is skipped. The import reports the count of created merchants and the count of skipped rows separately.

Permissions required to publish or revert

Imports are family-scoped, but imports attached to account statements also require permission to view the statement. Publishing an import (writing transactions into accounts) and reverting a published import (deleting those entries) each require write access — owner or full_control — to every pre-existing account the import targets. Accounts created by the import itself are excluded from this account-access check. Statement imports additionally require permission to manage the statement. This covers:

The primary destination account selected during mapping
Any accounts referenced via column mappings
Accounts that already received entries from a previous publish of the same import
For QIF files with embedded account names: any existing Sure accounts whose names match those in the file

If your access to an account has been downgraded to read-only since the import was configured, the publish or revert step will fail with a permissions error. Ask the account owner to grant you write access, or have them complete the action themselves. If a revert fails, the import’s status changes to Revert failed. A Try again button appears on the import detail page — click it to retry the revert without needing to navigate back to the imports list.

Import process

The import wizard shows a step indicator at the top of the page. Step labels display in your configured language (set under Settings → Preferences → Language). On mobile, the indicator shows a “Step X of Y” progress count instead.

Template suggestions

When you reach the Configure step after uploading a CSV, Sure checks whether you have a previous completed import of the same type for the same account. If one exists, a prompt appears offering to apply that import’s column mapping configuration to the current one. The prompt text, button labels, and sample data caption are displayed in your configured language.

Select Apply template to copy the column assignments, date format, signage convention, and number format from the previous import.
Select Manually configure to dismiss the suggestion and set up the columns yourself.

If no previous import is found, the Configure step opens directly in manual mode without showing a suggestion. The steps vary by import type:

Import type	Steps
CSV (transactions, trades, accounts, etc.)	Upload → Configure → Clean → Map → Confirm
QIF	Upload → Select → Clean → Map → Confirm
PDF statement	Upload → Configure → Clean → Confirm
Sure export (NDJSON)	Upload → Confirm

The Map step only appears when your data requires column or account mapping; it is skipped automatically when no mapping is needed.

Navigate to imports: Go to Settings → Imports or use the import button in the app
Upload: Drag and drop your file or click to browse
Configure: Choose the date format, number format, and column assignments
Select (QIF only): Review the detected date format and choose which categories and tags from your QIF file to import
Clean: Fix any invalid rows flagged in the table
Map (when needed): Assign imported accounts, categories, or tags to existing ones in Sure
Confirm: Review the import summary and publish

QIF imports

QIF (Quicken Interchange Format) files are exported from Quicken and similar personal finance apps. Sure parses the QIF format directly — no column mapping is needed.

Supported QIF account types

QIF type	Sure account type
Bank	Depository
Cash	Depository
CCard	Credit Card
Invst	Investment
Oth A	Other Asset
Oth L	Other Liability

Split transactions

QIF files can contain split transactions — single entries that are broken into multiple line items with individual categories, amounts, and notes. When your file contains splits, Sure imports each split line as a child entry under the parent transaction, preserving the original breakdown. Split categories are shown separately on the Select step so you can choose which ones to include. If the split amounts do not sum to the parent total, Sure skips the split lines and imports the transaction as a single entry.

Multi-account QIF files

A QIF file exported from Quicken can contain multiple accounts in a single file (identified by !Account sections). When Sure detects account metadata in the file:

Each account in the QIF file is matched to an existing Sure account by name, or created automatically if no match is found.
Opening balances declared in the file are applied to the corresponding accounts.
You do not need to assign a single target account before publishing — Sure routes each transaction to the correct account automatically.

When the QIF file does not contain account metadata, you must select a target account before publishing, as with a standard single-account import.

Date format detection

Sure automatically detects the date format used in your QIF file by sampling the D-fields and selecting the best match. You can review and change the detected format on the Select step before proceeding. The default fallback is MM/DD/YYYY (US convention). QIF files support several date styles including:

MM/DD/YYYY and MM/DD/YY (Quicken US)
DD.MM.YYYY (European dot-separated)
DD-MM-YYYY (dash-separated)
DD MMM YYYY (e.g. 26 Jan 2026, Amex-style)

Investment transactions

QIF !Type:Invst sections are imported as investment activity. Trade actions (Buy, Sell, Cover, ShtSell, ReinvDiv) create Trade records. Non-trade actions (Div, IntInc, CGLong, CGShort, XIn, XOut, MiscInc, MiscExp) create Transaction records with appropriate labels. Securities are resolved by matching the QIF security name to the ticker defined in the file’s !Type:Security sections.

Importing rules

Rule imports let you create or update transaction rules in bulk from a CSV file.

CSV format

Column	Required	Description
name	No	Rule name. If a rule with this name already exists, it is updated in place. Rows without a name always create a new rule.
resource_type*	Yes	Must be `transaction`
active	No	`true` or `false` (defaults to `false`)
effective_date	No	Only apply the rule to transactions on or after this date (YYYY-MM-DD)
conditions*	Yes	JSON array of condition objects
actions*	Yes	JSON array of action objects

Condition types

Each entry in the conditions array is a JSON object with condition_type, operator, and value fields.

`condition_type`	Description	Value
`transaction_name`	Matches on the transaction name	Plain text
`transaction_amount`	Matches on the amount	Numeric
`transaction_type`	Matches on transaction type (income, expense, transfer)	Type string
`transaction_merchant`	Matches on merchant	Merchant name — resolved to an ID automatically
`transaction_category`	Matches on category	Category name — resolved to an ID automatically
`transaction_tag`	Matches on tag	Tag name — resolved to an ID automatically
`transaction_details`	Matches on provider metadata fields	Plain text
`transaction_notes`	Matches on transaction notes	Plain text
`transaction_account`	Matches on the account	Account UUID — account names are not resolved

The operator field must be supported by the condition type:

Condition types	Supported operators
`transaction_name`, `transaction_notes`	`like`, `not_like`, `starts_with`, `ends_with`, `matches_regex`, `=`, `!=`, `is_null`, `is_not_null`
`transaction_amount`	`>`, `>=`, `<`, `<=`, `=`, `!=`
`transaction_merchant`, `transaction_category`, `transaction_tag`, `transaction_account`	`=`, `!=`, `is_null`, `is_not_null`
`transaction_type`	`=` (with `income`, `expense`, or `transfer`)
`transaction_details`	`like`, `=`, `is_null`

For text conditions, like means contains, not_like means does not contain, and starts_with and ends_with match a prefix or suffix. The matches_regex operator runs a case-insensitive PostgreSQL regular expression against the stored field value; patterns are capped at 200 characters and back-references (\\1 through \\9) are not allowed. is_null and is_not_null do not require a value. transaction_details searches string and number values in provider metadata. Both like and = use contains matching there: like is case-insensitive and = is case-sensitive. It does not support the extended text operators. When a transaction_category, transaction_merchant, or transaction_tag condition references a name that does not exist yet, Sure creates the category, merchant, or tag automatically. The same name used in multiple rows in the same file reuses the record created for the first row.

Action types

Each entry in the actions array is a JSON object with action_type and an optional value field.

`action_type`	Description	Value
`set_transaction_category`	Assign a category	Category name — resolved to an ID automatically
`set_transaction_merchant`	Assign a merchant	Merchant name — resolved to an ID automatically
`set_transaction_tags`	Assign one or more tags	Comma-separated tag names — each resolved to an ID automatically
`set_transaction_name`	Set the transaction name	Plain text
`auto_categorize`	Auto-categorize using AI	No value needed

Example CSV

name,resource_type*,active,effective_date,conditions*,actions*
Categorize groceries,transaction,true,2024-01-01,"[{""condition_type"":""transaction_name"",""operator"":""like"",""value"":""grocery""}]","[{""action_type"":""set_transaction_category"",""value"":""Groceries""}]"
Tag coffee runs,transaction,true,,"[{""condition_type"":""transaction_name"",""operator"":""like"",""value"":""coffee""}]","[{""action_type"":""set_transaction_tags"",""value"":""Coffee,Personal""}]"

Tips for successful imports

Use templates: Download CSV templates from the import screen for the correct format
Check encoding: Ensure your CSV file is UTF-8 encoded
Validate dates: Make sure dates match your selected format
Test with small files: Try importing a few rows first to verify the format
Clean your data: Remove any extra columns or formatting before importing

Troubleshooting

File upload fails on iPhone or iPad

On iOS (Safari and Chrome for iOS), tapping the file picker to upload a Sure export (NDJSON) or a bank statement (PDF) could fail silently or return an error page. The upload appeared to start but never reached the server. The affected Sure upload forms used native form submission. They now submit through Turbo using requestSubmit(), allowing Turbo to send the selected file in its fetch request. If you are on an older version and see a “We didn’t receive your file. Please try uploading it again.” alert on iOS, upgrade to the latest release and retry the upload.

Import fails with date errors

Check that your date format matches the setting you selected during import. The Balance Date column in account imports must use the same format as other date fields. Sure supports the following date formats for CSV imports:

Format	Example
MM/DD/YYYY	01/15/2024
DD/MM/YYYY	15/01/2024
YYYY-MM-DD	2024-01-15
DD/MM/YY	15/01/24

The DD/MM/YY format is available for CSV imports only. Because two-digit years are ambiguous (Sure interprets them as 1969–2068), this format is not available as a global date preference. Always verify the parsed preview against your CSV data before confirming the import.

Accounts not found

When importing transactions, ensure the account names in your CSV exactly match existing account names in Sure.

Duplicate transactions

Sure will import all rows from your CSV. Review your data before importing to avoid duplicates.

Rule import with tag conditions produces broken rules

If you imported a rules CSV with transaction_tag conditions on an older version of Sure (before the fix in #3419), the tag name was stored as-is instead of being resolved to the tag’s ID. Rules with this problem match no transactions for the tag condition. To fix affected rules, delete and re-import them, or edit each rule manually in Settings → Rules to remove and re-add the tag condition.

Sure NDJSON import fails with a null rule name

Rules exported from Sure may have a null name field, which is valid. If a full all.ndjson export fails preflight with an error about a missing rule name, ensure you are using a current version of Sure — older versions incorrectly required the name field to be present.

Sure NDJSON import fails with a missing reference on rejected transfers

If your export contains rejected transfers whose original transactions were later deleted, Sure will skip those orphaned rows and report them as warnings rather than blocking the import. Check the preflight warnings in the import response for details on any skipped records. Preflight missing-reference error and warning messages are displayed in your configured interface language (set under Settings → Preferences → Language).

Sure NDJSON import fails with a duplicate category or tag name

Category and tag names must be unique within a family. If your NDJSON file contains two or more Category (or Tag) records with the same name, preflight will reject the import with a duplicate_taxonomy_name error. Remove or rename the duplicate entries in your export file before retrying. If the duplicate names already exist in your Sure database from before this constraint was enforced, Sure automatically merges them during the upgrade migration. The oldest record (by creation date) is kept, and all references — transactions, rules, budget lines, and import mappings — are updated to point to the surviving record.

Sure NDJSON import on a fresh family shows warnings about existing categories, tags, or merchants

When you import a Sure export into a fresh family, Sure seeds that family with a default set of categories during onboarding. If your export contains categories, tags, or merchants whose names match those defaults, Sure treats the collision as a warning rather than an error: the existing record is reused and updated with the imported data instead of creating a duplicate. The import proceeds normally. The confirm screen lists how many records were reused so you can verify the outcome. No action is needed. If you see these warnings and the import finishes without errors, your data imported correctly.

Sure NDJSON import shows a warning about merchant details differing

Provider-assigned merchants (including legacy AI-created provider records) are shared across all families on a Sure instance. When an imported ProviderMerchant record already exists on the instance with different details — for example, a different website URL or name — Sure keeps the existing record as-is and surfaces the differences on the confirm screen as a warning. This is expected behavior. The import still proceeds; affected transactions reference the existing shared merchant. No action is required unless you want to update the merchant’s details, which you can do manually from Settings → Merchants after the import completes. If the import file contains a ProviderMerchant that does not exist on the instance at all, Sure creates a family-owned merchant (a FamilyMerchant) for the importing family instead of registering a new shared provider merchant. The transactions in the import are linked to that family-owned merchant, and the import proceeds normally.

Sure NDJSON import reports missing merchants as warnings instead of errors

Exports taken before provider-merchant support was added (before version containing #3113) did not include ProviderMerchant rows. When you import such a file, Sure cannot resolve the merchant references. The import now treats unresolvable merchant_id values as warnings rather than blocking errors — the affected transactions and recurring transactions import without a merchant assigned. The confirm screen shows the count of affected records. If you import from a newer export and still see this warning, it may mean some merchant records were not exported. Re-export from the source instance and retry the import.

Unnamed recurring transactions are skipped when their merchant is missing

A recurring transaction series requires either a name or a merchant to import. If a series has neither — because its merchant could not be resolved and it has no name — Sure skips it and reports the count on the confirm screen. Named series without a merchant import normally. Automatically detected recurring transactions that are skipped are rebuilt after the import completes when Sure syncs the family’s accounts.

Limits

Account imports: Maximum 50 accounts per import
Transactions: Maximum 10,000 rows per import
Actual Budget imports: Maximum 10,000 rows per import
Mint imports: Maximum 10,000 rows per import
Trade imports: Maximum 10,000 rows per import
Category imports: Maximum 10,000 rows per import
Rule imports: Maximum 10,000 rows per import
Merchant imports: Maximum 10,000 rows per import
CSV file size: Maximum 10 MB per import

If a CSV import fails during upload or publish, check both the row count and the file size. An import can be under the row limit and still fail if the CSV file is larger than 10 MB.

Getting help

If you encounter issues with CSV imports:

Check the troubleshooting guide
Ask in the Discord
Open an issue

​CSV imports

​Importing older history

​Supported import types

​Importing accounts

​CSV format

​Example CSV

​Balance date column

​Supported account types

​Importing transactions

​CSV format

​Example CSV

​Importing merchants

​CSV format

​Example CSV

​How duplicate names are handled

​Permissions required to publish or revert

​Import process

​Template suggestions

​QIF imports

​Supported QIF account types

​Split transactions

​Multi-account QIF files

​Date format detection

​Investment transactions

​Importing rules

​CSV format

​Condition types

​Action types

​Example CSV

​Tips for successful imports

​Troubleshooting

​File upload fails on iPhone or iPad

​Import fails with date errors

​Accounts not found

​Duplicate transactions

​Rule import with tag conditions produces broken rules

​Sure NDJSON import fails with a null rule name

​Sure NDJSON import fails with a missing reference on rejected transfers

​Sure NDJSON import fails with a duplicate category or tag name

​Sure NDJSON import on a fresh family shows warnings about existing categories, tags, or merchants

​Sure NDJSON import shows a warning about merchant details differing

​Sure NDJSON import reports missing merchants as warnings instead of errors

​Unnamed recurring transactions are skipped when their merchant is missing

​Limits

​Getting help

CSV imports

Importing older history

Supported import types

Importing accounts

CSV format

Example CSV

Balance date column

Supported account types

Importing transactions

CSV format

Example CSV

Importing merchants

CSV format

Example CSV

How duplicate names are handled

Permissions required to publish or revert

Import process

Template suggestions

QIF imports

Supported QIF account types

Split transactions

Multi-account QIF files

Date format detection

Investment transactions

Importing rules

CSV format

Condition types

Action types

Example CSV

Tips for successful imports

Troubleshooting

File upload fails on iPhone or iPad

Import fails with date errors

Accounts not found

Duplicate transactions

Rule import with tag conditions produces broken rules

Sure NDJSON import fails with a null rule name

Sure NDJSON import fails with a missing reference on rejected transfers

Sure NDJSON import fails with a duplicate category or tag name

Sure NDJSON import on a fresh family shows warnings about existing categories, tags, or merchants

Sure NDJSON import shows a warning about merchant details differing

Sure NDJSON import reports missing merchants as warnings instead of errors

Unnamed recurring transactions are skipped when their merchant is missing

Limits

Getting help