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".

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.

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

Hi WHMCS ecosystem developers! I am excited to share an early heads-up about the upcoming WHMCS 9.0 release by the end of 2025 - a major update that brings important changes to the platform’s technical requirements. As part of this release, several core dependencies will be updated, and minimum system requirements will be increased. These changes are designed to improve performance, security, and compatibility with modern PHP standards. Key Updates in WHMCS 9.0: Minimum PHP version: 8.2 Recommended PHP version: 8.3 Minimum ionCube Loader version: 13.0.2 or higher Recommended ionCube Loader version: 14.4.0 or higher Updated dependencies: A number of underlying libraries and components have been upgraded. Some notable changes include: Smarty v3.1.48 —> v4.3.4 Legacy Smarty Tags are being deprecated and will no longer function in 9.0. Smarty Template Objects (including their use in plugins) will no longer be supported. guzzlehttp v7.4 —> v7.4.5 illuminate v7.x —> v9.0 I have attached a provisional list of dependency changes to this post. Please also use this thread to provide your feedback and ask questions of the Development Team regarding these requirement and dependency changes. These changes will require action from module developers to ensure continued compatibility. We recommend reviewing your module code and preparing for updates ahead of the release. We’ll be sharing more details, including a release window, definitive changelog and developer guidance, between now and the end of 2025 to help you get ready. Thank you for being a valued part of the WHMCS ecosystem. We appreciate your continued support and look forward to working together to make WHMCS 9.0 a successful release. whmcsv90_composerlock_provisional.txt

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.

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.

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!

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.

Hi all, In 8.13 a small improvement was made to the accounting of refunded mass-pay invoices. Prior to this the totals of mass-pay invoices were included in the overall income statistics, but now they are excluded as it's already accounted for by the original invoices.

But you did ask them, and not by just posting here? EDIT: This is a bit old now, but a fast search on this board found:

Hello, Not at all and it's highly recommended, to change the admin path.

Is anyone else experiencing serious financial and reporting issues after upgrading to WHMCS 9.0.0? I updated my system as soon as the final version was released, and since then the financial data no longer matches the reports (Monthly Transactions) or the dashboard widget on the home page. After the introduction of Debit Notes and Credit Notes, the entire financial system started behaving incorrectly. Here are some examples of what is happening: When a client pays late, the cron correctly generates the late fee. However, this amount is recorded as “Amount Out” in the financial reports, even though no money left the system. This is a charge to the client, not an expense. When an issued invoice is cancelled (either due to service cancellation or any other reason), the outstanding invoice balance is displayed as income for the day, despite the fact that no payment was made. When a client adds account credit and later uses that credit to pay an invoice, both values are recorded as income: the credit addition the invoice payment even though it is the same money. Since the implementation of these accounting notes, the financial data no longer reflects the real cash flow. I opened a support ticket and provided detailed explanations, screenshots, videos, and database examples for testing. The support team confirmed that this is a critical system defect. However, it has now been over one week since the ticket was opened, and there has been no fix, workaround, or technical update provided. If this issue is truly critical — and it clearly is — how can it remain unresolved after seven days? We are talking about a financial system, where the absolute minimum expectation is that: income is recorded as income expenses are recorded as expenses reports reflect the real cash flow At the moment, none of this is happening. I would like to know if other users are facing the same problems after upgrading to WHMCS 9.0.0, because in its current state it is practically impossible to operate the system without performing daily manual corrections directly in the database.

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

If I had to guess, it's not an arbitrary decision, but based on some legal requirement they must follow or get into trouble. I'd have hoped a "change this at your own risk" choice would suffice, but maybe they don't want to chance someone claiming they missed it. Just a guess.

While invoice editing can currently be re-enabled via $allow_adminarea_invoice_mutation = true; in configuration.php, this option is reportedly being removed in a future release. This raises a practical concern: how are administrators expected to handle routine tasks such as removing late fees or splitting system-generated invoices that are linked to products and services?

Hi, Thanks for reaching out. AI-powered domain suggestions are part of the WHMCS Namespinning lookup providers functionality now: https://docs.whmcs.com/releases/9-0/9-0-release-highlights/ You can switch to another lookup provider if you don't wish to leverage the functionality of the WHMCS Namespinning lookup provider. Please see: https://docs.whmcs.com/8-13/domains/lookup-providers/

Thank you!

Thank you for your reply. I can't attach a screenshot because I don't have permission to edit the topic :) I'll leave it here, you can download and take a look.

Hey, after upgrading from 8.x to 9.x, I'm getting a strange issue: if I go to the configuration >> Sign-in option, Activate any social login, add the app ID and secure key, and save it, I get a strange issue. It shows the integration is activated; in the console, it returns success. But when I refresh the page, the integration reverts to the inactive state. I also don't see any active buttons on the Login and Sign-in pages, nor do I get any log or error message.

Thanks a lot for the kind words! Based on our testing so far, the bigger challenges in WHMCS 9.0 aren't so much about the new checkout UI, but about changes deeper in the core. WHMCS updated core libraries and parts of their API, which means existing integrations often need to be adjusted. There are also changes in how late fees and credit payments work, and those can affect billing, including recurring charges. These are some of the areas where modules, both off the shelf and custom ones, may not behave as expected if not updated. We shared a more practical take on this here, based on our ongoing work with WHMCS 9.0. If you're running custom functionality and want to be sure everything works the way it should, feel free to contact our team. We'll gladly talk it through and help you understand what, if anything, needs adjusting.

Personally I wouldn't recommend using it for production. There's a few reports of issues since upgrading which is common with new versions. Better to wait a few weeks for any bugs to get fixed.

am using 8.3 version now. i migrated my whmcs to a new server. but now the crons are not wrking properly. And am getting the following messages. Remove dead screens with 'screen -wipe'. #11 /home/mywhmcs/public_html/clients/vendor/whmcs/whmcs-foundation/lib/Installer/Composer/ComposerUpdate.php(0): WHMCS\Installer\Composer\ComposerUpdate->doComposerCommand(Object(Closure)) #12 /home/mywhmcs/public_html/clients/vendor/whmcs/whmcs-foundation/lib/Installer/Update/Updater.php(0): WHMCS\Installer\Composer\ComposerUpdate->getLatestVersion(true) #13 /home/mywhmcs/public_html/clients/vendor/whmcs/whmcs-foundation/lib/Cron/Task/CheckForWhmcsUpdate.php(0): WHMCS\Installer\Update\Updater->fetchComposerLatestVersion() #14 /home/mywhmcs/public_html/clients/vendor/whmcs/whmcs-foundation/lib/Scheduling/Task/AbstractTask.php(0): WHMCS\Cron\Task\CheckForWhmcsUpdate->__invoke() #15 /home/mywhmcs/public_html/clients/vendor/whmcs/whmcs-foundation/lib/Scheduling/Task/AbstractTask.php(0): WHMCS\Scheduling\Task\AbstractTask->execute() #16 /home/mywhmcs/public_html/clients/vendor/whmcs/whmcs-foundation/lib/Cron/Console/Command/AbstractCronCommand.php(0): WHMCS\Scheduling\Task\AbstractTask->run() #17 /home/mywhmcs/public_html/clients/vendor/whmcs/whmcs-foundation/lib/Cron/Console/Command/AbstractCronCommand.php(0): WHMCS\Cron\Console\Command\AbstractCronCommand->executeCollection(Object(WHMCS\Scheduling\Task\Collection)) #18 /home/mywhmcs/public_html/clients/vendor/symfony/console/Command/Command.php(255): WHMCS\Cron\Console\Command\AbstractCronCommand->execute(Object(WHMCS\Cron\Console\Input\CliInput), Object(Symfony\Component\Console\Output\ConsoleOutput)) #19 /home/mywhmcs/public_html/clients/vendor/symfony/console/Application.php(912): Symfony\Component\Console\Command\Command->run(Object(WHMCS\Cron\Console\Input\CliInput), Object(Symfony\Component\Console\Output\ConsoleOutput)) #20 /home/mywhmcs/public_html/clients/vendor/symfony/console/Application.php(264): Symfony\Component\Console\Application->doRunCommand(Object(WHMCS\Cron\Console\Command\AllCommand), Object(WHMCS\Cron\Console\Input\CliInput), Object(Symfony\Component\Console\Output\ConsoleOutput)) #21 /home/mywhmcs/public_html/clients/vendor/symfony/console/Application.php(140): Symfony\Component\Console\Application->doRun(Object(WHMCS\Cron\Console\Input\CliInput), Object(Symfony\Component\Console\Output\ConsoleOutput)) #22 /home/mywhmcs/public_html/clients/crons/cron.php(0): Symfony\Component\Console\Application->run(Object(WHMCS\Cron\Console\Input\CliInput), Object(Symfony\Component\Console\Output\ConsoleOutput)) #23 {main}[mywhmcs@hmserver ~]$ ^C [mywhmcs@hmserver ~]$ /opt/cpanel/ea-php74/root/usr/bin/php -q /home/mywhmcs/public_html/clients/crons/cron.php all -F -vvv^C

lol It has tons of missing features (just look at credit notes) and shipped with hardcoded paths to /var/www/html/whmcs. Not feature rich, not stable.

I'd suggest that your average user that grabs a script like this will not change anything in it, especially since they're not (apparently) being told to. I've seen users not change a "CHANGE_THIS" in scripts, then ask why it's not working. I've also seen them ignore the "remove this file after use", so relying on that might not be advisable either. Best practice is not to spoon feed, keep this outside the publicly accessible directories, and instead of that simple URL parameter you reveal, make it a "secret key" that is defined within the script, with a note to change it (or better still they make their own that must be x long and have this or that in it; if empty, fail with "key needed"). Safety first.

Thanks 🙂 Now displaying well. Shame multicurrency isn't working properly but beggars can't be choosers it's nice to have this feature back.

@DristiTechnologies Thank you so much for the analysis. This was more than I anticipated so it is very VERY much appreciated. 👍

Hi @ZeroMB, Thanks for that information. I've logged case #WHMCS-22693 with our developers in order to have this reviewed for future releases. Whilst I cannot provide an estimated time for completion for this, once we resolve cases and push features they are available at our change log, here: https://changelog.whmcs.com/ Thanks again for taking the time to report your findings.

Are you sure you haven’t modified the JSON files in BillingExtension/core/BillingExtension_Admin/resources/country, or changed the tbltax table in the WHMCS database at any point? I ask because Greece is correctly displayed with the ISO code GR and listed under Europe. The only place where the module uses the value EL is for VIES validation, as required, since Greece is represented as EL in the VIES system. As for the Canary Islands, they are not an EU country but a region of Spain, similar to how Normandy is part of France. If, as I assume, you need to handle tax rules for Las Palmas and Santa Cruz de Tenerife (special tax regimes of Canary Islands), you need to click the orange button next to Spain. From there, you can configure the specific tax settings in the modal window. Tick checkboxes to make them tax exempt. That said, given your question, specifically, how to treat the Canary Islands as an Intra-EU country even though, as mentioned earlier, they are not a country but a region of Spain, it leads me to suspect that you may have manually modified the tbltax table in WHMCS at some point. This is likely the root cause of the issue. The table should look like this with both regions defined as state under the same country, Spain (ES). In any case, when using only the BX interface for managing Tax Rules, no issues should occur.

Here is an updated link: https://controlc.com/d0ac5777

Hi. For convenience, I wanted to create a custom model for my module. I didn't like having to call Capsule every time I needed information that the module stored in the database. I want to share the code here in case other people didn't know how to do it but also to gather some feedback on this way of doing it. <?php namespace WHMCS\Module\Addon\MyModule; use WHMCS\Model\AbstractModel; /** * Convenience model for custom modules */ class MyModel extends AbstractModel { // Set the table that should be used for searching protected $table = 'mod_mymodule'; // We almost always have access to the service ID. Has to represent a column in the mod_mymodule table protected $primaryKey = 'serviceid'; } When using the model, we're able to do MyModule::find() or create a new instance using 'new MyModule()'.

With GSuite announcing that they will be discontinuing password-based access in the near future, will WHMCS be updated to support OAuth connections for POP Importing and SMTP in future versions?