You mean similar transactions in the same import? Those matches aren't added to the list until you press OK on the matcher, so the matcher can't see them. 

That aside, IMO searching for a match would be more cumbersome than simply selecting the account.

Actually my example for today is an existing deposit transaction that originated from a scheduled transaction entered about a month in advance that was not found when the OFX file from the bank reported the actual deposit for the identical amount within 3 or 4 days of the projected deposit, and having a very different description but several matching ascii characters suggested a fuzzy match.  In this case the main underlying transfer account is buried somewhere among many investment accounts and since it could not be matched to the transaction, there was no way to make a Bayesian example for next year.  Also, it is actually a six or seven line split with sales, cap gains, tax withholding, etc.  It happened that the same deposit transaction was in two different OFX files with overlapping date ranges,  Since I had deleted the first imported transaction, the second import tried again to import the same deposit, again without finding the existing transaction which now had the same date.

If a manual search started in the register at the transaction date in the import, and I think that there is a missing match, it would probably be in close time proximity.  Also, if there is more than one account in the import, it should start in the same account as the imported transaction.  This should then trigger the Bayesian teaching for future imports.

Back to duplicates in the same import file, I see a lot of those in transfers between the different accounts in the same file.  It would be nice if those were matched, but it is far easier to find those duplicates later because the Bayesian matching usually puts them right together in both the affected accounts and leaves one of the two account splits un-reconciled.  I think there is a feature request elsewhere to improve handling of those.

You do understand that the matcher doesn't search the transactions, it searches a separate record of previous matches, right? That means that even if you have a hundred manually entered transactions with exactly the same description, account, and amount, importing an exact copy won't match because the importer hasn't seen that transaction before.

The Bayesian matcher tokens are strings, not single characters, and the input is the Description and Memo fields, and *only* those fields.

Each account has its own set of tokens. The account that gets its tokens is the account thats bound to the "remote" account, meaning that if you have Assets:Bank:USAA Savings and import transactions from a download for the corresponding account from USAA then the matches apply to that USAA Savings account. If you have another account, just to keep it military we'll say NFCU, and you import transactions into that account it won't look at the USAA matches, only at earlier matches into NFCU.

So is this "not a bug" or an "enhancement request"?

From the Help manual there are settings:

Use Bayesian matching: Use Bayesian algorithms to match new transactions with existing accounts.

Match display threshold: The minimal score a potential match must have to be displayed in the match list.

Auto-add threshold: A transaction whose best match’s score is in the red zone (above display threshold, but below or equal to Auto-add threshold) will be added by default.

Auto-clear threshold: A transaction whose best match’s score is in the green zone (above or equal to Auto-clear threshold) will be cleared by default.


What is not explained there is that the 'color' seems to make it impossible to see a list of similar existing transactions if an incoming transaction is the wrong 'color' which is not a Bayesian criterion.  The problem is that sometimes the 'color' match is not correct.
Some colors can be manually changed, but if there are no 'Bars' there is no way to get to similar amount and date lists or to fix cases where a similar amount and date are not found.

A per transaction manual toggle to choose between selecting the 'other' account or selecting from a list of similar transactions would solve most of these cases.

If the 'color' matcher only searched a subset of transactions previously imported and excluded transactions that were manually entered or entered by SX, even by some possibly hidden and indirect characteristic that rarely if ever gets set when a transaction is manually created, that, IMHO, is a bug.  For example, the unique identifier from the FI is only set in transactions that were created by OFX import.  Thus, as I mentioned in comment 2, it is possible (and desirable) to delete a previously imported transaction and import it again.

I think that the 'color' matcher should only look at dates and amounts for the particular transaction account (defined by a criteria that remains correct if the account name has recently been changed) and no other criteria.

OK, I think I understand. You mean the duplicate transaction matcher doesn't always find transactions that you think it should and you want a way to manually search for existing transactions. Is that right?

> A per transaction manual toggle to choose between selecting the 'other' account or 
> selecting from a list of similar transactions would solve most of these cases.

That already exists: Tick the 'U+R' box. If it's checked, double-clicking the matcher entry brings up the match-transaction dialog; if it's not, double-clicking brings up the account picker. 

If the duplicate transaction matcher didn't find anything, the match transaction dialog will have an empty list, so it doesn't actually do you any good.

This is still an issue for me.  One recent example is a transaction that repeats every month with different amounts.  I have used a scheduled transaction to enter an estimated amount and now when importing transactions the matcher fails to find the existing transaction where I want to correct the amount.  Using the U+R cannot find it.  I know that it is there but there is no way during the import to find and update the transaction so the transaction can be matched.

New, but closely related problem.

Now that zero dollar transactions do not need a destination account, a newly imported zero dollar transaction cannot be matched to existing transactions or assigned to a transfer account if desired.  Curiously, there are bars showing that there is something found, but it cannot be checked to see if it is a match.

I will take another stab at trying to describe this issue.  Sometimes a new OFX  import file contains a transaction that has not been imported previously but is known to be similar to an existing transaction that was either manually entered or created by a SX does not get associated to that transaction as a possible match by the importer.

Then it is impossible to tell the importer that I want to manually match the incoming transaction to some other existing transaction that was not in that list.

I think John came close in comment 5 but then he stated "If the duplicate transaction matcher didn't find anything, the match transaction dialog will have an empty list, so it doesn't actually do you any good." which is what I am asking to change.

Ok, to re-summarize (it's actually not really documented), there are two very different matching processes the matcher does:

1- Finding in which account to send the other split of a new transaction.  This uses the bayesian matcher, which is only trained on the strings of previously imported transactions.  The fact that it only uses the original strings isn'T as much of a problem as one might think.  A bigger problem is that it cannot be retrained if you subsequently reorganize your accounts or transactions.


2- Finding duplicate transactions.  The bayesian matcher isn't involved in this process at all.   It basically only the unique id (if present), check number, date and amount and some primitive exact substring matching on memo and description.  

What you seem to want is to remove/lessen the restrictions on the amount.  This was a completely unanticipated need.  You can increase  the "Commercial ATM fees threshold" in the importer preferences to be above your typical estimation error.  That may be enough to make the transactions appear in the matcher.  But to cover your case, we'd need more granular use of the amount.  The matcher uses only 3 levels for amounts.  Exact match: +3, Match within the Atm fee threshold +2, Outside that range -5.  Dont set the fee to more than your typical max error, otherwise all the matcher will have left to work with in your case is the date.

Another improvement that would help you is if we were to use proper similarity matching on the strings (since you enter the strings manually).  But that's a separate issue.

An alternative to fiddling with the amount matcher might be to have an option to present all transactions in a date range.

GnuCash bug tracking has moved to a new Bugzilla host. The new URL for this bug is https://bugs.gnucash.org/show_bug.cgi?id=776636. Please continue processing the bug there and please update any external references or bookmarks.