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

[Paul Kroitor]

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"?


On 2026-09-07 7:31 p.m., Paul Kroitor wrote:
> I see that my reply to this didn't go to the list -- apologies for 
> this as it's a result of the opaque Reply All functionality when using 
> an iPad. Below is what I replied a couple of days ago.
>
> However, before I get to that, I should say that I've done quite a bit 
> of additional testing and have learned a number of things. I'm a bit 
> torn as to whether to continue here or move it to the dev list as it 
> gets a bit technical. But the points apply to users too, so I'll keep 
> it here until someone tells me to move it to the dev list.
>
> ===
>
> Here's the earlier missing reply:
>
> Thanks, that’s a big help, although not the specific message I 
> remembered. It was something regarding enabling a debug log that 
> showed that resulting evaluations.
>
> One question that maybe the cause of the confusion: is it the case 
> that a transaction that falls inside the autoclear threshold will show 
> as green, but if the same transaction is outside the autoclear 
> threshold, it will be red?
>
> What confuses me is that, in my “failure mode demonstration”, in case 
> A (exactly matching dates), it shows green and proposes a 
> counter-account. In case B, only one day off, it shows red, and fills 
> in nothing. BUT, the instant I click “c”, it finds the match, proposes 
> the counter-account and behaves like case A.
>
> So it*does* actually know what it’s supposed to match. It’s like it 
> knows what it should do but holds back until you give it the go-ahead.
>
> (although this still wouldn’t explain the lack of auto-clearing when 
> there’s a single day difference)
>
> Sent from my iPad
>
> ====
>
> I will send a separate message with my most recent discoveries.
>
> Paul
>
>
> On 2026-09-05 4:18 p.m., Sherlock wrote:
>> Hi Paul,
>>
>> You may be recalling one of my posts: 
>> https://lists.gnucash.org/pipermail/gnucash-user/2025-August/117213.html
>>
>> Regards,
>>
>> Sherlock
>>