Leaderboard

Honestly the worst thing I could have done. Modules are supported. Invoices can't be edited. Worst move ever.

None that I know of and the likely reason there is not is because it would be an absolute nightmare. Recieved donations you would still need to declare. Recieved donation = income tax - Services charges you pay for the transaction charges. Your holding money that doesn't belong to you/business. Client decides to cancle services what ever moneys you have recieved in donations for said client has to be given to client if they ask for it you can not legally hold onto it. Next issue if you are recieving donations for a client and holding those funds you become a money handler at which point your Business/Company then has to register as money handler. Simplest solution to this is clients should be responsible for that themselves its not the hosts responsibility.

Plesk Support suggests executing this command after updating to Plesk 18.0.79.4 (18.0.79 Update #4😞 plesk daily LoadCustomizations Now SSO is working again.

I just had Claude.ai help me create a module and hook to allow me to click a button to revert the invoice back to Draft and it also allows me to click a button to zero out a late fee. I am all set.

They closed the request to keep it optional so they are not even going to listen to us. https://requests.whmcs.com/idea/making-non-draft-invoices-are-immutable-optional Maybe if we opened 1000 requests they would listen.

Here we are 7 months on from major release and a large portion of the minor updates , from what I can tell, have been security-related. Very little in the way of fixing the major complaints. While im glad I didnt update, Im also miffed that another year of price updates go by without actually getting anything back that adds value.

Honestly, quite a few. Across much of Europe, an issued invoice is treated as an accounting document that must remain traceable for VAT and audit purposes. You generally should not be able to overwrite it in a way that destroys the original record, especially when the customer may already have booked the invoice and claimed input VAT from it. If an issued invoice is wrong, the normal process is to credit or reverse it and issue a corrected invoice. That said, I think you are focusing on the accounting mechanism rather than the actual usability problem. WHMCS should make this process almost invisible: You click Edit invoice, make the required changes, and WHMCS automatically credits the original invoice and creates a corrected replacement. The customer receives the corrected invoice and pays it as normal. There is no reason the user should have to manually cancel, recreate and resend everything. Preserving an audit trail is reasonable; making the workflow unnecessarily cumbersome is not.

I would love to know what county in the world doesn't let you amend and UNPAID invoice. So utterly ridiculous that you need to just keep cancelling and generating invoices if you need to update an invoice. QuickBooks lets you edit invoices. Xero lets you edit invoices. Sage lets you edit invoices.

We are already running into issues with this change. We had to add the line of code to config just to make some changes to a client wanting to upgrade their account which required the invoice to be updated. We need the ability to edit an invoice. Service upgrades, downgrades, additions, removals, you name it. This should obviously be something we choose to enable.. not force it on us. REMOVE THIS FEATURE

I’m trying to install ModulesStack from https://modulesstack.com/installation/ I followed the steps, but I’m not sure if I’m doing it correctly. The installer runs, but the modules don’t appear in my admin panel. Has anyone successfully installed it? What am I missing?

Hi everyone, I wanted to share a small WHMCS hook we created to support client-specific payment terms such as: Immediate Net 30 Net 60 Repo: https://github.com/Y2KWebs/whmcs-client-payment-terms The problem We needed a way to let some clients pay immediately, while others could have Net 30 or Net 60 terms. As many of you probably know, WHMCS ties recurring billing pretty closely to the service renewal cycle. A common workaround is to generate invoices many days before the service due date, but that is not really the same as offering payment terms. It is just invoicing earlier. What we actually wanted was: keep the normal WHMCS service renewal logic let WHMCS generate the invoice normally change only the invoice due date make sure the invoice email already goes out with the correct due date keep compatibility with accounting syncs such as QuickBooks Our approach We used: Client Groups to represent payment terms the InvoiceCreation hook to adjust the invoice duedate before the invoice email is sent The logic is simple: clients with no group or no mapped group keep the standard WHMCS due date Net 30 group = original WHMCS due date + 30 days Net 60 group = original WHMCS due date + 60 days Important detail The best approach turned out to be using the original WHMCS invoice due date as the base date, instead of the invoice date itself. That preserves native WHMCS behavior for standard clients, including cases where invoices are generated in advance. So for example, if WHMCS generates an invoice 7 days before renewal: standard client = keeps those 7 days Net 30 client = 7 + 30 days Net 60 client = 7 + 60 days Why InvoiceCreation and not InvoiceCreated? Because InvoiceCreated is too late if you want the invoice email to already contain the correct due date. What this does NOT change This hook only changes the invoice due date. It does not change: service Next Due Date renewal logic suspension logic So suspension still needs to be handled separately depending on your business rules. Why I’m sharing it I found many posts about Net 30 / invoice due dates / payment terms in WHMCS, so I thought this might be useful for others too. Hope it helps someone. Feedback and improvements are welcome.

Since editing invoices will be removed in the future I cannot do any more updates.

Seems 16 years after the issue was originally raised for any EU customer, which till now could fix that manually, the problem still remains, 1 month before digital invoicing comes into practice. I've reinforced the problem with support who appears to be an excellent developer but to have noclue on the EU fiscal legislation. And this WILL bring some user to get fines, because WHMCS will start pushing illegal invoices directly into the tax agency archives. Below is a copy of the ticket with references and legislation quotes: Let’s focus on the core problem: the invoice. The report is a minor issue — we can easily pull the subtotal instead of the total. The real issue is that the final invoice (HTML/PDF) WHMCS generates is incorrect. Scenario recap The client has an uninvoiced credit of 10€. An invoice for 10€ is generated. The invoice is marked as paid using the credit. WHMCS produces a “final” invoice showing a total of 0€. That’s not just wrong; it’s illegal in Spain and much of Europe. WHMCS has been told about this for 16years, yet it persists. Prior discussions (evidence that it’s an old, known problem) Case1 – “Credit management according to European fiscal law” – posted on 22 Aug 2024: https://whmcs.community/topic/339796-credit-management-according-to-european-fiscal-law-a-project/. The user clearly explains why zerototal invoices violate EU law and how to fix it, but there was no followup from WHMCS. Case2 – “Account prefunding credits” – 7 Feb 2008: https://whmcs.community/topic/34693-account-pre-funding-credits/. Users complained that credit zeroes out invoices and makes them look like free services. Case3 – “Paid invoices showing zero balance” – 2009: https://whmcs.community/topic/89177-paid-invoices-showing-zero-balance/. Users report that invoices show zero once paid. Case4 – “Credit into the invoice – paid but appears in 0” – 24 Sep 2007: https://whmcs.community/topic/22777-credit-into-the-invoice-paid-but-appears-in-0/. WHMCS staff responded that the invoice was “paid by credit,” implying it can show zero. This thread highlights the confusion and legal concerns caused by WHMCS treating creditfunded invoices as zerovalue invoices. Case5 – “Tax on credits” – 2008: https://whmcs.community/topic/37369-tax-on-credits/. Users from the EU explain that failing to invoice credits and showing services as free is illegal. VAT must be charged on the credit invoice; subsequent invoices paid from credit should show the amount and 0€ due, but WHMCS doesn’t do this. Case6 – Feature request “Invoices for 0.00 are illegal for many WHMCS users” – 2010: https://requests.whmcs.com/idea/invoices-for-0-00-are-illegal-for-many-whmcs-users. Users explicitly ask WHMCS to stop generating 0.00 invoices. If the service total really is 0, there should be no invoice. Why it is illegal Under EU and Spanish law: Every sale or service requires an invoice showing the taxable base, VAT, and total. Even if the VAT is zero, the “Total factura” must equal the base. Advance payments must be invoiced. The Spanish tax authority (Agencia Tributaria) states: “los empresarios y profesionales… deben expedir factura en los supuestos de pagos anticipados”. A credit on account is an advance payment, so there must be a proper invoice for it, with VAT. Zerovalue invoices are allowed only when there is a 100 % discount or return. Paying with credit isn’t a discount; it’s the settlement of a debt using funds already invoiced. Therefore, a zerototal invoice misrepresents the transaction and can be treated as a null invoice by the tax authorities. Digital invoicing (e.g., Spain’s SII) will reject zerovalue invoices unless they meet those strict exceptions. Sending invoices with a total of 0€ to the Spanish tax agency will mark the income as zero — effectively tax evasion. Why WHMCS must fix this If WHMCS continues to issue invoices showing 0€ when the real service cost is >0€, every EU client using WHMCS 9.0 for digital invoicing is going to push illegal invoices into government systems. This is not a minor bug; it’s a compliance failure. WHMCS is exposing its customers to fines and even criminal liability for issuing fraudulent invoices. I’ve been running companies in Italy and Spain since 2005, so this isn’t an academic complaint. You need to bring in a European tax expert and fix the invoicing logic immediately. Issue a proper invoice when credit is added, showing the taxable base, VAT and total. On the service invoice, show the service price and VAT, and then indicate that it’s paid via credit. The invoice can show a remaining balance of 0€, but it must not zero out the value of the service. Sending digital invoices with zero totals is a direct invitation to tax authorities to classify the transaction as void and accuse your clients of tax evasion. That’s unacceptable. WHMCS needs to address this now. Here are the primary legal and regulatory sources referenced above: AgenciaTributaria – Obligación de facturar (Spain) – Official guidance from the Spanish tax agency stating that businesses must issue invoices for all supplies of goods or services and must also issue invoices for advance payments sede.agenciatributaria.gob.es . https://sede.agenciatributaria.gob.es/Sede/iva/facturacion-registro/facturacion-iva/obligacion-facturar.html AgenciaTributaria – Libro registro de facturas expedidas (IVA) y de ventas e ingresos (IRPF) – FAQs clarifying that even operations exempt from VAT must be recorded, and the invoice’s “Total factura” must match the base amount sede.agenciatributaria.gob.es . https://sede.agenciatributaria.gob.es/Sede/iva/facturacion-registro/preguntas-frecuentes/libro-registro-facturas-expedidas-iva-irpf.html Ley 37/1992 del Impuesto sobre el Valor Añadido (Spanish VAT Law) – The consolidated text of the law, including Article 80 (reductions of the tax base) and related provisions on discounts and corrections. https://www.boe.es/buscar/act.phpid=BOE-A-1992-28740 SAP SII tip – Invoices with zero amounts in Spain – A professional summary referencing Article 164.Uno.3.º, Article 78.Tres.2º and Article 80 of Spain’s VAT law, explaining that zeroamount invoices are only valid for 100% discounts or returns community.sap.com . https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/sii-tip-for-spain-6-invoices-with-zero-amounts-in-sii-due-to-full-discounts/ba-p/14228706 Dear WHMCS developers, hire somebody who knows what he talks about to take care of this, not a php developer. I love the software but this requires fixing. thanks

Your idea is technically doable in WHMCS, but there are some important fiscal and accounting issues to be aware of. The main challenge is that the money would come from someone who is not your client, while the credit is assigned to a third party (your actual client). This creates a mismatch between the payment and the service, meaning you would legally need to issue a receipt or invoice to the donor even though the benefit goes to someone else. On top of that, VAT and taxes can get tricky. If the donation is treated as payment for a service, VAT normally applies, but calling it a "pure donation" isn't straightforward, since the money is effectively being used to pay for another person's services. And when your client eventually uses the credit to pay for their server, that counts as a separate transaction requiring its own invoice, which could create accounting confusion or even potential tax issues (double taxation) if not handled carefully. So, while WHMCS can handle the technical side, the real challenge is making sure this setup is compliant from a fiscal perspective. That being said, personally I would avoid playing with real money. Instead I'd create an alternative currency (credits, tokens or coins) that donors purchase and for which you issue an invoice. The beneficiary who receives the donation can then use those tokens at payment time to reduce the total of an invoice, for example by redeeming a discount coupon that adds a negative line on the invoice. That way you avoid the mismatch of receiving money from one party and assigning credit to another, and you eliminate the risk of double invoicing or double VAT payments.