Prepayments not showing correctly or am I missing something?

Prepayments are defined in QF as ‘Unassigned funds…’. But when I assign those funds to supplier’s invoices, the amount of Prepayments doesn’t decrease. It seems incongruent with the definition of prepayments, as well as with the equation Invoice Balance - Prepayments = Total

Is this a bug or am I missing something?

Hi @marekkowalczyk

Are you able to give an example where you’re seeing this please? If you could provide me with the last 3 digits of your account number and invoice, I can find the supplier from there and take a look.

Last there digits of my account number: 974

An affected supplier: SUP0000084; there are more.

All invoices are marked as paid and the sum of prepayments has been equal to the sum of invoices. So the outstanding balance ought to be zero.

But it is equal to the sum of prepayments (green).

If you go to the supplier and click the “View” button followed by “All payments”, you should be able to isolate those unallocated funds.

This usually occurs when you have manually lodged payments to invoices and also tagged from the bank.

1 Like

Spot on! Found double payments on file within the supplier account.

I’m wondering how I’ve managed to import them past the duplicate bank transaction checker…

1 Like

It looks like in some cases the transaction was imported, and other times it was created manually from the ‘Log Payment’ option on the invoice screen. This would override the duplicate checker.

1 Like

Does it make sense to extend the functionality of the duplicate checker to cover such cases or is it, for some reason, a bad idea?

It would be tricky. The duplicate checker also checks the description of the transaction. In some cases, you could be charging £5.00 on the same day to 10 customers, each same date and same value, but different description.

When you tag a payment from your invoice, the description will be pre-set by the system (similar to “Payment to Supplier Ltd”) which wouldn’t match up with the existing one on the statement.

Hope that makes sense?

Thank you for the clarification.

I came up with the following scenario for the duplicate checker:

When I am tagging a payment from the bank account, the checker flags existing payments to the same supplier with the same date and the same amount.

If there was a way to display side-by side both:

  • the description of the NEW bank account transaction and
  • the Supplier Reference number of the invoice that the EXISTING payment is matched to —

then I could determine whether the two payments are identical. The reason is that I always have Supplier Invoice Ref Nos as a description of a bank transaction.

I guess it is rather convoluted and is probably difficult to pull off. Also, I’m not sure how many people have the same problem.

Is this candidate for a feature request or should we just drop it?

I’m puzzled.

I’ve checked the Supplier SUP0000084, and can’t find any manual payments.

Can you please take a look at the supplier account in my system just to make sure I’m not missing anything?

If you go to your bank statement view and search for a specific date when you know a payment was made, you should be able to see the duplicates on the bank. I recall from checking earlier an instance where one of the payments originated from a feed/CSV and the other was added manually.

On the bank statement view there will be an icon to indicate how the transaction was entered.

1 Like

Ha! You’re right. Now I feel like an idiot.

It would’ve been much easier for me to spot this if there was a line in Recent Events about the manual payment.

It seems that as of now, only imported payments are registered in Recent Events.

It seems to me like a legit feature request :wink:

1 Like

Do you remember how you lodged the prepayment, was it from the supplier detail screen? An event does get lodged here, although it’s referred to as a “credit” rather than a “prepayment” (which we will change).

As far as I can remember, it was upon invoice creation — the ‘Paid in full’ box had been ticked upon creation.