github-starred/actual
2
0
Fork 0
mirror of https://github.com/actualbudget/actual.git synced 2026-05-11 01:18:59 -05:00
Code Issues 1.6k Packages Projects Releases 57 Wiki Activity

[GH-ISSUE #1524] [Bug]: OFX Import "Notes" & "Payee" Fields Switched #26362

New Issue
Closed
opened 2026-04-18 02:30:18 -05:00 by GiteaMirror · 8 comments
GiteaMirror commented 2026-04-18 02:30:18 -05:00
Owner
Copy Link

Originally created by @themadman0980 on GitHub (Aug 14, 2023).
Original GitHub issue: https://github.com/actualbudget/actual/issues/1524

Verified issue does not already exist?

  • I have searched and found no existing issue

What happened?

I have been happily using Actual for the last 8 months, and the OFX import tool has worked beautifully until now (first attempt in the last 3-4 weeks, so I'm assuming it's the new OFX importer).

Basically, the "Notes" and "Payee" fields have all been swapped, which is immensely painful and makes the import tool basically unusable. Below is an example of what I am seeing now, with all the purchase details in the payee field instead of notes. This means that every new transaction imported has a new payee, as every payment description is unique.

image

#521 seems like a related problem but I'm unsure what ended up happening.

FWIW I attempted to re-import some old OFX files that worked beautifully several months ago, and they're all exhibiting the same behaviour. This leads me to believe its not an issue with my bank's OFX export tool.

I'm currently running 23.8.1 using Docker and Google Chrome.

What error did you receive?

No response

Where are you hosting Actual?

Docker

What browsers are you seeing the problem on?

Chrome

Operating System

Mac OSX

Originally created by @themadman0980 on GitHub (Aug 14, 2023). Original GitHub issue: https://github.com/actualbudget/actual/issues/1524 ### Verified issue does not already exist? - [X] I have searched and found no existing issue ### What happened? I have been happily using Actual for the last 8 months, and the OFX import tool has worked beautifully until now (first attempt in the last 3-4 weeks, so I'm assuming it's the new OFX importer). Basically, the "Notes" and "Payee" fields have all been swapped, which is immensely painful and makes the import tool basically unusable. Below is an example of what I am seeing now, with all the purchase details in the payee field instead of notes. This means that every new transaction imported has a new payee, as every payment description is unique. ![image](https://github.com/actualbudget/actual/assets/107305060/5438d6d9-2ec1-455d-99cf-d69f5f11def0) #521 seems like a related problem but I'm unsure what ended up happening. FWIW I attempted to re-import some old OFX files that worked beautifully several months ago, and they're all exhibiting the same behaviour. This leads me to believe its not an issue with my bank's OFX export tool. I'm currently running 23.8.1 using Docker and Google Chrome. ### What error did you receive? _No response_ ### Where are you hosting Actual? Docker ### What browsers are you seeing the problem on? Chrome ### Operating System Mac OSX
GiteaMirror added the transaction importbug labels 2026-04-18 02:30:18 -05:00
GiteaMirror commented 2026-04-18 02:30:20 -05:00
Author
Owner
Copy Link

@MatissJanis commented on GitHub (Aug 14, 2023):

👋 Would you mind providing a redacted version of your OFX export? We really need a way to reproduce the issue in order to fix it.

<!-- gh-comment-id:1677955113 --> @MatissJanis commented on GitHub (Aug 14, 2023): 👋 Would you mind providing a redacted version of your OFX export? We really need a way to reproduce the issue in order to fix it.
GiteaMirror commented 2026-04-18 02:30:21 -05:00
Author
Owner
Copy Link

@themadman0980 commented on GitHub (Aug 14, 2023):

Here's a sample file I've exported from my bank that I've confirmed has the issue on my current setup.

OFXData-Sample.zip

I can't see any personal info here, but please let me know if there's any issues.

<!-- gh-comment-id:1678100476 --> @themadman0980 commented on GitHub (Aug 14, 2023): Here's a sample file I've exported from my bank that I've confirmed has the issue on my current setup. [OFXData-Sample.zip](https://github.com/actualbudget/actual/files/12339733/OFXData-Sample.zip) I can't see any personal info here, but please let me know if there's any issues.
GiteaMirror commented 2026-04-18 02:30:21 -05:00
Author
Owner
Copy Link

@joel-jeremy commented on GitHub (Aug 15, 2023):

The way the ofx importer is implemented right now is that is checks first if the ofx transaction has a NAME field and use that as the payee. Otherwise, it will use the MEMO as the payee.

Banks do not generate the ofx file the same. Some banks populate the NAME field with the name of the payee but others just use the MEMO field with the transaction details. In your case, it is the latter.

I think one possible solution is just put the MEMO in the Notes field and provide a way to easily create a rule inside the import modal so that users can easily create a rule to populate the Payee based on the Notes e.g.

image

<!-- gh-comment-id:1679417928 --> @joel-jeremy commented on GitHub (Aug 15, 2023): The way the ofx importer is implemented right now is that is checks first if the ofx transaction has a `NAME` field and use that as the payee. Otherwise, it will use the `MEMO` as the payee. Banks do not generate the ofx file the same. Some banks populate the `NAME` field with the name of the payee but others just use the `MEMO` field with the transaction details. In your case, it is the latter. I think one possible solution is just put the `MEMO` in the Notes field and provide a way to easily create a rule inside the import modal so that users can easily create a rule to populate the Payee based on the Notes e.g. ![image](https://github.com/actualbudget/actual/assets/20313680/18b557b2-1e51-4c18-a59a-c192c347d499)
GiteaMirror commented 2026-04-18 02:30:23 -05:00
Author
Owner
Copy Link

@themadman0980 commented on GitHub (Aug 15, 2023):

Yeah, that sounds like exactly what used to happen tbh. Thanks for following up!

<!-- gh-comment-id:1679616759 --> @themadman0980 commented on GitHub (Aug 15, 2023): Yeah, that sounds like exactly what used to happen tbh. Thanks for following up!
GiteaMirror commented 2026-04-18 02:30:24 -05:00
Author
Owner
Copy Link

@themadman0980 commented on GitHub (Aug 23, 2023):

This issue seems to be derived from the outcome of #1268.

<!-- gh-comment-id:1689653758 --> @themadman0980 commented on GitHub (Aug 23, 2023): This issue seems to be derived from the outcome of #1268.
GiteaMirror commented 2026-04-18 02:30:25 -05:00
Author
Owner
Copy Link

@Shazib commented on GitHub (Aug 24, 2023):

In this case the memo field seems to be some hybrid of the payee and some other notes. I guess we need a flag/option for the user to be able to use memo as payee optionally. @themadman0980

I will look this weekend if I can implement this - alternatively we could unwind #1268 as a regression in the interim @MatissJanis?

<!-- gh-comment-id:1692498555 --> @Shazib commented on GitHub (Aug 24, 2023): In this case the memo field seems to be some hybrid of the payee and some other notes. I guess we need a flag/option for the user to be able to use memo as payee optionally. @themadman0980 I will look this weekend if I can implement this - alternatively we could unwind #1268 as a regression in the interim @MatissJanis?
GiteaMirror commented 2026-04-18 02:30:26 -05:00
Author
Owner
Copy Link

@MatissJanis commented on GitHub (Aug 25, 2023):

I will look this weekend if I can implement this - alternatively we could unwind #1268 as a regression in the interim @MatissJanis?

I would prefer not to rollback. If we did that, then another group of people would start reporting bug reports about the inverse problem. Lets just try to patch this issue for the next release. If you don't have time this weekend, then I'll try to take a look at it next week.

<!-- gh-comment-id:1692920011 --> @MatissJanis commented on GitHub (Aug 25, 2023): > I will look this weekend if I can implement this - alternatively we could unwind #1268 as a regression in the interim @MatissJanis? I would prefer not to rollback. If we did that, then another group of people would start reporting bug reports about the inverse problem. Lets just try to patch this issue for the next release. If you don't have time this weekend, then I'll try to take a look at it next week.
GiteaMirror commented 2026-04-18 02:30:27 -05:00
Author
Owner
Copy Link

@MatissJanis commented on GitHub (Sep 1, 2023):

Fix: https://github.com/actualbudget/actual/pull/1631

Would appreciate some testing from you @themadman0980

<!-- gh-comment-id:1703146027 --> @MatissJanis commented on GitHub (Sep 1, 2023): Fix: https://github.com/actualbudget/actual/pull/1631 Would appreciate some testing from you @themadman0980
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
AI generated
API
bank sync
budgeting
bug
can’t replicate
dependencies
docker
documentation
electron
experimental feature
feature
feedback
goal templates
good first issue
help wanted
importers
maintenance
needs info
needs testing
needs triage
needs votes
openid
payees
pull-request
Mirrored from GitHub Pull Request
 regression
reports
responsive
rules
schedules
server
✨ merged
split transactions
tech debt
theme
transaction import
transaction reconciliation
transactions
translations
upstream
user interface
✅ approved
wontfix
No Label bug transaction import
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/actual#26362
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?