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

I think what's confusing the issue here is the choice the developers 
made to use red to denote this particular status (combination of facts). 
It doesn't actually represent an error, and perhaps grey would have been 
a clearer choice.

A red line is a transaction where Gnucash has determined there's nothing 
to be done for that transaction (it says "Do not import (no action 
selected)". You'll notice that if you turn off all the possible actions 
for importing a transaction, it becomes red. Conversely, if you manually 
select an action, the colour changes to yellow or green.

 From memory (I could be misremembering), one scenario I've encountered 
is when a nearly matching transaction exists in the register, but at a 
wildly different date. Then it elects not to turn on the "C" action and 
shows as red. You can check the "C" and it becomes matched, or leave it 
as is, and the existing transaction in the register will remain with an 
"N" (not reconciled).

Paul


On 2026-08-19 4:29 a.m., arthur brogard via gnucash-user wrote:
> I have queried this before and back then it was apparently unresolved.  Recently I took it to AI and it couldn't come up with anything - and it of course has access to just about everything so I'm thinking it is not resolved.
> However I will ask again just to be sure.
>
> The question:
>
> What causes the 'red flagging' of some transactions in a batch import from .csv  that on testing seems to be totally invalid?
> i.e. if you for instance take those red flagged transactions and put them in a batch of their own they will be accepted without demur.  'green flagged'.
>
> I just found/did/experienced an example of it.
>
> A batch of maybe 60 transactions being one bank statement's worth flagged four as red.  Numbers  1, 4, 5, 8.
> All transactions totally valide I know for sure because the book is reconciled and updated only statement by statement.  So no overlaps.  No duplicates.
>
> I took the four and put them at the end of the batch and submitted again. Exactly the same result so the position in the batch has nothing to do with it.
>
> Then I batched them up by themselves in their own csv and submitted it:  no problem, all green.
>
> Then I submitted the  original on top of that and I got again the same red flagging now that they existed already.   (Where AI had assured me that if a transaction already exist it will be 'yellow flagged'.
>
> So I don't know what causes it and I'm not impressed by AI's understanding.
>
> I will mention that I recently imported at least 3000 transactions in a couple or three batches and without one single red flag.  Transactions from the same statements, csv's produced by the same software.
>
> I find it very intriguing and am surprised if there is no answer.  I'd expect today's debugging software to be capable of quickly showing the problem even if its not so easy to provide a cure or rewrite to remove it, at least find it I'd expect.
>
> Any ideas?
>
> _______________________________________________
> gnucash-user mailing list
> [email protected]
> 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
[email protected]
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.