Leaderboard

Hi all, Thanks very much for your feedback on the invoice immutability and credit/debit notes implementation in v9.0. We heard you loud and clear, and I'm pleased to say that in v9.1 we have implemented an admin-configurable Invoice Immutability setting. You can enforce invoice immutability, relax it while keeping billing notes, or turn it off entirely. For more information check out our release highlights, try it out yourselves, and share your feedback in the v9.1 Beta Discussion Board

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.

Can't say I agree there. This will likely bite you at some point, badly.

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

Automatic MarketConnect Account Registration: If your install isn't linked to a Marketplace account, 9.1 now attempts to create one during upgrade, with a starter credit applied. WHMCS has now reached a this point. I'm sure the community cannot wait for this highly requested feature. 🤣 it's clear that WHMCS is now at the stage of milking the software and community as much as possible.

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.

Trying to download ImportAssist from Marketplace (https://marketplace.whmcs.com/product/46-importassist ) Using Chrome: the download process just gets stuck, without any error message Using Edge: I got the error "ImportAssist_v1.5.3.69 (2).zip can't be downloaded securely" Using Opera or Tor: the download is completed successfully

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!

Great! They need a month to publish hotfix contains a new word in code 🙂

WHMCS support have told me recently that they're focusing on support tickets, and this community is not a good way to obtain support. Send a support/bug report and include the URL to your post and they will reply. Would be great if you post the reply here too. Will most likely be a case/bug number for a future release.

There are still issues. The nexus cart is API driven and WHMCS has not considered existing functionality for additional fields for domains (something that is in their documentation). Hold off for now. Unless you want to answer customer questions, and/or miss out on sales.

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

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.

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.

As product manager, I should think he has more pressing responsibilities than this community. Busy with that job, vacation, who knows?

As you might know, whmcs has a problem with stripe: when the payment is not immediately confirmed by stripe (but requires to clic "capture" on stripe dashboard), whmcs does not record the order and the customer details and does not even send any notification to whmcs admin or to the customer. We solved with a hook that sends us an email with the order details, so that: - we know that there was a order attempt - we know that there might be a payment in stripe that requires manual "capture" - if necessary, we have all the client and order details in order to recreate the both client account and order. Here is the hook. <?php if (!defined("WHMCS")) { die("This file cannot be accessed directly"); } /** * Save all checkout data to a TXT file * AND email it to admin * Runs BEFORE order/invoice creation, and before redirect to Stripe. */ add_hook('ShoppingCartValidateCheckout', 1, function ($vars) { // --- 1. Clone and sanitise incoming data ------------------------------- $data = $vars; // Mask any possible card data (good practice even if Stripe never posts it) $sensitiveFields = [ 'ccnumber', 'cccvv', 'ccexpirymonth', 'ccexpiryyear', 'password', 'password2', ]; foreach ($sensitiveFields as $field) { if (!empty($data[$field])) { $data[$field] = '***masked***'; } } // --- 2. Attach cart contents from session (products, domains, etc.) --- $cart = isset($_SESSION['cart']) ? $_SESSION['cart'] : []; $payload = [ 'timestamp' => date('Y-m-d H:i:s'), 'ip' => $_SERVER['REMOTE_ADDR'] ?? null, 'user_agent' => $_SERVER['HTTP_USER_AGENT'] ?? null, 'checkoutFields' => $data, 'cart' => $cart, ]; // --- 3. Build a text representation (for file & email) ---------------- $entry = "==============================\n"; $entry .= "Checkout submitted: " . $payload['timestamp'] . "\n"; $entry .= "IP: " . ($payload['ip'] ?? 'N/A') . "\n"; $entry .= "User-Agent: " . ($payload['user_agent'] ?? 'N/A') . "\n\n"; $entry .= "DATA:\n" . print_r($payload, true) . "\n\n"; // --- 4. Save to TXT file ---------------------------------------------- $logDir = __DIR__ . '/../../logs'; $logFile = $logDir . '/pre_stripe_checkout.txt'; if (!is_dir($logDir)) { @mkdir($logDir, 0700, true); } @file_put_contents($logFile, $entry, FILE_APPEND); // --- 5. Send email to admin ------------------------------------------- // This uses WHMCS' built-in admin notification helper. // The "system" type means it goes to the system email / admin notifications. if (function_exists('sendAdminNotification')) { $subject = 'Pre-Stripe Checkout Captured'; // Use <pre> so the print_r formatting is readable in HTML email $message = nl2br(htmlspecialchars($entry)); sendAdminNotification('system', $subject, '<pre>' . $message . '</pre>'); } // IMPORTANT: Do NOT return an error. Just let checkout continue. return; }); I suggest to implement it. It would be great if it would offer some sort of customization in the admin area.

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.

The WHMCS.Community is intended to provide a place for users of WHMCS to discuss, share and interact with each other as well as WHMCS Staff. To ensure we maintain a friendly environment, we ask users to respect the following rules and guidelines. Please let us know via the WHMCS.Community Assitance category should you have any questions or comments, posts in this category are visible between yourself and the WHMCS.Community Team. WHMCS reserves the right to alter these rules from time to time. 1.User Accounts Each person may have (one) 1 forum login regardless of the number of companies you may be part of. Duplicate accounts will be removed from WHMCS.Community Please do not share your user account with others - each person should retain their own username and password Usernames must not be created that contain any of the items listed below: An email address A website address The following words WHMCS cPanel Staff Moderator Admin Any word determined to cause offence or be deemed inappropriate. Usernames or Users that do not comply with these rules may be removed from WHMCS.Community 2. Behaviour on the Community We expect all users to be friendly and polite. While we understand that users will disagree and have different points of view at times, this can be communicated in a civil manner Please do not post rude, insulting or inflammatory posts. Personal attacks, name-calling and insults will not be tolerated on WHMCS.Community. Profanity and inappropriate images (including porn or gross violence) may not be posted anywhere on the WHMCS.Community. WHMCS.Community Staff & Moderators use their sole discretion as to what is deemed unacceptable behaviour in the community and may remove content at any time. Your posts assist other users, please do not delete content if you find an answer, please share this solution to help other users. 3. Advertising on WHMCS.Community Advertising, offers or self-promotion are to be posted only in the Third Party Add-ons section of the community. Community users seeking to hire a developer may post within the Service Offers & Requests section. Advertising is limited to one advertisement per seven (7) day period on a rolling 7-day basis. Additional or excessive advertising will be removed by the moderation team and your ability to post in advertising boards removed. Soliciting and/or self-promotion via the private messaging (PM) system is strictly prohibited. The sale or reselling of WHMCS Licenses is strictly prohibited on the community. Affiliate and referral links may not be used, these links are those that link to a site and contain information crediting the person with that referral 4. Posting and Moderation on WHMCS.Community The WHMCS.Community is moderated by WHMCS.Community Moderators and Staff. When a post is deemed to be in breach of the rules it will be removed and the user advised via a warning. Please do not cross-post across the community. If your topic is better suited to another section one of the WHMCS.Community team will move it to the best category for you. You may report your post if you wish to have it moved by a moderator. For privacy reasons please do not post any personally identifiable information including Usernames, Passwords, Contact Numbers, Email Addresses and/or Credit Card Numbers As WHMCS.Community is a moderated community we have implemented a Warning System. When a post is removed for breaching the community rules we’ll be sure to let you know. We allocate points to a warning and once you have a set number of points you may be suspended from posting on the community. Users that do not comply with the rules for WHMCS.Community may be banned temporarily. Ongoing temporary bans may result in a permanent ban from WHMCS.Community. The public discussion of moderation decisions is not permitted, these will be removed without notice and may result in a community ban. 5. Signature and Profile Rules Your signature may include links, however, please ensure these are reasonable (no more than 4) and they must not include Referral/Affiliate links. This includes pricing and plan details Signatures may not contain more than 4 lines at a 1024x768 resolution Please do not sell or rent your signature space, your signature is yours alone. Where your signature does not comply with these rules you may be asked to alter or remove it 6. WHMCS.Community Ranks Official WHMCS Staff & Moderators are identified by one of the following ranks located below their profile image, in addition, their posts are highlighted blue WHMCS CEO WHMCS Community Manager WHMCS Customer Service WHMCS Developer WHMCS Marketing WHMCS Staff WHMCS Support Manager WHMCS Technical Analyst WHMCS.Community runs a ranking system, new community members start with the rank of Newbie and can progress based on the number of posts, reputation points and length of time active on the community Some users have a special “Super Users” rank. These members are a select group of elite community members that are long-standing mentors in the community, courteous to other members, always providing technical insight and advice, and generally helping to make our community a better place to learn, troubleshoot and advance. The WHMCS.Community ranking formula is changed from time to time and without notice. The algorithm used is not published or discussed with users to prevent gaming the system 7. Contacting the WHMCS.Community Team You may contact a member of the WHMCS.Community via the WHMCS.Community Assitance board If you would prefer to email you may open a ticket by emailing forums@whmcs.com Thank you for helping to keep WHMCS.Community a great place