How can we improve WHMCS?

Credits can either be added manually, or automatically due to an invoice overpayment. But when an overpaid invoice line item is added/deleted/changed, or the overpayment transaction is deleted, the overpayment credits no longer reflect the true overpayment amount. I insist that overpayment credits should be handled automatically to maintain our confidence in the integrity of credit balance data.

I'll share some of my communication with WHMCS support for context:

I just noticed that credit balances only increase due to overpayments but never decrease when overpayment transactions are deleted. This has created a disaster in our accounting as dozens of clients have potentially received thousands of dollars of credit due they shouldn't have received. The credit balance should reflect the absolute balance of a customers account (or at least the overpayment record in credit balances should reflect the original overpaid invoice's current overpayment balance).

Example:

$100 invoice + $400 transaction (#1) = $300 credit balance
$200 invoice + $200 credits applied = $100 credit balance
$500 invoice + $100 credits applied + $400 transaction (#2) = $0 credit balance

The way credit automation has been coded, it appears that ***if transaction #1 is removed and replaced with a $100 payment, the $300 credits remain,*** even though ***the invoice is no longer overpaid***. This is creating a nightmare in our bookkeeping and is seriously damaging the trust we have with the bookkeeping experience in this platform. It will take us many hours to tediously review 1,000 invoices to find all of the issues with over-crediting.

-- STEPS TO REPRODUCE --
- Create an invoice
- Record an overpayment transaction
- Notice that the client credit balance increases
- Delete the invoice overpayment transaction
- Record a payment that equals the amount of the invoice (not an overpayment)
- The credits remain the same even though the client should have NO credits

-- EXPECTED RESULTS --
- Expecting that when an overpayment that created credits gets deleted, there should be a deduction in the credit balance. It is currently possible for a client to receive credits that they should not have received due to a failure to deduct credits automatically.

-----------------------------

WHMCS response:

Regrettably, the credit system and transactions are separate due to the ability to be able to manage funds on a credit balance separately.

From the information you have provided, this appears to line up with the expected behavior.

Within WHMCS, when an overpayment is made, the invoice will be marked as paid and then excess funds will be added to a credit balance. Due to these being separate actions, removing the transaction will not affect credit additions.

With all that said, I can see how automated credit management would be useful. Therefore I would encourage you to please submit a request to our feature requests tracker where other users can contribute to and vote on your idea. Ideas with the most votes and activities do get reviewed by our team.

-----------------------------

My follow up:

I hope the WHMCS team can appreciate how confusing and frustrating it is that credits are automatically added, but not automatically edited/removed. It's not that my request is to "add automation" to credit management—the addition of credits is already automated. But the automation only works in one direction. This intentional decision by WHMCS to only automate the addition of credits has created chaos in my bookkeeping. I now have to decide whether to leave everything as is and lose hundreds or thousands of dollars by giving clients credits they didn't earn, or losing dozens of hours of my time tediously comparing credits to transactions and invoices.

I'm asking for advice from other large WHMCS users and they told me they don't use the credit system because of this problem, and suggested that I stop using it too. My business model requires that I use credits but I'm overwhelmed by the account reconciliation problem this has created for me.