Manually matching transactions from download

When manually matching transactions from a download for my checking account, the list of potential matching transactions includes about 10 transactions that are already reconciled.

I have tried changing the status from "R" to blank, saving the transaction and then changing the status back to "R" and saving it again, but the transaction still appears on the list.

Anyone have any ideas for making these reconciled transactions not appear on the list?

Thanks

Reply to
JP
Loading thread data ...

JP wrote in news:Xns9667D69DA234Asomeoneinvalidorg@24.24.2.167:

Not sure what version of Q you're runing but in Q2005 Deluxe, this works:

Click on the Edit tab for that transaction, then click Copy while holding down the Ctrl key. If the "Downloaded Transaction" box is checked the transaction will not appear in the Manual Match list.

Reply to
Porter Smith

Porter Smith wrote in news:Xns9667E5E9FE81Bmyport2000yahoocom@207.217.125.201:

Thanks so much for the help. This has been annoying me for months and I couldn't find a solution in Quicken's help files. Your solution worked perfectly!

Reply to
JP

If I understand this scenario correctly, you have a candidate transaction in the downloaded transactions window that matches a transaction in your register that is already reconciled. If things are working correctly, when you click on that transaction in the d/l window, it's status will change to "Match" and the corresponding transaction in your register will be highlighted. You can just click "accept." The transaction in the register will be unchanged, and will retain it "R" status (not change to "c" or blank). I think that's what you would want.

If the match doesn't occur correctly automatically, then, in the d/l window, select the downloaded xaction, select edit, and select the appropriate xaction in the register from those shown. Then click OK or accept or whatever.

I frequently find myself having to do this last step as the transaction matching algorithm is rather stupid and often selects the wrong one.

There's another (undocumented AFAIK) method mentioned in this thread to make the d/l'ed xaction disappear from the d/l list if you hit control-meta-cokebottle and the press c or some such. I'm not sure why I'd want to do that but it sounds like a very handy trick. I'll experiment with it.

Reply to
Jim Nugent

Jim - I believe the original poster already understood everything you explained (and your explanation was written very well).

His problem came into being in the sentence I left from your POST above. Re-read what he said, and his question was why would Quicken offer an

**already reconciled** transaction as a candidate for this new one to be matched to?? His question makes sense to me!

But I just have learned to disregard them and pick the right one from the list. That doesn't seem to bother me as much as it does the original poster, but his point is still certainly valid! I'll try the little algorthm that one of the posters gave as a solution sometime.

Reply to
Andrew

I can't speak for reconciling to an online balance, but reconciling to a paper statement does not care whether the transaction is marked as reconciled already or not - never has as far as I know. And the fact that the op had to manually mark the existing transaction as "downloaded" strongly suggests that Quicken was right to include it as a candidate for matching. If a transaction in the register has not been "matched" before, why should the fact that is is marked "reconciled" affect its candicy for matching? There is nothing preventing a user from reconciling a transaction that has yet to be downloaded (even if it does not seem to be a logical thing to do).

Reply to
John Pollard

I wonder if we're all communicating here!

Let me try again.

The original poster was simply asking why, when trying to match a downloaded transaction that has yet to be added into his register, Quicken would present transactions *already* reconciled (ergo, the ones in the register have already been accounted for somehow by a former reconciliation, and this NEW one that has yet to be entered can not possibly be any of those.).

Am I missing something? I really can't say this any clearer.

Reply to
Andrew

I ran into this same problem last night on one of my accounts. Q04 "matched" several transactions to already reconciled transactions. They did indeed match in amount and source. I think we've had a discussion before that led us to conclude that Quicken ignores the dates when trying to determine a match or new. In my case the May transactions for payroll lined up with the April transaction that were already reconciled. So I suspect that Q also ignores the reconciled column when it tries to match transactions. As long as you watch the top half of the screen when you go to accept the transactions you will be okay. I did goof and had to manually add one back in last night. In the future I will be more careful when checking the "match" transactions.

Reply to
Laura

When you download the transactions, Q tries to match the transactions up with already posted ones. This is so that you can manually enter transactions in advance and then let the bank download the actual transactions as posted. When this matching process takes place Quicken ignores the date and it appears that it also ignores the recociled column during this process. It ignores the date because you could enter a manual transaction on the 5th but the bank does not post it until the 6th. It is still a match despite the difference in dates. Hence, Q has to be able to match existing transactions in the register. Some may be cleared/reconciled but Q does not seem to look at this field either.

It looks like it may only check the amount in the process. It is up to the user to accept or edit the matched transactions so that the dates are correct. Remember, the matching is only a *guess*. I originally thought that it also checked vendor but my manual download last night only included the

1st line of the 2 line description yet Q was able to match already downloaded transactions correctly.
Reply to
Laura

I understood you exactly. I just disagree with you.

You can mark a transaction in your register as reconciled before you download it. The fact that a transaction that is already in your register is marked reconciled does not mean it has already been downloaded. Reconcilication, which perhaps normally includes transactions that have already been downloaded, does not require that the transaction have been downloaded.

Let me draw it out.

1.) You write check #123 2.) You manually enter the check in your register 3.) You receive a printed statement showing the check cleared 4.) You reconcile your account 5.) You - belatedly - download transactions, among them is check #123. (A story line - one of several possible: Suppose you lost your internet connection for a for a period starting just before the transaction was available for downloading ... and you received your printed statement during the time you had no internet connection, and you elected to reconcile because you had your printed statement in hand. Then after you completed your reconciliation, your internet connection was restored and you downloaded the, now reconciled, transaction for the first time).

I repeat; reconciling (to a printed statement) has no no reason to require that the transactions you mark reconciled have already been downloaded from your fi. A transaction in your register that has never before been matched to a downloaded transaction is a legitimate candidate for matching. Logic may say that a reconciled transaction has a low probability of being the transaction you want to match to ... but it does not say that it is impossible that it is the transaction you want to match to. Transactions that have never been matched are legitimate candidates for matching (if all other match conditions are met); it's really that simple.

Reply to
John Pollard

I no longer have the criteria Quicken uses for matching (and the criteria have changed a few times - and there was always a difference in the criteria for QIF files and web-connect/direct downloads), but I am almost certain that Quicken does not "ignore" the date ... I think Quicken is relatively forgiving about the date. At one time I think Quicken would allow transactions within the previous 90 days to be considered for matches to downloaded transactions, but that may have changed.

Reply to
John Pollard

That makes sense. The 2 cases that come to mind always were the last payment so they were always 30 days older than the current transaction. The other lesson is to always schedule the expected monthly payments & deposits. That way Q will see the scheduled entry as the last entry to match on.

Reply to
Laura

Now that defies logic. Why do you expect Quicken to match the most recent entry if there is a similar, older entry? Surely the locig within Quicken and in our usual day-to-day endeavours are such that the downloaded entry

*needs* be associated with the oldest entry in your register. If not, when will the oldest entry be matched?
Reply to
Mike B

OK - but we weren't (I don't think) ever talking about reconciling to any printed statement, strictly the online. I was all set to say the hell with this discussion, but I do consider your point about having to perhasps switch to a paper reconciliation for some hardware problem like the type you cited. I think I remember somewhere something being said about don't mix and match. Boy - I never want to have to go there.

So, I do see your point. I was thinking about perhaps having an option to not present RECONCILED transactions to match, but the # (at least in my case) is fairly low presented, and as I said, I just live with it when it happens.

Reply to
Andrew

I guess I did not write very clearly concerning earliest/latest transactions. I should have said 30 days earlier instead of older in my message.

Let me give you an example. I have a monthly payment for my ISP. The last entry was 4-27-05. Along comes the same amount for the 5-27-05 payment. Quicken matched the new transaction with the last transaction of 4-27-05. The april transaction was the last entry that it found with the same amount so it deemed it a match.

Reply to
Laura

Hey Andrew, I don't have any beef with you. Please look at my earlier post where I specifically said I was referring to reconciling to printed statements. I never intended my remarks to apply to any other situation ... and I would not object to being proved wrong about reconciling to printed statements either. To me, it's all about what folks who read what we write will come to understand about Quicken.

Reply to
John Pollard

Now you are confusing me even more. You have a monthly payment for 4/27/05 in your register. was this a downloaded entry or a scheduled entry? If it was a downloaded entry, it would have a flag set to prevent Quicken from matching it again. If it was a scheduled entry, then clearly it still needs to be matched with a downloaded entry. It seems to me you have lost a transaction somewhere nad there is a month-old transaction in your register that remains unmatched.

Reply to
Mike B

The 4/27/05 was a downloaded entry that was reconciled on 5/1/05. It was a real entry. I am not missing any entries. The ones that I did schedule matched correctly.

Then came along my next download session on 6/1/05. In it was the 5/27/05 transaction for the same vendor and amount, my ISP.

Quicken did not mark the 5/27/05 entry as NEW but as a match to the already reconciled transaction posted on 4/27/05. I had to manually tell Quicken that this was a new transaction overriding the MATCH that quicken thought it was.

This behavior has happened on all of my recurring entries. It will always match on the last/previous entry it finds. It does not matter if the entry was reconciled or not. I don't know where this "flag" is set.

Reply to
Laura

John - no problem on this end! I'm not arguing. And I'm hope never to try to "prove" anyone is wrong (in the pejorative sense of the word) - to me, the forum is SO useful for allowing people to share thoughts and experiences so we all learn about, for me, is my "so-called" system-justifying application (ie: Q). Besides, others like yourself know so much more than me, so I'm always on the learning end of any thread. I'm cool.

--------------------------------------------------------- Regards -

- Andrew

Reply to
Andrew

The behaviour you describe is completely bizarre. First, let us remove reconciliation out of the equation - it has very little to do with anything in this discussion.

In your scenario you start with no entries. Come 4/27/05 you downloaded a transaction from the FI. It was entered in your register. (When a transaction is downloaded, it is marked in the Clr field with a "c". You can also see it was downloaded by right-clicking on the transaction and then holding down Ctrl while left-clicking on the "Copy" option in the drop-down menu).

So come 5/27/05, you download a new transaction and Quicken now tries to match it to the downloaded transaction of 4/27/05? Thus forcing you to make it "New"?

But if you have a scheduled transaction in your register on 5/27/05, then Quicken would match with the scheduled transaction?

I have Q2004 and I cannot replicate what you describe. For a test, what would happen if you simultaneously downloaded both the 4/27 and 5/27 transactions? You could create a new file and test it. In your scenario, you'd end up with a single transaction dated 4/27, which again is completely wrong.

I'm stumped. You must have something seriously wrong in your version of Quicken.

Reply to
Mike B

BeanSmart website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.