How can we improve WHMCS?

This freaking idea is open for 10 years now. That's insane mate.
We still see this in the logs: Removed Previous Domain Renewal Line Item - Invoice ID: 53702 - Domain: kinderkaas.nl it's absolutely redicilous to remove invoice lines from existing invoices.

We export invoices to our accounting system automaticly and have to constantely explain why there is an difference in invoices.
When is this going to be fixt???

We need to separate manage invoice into view & manage based on admin roles. Currently in the admin role privileges there's only Manage Invoices, which includes both viewing and managing invoices. There is a strong and obvious need to separate view and manage invoices to give only those with manage invoices the ability to change them.

I see that this is in status "Planned", can WHMCS share any thoughts about what is planned? This is the biggest issue for us and many others I'm sure. Now that WHMCS license prices increased thousands of percentages, please spend the money to fix the billing. It is now unacceptable, and we have spent countless hours to try to make it work in a sensible way, but it is very hard thing to do to work with only handful of hooks available for us. You don't have this restriction, so please fix it as soon as possible!

This is correct. An Invoice is actually a legal document. Designing an immutable invoice is a basic design principle needed when implementing an accounting system.

Sorry WHMCS - this will not be a small change for you, but an important one.

+1 for this

This situation of invoices being altered automatically is doing my head in. I agree with Michael that automatically creating a credit note would be a good solution to this, but even just leaving the invoice as-is would be better, we can handle creating credit notes manually but these undetectable removals of line items opens us up to potential legal trouble.

There is possibly a VERY SIMPLE SOLUTION. Because only real invoices are affected, WHMCS could implement a new setting: "Don´t touch invoices?"
If set, invoice items will no longer be deleted from invoices, instead a credit note is issued.

Bamm - that easy.

Then it could work like this (no proforma invoicing):

Invoice created with several items
##
Client cancel one of the products just invoiced.
##
Client get credit note (new invoice with status refund) for the cancelled item automatically.

This is easy to do - but only for WHMCS devs.

3rd party hook/module would fail, as we can´t detect nor prevent invoiceitem deletion.

Another solution I´am testing right now is much more radical:
We do not need any prepaid invoicing at all, so we just could remove the automation settings from the invoiceitems completely at the time an invoice has been created (not the first invoice, only subsequent invoices). At this time, we manually set nextduedate and nextinvoicedate at the tblhosting table according to the products to prevent reinvoicing. This would have the effect, that on product cancellation it is not possible for WHMCS to delete the invoiceitem any longer as it is no longer bound to a product ID and thus can´t be found. Therefore the invoice remains untouched, while the product can still be cancelled whenever the client wants to.

This is maybe only possible, if you do not need automation (action when an invoice is paid). Most would need this at least for domain renewal. We have a reverse contract (our domains always renew until cancelled, so we do not need to care about this)

I do not recommend to do so to anybody as this is really a radical cut which can bring some unwanted results.

So please WHMCS.... do the simple thing and don´t touch invoices anymore.

I made a short investigation about this with a friend at PWC and even in England this behaviour isn´t legal. If you need to change an invoice you need to issue debt notes or credit notes, the regulations are nearly the same as in Germany. So you simply can´t just delete invoice items. In England you need to add the original invoice number to the credit note and the date of the original invoice. Nearly the same as in Germany, but we also need to declare for which item the credit note ("correction invoice") is issued.

Currently if an invoice is cancelled, we use a hook to detect that and when the invoice is unpaid, we automatically issue a refund/credit note/correction invoice. That´s ok for us. But if we have more than 1 item and the item in question is simply deleted, we have no chance to be aware of it, right? Or does anybody know a possibility to detect and correct?

Invoicing the way it is, may be ok for proforma invoicing, but we need to get a FAST solution if used with real invoicing.

As a developer I have an imagination what that means for the dev team. Sleepless nights. This will not be an easy task and means to say goodbye to product/automation/invoice linking and go straight to credit/debit notes handling with even more work to invest into automation handling.

I´m willing to contribute a workaround module to the community, if we at least get a chance to catch the deleted items when deletion occurs. Currently investigating how this can be done in detail.

But please consider this request and take it as serious as it is.

To all of you who are upvoting this request, please note that issued invoices are changed also by enabling or disabling auto renew for domains. This is far more dangerous because it is not easy to detect.
What happens if you have 2 items on an invoice issued to a client and one item is a domain renewal? Now, client disables auto renew. WHCMS kills (deletes) the line item in the already issued invoice. That is totally illegal (in my jurisdiction)

If there is only one line item for the domain renewal, the invoice will only be marked cancelled but NOT deleted. This is ok, we use invoice status only for information and issue automatic correction invoices (which are refunds) in that case. No problem with that so far.

But silently killing single line items (with no possibility at all to catch them before deletion) is worse.

As a workaround I disabled the auto renewal settings for the client in our template and replaced this with a message, that client should contact support to cancel a domain.

Writing that, I now fear what will happen if there are 2 products invoiced and client cancel one of those before due date. I will need to check and try that, but I think the same bad thing happens and one line item will be deleted.

So I would highly appreciate an option that prevents invoice manipulation post issued.

Please consider it for inclusion in the next update or at least within a reasonable time. The reason can be found on https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32006L0112
(look for Article 246 and then especially look at "In respect of the
invoices referred to in the second subparagraph of Article 233(1), the
details they contain may not be altered and must remain legible
throughout the storage period."). Is there a full list available of all
situations where WHMCS alters invoices without an admin doing it?

yes profroma invocies ARE NO fiscal document. repeat after me 50 times, a proforma invoice is not an invoice.


its more of an estimate and not a proper way to request any kind of money.
the only within the EU (and US at least bigger comapnys do it the same way) legal way is
-invocies are final
-onyl invocies are a proepr way to request payment
-wrong invoices (to be corrected) or canceling invoices are to be corrects via
- first a credit invoice to cancel old one out (or part of it)
- new invoice
orginal
1x ssl for 500€
__credit invoice would be ___
-1x ssl for -500€
__new invoice___
1xssl for 400€
also invocies should not be marked as unpaid or paid.
you CAN add transactions and stuff, thats nice for the customer and perfectly legal addon but not required
transaction /payment reciets are complete different thing
an invocie can combine both but dont have too. a payment reciet is made by the payment provider / bankstatement whatever
together with the invoice it will create a valid document for tax deduction
transactions on a invoice is just a nice infromation for the customer but not elgally valid for that reason
so the customer need anyway alawys the statement of payment in soem form togehter with the invoice

Reading up on this I don't agree that proforma invoices are to be considered fiscal documents. It's description of 'asking to pay' is spot on but your legal grounds to chase a customer are limited and sometimes non-existent. Proforma invoices are not final. They are often used when dealing with customs.

To be honest I don't have much problems with the fact that you can change invoices. It would be better if you can't, but training can do a lot here. Being able to send proper credit notes would be a welcome addition but my main concern is WHMCS changing invoices without our intervention. This should be changed first. WHMCS shouldn't be allowed to make changes unless you allow it to.

Companies in the US wouldn't treat WHMCS the same as companies from Europe. A toggle to switch this on and off would therefore be useful. If an invoice is changed we need a full audit trail, what happened, when and why. European law requires a reliable audit trail and I think that this would be useful for anyone, either way.

Even though it looks like this is planned they did exactly they introduced new functionality with the redemption/grace fees that still makes changes to invoices.
The redemption invoices are changed on the presumption that people pay online. If so, they would see that their invoice was changed and pay that amount. We still see a lot of customer who pay via bank transfer. As much as I would like to see this change it's the current reality we have to deal with. This means a customer either pays too much or too little depending on how you configure WHMCS. In our case we had domains removed from invoices and we had to manually go back through invoice e-mails to find the domains affected and renew them manually. That wasn't fun.
In my opinion a third option should be added to General Settings > Domains. It should create a new invoice with just the grace or redemption fee, link it to the domain and e-mail an explanation to the customer (a new invoice was created because the domain expired, etc, etc.). If the original invoice is paid and there is still a linked invoice open, don't renew the domain but notify the customer via e-mail or their account (if they pay online) that there is another invoice due. If both invoices are paid the domain can be renewed.

I had the same problem, and as i searching on WHMCS marketplace i found an add-on module named Invoice Data Updater. Can help you easily generate invoice snapshots for old invoices, change client details, custom fields and save the snapshot again to prevent any change.

This ideia will be possible in future? I saw that there is a addon...Cached invoices WHMCS addon module, that maybe help with our needs, bu never tested it, and anyways this fature better should be offered by WHMCS even if in a paid module...third part addon created by some one do not guarante us continuity to has these future for something soo important...

And if third part has know howhow to do that, WHMCS team also too...

Really expect to these futures comes available soo, if not free, could be paid, but let is make it possible.

Editing invoice after we add a payment transition is not allowed is most country, because, possibility to fraud Tax managment.

best regards

Hi,
We want to use WHMCS to issue invoices - but there are several problems with the way WHMCS is working now that are not inline with the law in our case.

In general there are several types of invoices and guidelines that we should implement in order to work legally:

1. pro forma invoice: that is actually a way to "ask" customers to pay us. This invoice should have a clear indication that this is the original invoice document and a digital signature to prove this is the original invoice. also there should be no way to change such a invoice after it was issued. when trying to send the same invoice to a customer again - this invoice should have a clear indication that this is a certified copy of the original invoice.
   
   
2. Invoice + receipt: you issue such an invoice if the customer already paid the invoice automatically so you send him the Invoice + receipt in one document. The serial number of this invoice should be different from the pro forma invoice number.This invoice should have a clear indication that this is the original invoice document and a digital signature to prove this is the original invoice. also there should be no way to change such a invoice after it was issued. when trying to send the same invoice to a customer again - this invoice should have a clear indication that this is a certified copy of the original invoice.
   
   
3. Refund invoice: you issue such an invoice if there is a mistake in the Invoice + receipt document or if the deal was cancelled and you have to refund the amount the customer paid you already. since there shouldn't be a way to change the original Invoice + receipt document - the only way to set things right is to issue a refund invoice. The serial number of this refund invoice should be different from the pro forma invoice number and from the Invoice + receipt document.This refund invoice should have a clear indication that this is the original refund invoice document and a digital signature to prove this is the original refund invoice. also there should be no way to change such a refund invoice after it was issued. when trying to send the same refund invoice to a customer again - this refund invoice should have a clear indication that this is a certified copy of the original refund invoice.

As you can see there are things in the list above that works differently now in WHMCS.

• WHMCS supports all three of these types of invoicing, which apart from Proforma ones are all based around the original invoice identification and each new status / invoice will replace the original document so when a client checks via their client area they will see in the invoice presented in whichever state it's currently in, so if in a "paid" state, that is the only invoice they will see however they will be emailed a copy each time the invoice is updated - but he relevant invoices will not be present in WHMCS.
  
  
• As mentioned above "paid" and "refunded" invoices will share the same sequential number and will be actually the same document.
  
  
• There is no way (out of the box) to add a digital signature to each type on invoices so it will prove this is the original document.
  
  
• There is no way to prevent us (in the admin side) to change such an invoice (all 3 types) after we issued it.
  
  
• There is no way (out of the box) to add an indication when sending to a customer the same invoice again - that this is not the original invoice but a certified copy of the original.

There are several feature request regarding the issues above:

• This feature request is about removing the ability to edit an invoice from the admin side after such an invoice was issued.
  
  
• This feature request is about having a different numbering for invoice and refund invoice.
  
  
• This feature request is about separating the 3 types of invoices to be actual 3 different documents (or maybe i'm wrong).
  
  
• This feature request is about adding PGP Support to sign outgoing Mails - I hope this deals with invoice digital signature
  
  So the only things left out (if the above feature requests really do handles the relevant issues I mentioned) are:
  
  

1. To make sure that the 3 types of invoices are 3 different documents that we (and the customer) can see at all times.
   
   
2. Making sure that the is only one "original" invoice document - and that every time we resend an invoice it will be marked with a clear indication that this is a certified copy of the original.

So to sum it all up:
We need a way to make sure that each type on invoice is a standalone document with different sequential number and have a digital signature to make sure that this is the only original document and prevent us from changing it after issuing it and with the relevant labeling as original document or a certified copy of the original.

Thanks!
Ram