Leaderboard

This new "feature" is terrible and is a fundamental change. This feature does not conform to most businesses and should be an option if there are other regulatory purposes in other countries. It severely limits the flexibility of the system and limits its function. I highly recommend a switch to disable this new "feature".

Glad to see more customers speaking up about this… it’s a simple, fixable issue. All they need to do is keep allowing the switch: Add ($allow_adminarea_invoice_mutation = true;) in your WHMCS configuration.php . WHMCS choosing a one-size-fits-all strict model is what’s really causing the pain… let us decide if we need to deal with regional compliance and added accounting complexity, not force it on everyone.

A system should be designed to be functional for its paying customers, rather than being dictated by external regulations that may or may not be applicable to all users. Implementing such a feature without a proper disable option is impractical and appears to be an oversight. The current suggested workarounds are ineffective for the majority of standard web design and hosting businesses. Remember, most projects start off with two 50% (published) invoices (deposit and final) from the quote when converted and the final invoice typically gets tweaked for various reasons. This change would prevent that quick 10 second update to it. WHMCS should focus on developing efficient software that delivers value to its users, allowing us to manage legal compliance independently, rather than introducing features that hinder usability.

Yes, I agree they should be an option

While I understand that bugs are part of any Release Candidate cycle, it's concerning that we are still discussing basic optimization issues like proper OPcache support. And let's not even get started on the fact that we still don't have 100% native Nginx support. This becomes particularly ironic with the introduction of the new WHMCS Cloud Solution. With cloud hosting, the resource costs are on their side, so you'd think they'd be rushing to support Nginx to reduce their own infrastructure expenses. It's like being sold a high-performance engine but being told you have to power it with hamster wheels. Maybe once their bills start rolling in, Nginx support will suddenly become a priority. This all points to the bigger issue: the development velocity. Core development feels like it's just about "keeping the lights on" (PHP/ionCube updates) rather than actual innovation. This stagnation has allowed third-party developers like ModulesGarden to build entire businesses by selling us functionality that should have been in the core a decade ago. When you look at the "Total Cost of Ownership" license fees + necessary third-party modules, the value proposition is slipping. Newer platforms like Upmind are entering the market with an API-first architecture and modern features built-in from day one. If WHMCS continues to outsource innovation to the community while raising prices for maintenance updates, that competitive threat is going to become an exodus very quickly. We need core features that match the modern hosting landscape, not just compatibility patches.

@WHMCS John If you want this to be the new default Stripe module, a migration path from the current default Stripe module will be necessary.

Yeah this is a nightmare

This is what one WHMCS Staff tell me You have the option to make the change to your WHMCS configuration.php file and add the line $allow_adminarea_invoice_mutation = true;, but it is your decision whether to do so. When this line is present in your configuration.php file, the system will permit most of the changes to invoices that existed before WHMCS version 9.0, notably: Line items can be changed for invoices in any status (when in the "Manage" mode and with the correct admin user permissions set). All attributes are available in the Options tab regardless of the invoice status (when in the "Manage" mode and with the correct admin user permissions set). Payments can be applied in the Add Payment tab regardless of the invoice status (with correct admin user permissions set). Please note that using this configuration line ($allow_adminarea_invoice_mutation = true;) in your WHMCS configuration.php The file is highly discouraged, as it may permit changes that are not compliant with regional/country business regulations and complicate accounting. To bring awareness of this, a Warning health check will appear in the System Health Check summary when the value is present in your WHMCS configuration.php file. Additionally, all “full administrators” will see an Admin Warning banner (which can be dismissed up to every fortnight). You may want to add it temporarily if you do need to make the changes listed above, which were changed in WHMCS version 9.0 to improve invoice management and ensure tax compliance by keeping invoice records consistent. If you do not see any warnings or have issues with editing invoices or changing their status when this line is added, please let us know. Starting with WHMCS version 9.0, non-Draft invoices are immutable. This means you cannot edit transactions (now listed under the Ledger section on the invoice), add or remove items, or modify descriptions on an invoice once it’s no longer in the "Draft" status. This change is intended to improve invoice management and ensure tax compliance by keeping invoice records consistent. For more information on invoice management in WHMCS version 9.0, please refer to the following documentation: https://docs.whmcs.com/9-0/billing-and-invoicing/invoice-management/

I never imagined that a simple update could introduce so many problems — and even worse, apparently without proper testing. It is absolutely ridiculous for a financial management system to have its own financial logic broken. In the last 24 hours, I finally received a response on the open support ticket, along with a so-called “patch” (attached). In practice, this patch only fixes the reports by hiding the incorrect ledger entries. However, in several other areas of the system, the incorrect postings are still happening. For example, the “Transactions” tab inside the client profile continues to show wrong values and misleading entries. So, in short, this patch does not actually fix the root problem — it only masks it in specific reports. For now, apply it if you want to slightly reduce the visible impact, but be aware that the financial logic is still broken in multiple parts of the system. At this point, we are seriously considering rolling back to a previous version — or even migrating away from WHMCS entirely. Year after year, the pricing increases exponentially, while the quality of support continues to decline and critical issues like this keep happening. The current level of instability and support simply does not justify the price they are charging anymore. whmcs_v9.0.0-supporthotfix.1_750a0b77ff.321_WHMCS-24949.zip

Okay, maybe I was too quick about credit notes. It seems a lot of the features are "coming soon™️". This is not a Release Candidate lol. This is not even alpha. This is internal development. Nothing can convince me that this release didn't just happen because WHMCS promised us a release in December.

I've recently had to investigate one of those slightly annoying WHMCS problems: the cron job appears to be running correctly, but some executions never actually finish. This can be surprisingly easy to miss. Having cron.php started every 5 minutes only tells us that cron is starting it every 5 minutes. It doesn't tell us whether the previous execution actually completed. If an automation task hangs — because of an external API, a registrar/module, a network problem, a database issue, custom code, etc. — you may eventually end up with several overlapping cron.php processes without immediately noticing what is going on. I put together a debugging approach that gives visibility into three different levels: whether the PHP cron process actually starts and terminates; whether the WHMCS automation cycle enters and exits normally; which individual WHMCS automation task starts but never returns (or simply takes an unusually long time). The basic idea is to use the PreCronJob / AfterCronJob and PreAutomationTask / PostAutomationTask hooks, combined with a simple external shell wrapper and a check for overlapping processes. Instead of just knowing: "The WHMCS cron seems to get stuck sometimes." you can hopefully get to something much more useful, such as: cron.php started DomainSync started another cron.php process started another cron.php process started DomainSync never returned At that point, at least you know where to start looking. I've written up the complete procedure, including the hooks, shell script, logging examples and some additional notes here: https://eurossl.eu/knowledgebase/whmcs-cron-job-stuck-debugging/ I'm posting this because I'd still like to contribute useful technical information back to the WHMCS community. However, after fighting over the years with the community's occasionally ("creative" code editor, formatting issues, disappearing posts and similar adventures), I've decided to keep the full article and code somewhere I can actually maintain them. 🙂 Hopefully this will save someone a few hours of debugging.

Seems it's an error I'd say. I randomly checked a few others in the marketplace, and that's the only one doing that. Frustrating it's the WHMCS addon, but things like this can creep in, especially on an addon that's been around a long while.

That's a small red flag. Anything that is using http today indicates a lack of care, error or just ignorance.

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

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.

Hello @sahostking Thank you for your message. We are aware of this issue in WHMCS 8.13.4, which is currently being tracked under case WHMCS-26568 with our development team. A hotfix has been attached to this message to address this issue for you and anyone else. Please upload and extract the contents of the attached file into your WHMCS installation directory, allowing it to overwrite the existing files. I hope this helps! WHMCS-26568-hotfix.zip

Hi everyone, I would like to share a free community addon I created for WHMCS 9.x: CW Invoice Mutability for WHMCS 9.x Repository: https://github.com/RicRey1988/cw-invoice-mutability-whmcs-9.x WHMCS 9 introduced invoice immutability for non-Draft invoices. I understand the reason behind this change from an accounting and audit-trail perspective, but I also noticed that some administrators still need a controlled way to manage invoice editing in specific internal cases, especially before an invoice is paid or before it is synchronized with an external tax/e-invoicing system. This addon provides an admin interface to manage the current WHMCS invoice mutability compatibility option without manually editing configuration.php. Main features: Enable or disable invoice mutability from the WHMCS Admin Area. Automatically add or remove the current WHMCS compatibility flag: $allow_adminarea_invoice_mutation = true; Create a backup of configuration.php before modifying it. Optionally hide the WHMCS Admin Area warning banner about invoice immutability being disabled. Advanced/emergency mode to convert eligible Unpaid invoices back to Draft. Audit log table with invoice snapshot, invoice items, transactions, admin ID, IP address, reason, and timestamp. Safety checks to block Draft conversion when the invoice has transactions, payment date, or possible external/tax authorization references. PayPal donation link included for anyone who wants to support the project. The advanced Draft mode is intentionally restricted. It is not intended for already-paid, fiscalized, externally authorized, or tax-reported invoices. In those cases, the correct workflow should normally be credit notes, cancellation, voiding, or re-issuance according to local accounting rules. Installation: The folder must be named exactly: cw_invoice_mutability Final WHMCS path: /modules/addons/cw_invoice_mutability/ Required structure: modules/ └── addons/ └── cw_invoice_mutability/ ├── cw_invoice_mutability.php ├── hooks.php ├── README.md └── lib/ └── CwInvoiceMutabilityTools.php You can clone it directly with: cd /path/to/whmcs/modules/addons git clone https://github.com/RicRey1988/cw-invoice-mutability-whmcs-9.x.git cw_invoice_mutability Then activate it from: Configuration > System Settings > Addon Modules After activation, go to: Addons > CW Invoice Mutability This addon is free and community-oriented. It is not affiliated with WHMCS. If it helps you, donations are welcome: https://paypal.me/hostingsupremo Feedback, improvements, and pull requests are welcome.

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?

I’ve added: $allow_adminarea_invoice_mutation = true; Honestly, this change is a nightmare for our daily workflow. We need to edit invoices every day, and with this new restriction, what used to be a simple operation has become an everyday problem. In my opinion, this was a very bad decision from a usability point of view, especially for companies that manage billing operations daily and need flexibility when handling invoices.

Unbelievable that all of our questions lately are being ignored. What's the point of this community?

Not everyone wants SAAS solutions, or keeping data with a third party due to concerns about client data. I'm one of those businesses.

Request WHMCS to make it a confugurable option instead of removing it?

The one question I have is "why"? Clearly there's a need and demand for it, why is it not even considered being made optional, with warnings about not doing it or what have you. Why is it simply removed, with no options and so on.

Whats stupid is as a developer this is as simple as adding a checkbox to the config to allow us to choose ourselves. I've never in my life understood why software companies lock you in, instead of giving you the option. You keep increasing prices year after year and you want us to stay with you, but if you keep doing this crap most of your base is not gonna find value in your ever increasing prices.

Welcome to the common sense reasons why were frustrated about WHMCS enforcement of preventing us from editing our OWN invoices we created in the first place. Credit / debit is useless in real world standard practice. If they want to provide a switch to disable editing published invoices or changing status fine, but dont force it on the customer base. That's dumb.

Are there still issues after the 9.0.3 release?

add this line to your configuration.php it will go back to normal behavior $allow_adminarea_invoice_mutation = true;

Thank you for the terrible WHMCS support. This is now the tenth client who has made a bulk payment and the late fee is simply not added to the invoice, and none of the outstanding invoices are automatically marked as paid. I’m not even going to mention the credit and debit issues anymore, because it seems the WHMCS developers themselves don’t even know what they’re doing. Does anyone have a suggestion for another system similar to this garbage?

I think you guys may be dramatically underestimating what AI is capable of, but I suppose we shall see. As for the post being suitable or not, Webpros has done everything in their power to alienate their client base - this type of post is the inevitable consequence of that.

"Luck" isn't really a component here. If you haven't played around with agentic coding I can see why this would seem like a stretch for you, but it's quite trivial to get a fairly simple billing system up and running quite rapidly. And like I said this is with current-level tools, in a year or two, replicating the entirety of WHMCS would likely be very doable.

Yeah, except for adding AI to domain search, this release doesn't really provide on any of the other promises. Credit notes doesn't work either. When you cancel an invoice, WHMCS just adds a transaction to the invoice. If the invoice has a total of $100, WHMCS just adds a transaction of $100 and cancels the invoice. There's no credit note or anything.

How WHMCS have set this as a RC instead of a Beta is insane. It's a huge upgrade in terms of it's impact on themes/modules. No beta, no reply from WHMCS, no forums specific to v9.

Your process sounds good apart from WHMCS. I would never recommend trying to import tables to new files. You need to update your existing install as normal. You can update from your version but you may have more luck doing a manual update. Backup everything, upload the new v8.13 files, adjust your hosting/server settings to meet the requirements (e.g you may need to update PHP) then run the installation script.

@BENELUX, Today's the day!! https://blog.whmcs.com/133775/whmcs-90-release-candidate-out-now

This week or next! It sure would be nice to double the size of the engineering team temporarily for one release every few years!

@stormy, I'm glad to hear the e-invoicing feature will be a real value add for you. We are working with expert solution-providers in this space, so we're confident about delivering an easy to use and compliant solution with the broadest coverage. @andp97, Yes, by the end of the year in a pre-release version of WHMCS you will have access to this new feature. This bullet point actually describes two significant features which we're very excited about: 1. A RESTful API which provides access to the product catalogue and shopping cart logic. This will provide a suite of new endpoints to get product catalogue information, add, manipulate and get information about items in the cart (including price breakdowns and totals) and much more, all without touching the cart.php file or PHP session data. This means that power users could create their own highly-bespoke frontends whilst WHMCS handles the maths in the background, before seamlessly passing visitors to the checkout page to complete payment. 2. A brand new thin client powered by the aforementioned new API capabilities, providing a thoroughly modern purchase experience based on Vue.js. I've attached a sneak peak below. The new BuyFlow is a compiled Single-page application, meaning the layout isn't manipulated through templates, but you will be able to customise the colours to match your theme through a custom.css overrides file. The shopping cart as it exists today (cart.php and order form templates) isn't going away and will still be available if you'd like to stay with the familiar experience. Stay tuned to our blog and socials over the coming weeks for more information!

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.

Hi @venkat.j, The current latest version is 8.13. This behaviour suggests the dates were set to 00/00/0000, either by an admin (in which case there should be an entry in the client's Log tab) or by a rogue after-market module (in which case there probably wouldn't). You can edit the date fields to set the actual dates and click Save Changes. The correct dates will be stored.

So after we have been told to rather use the Add Payment method instead for every single individual invoice, up to now for 15 years I have ALWAYS used the "Mark Paid" option for bank transfers as this is genuinely helpful when you have 5 invoices that need to be marked as paid. Now I have to edit every single invoice and mark them paid manually. What a MESS!! But now how do we fix the invoices that have credit notes added to them that are not being included in the reporting that were all marked with "Mark Paid" button? We can't edit the invoice after it has already been marked as paid and emails and invoices receipts have already gone out to clients! Did you manage to rectify the ones that have credit notes and were marked paid using the "Mark Paid" button so it shows in the financial reports? Do we just mark them as UNPAID and then add a payment? or what?

We have discovered an issue with 9.0.3 and were able to replicate it, if a customer has >100 billable items, once over 100 it will generate an invoice for each item Reproduced on an isolated test client with all custom hooks fully disabled; still fragmented at >100. ◦ Exact boundary confirmed: clean at 100, breaks at 101 (50→1, 99→1, 100→1, 101→2, 250→101 invoices). Once we rolled back to 8.13.3 it worked as normal and only produced 1 invoice >100

https://pearstream.com (I do not own this site or services, I only made the custom template)

@WHMCS John Can you please clarify?

Check the domain at NEO, as @RadWebHosting suggests the payment of the invoice will trigger a renewal with the registry. If NEO support domain syncing then the expiry update will be updated in due course. I can't find the article but the way to do this without getting a renewal processed is to edit the invoice. Then on a new line copy and paste the details of the domain and dates, add the price and then delete the original line. WHMCS links the line item to the action of renewal. By deleting the original line the renewal action is not done.

This is one of the most ludacris updates to whmcs I've seen in a long time! If they take away the editable feature I as well am done, been with whmcs for more than 10 years, this would be it for me. You don't get to tell me how to run my business. We have over 400 customers in the system, say goodbye to my monthly fee whmcs if you keep this up. You do realize that most guys in this community that pay you could spin up your replacement in a day or two in chatgpt right?? Only reason we don't is convenience, we have more important things to do, but this is going too far! I'm getting tired of these breaking updates.

We waited for V 9.0.2 in the hope that it will have no issues, and had the misfortune of upgrading. And since then spent an entire day trying to get it to work and it does not work. Issue 1: When you add a product to the Cart", the Nexus Cart shows empty with this warning: "error has occured" (screenshot below) Issue 2: I renamed nexus_cart to nexuscart, and then the Cart showed the product added to it, but several warning appeared on screen: "Internal Error. Try again later". (screenshot below) Issue 3: When you try to increase the number being ordered (1 to 2), you get another error: "invalid product/item ID". (screenshot below) Issue 4: When you try to remove the product by clicking the Trash icon, the product doesn't get removed. Issue 5: When you click Checkout, you encounter the same "internal error. try again". warning. Issue(s) 6: There are so many CSS issues and white spaces problems on the Nexus template and Nexus cart, which require endless customisations to fix. And, now cron has run, and we can't revert the backup and have to figure out another way to revert to previous version. Seriously, how can we rely on whmcs to bill our customers? More issues below: (8) When you activate Nexus Template and Nexus Cart, on Small screens (mobile and tablets), the Navbar becomes Hamburger menu (which is the correct behaviour), but it leaves massive White Space in the Navbar's place. That destroys the look of the product and other pages on whmcs. (9) I activated "Standard Cart" due to the previous issues, but when you add a domain and another product to Standard Cart, the Cart only shows Product and not the domain name. I think the same issue occurs on Nexus Cart too.

This also doesn't work for us. In our country (Thailand) you are only not allowed to change/edit paid invoices. Any other type is no problem. We use the "Edit invoice" option a lot. It would be better if there is a configuration option where we can choose which types of invoice could be edited. Or just make some check boxes in the "admin role" page, so that we can choose which type of invoices can be edited.

Stepping back from this specific issue, it does feel like a broader pattern within WHMCS rather than an isolated problem with NexusCart. I do not have insight into WHMCS internal development processes, and this is not intended as criticism of individual contributors, but from a customer and integrator perspective the overall direction can be difficult to follow. Over recent releases, we have seen recurring regressions, incomplete fixes, and features that appear to ship without being fully validated across real world installations. When combined with limited transparency around known issues or roadmaps, it creates the impression of fragmented development and weak internal communication. WHMCS is a mission critical platform for many businesses, so stability, predictable releases, and timely fixes are just as important as new features. At times it feels like significant bugs or long requested improvements are either delayed for extended periods or quietly deprioritized, which makes long term planning and confidence in upgrades challenging.

Definitely disable autoupdates 😧

Already opened up a bug (ticket DVZ-331740), just creating this here as well I have a couple of really, really old WHMCS versions (some at 7.1.x), deliberately, to do testing and whatnot for clients. Since they're dev installs and locked down to me only, I'm not terribly worried about threats there. Tried to upgrade one of the 7.1.x versions to 9 and couldn't do so. 'Cannot read configuration file' the system said Rolled back backup, upgraded to 8.13, then to 9, worked like a charm Just a heads up for those that may be in the same position. Looks like some earlier versions aren't available for a direct upgrade

I Need to.. any whmcs developer ? Thank you