Leaderboard

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

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.

I have updated to WHMCS 9 In vendor files the folders was updated, but the folders not required anymore was not removed by the automatic update tool as when I compare WHMCS 8,13 and 9 they are removed. So remember to remove these manually people true sonata-project Facebook container-interop My questions why does the update process not clean and remove everything that is "old". What happend with the quality of the WHMCS releases .. .

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

As long‑time WHMCS users running production hosting environments, we are increasingly concerned that WHMCS is drifting away from the real‑world needs of modern providers. Recent changes in 9.0 have exposed serious weaknesses not only in the financial engine, but also in the underlying technical architecture. The points below are not “nice to have” feature requests, they are fundamental requirements for any billing and automation platform that claims to be suitable for professional hosting companies in 2026. This is not about squeezing more revenue out of the existing user base to please investors, it is about delivering a product that is technically and financially solid enough to justify its price. 1. Financial & Reporting Integrity in 9.0 The new credit/debit note system in WHMCS 9.0 has introduced critical issues that make the financial data untrustworthy for real‑world operations: - Late fees are being treated as “Amount Out” (expense) in reports, even though they are actually additional income. - Cancelled invoices can appear as income for the day, despite no payment being made. - When a client adds credit and then uses that credit to pay an invoice, WHMCS counts both the credit addition and the invoice payment as income, even though it is the same money. For any company that needs reliable cash‑flow and revenue reporting for accountants, auditors, or tax authorities, this is a show‑stopper. A billing system where income/expense classification and basic cashflow are wrong cannot be considered production‑ready, regardless of how many UI tweaks or new themes are shipped on top. 2. Missing Modern Infrastructure Support (Technical Must‑Haves) In 2026, a hosting/billing platform that wants to be taken seriously must natively support modern web stacks and performance patterns. WHMCS is still heavily tied to an old‑fashioned Apache/mod_php‑style deployment model and largely ignores how providers actually scale PHP apps today: - No first‑class Nginx support: no official, up‑to‑date Nginx configurations, rewrites, security hardening, or best‑practice deployment guides. - No built‑in awareness of PHP OPcache: no guidance around optimal configuration, cache warmup, or avoiding stale‑code issues during updates and cron execution. - No native support for Redis/Memcached for sessions and application caching: WHMCS still assumes legacy PHP session storage and database‑driven patterns instead of modern, distributed caches. - No support for full‑page caching layers (such as Varnish or Nginx fastcgi_cache): no cache‑invalidation hooks, no official cache‑header strategy, and no clear statement of what can safely be cached and where it must be bypassed. For a billing/control application that often sits at the center of a hosting provider’s stack, this is a major architectural gap. Providers are forced to run WHMCS as a “special snowflake” on outdated PHP hosting patterns, while the rest of their infrastructure is containerized, horizontally scalable, cache‑aware, and built around Nginx and Redis by default. 3. Pricing, Investors and Misaligned Priorities Over the last years, WHMCS has significantly increased prices and tightened client‑based tiers. For many small and mid‑sized providers, license costs now consume a noticeable percentage of monthly revenue, especially when factoring in required third‑party modules to fill functional gaps. The problem is not just the higher price. The problem is what we are (not) getting in return: - Core billing logic that fails to represent real cashflow correctly. - Lack of native support for modern infrastructure (Nginx, Redis, full‑page caching). - Ongoing dependence on paid third‑party modules for things that should be core in a product at this price level. From the outside, it feels like the priority has shifted towards making investors and the holding company happier by pushing ARPU up, instead of investing deeply in stability, compliance, and technical modernization. Hosting providers are being asked to pay more for a platform that, in several critical areas, is standing still or even regressing. If WHMCS is going to charge premium pricing, it must deliver a premium‑grade product: technically modern, financially robust, and compliant in real‑world scenarios. 4. What Hosting Providers Need From WHMCS If WHMCS wants to remain relevant for professional hosting companies, the following should be treated as non‑negotiable priorities: 1. A fully audited, correct financial engine - Credit and debit notes that do not break basic accounting logic. - Accurate cash‑flow and revenue reporting that can be trusted by accountants and tax authorities. - Clear separation and correct handling of invoices, credit notes, cancellations, add‑funds and overpayments. 2. Native support for modern infrastructure - First‑class, documented support for Nginx, including recommended configurations and security best practices. - Built‑in support for Redis/Memcached for sessions and caching. - Official guidance and hooks for PHP OPcache management and safe deployment. - A clear, supported pattern for full‑page caching (Varnish / Nginx cache), including proper cache‑invalidation and headers. 3. Roadmap and communication aligned with operators, not just investors - Focus on fixing structural problems in billing, reporting and architecture before adding cosmetic features. - Transparent communication about critical bugs and security issues, not silent updates. - A pricing model that reflects the actual value delivered and acknowledges that many customers are small and mid‑sized providers, not just large enterprises.

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.

Hi John. Is there any further news on the ETA for this release?

Definitely disable autoupdates 😧

You may want to check in softaculous you may have the auto update turned on. Go into Softaculous find your install click on edit details auto upgrade select do not auto upgrade. With regards to 9.0 their will still be a lot of developers slightly behind. WHMCS didn't exactly give developers alot of notice with regards to the changes.

Whmcs doesn’t autoupdate - someone is initiating the update. You’re using addons that are not compatible- yet. Logos is not compatible Roll back and stay there till all your addons declare compatibility with v9.

Una buona notizia e' che il nostro team di sviluppatori sta attivamente lavorando per aggiungere la gestione di fatture elettroniche in una delle prossime release di WHMCS. In attesa di avere piu' dettagli nei prossimi mesi, non si hanno ancora tempistiche o specifiche. Certo e' che si potranno emettere fatture elettroniche in diversi formati, incluso Fattura PA. Per rimanere aggiornati potete sottoscrivere alla feature request corrispondente: https://requests.whmcs.com/idea/add-electronic-invoicing

Appreciate the clarification, that’s really helpful. Good to know the main pain points are deeper core and API changes rather than just the checkout UI, especially around billing logic like late fees and credits. That’s exactly the kind of thing that can quietly cause issues after an upgrade. I’ll definitely take a closer look at your practical notes and keep this in mind before moving to WHMCS 9.0.

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.

Thanks for the detailed update! It’s great to see that ModulesGarden is moving quickly with WHMCS 9.0 compatibility, especially for modules like cPanel Extended and Proxmox VE. I’m curious have you noticed any specific issues or challenges when integrating custom-developed WHMCS modules with the new version, particularly around the updated checkout experience or recurring payments? It would be helpful to know what to watch out for before upgrading.

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.

Hi @BENELUX, Work to implement our e-invoicing solution with direct integration with the Peppol network (BIS Billing 3.0) is in progress. We are currently in the final stages of polishing the integration and conducting rigorous testing. Given the critical importance of financial compliance, we are prioritising stability to ensure the solution is robust upon release in Q1 2026.

I’m honestly not convinced by these repeated price increases, especially when they happen without clear prior notice. I’m a small provider managing around 10–20 clients only, and with the latest increase, the subscription is becoming financially unjustifiable. At this scale, the cost is no longer proportional to the value received and is starting to feel more like a burden than a business tool. I understand that businesses evolve, but constant yearly increases without meaningful added value for small users come across as exploitation rather than progress. If this pricing strategy continues, I’m seriously considering moving away from the entire WebPros ecosystem, including WHM and WHMCS. At the very least, there should be better transparency, advance notifications, and fair pricing options for low-usage customers.

@EnricoloDi niente! Occhi puntati su quando verra' rilasciato WHMCS 9.0 😀

Dear all, Is there any documentation provided by WHMCS regarding custom security module? I want to create custom OTP functionality for logging in, and I believe how to achieve it is by creating custom security module but I cant find any documentation online. I have checked that there are several providers sell modules for OTP, so I think it is possible to achieve it. Any suggestion are welcomed. Thank you

I haven't noticed any difference, enom support still sucks just as much as it always has.

Technically the other way round - opensrs bought enom and that’s when enom fell apart

I just tested it with WHMCS v8.2.1 and the hook works fine here. However, I noticed an error when generating the hostname, it did not consist of random characters. I suspect that you did not put the hook into the correct directory. Attached you ind the updated hook including the directory structure, so you can simply upload the extracted content directly to your WHMCS root directory. hook.zip