mirror of
https://github.com/actualbudget/actual.git
synced 2026-03-09 19:52:56 -05:00
[Bug]: No transactions detected in bank CSV export #2696
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/actual#2696
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @mpeter50 on GitHub (Dec 7, 2025).
Verified issue does not already exist?
What happened?
When I tried to import the CSV exported from my bank's site, AB says there are no transactions in it:
But if I look into the file, I see that there are 5 transactions in it, and a header row, fields separated by commas.
If I set the "skip start lines" to 1, AB says I cant skip more lines than there is, so maybe it cannot handle the line endings used?
According to the linux "file" command, the is a "Little-endian UTF-16 Unicode text, with very long lines".
I dont know how to tell what line endings it has though, because suprisingly its much harder than on windows.. no text editor I know can tell that to me.
Another problem could be that AB does not allow me to select the standard date format used in my country (YYYY.MM.DD), but that would be on top of the line detection issue. If it turns out to be an issue I'll open a separate issue for that.
How can we reproduce the issue?
Where are you hosting Actual?
Docker
What browsers are you seeing the problem on?
Firefox
Operating System
Linux
@mpeter50 commented on GitHub (Dec 7, 2025):
Forgot to mention: I run version 25.12.0, but before I updated from 25.7.1 it did not work either.
@mpeter50 commented on GitHub (Dec 7, 2025):
If I open it with KDE Kate and use "File > Save as with encoding" to save it as UTF-8, then AB will see all the transactions in the file.
@mpeter50 commented on GitHub (Dec 7, 2025):
But it seems if I select the YYYY-MM-DD date format, it recognizes the dotted version I have too, so thats nice.
@youngcw commented on GitHub (Dec 8, 2025):
We need an example file or there is nothing we can do
@mpeter50 commented on GitHub (Dec 9, 2025):
Is there a way I could send it privately?
I'll also try to just redact it, and if it still reproduces the issue I'll send it here.
@youngcw commented on GitHub (Dec 9, 2025):
You can redact it or also reduce it to just one or two transactions.
@mpeter50 commented on GitHub (Dec 9, 2025):
Here is a redacted version: bank.csv
It produces the same behavior in AB as with the original export.
@sublettk commented on GitHub (Dec 17, 2025):
Hi @mpeter50. I took a look at your issue. Thanks for sharing an example file. I was able to replicate what you were experiencing. The good news is that from my findings, that data inside your CSV file is not the issue. I converted your file from UTF-16 LE to UTF-8 and the dates map fine (although they would be converted from dot notation to the predefined date formats on Actual (e.g. 2025.12.01 → 12/01/2025)).
I looked at the code for Actual and it seems that the application only accepts UTF-8 encoded files. To unblock you in the mean time so that you can continue using the application while this is fixed, you can convert your UTF-16 files to UTF-8. If you are on Linux, you can use the terminal to run a command like this
iconv -f UTF-16 -t UTF-8 bank-utf16.csv > bank-utf8.csv. There are also websites that you can use to do this.In terms of implementing a solution for this, I am working on proposing a feature that automatically and seamlessly converts a UTF-16 file to UTF-8 during the file import process.
@mpeter50 commented on GitHub (Dec 17, 2025):
Thanks!
While we are at it, its probably the topic of a different issue, but does AB have a way to recognize CSV column names in other languages than english? It would be useful if that would work automatically, or if some of the last selections were remembered.
Actually in my case, my bank's CSV contains columns such that sometimes I want to use column A, and sometimes column B, because they are similar in nature but for some transactions one or the othher does not hold meaningful information.