What a statement file is checked against

Some rows carry more or fewer fields than the header declares. The usual culprit is an unquoted comma inside a description ("Transfer to John, savings"). Importers either misalign every following column or reject the file. This needs a manual fix in a spreadsheet editor — automatic repair would have to guess which comma is real.

Several importers stop reading at the first blank line and silently drop everything after it — the classic "only half my transactions imported" symptom. Blank lines can be removed automatically.

Excel adds this marker when saving "CSV UTF-8". Some finance apps read it as part of the first column name ("Date" instead of "Date") and then fail to match the expected header. If your importer complains about an unknown first column, remove it.

This is exactly what YNAB reports as "file is empty" and other apps as "0 transactions imported". The export from your bank contained no rows: usually a date-range with no activity, or an export button that produced only column headers.

European Excel exports use ";" between columns. US-centric importers (YNAB, many banks' upload forms) expect commas and will read the whole row as one column. The file can be rewritten with commas automatically (quoted fields are preserved correctly).

Payee names like "AT&T" or "M&S" must be written as "AT&T" inside OFX/QFX files. A raw "&" breaks SGML/XML parsing at that exact point, which is one of the most common reasons a statement file fails to import even though it opens fine in a text editor.

The file starts with an invisible UTF-8 byte-order mark. Many OFX parsers require the very first bytes to be "OFXHEADER" and reject the file as invalid when a BOM is present. This is a frequent cause of "invalid file" errors for files that look perfectly fine in a text editor.

The <OFX> aggregate is never closed. This usually means the download was cut off by the bank or the browser. Most importers stop with a generic "unable to read file" error. The closing tag can be appended, but check that the transaction list looks complete.

OFX dates must be written as YYYYMMDD (optionally with a HHMMSS time and timezone suffix). Values like "2026-08-01" or "01/08/2026" make importers reject the transaction or the whole file.

Every <STMTTRN> must carry a unique FITID — it is how Quicken, QuickBooks and YNAB de-duplicate transactions between downloads. Transactions without one are silently dropped or fail the whole import. Deterministic IDs (built from date + amount + payee) can be generated automatically.

OFX 1.x files must begin with a header block (OFXHEADER:100, DATA:OFXSGML, VERSION, ENCODING, …) before the <OFX> body. Files exported without this header are rejected by Quicken, QuickBooks and GnuCash. A standard header can be prepended automatically.

TRNAMT values must be plain numbers with a dot as the decimal separator (e.g. -1234.56). Thousands separators, currency symbols or spaces make importers skip the transaction.

Accented payee names (é, ü, ñ, …) appear in a file whose header claims plain ASCII. Some importers replace them with garbage, others abort. If the import fails, ask the bank for a UTF-8 export or remove the accents manually — automatic transliteration is deliberately not applied to avoid corrupting names.

Two different transactions share the same FITID. Importers treat same-FITID entries as the same transaction, so all but the first are silently skipped — the classic "some transactions are missing after import" symptom. Duplicates can be made unique with a numeric suffix.

The file parses but contains zero <STMTTRN> entries. Apps typically report this as "file is empty" or import "0 transactions". Banks produce empty files when the selected date range contains no activity — re-download with a wider date range.

QFX/QBO files normally contain an <INTU.BID> tag identifying a bank licensed for Web Connect. Files without it may be refused by Quicken/QuickBooks with "not a valid Web Connect file". This tool does not insert bank identifiers — that value is issued to your bank by Intuit. If your bank cannot provide a proper QFX/QBO export, import via CSV instead.

This is a brokerage/investment statement (INVSTMTRS), whose transactions are buys, sells and transfers rather than the bank-style entries this tool checks. The file is not empty. Structural checks that apply to the whole document — header, escaping, dates, truncation — have still been run, but per-transaction ID checks are not yet supported for investment records.

Each QIF transaction must end with a line containing only "^". Records without one are merged into the next transaction or dropped entirely — the classic "only some of my transactions imported" symptom.

A QIF file must begin with a type declaration such as "!Type:Bank" or "!Type:CCard". Without it, GnuCash and Quicken either refuse the file or import zero transactions. A generic "!Type:Bank" header can be prepended (change it to !Type:CCard for credit-card accounts).

Amounts like "1,234.56" trip up several importers, which read the comma as a field or decimal separator. The commas can be stripped automatically ("1234.56").

An invisible UTF-8 marker precedes the first "!" line. Older QIF importers (Quicken, Microsoft Money era tools) read it as garbage and reject the header. It can be removed safely.

QIF dates are usually written as M/D/YY, M/D/YYYY or D/M/YY depending on locale. Dates outside these shapes (ISO 2026-08-01, month names, …) make importers silently skip records. Because QIF does not declare its date order, automatic rewriting would be a guess — check the importer's date-format setting instead (GnuCash lets you pick the format during import).

No transaction records were found in any !Type:Bank/CCard/Cash section, so the file contains nothing to import. If you expected data, the export date range was probably empty.