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
_______________________________________________
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.
