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

[Paul Kroitor]

Thanks very much John, but I fear you're not replying to anywhere near 
the most recent message in the thread.

Do not see anything more recent?

(the last one I sent was Sept 8th at 15:25 UTC)

Paul

On 2026-09-11 4:49 p.m., John Ralls wrote:
> I’m not sure if this is what you mean. The import backend is pretty well instrumented with debug logging, so if you run GnuCash from the command line with `—log gnc.import=debug` it will write (among other things, it’s quite verbose) a message for every probability adjustment and the conclusion (either “below threshold” or “Added to list of possible matches”) for every imported transaction and existing transaction pair. That’s n x m, so if there are a lot of transactions imported and a lot to check the number of message will be quite large. The existing transactions considered are everything in the account 42 days before the first date in the import and 42 days after the last. If the account is very active that can obviously be a lot of pairs to check even if there are only one or two imported transactions. To keep it manageable I suggest doing an import and leaving two or three unmatched transactions as-is, noting which ones they are. Save and quit then edit out all but those two or three transactions from a copy of the import file. Restart GnuCash with —log gnc.import=debug and import the reduced copy. You can force the import of the transactions or not as you please. After you quit GnuCash examine the debug messages to see why the import transactions didn’t match anything.
>
> Regards,
> John Ralls
>
>
>> On Sep 5, 2026, at 11:30 AM, Paul Kroitor <paul at kroitor.ca> 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.
>>>
>>>