[GNC] Any resolution to the 'red flagged' transactions on batch import problem?

[John Ralls]

Paul,

It seems to me that the matcher is behaving exactly as designed and documented. The documentation for the import status indicators for red says "Transaction has poor matches and no action was set: – Not to be imported. Intervention required.” (https://www.gnucash.org/docs/v5/C/gnucash-manual/trans-import.html#match_status). In other words GnuCash doesn’t know whether you want to add the imported transaction as new (check the A box), select one of the not-good-enough matches that GnuCash found (check the C box), or ignore it as already cleared and reconciled (check nothing) and it colors the row red so that you know it needs help.

In order for a substring matcher to find a match between "DO SYNDICATE          202624507365BWNEV” and “Sep” would require telling it that if any one letter matches between the two strings that’s good enough; for "[CW]INTERAC ETRNSFR SENT     CON” and "Condo Syndicate” the threshold would be a sequence of 3 letters. Either of those would produce so many false matches as to be utterly useless. It seems unlikely to me that Quicken would consider those matches. GnuCash already depends on International Components for Unicode which has a string search service (https://unicode-org.github.io/icu/userguide/collation/string-search.html). We can discuss what would be reasonable matching criteria and how much of a performance hit would be worth the higher match score if anyone is interested in that.

If a close (the default is ±4 days) date and exact amount match is enough for you to let GnuCash auto-clear the transaction then lowering the auto-clear threshold to 5 does that for you.

Regards,
John Ralls

> On Sep 8, 2026, at 8:25 AM, Paul Kroitor <paul at kroitor.ca> wrote:
> 
> I've concluded that my last supposition was correct: the match probability of the transactions at issue was so fragile that the single issue of being one day late causes the match to fail.
> 
> This is caused by the Description and Memo fields being so different in the two elements that they aren't counted as contributing factors (even though to a human, they would be a match), and there being no cheque number to match either. The result is the only matching elements are the amount and a close-but-no-cigar date, which just isn't enough.
> 
> It's aggravated by the forget-about-it philosophy of the import matcher where a non-match hides the existence of nearly-but-not-quite matches (I understand and mostly support this choice, and now I know about it, I can take it into account).
> 
> I've lowered the auto-clear threshold, which resolves my problem, but I'll have to see if it introduces others.
> 
> A couple of closing thoughts....
> 
> Gnucash doesn't have an import map the way Quicken does which would massage the incoming transactions to look closer to the way I keep my registers (eg. "[CW]INTERAC ETRNSFR SENT    CON" becomes "Condo Syndicate"). This would be lovely to have, but it's a big project to add into Gnucash.
> 
> A second best alternative might be a simple python thing to do it manually beforehand. It could be added to the context menu to allow right-clicking on QFX files to pre-massage my import data. Or one might consider an optional preprocess script being automatically called by all the gnucash import functions.
> 
> <end of Paul's adventures in gnucash-importland :-) >
> 
> 
> On 2026-09-07 8:08 p.m., Paul Kroitor wrote:
>> Some discoveries:
>> 
>> 1. The way to see the match weightings (on Windows) is to start gnucash from the command prompt as follows:
>> 
>> "C:\Program Files (x86)\gnucash\bin\gnucash.exe" --debug --log "gnc.import=debug"
>> 
>> (many of you may have known this, but credit to Gemini for telling me)
>> 
>> 2. Two aspects that greatly add to the general unhappiness are that:
>> 
>> A) when a potential match falls below the threshold, it shows red but it ALSO hides the entire possible match subtree (the ">" and the ability to expand it). Interestingly, if one simply checks the "C" column, the subtree and its indicator appear. So it's there, just hidden.
>> 
>> B) the description and memo texts from my scheduled transactions are nice and clean (eg. "Condo Syndicate" and "Sep") whereas the text coming in from the QFX is garish ("[CW]INTERAC ETRNSFR SENT  CON" and "DO SYNDICATE          202624507365BWNEV"). These are total non-matches from the matcher's point of view*.
>> 
>> 3. Here are the match logs for two nearly identical transactions in my test. The only difference is that the first (for $585) pre-exists in the register on Sep 1st, whereas the second (for $330) is in the register as Sep 2nd. Both are in the QFX file for the 2nd. The first is rejected (red and no expandable list of possible matches), the second shows green and gets an expandable section showing the match data.
>> 
>> ------------
>> 
>>  downloaded_split_amount=-585.000000
>>  match_split_amount=-585.000000
>> heuristics:  probability + 3 (amount)
>> Date download: 2026-09-02 vs match: 2026-09-01
>> diff day 1
>> heuristics:  probability + 2 (date)
>> number download: '' to match: ''
>> memo download: 'DO SYNDICATE          20262450737VMDHNH' to match: 'Sep'
>> description: download: '[CW]INTERAC ETRNSFR SENT     CON' to match: 'Condo Syndicate'
>> Added to list of possible matches: 5
>> ------------------
>>  downloaded_split_amount=-330.000000
>>  match_split_amount=-330.000000
>> heuristics:  probability + 3 (amount)
>> Date download: 2026-09-02 vs match: 2026-09-02
>> diff day 0
>> heuristics:  probability + 3 (date)
>> number download: '' to match: ''
>> memo download: 'DO SYNDICATE          202624507365BWNEV' to match: 'Sep'
>> description: download: '[CW]INTERAC ETRNSFR SENT     CON' to match: 'Condo Syndicate'
>> Added to list of possible matches: 6
>> ---------------
>> 
>> All these evaluations seem to make sense to me. The first is understandably given a lower date match score (2 vs 3). So my current avenue is to check my theory that a total score of 5 vs a 6 is the exact border that defines the reject / accept boundary.
>> 
>> Paul
>> 
>> * perhaps someone knows of a comparison function in one of the existing dependencies (boost?) that is smart enough to score these two very different strings as "partially similar"?
>> 
>> 
>> 
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at 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.