Gyle, The import matcher works with a number of settable parameters (Edit- >Preferences->Import. The default values of these may not be suitable for your specific cases. A problem I have encountered with one supplier is that my bank include sa unique identifier number from the vendor in the description provided by the bank of the transaction and this is sufficient for the transaction not to be matched at all even though it is a monthly transaction with the same amount and the description includes the vendor's name.
The matching process calculates a probability score from tokenized information. but the date information's score is determined by the relationship of the date to the "Likely matched day threshold" (default 4 days) and the "Unlikely matched day threshold" (default 14 days). Changing these carefully can improve the performance. A transaction which is within the 14 day window will likely be matched if there is no other higher scoring transaction. That it is reconciled is not material. Most of us will configure our downloads from the bank so that there is no overlap in the date range with previously imported data, but there is no reason the program should assume that we are that meticulous and it is useful that it flags items which might be a match. That is why the display threshold is 1. Whether the transaction is then flagged for adding as a not previously imported transaction is set by whether the score is below the Auto-add threshold. If its score is between the Auto-add threshold it is marked for Update and inofromation which is different in the import record from the matched record is updated. Ff the score is above the Auto- clear threshold it is marked as cleared and nothing is changed apart from that. You could try making the two date thresholds a bit tighter and experiment with changing the thresholds using a test copy of your books. That said the matcher is never going to give perfect results every and all the time. I only regard it as a useful flag of which transactions I need to pay more attention to. I still check what action the matcher has selected and which account has been assigned. Generally ~80% of my transactions import without me having to change the matcher information or the account assigned. this is a separate process from matching existing transactions using Bayesian stats to determine which is the most likely account. David Cousens On Thu, 2024-04-11 at 23:36 +0000, Gyle McCollam wrote: > Back on 3/11 I sent 2 emails about issues with imports. Neither > received any responses. This month when I imported the CSV file I > had the following issues: > > > 1. > There were many receipts from the same vendor. It matched the 1st to > an entry that was already reconciled, which to me doesn't make sense, > am I wrong? Every entry after that was then matched to an earlier > transaction. I was able to change these to the correct transaction. > BTW they all had the same value or $ amount that is why they > matched. If the 1st had not been matched to a reconciled transaction > they would have all been OK this month. > 2. > When importing an OFX/QFX file you have the option to reconcile after > matching, but in the case of a CSV import, it does not give you that > option. Is there a logical reason why not? > > > Thank You, > > Gyle McCollam > > Gyle McCollam > > gmccol...@live.com<mailto:gmccol...@gyleshomes.com> email > _______________________________________________ > gnucash-user mailing list > gnucash-user@gnucash.org > To update your subscription preferences or to unsubscribe: > https://lists.gnucash.org/mailman/listinfo/gnucash-user > ----- > Please remember to CC this list on all your replies. > You can do this by using Reply-To-List or Reply-All. _______________________________________________ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
