We’ve been uploading bank statements into our account but subsequently finding duplicate entries. These seem to be caused by us marking, for example, supplier payments as paid which QF posts to the bank statement and then the same payment to the supplier appearing in the statement when we subsequently upload the statements.
I looked in the community and found this post:
Plus the help file:
However both say that the “import process will however test for pre-existing items with the same date and amount and will give you the option to commit or ignore”.
Despite us having pre-existing items with the same date and amount I saw no prompt or option to commit or ignore the duplicates before posting. It has therefore been a bit tedious to run through and check manually.
Can you advise, or have we missed something?
Thanks for the help!
If you created tag rules after feed import then you will have duplication issues.
It is always best to have one consistent approach for bank writing, either log payments from invoices or feed in statement. As one date can have multiple transactions of same amount.
I just tested this feature by uploading a CSV bank statement twice. On the first occassion it commited all the transactions (as expected) and on the second occassion it prompted me for every single transactions giving me the option to skip or save.
I’m not sure why you weren’t presented with this option? Presumably you’re uploading from the bank import screen rather than the bank feed plugin?
I think in this instance it is case of manually recording receipts and payment through invoice screens and then uploading bank feed, since two transactions are not with same description for tagging purpose it is bound to record two different transaction which are giving du0lication effect. This is not same as uploading same feed twice
Well I originally thought this however at the point of upload the system only checks for matching dates and amounts and ignores the description. So if @u4h37u had manually tagged payments first then uploaded the CSV later, those warnings would still appear. When I did the CSV test I also changed the descriptions the second time around and the prompt still appeared for me.
Thanks for the responses.
We are manually recording payments, so that we can use the remittance advice email (which can’t be done via tagging from what I can see). We then follow up subsequently with a csv bank upload from Lloyds. I don’t think it can be done the other way round?
From what you say the upload facility should still present warnings as the values and dates match, even though the description does not (as the description QF posts would never match the bank description. However, we didn’t see those warnings.
I think the next time we do this I’ll take some screen shots and leave the duplicates in there for you to take a look at if you like.
Also, if there is a better way of achieving the same thing (i.e. sending remittance advice on the day payment is made while also being able to upload bank statements) I’d happily change our process to fit the tool.
That would be helpful, thanks!
It has been suggested that we make the email remittance option available within bank tagging, this is under consideration although we want to keep the tagging side as lightweight as possible, no huge email preview boxes.
I’ve just uploaded the csv bank statement for last week and went through the usual screens. I’ve pasted below what I saw:
Then looking at the statement there are a number of duplicates, where both the date and amount match where from what has been discussed I would have expected QF to pick them up (supplier details removed):
I’m guessing I’ve done something wrong but I’m not sure what…!
Further to this, our accounts person this morning has unfortunately deleted the duplicates, only moments after I’d uploaded and taken the above screen shots! Sorry for this as I’d asked that she didn’t touch it until you’d had a look.
I can confirm though that no duplicates were reported by QF despite transactions already in the bank account statement in QF matching the imported statement on date and amount, as shown in the image above.
Don’t worry, there was enough data there to find out exactly what the problem was, in fact we pulled out the CSV from the archive and replicated it exactly. It was a very obscure problem and the check was failing in some scenarios. We’ve issued a fix on the code and this should go live later today or tomorrow morning. I’m sure once the update is live that the check will work every time without fail
Appreciate the detailed info you supplied to assist us with the problem.
This topic was automatically closed after 7 days. New replies are no longer allowed.