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.
On Fri, Sep 4, 2026 at 7:28 PM Paul Kroitor <[email protected]> wrote:
I have gone back and pulled out the various versions of the
implicated
gnucash, log, and QFX files and put copies in a folder for repeat
testing
Repetition of the events show that what's happening is:
Early Sep 1st: 9 scheduled transactions in the account,
originating from
scheduled transactions. ALL ARE DATED SEP 1 and have status "n"
After bank gyrations, download and import QFX: six transactions
come in
from bank, five match date and amount and show in green with
action "c".
One is a wildly different amount than prediction, and shows yellow.
(so far operating as expected)
Early Sep 2nd: 3 scheduled transactions remain status "n" (still
dated
Sep 1). Six more transactions (dated Sep 2) arrive in QFX, three
should
match the three 'n' ones that didn't arrive on Sep 1 -- BUT they
show RED*.
===========
The only difference I can detect between the six that got handled
"properly" on the 1st and the three that didn't on the 2nd is that
the
download and transaction dates in the second group were the 2nd (1
day
off the transaction created by the scheduler), whereas in the first
batch the Gnucash transaction date, the QFX transaction date, and the
download date all matched as Sep 1.
In fact, if I change the date of the predicted transactions to the
2nd,
they get imported as green with action "C".
However, my "Import > Likely match day threshold" is set to the
default
(4), and other settings (2 or 6) don't change the behaviour.
So the question stands: why is the importer marking almost identical
situations in two different ways (red vs green)? The one day
difference
is supposed to be easily tolerated by the matcher, no?
Thanks as always, Paul
PS: I have my test environment intact here in case anyone wants to
suggests various setting permutations for me to try.
* There are also three new unrelated which (correctly) show as green
with action "A" checked. I mention this only for completeness.
On 2026-09-03 1:02 p.m., Paul Kroitor wrote:
> 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've changed my process a little here and now have more (about 10)
> scheduled transactions auto-created at the start of each month.
> They're set to auto-create 7 days beforehand, so around the
23rd, with
> all the transaction dates normally expected to occur on the 1st.
>
> This month, four or five of them went through the bank and got
> downloaded on the first, and those (correctly) showed green in the
> importer. But two went through the next day, and those
(unexpectedly)
> appeared red. As always, when I checked "C", they became green and
> imported correctly like the prior ones. Very strange.
>
> I can't recall the exact details: for example, did the red ones
> actually go through the bank on the 1st but get downloaded on the
> second? There are numerous other minor details that could be
different
> between the two groups of transactions.
>
> But something is very definitely resulting in very similar close
match
> situations getting imported differently: some are turning green,
and
> others red, in cases that at first blush are nearly identical. I
will
> pay closer attention next month and try to identify what the actual
> differences are.
>
> Paul
>
> On 2026-08-21 7:26 p.m., Stephen M. Butler wrote:
>> On 8/21/26 12:04, Kalpesh Patel wrote:
>>> Hmm, I have not encountered red colored transaction that is very
>>> good match (case 2) in six plus years of importing both CSV and
>>> OFX/QFX files. I would have thought that it would set "C" and
show
>>> green but I guess possibility is there for CSV import. Have you
>>> encountered as such in imports?
>>
>> Yes.
>>
>> I saw the match about 10 lines up in the import list. I
clicked the
>> option to go ahead and import it.
>> _______________________________________________
>> 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.
--
David Carlson
_______________________________________________
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.
