“All my transactions imported with a zero amount”
Zero amounts across the board mean the importer found the transactions but could not read their values — so it wrote the only number it was sure of. The values are still in your file; the reading of them failed.
Symptoms
Dates and payees imported correctly, amounts are all 0.00 Some transactions have amounts and others do not, along a pattern The amounts look perfectly normal when you open the file
What actually causes it
Currency symbols or thousands separators in the value
"$1,234.56" is text, not a number. Strict importers refuse it and fall back to zero rather than guessing which characters to ignore.
A decimal comma
"1234,56" is a number in much of Europe and unparseable to an importer expecting a dot, which is why entire European exports can arrive at zero.
The wrong column was mapped
Mapping a balance or reference column instead of the amount produces zeroes when that column is empty for most rows.
Amounts split across debit and credit columns
With one column mapped and the other ignored, every transaction of the ignored kind arrives as zero.
How to fix it
- Drop the file into the fixer below. It reports amount values that are not plain numbers and tells you which ones can be safely rewritten.
- US-formatted values such as "1,234.56" are normalised automatically; genuinely ambiguous ones — "1.234,56" could be either 1234.56 or 1.23456 — are reported rather than rescaled by a guess.
- For CSV, redo the mapping and make sure both debit and credit columns are accounted for.
- Reverse the zero-value import before re-importing, or you will end up with both versions.
Related import problems
Skip the manual edit — fix it automatically
The fixer will not touch an amount whose decimal separator is ambiguous. Silently turning 1.234,56 into 1.23456 would import the wrong money and look like a success. Free, no signup, no upload.
Open the fixer