[Bug]: Experimental OFX Parser: XML entities aren't parsed #713

New Issue

2026-02-28T19:14:45-06:00

GiteaMirror commented

2026-02-28 19:14:45 -06:00

Originally created by @Bryce-MW on GitHub (Nov 7, 2023).

Originally assigned to: @twk3 on GitHub.

Verified issue does not already exist?

I have searched and found no existing issue

What happened?

I import transactions from my banks and credit cards using OFX/QFX. Sometimes payees or memos contain XML entities, often ampersand (as &) but I have at least one that uses angle brackets which are double encoded, showing up at &lt; and &gt;. The double encoding is definitely an issue with my bank since it shows up in the actual qfx file but is displayed properly on their online interface. I have seen the ampersand on multiple banks but not less or greater than signs so I don't know if the double encoding is exclusive to my bank. Unless other people have also encountered the double encoding, I think just doing one round of decoding would be a reasonable idea.

As far as I know, there is no built in way to do the decoding. There is a hacky way that creates a hidden textfield, puts the text in there, and reads it back out, or you can use a library. I'm currently working on another PR but if no one claims this by the time I'm done, I'll work on it.

Here's a zip file containing a qfx file where I have included a couple real entries with those entities that I mentioned. I just changed the amounts.
example.zip

What error did you receive?

No response

Where are you hosting Actual?

Locally via Yarn

What browsers are you seeing the problem on?

Firefox

Operating System

Linux

Originally created by @Bryce-MW on GitHub (Nov 7, 2023). Originally assigned to: @twk3 on GitHub. ### Verified issue does not already exist? - [X] I have searched and found no existing issue ### What happened? I import transactions from my banks and credit cards using OFX/QFX. Sometimes payees or memos contain XML entities, often ampersand (as `&`) but I have at least one that uses angle brackets which are double encoded, showing up at `&lt;` and `&gt;`. The double encoding is definitely an issue with my bank since it shows up in the actual qfx file but is displayed properly on their online interface. I have seen the ampersand on multiple banks but not less or greater than signs so I don't know if the double encoding is exclusive to my bank. Unless other people have also encountered the double encoding, I think just doing one round of decoding would be a reasonable idea. As far as I know, there is no built in way to do the decoding. There is a hacky way that creates a hidden textfield, puts the text in there, and reads it back out, or you can use a library. I'm currently working on another PR but if no one claims this by the time I'm done, I'll work on it. Here's a zip file containing a qfx file where I have included a couple real entries with those entities that I mentioned. I just changed the amounts. [example.zip](https://github.com/actualbudget/actual/files/13284878/example.zip) ### What error did you receive? _No response_ ### Where are you hosting Actual? Locally via Yarn ### What browsers are you seeing the problem on? Firefox ### Operating System Linux

GiteaMirror added the transaction import experimental feature bug labels 2026-02-28 19:14:45 -06:00

GiteaMirror closed this issue

2026-02-28 19:14:45 -06:00

GiteaMirror commented

2026-02-28 19:14:45 -06:00

@twk3 commented on GitHub (Feb 16, 2024):

@Bryce-MW fix prepared in https://github.com/actualbudget/actual/pull/2364

I happened to also fix the double escaping because it just ends up being a matter of the order you handle the ampersand replacement in.

@twk3 commented on GitHub (Feb 16, 2024): @Bryce-MW fix prepared in https://github.com/actualbudget/actual/pull/2364 I happened to also fix the double escaping because it just ends up being a matter of the order you handle the ampersand replacement in.