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
[email protected]
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.
