[GNC] Any resolution to the 'red flagged' transactions on batch import problem?
Sherlock
sh025622 at gmail.com
Sat Sep 5 16:18:58 EDT 2026
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
More information about the gnucash-user
mailing list