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

[Paul Kroitor]

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