CSV format reference

CSV is the universal interchange format. Almost every bank, payroll provider, accounting product, and spreadsheet app exports a flavor of CSV. Solid Accounting reads them through a single unified import wizard with column-mapping at preview time, so you don't need a different importer per source.

What's supported

Solid auto-detects the delimiter from the first line — you don't pick it manually. If the first line contains a comma, it's CSV; a tab, TSV; a semicolon, semicolon-separated. If the file's mis-detected (rare, but possible with unusual data), the column mapping preview will show garbled columns and you can re-export with a cleaner delimiter.

The .txt extension is accepted because some banks export bank-statement files as .txt — the format is still CSV-like internally.

The import flow

CSV imports go through a wizard with these steps:

1. Pick the file — file picker filtered to .csv .tsv .tab .txt
2. Preview — Solid reads the first 20 rows and shows them in a table so you can see the columns and decide how to map them
3. Map columns — drag each CSV column to the corresponding Solid field (date, amount, account, payee, memo, etc.) or skip columns that don't matter
4. Parse + import — with mappings in hand, Solid parses the full file and stages the entries for review
5. Review — same review-and-post step as every other import path

The mapping is the work. CSVs from different sources have different column orders and naming conventions, so there's no good way to skip this step — but Solid remembers your mappings per-source so you only do it once for any given bank or product.

Required vs optional columns

Every CSV row that becomes a transaction needs at minimum:

Optional but very useful:

Anything else in the CSV (running balance, transaction-type code, internal IDs) goes into the entry's raw metadata and stays accessible from the entry's source-data tab without polluting the GL view.

Date formats

CSV dates are the source of more import errors than every other field combined. Solid accepts these on input:

If a column has dates that could be interpreted multiple ways (e.g. 04/05/2026 could be April 5 or May 4), Solid asks during the mapping step which interpretation to use. You pick once for the whole file.

Amount formats

Solid handles common bank amount formats:

For separate-debit-credit-columns CSVs, map both columns at the mapping step — Solid combines them into a single signed amount internally.

Encoding

CSVs come in a mix of encodings. Solid tries:

1. UTF-8 with or without a BOM (byte-order mark)
2. UTF-16 with BOM
3. CP-1252 / Windows-1252 as fallback

Almost every modern bank export is UTF-8. The fallback to CP-1252 catches old QuickBooks-era exports and some Windows-default Excel files. If a row has characters outside both encodings (rare), the import surfaces the offending row.

If you have a CSV in something exotic (Shift-JIS, Big5), open it in a text editor and save as UTF-8 first.

Quoting and escaping

Standard CSV quoting rules apply:

• Fields containing delimiters or quotes must be quoted: "Smith, John"
• Quotes inside quoted fields are doubled: "He said ""hi"""
• Newlines inside quoted fields are preserved as embedded newlines

Some bank exports get the quoting wrong (unescaped commas in payee names, unbalanced quotes). When the parser hits one of these, the affected row is flagged in the preview with an error indicator — you can edit the source file and re-import.

Common bank export quirks

If your bank's export has a wrinkle not listed here, the column mapper can usually figure it out — try it and see what the preview shows.

Saving column mappings

Once you've mapped columns for a source (e.g. Chase Operating Checking, transactions CSV), Solid offers to save the mapping. Subsequent imports from the same source skip the mapping step and go straight to preview-and-post.

Mappings are stored per-file in import_mappings. They can be edited or deleted from settings if a bank changes its export format.

When CSV is the wrong choice

For full company-file migrations, prefer the dedicated paths:

• QuickBooks Desktop → use the .qbextract migration tool, see Migrate from QuickBooks
• QuickBooks Online → the OAuth integration, also in the QuickBooks guide
• Xero, FreshBooks → respective OAuth integrations under /docs/import-export/from/

CSV is best for transactions only — bank statement imports, payroll-run imports, ad-hoc transaction batches. It doesn't carry chart-of-accounts structure, customer/vendor metadata, or reconciliation history; if you need those, use a richer format.

Common errors

"Could not parse date in column N row M" — date format the parser doesn't recognize. Check the row in question; usually a single bad row caused by a manual edit or a weird header. Edit the source CSV and re-import.

"Amount NaN" — non-numeric content in the amount column. Often a header row that wasn't excluded. Re-run the mapping step and tick "skip first row as header."

"Duplicate transactions detected" — Solid's duplicate-detection caught likely re-imports of the same data. The preview lists duplicates so you can confirm they're new vs. already-imported. Re-running an import is safe — Solid won't post duplicates without your confirmation.

"Encoding error decoding row N" — the file isn't UTF-8 or CP-1252. Open in a text editor, save as UTF-8 with BOM, retry.

"Wrong number of columns at row N" — a row has more or fewer columns than the header. Almost always an unescaped quote or comma in a payee name. Find the row in the source CSV and fix the quoting.

Cross-references

• Import & Export overview — table of every supported format and the migration guides
• IIF format reference — the QuickBooks alternative for transaction-only files
• Banking → Bank Feeds — automated daily sync via Plaid, the "no manual CSV" alternative