Critical Financial Report Issues After Updating to WHMCS 9.0.0

[Paulo Henrique]

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.

[Damo]

Yes, seeing this also. It's a mess. 'When' a fix is published we are hoping that the reporting will be retrospective when viewed. 

[Evolve Web Hosting]

It does not help either of you now and I am sorry you two are experiencing this. When WHMCS makes a major release and has NO BETA, it's going to be a disaster.

Any chance that you have a backup that you can restore to the previous version?

[Paulo Henrique]

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

[RadWebHosting]

Strongly agree @Evolve Web Hosting

[CHP]

i have the same issue here.- Is there any ETA to be resolved?

[WHMCS John]

Hi all,

The implementation of Credit/Debit notes and all the  surrounding logic and reporting is the single biggest transformation of the system's logic in our 20 year history, it is no exaggeration to say this is a very significant undertaking.

In 9.0 we have implemented many under-the-hood changes to transform the entire accounting system from Cash Basis to Accrual Accounting. This enables the fundamentals of invoice immutability and automated credit/debit notes. We will continue this accounting-focus into v9.1 to achieve full invoice immutability, manual credit note management, comprehensive update of reports and widgets, e-invoicing and updated invoicing APIs.

We're grateful for your feedback on your immediate reporting needs, and the late-fee upgrade bug. As such we are releasing v9.0.1 this week which will address the issues raised here in this thread:

WHMCS-24931 — Improved handling of existing Invoice Late Fees when upgrading to version 9.0
WHMCS-24949 - Exclude Billing Notes from Admin Area income statistics
WHMCS-24950 - Exclude Billing Note Transactions from Cashflow Reports

...plus some other high-priority cases we've identified.

Thank you for coming with us on this journey in 2026 as we evolve the WHMCS business functions to the next level!

[BENELUX]

Thanks for the update @WHMCS John. It is reassuring to hear that a fix for the critical reporting and late fee bugs (WHMCS-24931, 24949, 24950) is arriving this week with v9.0.1.

The shift to accrual accounting is clearly a massive undertaking, but accurate cash flow reporting is non-negotiable for us to operate.

While we are discussing high-priority fixes for this release window, could you please confirm if WHMCS-24661 (M365 Shared Mailbox import issues) is also slated for resolution in 9.0.1 or 9.1?
This issue is currently preventing us from properly importing/finding shared mailboxes via the Microsoft 365 integration, which is a critical part of our support workflow. Like the financial reporting bugs, this is hindering daily operations.

We appreciate the transparency on the roadmap for 9.1, but getting these functional defects resolved in the immediate hotfix would be a huge relief.

Looking forward to the release notes 🙂

[WHMCS John]

Hi @BENELUX,

Case  WHMCS-24661 is not part of 9.0.1. I see that support are tracking reports of this use-case from any other users, and that will help inform any changes in prioritisation.

[WHMCS John]

Hi all,

We've released 9.0.1 with these maintenance fixes: https://docs.whmcs.com/releases/9-0/9-0-change-log/#version-901-maintenance

[Paulo Henrique]

I have updated my WHMCS installation to version 9.0.1 and noticed that some of the previously reported issues have indeed been corrected. The debit and credit values are no longer being incorrectly counted in the financial reports, the homepage billing widget, or the “Transactions” tab within the client profile, which is a positive improvement.

However, the issue related to invoice cancellation still persists. When a client requests a cancellation, for example, we are still unable to properly cancel the issued invoice.

As a workaround, I added the following line to the 'configuration.php' file:

$allow_adminarea_invoice_mutation = true;

After adding this setting, the invoice can be cancelled. However, the system continues to generate multiple credit notes, even though these are no longer reflected in the reports. This behavior is particularly concerning because these credit entries remain visible on the client’s invoice, and the client may reasonably question why a cancelled invoice shows applied credit entries.

In practice, the behavior is as follows: the client requests a cancellation, the invoice cannot be cancelled normally, and each attempt to cancel the invoice results in a new credit note being created. If the cancellation is attempted multiple times, multiple credit notes are generated. When the configuration option is enabled, the invoice can finally be cancelled, but a credit note is still added regardless.

This creates confusion both internally and for the client, as it gives the impression that credits were issued when, in fact, the invoice was simply cancelled and no credit should have been generated at all.

Although the recent update addressed part of the problem, this remaining behavior continues to affect invoice integrity and client transparency.

[BENELUX]

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.