Thanks John, I concur with your analysis and don't intend to take it any
further.
IIRC Quicken *does* deal well with this scenario because it uses a
two-step process:
Firstly the import mapper automatically changes "[CW]INTERAC ETRNSFR
SENT CON” to "Condo Syndicate". This because the first time this manual
correction was performed, it asked if I would always like this to be
changed (actually one clicks the relevant words, so one creates a rule
equivalent to if ("INTERAC" in Desc and "SENT" in Desc and "CON" in
Desc) then Desc = "Condo Syndicate" -- but all in a user-friendly way).
These mapping rules run every import for all transactions, similar to
incoming message handling rules in an email client.
Secondly, the a match process similar to Gnucash occurs, but using the
remapped Desc rather than the original.
Quicken does not do anything with the Memo field, which is an annoyance,
especially for banks like mine that split their description over two
fields in QFX.
(at least all the above is my recollection -- I could be misremembering)
Anyway, thanks for your help, Paul
On 2026-09-12 3:41 p.m., John Ralls wrote:
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<[email protected]> 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
[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.
_______________________________________________
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.
_______________________________________________
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.
