Existing transaction not being matched during import.

  • 2
  • Problem
  • Updated 7 months ago
  • Solved
I am trying to import transactions from a previous month. When I went to import the data, I noticed some transactions weren't being matched and I knew that I had already added them myself (from mobile, web, etc). So just to check, I went and searched for a couple and I found the existing transactions. I ensured that the transaction I was importing matched the account, the date, the name, and the amount exactly. So I'm not sure why it's not being matched. This is alarming though, because now I feel like I can't trust the import and that I'm going to be creating a bunch of duplicates. I have taken screen shots as well.

Any help on this matter would be much appreciated! Other than this issue I'm running into, the app has saved me a lot of time and money!
Photo of Matt H

Matt H

  • 3 Posts
  • 1 Reply Like

Posted 3 years ago

  • 2
Photo of Matt H

Matt H

  • 3 Posts
  • 1 Reply Like
So I just had a thought. Sometimes when I don't keep up with my transactions as they happen, I will log into my credit card company and download a "recent activity" csv file and import the trans that are still in the current open period. Then, before I reconcile, I will import the "closed" statement just to make sure I haven't missed any. Since that existing transaction may have come from a "different" csv file, will good budget consider it a unique or new transaction, thus skipping as an auto match candidate?
Photo of Karisa Russell

Karisa Russell, Official Rep

  • 1690 Posts
  • 217 Reply Likes
Hi Matt H, 

Sorry for the troubles! Transactions that you've already imported should not show up in the Existing Transactions column, because they've already been matched and imported. 

When you import a CSV file, Goodbudget assign each transaction a 'FITID' -- an identification number that's used to make sure that the same transaction isn't imported twice. It sounds like GB may be assigning different FITIDs to the same transaction. 

I can test that by looking at the last two CSV files that you tried to import. If you send those over to support@goodbudget.com, I'll be able to take a look. 

Thanks!
Photo of Kerrie Hawkins

Kerrie Hawkins

  • 1 Post
  • 0 Reply Likes
Help! I have the same problem. I have emailed above but no reply yet but it's urgent!
Photo of Karisa Russell

Karisa Russell, Official Rep

  • 1690 Posts
  • 217 Reply Likes
Hi Kerrie, 

Sorry for the troubles! We responded to your email last Friday. Be sure to check your spam folder in case our reply went there. 
Photo of bdavidlewis

bdavidlewis

  • 3 Posts
  • 0 Reply Likes
I'm having the same issue. When I try to import transactions from a csv, existing transactions in Goodbudget are not matching, so I will end up with tons of duplicates. I don't have time to manually check to see whether every single transaction I'm importing already exists in GB (plus that would kind of defeat the purpose of the import!).  Is there a way to fix this? It seems like based on the above thread it has to do with GB assigning different FITIDs to the same transaction, but as a user based on the comments above I have no control over that. Is there a process I can follow to ensure GB does not do that? I really appreciate your help but I have potential for this problem pretty regularly and I don't want to have to bug you to check my csv's every time!! Thank you!!! 
(Edited)
Photo of bdavidlewis

bdavidlewis

  • 3 Posts
  • 0 Reply Likes
Just to clarify, I'm only importing using CSVs not the OFX or anything else.
Photo of Karisa Russell

Karisa Russell, Official Rep

  • 1690 Posts
  • 217 Reply Likes
Hi bdavidlewis,

Thanks for posting, and sorry for the troubles! You're right that this might be a FITID issue. 

Transactions in your CSV file don't have FITIDs, and so Goodbudget will generate one based on your transactions Name, Date and Amount. However, if any of those pieces of information change between one file to another, Goodbudget won't recognize those transactions as already imported. 

I've seen this happen before when folks include pending transactions in their CSV download -- those transactions are the most likely to change from one file to another since they haven't officially cleared yet. That could be what's happening for you. And can you can minimize that happening by only downloading transactions that have cleared in your account. 

If that's not what's happening for you, send us an email so we can take a look! 

Thanks again
Photo of Matt H

Matt H

  • 3 Posts
  • 1 Reply Like
I'm glad this thread is being revisited.  I ended up just having to wait until my statements were closed for the given period so that when I imported that file into Good Budget, it will use the same ids from the same file.

I suppose another workaround could be that you have a single file that you keep using for the statement period and you'd have to manually "merge" items from your statement's "recent" activity to the one you're building.

However, I still think this is an issue that the Good Budget team should be able to fix.  As a software engineer, I would think that there could be an algorithm written such that if the date and amount matched up _exactly_ with an item that's already imported, it could at least suggest them as a potential match during import.  Currently, even though the amount, date (and in this case the description) match, if you try and import the charge from two seperate .csv files, they are interpreted as "different" for some reason.