Credit balance on invoice payments

[weba]

Hi,

I have a custom module to read bank statements and with the function addtransaction payments are added to the invoice. 

Sometimes the customer pays more then the invoice amount and this results in a credit balance on that invoice. But this is only on that invoice, its not added to the client balance and not used for other invoices. I would suspect that the amount that is paid too much was added to his credit and used for (existing) other invoices.

I looked around but I cannot find documentation about this or how this should work.

Anyone experience on this ?

thx

Michel

[web2008]

If a customer pays too much, the amount is automatically added to the customer's credit balance, so that the amount can be used to pay other invoices.

[weba]

Thx for your reply!
Not when you use the API function AddTransaction, but it does work when you use the API function AddInvoicePayment.

Thats is the answer the supportdesk gave me.

[web2008]

Yes, there are differences in these API functions, so then your module may use AddTransaction which will be something other than AddInvoicePayment.

Otherwise, a little extra work is required to reconcile the Overpayment for the accounts.

[Kian]

2 hours ago, web2008 said:

If a customer pays too much, the amount is automatically added to the customer's credit balance and...

... invoice fraud is just around the corner as you're getting the overpayment without issuing a customer invoice 👍

I'm just saying it. Sadly you need more than AddTransaction.

Edited October 8, 2020 by Kian

[web2008]

It is actually quite common for a customer to pay the same invoice twice and you do not generate a new invoice for this amount, but leave it as a credit.

If weba mean that the customer pays more than the invoice amount, then it will be something else!

[Kian]

I'm saying that in many countries you are required by law to issue invoices for overpayment immediatelly or within a certain period of time. You can't just use credit balance adjustment and wait for subsequent invoices for a number of reasons:

• If the overpayment occurs X days later when the proforma already turned into an invoice, WHMCS overwrites its date messing up invoice sequential numbering. An invoice from 2019 could easily end up in 2020, 2021, 2022 etc. as long as the overpayment still occurs
• The fact that WHMCS "moves" invoices puts you at risk of making mistakes on your taxes
• Overpayments must include taxes as soon as you receive money. You can't postpone it, not even for 1 day. Imagine what happens with VAT rate changes over the years (example: you receive the overpayment in 2020 when VAT rate is 20% and the resulting credit is applied on invoices of 2021 with VAT rate 21%  🤨)

That's boring.

 

 

[web2008]

Kian, I do not know how it is in other countries, but what you say seems to me completely illogical.

Overpayment will be the same as add funds and will therefore not be included in the calculation of tax.

I therefore believe that WHMCS handles this correctly, even though there could have been better reporting, so that the balance in the accounts became easier to reconcile.

[weba]

FYI; we are busy with implementing whmcs and plan to go live in 6 to 8 weeks.

AddInvoicePayment does the trick (the difference is not well documented). New invoices automatic are paid with the credits but existing invoices not but thats another issue.

In my country its no problem to use the overpayment as credits. Also the customer can use old invoice numbers to make payment through the bank to add to his credit for future invoices. We do not pay tax for the prepaid. balance but we do mention it in accounting. 

[Kian]

2 hours ago, web2008 said:

Overpayment will be the same as add funds and will therefore not be included in the calculation of tax.

That's the point.

Add funds invoices issued by WHMCS are not correct. Let's say I add 100 euro of funds. WHMCS issues an invoice with 100 euro an no VAT. In "civilized" countries this is illegal as you're not charging VAT for a payment you are receiving. Add funds must include VAT. Always. VAT-free invoices exist but they're for things like special tax districts, reverse-charge, VIES, split payment etc. That said, overpayments, being a sort of "add funds", are also incorrect.

2 hours ago, web2008 said:

I therefore believe that WHMCS handles this correctly, even though there could have been better reporting, so that the balance in the accounts became easier to reconcile.

Not only it is terribly incorrect but having invoices that change their dates based on overpayments is a nightmare for any accountant. How can an invoice issued in 2019 move to 2020? Not to mention that changes to existing invoices are not allowed. But WHMCS freely adds transactions, it changes dates and even fiscal year... how is it considered "normal"?

1 hour ago, weba said:

In my country its no problem to use the overpayment as credits

Converting overpayments into credit is perfectly fine as long as you don't cause billing errors and break laws.

Edited October 9, 2020 by Kian

[weba]

In the Netherlands adding funds is the same as selling a gift card. You do not add tax, you add tax the moment the funds or giftcards are used. 
I believe we are quite "civilized" 😉

[Kian]

You're missing my point.

Is it normal in the Netherland (or any other country) to have invoices moving from one date to another even changing fiscal year? Is it normal to add transactions, change dates and alter amounts on invoices that have been accounted months/years ago? I don't think so. Invoices are something official, you can't play with them especially with things like electronic invoicing.

Side note. As for gift cards, it depends. In some countries single-purpose gift cards must include taxes hence the problem extends to add funds invoices.

[web2008]

None of my invoices that have overpayment have changed date (s) so do not quite understand what you mean?

Paying tax on overpayment, before the amount is possibly used on an invoice or repaid is not correct, neither in my head nor in my country.

Otherwise, I agree that one should not change invoices that have been sent out and therefore I use Proforma Invoices which becomes an invoice when the customer has paid. Then you can change as much as you want without coming into conflict with the law and you avoid credits.

[Kian]

4 hours ago, web2008 said:

None of my invoices that have overpayment have changed date (s) so do not quite understand what you mean?

On 10/10/2019 Mike, one of your customers, orders a domain for 10 euro.

WHMCS generates Proforma #500. Mike decides to pay it creating recurring subscription with PayPal. Proforma #500 becomes Invoice #100 of 10/10/2019.

11 months later, on 10/09/2019, Mike realizes that the domain is expirying next month then he immediately places an order for renewal. He forgot there was the recurring subscription.

WHMCS generates Proforma #2500. Mark sends the payment. Proforma #2500 becomes Invoice #150 of 10/09/2019 and here comes the problem.

A month later, PayPal automatically sends the payment (the recurring subscription). There's nothing to pay as the domain has been renewed already so WHMCS "elegantly" adds the transaction to the "closest" invoice. That's how Invoice #150 of 10/09/2019 (10 euro) becomes Invoice #150 of 10/10/2019 (20 euro) 😵 Lot of fun. That is absolutely wrong on so many levels especially if you're issuing electronic invoices. And I'm just talking about recurring subscriptions. It can happen in other ways.

This story can repeat forever as long as overpayments keep occurring. I've seen a lot of systems with invoices moving from 2012 to 2013, 2014, 2015, 2016, 2017... 🥶 Yes, invoices can even change fiscal year. Imagine your face when you issue more than 15k invoices per year. As if it wasn't enough complicated, we have taxes but that's another funny story.

Edited October 9, 2020 by Kian

[weba]

Invoices changing after being paid is not done that I agree. But I tested a lot of things now but haven't seen this myself but I do not use/test recurring paypal. It sounds like a bug of the paypal recurring module, not functionality.  If no open invoices then add it to credits that would seem to be the right way. 

[Damo]

52 minutes ago, Kian said:

11 months later, on 10/09/2019, Mike realizes that the domain is expirying next month then he immediately places an order for renewal. He forgot there was the recurring subscription

This recurring subscription is nothing more than a pre-planned payment.  It's not assigned an invoice number at this stage. 
 

If the client places a renewal and pays it then that transaction is different / complete and has its own invoice.
 

Here in Australia the subscription payment would be added to the clients account as a credit amount to be applied to an open invoice.