Thanks very much John, but I fear you're not replying to anywhere near
the most recent message in the thread.
Do not see anything more recent?
(the last one I sent was Sept 8th at 15:25 UTC)
Paul
On 2026-09-11 4:49 p.m., John Ralls wrote:
I’m not sure if this is what you mean. The import backend is pretty well
instrumented with debug logging, so if you run GnuCash from the command line
with `—log gnc.import=debug` it will write (among other things, it’s quite
verbose) a message for every probability adjustment and the conclusion (either
“below threshold” or “Added to list of possible matches”) for every imported
transaction and existing transaction pair. That’s n x m, so if there are a lot
of transactions imported and a lot to check the number of message will be quite
large. The existing transactions considered are everything in the account 42
days before the first date in the import and 42 days after the last. If the
account is very active that can obviously be a lot of pairs to check even if
there are only one or two imported transactions. To keep it manageable I
suggest doing an import and leaving two or three unmatched transactions as-is,
noting which ones they are. Save and quit then edit out all but those two or
three transactions from a copy of the import file. Restart GnuCash with —log
gnc.import=debug and import the reduced copy. You can force the import of the
transactions or not as you please. After you quit GnuCash examine the debug
messages to see why the import transactions didn’t match anything.
Regards,
John Ralls
On Sep 5, 2026, at 11:30 AM, Paul Kroitor <[email protected]> wrote:
I fear we're a little at cross purposes here. I am aware of and concur with
your explanation, as I've used it extensively for years. But the matcher has
always been (IMHO) a little flaky -- nowhere near as good as eg Quicken -- and,
although it mildly annoyed me, I knew its quirks and could live with it.
This current thread was introduced by someone complaining about one particular quirk:
that a "red" transaction seemed (to them) to occur in two opposite cases: one
where the transaction didn't match anything, the other where it matched everything.
Several here denied that this was the case, and I shared that position.
I chimed in to point out that my position has now changed ("Until now, I've been
entirely in agreement with this sentiment, but as a result of this discussion I've been
keeping an eye on the issue, and now concur with OP that something is fishy.")
I have found a very specific example where the matcher should have zero trouble
matching incoming and scheduled transactions, but it doesn't. This isn't a
boundary case. It's something it absolutely should match. I could write it up
as a bug right now, but I'm hoping for some elucidation on narrowing the cause
down before doing so. At a minimum I will simplify the situation by creating a
blank Gnucash file and removing all but the offending transactions from the QFX
file.
I recall that there's some way of tracking the "match points" that contribute
to a potential match's score, but can't find it any more. Does anyone remember this
mechanism?
Thanks for all help as always, Paul
On 2026-09-04 11:48 p.m., David Carlson wrote:
The transaction matcher is only making an educated guess. It will never be
perfect. If it were perfect, there wouldn't be a need for that step in the
import procedure. The documentation does make some suggestions that may improve
results with some users and some financial institutions giving better or worse
results. It can't possibly be better for everyone.
_______________________________________________
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.
