[GNC] Any resolution to the 'red flagged' transactions on batch import problem?

[Paul Kroitor]

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 <paul at kroitor.ca> 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
>     >> gnucash-user at gnucash.org
>     >> 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
>     > gnucash-user at gnucash.org
>     > 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
>     gnucash-user at gnucash.org
>     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