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

Dustin Henning gcul209 at mynym.us
Tue Sep 15 08:40:25 EDT 2026 

I believe I actually asked about this a long time ago, probably using a 
different e-mail address than the one I use now.  That is neither here 
nor there, but I recently found that I can make it work a little in 
current versions better than I could then (though the same behavior may 
have been available with me overlooking it at that time).  As such, in 
case it is helpful, here is my current process:

 1. Put my description in the notes field (when I started doing this,
    the import text that is added to the notes field wasn't added, but
    that's a separate conversation in another relatively old thread that
    may have also been on a previous e-mail address, but there is a
    setting for that text to append, so this still works)
 2. When I import, look at each red line and check the middle (update)
    box, then use the expansion button on the left side to see what it
    matches to.  If the amount is the same, I'm most likely good to go. 
    Otherwise, I can look into why that discrepancy exists before
    importing that match (proceeding with the others to limit what is
    left for review).
 3. Reconcile, since everything should have matched and should be marked
    cleared, reconciliation should be automatic once the correct date
    and amount are entered; this confirms everything matches well enough
    (if one diescription is flipped, another must also be for the same
    amount).

The above is much better than my previous process (which, if I remember 
correctly, came around because it was much more difficult to reconcile 
if forcing matches without the information above), for reference:

 1. Put my description in the notes field (as stated above, I've been
    doing this since the import behavior was much better)
 2. Push the import through where things match
 3. Try again to see the red lines only, find and edit each of them to
    match the date (or figure out why there is an amount discrepancy if
    relevant)
 4. Reconcile, same as above, but this process was more fragile /
    mistake prone, so reconciliation didn't work automatically as
    consistently

While it would be great if importing just worked, the new procedure 
isn't that bad (though I am a bit OCD and manually delete all of the ofx 
details from the notes, so that part is a bit painful and makes me 
sometimes ponder trying to switch to SQL format so I can script them 
out).  Hopefully this is helpful to someone regardless of whether or not 
I was previously missing anything obvious.

On 9/12/26 15:44, Paul Kroitor wrote:
> Thanks John, I concur with your analysis and don't intend to take it 
> any further.
>
> IIRC Quicken *does* deal well with this scenario because it uses a 
> two-step process:
>
> Firstly the import mapper automatically changes "[CW]INTERAC ETRNSFR 
> SENT CON” to "Condo Syndicate". This because the first time this 
> manual correction was performed, it asked if I would always like this 
> to be changed (actually one clicks the relevant words, so one creates 
> a rule equivalent to if ("INTERAC" in Desc and "SENT" in Desc and 
> "CON" in Desc) then Desc = "Condo Syndicate" -- but all in a 
> user-friendly way). These mapping rules run every import for all 
> transactions, similar to incoming message handling rules in an email 
> client.
>
> Secondly, the a match process similar to Gnucash occurs, but using the 
> remapped Desc rather than the original.
>
> Quicken does not do anything with the Memo field, which is an 
> annoyance, especially for banks like mine that split their description 
> over two fields in QFX.
>
> (at least all the above is my recollection -- I could be misremembering)
>
> Anyway, thanks for your help, Paul
>
>
> On 2026-09-12 3:41 p.m., John Ralls wrote:
>> Paul,
>>
>> It seems to me that the matcher is behaving exactly as designed and 
>> documented. The documentation for the import status indicators for 
>> red says "Transaction has poor matches and no action was set: – Not 
>> to be imported. Intervention required.” 
>> (https://www.gnucash.org/docs/v5/C/gnucash-manual/trans-import.html#match_status). 
>> In other words GnuCash doesn’t know whether you want to add the 
>> imported transaction as new (check the A box), select one of the 
>> not-good-enough matches that GnuCash found (check the C box), or 
>> ignore it as already cleared and reconciled (check nothing) and it 
>> colors the row red so that you know it needs help.
>>
>> In order for a substring matcher to find a match between "DO 
>> SYNDICATE          202624507365BWNEV” and “Sep” would require telling 
>> it that if any one letter matches between the two strings that’s good 
>> enough; for "[CW]INTERAC ETRNSFR SENT CON” and "Condo Syndicate” the 
>> threshold would be a sequence of 3 letters. Either of those would 
>> produce so many false matches as to be utterly useless. It seems 
>> unlikely to me that Quicken would consider those matches. GnuCash 
>> already depends on International Components for Unicode which has a 
>> string search service 
>> (https://unicode-org.github.io/icu/userguide/collation/string-search.html). 
>> We can discuss what would be reasonable matching criteria and how 
>> much of a performance hit would be worth the higher match score if 
>> anyone is interested in that.
>>
>> If a close (the default is ±4 days) date and exact amount match is 
>> enough for you to let GnuCash auto-clear the transaction then 
>> lowering the auto-clear threshold to 5 does that for you.
>>
>> Regards,
>> John Ralls
>>
>>> On Sep 8, 2026, at 8:25 AM, Paul Kroitor<paul at kroitor.ca> wrote:
>>>
>>> I've concluded that my last supposition was correct: the match 
>>> probability of the transactions at issue was so fragile that the 
>>> single issue of being one day late causes the match to fail.
>>>
>>> This is caused by the Description and Memo fields being so different 
>>> in the two elements that they aren't counted as contributing factors 
>>> (even though to a human, they would be a match), and there being no 
>>> cheque number to match either. The result is the only matching 
>>> elements are the amount and a close-but-no-cigar date, which just 
>>> isn't enough.
>>>
>>> It's aggravated by the forget-about-it philosophy of the import 
>>> matcher where a non-match hides the existence of 
>>> nearly-but-not-quite matches (I understand and mostly support this 
>>> choice, and now I know about it, I can take it into account).
>>>
>>> I've lowered the auto-clear threshold, which resolves my problem, 
>>> but I'll have to see if it introduces others.
>>>
>>> A couple of closing thoughts....
>>>
>>> Gnucash doesn't have an import map the way Quicken does which would 
>>> massage the incoming transactions to look closer to the way I keep 
>>> my registers (eg. "[CW]INTERAC ETRNSFR SENT    CON" becomes "Condo 
>>> Syndicate"). This would be lovely to have, but it's a big project to 
>>> add into Gnucash.
>>>
>>> A second best alternative might be a simple python thing to do it 
>>> manually beforehand. It could be added to the context menu to allow 
>>> right-clicking on QFX files to pre-massage my import data. Or one 
>>> might consider an optional preprocess script being automatically 
>>> called by all the gnucash import functions.
>>>
>>> <end of Paul's adventures in gnucash-importland :-) >
>>>
>>>
>>> On 2026-09-07 8:08 p.m., Paul Kroitor wrote:
>>>> Some discoveries:
>>>>
>>>> 1. The way to see the match weightings (on Windows) is to start 
>>>> gnucash from the command prompt as follows:
>>>>
>>>> "C:\Program Files (x86)\gnucash\bin\gnucash.exe" --debug --log 
>>>> "gnc.import=debug"
>>>>
>>>> (many of you may have known this, but credit to Gemini for telling me)
>>>>
>>>> 2. Two aspects that greatly add to the general unhappiness are that:
>>>>
>>>> A) when a potential match falls below the threshold, it shows red 
>>>> but it ALSO hides the entire possible match subtree (the ">" and 
>>>> the ability to expand it). Interestingly, if one simply checks the 
>>>> "C" column, the subtree and its indicator appear. So it's there, 
>>>> just hidden.
>>>>
>>>> B) the description and memo texts from my scheduled transactions 
>>>> are nice and clean (eg. "Condo Syndicate" and "Sep") whereas the 
>>>> text coming in from the QFX is garish ("[CW]INTERAC ETRNSFR SENT  
>>>> CON" and "DO SYNDICATE 202624507365BWNEV"). These are total 
>>>> non-matches from the matcher's point of view*.
>>>>
>>>> 3. Here are the match logs for two nearly identical transactions in 
>>>> my test. The only difference is that the first (for $585) 
>>>> pre-exists in the register on Sep 1st, whereas the second (for 
>>>> $330) is in the register as Sep 2nd. Both are in the QFX file for 
>>>> the 2nd. The first is rejected (red and no expandable list of 
>>>> possible matches), the second shows green and gets an expandable 
>>>> section showing the match data.
>>>>
>>>> ------------
>>>>
>>>>   downloaded_split_amount=-585.000000
>>>>   match_split_amount=-585.000000
>>>> heuristics:  probability + 3 (amount)
>>>> Date download: 2026-09-02 vs match: 2026-09-01
>>>> diff day 1
>>>> heuristics:  probability + 2 (date)
>>>> number download: '' to match: ''
>>>> memo download: 'DO SYNDICATE          20262450737VMDHNH' to match: 
>>>> 'Sep'
>>>> description: download: '[CW]INTERAC ETRNSFR SENT     CON' to match: 
>>>> 'Condo Syndicate'
>>>> Added to list of possible matches: 5
>>>> ------------------
>>>>   downloaded_split_amount=-330.000000
>>>>   match_split_amount=-330.000000
>>>> heuristics:  probability + 3 (amount)
>>>> Date download: 2026-09-02 vs match: 2026-09-02
>>>> diff day 0
>>>> heuristics:  probability + 3 (date)
>>>> number download: '' to match: ''
>>>> memo download: 'DO SYNDICATE          202624507365BWNEV' to match: 
>>>> 'Sep'
>>>> description: download: '[CW]INTERAC ETRNSFR SENT     CON' to match: 
>>>> 'Condo Syndicate'
>>>> Added to list of possible matches: 6
>>>> ---------------
>>>>
>>>> All these evaluations seem to make sense to me. The first is 
>>>> understandably given a lower date match score (2 vs 3). So my 
>>>> current avenue is to check my theory that a total score of 5 vs a 6 
>>>> is the exact border that defines the reject / accept boundary.
>>>>
>>>> Paul
>>>>
>>>> * perhaps someone knows of a comparison function in one of the 
>>>> existing dependencies (boost?) that is smart enough to score these 
>>>> two very different strings as "partially similar"?
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> 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.

More information about the gnucash-user mailing list