[GNC] Any resolution to the 'red flagged' transactions on batch import problem?
Paul Kroitor
paul at kroitor.ca
Mon Sep 7 19:31:59 EDT 2026
I see that my reply to this didn't go to the list -- apologies for this
as it's a result of the opaque Reply All functionality when using an
iPad. Below is what I replied a couple of days ago.
However, before I get to that, I should say that I've done quite a bit
of additional testing and have learned a number of things. I'm a bit
torn as to whether to continue here or move it to the dev list as it
gets a bit technical. But the points apply to users too, so I'll keep it
here until someone tells me to move it to the dev list.
===
Here's the earlier missing reply:
Thanks, that’s a big help, although not the specific message I remembered. It was something regarding enabling a debug log that showed that resulting evaluations.
One question that maybe the cause of the confusion: is it the case that a transaction that falls inside the autoclear threshold will show as green, but if the same transaction is outside the autoclear threshold, it will be red?
What confuses me is that, in my “failure mode demonstration”, in case A (exactly matching dates), it shows green and proposes a counter-account. In case B, only one day off, it shows red, and fills in nothing. BUT, the instant I click “c”, it finds the match, proposes the counter-account and behaves like case A.
So it*does* actually know what it’s supposed to match. It’s like it knows what it should do but holds back until you give it the go-ahead.
(although this still wouldn’t explain the lack of auto-clearing when there’s a single day difference)
Sent from my iPad
====
I will send a separate message with my most recent discoveries.
Paul
On 2026-09-05 4:18 p.m., Sherlock wrote:
> 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 <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
>
> _______________________________________________
> 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.
More information about the gnucash-user
mailing list