Hi Paul,

You may be recalling one of my posts: https://lists.gnucash.org/pipermail/gnucash-user/2025-August/117213.html

Regards,

Sherlock

On 9/5/26 11:30 AM, Paul Kroitor 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.

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.

Reply via email to